Kapitel 9 — Die RAG-Evaluations-Triade

Neunter Beitrag der kapitelweisen Tour durch LLM Primer III: Enhancing Enterprise AI with RAG. Darin: Drei verschiedene Versagen kollabieren in dasselbe Symptom — und das Feld erfindet eine dreiköpfige Metrik, die dem Team endlich sagt, welches Symptom welches ist.

Warum dieses Kapitel existiert

Ein RAG-System kann an drei verschiedenen Stellen versagen, und von außen sehen die Versagen identisch aus. Der Retriever holt den falschen Kontext. Das Modell ignoriert den richtigen Kontext. Das Modell ehrt den Kontext, beantwortet aber eine andere Frage als die gestellte. Jedes Produktionsteam hat irgendwann versucht, eines dieser Versagen zu beheben, während es ein anderes maß. Dieses Kapitel handelt von dem kleinen, sturen Vokabular, das diesen Fehler verhindert.

Es ist auch ein Kapitel über eine Verschiebung. Klassische Information Retrieval wurde gegen gelabelte Ground Truth evaluiert — Queries mit bekannten richtigen Dokumenten, Präzision und Recall gegen die Labels berechnet. RAG operiert in einer Welt, in der solche Labels nicht existieren. Fragen sind offen, Antworten generativ, der relevante Kontext ist, was das Modell in diesem Moment braucht. Die Triade wurde für diese Welt entworfen. Sie misst Konsistenz zwischen Stufen, nicht Übereinstimmung mit einer Referenz.

9.1 Warum drei Signale, nicht eines

Der Instinkt eines neuen Teams ist, die finale Antwort zu benoten. Der Nutzer tippte eine Frage, das System produzierte eine Antwort, entweder ist die Antwort korrekt oder nicht. Der Instinkt versagt, weil die finale Antwort ein Komposit jeder Stufe ist, und wenn sie versagt, sagt dir das Komposit nichts darüber, welche Stufe zu reparieren ist. Wurde das richtige Dokument verfehlt? Wurde es abgerufen und ignoriert? Wurde es benutzt, aber für eine andere Frage beantwortet? Drei verschiedene Bugs, drei verschiedene Korrekturen, ein ununterscheidbares Symptom.

Die Triade trennt die Pipeline in die drei Orte, an denen Information entweder überlebt oder verlorengeht. Retrieval, Grounding, Antworten. Jeder bekommt seine eigene Metrik: Context Relevance, Groundedness, Answer Relevance. Was die Struktur nützlich macht, ist nicht, dass die drei erschöpfend wären — sind sie nicht — sondern dass sie unabhängig sind. Ein System kann auf einer gut und auf einer anderen schlecht abschneiden, und wenn es das tut, weiß das Team, wo nachzuschauen ist. Wird ein neues Embedding-Modell ausgespielt, sollte sich Context Relevance bewegen. Wird ein neuer Prompt ausgespielt, sollte sich Groundedness bewegen. Bewegt sich die Metrik, die sich bewegen sollte, weiß das Team, dass die Änderung gewirkt hat. Ein einzelner End-to-End-Score lässt all das in etwas zusammenfallen, das man nicht debuggen kann.

9.2 Context Relevance — hast du den richtigen Kontext abgerufen?

Context Relevance fragt, ob die abgerufenen Chunks satzweise zur Frage gehören, bewertet von einem LLM-Judge. Sie fängt Retrieval-Präzision ein — den Anteil des Kontextfensters, der auf relevantes Material verwendet wird. Ein hoher Score heißt, der Retriever verschwendet keine Tokens. Ein niedriger heißt, er bringt Rauschen heran, und das Modell zahlt das Rauschen in Latenz und Qualität, weil sich lange irrelevante Kontexte wiederholt als generierungs-degradierend erwiesen haben.

Was Context Relevance nicht einfängt, ist Recall — ob alle Chunks, die das Modell gebraucht hätte, tatsächlich abgerufen wurden. Ein Retriever, der einen perfekten Chunk und sonst nichts zurückbringt, scort perfekt, auch wenn die Antwort zwei brauchte und der zweite fehlte. Recall ist sein eigenes Problem, gemessen gegen kuratierte Goldene Sets, in denen die antworttragenden Dokumente bekannt sind. Das Kapitel benennt außerdem zwei Artefakte, die man kennen sollte: aggressives Chunking bläst Context Relevance auf, ohne die Antwort notwendigerweise zu verbessern, und ungewichtete Mittelwerte über ein festes Top-k können einen Retriever schlecht aussehen lassen, wenn die irrelevanten Chunks auf Position vier bis zehn das Modell ohnehin kaum beeinflussen.

