RAG evaluieren: Retrieval-Metriken, Faithfulness und wie du erkennst, welche Hälfte versagt hat

Die meisten RAG-Systeme gehen auf Basis einer Demo live. Jemand stellt fünf Fragen, die Antworten sehen richtig aus, das Team zieht weiter. Dann wächst der Korpus, das Chunking ändert sich, das Modell wird aktualisiert, und niemand kann sagen, ob das System besser oder schlechter geworden ist. Die ehrliche Antwort auf „Ist es gut?“ ist eine Zahl, die du neu berechnen kannst, und bei RAG braucht es dafür mehr als eine Zahl.

Der Grund ist strukturell. Ein RAG-System sind zwei Systeme hintereinander: ein Retriever, der entscheidet, was das Modell sieht, und ein Generator, der entscheidet, was er dazu sagt. Jedes versagt auf eigene Weise, braucht eigene Metriken und wird durch andere Arbeit repariert. Bewertest du nur die finale Antwort, sagt dir eine falsche Antwort, dass etwas kaputt ist, aber nicht wo.

Dieser Artikel zeigt, wie ich RAG-Evaluierung für ein Produktteam aufsetzen würde: die Metriken und was jede wirklich misst, ein Golden Set aus echten Anfragen, ein LLM-Judge, den du gegen Menschen geprüft hast, die Tools, die einen Blick wert sind, Evals in CI und ein kurzes Verfahren zur Diagnose, ob Retrieval oder Generierung versagt hat. Er baut auf meinen Beiträgen zu Evals für LLM-Produktfunktionen und zur RAG-Pipeline selbst auf.

Zwei Hälften, sieben Zahlen

Das RAGAS-Paper beschreibt RAG-Evaluierung entlang dreier Dimensionen: die Fähigkeit des Retrievers, relevante und fokussierte Passagen zu finden, die Fähigkeit des Generators, diese Passagen treu zu verwenden, und die Qualität der Ausgabe. In der Praxis teile ich die Zahlen nach der Frage, die sie beantworten. Retrieval-Metriken fragen: Ist das richtige Material beim Modell angekommen, und in guter Reihenfolge? Generierungs-Metriken fragen: Hat sich das Modell bei dem, was es gesehen hat, korrekt verhalten?

Die Tabelle zeigt die Metriken, die ich tatsächlich nutze. Die Namen unterscheiden sich je nach Tool, deshalb beschreibe ich, was jede misst, statt wie eine Bibliothek sie nennt.

Beachte, dass Context Precision zum Retrieval gehört, obwohl sie oft neben den Generierungs-Metriken aufgelistet wird. Sie wird über die abgerufenen Chunks berechnet und sagt dir etwas über den Ranker, nicht über das Schreiben des Modells. Nur wenn die Ebenen-Spalte stimmt, funktioniert die Diagnose weiter unten.

Retrieval-Metriken: recall@k, MRR und nDCG

Retrieval-Metriken stammen aus der Suchevaluierung und brauchen etwas, das Generierungs-Metriken nicht brauchen: eine Vorstellung davon, welche Chunks für jede Anfrage relevant sind.

• Recall@k fragt, ob das relevante Material in den Top k steht. Es ist die wichtigste Retrieval-Zahl, weil sie eine Obergrenze ist. Steht der Chunk mit der Antwort nicht unter den k Chunks, die du ans Modell gibst, kann das Modell seine Antwort nicht darauf stützen, egal was im Prompt steht. Wähle k passend zu dem, was du wirklich an den Generator schickst.
• MRR (Mean Reciprocal Rank) mittelt 1 geteilt durch den Rang des ersten relevanten Treffers: 1 für Platz eins, 0,5 für Platz zwei. Sie belohnt es, einen guten Chunk nach oben zu bringen. Ihre dokumentierte Einschränkung: Nur der erste relevante Treffer zählt, weitere werden ignoriert. Sie passt daher zu Fragen mit einer richtigen Passage und führt bei Fragen in die Irre, die mehrere brauchen.
• nDCG summiert abgestufte Relevanzwerte mit logarithmischer Abwertung für tiefere Positionen und teilt durch die ideale Reihenfolge, sodass das Ergebnis zwischen 0 und 1 liegt. Sie ist die richtige Metrik, wenn Relevanz nicht binär ist, etwa ein Chunk, der die Frage voll beantwortet, gegenüber einem, der das Thema nur erwähnt, und wenn die Reihenfolge zählt, weil Kontextfenster oder Reranker-Cut-off die Liste abschneiden.

