RAG fehlgeschlagen – aber welche Ebene ist tatsächlich fehlgeschlagen? Eine diagnostische Methode

Ein RAG-System liefert eine schwache, falsche, unvollständige oder unbelegte Antwort. Die übliche Diagnose lautet „Retrieval fehlgeschlagen“ oder „das Modell hat halluziniert“. Beide Bezeichnungen sind zu unspezifisch, um nützlich zu sein. Eine Produktions-RAG-Pipeline kann vor dem Retrieval, während des Retrievals, beim Ranking, bei der Kontextzusammenstellung, während der Generierung oder nach der Generierung fehlschlagen, wenn Evidenz und Validität geprüft werden.

Warum „RAG ist fehlgeschlagen“ keine Diagnose ist

Retrieval-augmentierte Generierung kombiniert mehrere Mechanismen: Eine Benutzeranfrage wird interpretiert, eine oder mehrere Suchen werden konstruiert, Kandidatenmaterial wird abgerufen, Ergebnisse werden gefiltert oder neu gerankt, ausgewählte Evidenz wird in einen Modellkontext eingefügt und ein Modell generiert eine Antwort. Produktionssysteme können Berechtigungen, Metadatenfilter, Aktualitätsregeln, Zitate, Query-Rewriting, hybride Suche, Tool-Aufrufe, Speicher und externen Zustand hinzufügen.

Eine falsche endgültige Antwort sagt daher nicht, welche Komponente fehlgeschlagen ist. Das Modell kann die falsche Evidenz erhalten haben. Es kann die richtige Evidenz mit zu viel Rauschen vermischt erhalten haben. Die Evidenz kann korrekt, aber veraltet sein. Die Quelle kann die Antwort nie enthalten haben. Oder das Modell hat einen völlig ausreichenden Kontext ignoriert.

OpenAIs RAG-Leitfaden unterscheidet bereits grundlegend zwischen Retrieval-Fehler und Modellfehler: Ein System kann den falschen Kontext liefern oder den richtigen Kontext liefern und trotzdem die falsche Antwort generieren. AWS trennt ebenso die reine Retrieval-Bewertung von der Retrieve-and-Generate-Bewertung. Für die Produktionsdiagnose sollte diese Unterscheidung weitergeführt werden.

Der RAG Failure Stack

Schicht 1 — Quellenabdeckung: Kann das System dies überhaupt beantworten?

Bevor Sie Embeddings, Reranker oder Prompts optimieren, verifizieren Sie, dass die Antwort im Wissensraum existiert, den das System nutzen darf. Das klingt offensichtlich, aber viele RAG-Fehler sind tatsächlich Korpus-Fehler. Die angeforderte Tatsache kann fehlen, in einem nicht indexierten Anhang verborgen sein, nur in einem neueren Dokument verfügbar sein, in einem System außerhalb des RAG-Korpus gespeichert sein oder durch Berechtigungen blockiert werden.

Eine Retrieval-Metrik kann Informationen nicht wiederherstellen, die nie indexiert wurden. Ein größeres Top-k kann kein Dokument abrufen, das die Pipeline nicht enthält. Wenn der Quellenabdeckungstest fehlschlägt, ist die richtige Lösung Ingestion, Quellenauswahl, Berechtigungen oder ein explizites Verhalten „nicht beantwortbar aus verfügbarer Evidenz“.

Schicht 2 — Query-Konstruktion: Hat das System dem Korpus die richtige Frage gestellt?

Die Benutzeranfrage ist nicht immer die Retrieval-Anfrage. Produktionssysteme schreiben Fragen um, lösen Pronomen auf, extrahieren Entitäten, übersetzen Sprachen, fügen Metadatenbeschränkungen hinzu, teilen komplexe Fragen auf oder generieren mehrere Suchen. Jede Transformation kann das Retrieval verbessern, aber jede Transformation kann auch Informationen zerstören.

