RAG- und Retrieval-Evaluation

Ein RAG-System beantwortet Fragen in zwei Schritten. Der Suchschritt holt zu einer Frage die passenden Dokumente aus Ihrer Ablage, etwa die Produktdoku. Der Antwortschritt gibt Frage und Dokumente einem Modell, das daraus die Antwort schreibt. Der Nutzer sieht nur die Antwort. Ist sie falsch, kann die Ursache in jedem der beiden Schritte liegen. Und die Reparatur sieht jeweils völlig anders aus.

Der Support-Assistent aus dem Praxisbeispiel ist so ein System. Zum Ticket T-48213 hat der Suchschritt den Abschnitt pricing#plans geholt. Der Antwortschritt hat daraus 39 € für einen Kunden im Pro-Tarif gemacht. Richtig wären 45 €. Von außen sieht man nicht, was passiert ist. Hat der Suchschritt den falschen Abschnitt geliefert? Oder hat der Antwortschritt den richtigen Abschnitt falsch gelesen? Im ersten Fall muss niemand den Prompt anfassen. Im zweiten Fall muss niemand den Suchindex anfassen.

Die erste Regel der RAG-Evaluation lautet deshalb: Messen Sie die zwei Schritte getrennt, dann das Ganze. Dieses Kapitel macht daraus drei Messungen, jede mit der Datei, die man dafür braucht, und dem, was man danach sieht.

Messung 1: Der Suchschritt

Was Sie tun. Die Frage an den Suchschritt lautet nicht „War die Antwort gut?“. Sie lautet: „Waren die Dokumente, die die Antwort braucht, unter den gefundenen?“ Dafür brauchen Sie für jede Frage eine Liste der Dokumente, die sie wirklich beantworten. Das sind die Labels dieser Messung. Dann lassen Sie den Suchschritt allein über die Fragen laufen und vergleichen, was er holt, mit der Liste.

Die Datei. Eine Zeile je Frage in evals/relevance.jsonl. relevant sind die Abschnitte, die ein Mensch als nötig markiert hat:

{"query_id":"q-001","query":"Was kostet ein zusätzlicher Platz im Monat?","relevant":["pricing#plans","pricing#seats"]}
{"query_id":"q-002","query":"Gilt der Nachtzuschlag ab 21:45?","relevant":["rules#night-surcharge"]}
{"query_id":"q-003","query":"Wie exportiere ich den Dienstplan nach Excel?","relevant":["export#excel","export#formats","export#permissions"]}

Woher diese Labels kommen: Nehmen Sie Antworten, die Ihr Team für gut hält. Finden Sie zu jeder Aussage darin den Abschnitt, aus dem sie stammt. Diese Abschnitte sind relevant. Fünfzig solcher Zeilen sind ein unvollständiges, aber echtes Label-Set. Das ist die wertvollste Label-Arbeit, die ein RAG-Team leisten kann.

Die Rechnung. Die Zahl heißt Recall@k: Wie viele der nötigen Abschnitte sind unter den ersten k gefundenen? Frage q-003 braucht drei Abschnitte. Der Suchschritt liefert fünf, darunter zwei der drei nötigen. Recall@5 ist 2 von 3, also 0,67. Den dritten Abschnitt hat der Antwortschritt nie zu sehen bekommen. Kein Prompt und kein besseres Modell kann ihn zurückholen, denn die Information ist nicht im Raum. Deshalb kommt diese Zahl vor jeder anderen.

# evals/recall.py
import json
import pathlib
import sys

from app.search import retrieve          # der Suchschritt des Produkts, ohne Modellaufruf

k = int(sys.argv[1])                     # z. B. 5
zeilen = [json.loads(z) for z in pathlib.Path("evals/relevance.jsonl").read_text().splitlines()]

