RAG statt Halluzination: Wie Unternehmens-Chatbots verlässlich werden

Warum Sprachmodelle überzeugend falsch antworten

Ein Sprachmodell sagt das jeweils wahrscheinlichste nächste Wort voraus. Es besitzt kein internes Konzept davon, ob eine Aussage zutrifft — es erzeugt Text, der zu seinen Trainingsdaten passt. Fehlt die konkrete Information, entsteht deshalb keine Fehlermeldung, sondern eine plausibel formulierte Erfindung. Genau das macht Halluzinationen im Unternehmenskontext gefährlich: Sie sind sprachlich nicht von korrekten Antworten zu unterscheiden.

Hinzu kommt der Stichtag der Trainingsdaten. Ein Modell kennt die eigenen Produktpreise, internen Prozesse oder die aktuelle Lieferzeit eines Unternehmens grundsätzlich nicht — diese Informationen waren nie Teil des Trainings. Auf die Frage nach der Rückgabefrist antwortet es dann mit dem, was branchenüblich ist, statt mit dem, was tatsächlich gilt.

Was Retrieval-Augmented Generation konkret ändert

RAG dreht die Reihenfolge um: Statt das Modell aus dem Gedächtnis antworten zu lassen, wird zuerst in den eigenen Dokumenten gesucht und das Modell anschließend gebeten, die Frage ausschließlich anhand der gefundenen Textstellen zu beantworten. Das Modell liefert damit nicht mehr das Wissen, sondern nur noch die Formulierung.

Technisch werden die Unternehmensdokumente dafür in Abschnitte zerlegt und in eine Vektor-Darstellung überführt, die inhaltliche Aehnlichkeit abbildet statt wörtlicher Uebereinstimmung. Eine Frage nach "Wie lange kann ich zurückgeben?" findet so auch einen Abschnitt, der von "Widerrufsfrist" spricht. Die passendsten Abschnitte gehen zusammen mit der Frage an das Modell.

Der praktisch wichtigste Nebeneffekt: Weil bekannt ist, aus welchen Abschnitten die Antwort stammt, lässt sich die Quelle mit ausgeben. Aus einer nicht überprüfbaren Aussage wird eine Antwort mit Beleg — und Nutzende können im Zweifel selbst nachlesen.

Die Qualität entscheidet sich beim Aufbereiten, nicht beim Modell

Der häufigste Grund für schlechte RAG-Ergebnisse ist nicht ein zu schwaches Modell, sondern eine schlechte Aufbereitung der Dokumente. Werden Texte stur nach Zeichenzahl zerschnitten, endet ein Abschnitt mitten im Satz und die entscheidende Bedingung landet im nächsten Block, der nie mitgeliefert wird. Sinnvoller ist ein Schnitt entlang der Struktur — Ueberschriften, Absätze, Tabellenzeilen — mit etwas Ueberlappung an den Rändern.

Ebenso wichtig ist die Aktualität des Bestands. Liegen im Index zwei Versionen einer Preisliste, wird das Modell irgendeine davon zitieren, und zwar mit derselben Ueberzeugung. Ein RAG-System braucht deshalb einen definierten Prozess dafür, wie Dokumente hineinkommen und — vor allem — wie veraltete wieder herausfliegen. Ohne diesen Prozess verschlechtert sich die Antwortqualität im Betrieb kontinuierlich.

Wo auch RAG nicht hilft

RAG löst das Problem fehlenden Wissens, nicht das Problem fehlender Logik. Fragen, die eine Rechnung über mehrere Dokumente hinweg erfordern — "Wie viele Aufträge aus dem letzten Quartal sind noch offen?" — beantwortet ein Retrieval-System schlecht, weil die Antwort in keinem einzelnen Abschnitt steht. Solche Fragen gehören an eine Datenbankabfrage, nicht an eine Textsuche.

Ebenso bleibt die Zugriffskontrolle eine eigene Aufgabe. Wird der gesamte Dokumentenbestand ohne Rechteprüfung indexiert, kann der Chatbot Inhalte aus Bereichen zitieren, die die fragende Person nicht sehen dürfte — ein Datenschutzvorfall, der sich technisch trivial vermeiden lässt, wenn die Berechtigungen bereits bei der Suche und nicht erst bei der Anzeige greifen.

Und schließlich verschwindet die Halluzination nicht vollständig. Findet die Suche keinen passenden Abschnitt, neigt das Modell weiterhin dazu, etwas zu formulieren. Ein belastbares System braucht deshalb eine ausdrückliche Anweisung und Prüfung, bei fehlender Grundlage "das steht mir nicht zur Verfügung" zu antworten — und eine Eskalation an einen Menschen.

Woran sich ein tragfähiges RAG-Projekt erkennen lässt

Ein belastbares System liefert zu jeder Antwort die Quelle mit, kennt eine definierte Abbruchbedingung bei fehlender Grundlage, respektiert bestehende Zugriffsrechte und hat einen dokumentierten Weg, wie Inhalte aktualisiert werden. Fehlt einer dieser vier Punkte, entsteht ein System, das im Demo-Termin beeindruckt und im Betrieb Vertrauen kostet.

Sinnvoll ist ausserdem, mit einem eng umrissenen Bereich zu starten statt mit dem gesamten Firmenwissen — etwa nur der Produktdokumentation. Ein kleiner, sauber gepflegter Bestand liefert bessere Antworten als ein großer mit widersprüchlichen Ständen, und die Qualität lässt sich in einem begrenzten Bereich überhaupt erst beurteilen.