9.3 Groundedness — hat das Modell den Kontext geehrt?

Groundedness, manchmal Faithfulness genannt, fragt das Gegenstück: Welcher Anteil der vom Modell produzierten Behauptungen kann durch den abgerufenen Kontext gestützt werden? Die Standardberechnung zerlegt die Antwort in atomare Behauptungen und fragt den Judge für jede einzeln, ob der Kontext sie stützt. Die Zerlegung ist der entscheidende Teil. Eine lange Antwort als Block zu bewerten, neigt zu vollständig grounded oder vollständig ungrounded, je nachdem, wohin der Gesamteindruck zieht. Atomare Behauptungen zwingen den Judge, jede Aussage unabhängig zu bewerten — was das häufige Versagen einfängt, bei dem eine größtenteils korrekte Antwort einen Satz enthält, den der Kontext nie gestützt hat.

Das Kapitel ist ehrlich über Groundedness' Asymmetrie: Es bestraft Erfindung, aber nicht Auslassung. Ein Modell, das die Antwort verweigert, scort perfekt. Ein Modell, das eine korrekte, gut grounded Antwort gibt, aber einen entscheidenden Vorbehalt aus dem Kontext fallenlässt, scort ebenfalls gut. Es ist auch die Metrik, die am ehesten ein Prompt-Problem statt ein Modell-Problem aufdeckt. Wenn Context Relevance hoch ist und Groundedness niedrig, sitzt die Antwort fast immer im Systemprompt, nicht im Modell — die Anweisungen sind zu weich, das Modell im Kontext zu halten. Verschärfe den Prompt, bevor du das Modell beschuldigst.

9.4 Answer Relevance und die referenzfreie Verschiebung

Answer Relevance ist die am leichtesten misszuverstehende. Sie misst weder Korrektheit noch Grounding. Sie misst, ob die Antwort die gestellte Frage adressiert. Eine sachlich korrekte Antwort, die eine leicht andere Frage beantwortet, scort schlecht. Eine höfliche Verweigerung scort schlecht. Die Standardberechnung ist eine clevere Inversion: Aus der Antwort generiert man die Fragen, auf die sie plausibel eine Antwort sein könnte, und vergleicht diese mit der ursprünglichen. Sind sie nah, ist die Antwort am Ziel. Driften sie ab, ist das Modell abgewandert.

Answer Relevance ist auch der Ort, an dem die referenzfreie Verschiebung am härtesten zubeißt. Keine dieser Metriken kann durch Vergleich mit einer gelabelten richtigen Antwort berechnet werden — der Raum akzeptabler Antworten ist unendlich und nicht aufzählbar. Also hat sich das Feld auf LLM-as-a-Judge geeinigt: Ein Frontier-Modell benotet jede Metrik mit einem dokumentierten Prompt. Die Technik skaliert. Sie ist günstig. Sie korreliert grob mit menschlichem Urteil. Sie hat auch gut dokumentierte Versagensmuster — Positionsverzerrung in paarweisen Vergleichen, Längen-Bias, Modellfamilien-Bias, Kalibrierungsdrift über stille Modellupdates und das tiefere Problem, dass Judges und Generatoren Trainingskorpora teilen und daher korreliert versagen. Die Verteidigung ist nicht technisch, sondern operativ: Judge-Modell und -Prompt fixieren, gegen ein kleines handgelabeltes Set kalibrieren, einen kleinen Anteil bewerteter Outputs in menschliche Review schicken, und jeden Judge-Wechsel als Re-Baselining-Event behandeln, das historische Vergleiche entwertet.

Was Kapitel 9 vorbereitet

Die Triade gibt ein Vokabular dafür, was zu messen ist. Sie sagt nicht, wie die Messungen tatsächlich gefahren werden — die Prompts für den Judge, die Zerlegungslogik, die Embedding-Wahl, die Sampling-Rate, die Dashboards, das Alerting. Nichts davon wird neu von Grund auf gebaut. Über die letzten zwei Jahre ist eine kleine Zahl von Frameworks entstanden, die die Triade in der Praxis messbar machen, jedes mit eigenen Meinungen darüber, wie sich Produktionsevaluation anfühlen sollte. Kapitel 10 geht sie nebeneinander durch.

Als Nächstes — Kapitel 10: Führende Evaluations-Frameworks. RAGAS, TruLens, DeepEval und die Observability-Plattformen — wofür jedes da ist, wo die metrik-zuerst-Bibliotheken enden und die Produktionsplattformen beginnen, und die Evaluation Gap, die noch keine geschlossen hat.