Ich lese sie zusammen. Hoher recall@k bei schwachem MRR oder nDCG heißt: Der richtige Chunk wird gefunden, liegt aber vergraben, was ein Reranker meist behebt (Chunking, Hybrid-Suche und Reranking findest du im Pipeline-Beitrag). Niedriger recall@k heißt: Der richtige Chunk wird nie gefunden. Das ist ein Problem von Chunking, Embeddings, Query-Rewriting oder Index, und kein Reranker repariert eine Kandidatenliste, die die Antwort nicht enthält.

Diese Metriken brauchen Relevanz-Labels, und das ist der teure Teil. Die Ragas-Dokumentation beschreibt eine ID-basierte und eine Nicht-LLM-Variante von Context Recall, die abgerufene Chunk-IDs oder Texte mit Referenzkontexten vergleichen, ohne LLM-Aufruf. Die sind günstig, deterministisch und ideal für CI, sofern dein Golden Set speichert, welche Chunks relevant sind.

Generierungs-Metriken: Faithfulness und Antwortrelevanz

Generierungs-Metriken beurteilen die Antwort angesichts dessen, was dem Modell gezeigt wurde. Faithfulness ist die zentrale. In der Ragas-Definition ist sie die Zahl der Aussagen in der Antwort, die der abgerufene Kontext stützt, geteilt durch die Gesamtzahl der Aussagen: Die Antwort wird in Aussagen zerlegt, jede wird gegen den Kontext geprüft, das Verhältnis ist der Score von 0 bis 1. Sie braucht keine Referenzantwort, weshalb sie auf Produktionsverkehr so nützlich ist.

Antwortrelevanz fragt, ob die Antwort die Frage überhaupt adressiert. Eine Antwort kann dem Kontext perfekt treu sein und der Frage trotzdem ausweichen, etwa indem sie ein Dokument zusammenfasst, obwohl der Nutzer nach einer Zahl gefragt hat. TruLens nennt das Äquivalent Context Relevance, Groundedness und Answer Relevance, Ragas nennt es Response Relevancy, DeepEval Answer Relevancy. Dieselbe Idee, andere Namen.

Zwei Eigenschaften übersieht man leicht. Erstens misst Faithfulness die Übereinstimmung mit dem abgerufenen Kontext, nicht mit der Wahrheit. Hat das Retrieval ein veraltetes Richtliniendokument geliefert, ist eine perfekt faithful Antwort falsch. Zweitens kann man einen hohen Wert erreichen, indem man wenig sagt: Ein Modell, das ablehnt oder ausweicht, macht wenige Aussagen, und wenige Aussagen können alle gestützt sein. Lies Faithfulness immer neben Antwortrelevanz und einer Korrektheitsprüfung gegen die Golden-Antwort.

Das Golden Set aus echten Anfragen bauen

Alles oben hängt an einem Golden Set: Anfragen mit den Erwartungen, gegen die du bewertest. Synthetische Fragen, die aus deinen Dokumenten generiert werden, sind ein nützlicher Start, teilen aber das Vokabular der Dokumente, das echte Nutzer nicht haben. Echte Anfragen haben Tippfehler, Abkürzungen, vage Formulierungen, Produktcodes und Fragen, die der Korpus nicht beantworten kann. Daraus würde ich das Set bauen.

1. Echte Anfragen ziehen. Nimm sie aus Such-Logs, Support-Tickets oder Chat-Verläufen. Entferne vorher personenbezogene Daten und achte auf deine Rechtsgrundlage: siehe meine Hinweise zu DSGVO und LLM-APIs.
2. Schichten bilden, nicht nur samplen. Nimm die häufigen Fragen, den Long Tail, Fragen über mehrere Dokumente, Fragen mit exakten Kennungen und Fragen auf, die „Ich weiß es nicht“ ergeben sollen, weil der Korpus keine Antwort hat.
3. Festhalten, was eine richtige Antwort braucht. Notiere pro Anfrage die relevanten Chunks oder Dokumente (für recall@k, MRR und nDCG), eine kurze Referenzantwort und, wo es zählt, die Fakten, die die Antwort enthalten muss.
4. Von einer Fachperson labeln lassen und messen, ob zwei Personen übereinstimmen. Wenn zwei Menschen uneins sind, was relevant ist, kann dir keine Metrik das abnehmen.
5. Versionieren und einen Teil zurückhalten. Behandle das Set wie Code. Halte einen Teil zurück, gegen den du nie tunst, damit Verbesserungen nicht nur Überanpassung an die Beispiele sind, die du dir angesehen hast.
6. Aus der Produktion speisen. Jedes Thumbs-down, jede Eskalation und jede im Review gefundene falsche Antwort wird ein neuer Fall mit Label. So bleibt das Set repräsentativ, während sich das Produkt ändert.

