Wie man ein RAG-System evaluiert: Metriken für Retrieval, Faithfulness und Golden Set

Regelmäßig erleben wir denselben Moment: Ein Team implementiert einen RAG-basierten Assistenten, jemand meldet, dass „der Bot halluziniert“, und die Suche nach dem Schuldigen beginnt. Halluziniert das Modell, oder hat es einfach nicht den richtigen Kontextausschnitt erhalten? Ohne getrennte Messung beider Schichten endet diese Diskussion im Ratespiel. Die Evaluierung von RAG ist keine einzelne Zahl – es sind zwei Metrikensätze, verbunden durch einen gemeinsamen Testdatensatz, die gemeinsam zeigen, wo genau das System versagt.

Ein RAG-System besteht aus zwei Komponenten, die unabhängig voneinander versagen können. Der Retrieval kann den richtigen Ausschnitt nicht finden – dann hat die Generierung keine Chance, weil das Modell nicht sieht, was es nicht erhalten hat. Oder der Retrieval liefert den korrekten Kontext, und das Modell antwortet trotzdem daneben, ignoriert ihn oder fügt Fakten aus dem eigenen Gedächtnis hinzu. Das sind zwei verschiedene Fehler mit zwei unterschiedlichen Lösungsansätzen.

Daher messen wir sie separat. Die Qualität der semantischen Suche bewertet, ob die richtigen Ausschnitte hoch im Kontext landen. Die Qualität der Antwort bewertet, ob sich das Modell an das hält, was es erhalten hat. Erst die Kombination beider ergibt ein End-to-End-Bild. Ein häufiger Fehler ist es, nur die endgültige Antwortbewertung zu betrachten: Wenn sie sinkt, ist unklar, ob der Retrieval oder die Generierung schuld ist, sodass die Verbesserungen chaotisch ausfallen.

Die Suchschicht messen wir mit denselben Tools wie reinen Retrieval. Recall@k gibt an, welcher Anteil der erwarteten Ausschnitte sich in den Top-k-Ergebnissen befindet, die dem Modell übergeben werden. Das ist eine Coverage-Metrik – wenn der richtige Ausschnitt nicht im Kontext ist, kann selbst das beste Modell keine korrekte Antwort generieren, sondern halluziniert. Daher ist recall@k für RAG wichtiger als für eine Suchmaschine, bei der der Nutzer die Liste selbst durchsieht.

Precision@k hingegen gibt an, welcher Anteil der übergebenen Ausschnitte tatsächlich relevant war. Eine niedrige Präzision bedeutet, dass der Kontext mit Rauschen überflutet wird – das Modell erhält Störsignale, die Token-Kosten steigen und das Risiko, dass es sich an irrelevante Fragmente klammert, wächst. In der Praxis balancieren wir beide: Ein größeres k erhöht den Recall, senkt aber die Präzision. MRR (Mean Reciprocal Rank) zeigt an, wie hoch der erste relevante Treffer landet, was wichtig sein kann, wenn wir dem Modell weniger Kontext übergeben möchten.

Die Zahlen in der Spalte „Schwellenwert“ sind Richtwerte, die wir in Projekten mit polnischen Unternehmensdokumenten beobachtet haben – keine universellen Konstanten. Betrachte sie als Kalibrierungspunkt. Die Methodik zur Messung des Retrievals selbst vertiefen wir im Artikel Wie man die Qualität von Embeddings misst. Wenn der Recall zu niedrig ist, sind die häufigsten Hebel die Änderung der Chunking-Strategie und die Ergänzung um hybride Suche BM25 plus Vektoren.

Die zweite Schicht ist die Qualität der Antwort selbst, unter der Annahme, dass der Kontext bereits vorhanden ist. Die Schlüsselmetrik ist Faithfulness (Verankerung): Lässt sich jede Aussage in der Antwort durch einen Ausschnitt aus dem bereitgestellten Kontext stützen? Eine treue Antwort fügt keine Fakten hinzu, die nicht im Material enthalten sind – genau solche Ergänzungen sind klassische Halluzinationen. Faithfulness messen wir, indem wir die Antwort in einzelne Sätze-Aussagen zerlegen und prüfen, ob jede davon im Kontext verankert ist.

Die zweite Metrik ist die Relevanz der Antwort (answer relevance): Bezieht sich die Antwort tatsächlich auf die Frage und ist nicht korrekt, aber thematisch daneben? Die dritte ist die Quellenattribution: Gibt das System an, aus welchem Dokument die Information stammt, und sind diese Zitate wahrheitsgemäß? Attribution ist kein Schmuck – sie ist ein Mechanismus, der es dem Nutzer ermöglicht, die Antwort zu überprüfen, und uns gleichzeitig eine auditierbare Spur bei der Evaluierung liefert.

Halluzinationen in RAG haben zwei verschiedene Ursachen. Erstens: Der Retrieval hat die Antwort nicht geliefert, also „ergänzt“ das Modell aus dem Gedächtnis – das ist ein Defekt der Suchschicht, der durch niedrigen Recall erkannt wird. Zweitens: Der Kontext war korrekt, aber das Modell ist trotzdem darüber hinausgegangen – das ist ein Defekt der Generierung, der durch niedrige Faithfulness erkannt wird. Die getrennte Messung zeigt sofort, welche Schicht repariert werden muss, statt „den Prompt zu verbessern“, wenn das eigentliche Problem ein fehlender Chunk ist.

