RAG-Qualität messen: Testset, Metriken und Abnahme

Ein Wissenssystem mit nachgewiesener Antwortqualität statt Demo-Eindruck? Der RAG Proof of Value bewertet einen abgegrenzten Bestand anhand vereinbarter Referenzfragen mit Baseline-Messung, zwei Optimierungszyklen und Qualitätsbericht. Für laufende Anwendungen übernimmt LLMOps die regelmäßigen Eval-Läufe. RAG Proof of Value ansehen · Interne KI-Assistenten

Ein RAG-System wirkt in der Demo fast immer gut: Die vorbereiteten Fragen treffen, die Antworten sind flüssig und nennen Quellen. Ob es im Alltag trägt, zeigt erst eine Messung mit Fragen, die niemand für die Demo ausgesucht hat. Dieser Artikel beschreibt, wie ein belastbares Testset entsteht, welche Metriken die Suche und welche die Antwort messen, wo automatische Bewertung durch ein Sprachmodell hilft und wo nicht, und wie daraus Abnahmekriterien und Regressionstests werden. Er ist unabhängig vom eingesetzten Framework; Ragas und Langfuse dienen als Beispiele, weil beide Open Source sind und sich selbst betreiben lassen. Stand September 2026.

Inhaltsverzeichnis

• Zwei Ebenen: Suche und Antwort getrennt messen
• Das Testset: Referenzfragen aus dem Fachbereich
• Retrieval-Metriken: Recall@k, Precision@k, MRR und nDCG
• Antwortmetriken in Ragas
• LLM-as-a-Judge mit lokalem Modell
• Abnahmekriterien festlegen
• Regressionstests bei Änderungen an Modell, Index und Prompt
• Evaluation im laufenden Betrieb
• Typische Messfehler

Zwei Ebenen: Suche und Antwort getrennt messen

Ein RAG-System besteht aus zwei Schritten, die unabhängig voneinander scheitern können: Die Suche holt Textabschnitte aus dem Index, das Sprachmodell formuliert daraus eine Antwort. Wie beides zusammenspielt, erklärt Was ist RAG?. Für die Messung heißt das: Eine einzige Gesamtnote verdeckt, wo der Fehler liegt.

Die Reihenfolge der Fehlersuche folgt daraus. Fehlt die richtige Fundstelle im Kontext, kann kein Modell eine korrekte, belegte Antwort erzeugen, und jede Arbeit am Prompt ist verschwendet. Erst wenn die Suche nachweislich liefert, lohnt es sich, die Antwortseite zu optimieren. Stellschrauben auf der Suchseite beschreiben die Artikel zu Chunking und zu Hybrid Search und Reranking.

Das Testset: Referenzfragen aus dem Fachbereich

Jede Metrik ist nur so gut wie die Fragen, an denen sie gemessen wird. Das Testset (oft Goldstandard oder Golden Dataset genannt) ist deshalb der wichtigste und zugleich der am häufigsten vernachlässigte Teil der Evaluation.

Woher die Fragen kommen. Die besten Quellen sind Fragen, die heute schon gestellt werden: Tickets, E-Mails an die Fachabteilung, Einträge im internen Forum, Suchanfragen im Intranet. Sie verwenden die Begriffe der Nutzer und nicht die der Dokumente, und genau an dieser Lücke scheitern Suchsysteme. Fragen, die ein Entwickler beim Lesen eines Dokuments formuliert, übernehmen dessen Wortlaut und sind dadurch zu leicht.

Was zu jedem Eintrag gehört.

Welche Fragetypen hinein gehören. Ein Testset aus lauter leicht beantwortbaren Fragen misst nur, dass das System leichte Fragen beantworten kann.

Die Rechte-Tests sind keine Qualitätsfrage im engeren Sinn, gehören aber in dasselbe Set, weil sie bei jeder Änderung mitlaufen müssen. Warum der Filter vor der Suche sitzen muss, beschreibt RAG mit Berechtigungen.

Umfang. Eine allgemeingültige Mindestzahl gibt es nicht. Für einen abgegrenzten Wissensbestand sind 40 bis 60 sorgfältig ausgewählte Fragen ein tragfähiger Start, wenn alle Fragetypen vertreten sind. Wichtiger als die Zahl ist, dass jede Kategorie mehrere Fälle hat, damit ein einzelner Ausreißer nicht das Bild bestimmt.

Synthetische Fragen. Ragas kann Testsets aus den Dokumenten erzeugen, auch auf Deutsch (Non-English Testset Generation). Das ist nützlich, um Breite zu gewinnen, hat aber eine eingebaute Schwäche: Die Fragen entstehen aus dem Text, den das System finden soll, und treffen deshalb dessen Wortlaut. Synthetische Fragen ergänzen den Kern aus echten Fragen, sie ersetzen ihn nicht, und jede übernommene Frage sollte ein Mensch gelesen haben.

