RAG-Evaluation ist die systematische, messbare Qualitätsprüfung eines Retrieval-Augmented-Generation-Systems. Sie beantwortet zwei getrennte Fragen: Findet das Retrieval die richtigen Dokumente, und beruht die generierte Antwort treu auf genau diesen Dokumenten? Ohne diese Trennung bleibt unklar, ob eine schlechte Antwort vom Retrieval oder vom Sprachmodell kommt. Frameworks wie RAGAS, TruLens, DeepEval und LangSmith automatisieren diese Messung mit standardisierten Metriken.

• Was wird gemessen? Vier Kernmetriken: Faithfulness/Groundedness, Answer Relevance, Context Precision und Context Recall.
• Womit? RAGAS (De-facto-Standard), TruLens (RAG-Triade), DeepEval (Pytest-Stil), LangSmith (Tracing + Dataset-Eval) sowie Arize Phoenix (OSS-Tracing).
• Warum? Ohne Evaluation entsteht stille Qualitätsregression: Ein Pipeline-Change verschlechtert die Antworten, ohne dass es jemand bemerkt, bis sich Nutzer beschweren.

Warum RAG zwei Fehlerquellen hat

Ein RAG-System kann auf zwei voneinander unabhängige Arten versagen. Erstens kann das Retrieval die falschen oder unvollständigen Kontexte liefern, dann hat das Modell gar keine Chance auf eine korrekte Antwort. Zweitens kann das Modell trotz korrektem Kontext halluzinieren, also Aussagen treffen, die im abgerufenen Material nicht stehen. Dieses zweite Phänomen heißt context-unfaithful generation: Das Modell zitiert Quellen, weicht inhaltlich aber davon ab.

Genau deshalb reicht eine einzige Gesamtnote nicht. RAG-Evaluation zerlegt die Qualität in eine Retrieval-Achse und eine Generierungs-Achse. Erst diese Trennung macht Debugging möglich: Sinkt Context Recall, optimiert man Chunking, Embeddings oder Hybrid Search. Sinkt Faithfulness bei gutem Kontext, optimiert man Prompt, Citation-Forcing oder Guardrails.

Die vier zentralen RAG-Metriken

RAGAS misst RAG-Qualität entlang von Faithfulness, Answer Relevancy, Context Precision und Context Recall. Diese vier Begriffe sind das gemeinsame Vokabular der gesamten Branche, auch wenn einzelne Tools sie anders benennen.

Faithfulness / Groundedness (Generierungs-Achse)

Misst, ob jede einzelne Aussage der Antwort durch den abgerufenen Kontext gedeckt ist. Ein LLM-as-Judge zerlegt die Antwort in atomare Behauptungen und prüft jede gegen den Kontext. Der Wert ist der Anteil belegter Behauptungen. Niedrige Faithfulness bedeutet Halluzination trotz RAG, die häufigste Vertrauensfalle in produktiven Systemen.

Answer Relevance (Generierungs-Achse)

Misst, ob die Antwort die gestellte Frage tatsächlich beantwortet und nicht abschweift oder unvollständig bleibt. Eine Antwort kann faithful, aber irrelevant sein, etwa wenn sie korrekt einen Nebenaspekt referiert, die Kernfrage aber nicht trifft. Beide Metriken müssen daher immer gemeinsam betrachtet werden.

Context Precision (Retrieval-Achse)

Misst, ob die relevanten Chunks in den oberen Rängen der Retrieval-Ergebnisse stehen. Hohe Precision heißt: wenig Rauschen, die wichtigen Passagen kommen zuerst. Das ist entscheidend, weil zu viel irrelevanter Kontext zum Lost-in-the-middle-Effekt führt und die Generierungsqualität senkt.

Context Recall (Retrieval-Achse)

Misst, ob alle für die Idealantwort nötigen Informationen überhaupt abgerufen wurden. Recall benötigt eine Referenzantwort (Ground Truth), gegen die geprüft wird, ob jede nötige Information in den abgerufenen Kontexten vorhanden war. Niedriger Recall ist ein klassisches Symptom für schlechtes Chunking oder ein für die Sprache ungeeignetes Embedding-Modell.

Ergänzend bieten die Frameworks weitere Metriken wie Answer Correctness, Noise Sensitivity (RAGAS) oder Hallucination (DeepEval).

RAG-Evaluations-Tools im Vergleich

Die folgenden Frameworks sind 2026 die etablierten Werkzeuge. Alle arbeiten überwiegend nach dem LLM-as-Judge-Prinzip, ein zweites Modell bewertet also die Ausgabe.

Hinweis Stand 2026: Versions- und Metrik-Bezeichnungen entwickeln sich schnell weiter. Die hier genannten RAGAS-Metriken beziehen sich auf die Dokumentation der Version v0.1.21; vor produktivem Einsatz die aktuelle Doku des jeweiligen Tools prüfen.

Einen Eval-Datensatz (Goldset) aufbauen