summe = 0.0
for zeile in zeilen:
    gefunden = [doc["ref"] for doc in retrieve(zeile["query"])[:k]]
    treffer = sum(1 for ref in zeile["relevant"] if ref in gefunden)
    summe += treffer / len(zeile["relevant"])
    if treffer < len(zeile["relevant"]):
        print(f"{zeile['query_id']}  {treffer}/{len(zeile['relevant'])}  fehlt: {set(zeile['relevant']) - set(gefunden)}")

print(f"\nRecall@{k} = {summe / len(zeilen):.2f}  über {len(zeilen)} Fragen")

Was Sie sehen. Eine Zeile je Frage, bei der etwas fehlt, und der Mittelwert:

q-003  2/3  fehlt: {'export#permissions'}
q-017  0/1  fehlt: {'billing#invoices-pdf'}

Recall@5 = 0.84  über 50 Fragen

Die Zeilen mit fehlt sind die Arbeitsliste für den Suchschritt: Abschnitte, die es gibt, die aber zu ihrer Frage nicht gefunden werden.

Zwei weitere Zahlen aus derselben Datei, beide Jahrzehnte alt und gut verstanden. Precision@k fragt umgekehrt: Wie viele der fünf gelieferten Abschnitte waren relevant? Das zählt, denn irrelevante Abschnitte kosten nicht nur Token. Sie machen die Antwort schlechter. MRR und nDCG berücksichtigen zusätzlich die Position: Kam der relevante Abschnitt an erster oder an fünfter Stelle? Das zählt, weil ein Modell einen langen Kontext ungleichmäßig liest.

Messung 2: Der Antwortschritt, Suche festgehalten

Was Sie tun. Jetzt der andere Schritt. Diese Messung überspringen Teams am häufigsten. „Festgehalten“ heißt: Der Suchschritt läuft gar nicht. Sie geben dem Antwortschritt einen Satz Dokumente, den Sie selbst ausgewählt haben und von dem Sie wissen, dass es die richtigen sind. Dann bewerten Sie die Antwort. Ist sie falsch, kann der Suchschritt nicht schuld sein, denn er lief nicht. Sie messen allein den Antwortschritt.

Die Datei. Das ist genau der Fall aus Ein Eval in fünf Dateien. Dort steht retrieved fertig in der Falldatei, und run.py gibt diese Abschnitte dem Modell, ohne zu suchen:

{
  "id": "case-001",
  "ticket": "Was kostet ein zusätzlicher Platz im Monat?",
  "customer": { "plan": "pro" },
  "retrieved": [
    { "ref": "pricing#plans", "text": "Starter: 39 € pro Platz und Monat. Pro: 45 € pro Platz und Monat." },
    { "ref": "pricing#seats", "text": "Zusätzliche Plätze werden ab dem Tag der Aktivierung anteilig berechnet." }
  ],
  "checks": ["zitate_loesen_auf", "keine_zahl_ohne_beleg", "erwartetes_kommt_vor"],
  "expect": { "nennt": ["\\b45\\s?€"] }
}

Der Antwortschritt bekommt hier die richtigen zwei Abschnitte. Nennt er trotzdem 39 €, liegt der Fehler in ihm. Bewertet wird mit den Prüfungen aus den fünf Dateien und dem Judge aus dem Praxisbeispiel.

Was Sie sehen. Die Bestehensquote des Antwortschritts bei perfekter Suche. Sie ist die Obergrenze für das ganze System: Besser als diese Zahl kann das Ganze nicht werden, egal wie gut die Suche wird.

Warum sich diese Messung verteidigen lässt, wenn jemand sie streichen will: Ihr Gesamtwert fällt um drei Punkte. In derselben Woche hat eine Person den Prompt geändert und eine andere das Embedding-Modell getauscht. Mit Messung 1 und 2 wissen Sie, welche der beiden Änderungen es war. Ohne sie raten Sie, und zwei Teams streiten sich.

Messung 3: Das Ganze

