RAG evaluieren: Retrieval-, Groundedness- und Antwortqualitätsmetriken

Eine belastbare RAG-Evaluation beantwortet mindestens drei unterschiedliche Fragen: Hat der Retriever die benötigte Evidenz gefunden, stützt sich die Antwort auf den abgerufenen Kontext und löst sie die Aufgabe des Nutzers? Ein aggregierter Score verdeckt die Fehlerursache. Hohe Groundedness hilft nicht, wenn das System einen irrelevanten Chunk korrekt wiedergibt; und eine richtige Antwort beweist keine gute Retrieval-Qualität, weil das Modell den Fakt aus seinem parametrischen Gedächtnis reproduziert haben kann.

Bauen Sie die Evaluation als Diagnosebaum auf. Fixieren Sie zuerst Corpus-Version, Query, erlaubte Dokumente und Relevanz-Labels. Speichern Sie danach Retrieved IDs, Rankings und Texte und erst anschließend Antwort, Zitate und Grader-Urteile. Dieser Trace trennt Ingestion-Defekte von Retrieval-Misses, Reranker-Regressionen, unbelegten Claims und schwacher Antwortform. Ein Release-Gate sollte aus separaten Schwellenwerten und kritischen Failure Cases bestehen, nicht aus einem hübschen Durchschnitt.

• Retrieval: ob die benötigten Dokumente oder Chunks in den Top-k erscheinen und auf welchen Positionen.
• Grounding: ob der Kontext jede überprüfbare Aussage der Antwort stützt.
• Antwortqualität: ob die Antwort korrekt, relevant, vollständig und für die Aufgabe brauchbar ist.
• Betrieb: Latenz, Kosten, leeres Retrieval, Timeouts und Ergebnisse mit veralteten Quellen.
• Safety: ACL-Leaks, Prompt Injection, unsichere Zitate und korrekte Abstention.

Markieren Sie für jede Eval-Query die relevanten Dokument- oder Chunk-IDs, idealerweise mit abgestufter Relevanz: kritische Evidenz, nützlicher Kontext und irrelevantes Material. Recall@k zeigt, welchen Anteil der benötigten Objekte das System in den ersten k Ergebnissen gefunden hat; Precision@k zeigt, wie viele dieser Ergebnisse tatsächlich relevant sind. Mean Reciprocal Rank ist nützlich, wenn das erste korrekte Ergebnis zählt, während nDCG Reihenfolge und mehrere Relevanzstufen berücksichtigt.

Verknüpfen Sie die Metrik mit UX und Generator-Contract. Wenn die Antwort nur vier Chunks nutzen kann, beschreibt Recall@50 den effektiven Kontext nicht. Prüfen Sie Document-Level- und Chunk-Level-Retrieval getrennt: Das richtige Dokument mit schlechtem Chunking kann wie ein Teilerfolg aussehen. Für Metadata-Filter, Tenant-ACLs und zeitabhängige Queries brauchen Sie zusätzlich Constraint Correctness: Ein relevantes, aber nicht erlaubtes oder veraltetes Dokument ist ein Fehler und kein positives Ergebnis.

Zerlegen Sie die Antwort in überprüfbare Aussagen und speichern Sie für jede Aussage supported, contradicted oder not-in-context zusammen mit den konkreten Source Spans. Groundedness beziehungsweise Faithfulness misst die Unterstützung durch den bereitgestellten Kontext, garantiert aber nicht die Wahrheit der Quelle selbst. Prüfen Sie Citation Correctness separat: Das Zitat muss auf genau den Abschnitt verweisen, der die Aussage belegt, nicht nur auf ein thematisch ähnliches Dokument.

Ein reference-free Judge ist für eine breite Regression Suite nützlich, sein Urteil ist jedoch kein Ground Truth. Kalibrieren Sie den Judge auf einem human-gelabelten Slice, messen Sie Agreement und Stabilität über wiederholte Runs, pinnen Sie Judge-Version und Prompt und geben Sie Grenz- sowie High-Risk-Cases an Menschen. Ergänzen Sie negative Beispiele mit widersprüchlichen Chunks, fehlender Antwort und Versuchen, das Modell zur Nutzung externen Wissens zu verleiten; sonst optimiert das Team nur einfache positive Cases.

Answer Correctness vergleicht das Ergebnis mit einer Reference Answer oder Rubric, doch Literal Match reicht bei offenen Antworten selten aus. Definieren Sie Pflichtfakten, zulässige Formulierungen, verbotene Claims, das benötigte Format und Abstention-Bedingungen. Für Extraction eignen sich Field-Level Precision und Recall; für Support Resolution Correctness und Escalation; für Research die Abdeckung zentraler Claims, Provenance und Darstellung von Unsicherheit.