Eine Anfrage wie „Gilt die Richtlinie nach dem September-Update noch für Auftragnehmer in Deutschland?“ enthält mindestens eine Entität, eine Population, eine Gerichtsbarkeit und eine Zeitgrenze. Eine umgeschriebene Anfrage, die zu „Auftragnehmer-Richtlinie“ wird, kann semantisch verwandten Text abrufen, während die Variablen verloren gehen, die entscheiden, ob die Antwort gültig ist.

Ebene 3 — Kandidatenabruf: Ist der relevante Beleg in die Menge gelangt?

Der Kandidatenabruf ist in erster Linie ein Recall-Problem. Die diagnostische Frage lautet noch nicht, ob das beste Ergebnis an erster Stelle steht; sie lautet, ob relevanter Beleg irgendwo im Kandidatenpool aufgetaucht ist. Wenn die bekannte korrekte Quelle nicht erscheint, untersuchen Sie Indexierung, Chunking, Embeddings, lexikalisches Matching, Metadaten, hybride Suche, Sprachbehandlung, Synonyme und Query-Erweiterung.

Hier ist die reine Retrieval-Evaluierung wertvoll. AWS stellt Kontextrelevanz und Kontextabdeckung für die reine Retrieve-only-RAG-Evaluierung bereit. Die wichtige Produktionsgewohnheit ist, das Retrieval vor der Generierung zu bewerten, damit eine ausgefeilte endgültige Antwort keine schwache Kandidatenmenge verbergen kann.

Ebene 4 — Ranking und Filterung: Wurde der richtige Beleg verworfen oder begraben?

Ein System kann einen guten Recall haben und trotzdem scheitern, weil der relevante Beleg unter noisy aber semantisch ähnlichem Material rangiert. Reranker, Aktualitäts-Boosts, Autoritätsgewichtungen, Sprachpräferenzen, Mandantenfilters, Zugriffskontrollen, Produktstatusfilter und Deduplizierung verändern alle, was in den endgültigen Kontext überlebt.

Das Debugging sollte daher die vollständige Kandidatenliste bewahren, nicht nur die endgültigen Top-k. Wenn der Gold-Beleg auf Rang 18 abgerufen und von einem Reranker entfernt wurde, ist die Lösung nicht dieselbe wie bei einem Retrieval-Fehler.

Ebene 5 — Kontextzusammenstellung: Wurde nützlicher Beleg zu nutzbarem Kontext?

Retrieval-Erfolg garantiert keinen Kontext-Erfolg. Relevante Chunks können abgeschnitten, von ihren Qualifikatoren getrennt, dupliziert werden, bis sie den Prompt dominieren, mit widersprüchlichen Versionen vermischt oder von genügend irrelevantem Text umgeben sein, sodass die entscheidende Passage an Salienz verliert.

Chunk-Grenzen sind besonders wichtig. Ein Satz kann die Regel enthalten, während der folgende Satz die Ausnahme enthält. Wenn sie getrennt indexiert werden und nur der erste abgerufen wird, kann der Retriever relevant erscheinen, während der zusammengestellte Kontext irreführend wird.

Ebene 6 — Generierung: Kann das Modell korrekten Beleg korrekt nutzen?

Sobald das System nachweislich ausreichenden Beleg geliefert hat, wird die Generierung unabhängig testbar. Das Modell kann überverallgemeinern, inkompatible Passagen kombinieren, eine negative Aussage ignorieren, das angeforderte Antwortformat nicht einhalten, eine Brücke zwischen Fakten erfinden oder aus parametrischem Gedächtnis statt aus dem abgerufenen Beleg antworten.

Deshalb ist die End-to-End-Korrektheit allein für die Diagnose unzureichend. OpenAI empfiehlt Evaluierung als strukturierte Methode, um das Verhalten von Anwendungen zu verstehen, während Anthropics Leitfaden zur Agenten-Evaluierung mehrere Versuche, Bewerter, Traces und realistische Fehlerfälle betont. Für RAG sollte der Generator sowohl mit normalem Retrieval als auch mit kontrolliertem Gold-Kontext getestet werden.

Ebene 7 — Belegzuordnung: Wird die Antwort tatsächlich gestützt?