Retrieval-Metriken: Recall@k, Precision@k, MRR und nDCG

Die Suche lässt sich ohne Sprachmodell messen, wenn zu jeder Frage die erwarteten Fundstellen bekannt sind. Diese Metriken stammen aus dem klassischen Information Retrieval (Manning, Raghavan, Schütze: Evaluation of ranked retrieval results) und sind deterministisch: Derselbe Index liefert bei derselben Frage denselben Wert.

Für RAG ist Recall@k meist die wichtigste Zahl, weil das Modell nur sehen kann, was im Kontext landet. k entspricht dabei der Zahl der Abschnitte, die tatsächlich an das Modell gehen, nicht der Zahl der Kandidaten vor dem Reranking. Wer einen Reranker einsetzt, misst am besten beide Stufen: Recall der Kandidatenliste (findet die Suche den Beleg überhaupt?) und Recall nach dem Reranking (landet er unter den übergebenen Abschnitten?).

MRR eignet sich für Fragen mit genau einer richtigen Quelle, etwa bei exakten Kennungen. nDCG lohnt sich, wenn der Fachbereich Fundstellen abgestuft bewertet, zum Beispiel „beantwortet die Frage" gegenüber „liefert Hintergrund".

Eine Voraussetzung wird oft übersehen: Die erwarteten Fundstellen brauchen stabile IDs. Wird bei einer Änderung des Chunkings neu zerteilt, ändern sich Chunk-IDs, und die Referenz passt nicht mehr. Robuster ist es, Fundstellen auf Dokument- und Abschnittsebene zu hinterlegen und einen Treffer als richtig zu werten, wenn er aus dem erwarteten Abschnitt stammt.

Antwortmetriken in Ragas

Ragas ist eine Open-Source-Bibliothek unter Apache-2.0-Lizenz, die auf das Paper Ragas: Automated Evaluation of Retrieval Augmented Generation zurückgeht. Die aktuelle Version auf PyPI ist 0.4.3 (Stand September 2026). Die RAG-Metriken führt die Dokumentation unter Available Metrics. Die gebräuchlichsten:

Alle Werte liegen zwischen 0 und 1. Drei Punkte sind für die Interpretation entscheidend:

Faithfulness misst Belegtreue, nicht Richtigkeit. Ein Wert von 1,0 heißt, dass jede Aussage aus dem Kontext ableitbar ist. Stammt der Kontext aus einer veralteten Fassung, ist die Antwort belegt und trotzdem falsch. Faithfulness gehört deshalb immer mit Context Recall zusammen gelesen. Als Alternative zum LLM-Urteil bietet Ragas die Variante FaithfulnesswithHHEM, die mit Vectaras Klassifikationsmodell HHEM-2.1-Open arbeitet.

Answer Relevancy misst keine Richtigkeit. Die Dokumentation sagt das ausdrücklich: Die Metrik bewertet, wie gut die Antwort zur Absicht der Frage passt, ohne die sachliche Richtigkeit zu prüfen. Sie bestraft ausweichende und aufgeblähte Antworten, belohnt aber auch eine flüssige Falschaussage. Die aktuelle API führt sie als AnswerRelevancy unter ragas.metrics.collections, die ältere, als veraltet markierte API als ResponseRelevancy.

Context Precision und Context Recall gibt es mit und ohne LLM. Die ID-basierten Varianten vergleichen retrieved_context_ids mit reference_context_ids und entsprechen damit im Kern Precision und Recall aus dem vorherigen Abschnitt. Wer erwartete Fundstellen im Testset pflegt, kann diese Varianten deterministisch und ohne Modellkosten rechnen und die LLM-Varianten für Fälle reservieren, in denen keine IDs vorliegen.

LLM-as-a-Judge mit lokalem Modell

Faithfulness, Answer Relevancy und die LLM-Varianten der Kontextmetriken lassen ein Sprachmodell urteilen. Das skaliert, hat aber bekannte Schwächen. Die Studie Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena von Zheng et al. benennt Positions-, Längen- und Selbstbevorzugungs-Bias sowie begrenztes Schlussfolgern und fand für GPT-4 als Bewerter eine Übereinstimmung mit menschlichen Präferenzen von über 80 Prozent, etwa auf dem Niveau zwischen zwei Menschen. Über 80 Prozent heißt im Umkehrschluss: Ein relevanter Teil der Urteile weicht ab.

Für den Betrieb auf eigener Infrastruktur folgen daraus fünf Regeln:

