RAG-Qualität messen — Evaluation mit RAGAS, TREC und Golden-Sets

RAG-Pipelines wirken in der Demo überzeugend. Eine Frage, eine flüssig formulierte Antwort, drei Quellenangaben — Stakeholder sind zufrieden. Das Problem entsteht später: Nach drei Monaten Produktivbetrieb häufen sich Beschwerden, dass Antworten unvollständig oder schlicht falsch seien. Ohne Mess-Disziplin lässt sich dann nicht mehr rekonstruieren, ob das Embedding-Modell, der neue Chunking-Parameter oder das jüngste LLM-Update die Ursache war. Evaluation ist deshalb keine akademische Übung, sondern eine betriebliche Notwendigkeit.

Warum Gefühl nicht reicht

Drei häufige Fehlannahmen beobachten wir in Mittelstandsprojekten. Erstens: „Unsere Nutzer melden sich, wenn etwas nicht stimmt.“ In Wahrheit melden sich nur wenige Prozent — der Rest gewöhnt sich an mittelmäßige Antworten oder umgeht das System. Zweitens: „Wir prüfen vor jedem Release manuell zehn Beispiele.“ Das deckt grobe Brüche auf, aber keine schleichende Verschlechterung. Drittens: „Das Modell ist neu, also muss es besser sein.“ Jeder erfahrene Betreiber weiß, dass Modell-Updates manchmal regressiv wirken — etwa wenn das neue LLM stärker auf eigene Vortrainingsdaten zurückgreift und den retrievten Kontext ignoriert.

Eine messbare Eval-Pipeline löst diese Probleme. Sie ist günstig (ein paar GPU-Stunden), reproduzierbar und liefert vergleichbare Zahlen über Monate hinweg. Die Vorarbeit — ein gutes Golden-Set — ist überschaubar.

Die fünf Metriken, die zählen

RAGAS hat sich 2025/26 als de-facto Standard für die programmatische Bewertung von RAG-Pipelines etabliert. Das Framework definiert mehrere Metriken, die sich in zwei Gruppen einteilen lassen: Retrieval-Qualität und Generation-Qualität.

Metrik	Was wird gemessen	Ziel	Skala
Context Precision	Anteil der retrievten Chunks, die wirklich relevant sind	Token-Effizienz	0–1
Context Recall	Wurden alle für die Antwort nötigen Chunks gefunden?	Vollständigkeit der Suche	0–1
Faithfulness	Stützt sich die Antwort ausschließlich auf den Kontext?	Halluzinations-Schutz	0–1
Answer Relevancy	Beantwortet die Antwort die gestellte Frage?	Themen-Treffsicherheit	0–1
Response Completeness	Sind alle Aspekte der Frage abgedeckt?	Vollständigkeit der Antwort	0–1

Faustregel für produktive Mittelstands-RAGs: Context Recall > 0.85, Faithfulness > 0.9, Answer Relevancy > 0.85. Werte unterhalb dieser Schwellen sind ein klares Warnsignal — entweder retrieved die Pipeline falsch, oder das LLM ignoriert den Kontext.

Das Golden-Set: 50 bis 200 Q/A-Paare

Ein Golden-Set ist eine kuratierte Sammlung repräsentativer Fragen mit dokumentierter Idealantwort und den Quellen-Chunks, aus denen die Antwort hervorgehen soll. Es ist die teuerste, aber auch wichtigste Investition im gesamten Eval-Prozess. Praxiserprobte Anforderungen:

• Größe: 50 Q/A-Paare als Minimum, 150–200 sind belastbarer und decken Edge-Cases ab.
• Diversität: Mischung aus einfachen Faktenfragen, Mehrfach-Fakten-Aggregationen, Vergleichen, Folgerungen und „Trickfragen“, deren Antwort nicht im Korpus steht.
• Quellenbindung: Pro Frage ein bis fünf konkrete Chunk-IDs, die für die Antwort erforderlich sind.
• Negativbeispiele: Mindestens 10 Prozent „No-Answer“-Fälle, in denen die Pipeline ehrlich „weiß ich nicht“ liefern soll.
• Versionierung: Das Set liegt in Git, Änderungen brauchen Code-Review.

Die Erstellung erfolgt typischerweise in einem zweitägigen Workshop mit den Fachbereichen. Domänen-Experten formulieren Fragen, die sie tatsächlich an das System richten würden — keine theoretischen Konstrukte. Zur Beschleunigung lassen sich Vorschläge synthetisch mit einem starken LLM aus den Quelldokumenten generieren und dann manuell kuratieren. Wichtig: Ungeprüfte synthetische Q/A-Paare sind kein Ersatz für menschliche Qualitätssicherung.

RAGAS-Setup mit lokalem LLM-as-Judge

RAGAS wertet die Metriken mit einem LLM aus, das im Hintergrund Antworten und Kontexte gegeneinander prüft. In On-Prem-Umgebungen wäre es widersinnig, dafür ein Cloud-Modell zu nutzen. Stattdessen kommt der eigene OpenAI-kompatible Endpoint (siehe OpenAI-API selbst hosten) zum Einsatz, idealerweise mit einem stärkeren Judge-Modell als das, das in der Produktions-RAG eingesetzt wird.