Eine plausible Antwort mit Zitaten kann dennoch schwach fundiert sein. Das zitierte Dokument kann für das Thema relevant sein, aber die spezifische Behauptung nicht stützen. Ein Satz kann gestützt sein, während ein anderer abgeleitet wird. Ein Zitat kann auf eine Quelle verweisen, die der Antwort widerspricht, sobald ihre Bedingungen gelesen werden.

Die Zitatbewertung gehört daher nach die Generierung. AWS unterscheidet zwischen Zitatpräzision und Zitatabdeckung: ob zitierte Passagen korrekt zitiert werden und ob die Antwort ausreichend durch Zitate gestützt wird. In der Produktion ist die Unterstützung auf Behauptungsebene nützlicher, als das Vorhandensein irgendeines Zitats als Belegqualität zu behandeln.

Ebene 8 — Gültigkeit und Aktualität: War der Beleg für diese Version der Realität korrekt?

RAG kann eine vollkommen authentische, hochrelevante, getreu zitierte Quelle abrufen und dennoch eine falsche Antwort produzieren, wenn die Quelle für die aktuelle Frage nicht mehr gültig ist. Richtlinien ändern sich. APIs werden veraltet. Preise bewegen sich. Softwareverhalten ändert sich zwischen Versionen. Produktbestände ändern sich. Berechtigungen ändern sich. Spiel-Patches ändern Mechaniken.

Dies ist eine separate Fehlerklasse von Halluzination. Der Beleg ist real; seine Anwendbarkeit ist falsch. Ein robustes System benötigt daher Zeitstempel, Versions- oder Gerichtsbarkeitsmetadaten, wo relevant, Quellenautorität, Ablöseregeln und einen expliziten Mechanismus, um zu entscheiden, wann älterer Beleg eingeschränkt oder verworfen werden muss.

Die schnellste Isolationsmethode: der Oracle-Kontext-Test

Die nützlichste erste Aufteilung ist einfach: Stellen Sie dem Generator manuell eine kleine Menge von Belegen zur Verfügung, von denen Sie wissen, dass sie ausreichen, um die Frage zu beantworten. Lassen Sie die Aufgabe und die erwartete Antwort unverändert.

Eine diagnostische Abfolge für den Produktivbetrieb

Ändern Sie nicht drei Ebenen gleichzeitig

Ein häufiger Debugging-Fehler besteht darin, Embeddings, Chunk-Größen, Top-k, Prompts und das Modell in einer Iteration zu ändern. Wenn sich die Bewertung verbessert, wissen Sie nicht, warum. Wenn sie sich verschlechtert, wissen Sie nicht, welche Änderung die Regression verursacht hat.

Behandeln Sie RAG-Debugging wie eine experimentelle Diagnose: Halten Sie so viel von der Pipeline wie möglich konstant und ersetzen Sie eine unsichere Komponente durch eine kontrollierte Eingabe. Gold-Dokumente isolieren das Retrieval. Gold-Chunks isolieren die Chunk-Auswahl. Ein fester Kontext isoliert die Generierung. Ein festes Modell isoliert Retrieval-Änderungen. Ein fester Korpus isoliert Änderungen an Ingestion und Indexierung.

Eine Fehlermatrix für häufige RAG-Symptome

Messen Sie jede Ebene mit der Metrik, die sie tatsächlich beeinflussen kann

Eine korrekte Antwort kann dennoch einen RAG-Defekt verbergen

Das umgekehrte Problem ist ebenfalls wichtig. Ein RAG-System kann die korrekte Antwort liefern, während das Retrieval defekt ist. Das Modell kennt die Antwort möglicherweise bereits aus dem Training, leitet sie aus schwachen Belegen ab oder rät richtig. Wenn die Evaluierung nur die endgültige Antwort betrachtet, kann das System gesund erscheinen, bis die Frage Informationen erreicht, die nur im privaten Korpus existieren.

