„Sie schreiben, dass eine Stornierung bis 48 Stunden vorher kostenlos ist. In unserer Offerte steht aber etwas anderes.“
Der Support-Mitarbeiter öffnet das Chat-Protokoll. Der Bot hat eine klare Antwort gegeben. Nur: Im Log steht nicht, welche Richtlinie er verwendet hat, welche Version davon und ob vielleicht zwei Dokumente gleichzeitig im Kontext lagen.
Das Problem ist nicht zwingend, dass das Wissen veraltet war. Vielleicht waren beide Dokumente aktuell. Vielleicht galt eines nur für Firmenkunden und das andere für Privatkunden. Ohne Herkunft der Antwort lässt sich der Streit kaum sauber klären.
Genau deshalb braucht ein produktiver RAG-Chatbot Provenance: nicht als akademisches Extra, sondern als Antwort auf die einfache Frage „Worauf basiert diese Aussage?“
Aktualität und Herkunft sind zwei verschiedene Kontrollen
Am 27. Juli haben wir bei AlpenAgent über aktuelles Servicewissen geschrieben. Dort geht es um Verantwortlicher, Gültigkeit und Ablaufdatum von Informationen. Provenance löst ein anderes Problem.
Ein Dokument kann von gestern sein und trotzdem die falsche Grundlage für diesen Kundenfall bilden. Oder ein altes Dokument kann bewusst noch für bestehende Verträge gelten. „Neueste Version“ ist deshalb nicht immer gleich „richtige Version“.
W3C beschreibt Provenance als Informationen über Entitäten, Aktivitäten und Beteiligte, die zur Entstehung eines Datenobjekts geführt haben. Für einen KMU-Chatbot müssen Sie dafür kein W3C-Datenmodell vollständig implementieren. Der praktische Kern reicht:
- Welche Quelle wurde verwendet?
- Welche Version oder welches Änderungsdatum hatte sie?
- Welcher Abschnitt stützt die Aussage?
- Für welchen Geltungsbereich gilt die Quelle?
- Welche anderen Quellen standen im Konflikt?
Bestätigter Fakt: W3C PROV wurde genau für die interoperable Beschreibung von Herkunft und Ableitung von Informationen entwickelt.
Empfehlung des Autors: Für kundenwirksame Aussagen sollte ein RAG-System mindestens source ID, Version und relevanten Abschnitt im internen Trace speichern, auch wenn dem Kunden nicht jede technische Referenz gezeigt wird.
Nicht jede Chatbot-Antwort braucht einen sichtbaren Quellenkasten
Wenn jemand fragt „Habt ihr am Samstag offen?“, kann eine direkte Antwort mit einem Link zur Öffnungszeit sinnvoll sein. Wenn der Kunde „Danke“ schreibt, braucht es keine Citation.
Anders sieht es bei Aussagen aus, die Geld, Rechte, Fristen oder eine konkrete Zusage betreffen: Stornobedingungen, Preisbestandteile, Garantie, Verfügbarkeit, Vertragswechsel, Rückerstattung, Liefertermin oder Leistungsumfang.
Hier sollte der Bot in einen Evidence Mode wechseln. Das bedeutet nicht, dass jede Antwort wie eine wissenschaftliche Arbeit aussieht. Es bedeutet, dass die Herkunft technisch mitgeführt und bei Bedarf sichtbar gemacht wird.
Ein guter Flow kann so aussehen: Der Bot antwortet knapp, zeigt „Quelle: Stornobedingungen, Version 12.08.2026“ und bietet einen Link zum relevanten Abschnitt. Intern speichert das System zusätzlich Dokument-ID, Chunk/Abschnitt, Retrieval-Zeitpunkt und gegebenenfalls weitere Kandidaten.
Bei sensiblen internen Dokumenten gehört die Quelle natürlich nur dann zum Nutzer, wenn dieser sie sehen darf. Provenance ersetzt keine Berechtigungen.
Der schwierige Fall ist nicht „keine Quelle“, sondern zwei widersprüchliche
RAG-Demos zeigen gerne eine saubere Wissensbasis. In Firmenwissen liegen aber oft mehrere Wahrheiten nebeneinander.
Die Website sagt „24 Stunden kostenlos stornieren“. Das PDF im Sales-Ordner sagt 48 Stunden. Eine E-Mail-Vorlage nennt eine Ausnahme für Gruppen. Im CRM hängt noch eine Sondervereinbarung für diesen Kunden.
Ein schlechter Chatbot wählt einen Treffer und formuliert daraus eine selbstbewusste Antwort.
Ein besserer Chatbot erkennt, dass die Quellen nicht konsistent sind. Dann lautet die Arbeitsregel nicht „nimm die Quelle mit dem höchsten Similarity Score“, sondern: Konflikt + materielle Auswirkung = keine definitive Zusage ohne Prüfung.
Der Agent kann sagen: „Ich finde zwei unterschiedliche Stornoregeln für diesen Fall. Ich lasse das kurz von unserem Team prüfen.“ Damit verliert der Bot keine Autorität. Er verhindert, dass scheinbare Sicherheit zu einer falschen Kundenvereinbarung wird.
Auch eine eindeutige Quelle kann problematisch sein. Ein Absatz ist juristisch unklar. Eine Tabelle hat keine Einheit. Ein internes Memo ist nie freigegeben worden. Provenance macht die Schwäche sichtbar, löst sie aber nicht automatisch.
So baut man Provenance in einen KMU-Chatbot ein
Starten Sie nicht mit einem neuen Vektor-Stack. Starten Sie mit der Wissensquelle.
- Geben Sie jedem relevanten Dokument eine stabile ID, einen Verantwortlichen und eine Version oder ein Änderungsdatum.
- Speichern Sie beim Retrieval nicht nur den Text-Chunk, sondern auch Quelle, Abschnitt und Berechtigungskontext.
- Definieren Sie Antwortklassen: Routine, kundenwirksame Zusage, sensible Information, Konfliktfall.
- Zeigen Sie Quellen dort sichtbar, wo sie dem Kunden bei der Prüfung helfen; halten Sie interne Nachweise ansonsten im Trace.
- Lassen Sie widersprüchliche oder schwach belegte Aussagen abstain/weitergeben statt „best guess“ spielen.
- Prüfen Sie regelmässig, ob Links, Dokumente und Versionen noch erreichbar sind.
Ein wichtiger Sonderfall ist das Löschen einer Quelle. Wenn das Dokument nachträglich entfernt wird, darf der Log nicht so tun, als sei die Antwort weiterhin voll belegbar. Speichern Sie deshalb genug Metadaten für Audit und definieren Sie eine Aufbewahrungsregel, die zum Datenschutz und zum Geschäftszweck passt.
Übergabe an Menschen: Quelle mitgeben, nicht nur die Frage
Wenn ein Chatbot eskaliert, sollte der Mitarbeiter nicht erneut suchen müssen. Die Übergabe enthält die Kundenfrage, die vorläufige Antwort, die verwendeten Quellen, den Konflikt und den Grund für die Eskalation.
Bei einer Preisfrage könnte das heissen: „Website Preisliste v4 sagt CHF X; Kundenvertrag 2025 enthält Sonderkondition; Bot hat keine finale Zahl genannt.“ Das ist ein brauchbarer Arbeitsauftrag.
Wichtig: Der Mensch bleibt auch dann verantwortlich für die Entscheidung, wenn die Quelle sauber aussieht. Provenance verbessert Nachvollziehbarkeit; sie garantiert nicht, dass das Dokument korrekt, vollständig oder rechtlich anwendbar ist.
Minimaler Pilot und fünf Metriken
Nehmen Sie eine Wissensdomäne mit echten Streitpunkten, etwa Storno, Lieferbedingungen oder Serviceumfang. Bauen Sie 30–50 Fragen, darunter bewusst widersprüchliche und mehrdeutige Fälle.
Messen Sie Antworten mit vollständigem Source Trace, kundenwirksame Antworten mit korrekter Quelle, Konflikte, die erkannt statt verdeckt wurden, Übergabe-Fälle mit vollständiger Evidenz sowie nicht belegte definitive Aussagen. Zusätzlich lohnt sich die Zeit, die ein Mitarbeiter benötigt, um eine eskalierte Antwort zu verifizieren.
Ein guter Chatbot soll nicht nur die richtige Antwort ausspucken. Bei wichtigen Aussagen muss Ihr Team später nachvollziehen können, warum diese Antwort entstanden ist. Wenn das System diese Herkunft nicht kennt, ist sein Selbstvertrauen für den Betrieb deutlich weniger wert.
Die Pflege des Wissens erklären wir in aktuelles Servicewissen für Chatbots. Für interne Dokumente verhindert RAG mit Berechtigungen, dass ein hilfreicher Quellenhinweis selbst zum Datenleck wird.
Quellen
Vor dem Aufbau steht die Wahl der notwendigen Technik. Der Vergleich RAG oder Fine-Tuning ordnet fehlende Fakten, Suchfehler und Ausgabeprobleme getrennt ein und macht den Pflegeaufwand sichtbar.
FAQ
Muss jede Antwort eine sichtbare Quelle haben?
Nein. Für Routinefragen kann ein unaufdringlicher Link reichen. Materielle Zusagen sollten intern immer nachvollziehbar sein und bei Bedarf eine sichtbare Quelle erhalten.
Reicht es, den Dokumentnamen zu speichern?
Oft nicht. Version, Abschnitt und Retrieval-Zeitpunkt helfen, wenn Dokumente geändert werden oder mehrere Regeln ähnlich heissen.
Was tun bei widersprüchlichen Quellen?
Keine definitive Antwort erzwingen. Konflikt markieren und bei kundenwirksamen Fragen an einen Menschen übergeben.
Ist Provenance dasselbe wie RAG?
Nein. RAG holt Wissen in den Antwortprozess. Provenance dokumentiert, welche Herkunft und Ableitung hinter der konkreten Antwort stand.
Was, wenn die Quelle später gelöscht wird?
Definieren Sie eine Audit- und Retention-Strategie. Der Trace sollte zeigen, welche Quelle damals verwendet wurde, ohne Datenschutzregeln zu ignorieren.