Diagnose von RAG-Fehlern: Eine Schritt-für-Schritt-Anleitung sowie ein Groundedness-Prüfer auf Behauptungs-Ebene
Ermitteln Sie, an welcher Stelle die RAG-Pipeline versagt hat, und entwickeln Sie anschließend einen Groundedness-Prüfer für LLMs, der die Behauptungen nacheinander überprüft und durch Kappa gegen menschliche Bewertungskräfte validiert wird.
Quellen: How to Diagnose RAG Failures with a Groundedness Judge
Wenn ein RAG-Bot falsch antwortet
Das Bereitstellen einer RAG-App ist noch nicht das Ende der Arbeit – schon gar nicht in der Produktion. Irgendwann beginnt der Bot, falsch zu antworten, und die erste Herausforderung besteht darin, die Ursache zu finden. Das System weist mindestens sieben Stellen auf, an denen Fehler unbemerkt auftreten können: die Aufteilung in Blöcke, die Erstellung von Embeddings, die Abfrage von Informationen, die Neubewertung der Ergebnisse, die Zusammenstellung des Kontexts, die Generierung der Antwort sowie der Prompt, der all diese Schritte verbindet. Eine schlechte Endantwort verrät fast nichts darüber, an welcher Stelle etwas schiefgelaufen ist. Einige Ingenieure haben wertvolle Zeit damit verbracht, einen Prompt zur Generierung zu optimieren, obwohl der Fehler in Wirklichkeit bei der Aufteilung in Blöcke lag.
Es gibt eine eher mechanische Methode, um einen Fehler zu lokalisieren. Danach stellt sich das zweite Problem: Die Messung der Grundierung in großem Maßstab, da das Lesen jeder Transkription ab der Konzeptprüfungsphase nicht mehr praktikabel ist. Ein LLM, das als Richter fungiert, kann diese Aufgabe übernehmen, doch auch Richter haben ihre eigenen Fehlermuster, die genauso leicht übersehen werden können wie die RAG-Fehler, die sie eigentlich aufdecken sollen. Beide Aspekte werden unten behandelt: Die Rückverfolgung von Fehlern auf ihre Ursache sowie die Entwicklung eines vertrauenswürdigen Richters für die Grundierung.
Finden Sie zuerst den fehlerhaften Link
Ein RAG-Pipeline ist eine Kette, und die erste Aufgabe besteht darin, herauszufinden, welcher Link versagt hat, bevor jemand einen Prompt bearbeitet. Die untenstehende Übersicht dient als Rahmenwerk zur Lokalisierung des Problems. Sie ist nicht ausführlich und kann an ein bestimmtes System sowie einen bestimmten Anwendungsfall angepasst werden.
Die Reihenfolge ist absichtlich gewählt: Zuerst wird das Abrufen von Informationen bereinigt, bevor mit der Erstellung begonnen wird. Prompt-Engineering kann ein Kontextfenster nicht reparieren, das niemals die richtigen Fakten enthielt. Teams arbeiten oft rückwärts, indem sie den Systemprompt fünfmal umschreiben, während der Reranker den wichtigsten Abschnitt herunterrangiert. Günstige Lösungen mit großem Nutzen, wie besseres Aufteilen in Teile oder hybride Suchverfahren, sollten Vorrang vor kostspieligen Methoden wie der Feinabstimmung eines Rerankers oder dem Neutraining haben.
Drei realistische Symptome zeigen, wie die Methode tatsächlich eingesetzt wird:
- Die Antworten klingen selbstsicher, obwohl die Dokumente das Thema überhaupt nicht berühren. Das ist kein korrektes Abrufen, da es nichts Relevantes zum Auswählen gibt. Es handelt sich um einen Fehler bei der Erstellung oder Ausweichverhalten: Das Modell betrachtet „Ich habe das nicht“ nicht als akzeptable Antwort.
- Der Bot liefert plausible, aber veraltete Informationen. Chunking ist fast nie die Ursache. Der Index ist veraltet, weil sich die Dokumente geändert haben und niemand sie erneut eingebettet hat.
- Fragen mit nur einem Fakt werden erfolgreich beantwortet, während alle Fragen, die zwei Fakten aus zwei Dokumenten erfordern, fehlschlagen. Dies ist ein Suchfehler, der speziell bei mehrstufigen Abfragen auftritt, da eine einzige dichte Suchvorgang nicht zwei Informationen liefern kann, die jeweils nicht der Abfrage entsprechen.
Der nächste Schritt besteht darin, den tatsächlich gefundenen Kontext für ein fehlschlagendes Beispiel heranzuziehen und ihn zu lesen, bevor etwas geändert wird. Wenn der Fakt nicht vorhanden ist, liegt das Problem in der Suche. Wenn er vorhanden ist und das Modell ihn dennoch falsch versteht, liegt das Problem in der Generierung. Diese eine Überprüfung kann Tage sparen.
Was Groundedness bedeutet
Das Lesen von Transkripten ist in einigen Fällen geeignet, bei Tausenden jedoch hoffnungslos. Hier kommt ein LLM-Bewerter ins Spiel, insbesondere einer für die Grundlage, auch als Treue bezeichnet. Seine Frage lautet, ob jede Behauptung in der Antwort auf etwas im abgerufenen Kontext zurückgeführt werden kann.
Ein subtiler Punkt, der viele Menschen sofort in Verwirrung bringt: Grundlage und Richtigkeit sind getrennt. Eine richtige Antwort kann unbegründet sein, zum Beispiel wenn das Modell die Information aus dem Training und nicht aus den Dokumenten kennt. Eine begründete Antwort kann falsch sein, wenn der abgerufte Abschnitt selbst veraltet oder fehlerhaft ist. Bei der Bewertung von RAG ist die Grundlage der maßgebliche Indikator, da sie zeigt, ob die Informationsbeschaffung ihre Aufgabe erfüllt hat – unabhängig von der Qualität der zugrunde liegenden Dokumente.
Bewerter auf Behauptungsebene
Ein einziger Prompt, der um eine Bewertung der Grundlage der Antwort von 1 bis 5 bittet, klingt vernünftig, ist aber in der Regel nahezu nutzlos. Er liefert eine Zahl ohne Erklärung, und genau bei der Bewertung der gesamten Antwort zeigen KI-Modelle Inkonstanz. Es funktioniert weitaus besser, die Antwort in einzelne Aussagen zu zerlegen und jede für sich im Kontext zu überprüfen.
Der Ausgangsprompt weist dem Modell die Rolle eines Bewerters der Grundlage der Antwort zu, gibt eine Frage, den abgerufenen Kontext sowie die erzeugte Antwort vor und macht von vornherein klar, dass die Aufgabe nicht darin besteht, allgemein zu entscheiden, ob die Antwort wahr ist. Anschließend wird gebeten, Aussagen zu extrahieren und diese nacheinander im Kontext zu überprüfen, wobei für jede Aussage ein Urteil sowie ein entsprechender Kontextabschnitt angegeben werden sollen.
SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.
Do the following:
1. Decompose the ANSWER into a list of atomic claims (each claim = one
discrete factual statement, not a compound sentence).
2. For each claim, decide:
- SUPPORTED: directly stated or reasonably entailed by CONTEXT
- CONTRADICTED: conflicts with CONTEXT
- UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
(or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).
Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.
Return valid JSON only:
{
"claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
"groundedness_score": 0.0,
"num_claims": 0
}
QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}
Manche Gestaltungsentscheidungen müssen ausdrücklich gemacht werden, weil sie auf den ersten Blick nicht offensichtlich sind:
- Bewertung auf Behauptungsebene. Eine Gesamtbewertung ist schwer zu debuggen. Entscheidungen pro Behauptung zeigen genau an, welche Aussage fehlschlug, was wichtig ist, wenn jemand die zugrunde liegende Ursache beheben muss.
- Pflichtiger Beweisumfang. Die Verpflichtung für den Urteilsfassenden, stützende Texte anzuführen, zwingt ihn dazu, seine Entscheidungen auf Beweisen und nicht auf Plausibilität zu stützen, und ermöglicht es einem menschlichen Prüfer, ein Urteil schnell zu überprüfen, ohne den gesamten Kontext erneut lesen zu müssen.
- UNBESTÄTIGT gegenüber WIDERSPRUCHLICH. Widerspruch zu den Beweisen und lediglich fehlender Support sind zwei unterschiedliche Fehler mit verschiedenen Lösungsansätzen. Beide unter einem einzigen „schlechten“ Label zusammenzufassen, führt dazu, dass diagnostische Details verloren gehen.
Den Bewerter an Menschen überprüfen
Das ist der Schritt, der immer übersprungen wird, und er entscheidet darüber, ob der Rest überhaupt Wert hat: Ein Bewerter muss anhand von Menschen überprüft werden, bevor man ihm vertrauen kann.
Der Prozess ist einfach. Nehmen Sie 100 bis 200 Beispiele, lassen Sie eine Person die Grundlage der Antworten unabhängig bewerten und berechnen Sie die Übereinstimmung mit Cohens Kappa. Die Rohgenauigkeit täuscht, wenn die meisten Antworten fundiert sind, denn ein Bewerter, der immer „fundiert“ sagt, erzielt gute Ergebnisse, ist aber wertlos. Überprüfen Sie außerdem die üblichen Vorurteile der Bewerter:
- Positionsvorurteil: Ändert sich das Urteil, wenn die Kontexttexte umgeordnet werden?
- Verbositätsverzerrung: Neigt der Bewertungsrichter zu längeren Antworten, unabhängig davon, ob diese tatsächlich besser begründet sind?
- Selbstpräferenzverzerrung: Wenn der Bewertungsrichter zur gleichen Modellfamilie wie der Generator gehört, bewertet er möglicherweise die Ausgaben dieser Familie günstiger.
- Nachsichtsverschiebung: Schwindet die Übereinstimmung im Laufe der Wochen leise, je nachdem, ob sich das Bewertungsmodell oder die Prompt-Version ändert?
Ein niedriger Kappa-Wert in einer Kategorie ist ein Zeichen dafür, dass die Bewertungskriterien für diese Kategorie angepasst werden müssen. Das bedeutet jedoch nicht, dass das RAG-System dort defekt ist. Die Leute verwechseln diese beiden Aspekte ständig, und im nächsten Abschnitt wird diese Unterscheidung erläutert.
Ein Dashboard wie ein Operator lesen
Stellen Sie sich ein Dashboard vor, das nach Anfrageart unterteilt ist. Die richtige Haltung ist die eines Operators, nicht die eines Zuschauers eines Scoreboards.
Der Gesamtdurchschnitt weist einen leichten Rückgang auf, was irreführend sein kann. Zeile für Zeile sieht die Auswertung wie folgt aus.
- Einfache faktische Abfrage bleibt sowohl bei der Grundlage als auch bei der Übereinstimmung konstant hoch. Sowohl das System als auch der Beurteiler finden sie einfach. Allein ist sie langweilig, doch ein Rückgang würde darauf hindeuten, dass etwas Grundlegendes fehlt: die Indizierung, die Abrufung der Basisdaten oder die Anfrage an den Beurteiler – und nicht das Schlussfolgern oder die Mehrdeutigkeit.
- Mehrschrittige Verarbeitung und Vergleich sind stark zurückgegangen. Bei κ=0,71 ist die Übereinstimmung lediglich mäßig, weshalb Störungen durch lange Antworten, die sich der Aufschlüsselung widersetzen, einen Teil davon erklären könnten. Bevor man von einer Regression spricht, sollte man fünf fehlerhafte Transkripte heranziehen und prüfen, ob beide Abschnitte, die für die Antwort benötigt werden, im Kontext vorhanden sind. Wenn nur ein Abschnitt vorliegt, handelt es sich um ein Problem mit der Recherche- und Erinnerungsfähigkeit, da die einmalige dichte Recherche oft zwei Fakten übersehen kann, die nicht jeweils der Anfrage ähneln; die Lösung liegt in der Aufschlüsselung der Anfrage oder in der Mehr-Anfrage-Recherche und nicht in Anpassungen der Anfrageformulierung. Wenn beide Abschnitte vorliegen, aber der Vergleich dennoch fehlschlägt, liegt das Problem in der Synthese, wobei der „Verloren-im-Mittelfeld“-Effekt der Hauptverdächtige ist: Das Modell stützt sich auf den ersten Abschnitt und verleiht dem zweiten zu geringes Gewicht.
- Zahlische und finanzielle Angaben zeigen κ=0,52. Das ist eine schwache Übereinstimmung und das auffälligste Signal in der Tabelle, denn es bedeutet, dass dem Richter hier noch nicht vertraut werden kann. Eine numerische Äquivalenz ist für einen LLM-Richter wirklich schwierig: „20 %“, „etwa ein Fünftel“ und „20 Dollar Rabatt auf ein 100-Dollar-Produkt“ sind dieselbe Aussage in unterschiedlicher Formulierung. Der vernünftige Instinkt ist es, das RAG-System unberührt zu lassen, bis die Bewertungskriterien festgelegt sind, da die Verfolgung unzuverlässiger Zahlen Zeit im Entwicklungsprozess verschwendet.
- Politische und prozedurale Aspekte sind genauso gut wie die erste Zeile – aus einem anderen Grund: Die Antworten stammen in der Regel aus einem gut strukturierten Dokument und erfordern keine Synthese aus mehreren Dokumenten. Sinkt dieser Wert, ist das logische Denken nicht die erste Ursache. Wahrscheinlicher ist, dass die nummerierte Liste an den Grenzen der Datenblöcke unterbrochen wird, wodurch das Modell die Schritte 1 bis 3 behält und 4 sowie 5 erfindet.
- Aus dem Aufgabenbereich fallend verdient die erste Korrektur, obwohl n=20 es zum kleinsten Segment macht. Bei κ=0,90 ist der Bewertungsalgorithmus hier sehr zuverlässig, denn das Erkennen einer erfundenen Antwort ohne entsprechenden Kontext ist weitaus einfacher als die Beurteilung subtiler numerischer oder mehrstufiger Behauptungen. Diese Zuverlässigkeit macht den Rückgang glaubwürdig – und es handelt sich dabei um den gefährlichsten Fehler in der Tabelle. Das System wechselte von der korrekten Angabe von „Ich weiß es nicht“ zu selbstbewusstem Erfinden von Antworten, was schlimmer ist als eine falsche Zahl, da es im Tonfall nicht von einer richtigen Antwort zu unterscheiden ist. Zwei mögliche Ursachen: Die Informationsabrufung liefert nahe liegende Passagen, die das Modell als Erlaubnis zum Antworten interpretiert, oder eine kürzliche Änderung im Prompt oder im Modell hat die Anweisung zur Enthaltung stillschweigend entfernt. Beginnen Sie mit den Similaritätswerten aus der Informationsabrufung für dieses Segment. Wenn die Antworten nahe am „Noise Floor“ liegen und dennoch eine Antwort des Modells erfolgt, fehlt ein Relevanzschwellenwert-Filter vor der Generierung.
Die Methode in fünf Schritten
Die gesamte Vorgehensweise lässt sich auf Folgendes reduzieren:
- Vertrauen Sie nicht auf den Gesamtwert.
- Überprüfen Sie die Zuverlässigkeit des Bewerters, bevor Sie sich auf die Bewertungsscore verlassen.
- Segmentieren Sie die Daten nach Kategorien.
- Erstellen Sie auf der Grundlage konkreter Belege eine Hypothese darüber, in welcher Phase ein Fehler aufgetreten ist.
- Ordnen Sie die Probleme nach Schweregrad multipliziert mit Zuverlässigkeit, und nicht danach, welche Schwellenwertmarke am meisten angepasst wurde.
Praktische Hinweise für neue Bewertende
- Jede bewertete Antwort kostet einen zusätzlichen Aufruf des LLM. Bei hohem Volumen sollten Sie statt aller Antworten nur Stichproben bewerten und diese nach Abfruckategorie strukturieren, damit seltene, aber kritische Fälle wie Abfragen außerhalb des Aufgabengebiets nicht von zahlreichen einfachen Abfragen überwältigt werden.
- Überprüfen Sie den Kappa-Wert erneut, sobald sich das Bewertungsmodell oder die Bewertungsanweisungen ändern. Jede dieser Änderungen führt zur Erstellung eines neuen Bewerters.
Sämtliche Beispiele und Darstellungen hier dienen nur der Veranschaulichung und stammen nicht aus einem echten Produktionssystem. Das Framework sowie die Struktur der Anfragen bilden einen vernünftigen Ausgangspunkt.
Wo es endet
Der obige Text behandelt ein Verfahren zur Lokalisierung von Fehlern, die Lücke zwischen Grundlage und Korrektheit, einen Richter auf Ebene der Aussagen sowie den oft übersprungenen Kalibrierungsschritt. Es bleibt jedoch eine Einschränkung: Alles setzt voraus, dass es einen einheitlichen, unverfälschten Block an abgerufenem Kontext gibt. Diese Annahme gilt nicht mehr, sobald ein System Tools aufruft, die Abfragen miteinander verknüpft oder auf eigenen Zwischenergebnissen weiterarbeitet, wie es agierende Systeme tun. Die Definition von Grundlage ohne einen einzelnen Kontextblock zur Überprüfung sowie die entsprechende Anpassung des Richters stellen ein separates Problem dar.
Weitere Literatur
- Praktische Hinweise: Wo man 2026 RAG von Grund auf lernen kann – Die Kurse — Detaillierte Anleitung zu den Praktischen Hinweisen: Wo man 2026 RAG von Grund auf lernen kann – Die Kurse: Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster einsetzen.
- RAG mit LangChain von Grund auf: Lader, Chunking, Embeddings, Bewertung — Schritt für Schritt ein Dokumenten-FAQ-System aufbauen: Dateien laden, in Blöcke aufteilen, Embeddings erstellen, Indexierungs- und Abrufphase sowie wie man die Qualität der Abrufe und Antworten bewertet.