Was Sie tun. Erst jetzt läuft die echte Pipeline, Suchschritt und Antwortschritt hintereinander, über das echte Eval-Set. Bewertet wird, ob die Aufgabe erledigt wurde. Die Fälle sehen aus wie im Praxisbeispiel: retrieved steht nicht in der Datei, sondern der Runner lässt die Suche laufen, gegen die festgenagelte Doku.

Was Sie sehen. Die Zahl, die Sie berichten. Die zwei Messungen davor erklären Ihnen diese Zahl, wenn sie sich bewegt: Fällt Messung 1, war es die Suche. Fällt Messung 2, war es der Antwortschritt.

In Produktion kommen die billigen Prüfungen dazu, die keine Musterantwort brauchen: Jede Quellenangabe verweist auf einen wirklich gefundenen Abschnitt, jede Zahl in der Antwort kommt im gefundenen Text vor. Online-Evaluation zeigt, wie diese Prüfungen auf echtem Verkehr laufen.

Die Falle, wenn Sie Messung 1 überspringen

Die meisten Teams messen den Antwortschritt mit einer beliebten Zahl: Faithfulness, auf Deutsch Quellentreue. Ein Judge zerlegt die Antwort in einzelne Aussagen. Jede Aussage prüft er gegen die gefundenen Abschnitte: Steht das da drin? Der Wert ist die Zahl der belegten Aussagen geteilt durch alle Aussagen.

Lesen Sie diese Definition noch einmal und achten Sie darauf, was fehlt. Faithfulness fragt nie, ob die gefundenen Abschnitte die richtigen waren. Sie misst nur, ob der Antwortschritt sich an das Gelieferte gehalten hat.

Ein Beispiel. Ein System hat eine Faithfulness von 0,91, ein hervorragender Wert. Gleichzeitig melden Nutzer, dass etwa jede sechste Antwort etwas Wichtiges auslässt. Beide Beobachtungen stimmen. Der Antwortschritt verhält sich tadellos: Jede Aussage ist belegt, nichts ist erfunden. Der Suchschritt aber übersieht bei Fragen, die zwei Abschnitte brauchen, den zweiten. Der Recall liegt bei etwa 0,62. Der Antwortschritt fasst getreu die halbe Antwort zusammen.

Faithfulness kann diesen Fehler von ihrer Konstruktion her nicht sehen. Genau davor schützt Messung 1.

(Dieses Muster ist breit beschrieben. Die konkreten Zahlen oben sind illustrativ und stammen nicht aus einer veröffentlichten Fallstudie.)

Häufiger Fehler: Faithfulness als die RAG-Qualitätsmetrik berichten. Sie deckt nur den Antwortschritt ab. Für sich genommen belohnt sie ein System, das schlecht sucht und vorsichtig formuliert. Recall ist die Metrik, die den Fehler fängt, den Nutzer wirklich bemerken. Und Recall braucht gelabelte Abschnitte. Genau deshalb überspringen Teams ihn.

Wessen Fehler war es?

Liefert das ganze System eine falsche Antwort, sagen Ihnen die Messungen 1 und 2, welchen Schritt Sie verdächtigen sollten. Das geht auch je Antwort. Zerlegen Sie die Antwort in ihre Aussagen. Prüfen Sie jede. Fragen Sie bei jeder falschen Aussage: Wurde der Abschnitt, der sie richtig gemacht hätte, überhaupt gefunden?

Nehmen Sie eine Antwort:

„Ihre Plus-Mitgliedschaft enthält kostenlose Rücksendungen innerhalb von 30 Tagen, und Erstattungen werden in 3 Werktagen bearbeitet.“

Das sind drei Aussagen, nicht eine Antwort. Prüfen Sie jede gegen die Abschnitte, die das System tatsächlich gefunden hat:

Die dritte Spalte ist der ganze Trick. Die zwei unteren Aussagen sind beide falsch. Ein einzelner Qualitätswert würde sie in einen Topf werfen. Es sind aber verschiedene Fehler mit verschiedenen Zuständigen. Am Prompt zu arbeiten hilft der dritten Zeile nicht. An der Suche zu arbeiten hilft der zweiten Zeile nicht.