Dies ist dasselbe Zuverlässigkeitsproblem, das allgemeiner in Agentensystemen auftritt: Korrektheit des Ergebnisses reicht nicht aus, um zu beweisen, dass der Ausführungspfad zuverlässig war. Für RAG sollten Traces mindestens die Retrieval-Abfrage, den Kandidatensatz, das Ranking, den endgültigen Kontext, die Antwort, Zitate, Modellversion, Korpus-/Indexversion und relevante Filter bewahren.

Verwenden Sie konkurrierende Hypothesen, nicht eine Lieblingserklärung

Wenn eine schlechte Antwort sofort zu einem „Embedding-Problem“ wird, ist die Untersuchung bereits voreingenommen. Eine stärkere Debugging-Methode schreibt konkurrierende Hypothesen auf, bevor das System geändert wird: fehlende Quelle, schlechtes Query-Rewriting, geringer Retrieval-Recall, schlechtes Reranking, Kontextkürzung, widersprüchliche Versionen, Generierungsfehler, Zitationsfehler oder veraltete Evidenz.

Wählen Sie dann einen Test, der diese Hypothesen trennen würde. Dies ist effizienter als das Sammeln weiterer Beispiele, die die erste Erklärung stützen. Dasselbe Prinzip gilt allgemein für KI-gestütztes technisches Denken: Eine nützliche Diagnose ist eine, die diskriminierende Tests übersteht, nicht eine, die lediglich plausibel klingt.

Was würde diese Antwort ändern?

Die genauen Diagnoseschichten ändern sich mit der Architektur. Eine einfache Single-Document-RAG-Anwendung hat möglicherweise kein Query-Rewriting, keinen Reranker und keine Zitationsschicht. Ein agentisches Retrieval-System kann Planung, mehrere Suchen, Tool-Auswahl, Gedächtnis, Berechtigungen und iterative Evidenzsammlung hinzufügen. Eine strukturierte Datenbankabfrage verwendet möglicherweise überhaupt keine Chunks oder Embeddings.

Die Kernmethode bleibt bestehen: Identifizieren Sie die Komponenten, die das Ergebnis unabhängig verändern können, konstruieren Sie kontrollierte Tests, die unsichere Komponenten durch bekannt gute Eingaben ersetzen, und messen Sie jede Komponente mit Evidenz, die für diese Schicht geeignet ist.

Einschränkungen

Reale Fehler sind oft gekoppelt. Eine schwache Query kann den Recall verringern, was das Reranking verändert, was den Kontext verändert, was die Generierungsvarianz erhöht. Der Oracle-Kontext-Test ist eine diagnostische Abkürzung, kein Beweis dafür, dass eine Komponente allein verantwortlich ist. Evaluierungsdatensätze können auch nicht repräsentativ sein, und modellbasierte Bewerter können eigene Fehler einführen.

Der vorgeschlagene Stack wird daher am besten als Untersuchungsstruktur verwendet: die Pipeline protokollieren, Variablen isolieren, Fehler reproduzieren, konkurrierende Erklärungen testen und nach schichtweisen Korrekturen eine End-to-End-Evaluierung beibehalten.

Fazit

„RAG ist fehlgeschlagen“ sollte der Beginn der Untersuchung sein, nicht das Fazit. Eine nützliche Diagnose identifiziert, ob dem System die Evidenz fehlte, es falsch suchte, sie nicht abrufen konnte, sie schlecht einordnete, unbrauchbaren Kontext zusammenstellte, falsch generierte, Aussagen schlecht zuordnete oder Evidenz außerhalb ihrer Gültigkeitsgrenze anwendete.

Die praktische Regel ist einfach: Ersetzen Sie Unsicherheit Schicht für Schicht durch kontrollierte Evidenz. Beginnen Sie mit dem Oracle-Kontext-Test. Trennen Sie die reine Retrieval-Evaluierung von der Generierungs-Evaluierung. Bewahren Sie den vollständigen Trace auf. Beheben Sie dann die Komponente, die tatsächlich fehlgeschlagen ist, anstatt den gesamten RAG-Stack nach Intuition abzustimmen.

FAQ

Glossar

Primärquellen und weiterführende Literatur