1. Das Bewertungsmodell ist austauschbar. Die Beispiele der Ragas-Dokumentation nutzen OpenAI-Modelle, das Judge-Modell kann aber ein lokal betriebenes Modell hinter einem OpenAI-kompatiblen Endpunkt sein, etwa mit vLLM oder Ollama. So verlassen Testfragen und Dokumentauszüge die eigene Umgebung auch bei der Bewertung nicht.
2. Judge und Generator trennen. Bewertet ein Modell die eigenen Antworten, wirkt der Selbstbevorzugungs-Bias. Ein anderes, möglichst stärkeres Modell als Judge verringert das.
3. Prompts an Deutsch anpassen. Ragas passt Metriken über adapt() an eine Zielsprache an. Standardmäßig werden nur die Few-Shot-Beispiele übersetzt, die Anweisungen bleiben englisch; mit adapt_instruction=True werden auch sie übersetzt (Adapting Metrics to Target Language). Die angepassten Prompts sollten gespeichert und versioniert werden, damit Messungen vergleichbar bleiben.
4. Strukturierte Ausgabe prüfen. Langfuse verlangt für LLM-as-a-Judge über ein eigenes Gateway, dass der Endpunkt Tool Calling im OpenAI-Format unterstützt (LLM Connections). Kleine lokale Modelle scheitern hier eher als an der eigentlichen Bewertung.
5. Den Judge kalibrieren. Eine Stichprobe von Urteilen wird von Fachleuten gegengeprüft, bevor automatische Werte als Abnahmekriterium dienen. Weicht der Judge in einer Kategorie systematisch ab, zählt dort das menschliche Urteil.

Automatische Bewertung ist ein Werkzeug, um viele Durchläufe vergleichbar zu machen. Sie ersetzt nicht die fachliche Abnahme durch Menschen, die den Bestand kennen.

Abnahmekriterien festlegen

Eine Abnahme braucht Kriterien, die vor der Messung vereinbart sind. Bewährt hat sich eine Trennung in blockierende Fälle, die ausnahmslos bestehen müssen, und Durchschnittswerte, die eine Schwelle erreichen müssen.

Konkrete Grenzwerte hängen vom Risiko des Einsatzes und der Vielfalt der Fragen ab. Ein Assistent für interne Richtlinien verträgt andere Schwellen als ein System, dessen Antworten an Kunden oder in Verwaltungsentscheidungen gehen. Universelle Zahlen wie „Faithfulness über 0,9" sind ohne Bezug zum eigenen Testset nicht aussagekräftig.

Praktisch bewährt sich eine Baseline: Die erste Messung mit einer einfachen Konfiguration legt den Ausgangswert fest, jede Optimierung wird daran gemessen. So wird sichtbar, ob Hybrid Search, ein Reranker oder ein anderes Chunking tatsächlich etwas bringen. Die Auswertung sollte je Fragetyp erfolgen; ein guter Gesamtwert kann eine Kategorie verdecken, in der das System zuverlässig scheitert.

Für Systeme, die unter die KI-Verordnung fallen können, sind dokumentierte Tests und Protokolle ohnehin gefordert. Einordnung dazu im Beitrag RAG und KI-Verordnung.

Regressionstests bei Änderungen an Modell, Index und Prompt

Ein RAG-System ändert sich laufend, und fast jede Änderung kann die Qualität verschieben. Das Testset wird deshalb nach der Abnahme nicht archiviert, sondern zum Regressionstest.

Der häufigste Auslöser für unbemerkte Qualitätsverluste ist ein Wechsel des Embedding-Modells, weil er den gesamten Index betrifft. Welche Modelle für deutsche Texte in Frage kommen, vergleicht der Beitrag zu Embedding-Modellen für Deutsch.

Umsetzung mit Langfuse. Langfuse bildet ein Testset als Dataset ab: Jeder Eintrag hat input, optional expected_output und metadata. Jede Änderung an den Einträgen erzeugt eine neue Dataset-Version, sodass ein Experiment später gegen genau den damaligen Stand wiederholt werden kann. Mit run_experiment() aus dem SDK läuft die eigene Anwendung gegen das Dataset; Evaluatoren auf Eintragsebene schreiben Scores an die Traces, Evaluatoren auf Laufebene berechnen Gesamtwerte (Experiments via SDK). Die Läufe erscheinen als Dataset Runs und lassen sich in der Oberfläche vergleichen.

Für die Pipeline beschreibt Langfuse zwei Freigaberegeln (Experiments in CI/CD): Entweder muss jeder Pflichtfall eine absolute Qualitätsschwelle erreichen, oder kein Fall, der in der freigegebenen Baseline bestanden hat, darf zurückfallen. Wird die Regel verletzt, bricht der Build ab. Ragas-Metriken lassen sich dabei als Evaluatoren einbinden oder als Scores an Traces schreiben (Cookbook: RAG mit Ragas evaluieren). Wie Langfuse selbst betrieben wird, beschreiben Was ist Langfuse? und der Beitrag zu Langfuse self-hosted.

