Bei einem Kunden aus der Energiebranche haben wir RAG über technische Normen und Betriebsrichtlinien eingesetzt. Nach den ersten zwei Produktionswochen meldeten Operatoren, das System antworte „manchmal richtig, manchmal nicht". Bei näherer Betrachtung zeigten sich zwei völlig unterschiedliche Ursachen: In einigen Fällen hatte das Retrieval die falschen Dokumente geladen — die richtige Antwort war in der Knowledge Base vorhanden, das System fand sie aber nicht. In anderen Fällen funktionierte das Retrieval einwandfrei, das generative Modell ignorierte jedoch den geladenen Kontext und halluzinierte eine eigene Antwort. Aus Benutzerperspektive sahen beide Fehler identisch aus. Ohne Metriken konnten wir sie nicht unterscheiden.
Das ist der Kern des Problems bei der Evaluierung von RAG-Systemen: Retrieval und Generation sind zwei eigenständige Komponenten, die jeweils aus unterschiedlichen Gründen versagen können. Messen Sie beide zusammen, verlieren Sie die Fähigkeit zur Diagnose. Dieser Artikel beschreibt, wie man es besser macht — getrennt, systematisch, mit den dafür verfügbaren Werkzeugen.
Warum klassische Metriken nicht ausreichen
Der erste Impuls bei der Bewertung eines RAG-Systems lautet: „Ist die Antwort richtig?" — und das entweder manuell oder durch einfachen Abgleich mit einer erwarteten Ausgabe zu messen. Dieser Ansatz hat einen grundlegenden Fehler: Er sagt nicht, *wo* die Pipeline versagt hat.
Stellen Sie sich drei Szenarien vor:
- Retrieval hat das richtige Dokument geladen, das Modell hat daraus korrekt geantwortet — gutes Ergebnis.
- Retrieval hat ein falsches Dokument geladen, das Modell hat konsistent daraus geantwortet — schlechtes Ergebnis, aber Faithfulness ist hoch (das Modell halluzinierte nicht, hatte nur den falschen Kontext).
- Retrieval hat das richtige Dokument geladen, das Modell ignorierte es und halluzinierte — schlechtes Ergebnis, Faithfulness ist niedrig.
Drei verschiedene Szenarien, zwei verschiedene Fehlerquellen, ein gemeinsames Symptom: die falsche Antwort. Wenn Sie nur das Endergebnis messen, korrigieren Sie vielleicht das Retrieval und stellen dann fest, dass die Generation immer noch halluziniert — oder umgekehrt.
Deshalb teilt moderne RAG-Evaluierung die Messung in zwei Schichten auf: Retrieval-Metriken (Context Precision, Context Recall) und Generation-Metriken (Faithfulness, Answer Relevancy). Genau das ist die Philosophie hinter dem Tool RAGAS.
RAGAS — was es ist und was es nicht ist
RAGAS (Retrieval-Augmented Generation Assessment) ist ein Open-Source-Evaluierungsframework, das die Qualität einer RAG-Pipeline misst, ohne für jeden Fall manuelle Annotationen zu benötigen. Stattdessen nutzt es den LLM-as-Judge-Ansatz: Aussagen oder Behauptungen werden von einem weiteren Sprachmodell bewertet.
Was RAGAS ist: ein Framework zur Offline-Evaluierung von RAG-Pipelines anhand eines Gold-Standard-Datensatzes (Golden Set). Sie übergeben Fragen, Referenzantworten, die von Ihrem Retrieval geladenen Kontexte und die generierten Antworten — und erhalten vier Schlüsselmetriken.
Was RAGAS nicht ist: kein Produktions-Monitoring in Echtzeit, kein Ersatz für die vollständige Evaluierung einer LLM-Anwendung, kein Werkzeug zur Messung der faktischen Korrektheit der Knowledge Base selbst. Wenn Ihre Dokumente falsche Informationen enthalten, erkennt RAGAS das nicht — es misst Konsistenz und Relevanz, nicht die Wahrheit der Quellen.
Eine wichtige Abgrenzung gegenüber anderen Evaluierungstypen: RAGAS konzentriert sich ausschließlich auf die RAG-Komponente. Wenn Sie die Qualität einer LLM-Antwort unabhängig vom Retrieval messen oder ein feinabgestimmtes Modell bewerten wollen, verwenden Sie andere Metriken — diese gehören in einen eigenständigen Eval-Bereich. Ebenso ist die Fine-Tuning-Eval (zum Beispiel die Messung, ob Fine-Tuning geholfen hat) eine andere Disziplin als die RAG-Eval.
Die vier Schlüsselmetriken von RAGAS
Context Precision
Context Precision misst, ob die Dokumente, die das Retrieval zurückgegeben hat, tatsächlich relevant für die gestellte Frage sind. Konkret: Welcher Anteil des geladenen Kontexts ist nützlich, um die richtige Antwort zu generieren?
Hohe Context Precision bedeutet, dass das Retrieval keinen Rausch zurückgibt — jeder geladene Chunk trägt zur Antwort bei. Niedrige Context Precision signalisiert, dass das System zu viele irrelevante Dokumente lädt, was die Qualität der Generation verschlechtert (das LLM muss sich gleichzeitig durch relevantes und irrelevantes Material navigieren).
In der Praxis: Bei niedriger Context Precision liegt das Problem typischerweise im Embedding-Modell, bei fehlerhafter Dokumentsegmentierung (Chunking) oder in der Top-K-Einstellung (zu viele Dokumente werden geladen). Mehr zur Auswahl und Konfiguration von Retrieval-Komponenten finden Sie im Artikel über Hybrid Search.
Context Recall
Context Recall ist die komplementäre Metrik: Welcher Anteil der Informationen, die für die richtige Antwort nötig sind, befindet sich im geladenen Kontext? Gemessen wird gegen die Referenzantwort aus dem Golden Set.
Ist Context Recall niedrig, verfehlt das Retrieval relevante Dokumente — die Information ist in der Knowledge Base vorhanden, das System findet sie aber nicht. Typische Ursachen: unzureichende Qualität des Embedding-Modells für die jeweilige Sprache oder Domäne, schlechtes Chunking (die Information ist über mehrere Fragmente verteilt, von denen keines allein ausreicht) oder ein zu kleines K (Sie laden zum Beispiel nur die Top-3, das relevante Dokument landete aber auf Rang 7).
Faithfulness
Faithfulness misst, inwieweit die generierte Antwort durch den geladenen Kontext belegt ist. RAGAS zerlegt dazu die Antwort in einzelne Behauptungen und überprüft für jede, ob sie explizit oder implizit im Kontext verankert ist.
Das ist die wichtigste Metrik aus Sicht der Vertrauenswürdigkeit eines RAG-Systems. Niedrige Faithfulness bedeutet, dass das Modell halluziniert — es generiert Informationen, die im geladenen Kontext nicht vorhanden sind, aber plausibel klingen. Es ist entscheidend zu verstehen: Faithfulness ≠ faktische Korrektheit. Ein Modell kann perfekt faithful sein (100 % der Antwort ist kontextbelegt), aber der Kontext selbst kann falsch sein. Wer faktische Genauigkeit messen will, muss die Qualität der Knowledge Base separat behandeln.
Niedrige Faithfulness wird typischerweise auf Ebene des System-Prompts behoben (Anweisung, ausschließlich aus dem Kontext zu antworten), durch Modellauswahl (manche Modelle folgen Anweisungen konsistenter) oder durch eine Guardrails-Schicht. Mehr über Guardrails für KI-Agenten, einschließlich Faithful-Answer-Checks, finden Sie im Artikel über Guardrails für KI-Agenten.
Answer Relevancy
Answer Relevancy bewertet, ob die Antwort tatsächlich auf die gestellte Frage eingeht. RAGAS misst das, indem es aus der generierten Antwort mehrere hypothetische Fragen zurückgeneriert und prüft, ob diese der ursprünglichen Anfrage ähneln.
Niedrige Answer Relevancy kann auch bei hoher Faithfulness auftreten: Das Modell kann dem Kontext treu sein, aber auf eine andere Frage antworten als gestellt wurde — typischerweise wenn der Kontext vage ist oder der System-Prompt nicht direkt genug formuliert ist. In der Praxis deckt diese Metrik Probleme mit dem Prompting und der Frageformulierung auf.
Golden Set — die Basis jeder Evaluierung
RAGAS-Metriken sind nur so gut wie der Datensatz, auf dem sie berechnet werden. Der Gold-Standard (Golden Set) ist eine Sammlung von Testfällen im Format:
- Frage — eine reale oder repräsentative Anfrage
- Referenzantwort — eine verifizierte korrekte Antwort (Ground Truth)
- Geladener Kontext — die von Ihrem Retrieval zurückgegebenen Dokumente für die jeweilige Anfrage
- Generierte Antwort — die Ausgabe Ihres RAG-Systems
Das Problem: Der Aufbau eines Golden Sets ist aufwändig — typischerweise 100–300 Fälle für eine grundlegende Evaluierung, 500–1 000 für eine robustere. Das manuelle Erstellen jedes Falls durch einen Domänenexperten ist langsam und teuer.
Hier kommen zwei Strategien ins Spiel:
Synthetische Generierung des Golden Sets: RAGAS und andere Tools enthalten Funktionen zur automatischen Generierung von Testfragen direkt aus Ihren Dokumenten. Ein LLM liest einen Fragment, generiert eine Frage und eine Referenzantwort. Vorteil: Geschwindigkeit und Skalierbarkeit. Nachteil: Synthetische Fragen können zu einfach sein oder nicht den realen Anfragen der Benutzer entsprechen. In der Praxis empfehlen wir eine Mischung: 60–70 % synthetische Fälle als Basis, 30–40 % reale Anfragen aus Produktionslogs, annotiert von einem Experten.
Mining aus Produktionslogs: Wenn das RAG-System in der Produktion läuft, loggen Sie Paare (Frage, Antwort). Die Auswahl repräsentativer Fälle, annotiert mit User-Feedback (Daumen hoch/runter) oder durch einen Domänenexperten, ergibt ein realistisches Golden Set, das tatsächlichem Verwendungsverhalten entspricht.
Ein wichtiges Prinzip: Das Golden Set muss lebendig gehalten werden. Wenn sich die Knowledge Base aktualisiert, werden Teile der Testfälle veraltet. Bei größeren Dokumentationsaktualisierungen prüfen Sie immer, ob das Golden Set noch den aktuellen Stand widerspiegelt.
RAGAS in der Praxis — Integration in die Pipeline
RAGAS ist eine Python-Bibliothek, die sich einfach in einen bestehenden RAG-Workflow integrieren lässt. Der grundlegende Anwendungsfall sieht so aus: Für jeden Testfall aus dem Golden Set rufen Sie die Evaluierung mit Frage, Referenzantwort, geladenem Kontext und generierter Antwort auf. Das Ergebnis sind Scores für jede Metrik, sowohl aggregiert als auch pro Fall.
Was Sie vor dem Einsatz wissen sollten:
Kosten: RAGAS ruft intern ein LLM zur Berechnung der Metriken auf (LLM-as-Judge). Für ein Golden Set mit 200 Fällen können Sie Hunderte bis Tausende von LLM-Aufrufen erwarten, was bei Frontier-Modellen erhebliche Kosten verursacht. In der Praxis empfiehlt es sich, ein kleineres, günstigeres Modell für die Judge-Funktion zu verwenden (etwa Haiku/Flash-Tier) oder wo möglich ein lokales Open-Weight-Modell. Die Faithfulness-Berechnung ist besonders token-intensiv, da die Antwort in einzelne Behauptungen zerlegt wird.
Regelmäßige Evaluierung, nicht nur ad-hoc: Evaluierung macht als kontinuierlicher Prozess Sinn — bei jeder Änderung der Retrieval-Komponente, Aktualisierung der Knowledge Base oder Anpassung von Prompts. Wir empfehlen, RAGAS-Evaluierung in die CI/CD-Pipeline einzubinden — zumindest als Sanity-Check auf einem Subset des Golden Sets vor jedem Deployment.
Interpretation absoluter Zahlen: Ein Faithfulness-Score von 0,80 ist objektiv weder gut noch schlecht — er hängt vom Use-Case ab. Für medizinische Dokumentation ist 0,80 unzureichend. Für einen internen Helpdesk kann es ausreichend sein. Wichtiger sind Trends: Wenn nach einer Prompt-Anpassung die Faithfulness von 0,85 auf 0,72 gesunken ist, haben Sie ein klares Signal.
Retrieval-Eval von Generation-Eval trennen
Eine Schlüsselpraxis, die wir zu wenig genutzt sehen: Eval der Retrieval-Komponente und Eval der Generation-Komponente sollten auch unabhängig voneinander durchgeführt werden, nicht nur als RAGAS-End-to-End.
Retrieval-Eval separat: Sie können das Retrieval ohne jegliche LLM-Generation bewerten. Für jede Testfrage wissen Sie, welche Dokumente das Retrieval idealerweise finden sollte (aus dem Golden Set). Sie messen Precision@K und Recall@K — wie viele der relevanten Dokumente sind in den Top-K-Ergebnissen gelandet. Das gibt Ihnen ein sauberes Signal über die Qualität des Embedding-Modells, der Indexierungsstrategie und der Suchkonfiguration — ohne dass das generative Modell Probleme verdeckt oder Retrieval-Fehler kompensiert.
Generation-Eval separat: Sie können den Kontext fixieren — statt dynamisch geladener Dokumente geben Sie dem Modell immer denselben, manuell verifizierten Kontext — und messen ausschließlich Faithfulness und Answer Relevancy. Das testet isoliert die Fähigkeit des Modells, Anweisungen zu folgen und Informationen aus dem bereitgestellten Text zu extrahieren.
Die Kombination beider Perspektiven mit End-to-End-RAGAS-Metriken ergibt ein vollständiges Bild davon, wo genau die Pipeline an Qualität verliert.
Was RAGAS nicht misst — und worauf Sie achten müssen
RAGAS ist ein leistungsstarkes Werkzeug, hat aber Grenzen, die explizit bekannt sein müssen.
Faktische Korrektheit der Knowledge Base: Wie erwähnt misst RAGAS die Konsistenz der Antwort mit dem Kontext. Wenn Dokumente in der Knowledge Base veraltete oder falsche Informationen enthalten, deckt RAGAS das nicht auf. Die Qualität der Knowledge Base müssen Sie separat sicherstellen — durch Domänen-Review, Dokumentendatierung und Update-Mechanismen.
Latenz und Kosten in der Produktion: RAGAS ist ein Offline-Evaluierungstool. Es sagt Ihnen nicht, wie sich die Pipeline bei hohem Anfragevolumen verhält, wie hoch die tatsächliche Latenz für Benutzer ist oder wie hoch die Produktions-Token-Kosten sind. Für diese Metriken benötigen Sie Produktions-Monitoring — Tools wie LangSmith, Langfuse oder eine eigene Logging-Schicht. Über die Observability von KI-Agenten und Produktions-Monitoring schreiben wir ausführlicher im Artikel über Observability von KI-Agenten.
Sicherheitseigenschaften: RAGAS misst nicht die Robustheit gegenüber Prompt Injection, die Fähigkeit des Systems, unangemessene Anfragen abzulehnen, oder die Einhaltung von Sicherheits-Guardrails. Das gehört zur Security-Eval, die eine eigene Disziplin ist.
Sprachqualität und Register: Wenn Ihre Benutzer auf Deutsch kommunizieren und die Knowledge Base auf Englisch ist, sagt Ihnen der RAGAS-Score nichts über die Qualität der Übersetzung oder die Natürlichkeit der deutschen Antworten. Wenn Sie mit einem mehrsprachigen Setup arbeiten, benötigen Sie menschliche Evaluierung der Sprachqualität.
Häufige Fragen
Wie viele Fälle brauche ich im Golden Set für verlässliche Ergebnisse?
Für einen ersten Baseline reichen 50–100 Fälle, um eine Orientierung zu erhalten. Für Entscheidungen wie „Embedding-Modell wechseln" oder „Chunking-Strategie anpassen" empfehlen wir 200–400 Fälle, die verschiedene Fragetypen und Teile der Knowledge Base abdecken. Unter 50 Fällen sind die Ergebnisse zu anfällig für individuelle Ausreißer.
Kann ich RAGAS für Echtzeit-Produktions-Monitoring einsetzen?
Nicht direkt — jede RAGAS-Messung kostet LLM-Aufrufe, was für jede Produktionsanfrage zu teuer ist. Der typische Ansatz ist Sampling: Statt jede Anfrage zu messen, nehmen Sie eine zufällige Stichprobe von 1–5 %, führen die RAGAS-Evaluierung asynchron durch und beobachten Trends über die Zeit. Für Echtzeit-Produktions-Monitoring eignen sich einfachere Signale besser: Daumen-hoch/runter-Feedback der Benutzer, Latenz, Anzahl der Fallback-Antworten.
Wie erkenne ich, ob das Problem im Retrieval oder in der Generation liegt?
Der einfachste Test: Kopieren Sie manuell das relevante Dokument direkt in den Kontext (umgehen Sie das Retrieval) und senden Sie es ans Modell. Wenn die Antwort gut ist, liegt das Problem im Retrieval. Wenn das Modell auch mit perfektem Kontext halluziniert oder irrelevant antwortet, liegt das Problem in der Generation-Schicht — im Prompt, im Modell oder in der Art, wie Sie den Kontext formatieren. Dieser manuelle Test ist schneller als eine vollständige Eval und deckt die meisten Probleme in Minuten auf.
Ist LLM-as-Judge zuverlässig? Kann er falsch bewerten?
LLM-as-Judge hat eigene blinde Flecken — zum Beispiel bewertet er längere Antworten höher, auch wenn sie weniger präzise sind, oder bevorzugt Stile, die den Trainingsdaten des Judge-Modells ähneln. RAGAS kompensiert das teilweise, indem es Faithfulness in einzelne Behauptungen zerlegt und jede separat überprüft. Für kritische Use-Cases (regulierte Branchen, sicherheitskritische Systeme) empfehlen wir, automatische Eval mit menschlicher Überprüfung zumindest für einen Teil der Fälle zu kombinieren.
Welches Modell sollte ich als Judge in RAGAS verwenden?
Für die meisten Fälle reicht ein Frontier-Modell der mittleren Klasse (Sonnet/Flash/Haiku-Tier) — es ist ausreichend präzise und deutlich günstiger als der maximale Tier. Bei On-Premise-Anforderungen oder sensiblen Daten unterstützt RAGAS auch lokale Modelle über eine OpenAI-kompatible API — ein starkes Open-Weight-Modell aus der Qwen3- oder Llama-Familie auf Inferenz via vLLM funktioniert für Judgment-Aufgaben gut.
*Wenn Sie unsicher sind, wo Sie mit der Evaluierung Ihrer RAG-Pipeline beginnen sollen, oder prüfen möchten, wo genau Ihre Pipeline an Genauigkeit verliert — bei MP Industrial Solutions führen wir diagnostische Assessments von RAG-Deployments durch und helfen, einen Evaluierungsprozess einzurichten, der umsetzbare Ergebnisse liefert, nicht nur Zahlen.*