Answer Relevance prüft, ob das System tatsächlich die gestellte Frage beantwortet, Completeness dagegen, ob notwendige Teile fehlen. Belohnen Sie keine bloße Länge: Eine kurze, belegte Antwort kann besser sein als ein vollständiger, aber riskanter Text. Führen Sie einen separaten Abstention Score für Queries ein, die der Corpus nicht abdeckt. Ein RAG-System, das ohne Evidenz ablehnt, kann eine niedrigere oberflächliche Answer Rate, aber eine bessere Fehlerkontrolle haben.

Starten Sie mit einem kleinen Set manuell geprüfter production-naher Queries und einem versionierten Manifest. Schichten Sie nach Intent, Schwierigkeit, Sprache, Antwortlänge, Quellentyp, Freshness, ACL und Fehlerkosten. Ergänzen Sie einfache Lookups, Multi-Hop-Fragen, mehrdeutige Formulierungen, No-Answer-Cases, adversariale Anweisungen in Dokumenten und Queries nach Corpus-Updates. Teilen Sie Train und Test nicht mit zufälligen Near-Duplicates desselben Dokuments.

Synthetische Fragen erweitern die Abdeckung, ersetzen aber keine menschliche Prüfung: Ein Generator kann eine Query erzeugen, die den Chunk unnatürlich wiederholt und den Retrieval Score künstlich erhöht. Kennzeichnen Sie die Herkunft jedes Case und berichten Sie Human-, Production- und Synthetic-Slices getrennt. Jeder Incident oder bestätigte User Correction sollte, sofern die Data Policy es erlaubt, einen bereinigten Regression Case erzeugen.

Wenn Retrieval Recall niedrig ist, untersuchen Sie Ingestion Coverage, Chunk-Grenzen, Query Rewriting, Embeddings, Filter und Hybrid Search, bevor Sie den Generator-Prompt ändern. Wenn Recall gut, aber Precision oder nDCG schwach sind, optimieren Sie Ranking, Deduplication und Top-k. Sind die Belege korrekt, aber Groundedness fällt, prüfen Sie Context Assembly, Instruction Hierarchy, Claim Scope und Citation Generation. Ist Groundedness hoch, aber der Answer Score niedrig, kann ein unvollständiger Corpus oder eine unpassende Task Rubric die Ursache sein.

Ändern Sie pro Experiment nur einen kontrollierten Faktor und bewahren Sie Retrieved Snapshots für gepaarte Vergleiche auf. Wer Chunking, Embedding Model und Prompt gleichzeitig ändert, kann Improvement oder Regression nicht erklären. Segment-Level-Ergebnisse sind wichtiger als der Portfolio-Durchschnitt: Verbesserungen bei einfachen FAQs dürfen Verschlechterungen bei ACL-, No-Answer- oder mehrsprachigen Queries nicht verdecken.

• Fehlende Evidenz → Ingestion, Query, Filter, Embedding oder Retrieval untersuchen.
• Evidenz zu niedrig gerankt → Reranking, Hybrid Weights, Deduplication oder Top-k untersuchen.
• Belegter Kontext, unbelegter Claim → Generation, Context Assembly oder Judge untersuchen.
• Richtige Antwort, falsches Zitat → Citation Alignment als eigenen Defekt behandeln.
• Guter Offline Score, schlechtes Production Outcome → Dataset Drift oder Rubric Mismatch untersuchen.

Führen Sie in CI deterministische Retrieval-Metriken auf einem gepinnten Corpus Snapshot aus und Model-based Grader mit fixierten Versionen, Prompts und Retry Policy. Das Gate kann null kritische ACL-Leaks, No-Answer False Confidence unter einem vereinbarten Schwellenwert, Non-Regression für zentrale Slices sowie begrenzte Latenz und Kosten verlangen. Konkrete Thresholds leiten Sie aus Baseline und Risk Appetite Ihres Systems ab; eine universell sichere Zahl gibt es nicht.

Sammeln Sie nach dem Canary privacy-sichere Traces, User Corrections, Citation Opens, Empty Retrieval und Escalation Outcomes, behandeln Sie einen impliziten Klick aber nicht als Beweis für Correctness. Sampling leitet schwierige Cases in Review, bestätigte Fehler kehren in das Eval-Set zurück. Rollback stellt frühere Corpus-, Retriever-, Reranker- und Prompt-Versionen als abgestimmtes Bundle wieder her. Der Audit Trail muss zeigen, welches Dataset, welcher Code, welche Daten und welche Grader den Release erlaubt haben.