RAG: Wie man die Qualität von Antworten evaluiert (Golden Set)

Das Team hat RAG implementiert, das erste Demo sieht großartig aus, die Geschäftsführung ist zufrieden. Dann, nach sechs Wochen im Produktivbetrieb, ändert jemand die Struktur der Dokumente in der Wissensdatenbank. Die Qualität der Antworten sinkt. Niemand bemerkt es zwei Wochen lang, weil es keinen Regressionstest gibt. Das ist ein Szenario, das wir bei jedem dritten Erstprojekt sehen.

Die Evaluierung von RAG ist kein akademisches Add-on. Es ist die einzige Methode, die „das System antwortet“ von „das System antwortet korrekt“ unterscheidet. Im Folgenden beschreibe ich, wie man sie aufbaut, welche Metriken man verwendet und wie man die Qualität über den gesamten Lebenszyklus des Systems aufrechterhält.

Das Testen einer REST-API ist einfach: Sie senden eine Anfrage und vergleichen die Antwort mit dem Schema. RAG hat drei unabhängige Fehlerquellen, die separate Metriken erfordern.

Retrieval-Fehler. Das System hat Fragmente abgerufen, die nicht zur Frage passen. Das generative Modell hat einen guten, aber falschen Kontext. Die Antwort kann überzeugend klingen und völlig falsch sein.

Faithfulness-Fehler. Das System hat relevante Fragmente abgerufen, aber das Modell hat nicht existierende Informationen daraus abgeleitet oder eigenes parametrisches Wissen hinzugefügt. Das ist eine klassische Halluzination, selbst bei korrektem Retrieval.

Relevance-Fehler. Das System hat die richtigen Fragmente abgerufen, das Modell hat einen Text generiert, der aus diesen Fragmenten resultiert, aber die Antwort adressiert nicht die tatsächliche Frage des Nutzers. Dies passiert, wenn die Frage mehrdeutig ist oder wenn die Wissensdatenbank thematische Lücken aufweist.

Unit-Tests für APIs erfassen keinen dieser Fehler. Sie benötigen separate Metriken für jede Ebene.

Das Golden Set ist ein kontrollierter Satz von Eingabe-Erwartete-Ausgabe-Paaren, der einmal erstellt, kontinuierlich gepflegt und automatisch ausgeführt wird. Minimale Anforderungen für den Produktivbetrieb:

Das Golden Set wird aus Quellen aufgebaut, die Sie kennen: Fragen aus Support-Tickets (am wertvollsten, weil real), Fragen aus Kontaktformularen, Fragen an Berater. Erstellen Sie es nicht durch das Erfinden von Fragen am Schreibtisch — im Vakuum erfundene Fragen entsprechen selten dem, wonach Nutzer wirklich suchen.

Formale Fragen außerhalb der Domäne (diejenigen, auf die die Wissensdatenbank nicht antworten sollte) müssen ebenfalls im Golden Set enthalten sein. Die RAG-Evaluierung ohne negative Tests misst nicht, ob das System korrekt die Antwort verweigert.

Die RAG-Evaluierung lässt sich auf drei Zahlen reduzieren, die Sie auf Ihrem Dashboard benötigen.

Faithfulness misst, ob die Antwort aus den bereitgestellten Fragmenten resultiert. Skala 0-1. Ein Wert von 1 bedeutet, dass jede These in der Antwort durch mindestens eines der Kontextfragmente bestätigt wird. Ein Wert von 0 bedeutet, dass das Modell aus eigenem parametrischem Wissen geantwortet hat und den Kontext ignoriert.

Erforderlicher Wert für den Produktivbetrieb: über 0,85. Unter diesem Schwellenwert generiert das System regelmäßig Informationen außerhalb der Wissensdatenbank.

Context Relevance (Kontextrelevanz) misst, welcher Prozentsatz der abgerufenen Fragmente inhaltlich nützlich für die Beantwortung der Frage ist. Eine niedrige Context Relevance bei hoher Faithfulness ist ein klassisches Symptom für zu breites Retrieval: Das Modell ist dem Kontext treu, aber der Kontext ist unnötig. Dies erfordert eine Korrektur des Rerankings oder der Suchparameter.

Answer Relevance misst, ob die Antwort die tatsächliche Frage des Nutzers adressiert. Diese Metrik ist unabhängig von Faithfulness: Die Antwort kann den Fragmenten treu sein, aber nicht auf die gestellte Frage eingehen. Besonders relevant bei mehrdeutigen oder mehrdimensionalen Fragen.