Wie groß? Ich würde mit einigen Dutzend gut gelabelten Anfragen starten und von dort wachsen; ein kleines, sauberes Set, dem du vertraust, schlägt ein großes, das niemand geprüft hat. Am Anfang geht es nicht um statistische Aussagekraft, sondern darum, dass eine Regression am Tag ihres Auftretens sichtbar wird. Berichte mit wachsendem Set die Ergebnisse pro Schicht, denn ein Durchschnitt verbirgt den Einbruch in einem Anfragetyp.

Diagnose: Retrieval oder Generierung?

Wird eine falsche Antwort gemeldet, widerstehe dem Drang, den Prompt zu ändern. Geh die Kette von unten durch, mit den gespeicherten Retrieval-Ergebnissen zu dieser Anfrage, und halte bei der ersten Frage an, die du mit „Nein“ beantwortest.

Die Zweige führen zu unterschiedlicher Arbeit. Eine Inhaltslücke ist ein redaktionelles oder Ingestion-Problem: Das Dokument fehlt, ist veraltet oder wurde nie sauber geparst. Ein Retrieval-Fehler wird in Chunking, Embeddings, Hybrid-Suche, Query-Rewriting oder Reranking behoben. Eine unfaithful Antwort ist ein Generierungsproblem: Schärfe die Anweisung, nur aus dem Kontext zu antworten, reduziere irrelevanten Kontext, der zu Spekulation einlädt, oder wechsle das Modell. Eine Antwort am Ziel vorbei liegt meist am Prompt oder ist ein verkapptes Retrieval-Problem, bei dem der Kontext zum Thema passt, aber nicht zur Frage.

Auch die letzte Box zählt. Bestehen alle Metriken und die Antwort ist trotzdem falsch, verdächtige vor dem System das Golden-Label, die Referenzantwort oder den Judge selbst. Bei agentischen Setups, in denen das Modell entscheidet, was es abruft, und mehrfach abrufen kann, gilt dieselbe Logik pro Retrieval-Schritt; siehe RAG 2026: hybrid, agentisch und Long Context.

LLM-as-Judge: gegen Menschen kalibrieren

Faithfulness, Antwortrelevanz und die meisten Kontext-Metriken bewertet ein LLM. Ragas vermerkt, dass seine LLM-basierten Metriken einen oder mehrere LLM-Aufrufe für einen Score nutzen können. Damit ist der Judge Teil deines Messaufbaus, und ein Instrument braucht Kalibrierung.

Die Belege sind ermutigend, aber nicht bedingungslos. Das MT-Bench-Paper fand, dass ein starker Judge wie GPT-4 über 80 Prozent Übereinstimmung mit menschlichen Präferenzen erreichte, so viel wie Menschen untereinander. Dasselbe Paper nennt Positions-Bias, Längen-Bias und Selbstbevorzugungs-Bias und vermerkt eingeschränkte Reasoning-Fähigkeit. Diese Befunde betreffen paarweise Präferenzen bei Chat-Antworten; sie übertragen sich nicht automatisch auf deine Domäne, deine Rubrik oder dein Judge-Modell.

1. Eine Stichprobe von Hand labeln. Nimm einige Dutzend Fälle mit guten, schlechten und grenzwertigen Ausgaben und lass eine Person sie mit derselben Rubrik bewerten, die der Judge bekommt.
2. Übereinstimmung über den Zufall hinaus messen. Prozentuale Übereinstimmung schmeichelt dir, wenn ein Label dominiert. Cohens Kappa korrigiert um zufällige Übereinstimmung (Kappa gleich beobachtete minus erwartete Übereinstimmung, geteilt durch eins minus erwartete Übereinstimmung) und reicht von -1 bis 1. Auch hier gilt eine Einschränkung: Der Wert hängt von Prävalenz und Bias ab, einen universellen Schwellenwert gibt es nicht. Sieh dir die Konfusionsmatrix an, nicht nur die Zahl.
3. Die Eingaben des Judge festlegen. Nutze eine enge Rubrik, binäre oder kleine Skalen und lass die Begründung vor dem Score ausgeben. Pinne die exakte Version des Judge-Modells, denn ein stilles Update verschiebt deine Trendlinie.
4. Bekannte Biases gegensteuern. Randomisiere die Antwortreihenfolge bei paarweisen Vergleichen, nutze nach Möglichkeit nicht dasselbe Modell zum Generieren und zum Bewerten und prüfe, ob Scores mit der Antwortlänge korrelieren.
5. Bei Änderungen neu kalibrieren. Neues Judge-Modell, neue Rubrik, neue Domäne: Wiederhole den Vergleich. Behalte die gelabelte Stichprobe als dauerhaftes Kalibrierset.

