RAG Evaluation: Metriken, Golden Dataset & Regression Tests

Ein RAG-System ist nicht gut evaluiert, weil seine Antworten in einer Demo plausibel wirken. RAG-Evaluation beginnt mit der Frage, welche Schicht versagt hat: Retrieval, Context Assembly oder Generation. Erst danach ist eine Metrik hilfreich.

Eine falsche Antwort ist ein Symptom, keine Fehlerursache. Wurde das aktuelle Dokument nicht gefunden? Wurde die entscheidende Passage nicht in den Modellkontext übernommen? Oder lag die Evidenz vor und das Modell hat sie falsch verwendet? Für das Gesamtbild der Pipeline siehe RAG-System entwickeln & richtig aufbauen. Wenn ein PoC bereits existiert und seine Qualität belastbar werden muss, führt der direkte Weg zur KI Production Readiness.

RAG Evaluation in einem Satz

Ein produktives RAG-System sollte jede falsche oder unsichere Antwort einer prüfbaren Fehlerklasse zuordnen können. Ein einziger „Answer Quality“-Score kann zeigen, dass etwas schiefgeht. Er zeigt nicht, welche Änderung Retrieval, Kontextaufbereitung oder Generation tatsächlich verbessert.

Ein falscher Wert ist noch keine Diagnose

Eine Mitarbeiterin fragt: „Welche Kündigungsfrist gilt für meine Rolle?“ Das System antwortet „drei Monate zum Quartalsende“. Die aktuelle HR-Richtlinie enthält jedoch „zwei Monate zum Monatsende“; eine ältere Richtlinie enthält den Wert aus der Antwort.

Ohne Diagnose ist die naheliegende Reaktion oft: Prompt anpassen oder Modell wechseln. Das wäre voreilig. Vier unterschiedliche Ursachen sind möglich:

1. Das Retrieval hat die aktuelle Richtlinie nicht gefunden und nur die alte Version geliefert.
2. Beide Dokumente wurden gefunden, aber die aktuelle Passage wurde durch Chunking, Kontextlimit oder Auswahl nicht an das Modell übergeben.
3. Die aktuelle Passage lag im Kontext, doch das Modell hat die ältere Passage bevorzugt, falsch zusammengefasst oder ohne belastbare Quelle geantwortet.
4. Die erwartete Referenz im Testfall ist selbst veraltet, der Geltungsbereich der Richtlinie wurde falsch erfasst oder die Nutzerrolle hat eine Ausnahme.

Die gleiche sichtbare Antwort verlangt also vier verschiedene Prüfungen. Das ist der Grund, warum Metriken nicht die Dramaturgie der Evaluation sein sollten.

Falsche RAG-Antwort diagnostizieren

1. 01

   Retrieval

   Wurde die aktuelle, für diese Rolle erlaubte Evidenz gefunden?

   Recall, Filter und Index prüfen

2. 02

   Context Assembly

   Kam die entscheidende Passage vollständig und ohne störenden Altbestand in den Modellkontext?

   Coverage, Versionen und Chunk-Auswahl prüfen

3. 03

   Generation

   Hat das Modell die bereitgestellte Evidenz korrekt verwendet und belegt?

   Correctness, Groundedness und Zitat prüfen

4. 04

   Erwartung validieren

   Ist die Referenzantwort für Rolle, Zeitpunkt und Richtlinienstand überhaupt gültig?

   Ground Truth und Geltungsbereich prüfen

Diagnosepfad: Retrieval, Context Assembly, Generation

1. Retrieval: Wurde die richtige Evidenz gefunden?

Hier geht es noch nicht um einen schönen Antworttext. Prüfen Sie, ob die aktuelle Richtlinie innerhalb der abgerufenen Treffer liegt und ob Versions-, Rollen- und Berechtigungsfilter korrekt greifen. Fehlt sie, liegen die nächsten Untersuchungen bei Query-Aufbereitung, Index, Embeddings, Hybrid Search, Metadaten oder Filtern.

Recall@k ist passend, wenn die relevante Evidenz in den Top-k-Treffern erscheinen muss. Precision@k ist sinnvoll, wenn zu viel irrelevantes oder veraltetes Material die nachfolgende Auswahl belastet. MRR oder nDCG lohnen sich nur, wenn die Rangfolge selbst relevant ist: etwa wenn die erste brauchbare Passage sehr früh liegen muss oder mehrere Evidenzen in einer abgestuften Reihenfolge gebraucht werden.

