Warum die meisten RAG-Systeme an echten Dokumenten scheitern

Die Demo läuft immer gut. Jemand lädt zwanzig saubere PDFs in ein RAG-System (Retrieval-Augmented Generation), stellt fünf Fragen, und alle werden ordentlich mit Quellenangabe beantwortet. Alle sind beeindruckt.

Drei Monate später hängt dasselbe System am echten Dokumentenbestand, und die Leute haben es still und leise wieder aufgegeben. Die Antworten sind vage oder selbstbewusst falsch, oder sie zitieren ein Reglement, das vor zwei Jahren ersetzt wurde.

Am Sprachmodell liegt das selten. Ein RAG-System hat zwei Aufgaben: die richtigen Textstellen finden und daraus eine Antwort schreiben. Fast alle Fehler passieren bei der ersten Aufgabe. Liefert die Suche dem Modell die falschen drei Absätze, kann auch das beste Modell keine richtige Antwort geben.

Typischerweise hakt es an diesen Stellen.

Die Dokumente sind unordentlicher, als alle zugeben

Echtes Firmenwissen steckt nicht in zwanzig aufgeräumten PDFs. Es steckt in gescannten Verträgen mit einem Stempel quer über dem Text, in Word-Dateien mit Änderungen, die nie jemand angenommen hat, in Excel-Tabellen, bei denen das Wichtigste ein Kommentar in Zelle F14 ist, und in Ordnern namens Archiv_alt_NICHT_LÖSCHEN.

Und es gibt Versionen. Spesenreglement_2022.pdf, Spesenreglement_2024_final.pdf, Spesenreglement_2024_final_v2.pdf. Für ein Suchsystem sind das drei gleichwertige Quellen. Fragt jemand nach der Verpflegungspauschale, vermischt es womöglich alte und neue Regeln zu einer Antwort, die zu keiner von beiden passt.

Das ist kein KI-Problem, und ein besseres Modell löst es auch nicht. Jemand muss entscheiden, welche Dokumente gültig sind, den Rest als archiviert markieren und die Scans durch eine ordentliche Texterkennung schicken. Das ist unspektakuläre Arbeit, und sie bringt für die Antwortqualität mehr als alles andere auf dieser Liste.

Das Zerlegen trennt an den falschen Stellen

Bevor Dokumente durchsucht werden können, werden sie in Abschnitte zerlegt, das sogenannte Chunking. In den meisten Anleitungen geschieht das nach fester Länge, etwa 500 Wörter mit etwas Überlappung. Für Blogartikel geht das. Für Verträge und Reglemente ist es eine Katastrophe.

Eine Aufteilung nach fester Länge schneidet fröhlich eine Tabelle mittendurch, sodass die Spaltenüberschriften in einem Abschnitt landen und die Zahlen im nächsten. Sie trennt eine Klausel vom Satz «sofern in Anhang B nichts anderes vereinbart ist». Sie verliert den Kapiteltitel, und ein Abschnitt mit «die Frist beträgt 90 Tage» sagt nicht mehr, um welche Frist es geht.

Besser ist eine Aufteilung entlang der Struktur des Dokuments: Kapitel, Klauseln, Tabellenzeilen mit wiederholten Überschriften. Jeder Abschnitt sollte zudem seinen Kontext mitführen (Dokumenttitel, Kapitel, Datum), damit er auch für sich allein verständlich bleibt.

Gefragt wird nicht in den Worten der Dokumente

Vektorsuche ist gut bei Bedeutung und weniger gut bei exakten Begriffen. Jemand fragt «Wie lange ist die Kündigungsfrist für Lieferanten?», und im englischen Rahmenvertrag steht «notice period». Jemand sucht nach einer Artikelnummer, und die inhaltlich ähnlichsten Treffer haben damit nichts zu tun.

In Schweizer Unternehmen kommt dazu, dass die Frage auf Deutsch gestellt wird, das Reglement auf Englisch vorliegt und der Lieferantenvertrag auf Französisch.

Hilfreich ist eine Kombination von Verfahren. Die Stichwortsuche findet exakte Codes und Namen, die Vektorsuche findet Bedeutung, und ein nachgelagertes Re-Ranking wählt die Stellen aus, die die Frage tatsächlich beantworten. Die Frage vor der Suche umzuformulieren (Abkürzungen ausschreiben, den Fachbegriff in der anderen Sprache ergänzen) bringt mehr, als man denkt.

Berechtigungen kommen ganz am Schluss

Hier geht es nicht um Qualität, aber genau daran scheitern Projekte. Was der Assistent finden kann, kann er auch zitieren. Liegen HR-Dossiers oder Verwaltungsratsprotokolle im Index, stellt früher oder später jemand eine harmlose Frage und bekommt eine Antwort daraus.

Zugriffsrechte müssen bei der Suche durchgesetzt werden, mit denselben Berechtigungen, die das Dokument bereits in SharePoint oder auf dem Fileserver hat. Ein Satz im Prompt wie «gib keine vertraulichen Informationen preis» ist keine Zugriffskontrolle.

Niemand misst die Suche

Die meisten Teams beurteilen ihr RAG-System, indem sie ein paar Fragen ausprobieren und schauen, wie sich die Antworten anfühlen. So lässt sich nie sagen, ob eine Änderung etwas verbessert oder verschlechtert hat.

Was funktioniert, ist langweilig. Sammeln Sie 50 bis 100 echte Fragen der künftigen Nutzerinnen und Nutzer und notieren Sie zu jeder, in welchem Dokument und Kapitel die Antwort steht. Dann messen Sie zwei Dinge getrennt: Hat die Suche die richtige Stelle gefunden, und war die Antwort richtig, wenn die richtige Stelle vorlag? Ist die Suche die Schwachstelle (das ist sie meistens), wissen Sie jetzt genau, wo Sie ansetzen müssen.

Es hilft auch, dem System zu erlauben, «Dazu habe ich nichts gefunden» zu sagen. Eine ehrliche Nicht-Antwort richtet weit weniger Schaden an als eine flüssig formulierte falsche.

Wo wir anfangen würden

Bekämen wir ein RAG-Projekt, das nicht funktioniert, hätte die erste Woche nichts mit dem Modell zu tun. Wir würden klären, welche Dokumente gültig sind, die Texterkennung bei den schlimmsten Dateien verbessern, das Zerlegen entlang der Dokumentstruktur neu aufbauen und die Testfragen schreiben. Erst danach kämen Prompts und Modelle an die Reihe. Diese Reihenfolge wirkt verkehrt, aber genau daher kommt der grösste Teil der Antwortqualität.