RAG Evaluation

RAG Evaluation prüft die Qualität eines RAG-Systems (Retrieval-Augmented Generation, also ein KI-Assistent, der eigene Dokumente durchsucht und die gefundenen Inhalte für die Antwort nutzt) getrennt auf zwei Ebenen: Suche (findet das System die richtigen Dokumente?) und Antwort (nutzt es diese Dokumente korrekt?). Grundlage ist ein Prüf-Datensatz mit Musterfragen und geprüften Referenz-Antworten. Damit lässt sich nach jeder Änderung am System nachvollziehbar messen, ob es besser oder schlechter geworden ist.

Was ist RAG Evaluation?

RAG Evaluation trennt die Bewertung eines RAG-Systems in zwei Ebenen, weil beide unabhängig voneinander fehlschlagen können: Die Suche kann die falschen Dokumente liefern, oder das Sprachmodell interpretiert die richtigen Dokumente falsch. Auf der Such-Ebene (Retrieval) prüft der Prüfrahmen, ob die passenden Textabschnitte unter den ersten Treffern stehen. Übliche Kennzahlen sind Recall@k (kommen die relevanten Textstellen in den obersten k Ergebnissen vor?) und Precision@k (wie viele der zurückgegebenen Treffer sind tatsächlich relevant?), ergänzt um rangordnungssensitive Maße wie Mean Reciprocal Rank und Normalized Discounted Cumulative Gain. Auf der Antwort-Ebene (Generation) wird geprüft, ob die Modellantwort durch die gelieferten Textabschnitte belegt ist und die Frage beantwortet. Übliche Kennzahlen sind Faithfulness beziehungsweise Groundedness (steht jede Aussage der Antwort im gelieferten Kontext?), Answer Relevance (passt die Antwort zur Frage?), Context Relevance (passt der gelieferte Kontext zur Frage?) und Correctness (Abgleich mit einer Referenz-Antwort). Die Trennung ist die eigentliche Diagnose-Leistung: Sinkt die Faithfulness, liegt die Ursache meist beim Sprachmodell; sinkt der Context Recall, liegt sie in der Suche.

Ein RAG-Evaluations-Setup besteht aus vier Bausteinen. Erstens ein Goldstandard-Dataset aus typisch 50 bis 500 kuratierten Frage-Antwort-Paaren mit Referenz-Kontext. Zweitens ein Metrik-Set über beide Ebenen. Drittens ein Judge: LLM-as-a-Judge (skalierbar, muss gegen menschliches Sample kalibriert sein), regel-basiert (deterministische Checks wie String-Match oder Zitations-Prüfung) oder menschlich (Human-Review auf Stichprobe). Viertens ein Runner, dessen Läufe versioniert und zwischen zwei Ständen vergleichbar bleiben. Etablierte Frameworks für diese Bausteine sind [RAGAS](https://docs.ragas.io/) (Referenz-Framework mit Faithfulness-, Answer-Relevancy- und Context-Recall-Metriken; [Es et al. 2023, arXiv 2309.15217](https://arxiv.org/abs/2309.15217)), TruLens (RAG-Triad aus Context Relevance, Groundedness und Answer Relevance), [DeepEval](https://deepeval.com/guides/guides-rag-evaluation), LangSmith, Arize Phoenix, [Databricks Agent Evaluation](https://docs.databricks.com/en/generative-ai/agent-evaluation/index.html) sowie MLflow-LLM-as-Judge-Metriken. Einen Überblick über den Forschungsstand liefert der [Survey von Yu et al. 2024, arXiv 2405.07437](https://arxiv.org/abs/2405.07437).

Der Prüfprozess verläuft in drei zeitlichen Phasen. Offline-Evaluation vor dem Rollout gegen das Goldstandard-Set. Regressions-Evaluation bei jeder Änderung an Chunking, Retriever, Reranker, Prompt oder Modell, damit eine neue Version bekannte Fälle nicht schlechter beantwortet als der Vorgänger. Online-Evaluation im Betrieb: eine Stichprobe des Live-Traffics wird mit demselben Judge nachbewertet, oft ergänzt um Human-Review auf einem kleinen Anteil.

Abgrenzung zu LLM Evaluation, Agent Evaluation und Retrieval-Benchmarks

Vier verwandte Prüfrahmen werden häufig gleichgesetzt, obwohl sie unterschiedliche Systeme messen.

LLM Evaluation prüft nur das Modell und ist damit blind für Retrieval-Fehler; ein Modell kann in einer isolierten LLM-Prüfung stark abschneiden und in der RAG-Pipeline dennoch falsche Antworten liefern, wenn der Retriever daneben greift. Agent Evaluation umfasst RAG als einen möglichen Tool-Aufruf, misst darüber hinaus aber Werkzeugwahl und Reasoning-Ketten. Retrieval-Benchmarks liefern eine vergleichbare Vermessung des Retrievers auf öffentlichen Datensätzen, sagen aber nichts über das eigene Aufgaben-Profil und nichts über die Generation-Ebene aus. Faithfulness schließlich ist keine Alternative zu RAG Evaluation, sondern eine einzelne Metrik in ihrem Metrik-Set.

Beispiel: Freigabe eines internen Wissensassistenten

Ein interner Wissensassistent auf Vector Search wird vor dem Rollout gegen ein Goldstandard-Set aus 200 Fragen mit Referenz-Antwort und Referenz-Kontext geprüft. Gemessen werden vier Kennzahlen: Context Recall@10 und Context Precision auf der Retrieval-Ebene sowie Faithfulness und Answer Relevance auf der Generation-Ebene, umgesetzt in RAGAS mit einem LLM-Judge. Der Judge wird vorab gegen ein Sample von 30 menschlich bewerteten Antworten kalibriert, damit die automatischen Scores belastbar bleiben. Erst wenn Recall und Faithfulness über definierten Schwellen liegen, geht die Version live. Bei jedem Wechsel der Chunk-Größe, jedem Prompt-Refactor und jedem Modell-Update läuft dieselbe Suite als Regression. Nach dem Rollout wird ein Anteil des Live-Traffics stichprobenhaft mit demselben Judge nachbewertet, um Drift und neue Fehlermuster früh zu erkennen. Die Läufe landen versioniert in MLflow oder LangSmith und lassen sich zwischen zwei Ständen direkt vergleichen.