Ohne Golden Set gibt es nichts zu messen – weder auf welcher Schicht. Für RAG ist das Golden Set reichhaltiger als für reinen Retrieval, denn jeder Eintrag besteht aus einem Triple: eine realistische Frage, eine Sammlung von Ausschnitten, die den richtigen Kontext bilden, und eine mustergültige Antwort (oder eine Reihe von Fakten, die eine korrekte Antwort enthalten muss). Frage und markierter Kontext speisen die Retrieval-Metriken; Frage, Kontext und mustergültige Antwort speisen die Generierungsmetriken.

Beginne mit 50-100 echten Fragen aus den Logs des Assistenten, Supportanfragen oder Interviews mit zukünftigen Nutzern. Am Schreibtisch ausgedachte Fragen sind zu regelmäßig und spiegeln nicht die Sprache der Nutzer wider, die mit Abkürzungen und Fehlern schreiben. Für jede Frage markierst du die relevanten Kontextausschnitte und notierst eine mustergültige Antwort – die Annotation sollte von einer fachkundigen Person durchgeführt werden, nicht vom Sprachmodell, da das Modell hier das Bewertungsobjekt ist.

Korpus für die Evaluierung indexierst du mit genau derselben Pipeline wie die Produktionsumgebung: dieselbe Chunking-Strategie, dasselbe Embedding-Modell, dieselbe Fragmentgröße. Wenn du irgendetwas zwischen Test und Produktion änderst, sind die Metriken nicht mehr vergleichbar. Behandle das Golden Set wie Code – es wächst mit dem System, und jeder gemeldete Produktionsfehler sollte als neuer Testfall zurückfließen.

Die Offline-Evaluierung auf dem Golden Set ist wiederholbar und kostengünstig, hat aber einen blinden Fleck: Sie misst nur, was wir vorhergesehen haben. Echte Nutzer stellen Fragen außerhalb des Sets, in Formen, die wir uns nicht ausgedacht haben. Daher dient Offline dem Vergleich von Varianten (Modell A vs. B, Chunking 256 vs. 512) und dem Schutz vor Regressionen nach jeder Änderung, ersetzt aber nicht die Produktionsbeobachtung.

Die Online-Evaluierung läuft im Live-Betrieb. Grundlage ist die Observability: Wir loggen Frage, bereitgestellten Kontext, Antwort und angegebene Quellen, sodass jede Antwort nachvollziehbar und auditierbar ist. Darauf aufbauend berechnen wir Faithfulness im Continuous-Mode – ein automatischer Richter (LLM-as-judge) prüft, ob die Aussagen in der Antwort im geloggten Kontext verankert sind, und markiert Fälle ohne Abdeckung als Halluzinationskandidaten. Das ist ein Signal, kein Urteil: Ein Teil der Markierungen erfordert manuelle Prüfung, und eine Stichprobe geht in die fachliche Bewertung.

Attribution schließt den Kreis. Wenn jede Antwort die Fragmente angibt, auf denen sie basiert, reduziert sich die Halluzinationsprüfung darauf, zu überprüfen, ob die zitierten Fragmente tatsächlich das enthalten, was das Modell behauptet. Eine Diskrepanz zwischen Zitierung und Fragmentinhalt ist ein starkes Halluzinationssignal. Produktionssignale – niedrige Faithfulness, Daumen runter, Eskalation zum Menschen – fließen zurück ins Golden Set als neue Testfälle und schließen den Offline-Online-Kreislauf. Wie dieser Kreislauf für einen gesamten Assistenten aussieht, beschreiben wir im Text über Monitoring der Qualität eines KI-Agenten.

Nein. Eine einzelne Endbewertung zeigt, dass etwas nicht stimmt, sagt aber nicht, ob der Retrieval oder die Generierung versagt hat. Das sind zwei verschiedene Fehler mit unterschiedlichen Lösungen, daher müssen beide Schichten separat gemessen und erst dann zu einem End-to-End-Bild zusammengesetzt werden. Ohne diese Trennung sind Verbesserungen ein Ratespiel.

Faithfulness prüft, ob sich die Antwort an den bereitgestellten Kontext hält und keine Fakten außerhalb davon hinzufügt – das schützt vor Halluzinationen. Relevanz prüft, ob die Antwort überhaupt auf die Frage eingeht. Eine Antwort kann kontexttreu, aber irrelevant sein (korrekt, aber thematisch daneben), daher werden beide Metriken parallel benötigt.

Aus unserer Praxis ist ein vernünftiger Start 50-100 Frage-Kontext-Antwort-Paare, basierend auf realen Anfragen. Das reicht aus, um deutliche Unterschiede zwischen Varianten und Regressionen zu erkennen. Behandle den Datensatz als lebendig: Jeder neue Produktionsfehler sollte als weiterer Testfall hinzugefügt werden, sodass er mit der Zeit wächst.

Ja, LLM-as-judge ist ein praktischer Weg, Faithfulness im großen Maßstab zu bewerten, besonders online. Aber behandle es als Signal, nicht als endgültiges Urteil: Kalibriere den Richter anhand einer manuell bewerteten Stichprobe und auditiere regelmäßig seine Entscheidungen. Verwende für die Annotation des Golden Sets (Markierung des richtigen Kontexts) nicht denselben Modelltyp, den du bewertest, da dies die Messung verfälscht.

Wenn die Antwort die Fragmente angibt, auf denen sie basiert, reduziert sich die Überprüfung darauf, ob diese Fragmente tatsächlich das enthalten, was das Modell behauptet. Eine Diskrepanz zwischen Zitierung und Fragmentinhalt ist ein starkes Halluzinationssignal. Attribution liefert zudem eine auditierbare Spur – nützlich sowohl für die Evaluierung als auch für die Bearbeitung von Nutzerbeschwerden.