Die Suchstrategie ist keine Glaubensfrage. Exakte Richtliniennamen, Versionen oder Rollenkennungen können lexical search brauchen, semantisch formulierte Fragen oft Vector Search. Der Vergleich Hybrid Search vs. Vector Search für RAG zeigt, warum beides gegen reale Fälle geprüft werden muss.

2. Context Assembly: Wurde die Passage wirklich nutzbar gemacht?

Ein Treffer ist noch kein brauchbarer Kontext. Die aktuelle Richtlinie kann in den Top-k liegen, während das übergebene Kontextfenster nur die alte Passage enthält. Typische Ursachen sind ungünstige Chunk-Grenzen, ein Reranker, zu kleine Kontextbudgets, doppelte Inhalte oder fehlende Versionslogik.

Hier zählen Evidence Coverage und die Qualität des tatsächlichen Modellkontexts: Ist die entscheidende Passage enthalten, vollständig, aktuell und für diesen Nutzer freigegeben? Messen oder prüfen Sie außerdem das Verhältnis von relevanter zu irrelevanter Evidenz sowie stale oder duplicate content. Mehr Kontext ist nicht automatisch besser; irrelevante Chunks können die tragende Aussage verdrängen.

Wenn die Evidenzeinheit schon bei der Aufbereitung unbrauchbar wird, kann Retrieval sie nicht sauber liefern. Deshalb gehört RAG Chunking: Strategien für Unternehmensdaten in dieselbe Evaluationsschleife.

3. Generation: Wurde die Evidenz korrekt verwendet?

Liegt die richtige Passage im Kontext, darf die Antwort trotzdem nicht blind als korrekt gelten. Prüfen Sie Correctness gegen fachliche Regeln, erwartete Werte oder eine begründete Referenzantwort. Groundedness prüft, ob die Antwort durch den bereitgestellten Kontext gedeckt ist. Citation Accuracy prüft, ob eine angegebene Quelle die jeweilige Aussage wirklich trägt. Instruction Adherence und Task Success sind wichtig, wenn die Antwort zum Beispiel eine Ausnahme erklären, sicher eskalieren oder ausdrücklich keine Antwort erfinden soll.

LLM-as-a-Judge kann semantische Bewertungen skalieren, ersetzt aber keine überprüfbare Erwartung. Deterministische Checks für Werte, Daten, IDs oder Formate und menschliche Prüfung kritischer Fälle bleiben sinnvoll. Grader-Prompt, Grader-Modell und Rubrik müssen versioniert sein, damit nicht Messmethode und System gleichzeitig wechseln.

4. Erwartung validieren: Ist die Ground Truth gültig?

Auch das Golden Dataset kann falsch liegen. Bei Richtlinienfragen muss klar sein, welche Version am Stichtag gültig war, für welche Rolle sie gilt und ob es dokumentierte Ausnahmen gibt. Eine Referenzantwort ohne erwartete Quelle oder Bewertungskriterium kann nicht sauber zwischen Systemfehler und falscher Erwartung unterscheiden.

Diese vierte Prüfung verhindert einen besonders teuren Fehler: Das System wird auf eine veraltete oder zu grobe Testreferenz optimiert.

Golden Dataset: kontrollierte Testbasis statt Benchmark-Sammlung

Ein Golden Dataset ist kein statischer Katalog akademischer Fragen. Es ist eine versionierte Kontrollbasis für reale Nutzerfragen und die Evidenz, auf die sich eine Antwort stützen darf.

Ein brauchbarer Fall enthält:

• den realistischen Query-Typ und gegebenenfalls die konkrete Aufgabe,
• erwartete Quellen, Dokumente oder Passage als Evidenz,
• eine erwartete Antwort oder explizite Bewertungskriterien,
• Nutzerrolle, Mandant und relevante Berechtigungen,
• Gültigkeitszeitpunkt, Dokumentversion und bekannte Aktualitätsrisiken,
• das erwartete Verhalten bei fehlender oder widersprüchlicher Evidenz.

