Start KI-Lösungen Fertige Lösungen Peers & Simulation RAG & Retrieval Use Cases Frameworks Blog English Kontakt
Zurück zum Blog

Das RAG, das wir wirklich gebaut haben, gegen das aus den Diagrammen

Referenzdiagramme für Retrieval-Pipelines zeigen acht oder neun Kästen. Unseres hat vier, und zwei davon existieren nur, weil ein konkreter Fehler sie erzwungen hat. Hier die Abrechnung: was jede Stufe gekostet hat, was sie gefangen hat und was wir wieder entfernt haben.

Vier Kästen, nicht neun

Unsere Retrieval-Pipeline im Betrieb besteht aus einem Chunker, einem hybriden Index, einem Cross-Encoder-Reranker und einem Generierungsschritt mit Schema auf der Ausgabe. Das ist alles. Jede Referenzarchitektur, die uns in Workshops gezeigt wurde, hat mindestens doppelt so viele Stufen, und jede davon ist für sich vertretbar.

Wir sind nicht aus Minimalismus bei vier gelandet, sondern weil wir eine Stufe nur ergänzen, wenn ein gemessener Fehler sie verlangt, und alles entfernen, was seinen Beitrag auf dem Referenzset nicht zeigen kann. Das Ergebnis ist kleiner als die Diagramme, und dieser Unterschied gehört erklärt statt entschuldigt.

Dokumentechunks · vektoren Indexvektor + volltextgraph Frage Hybride Sucherrf Rerankercross-encoder Antwortmit quellen
Dokumente werden gechunkt, eingebettet und indexiert — Vektoren plus Volltext. 1/4

Das Vokabular, das geholfen hat

Gao und Kollegen haben in jenem Dezember eine Übersichtsarbeit veröffentlicht, die das Feld in naives, fortgeschrittenes und modulares Retrieval-Augmented Generation ordnet, mit benannten und getrennten Stufen vor, während und nach dem Abruf. Übersichtsarbeiten ändern selten, was wir bauen, aber diese hat verändert, wie wir darüber sprechen.

Vorher war ein Gespräch über Query-Rewriting ein Gespräch über eine bestimmte Umsetzung, von der jemand gelesen hatte. Danach war es ein Gespräch über eine benannte Stufe mit bekanntem Zweck — was die nützliche Frage viel leichter stellbar machte: Was würde sie hier fangen, und woran würden wir es merken?

Was sich jede unserer Stufen verdient hat

Das Chunking hat seinen Platz verdient, weil es der größte einzelne Hebel war, den wir gefunden haben. Der Wechsel von Splits fester Größe zu strukturbewussten, die Überschriften und Tabellengrenzen respektieren, hat die Retrieval-Qualität stärker verändert als jeder Modellwechsel im selben Zeitraum.

Der hybride Index hat ihn verdient, weil er den Fehler abdeckt, den ein reiner Vektorindex nicht abdecken kann: exakte Kennungen. Teilenummern und Vertragsreferenzen sind genau die Anfragen, bei denen semantische Ähnlichkeit nutzlos und Volltextabgleich exakt ist — und zugleich die, bei denen ein Fehler den Nutzern am deutlichsten auffällt.

Die Stufe, die wir ergänzt und wieder entfernt haben

Wir haben etwa zwei Monate lang Query-Rewriting betrieben. Die Idee ist stimmig: die Nutzerfrage vor der Suche erweitern oder umformulieren, damit abweichendes Vokabular keinen Recall mehr kostet. Auf unserem Referenzset brachte es eine kleine Verbesserung und einen neuen Fehlermodus, bei dem eine umformulierte Anfrage weit genug abdriftete, um selbstsicher eine andere Frage zu beantworten.

Der kleine Gewinn überlebte nicht, dass der neue Fehler schwerer zu bemerken war. Wir haben die Stufe entfernt und den Aufwand stattdessen in den Chunker gesteckt, der denselben Vokabularbruch weitgehend dort behebt, wo der Text indexiert wird, statt dort, wo gefragt wird.

StufeWarum sie bei uns drin ist oder nicht
Strukturbewusstes ChunkingDrin. Größter gemessener Qualitätshebel
Hybrider IndexDrin. Deckt exakte Kennungen ab, die Vektoren verfehlen
Cross-Encoder-RerankingDrin. Reihenfolge zählt so viel wie Auswahl
Query-RewritingRaus. Kleiner Gewinn, ein schwer bemerkbarer neuer Fehler
Multi-Hop-RetrievalRaus. Unsere Fragen verketten sich nicht so
Wissensgraph-SchichtRaus. Kosten trafen nie auf einen Fehler, den sie gefangen hätte

Die zwei, die wir weiterhin nicht betreiben

Multi-Hop-Retrieval fehlt, weil unsere Fragenverteilung es nicht braucht. Nutzer fragen nach einem Auftrag, einem Vertrag, einem Teil. Eine Pipeline, die eine Kette von Abfragen plant, bringt Latenz und Fehlerfläche für einen Fall, der deutlich unter einem Prozent des Verkehrs ausmacht — und dieser Fall ist bei einem Menschen besser aufgehoben.

Eine Graphschicht fehlt aus einem anderen Grund: Wir konnten nie auf einen Fehler zeigen, den sie gefangen hätte. Das Verfahren ist mächtig, und wir erwarten, es einzusetzen, sobald ein Kundenbestand die nötige Beziehungsdichte hat. Bisher hatte keiner sie, und es auf Verdacht zu bauen hieße, eine Komponente zu bauen, die niemand bewerten kann.

Wie wir entscheiden, eine Stufe aufzunehmen

Eine Stufe kommt hinein, wenn wir den Fehler benennen können, den sie beseitigt, ihn im Referenzset zeigen können und zeigen können, dass die Stufe ihn behebt, ohne einen schlimmeren einzuführen. Das klingt selbstverständlich und ist der am häufigsten übersprungene Schritt — denn die Alternative ist, eine Stufe zu übernehmen, weil eine Referenzarchitektur sie enthält.

Der Preis des Überspringens ist nicht nur die Stufe selbst. Jede Stufe ist eine weitere Sache, die driften kann, ein weiterer Ort, an dem sich eine Regression verstecken kann, und eine weitere Komponente, deren Verhalten jemand um drei Uhr nachts verstehen muss, wenn die Antworten kippen.

Was uns das kostet

Eine kleine Pipeline hat auch Nachteile. Manche Anfragen behandeln wir schlechter als ein aufwendigeres System es täte, besonders vergleichende Fragen über mehrere Dokumente hinweg — und wir wissen es, weil diese Fälle in unserem Referenzset scheitern und wir uns entschieden haben, sie vorerst nicht zu beheben.

Wir tragen außerdem das Risiko, etwas Hilfreiches ausgelassen zu haben. Die Absicherung ist, dass das Referenzset eine Ergänzung billig bewertbar macht: Jede der drei ausgelassenen Stufen lässt sich an einem Nachmittag ausprobieren und nur behalten, wenn sie sich den Platz verdient.

Was wir nicht behaupten

Wir behaupten nicht, vier Stufen seien allgemein die richtige Zahl. Sie ist richtig für die Bestände und Fragenverteilungen, gegen die wir laufen, und ein Kunde mit dichten Querverweisen zwischen Dokumenten bräuchte vermutlich mehr.

Wir behaupten auch nicht, die Taxonomie der Übersichtsarbeit sei eine Vorschrift. Sie ist eine Karte dessen, was gebaut wurde, keine Liste zum Abarbeiten — und sie als Letzteres zu lesen ist der Weg, auf dem Pipelines Stufen bekommen, die niemand begründen kann.

Quellen