Judge-Aufrufe kosten bei jedem Lauf Tokens, deshalb gelten die Kosten- und Latenz-Taktiken aus LLM-Kosten, Latenz und Prompt-Caching auch für deine Eval-Suite. Ein kleineres Judge-Modell ist akzeptabel, wenn und nur wenn die Kalibrierung es hergibt.

Tools: Ragas, DeepEval, TruLens und Phoenix

Du kannst das alles in einigen hundert Zeilen selbst schreiben, und für die deterministischen Retrieval-Metriken tue ich das oft. Für LLM-bewertete Metriken und fürs Tracing sparen die etablierten Tools echte Zeit. Das sagt ihre eigene Dokumentation, geprüft am 2. Oktober 2026:

Mein praktischer Rat: Wähle danach, wo Evals leben sollen. Willst du sie als Tests im Repository, passt DeepEval oder ein dünner Ragas-Wrapper. Willst du echte Produktions-Traces ansehen und Scores daran hängen, passen TruLens oder Phoenix. Was immer du wählst: Halte Golden Set und Labels in einem schlichten Format im eigenen Repository, damit ein Toolwechsel einen Nachmittag kostet statt ein Quartal. Und denk daran, dass gleichnamige Metriken je Tool unterschiedlich berechnet sein können, vergleiche Scores also nie zwischen Tools.

Evals in CI ausführen

Ein Eval, den niemand ausführt, ist Dokumentation. Das Ziel: Eine Änderung an Chunking, Embedding-Modell, Prompt oder Generator darf nicht gemergt werden, ohne Zahlen zu erzeugen. Ich nutze zwei Stufen, weil die Kostenprofile verschieden sind.

• Bei jedem Pull Request: nur Retrieval. Führe recall@k, MRR und nDCG gegen einen festen Index-Snapshot oder ein Fixture aus. Sie können deterministisch sein und brauchen keinen LLM-Aufruf, sind also schnell, kostenlos und stabil.
• Nach Zeitplan oder bei relevanten Änderungen: die LLM-bewertete Suite. Führe Faithfulness, Antwortrelevanz und Korrektheit aus, wenn sich Index, Prompt, Modell oder Judge ändern, und sonst nächtlich. Die DeepEval-Dokumentation beschreibt einen Test-Befehl, um Evals in CI/CD-Pipelines auszuführen.
• Auf Regression gaten, nicht auf eine magische Zahl. Vergleiche pro Schicht mit der zuletzt akzeptierten Baseline und lass bei einem Rückgang scheitern, der über das Rauschen hinausgeht, das du durch mehrere Läufe der Suite gemessen hast.
• Rauschen kontrollieren. Pinne Judge- und Generator-Versionen, setze die Temperatur niedrig, cache Judge-Aufrufe bei unveränderten Eingaben und speichere Scores und abgerufene Chunk-IDs jedes Laufs, damit ein Fehler ohne erneuten Lauf diagnostizierbar ist.
• Den Kreis schließen. Ein fehlschlagender Produktionsfall wird im selben Pull Request, der ihn behebt, eine Zeile im Golden Set.

Wie das in die breitere Praxis des Testens von LLM-Funktionen passt, einschließlich Online-Monitoring und menschlichem Review, steht in Evals für LLM-Produktfunktionen.

Was ich zuerst tun würde

1. Logge für jede Anfrage die Query, die abgerufenen Chunk-IDs mit Scores und die finale Antwort.
2. Sammle 30 bis 50 echte Anfragen über deine Schichten hinweg und labele relevante Chunks und eine kurze Referenzantwort.
3. Berechne heute recall@k, MRR und nDCG. Repariere das Retrieval, bevor du den Prompt anfasst.
4. Ergänze Faithfulness und Antwortrelevanz mit einem LLM-Judge und kalibriere ihn mit Kappa an einer von Hand gelabelten Stichprobe.
5. Hänge die günstigen Metriken an Pull Requests und die bewertete Suite an einen nächtlichen Job.
6. Füge jeden Produktionsfehler dem Golden Set hinzu, samt Diagnose aus der Entscheidungskette.

Nichts davon braucht eine Plattform. Es braucht ein gelabeltes Set, ein paar ehrliche Zahlen und die Gewohnheit, bei jeder schlechten Antwort zu fragen, welche Hälfte versagt hat.

Quellen

1. Es et al.: RAGAS, Automated Evaluation of Retrieval Augmented Generation (arXiv 2309.15217)
2. Zheng et al.: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685)
3. Ragas documentation: available metrics
4. Ragas documentation: faithfulness
5. Ragas documentation: context precision
6. Ragas documentation: context recall
7. DeepEval documentation: metrics introduction
8. TruLens
9. Arize Phoenix documentation
10. Wikipedia: Discounted cumulative gain
11. Wikipedia: Mean reciprocal rank
12. Wikipedia: Cohen's kappa