Eine vierte Metrik, die wir jedem Projekt hinzufügen: "Weiß nicht"-Rate — der Prozentsatz der Anfragen, bei denen das System korrekt die Antwort verweigert hat, weil keine relevanten Fragmente vorhanden waren. Ein zu niedriger Wert deutet darauf hin, dass die Guardrails zu permissiv sind und das System halluziniert, anstatt zu eskalieren.

Es gibt zwei praktische Methoden zur Messung qualitativer Metriken: LLM-as-Judge und die Bewertung durch einen Domänenexperten. Jede Methode hat unterschiedliche Anwendungsfälle.

LLM-as-Judge ist ein zweites Modell (anders als das, das die Antwort generiert), das das Paar (Frage, Antwort, Kontext) nach einem definierten Bewertungsschema bewertet. Der Vorteil ist die Skalierbarkeit: Die Bewertung von tausend Paaren dauert Minuten. Der Nachteil ist die Notwendigkeit der Kalibrierung, da verschiedene Modelle unterschiedliche Bewertungsbias haben.

Kalibrierung von LLM-as-Judge: Nehmen Sie 100 Paare aus dem Golden Set und bewerten Sie sie manuell (Domänenexperte), dann bewerten Sie denselben Satz mit LLM-as-Judge. Eine Pearson-Korrelation von über 0,8 zwischen menschlicher und modellbasierter Bewertung ist der Schwellenwert, ab dem Sie der automatischen Evaluierung bei großen Volumina vertrauen können.

Bewertung durch Domänenexperten ist langsam und kostspielig, aber notwendig als Referenzpunkt. Minimale Empfehlung: Alle zwei Wochen werden zufällig 30-50 Paare aus der Produktion von einem Experten bewertet. Diese Stichprobe hält die Kalibrierung von LLM-as-Judge aufrecht und erkennt Verschlechterungen, die automatische Metriken nicht sehen.

Die Bewertung durch Endnutzer (Daumen hoch/runter, kurze Umfrage) ist die einfachste Methode, um Feedback zu sammeln, misst aber den Eindruck, nicht die inhaltliche Qualität. Nutzer geben hohe Bewertungen für stilistisch überzeugende Antworten, selbst wenn der Inhalt falsch ist. Ergänzen Sie sie, ersetzen Sie sie nicht.

Das Golden Set hat nur dann einen Wert, wenn es regelmäßig und automatisch ausgeführt wird. Der Regressionszyklus für RAG:

Bei jeder Änderung der Wissensdatenbank. Das Hinzufügen neuer Dokumente, das Entfernen veralteter oder die Änderung der Chunk-Struktur — jede dieser Aktionen kann die Retrieval-Ergebnisse für bestehende Fragen verändern. Das nach der Änderung ausgeführte Golden Set erkennt Regressionen, bevor sie in die Produktion gehen.

Bei Änderung der Modell- oder Reranker-Konfiguration. Ein Update des Embedding-Modells, die Änderung der Reranking-Parameter, die Anpassung des Faithfulness-Schwellenwerts in den Guardrails — jede dieser Einstellungen beeinflusst die Metriken. Ohne Regressionstest wissen Sie nicht, in welche Richtung.

Wöchentlich auf einer Produktionsstichprobe. Unabhängig von Infrastrukturänderungen können reale Nutzeranfragen eine Verschlechterung aufdecken, die im Golden Set nicht sichtbar ist (Fragen außerhalb der Domäne, neue Fragetypen). Eine automatische Stichprobe von 50 Produktionsgesprächen, die wöchentlich von LLM-as-Judge bewertet wird, ergänzt das Golden Set um ein Signal aus der Realität.

Die Kombination dieser Ansätze mit einem versionierten Wissensdatenbank-Prozess beschreibt der Artikel Wissensaktualisierung in RAG und Versionierung.

Die Evaluierung von RAG ist nicht nur eine Frage der technischen Qualität. Für Systeme, die personenbezogene Daten verarbeiten oder in Hochrisikobereichen eingesetzt werden, ist der Evaluierungsnachweis Teil der Dokumentation, die durch den AI Act gefordert wird.

Minimale Anforderungen seitens der Compliance:

Evaluierungslogs müssen enthalten: Modellversion, Version der Wissensdatenbank, Datum der Testausführung, Ergebnisse pro Metrik und Identifikatoren der Testpaare. Der Inhalt der Testanfragen kann PII aus Produktionslogs enthalten, was eine Pseudonymisierung vor der Aufnahme in das Golden Set erfordert.

Für Systeme, die einer DPIA unterliegen (z. B. HR, Finanzen, Gesundheitswesen), muss die Evaluierung Bias-Tests umfassen: Behandelt das System dieselben Fragen unterschiedlich, abhängig von demografischen Merkmalen des Nutzers, die im Kontext vorhanden sind? Die Ergebnisse solcher Tests werden als Teil der Risikobewertung dokumentiert.

TTL der Evaluierungslogs: Aggregierte Ergebnisse (Metriken ohne Inhalte) können langfristig als Audit-Trail gespeichert werden. Logs mit vollständigen Evaluierungspaaren, die Inhalte von Anfragen enthalten, haben eine kürzere TTL, angepasst an die RODO-Retentionsrichtlinie — typischerweise 30-90 Tage.

Fehlende dokumentierte Evaluierung bei Hochrisikosystemen ist eine potenzielle Lücke während eines Aufsichtsaudits. Human-Oversight muss nachweisen können, dass es durchgeführt wurde, und nicht nur deklariert.

RAGAS (Retrieval Augmented Generation Assessment) ist das beliebteste Open-Source-Framework für die RAG-Evaluierung. Es implementiert Faithfulness, Answer Relevance, Context Precision und Context Recall als fertige Metriken. Es erfordert ein LLM-Modell zur Bewertung (LLM-as-Judge integriert) und kann lokal über den OpenClaw-Router betrieben werden.

Wann RAGAS die richtige Wahl ist: Wenn Sie die Evaluierung von Grund auf starten und schnell einen Satz Metriken ohne eigene Bewertungslogik erhalten möchten. RAGAS eignet sich gut für die ersten 3-6 Monate eines Projekts.

Wann eine eigene Pipeline aufbauen: Wenn Sie spezifische domänenspezifische Anforderungen haben (z. B. Evaluierung von rechtlicher Compliance, technischer Faktografie, formellem Ton in einer bestimmten Sprache), die fertige Rubriken nicht abdecken. Eine eigene Pipeline bietet auch bessere Kontrolle über die Token-Kosten der Bewertung.

Wichtiger technischer Hinweis: Das bewertende Modell (LLM-as-Judge) sollte nicht dasselbe Modell sein, das die Antworten generiert. Verschiedene Modelle haben unterschiedliche Bias, und die Selbstbewertung desselben Modells führt zu überhöhten Ergebnissen. Ein gutes Muster ist ein kleineres, schnelleres Modell als Judge (geringere Token-Kosten) bei einem größeren generativen Modell.

Das bei der Implementierung erstellte Golden Set wird mit der Zeit zunehmend unrepräsentativ. Nach sechs Monaten können Nutzerfragen erheblich von denen im Golden Set abweichen — neue Themenbereiche, neue Kundentypen, geänderte Prozesse in der Organisation. Dieser Drift der Abfrageverteilung ist ein stiller Qualitätskiller: Die Metriken auf dem Golden Set bleiben stabil, aber die tatsächliche Qualität in der Produktion sinkt.

Signale, dass das Golden Set aktualisiert werden muss:

• Die Eskalationsrate zum Menschen steigt drei Wochen in Folge ohne Konfigurationsänderung.
• Es entsteht ein thematischer Cluster in der Produktion, der keine Repräsentation im Golden Set hat (erkennbar durch Clustering von Embeddings realer Abfragen).
• Nutzerfeedback enthält Antwortkategorien, die das Golden Set nicht testet.

Die Aktualisierung des Golden Sets sollte mindestens einmal pro Quartal erfolgen: Überprüfen Sie 200-300 Produktionsgespräche, identifizieren Sie neue Fragetypen, fügen Sie sie dem Golden Set hinzu und führen Sie einen Benchmark durch. Das ist kein einmaliges Projekt, sondern ein Prozess.

Der Artikel Monitoring der Qualität eines KI-Agenten beschreibt, wie die Golden-Set-Evaluierung in ein umfassenderes operatives Dashboard integriert wird.