from ragas import evaluate
from ragas.metrics import (
    context_precision, context_recall,
    faithfulness, answer_relevancy
)
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = ChatOpenAI(
    model="qwen-2.5-72b",
    base_url="https://api.ki.intern/v1",
    api_key="sk-eval-judge-***",
    temperature=0,
)

result = evaluate(
    dataset=golden_set,
    metrics=[context_precision, context_recall,
             faithfulness, answer_relevancy],
    llm=LangchainLLMWrapper(judge),
)
print(result.to_pandas())

Der gesamte Lauf über 150 Q/A-Paare dauert auf einer einzelnen H100 etwa 15 bis 25 Minuten. Das Ergebnis ist ein DataFrame mit Werten pro Frage und Aggregaten pro Metrik. Diese Werte werden in eine Zeitreihen-Datenbank (Prometheus oder TimescaleDB) geschrieben, sodass Verläufe sichtbar werden.

Retrieval-only vs. End-to-End

Für tiefere Diagnosen lohnt es sich, Retrieval und Generation getrennt zu evaluieren. Retrieval-only-Metriken aus der TREC-Tradition — Recall@k, MRR (Mean Reciprocal Rank) und nDCG — beantworten die Frage: „Würde ein perfektes LLM aus diesem Kontext die richtige Antwort bauen können?“ Wenn Recall@10 unter 0.8 liegt, ist das LLM-Tuning vergeblich; das Problem sitzt in Embedding oder Chunking.

End-to-End-Metriken wie Faithfulness und Answer Relevancy beantworten die zweite Frage: „Macht das LLM aus dem Kontext etwas Gutes?“ Diese Trennung ist entscheidend, weil sie Optimierungsenergie in den richtigen Layer lenkt.

A/B-Tests von Embeddings und Chunking

Mit einem stabilen Golden-Set werden Optimierungsentscheidungen zur Routineübung. Typische A/B-Vergleiche, die sich quantitativ entscheiden lassen:

• Embedding-Modell: BGE-M3 vs. Jina-v3 vs. Nomic-Embed-Text-v2 — welches liefert für Ihre Sprachmischung den höchsten Recall@10?
• Chunk-Größe: 256 vs. 512 vs. 1024 Tokens, jeweils mit 10/20/40 Prozent Overlap.
• Chunking-Strategie: Semantisches Chunking vs. starre Fenster vs. Markdown-strukturiertes Chunking.
• Reranker: BGE-Reranker-v2 ein/aus — wieviel Faithfulness-Gewinn rechtfertigt die zusätzliche Latenz?
• Hybride Suche: Reine Vektor- vs. BM25-+-Vektor-Hybridsuche.

Erfahrungswerte aus deutschen B2B-Korpora: Hybridsuche bringt regelmäßig 5–12 Prozentpunkte Recall, ein guter Reranker zusätzlich 4–8 Punkte Faithfulness. Diese Effekte sind bei reinem Bauchgefühl-Test nicht sicher zu erkennen.

Regression-Tests bei Modell-Updates

Wenn das Generator-LLM von Llama 3.3 auf Llama 4 aktualisiert wird, sollte die Eval-Suite zwingend laufen, bevor die neue Version Produktion sieht. Praktisch hat sich folgendes Vorgehen bewährt:

1. Aktuelle Pipeline mit neuem Modell evaluieren, alte Werte als Baseline.
2. Toleranz-Grenze definieren: typischerweise −2 Prozentpunkte pro Metrik akzeptabel, mehr blockt das Update.
3. Bei Regressionen: stichprobenartig Q/A-Paare manuell prüfen, oft sind es einzelne Aufgabentypen, die schwächer werden.
4. Bei klar bestätigtem Fortschritt: Modell ausrollen, Baseline aktualisieren, Eval-Lauf in der CI dokumentieren.

Das gleiche Vorgehen gilt für Embedding-Updates, Vektor-DB-Versions-Sprünge und größere Änderungen am System-Prompt. Eine kleine, laufende Investition in den Eval-Workflow erspart in der Praxis erhebliche Diskussionen mit Fachbereichen und Compliance — denn jede Aussage „die Qualität ist gleich/besser“ ist mit Zahlen belegbar.

Integration in CI/CD

Im Idealfall ist die Eval-Suite Teil der Continuous-Integration-Pipeline. Bei jedem Pull-Request, der RAG-Komponenten verändert, läuft automatisch ein verkleinertes Eval-Set (etwa 30 Q/A-Paare) und postet Ergebnisse als PR-Kommentar. Vollständige Läufe finden nächtlich statt, Resultate landen in einem Grafana-Dashboard mit Trend-Linien über drei Monate. Damit wird Qualität von einem Bauchgefühl zu einer harten Kennzahl, die im Lenkungsausschuss berichtbar ist.

Häufige Fragen