RAG-System evaluieren: Metriken, Testsets und Monitoring

Ein RAG-System testen Sie nicht durch Bauchgefühl, sondern mit klaren Zahlen: Wie oft findet die Suche die richtigen Passagen (Recall@k, MRR), wie oft bleibt die Antwort nah an den Quellen (Faithfulness) und wie oft stimmen die angegebenen Zitate tatsächlich? Dafür brauchen Sie ein Testset aus echten Fragen, feste Metriken und ein Monitoring, das auch nach dem Launch weiterläuft. Dieser Leitfaden zeigt Schritt für Schritt, wie Sie das aufbauen, ohne ein eigenes ML-Team einzustellen.

Warum die meisten RAG-Projekte ohne Evaluierung scheitern

In der Demo funktioniert fast jedes RAG-System überzeugend: Fünf sorgfältig ausgewählte Fragen, saubere Dokumente, eine aufmerksame Vorführung. Im Produktivbetrieb sieht die Realität anders aus: tippfehlerhafte Nutzerfragen, mehrdeutige Formulierungen, Dokumente, die sich widersprechen, und Antworten, die zwar plausibel klingen, aber auf der falschen Seite zitieren. Ohne Messgrößen bemerken Sie das erst, wenn ein Kunde sich beschwert oder ein Mitarbeiter eine falsche Information als Entscheidungsgrundlage nutzt. Wer eine Wissensdatenbank produktiv einsetzt, sollte deshalb von Anfang an drei Fragen getrennt beantworten können: Findet das System die richtigen Passagen? Bleibt die generierte Antwort bei diesen Passagen? Und stimmen die angegebenen Quellen wirklich?

Retrieval-Metriken: Finden Sie überhaupt die richtigen Passagen?

Bevor Sie irgendetwas an der Antwortgenerierung optimieren, prüfen Sie die Suche selbst. Wenn die relevante Passage gar nicht unter den abgerufenen Ergebnissen ist, kann auch das beste Sprachmodell keine korrekte Antwort liefern. Das ist der Grund, warum Hybrid Search aus Volltext- und Vektorsuche bei vielen Anwendungsfällen zuverlässiger abschneidet als reine semantische Suche: Fachbegriffe, Artikelnummern oder Gesetzesparagrafen werden sonst leicht übersehen.

Recall@k und Precision@k

Recall@k misst, wie oft die relevante Passage unter den ersten k abgerufenen Treffern auftaucht. Bei Recall@5 von 80 % bedeutet das: In 80 % der Testfragen war die richtige Antwortquelle unter den fünf angezeigten Treffern. Precision@k misst umgekehrt, wie viele der k Treffer tatsächlich relevant sind, also wie viel Rauschen mitgeliefert wird. Für RAG-Systeme ist Recall meist wichtiger als Precision, weil ein nachgelagertes Sprachmodell irrelevante Passagen notfalls ignorieren kann, eine fehlende Passage aber nicht erfinden sollte.

Mean Reciprocal Rank (MRR)

MRR bewertet zusätzlich die Position des ersten relevanten Treffers. Steht die richtige Passage an erster Stelle, zählt das mit 1,0, an zweiter Stelle mit 0,5, an fünfter Stelle nur noch mit 0,2. Das ist wichtig, weil Sprachmodelle Informationen am Anfang des Kontexts tendenziell stärker gewichten. Eine Suche mit hohem Recall, aber niedrigem MRR liefert die richtige Antwort oft erst an Position vier oder fünf, was die Antwortqualität trotzdem verschlechtert.

Antworttreue (Faithfulness) und Zitatgenauigkeit prüfen

Gute Retrieval-Werte garantieren noch keine gute Antwort. Das Sprachmodell kann die richtigen Passagen erhalten und trotzdem Details hinzuerfinden, Zahlen verwechseln oder zwei Dokumente vermischen. Genau das beschreibt Faithfulness: der Anteil der Aussagen in der generierten Antwort, die sich tatsächlich aus den abgerufenen Passagen ableiten lassen. Eine Antwort kann sprachlich flüssig und inhaltlich falsch zugleich sein, das ist der klassische Fall einer Halluzination trotz Retrieval.

Zitatgenauigkeit (Citation Accuracy) ist eine eigene, oft unterschätzte Dimension: Steht neben einer Aussage ein Verweis auf Dokument X, Seite 3, stimmt diese Zuordnung dann auch? In der Praxis sehen wir häufig Antworten, die inhaltlich korrekt sind, aber die falsche Quelle zitieren, etwa weil zwei Passagen sehr ähnlich formuliert sind. Für Anwendungen mit Haftungsrisiko, etwa in der Rechtsberatung oder im Arbeitsschutz, ist diese Prüfung mindestens so wichtig wie die inhaltliche Korrektheit. Mehr dazu, wie Sie Quellenangaben systematisch gegenprüfen, finden Sie im Artikel KI-Antworten mit Quellenangaben prüfen.

