Fehlersuchen im Pipeline-System, nicht im LLM: Ein praktisches Denkmodell für RAG-Fehler in der Produktion
Wenn ein RAG-Bot falsch antwortet, ist das LLM selten die Ursache. Verfolgen Sie die Fehler von der Eingabe über die Abrufung, Erstellung, Bewertung bis zum Schleifenprozess, um die betroffene Stufe zu finden.
Quellen: RAG Is Not Just Vector Search
Stellen Sie sich einen Support-Bot in einem mittelgroßen SaaS-Unternehmen vor, der eines Tages zwei Kunden unterschiedlich antwortet, obwohl beide nach dem Rückgabefenster fragen.
Es wird ein Incident eröffnet, und der diensthabende Ingenieur denkt zunächst, dass das LLM Halluzinationen hat und ein anderes Modell benötigt wird. Das ist die erste, oberflächliche Diagnose. Dabei wird RAG als Black Box behandelt, das Modell ausgetauscht und man hofft, dass das Symptom verschwindet.
Ein erfahrener Ingenieur beginnt anders und fragt, in welcher Phase des Pipelines ein Fehler aufgetreten ist. Zu behaupten, das Modell erzeuge Halluzinationen bei Namen, ist lediglich ein Symptombeschreibung und erklärt nichts weiter.
Zwei Tage später taucht das eigentliche Problem auf. Die Rückerstattungspolitik hatte geändert werden sollen, doch niemand hat das veraltete PDF aus dem Abrufkorpus entfernt, wodurch beide Versionen weiterhin mit ähnlichen Relevanzwerten auftauchten und das Modell den widersprüchlichen Kontext getreu zusammenfasste. Es halluzinierte überhaupt nicht. (Dies ist ein zusammengefügtes Szenario zur Veranschaulichung, doch Varianten davon sind häufig.)
Hier ist der Unterschied zwischen der theoretischen Version von RAG und der Art und Weise, wie RAG in der Praxis versagt. Anleitungen komprimieren dies in der Regel auf eine einzige Zeile:
Embed → Search → Generate
Das reicht für eine Demo aus, aber nicht für die Produktion. Ein echtes System verfügt über mehrere Fehlergrenzen. Die wichtige ingenieurtechnische Frage ist nicht nur, ob das LLM eine gute Antwort schreiben kann, sondern auch, ob jede Schicht, die diese Antwort liefert, ordnungsgemäß funktioniert.
Eingabe: Die Qualität wird bereits vor dem Start der Abfrage festgelegt
Die meisten Fehlersuche-Aktivitäten bei RAG beginnen am falschen Ende. Die Leute passen Anfragen an, wechseln Embedding-Modelle und regulieren den Top-k-Wert, obwohl der eigentliche Fehler bereits Wochen zuvor bei der Eingabe aufgetreten ist.
Auswertung nach Struktur
Tabellen, Codeblöcke, Überschriften und Listen übermitteln ihre Bedeutung durch ihre Struktur. Wenn eine Preisliste in gewöhnlichen Text umgewandelt wird, kann der Zusammenhang zwischen einer Zeile und ihrem Spaltenkopf verschwinden. Ein Eingabepipeline sollte diese Struktur beibehalten und eine Darstellung wählen, die der Abfrage entspricht, anstatt jedes Dokument als einen einheitlichen, ununterschiedlichen Textblock zu behandeln.
Der richtige Ansatz hängt vom Inhalt ab. Eine Tabelle erfordert möglicherweise eine strukturierte Extraktion, eine Textserialisierung, Metadaten oder eine Kombination aus lexikalischer und semantischer Suche.
Chunking nach Bedeutung
Die einfache Methode teilt den Text alle 512 Token auf. Doch die Tokenanzahl stimmt nicht immer mit der Bedeutung überein, wodurch ein Chunk mit einer Einleitung beginnt und mitten im eigentlichen Inhalt endet.
Semantisches Chunking zielt darauf ab, an Stellen von Themenwechseln zu trennen anstatt nach Tokenzahlen zu gehen. Es handelt sich dabei nicht um eine universelle Verbesserung, und die Verarbeitung kostet mehr Zeit. Bei langen Dokumenten wie Richtlinien, Verträgen und technischer Dokumentation führt das Beibehalten ganzer Ideen oft zu besseren Suchergebnissen.
Geben Sie jedem Chunk vor dem Einbetten etwas Kontext
Ein Auszug aus Seite 40 eines 60-seitigen Dokuments kann durchaus gültiger Text sein, dennoch unklar sein, wenn er außerhalb seines ursprünglichen Kontexts steht. Nehmen wir einen Satz, der besagt, dass eine Beschränkung nur für Enterprise-Kunden gilt. Ohne den umgebenden Abschnitt gibt es keine Hinweise darauf, worauf sich „diese Beschränkung“ bezieht.
Die kontextbasierte Extraktion löst dieses Problem, indem sie vor dem Einbetten des Auszugs den Dokumentenkontext voranstellt: den Titel, den Abschnittspfad, das Produkt, die Version oder eine kurze, automatisch generierte Anmerkung dazu, wo sich der Auszug befindet. Ziel ist es, dass jeder Auszug den Kontext behält, den sonst die Aufteilung in Teile entfernen würde.
Metadaten hinzufügen
Betrachten Sie Metadaten als funktionale Daten. Spätere Schritte benötigen Quelle, Datum, Dokumenttyp, Nutzer, Berechtigungen und Version zur Filterung, Zugriffskontrolle, Überprüfung der Aktualität und Fehlerbehebung.
Das wirft eine der wichtigsten Fragen bei der Datenaufnahme auf: Was passiert, wenn sich ein Queldokument morgen ändert? Wenn der Pipeline-Prozess alles nur neu indizieren kann, wird eine kleine Inhaltserstellung zu einer betrieblichen Belastung. Idealerweise sollte die Datenaufnahme inkrementell und idempotent ablaufen, sodass eine Aktualisierung erkannt, verarbeitet und weitergeleitet werden kann, ohne das gesamte Korpus neu aufzubauen.
In der vorangegangenen Geschichte lag das Problem mit der alten Rückerstattungspolitik niemals am LLM – es hing davon ab, wie die Datenaufnahme sowie das Korpus verwaltet wurden.
Die Informationsabrufung ist ein Pipeline-Prozess und keine einfache Suche
Der Begriff lässt auf einen einzigen Schritt schließen. In der Praxis ist die Informationsabrufung jedoch eine Abfolge von Entscheidungen, und diese Reihenfolge hat Konsequenzen.
1. Umformulieren
Menschen schreiben nicht von Natur aus Suchanfragen. Sie fragen beispielsweise, ob die Rückerstattung bereits versandt wurde. Ein LLM kann das in etwas Umsetzen, das für die Suche nützlicher ist – vielleicht indem es das Gesprächsverlauf berücksichtigt oder eine komplexe Frage in kleinere aufteilt. Eine Neufassung ist jedoch nicht kostenlos: Eine schlechte Neufassung kann wichtige Details weglassen oder Annahmen hinzufügen. Betrachten Sie sie als weiteren Aspekt, der bewertet werden muss, und nicht als Zaubertrick.
2. Umfang vor der Suche
Das gehört zu den wichtigsten Produktionsaspekten. Wenn das System mehreren Nutzern dient oder Berechtigungen berücksichtigt, muss der Suchbereich diese Grenzen respektieren. Nutzer, Berechtigungen, Sichtbarkeit, Datum und Quelle sollten innerhalb der Suchoperation angewendet werden, sofern das zugrunde liegende System es zulässt.
Das Filtern nach einem globalen Top-k führt zu zwei Problemen. Erstens könnten nützliche Dokumente bereits durch Dokumente, die der Benutzer nicht sehen darf, aus dem Top-k verdrängt worden sein. Zweitens wird die Autorisierungslogik gefährlich von der Suchfunktion getrennt. Einfach ausgedrückt: Suchen Sie nicht alles und fragen Sie anschließend, was der Benutzer sehen darf. Beschränken Sie die Suche zunächst.
3. Suchen auf zwei Arten
Dichte Vektorsuche bewältigt semantische Ähnlichkeit gut. Jemand, der nach einer Stornomöglichkeit fragt, kann mit Texten abgeglichen werden, in denen steht, dass Kunden ihr Abo jederzeit beenden können – trotz keiner gemeinsamen Formulierungen.
Embeddings sind bei exakten Identifikatoren jedoch schwächer. Denken Sie an solche Zeichenketten:
ERR_CONNECTION_RESET
SKU-48392
API-v3-beta
Bei solchen Abfragen ist das wörtliche Token das Signal, und genau hier findet die lexikalische Suche wie BM25 ihre Anwendung. Die Produktionssuche kombiniert oft die dichte Suche nach Bedeutung mit der lexikalischen Suche nach exakten Zeichenketten.
4. Fusionieren
Es gibt nun zwei gerankte Listen. Die dichte Suche hat ihre eigene Sortierung, BM25 hat wiederum seine eigene, und ihre Rohwerte sind nicht unbedingt vergleichbar. Die Reciprocal Rank Fusion (RRF) bietet eine einfache Methode, sie mithilfe der Rangposition zu verschmelzen:
RRF_score(d) = Σ 1 / (k + rank_i(d))
Jede Liste trägt entsprechend dazu bei, wo sich ein Dokument in ihr befindet, was es vermeidet, die Score-Verteilungen zweier unverwandter Systeme gegeneinander kalibrieren zu müssen.
5. Neubewertung
Fusion liefert eine Liste von Kandidaten, nicht unbedingt den endgültigen Kontext. Ein cross-encoder-basierter Neubewertungsalgorithmus liest die Abfrage sowie jeden Kandidaten gemeinsam und erzeugt einen Relevanzwert für dieses spezifische Paar. Das unterscheidet sich grundlegend davon, Abfrage und Dokument unabhängig einzubetten und anschließend Vektoren zu vergleichen.
Der Aufwand liegt im Rechenaufwand, weshalb man keinen cross-encoder über das gesamte Korpus laufen lässt. Die Suche kann die 20 oder 50 besten Kandidaten zurückgeben, und der Neubewertungsalgorithmus wählt aus diesen den stärksten Kontext aus.
Das zugrunde liegende Denkmodell ist daher erst dichte Suche, dann lexikalische Suche, anschließend Fusion und schließlich Neubewertung. Es handelt sich dabei nicht um eine einfache „Vektordatenbank-Lösung“.
Generierung: Ein guter Kontext garantiert noch keine gute Antwort
Es ist notwendig, die richtigen Dokumente zu finden, doch das reicht nicht aus. Das LLM muss sie dennoch richtig verwenden.
Verwaltung des Kontextfensters
Mehr Kontext führt nicht automatisch zu einer besseren Antwort. Modelle nutzen lange Kontexte nicht gleichmäßig. Forschungen haben gezeigt, dass Informationen in der Mitte eines langen Kontexts seltener zuverlässig abgerufen werden können als Informationen am Anfang oder Ende. Daher kann das Hinzufügen der 20 wichtigsten Abschnitte zum Prompt die Antwort verschlechtern. Das Ziel ist ein maximal nützlicher Kontext und nicht ein maximaler Kontext.
Prompt-Grenzen und Zuschreibung
Legen Sie im Prompt klar fest, wie die abgerufenen Abschnitte verwendet werden sollen. Das Modell muss sie als zu zitierende Belege betrachten und niemals als Anweisungen, denen Folge geleistet werden muss.
Zitate tragen auch zum Vertrauen und zur Fehlerbehebung bei. Wenn in einer Antwort steht, dass Enterprise-Kunden 30 Tage Zeit zum Kündigen haben, braucht man eine Möglichkeit, diese Aussage auf eine herangezogene Quelle zurückverfolgen zu können.
Abstention
Abstention markiert eine deutliche Trennung zwischen einer Demo-Version und einem zuverlässigen System. Wenn die Suche ergebnislos bleibt, versucht das Modell dennoch, zu helfen – es sei denn, ein Ablehnen ist als zulässiges Ergebnis vorgesehen. Ein Produktionsystem sollte in der Lage sein, mitzuteilen, dass die Beweise unzureichend sind. Das ist oft die richtige Entscheidung und kein Defekt.
Ohne Abstention kann jedes Suchfehler zu einer glaubwürdigen Halluzination werden. Das LLM trägt die Schuld für die Erstellung der falschen Antwort, obwohl der eigentliche Fehler bereits mehrere Ebenen früher aufgetreten sein könnte.
Bewertung vor jeder Korrektur
RAG weist eine unangenehme Eigenschaft auf: Die Qualität kann sinken, obwohl der Anwendungscode unverändert bleibt. Ein neues Embedding-Modell, eine andere Chunking-Methode, hinzugefügte oder entfernte Dokumente, angepasste Sucheinstellungen oder ein überarbeiteter Prompt können jeweils die Antworten verändern – selbst wenn der gestern bereitgestellte Code bytegenau derselbe ist. Daher sollte RAG in der Produktion auf mehreren Ebenen bewertet werden.
Qualität der Informationsabrufung. Die Präzision des Kontexts bezieht sich darauf, wie viel des abgerufenen Kontexts relevant war. Die Erinnerungskraft des Kontexts bezieht sich darauf, wie viel von den verfügbaren relevanten Informationen tatsächlich gefunden wurde. Gemeinsam unterscheiden sie zwischen „Wir haben es nie gefunden“ und „Wir haben es gefunden, aber es ging im Rauschen unter.“
Qualität der Erstellung. Die Treueprüfung (auch Fundiertheit genannt) stellt sicher, dass die Antwort aus den abgerufenen Belegen abgeleitet ist, und die Zitiergenauigkeitsprüfung überprüft, ob die genannten Quellen jede Behauptung stützen. Eine gut geschriebene Antwort kann dennoch unbegründet sein.
Systemgesundheit. Auch operative Metriken spielen eine Rolle: p95-Latenz, Kosten pro Abfrage sowie die Abbruchrate. Es handelt sich dabei nicht nur um Infrastrukturprobleme. Wenn die Latenz sich verdoppelt, weil ein Agent mehrere Abfragen ausführt, gehört das zur Qualität des Systems. Ein plötzlicher Anstieg der Abbruchrate kann darauf hindeuten, dass die Informationsbeschaffung nachgelassen hat. Ein Anstieg der Kosten pro Abfrage kann bedeuten, dass eine scheinbar unbedeutende Änderung zu einem teuren Ablauf geführt hat.
Die Trennung der Messwerte ist bei der Diagnose vorteilhaft. Eine gesunde Erinnerungskraft bei abnehmender Bodenhaftung deutet auf die Generierung hin. Eine abnehmende Präzision weist auf Aufnahme, Filtern, Abrufen oder Ranking hin. Wenn man nur die Gesamtqualität der Antworten verfolgt, erscheinen alle Rückgänge identisch und liefern keine Anhaltspunkte für Handlungen.
Von der Pipeline zum Feedbackloop
Die Kernpipeline bleibt einfach gehalten:
Ingestion → Retrieval → Generation → Evaluation
Viele Systeme benötigen nichts weiter. Eine gut indizierte Wissensdatenbank sowie klare Fragen erfordern selten, dass ein Agent den nächsten Schritt wählt. Es gibt jedoch auch schwierigere Fragen.
Nehmen wir einen Antrag, bei dem die Umsatzzahlen des zweiten Quartals mit denen aus der Vorstandsvorlage verglichen und anschließend der Unterschied erläutert werden soll. Die Antwort erfordert möglicherweise die Zahlen des Q2, die Vorstandsvorlage, die relevanten Abschnitte beider Quellen, einen Vergleich sowie gegebenenfalls eine Abfrage in einer anderen Datenquelle. Eine einzige Abfrage reicht möglicherweise nicht aus – genau da wird agierendes RAG nützlich. Anstelle eines einfachen Schritts von Abfrage bis Erstellung kann man einen Schleifenprozess verwenden:
Retrieve
↓
Evaluate
↓
Enough evidence?
↓ no
Retrieve again
↓
Generate
Ein solches System kann zu dem Schluss kommen, dass die bisherigen Beweise unzureichend sind, die Anfrage umformulieren, erneut suchen oder eine Unterfrage an eine SQL-Datenbank, ein Wissensgraph oder eine Live-API weiterleiten. Die Informationsbeschaffung wird dadurch iterativ und ist nicht mehr auf einen einzigen Versuch beschränkt.
Agentic RAG ist jedoch nicht automatisch besser. Jeder zusätzliche Schleifenzyklus führt zu Verzögerungen, höheren Tokenkosten sowie mehr Fehlerrisiken und kann unnötige Suchvorgänge auslösen, wenn der Agent keinen klaren Grund hat, fortzufahren. Seine Komplexität lohnt sich bei unklaren Fragen, mehrstufigen Abfragen oder wenn mehrere Quellen benötigt werden. Eine Frage zur Rückerstattungspolitik sollte vermutlich in einem einzigen Durchlauf durch einen gut konzipierten statischen Prozess beantwortet werden. Der Vergleich der Spielkarten könnte eine Iteration rechtfertigen.
Die wichtige Frage ist, ob das System einen messbaren Grund hat, erneut nachzuschauen – und nicht, ob es überhaupt einen Agenten benötigt. Das Endlos-Suchen ohne klare Beendigungsregel führt nur zu Verzögerungen und Kosten.
Ein mentales Modell für die Produktion
Beim Arbeiten mit großen Sprachmodellen ist der häufigste Fehlerschluss das Verlassen des Modells selbst. Eine schlechte Antwort ist lediglich das letzte sichtbare Symptom, während die Ursache oft viel weiter oben liegt. Veraltete Dokumente ähneln Halluzinationen, eine mangelhafte Aufteilung in Abschnitte ähnelt einem fehlgeschlagenen Abruf, eine schwache Informationsabrufung ähnelt einem Fehler bei der Erzeugung von Inhalten, und das Fehlen einer Bewertung verdeckt all diese Probleme, bis die Kunden sich beschweren.
Stellen Sie also nicht die Frage, welches Modell verwendet werden soll. Fragen Sie stattdessen, welche Schicht versagt.
INGESTION
↓
RETRIEVAL
↓
GENERATION
↓
EVALUATION
↖
└── feedback loop / Agentic RAG
Veraltete Daten bedeuten eine Korrektur der Eingabeverarbeitung. Ein fehlendes Dokument bedeutet eine Korrektur der Abruflogik. Ein gefundenes Dokument mit niedriger Bewertung bedeutet eine Anpassung der Rangliste. Der falsche Antwortkontext bedeutet, dass man die Generierung überprüfen muss. Wenn man nicht erkennen kann, welches Problem vorliegt, sollte man zunächst eine bessere Bewertungsmethode entwickeln. Und wenn eine einzige Durchlaufphase niemals ausreicht, sollte man einen agierenden Schleifenmechanismus in Betracht ziehen.
Beginnen Sie mit dem Pipeline-Verfahren und lassen Sie das Modell zum Schluss kommen.
Woher die Ideen stammen
Zur weiteren Lektüre definiert der ursprüngliche Artikel von Lewis und Kollegen (NeurIPS 2020) zum retrieval-augmented Generation das grundlegende Muster. Der Bericht von Anthropic aus dem Jahr 2024 über kontextbasiertes Retrieving weist große Rückgänge bei Fehlern beim Retrieving durch kontextuelle Embeddings, kontextuelles BM25 sowie Reranking auf – allerdings handelt es sich dabei um Messungen des Anbieters selbst. Cormack, Clarke und Büttcher (SIGIR 2009) führten die Methode Reciprocal Rank Fusion ein. Der Artikel „Lost in the Middle“ von Liu und Kollegen untersucht, wie Modelle lange Kontexte nutzen, der Artikel RAGAs beschreibt die automatisierte Bewertung von RAG-Systemen, und der Artikel Self-RAG von Asai und Kollegen befasst sich mit selbstreflektivem, agentenbasiertem Retrieving.
Verwandte Literatur
- Praktische Hinweise: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr — Detaillierte Anleitung zu den Praktischen Hinweisen: Die Grenzen der Vektorsuche in RAG – Kosinusähnlichkeit und mehr: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.
- Bedeutung als Koordinaten: Von Embeddings zu Vektordatenbanken und RAG — Einfache Erklärung zu Satz-Embeddings, Kosinusähnlichkeit, Vektordatenbanken sowie dem RAG-Loop, ergänzt durch vier kurze Sätze über Hunde, Katzen und Paris, die zeigen, wie die Bedeutungssuche funktioniert.