Die Frage „Stützt dieser Abschnitt diese Aussage wirklich?“ hat einen Fachnamen: Entailment-Prüfung. Er taucht im nächsten Befund auf.

Befund: RAGChecker (NeurIPS 2024) zerlegt Antworten in Behauptungen. Mit Entailment-Prüfung ordnet es jeden Fehler dem Retriever oder dem Generator zu. Für seine Metriken auf Behauptungsebene wurde eine Korrelation mit menschlicher Präferenz von bis zu 62 % Pearson berichtet. Das liegt über BLEU, ROUGE, BERTScore, TruLens, RAGAS und ARES im selben Vergleich. (Die Pearson-Korrelation misst, wie eng zwei Ranglisten miteinander laufen. Die Skala reicht von 0 „kein Zusammenhang“ bis 1 „perfekte Übereinstimmung“. 62 % gegen menschliche Präferenz ist für diese Art Metrik viel.)

Quelle: RAGChecker, NeurIPS 2024

Befund: ARES verfolgt einen anderen Ansatz: synthetische Trainingsdaten plus leichte Judge-Modelle. Kalibriert werden sie mit Prediction-Powered Inference. Das ist ein statistisches Verfahren. Es korrigiert die Schätzungen billiger Klassifikatoren mithilfe einer kleinen, von Menschen gelabelten Stichprobe. ARES ist die prinzipiellste veröffentlichte Antwort auf die Frage „Wie traue ich einem billigen Judge auf ungelabelten Daten?“. Sie verdient mehr Aufmerksamkeit, als sie bekommt.

Quelle: ARES, 2023

Quellenangaben prüfen

Wenn Ihr Produkt Quellen anzeigt, ist die Korrektheit der Quellenangaben vermutlich die Zahl, die Ihre Nutzer wirklich interessiert. Sie zerfällt in drei Prüfungen. Zwei davon kennen Sie schon aus den fünf Dateien:

1. Auflösbar: Der zitierte Abschnitt existiert und war unter den gefundenen. Das ist zitate_loesen_auf. Reiner Code, kein Judge.
2. Stützend: Der zitierte Abschnitt enthält eine Aussage, die die Behauptung stützt. Das ist die Frage des Judges aus dem Praxisbeispiel. Braucht einen Judge oder einen Menschen.
3. Vollständig: Jede Aussage, die einen Beleg braucht, hat einen. Braucht die Zerlegung in Aussagen.

Prüfung 1 läuft kostenlos auf 100 % des Produktionsverkehrs. Viele Teams entdecken beim ersten Lauf eine nennenswerte Rate nicht auflösbarer Quellenangaben. Das ist peinlich und zugleich der billigste mögliche Gewinn.

Die Namen, die Ihnen in Werkzeugen begegnen

RAGAS hat den größten Teil des Vokabulars geliefert, das Eval-Werkzeuge heute benutzen. Die Namen sind eingängiger als die Definitionen. Deshalb steht hier, was jede Kennzahl fragt und zu welcher Messung dieses Kapitels sie gehört:

Bis 2026 hatte RAGAS sich weit über RAG hinaus ausgedehnt: agentische Workflows, Text-zu-SQL und multimodale Kennzahlen wie Multimodal Faithfulness und Noise Sensitivity. Die referenzfreie Philosophie ist mitgewandert. Referenzfrei heißt: Die Kennzahlen brauchen keine gelabelten Abschnitte.

Das ist bequem und eine Warnung wert. Die zwei Kennzahlen ohne Labels sind genau die zwei, die den Suchschritt nicht sehen können. Ein durchgehend referenzfreier Stack hat auf einfache Einrichtung statt auf diagnostische Kraft optimiert. Die Falle oben zeigt, wie dieser Kompromiss in Produktion aussieht.