Evaluation im laufenden Betrieb

Das Testset prüft bekannte Fragen. Im Betrieb kommen unbekannte hinzu, und die Messung muss sie erfassen.

• Online-Bewertung. Langfuse kann LLM-as-a-Judge-Evaluatoren auf einzelne Beobachtungen im Live-Betrieb anwenden, etwa auf den Retrieval-Schritt oder die Antwort, und ebenso auf Experimente (LLM-as-a-Judge). Das liefert Trends, keine Einzelurteile mit Abnahmequalität.
• Menschliche Prüfung. Annotation Queues verteilen ausgewählte Traces an Fachleute zur Bewertung. Sinnvoll sind Stichproben plus alle Fälle mit negativem Nutzerfeedback oder niedrigem Judge-Score.
• Rückfluss ins Testset. Jede echte Frage, die schiefgegangen ist, wird nach Klärung als neuer Eintrag ins Dataset übernommen. So wächst das Testset entlang der tatsächlichen Schwachstellen.
• Unbeantwortete Themen auswerten. Fragen, auf die das System korrekt mit „nicht im Bestand" antwortet, zeigen fehlende Dokumente. Diese Liste ist eine Redaktionsaufgabe, kein Fehler des Systems.

Die Funktionen für Datasets, Experimente, LLM-as-a-Judge und Annotation Queues sind in der selbst betriebenen Open-Source-Version von Langfuse enthalten (Self-Hosting Pricing); LLM-as-a-Judge, Annotation Queues, Prompt-Experimente und der Playground wurden am 4. Juni 2025 unter MIT-Lizenz freigegeben (Langfuse Blog).

Typische Messfehler

• Nur die Antwort bewerten. Ohne Retrieval-Metriken bleibt unklar, ob ein Fehler in der Suche oder im Modell liegt.
• Testset aus Dokumenttext statt aus Nutzerfragen. Die Werte steigen, die Praxistauglichkeit nicht.
• Keine unbeantwortbaren Fragen. Dann bleibt unsichtbar, ob das System Wissenslücken benennt oder Antworten erfindet.
• Judge-Werte ohne Kalibrierung. Ein automatischer Score, den nie ein Mensch gegengeprüft hat, ist eine Schätzung.
• Durchschnitt statt Kategorien. Ein Mittelwert von 0,85 kann bedeuten, dass alle Fragen zu exakten Kennungen scheitern.
• Testset ohne Versionsstand. Ändern sich Fragen und System gleichzeitig, sind zwei Messungen nicht vergleichbar.
• Referenz-IDs nach Neuindexierung nicht geprüft. Nach einem Chunking-Wechsel zeigen die erwarteten Fundstellen ins Leere, und Recall fällt scheinbar auf null.

Was das für Ihr Projekt heißt

Die Evaluation beginnt vor der ersten Zeile Code: mit echten Fragen aus dem Fachbereich, erwarteten Fundstellen und einer Absprache, welche Fälle blockieren. Wer das Testset früh aufbaut, kann jede technische Entscheidung an einer Baseline messen, statt nach Eindruck zu optimieren, und hat nach der Abnahme einen Regressionstest für jede spätere Änderung.

Die Grundlagen stehen in Was ist RAG?. Wie die Suche robuster wird, zeigen Hybrid Search und Reranking, Contextual Retrieval und Chunking. Warum Rechte-Tests in jedes Testset gehören, erklärt RAG mit Berechtigungen, und wo Langfuse im Stack sitzt, zeigt Der Open-Source-LLM-Stack.

Quellen

• Ragas, Available Metrics
• Ragas, Faithfulness
• Ragas, Answer Relevancy
• Ragas, Context Precision
• Ragas, Context Recall
• Ragas, Noise Sensitivity
• Ragas, Adapting Metrics to Target Language
• Ragas, Non-English Testset Generation
• Es et al., Ragas: Automated Evaluation of Retrieval Augmented Generation (arXiv 2309.15217)
• Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv 2306.05685)
• Manning, Raghavan, Schütze: Evaluation of ranked retrieval results
• Langfuse, Datasets
• Langfuse, Experiments via SDK
• Langfuse, Experiments in CI/CD
• Langfuse, LLM-as-a-Judge
• Langfuse, LLM Connections
• Langfuse, Annotation Queues
• Langfuse, Cookbook: Evaluation of RAG with Ragas
• Langfuse, Self-Hosting Pricing
• Langfuse, Open-Sourcing Langfuse Product Features (04.06.2025)