Damit testet der Kündigungsfrist-Fall nicht nur den Text „zwei Monate“, sondern auch, ob die aktuelle Richtlinie gefunden wird, ob alte Fassungen verdrängt werden, ob die Mitarbeiterin die Information sehen darf und ob eine Ausnahme sauber behandelt wird. Negativfälle gehören dazu: Eine Frage darf keine nicht freigegebene Evidenz in Retrieval, Kontext oder Antwort sichtbar machen. Das verbindet Evaluation direkt mit RAG-Berechtigungen und Security Trimming.

Metriken folgen der Fehlerklasse

Eine kleine, erklärbare Messung ist besser als eine lange Liste ohne Entscheidungskontext:

NVIDIA führt in seiner RAG-Blueprint-Dokumentation unter anderem Answer Accuracy, Context Relevancy und Response Groundedness als getrennte Dimensionen. Das passt zu diesem Diagnoseprinzip: Kontext und generierte Antwort sind nicht dieselbe Qualitätsfrage. Quelle: NVIDIA RAG Blueprint – Evaluate.

Regression statt Demo-Bewertung

Sobald das Golden Dataset reale Fehlerklassen abdeckt, wird es zur Regression-Suite. Jede Änderung an Chunking, Retrieval, Reranking, Prompting, Modell oder Daten muss gegen dieselbe kontrollierte Basis laufen. Das gilt ebenso für Embeddings, Query-Rewriting, Hybrid-Gewichtung, Kontextgröße, Datenquellen und Berechtigungslogik.

Entscheidend ist nicht, ob eine neue Version „besser wirkt“. Dokumentieren Sie pro Änderung, welche Fälle besser werden, welche regressieren und welche Kosten oder Latenzen sich verschieben. Ein globaler Mittelwert darf keine kritische Regression bei Richtlinien, Preisen, Berechtigungen oder Compliance-Fällen verdecken.

Production Monitoring und Drift

Regressionstests schützen vor bekannten Fällen vor dem Rollout. Im Betrieb kommen neue Dokumente, veränderte Sprache, neue Rollen, geänderte Berechtigungen und unerwartete Fragen hinzu. Monitoring ergänzt das Golden Dataset deshalb um Signale wie Retrieval-Fehlschläge, leere oder übervolle Kontexte, Citation-Fehler, Eskalationen, No-Answer-Raten, Latenz und Kosten.

Produktionssignale sind kein automatischer Beweis für einen Modellfehler. Sie liefern Kandidaten für neue oder nachzuschärfende Golden-Set-Fälle. So bleibt das Dataset eine kontrollierte Basis und wächst nur mit überprüften realen Fehlern.

Architecture View: Fehler lokalisierbar machen

Ein produktives RAG-System sollte Fehler lokalisieren können. Wenn Retrieval, Kontextaufbereitung und Generation nur mit einem einzigen „Answer Quality“-Score bewertet werden, bleibt unklar, welche Änderung das System tatsächlich verbessert oder verschlechtert.

Die Architektur braucht daher getrennt erfassbare Artefakte: Query und Nutzerkontext, abgerufene Treffer mit Versions- und Berechtigungsdaten, tatsächlich übergebene Chunks, Antwort und Quellenbezug sowie die Version der Evaluationsregel. Jede Änderung an Chunking, Retrieval, Reranking, Prompting oder Modell sollte gegen dasselbe Golden Dataset regressionsgetestet werden.

Das ist keine zusätzliche Bürokratie. Es ist die Voraussetzung, um aus einer falschen Antwort eine konkrete technische Entscheidung abzuleiten statt an der falschen Schicht zu optimieren.

Nächster Schritt

Wenn ein bestehendes RAG-System plausible Antworten liefert, aber Qualität, Berechtigungen oder Regressionen nicht belastbar diagnostiziert werden können, ist nicht noch ein weiterer Prompt-Tuning-Zyklus der richtige nächste Schritt.

Ich unterstütze Unternehmen dabei, vorhandene RAG- und LLM-Systeme mit realistischen Testsets, Failure Analysis und klaren Go-Live-Kriterien zu prüfen: KI-System testen und produktionsreif machen.

Für einen Neuaufbau oder die technische Integration in bestehende Systeme ist RAG-Implementierung & KI-Integration der passendere Einstieg.