Beschreiben Sie Ihr RAG-System oder die geplante Implementierung, und das Modell zeigt Ihnen, mit welchen Metriken Sie beginnen sollten, wie Sie ein Golden Set für Ihren Anwendungsfall aufbauen und welche Qualitätsrisiken in Ihrem Fall kritisch sind (Playground: PII maskiert, keine Speicherung):

Mindestens 50 Paare ermöglichen es, Regressionen von mehr als 10 Prozentpunkten bei Qualitätsmetriken zu erkennen. Für eine Wissensdatenbank mit bis zu 200 Dokumenten und einem engen Themenbereich ist das ein ausreichender Start. Bei 200 Paaren sind die Ergebnisse statistisch stabil und ermöglichen die Erkennung von Änderungen im Bereich von 3-5 Prozentpunkten. Wenn die Wissensdatenbank mehrere separate Themenbereiche hat, muss das Golden Set eine repräsentative Abdeckung jedes Bereichs aufweisen, auch wenn die Gesamtzahl der Paare gering ist. Details zur Vorbereitung der Wissensdatenbank beschreibt der Artikel Wie man Unternehmensdaten für KI vorbereitet.

Faithfulness misst, ob die Antwort aus den bereitgestellten Kontextfragmenten resultiert, unabhängig davon, ob diese Fragmente relevant waren. Relevance misst, ob die Antwort tatsächlich die Frage des Nutzers adressiert. Ein System kann eine hohe Faithfulness (das Modell zitiert die Fragmente treu) und eine niedrige Relevance (die Fragmente passen nicht zur Frage) aufweisen. Beide Metriken müssen separat gemessen werden. Der häufigste Fehler besteht darin, nur eine von beiden zu messen und Schlussfolgerungen über das gesamte System zu ziehen. Wenn Faithfulness hoch, aber Relevance niedrig ist, liegt das Problem im Retrieval, nicht im generativen Modell. Mehr über die Suche beschreibt der Artikel Semantische Suche und Embeddings im Unternehmen.

Führen Sie es bei jeder Änderung der Wissensdatenbank oder Modellkonfiguration aus. Unabhängig von Änderungen führen Sie es w wöchentlichen Abständen auf einer Produktionsstichprobe von 50 Gesprächen aus, die von LLM-as-Judge bewertet wird. Für Systeme, die mehr als 1.000 Anfragen pro Tag bearbeiten, verkürzen Sie das Intervall auf 3-4 Tage. Für Systeme in Hochrisikobereichen (Finanzen, Gesundheit, HR) erfordert jede Konfigurationsänderung das Durchlaufen des Golden Sets mit vollständiger Dokumentation der Ergebnisse als Teil des Audit-Trails nach AI Act. Die automatische Ausführung in CI/CD eliminiert das Risiko, Tests bei schnellen Änderungen zu überspringen.

Ohne Kalibrierung anhand einer Expertenbewertung liefert LLM-as-Judge Ergebnisse mit geringer Korrelation zur tatsächlichen domänenspezifischen Qualität. Modelle definieren „Relevanz“ für verschiedene Bereiche unterschiedlich. Die Kalibrierung funktioniert so: Sie bewerten 100 Paare manuell, bewerten dieselben Paare mit LLM-as-Judge und messen die Korrelation. Unter einem Pearson-Wert von 0,75 ist das Modell kein vertrauenswürdiger Richter für Ihre Domäne. Die Kalibrierung muss nach Aktualisierungen des bewertenden Modells wiederholt werden. Die Kosten dieser Arbeit sind einmalig bei der Systemeinführung und lohnen sich, da sie das Vertrauen in automatische Metriken ermöglicht.

Für Systeme, die gemäß AI Act als Hochrisikosysteme eingestuft werden (insbesondere in den Bereichen HR, Finanzen, Gesundheitswesen), verlangt die Verordnung die Dokumentation der Wirksamkeit des Systems und die Möglichkeit, seine Funktionsweise zu erklären. Die Evaluierung des Golden Sets mit protokollierten Ergebnissen ist ein direkter Nachweis, dass das System regelmäßig kontrolliert wurde. Das Fehlen dieser Dokumentation erschwert den Nachweis der Konformität während eines Aufsichtsaudits. Für Systeme, die einer DPIA unterliegen, fügen Sie dem Evaluierungsprozess Tests auf Bias und Tests zur Verweigerung von Antworten auf Fragen außerhalb der Domäne hinzu. Die Pflichten von Unternehmen gemäß AI Act und RODO beschreibt der Artikel AI Act und RODO 2026.