• Faithfulness manuell: Stichprobe von 30-50 Antworten, jede Aussage einzeln gegen die zitierte Passage prüfen
• Faithfulness automatisiert: ein zweites Sprachmodell als Gutachter einsetzen, das prüft, ob jede Aussage durch die Passage gedeckt ist
• Zitatgenauigkeit: prüfen, ob die angegebene Fundstelle die Aussage tatsächlich enthält, nicht nur thematisch verwandt ist
• Negativtest: Fragen stellen, zu denen keine Antwort in den Dokumenten steht, und prüfen, ob das System das ehrlich zugibt

Ein Testset aus echten Fragen aufbauen

Synthetische Testfragen, die Sie selbst am Schreibtisch formulieren, sind ein guter Start, bilden aber selten die tatsächliche Nutzung ab. Echte Nutzerfragen sind kürzer, unpräziser und enthalten oft Tippfehler oder Umgangssprache. Ein belastbares Testset entsteht in mehreren Schritten.

1. Echte Fragen sammeln: aus Support-Tickets, Suchprotokollen, E-Mails an Fachabteilungen oder einer ersten Testphase mit echten Nutzern
2. Pro Frage die erwartete Antwortquelle markieren: welches Dokument, welcher Abschnitt, welche Passage sollte als Grundlage dienen
3. Schwierigkeitsgrade mischen: einfache Faktenfragen, Fragen mit mehreren relevanten Quellen (Multi-Hop) und bewusst unbeantwortbare Fragen
4. Randfälle einbauen: mehrdeutige Begriffe, veraltete Dokumentversionen, widersprüchliche Angaben in verschiedenen Quellen
5. Das Set versionieren: bei jeder Änderung an Chunking, Indexierung oder Prompt dieselben Fragen erneut laufen lassen und Werte vergleichen

Die Qualität des Testsets hängt auch an der Chunking-Strategie, denn falsch geschnittene Passagen führen zu falschen Erwartungswerten im Testset selbst. Wenn Sie beim Aufbau Ihrer Wissensdatenbank unsicher sind, wie Dokumente sinnvoll in Abschnitte zerlegt werden, lohnt sich ein Blick in Chunking-Strategien für RAG, bevor Sie Ihr Testset final festlegen.

Kontinuierliches Monitoring im Betrieb

Evaluierung ist kein einmaliges Projekt vor dem Launch. Dokumente werden aktualisiert, neue Fachbereiche kommen hinzu, Nutzer stellen Fragen, die beim Testaufbau niemand vorhergesehen hat. Drei Praktiken halten die Qualität dauerhaft messbar:

• Stichproben aus echten Produktionsfragen regelmäßig von Fachleuten gegenlesen, etwa 20 Antworten pro Woche
• Automatisierte Faithfulness-Prüfung auf einen Teil des Live-Verkehrs anwenden, um Ausreißer früh zu erkennen
• Retrieval-Metriken nach jeder Änderung an Dokumenten, Chunking oder Index erneut gegen das Testset laufen lassen
• Nutzer-Feedback einsammeln: ein einfaches Daumen-hoch-runter nach jeder Antwort liefert überraschend verwertbare Signale

Diese Praxis unterscheidet sich kaum danach, ob Sie eine selbst gehostete Pipeline betreiben oder eine Wissensdatenbank bei einem Anbieter wie Kopik pflegen: Die Metriken bleiben dieselben, nur der Aufwand für Infrastruktur und Indexierung entfällt.

Praxisbeispiel: Eine Wissensdatenbank auf Kopik evaluieren

Ein konkreter Vorteil beim Testen mit einer gehosteten Wissensdatenbank: Sie können Retrieval und Generierung getrennt prüfen. Im passages-Modus liefert Kopik nur die abgerufenen Textstellen ohne generierte Antwort, ideal um Recall@k und MRR gegen Ihr Testset zu messen, ohne dass Formulierungen des Sprachmodells die Auswertung verfälschen. Im normalen Modus mit belegten Antworten prüfen Sie zusätzlich Faithfulness und Zitatgenauigkeit, da jede Antwort mit den zitierten Passagen verknüpft ist. Über die REST-API lässt sich ein Testset von hundert Fragen in wenigen Minuten vollautomatisch durchlaufen lassen, die Antworten und Quellenangaben werden strukturiert zurückgegeben und können direkt gegen Ihre erwarteten Ergebnisse abgeglichen werden. Wer eine neue Wissensdatenbank aufbaut, kann das Vorgehen direkt beim Anlegen mitdenken: Dokumente hochladen, ein erstes Testset mit zehn bis zwanzig echten Fragen anlegen und vor der produktiven Nutzung einmal komplett durchspielen.

Wenn Ihr Anwendungsfall personenbezogene Daten betrifft, etwa Mitarbeiterunterlagen oder Kundendaten in den Dokumenten, sollte die Evaluierung außerdem Teil Ihrer Dokumentation sein. Die DSGVO-Checkliste für RAG zeigt, welche Nachweise dabei typischerweise verlangt werden.