Jede belastbare Evaluation braucht ein Goldset, also einen kuratierten Datensatz aus repräsentativen Fragen. Ein Eintrag besteht typischerweise aus vier Feldern:

• question: eine reale oder realistische Nutzerfrage
• ground_truth: die ideale, faktisch korrekte Antwort
• reference_contexts (optional): die Chunks, die die Antwort belegen
• metadata (optional): Tenant, Quelle, Schwierigkeitsgrad

Vorgehen in der Praxis:

1. Manuell kuratieren: 30 bis 100 echte Fragen aus Support-Logs, Vertriebsanfragen oder Fachabteilungen sammeln und mit Expertenantworten versehen. Qualität schlägt Quantität.
2. Synthetisch ergänzen: RAGAS und DeepEval bieten Test-Set-Generatoren, die aus dem eigenen Dokumentenkorpus automatisch Frage-Antwort-Paare erzeugen. Diese unbedingt stichprobenartig manuell prüfen.
3. Edge Cases einplanen: Fragen, deren Antwort gar nicht im Korpus steht (das System soll dann „weiß ich nicht" antworten), sowie Fragen nach exakten Codes oder IDs, die reine Embeddings oft verfehlen.
4. Versionieren: Das Goldset gehört ins Repository. Jede Änderung wird nachvollziehbar, und Eval-Ergebnisse bleiben über die Zeit vergleichbar.

Wo ein vollständiges Goldset fehlt, lassen sich reference-free-Metriken (Faithfulness, Answer Relevancy) plus implizite Signale (Klicks, Daumen hoch/runter) als Übergangslösung nutzen.

Konkretes Beispiel: Eval im Entwicklungs-Loop

Ein DACH-Mittelständler betreibt einen internen RAG-Assistenten auf der technischen Dokumentation. Das Goldset umfasst 60 Fragen. Die Evaluation läuft bei jedem Pull Request automatisch (Pseudocode):

```
goldset = load("eval/goldset_v3.json") # 60 Eintraege
results = ragas.evaluate(
dataset = goldset,
metrics = [faithfulness, answer_relevancy,
context_precision, context_recall]
)

assert results["faithfulness"] >= 0.90
assert results["context_recall"] >= 0.80
assert results["answer_relevancy"] >= 0.85

Build bricht, wenn ein Schwellenwert unterschritten wird

```

Im Ausgangszustand liefert die Pipeline Faithfulness 0,88 und Context Recall 0,71. Ein Entwickler ergänzt einen Cross-Encoder-Reranker und Contextual-Header pro Chunk. Anthropic beziffert den Effekt von Contextual Retrieval auf eine Reduktion der Retrieval-Fehlerrate um 49 Prozent, in Kombination mit Reranking um 67 Prozent (Anthropic, Stand 09/2024). Im Goldset steigt Context Recall daraufhin auf 0,86 und Faithfulness auf 0,93, alle Schwellenwerte sind erfüllt, der Build geht durch.

Drei Wochen später senkt jemand testweise top_k von 8 auf 3. Faithfulness bleibt stabil, aber Context Recall fällt auf 0,74. Der automatisierte Eval-Lauf blockiert den Merge, bevor die Verschlechterung jemals einen Nutzer erreicht. Genau das ist der Sinn von Evaluation in der CI: stille Qualitätsregression sichtbar machen (Anti-Pattern AP5: Deployment ohne Faithfulness-Messung).

Faithfulness als Guardrail zur Laufzeit

Evaluation endet nicht beim Deployment. Dieselbe Faithfulness-Messung lässt sich als Laufzeit-Guardrail einsetzen: Liegt der Faithfulness-Score einer konkreten Antwort unter einem Schwellenwert, verweigert das System die Antwort oder eskaliert an einen Menschen, statt eine möglicherweise halluzinierte Auskunft auszuliefern. Kombiniert mit Citation-Forcing (jede Aussage muss eine Chunk-Quelle nennen) entsteht so eine doppelte Absicherung gegen Halluzinationen, die in regulierten Branchen Pflicht ist.

Für Agenturen und B2B

Für Marketing-Agenturen und B2B-Entscheider ist RAG-Evaluation der Unterschied zwischen einer demotauglichen Spielerei und einem produktionsreifen Wissenssystem. Wer einem Kunden einen RAG-Assistenten verkauft, sollte Qualität in Zahlen belegen können, nicht in Anekdoten. Ein dokumentiertes Goldset plus CI-Gate aus Faithfulness und Context Recall ist ein konkretes, prüfbares Qualitätsversprechen und zugleich ein Differenzierungsmerkmal im Pitch. Blck Alpaca aus Wien begleitet DACH-Unternehmen beim Aufbau evaluierbarer RAG-Pipelines, von der Goldset-Kuratierung über die Tool-Auswahl bis zur Integration der Evaluation in den Entwicklungs-Loop. Sprechen Sie uns an, wenn Sie Ihr RAG-System messbar machen wollen.