Sechs wichtige RAG-Bewertungsmetriken in der Produktion

Frühe RAG-Tutorials lassen den Weg kurz erscheinen: Dokumente aufteilen, sie einbetten, Vektoren speichern, einen kleinen top_k wählen und das Modell aufrufen. Dieses Vorgehen mag in einer Demo gut aussehen. In der Produktion ist die Situation jedoch anders.

Die Fragen kommen unstrukturiert. Die Queldokumente widersprechen sich. Einige Anfragen erfordern Beweise aus mehreren Quellen gleichzeitig. Nutzer erfinden Formulierungen, die im ursprünglichen Testset nie vorkamen. Eine Lösung, die bei einem standardisierten Benchmark gut abgeschnitten hat, beginnt plötzlich seltsam unzuverlässige Antworten zu liefern.

Beim Anpassen der Suchfunktion für einen unternehmensinternen Assistenten zeigte sich dieses Muster deutlich. Fehlende Beweise veranlassten das Team, die Suchtiefe zu erhöhen. Die Ergebnisse der Offline-Suche verbesserten sich, ebenso wie die Trefferquote. Die auf Papier ermittelten Metriken zeigten „bessere“ Leistungen – doch die generierten Antworten wurden schlechter.

Der zusätzliche Kontext half nicht. Manchmal tat es sogar weh. Die relevanten Abschnitte kamen vermischt mit Duplikaten, schwachen Bezugselementen sowie gelegentlichen Konflikten.

Diese Erfahrung veränderte die Herangehensweise bei der Bewertung. Die Frage lautete nicht mehr „Haben wir die richtige Datei heruntergeladen?“, sondern „Kann jede Phase des Workflows zeigen, dass sie ihre Aufgabe erfüllt?“

Das Debuggen von laufenden RAG-Systemen trennt schnell verschiedene Aspekte voneinander, die in Demonstrationsversionen zu einem einzigen Bewertungswert zusammengefasst werden: Wie gut wird die Information abgerufen, wie gut wird sie gerankt, wie gut ist die Antwort, bleiben die Aussagen belegt, wie lange müssen Nutzer warten und wie viel kostet jede Anfrage? Die anschließende Frage – Wie sollten wir die Größe der Datenblöcke und den Wert von top-k festlegen? – verdient nicht länger nur eine vorgefertigte Zahlengruppe.

Betrachten Sie das Problem als Offline-Optimierung: Erfinden Sie einen Referenzwert, messen Sie die richtigen Kennzahlen, benennen Sie die Abwägungen, prüfen Sie unbekannte Anfragen und bestätigen Sie anschließend, dass der gewählte Ansatz auch in der Produktion funktioniert.

Sechs Metriken sind besonders nützlich: Recall@K, nDCG, MRR, Faithfulness, Latenz und Kosten. Jede von ihnen zeigt einen anderen Fehler auf. Gemeinsam erklären sie, wie aus einem Prototyp ein System wird, das betrieben werden kann.

Fangen Sie mit der Informationsbeschaffung an

Wenn die Ergebnisse nachlassen, kehren Sie zu dem Anfang des Prozesses zurück, anstatt Prompts umzuschreiben, Modelle auszutauschen oder zusätzliche Agenten hinzuzufügen. Stellen Sie sich die direkte Frage: Wird überhaupt das notwendige Material gefunden? Ein Modell kann keine Informationen verwenden, die niemals in das Kontextfenster gelangt sind.

1. Recall@K – Abdeckung der benötigten Informationen

Recall@K fragt, welcher Anteil der wirklich relevanten Elemente unter den ersten K Ergebnissen zu finden ist.

Nehmen wir einen ITSM-Bot, der folgende Frage gestellt bekommt: „Der Zahlungsdienst ist nach einem Datenbank-Failover ausgefallen – welche Wiederherstellungs Schritte sollte ich ausführen?“ Es sind fünf Fakten erforderlich. Die fünf wichtigsten Ergebnisse des Informationsbeschaffungssystems enthalten nur vier davon. Der Recall@5-Wert beträgt 0,80.

Diese einzige Zahl bestimmt bereits die Fehlersuche. Der Generator ist vielleicht nicht der Schuldige – zwanzig Prozent der benötigten Beweise sind nie angekommen. Faustregel: Verbessern Sie zunächst das, was das Modell sieht, bevor Sie es dafür verantwortlich machen, wie es schreibt.

Dies erklärt auch, warum ein fester Wert von top_k = 5 nicht heilig ist. Wenn man K von 5 auf 10 erhöht und beobachtet, wie sich die Recall-Wert von 0,80 auf 0,94 steigert, deutet das darauf hin, dass der Index zwar das gewünschte Material enthält, aber die Auswahl zu oberflächlich ist. Eine Erhöhung von K birgt außerdem das Risiko, den Prompt mit Unrat zu überfluten – deshalb kommen anschließend die Ranking-Metriken.

2. nDCG – sind die besten Ergebnisse ganz oben?

Allein die Abdeckung reicht nicht aus. Die Position spielt eine Rolle.

Zwei Systeme können dasselbe Handbuch verwenden. Das eine platziert es an erster Stelle, dann ein weiteres nützliches Verfahren und anschließend schwächere Abschnitte. Das andere versteckt das Handbuch auf Rang acht unter weniger relevanten Seiten. Ähnlicher Recall – völlig unterschiedliche Ergebnisse.

nDCG (normalisierter diskontierter kumulativer Gewinn) bewertet die Relevanz und belohnt es, starke Ergebnisse früh zu platzieren. Die klassische Arbeit zu diskontierten Gewinnen von Järvelin und Kekäläinen existiert genau aus diesem Grund.

Durch Neuranking wird dies für RAG konkret umgesetzt. Es werden zwanzig Kandidaten abgerufen, fünf bleiben für das Modell – die Reihenfolge der zwanzig bestimmt, ob die fünf überhaupt geeignet sind. Hohe Trefferquote bei schwachem Ranking kann dazu führen, dass der richtige Abschnitt zwar im Pool vorhanden ist, aber außerhalb des endgültigen Prompts landet.

Trefferquote überprüft die Entdeckungskraft. nDCG prüft eine intelligente Anordnung der Ergebnisse.

3. MRR – wie schnell kommt der erste nützliche Treffer?

Die mittlere rekursive Rangfolge konzentriert sich auf das erste relevante Ergebnis:

[
RR = \frac{1}{\text{rank of first relevant result}}
]

Rang 1 → RR 1,0. Rang 5 → RR 0,2. Im Durchschnitt über eine Abfragesammlung ist MRR ein deutliches Signal dafür, dass der erste gute Treffer den gesamten Prozess dominiert.

Interaktive Assistenten stoppen oft nach dem ersten aussagekräftigen Abschnitt. Ein Retriever, der das richtige Handbuch auf Rang neun versteckt, kann bei Recall@20 gut abschneiden, in der Benutzeroberfläche aber immer noch unzuverlässig wirken.

Wenn „mehr Kontext“ kontraproduktiv ist

Auch nach der Verbesserung der Retrieval-Zahlen sank die Qualität der Antworten weiter. Das Modell war überflüssigem und widersprüchlichem Text ausgesetzt. Die Ranking-Metriken erklären diese Falle: Ein größeres K ohne bessere Sortierung führt zu Störungen im Prompt, was wiederum Kontrollen erfordert.

4. Treue – Behauptungen im Zusammenhang mit dem abgerufenen Text

Unter Treue wird geprüft, ob die Behauptungen in der Antwort durch den abgerufenen Kontext gestützt werden. Flüssiger Text, der einen Schritt erfindet, einen Schwellenwert konstruiert oder zwei Richtlinien zu einer dritten verschmilzt, verletzt die Treue – selbst wenn er überzeugend klingt.

Halten Sie Treue getrennt von Korrektheit.

Nehmen wir an, das Korpus enthält weiterhin eine veraltete Passwortregel – Ablauf nach 60 Tagen. Das Modell holt sie ab und wiederholt sie. Die Antwort kann der abgerufenen Seite vollständig treu sein und dennoch im Widerspruch zur beabsichtigten Quelle der Wahrheit stehen.

• Treue: Welchen Informationen entspricht sie?
• Korrektheit: Stimmt sie mit der beabsichtigten Richtlinie überein?

Diese Trennung ist wichtig, sobald Wissensbasen unter einem laufenden System abweichen.

5. Latenz – eine Zeit, die qualitativ hochwertige Nutzer in Kauf nehmen können

Die Qualität im Offline-Betrieb ist nutzlos, wenn das Produkt die Wartezeit nicht verkraften kann.

Vergleichen wir zwei Konfigurationen: A erreicht eine Antwortgenauigkeit von 91 % bei einer Abruflatenz von 120 ms. B erreicht 93 % bei 650 ms. Allein in Bezug auf die Genauigkeit hat B Vorteile. Produktbedingungen entscheiden jedoch, ob B tatsächlich besser ist. Interaktive Assistenten mit strengen Antwortzeiten mögen diese Verzögerung ablehnen, und der Abruf ist nur ein Teil der Gesamtzeit.

Eine Live-Anfrage kann Umformulierung, Abruf, Neubewertung, Zusammenstellung des Kontexts und Erstellung umfassen. Messen Sie die einzelnen Phasen sowie den gesamten Ablaufweg. Ziehen Sie Verteilungen vor Durchschnitten vor. Ein Durchschnitt von 400 ms bei einer P95-Wertzeit von 1,8 s wirkt keineswegs wie ein System, bei dem die Werte P50/P95/P99 niedrig bleiben.

Berechnen Sie die Latenz bereits ab dem ersten Tag in den Bewertungsplan ein – und nicht erst als Betriebsmetrik, nachdem die Architektur festgelegt wurde.

6. Kosten – was passiert bei Millionen von Abfragen

Ökonomische Aspekte treten bereits dann in Erscheinung, wenn ein Prototyp zu einem Produkt wird.

Die Erhöhung von top-k beeinflusst mehr als nur die Vollständigkeit der Ergebnisse. Dadurch kann die Arbeit des Neubewertungsalgorithmus, die Größe des Endkontexts, die Anzahl der Eingabetoken, die Latenz sowie der Ressourcenverbrauch steigen.

Falls die Blöcke im Durchschnitt 600 Token enthalten, dann:

Final K = 5

wird etwa 3.000 abgerufene Token eingespeist. Wechseln Sie zu:

Final K = 15

und Sie kommen dem Wert von 9.000 näher – das ist das Dreifache der ermittelten Masse. Kleine Datenmengen verbergen die tatsächlichen Kosten. Millionen von Anfragen machen daraus eine Produktwahlmöglichkeit. Top-k ist gleichzeitig ein Regler für Qualität, Latenz und Kosten.

Was „Größe der Blöcke und Top-k anpassen“ wirklich bedeutet

Die Interviewfrage verlangt nicht nach zwei magischen Zahlen, sondern nach einem experimentellen Design.

Erstellen Sie etwa 200 repräsentative Abfragen zu Themen wie Fehlerbehebung, Verfahren, Vorfälle/RCA, Richtlinien, Mehrdeutigkeiten, mehrstufigen Abläufen sowie Randfällen. Lassen Sie Fachleute aus dem jeweiligen Bereich die Relevanz beurteilen.

Testen Sie verschiedene Blöckengrößen wie:

Chunk sizes:
256
512
1024
2048

und Überschneidungen der /-K-Matrizen wie:

Overlap:
64
128
256Candidate K:
5
10
20

Eine 4 × 3 × 3-Matrix ergibt etwa 36 Konfigurationen. Bewertet jede mit mehr als einer Zahl:

Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost

Wählen Sie anschließend die beste Lösung hinsichtlich Qualität, Latenz und Kosten – nicht automatisch die mit der höchsten Erinnerungsrate oder F1-Wert.

Gegenintuitive Ergebnisse von Experimenten

Nehmen wir an, drei Konfigurationen ergeben folgende Ergebnisse:

• A: Recall@10 0,94, nDCG@10 0,81, Genauigkeit 0,89, Treuegrad 0,95, P95 510 ms, $0,025
• B: Recall@10 0,91, nDCG@10 0,88, Genauigkeit 0,94, Treuegrad 0,96, P95 560 ms, $0,027
• C: Recall@10 0,97, nDCG@10 0,79, Genauigkeit 0,86, Treuegrad 0,76, P95 820 ms, $0,034

Allein schon der Recall macht C zum Sieger. C liefert die schwächsten Ergebnisse – eine zusätzliche Extraktion scheint der Generierung zu schaden. B weist zwar einen geringeren Recall auf, führt aber bei nDCG, Genauigkeit und Treuegrad vor, wobei nur eine geringe Verzögerungs- bzw. Kostennachteiligung besteht. Das ist die Konfiguration, die genauer untersucht werden sollte – und der Grund, warum „der höchste Extraktionswert gewinnt“ keine gute allgemeine Regel ist. Optimieren Sie stattdessen nach dem tatsächlichen Ziel des Produkts.

Fehler → nächste Untersuchung

• Schwacher Recall@K → Chunking, Embeddings, Index, Metadatenfilter, Abfragesyntax, Extraktionsstrategie

Schöne Erinnerungsfähigkeit, schwacher nDCG → Ranking/Reranking

Schöne Rechercheleistung, schwache Antwortgenauigkeit → Kontextzusammenstellung, Sortierung, Anfragen, Generierung

Plausible, aber ununtermauerte Antworten → Treue/Grundierung

Gute Qualität, schlechte Latenz → Jede Phase genau analysieren

Gute Qualität, hoher Kostenfaktor → Kandidaten-K, End-K, Chunk-Größe, Kompression, Caching, Modellwahl, Token-Effizienz

Diese Checkliste verwandelt das Debuggen in ein strukturiertes Verfahren.

Den Kreislauf in der Produktion am Laufen halten

Ein einmaliger Benchmark ist nicht das Endziel. Man benötigt eine kontinuierliche Bewertung. Reales Traffic unterscheidet sich von sorgfältig zusammengestellten Datensätzen: Formulierungen ändern sich, Dokumente wechseln, Richtlinien werden aktualisiert, neue Dienste erscheinen, es treten Randfälle auf. Erweitern Sie den Bewertungssatz durch Fehler aus der Produktion.

Entwickelte Leistungsübersicht

Niemandlicher Metrik erzählt die ganze Geschichte. Eine nützliche Übersichtskarte zeigt Abdeckung, Rangfolge, Korrektheit, Genauigkeit, Latenzprozente sowie die Kostenstruktur zusammen an.

Fragen Sie erst, bevor Sie einstellen

Wenn jemand eine bestimmte Chunk-Größe und einen Wert für top-k verlangt, beantworten Sie zunächst mit Fragen: Was optimieren wir, wie sieht die gelabelte Datensammlung aus und welchen Kostenfaktor hat ein fehlgeschlagener Abruf? Mit diesen Antworten werden Konfigurationen zu experimentellen Ergebnissen.

Ein mögliches Ergebnis könnte sein:

512 tokens
128 overlap
Candidate K = 20
Final K = 5

Eines weiteren:

1024 tokens
64 overlap
Candidate K = 10
Final K = 4

Semantisches Chunking könnte beide Ansätze übertreffen. Ein Neurankierer könnte dafür sorgen, dass der endgültige Wert K wichtiger ist als der ursprünglich vorgesehene Wert K.

Vertrauen Sie keinem universellen Wert ohne Messung. Ein RAG-System ist nicht „gut“, nur weil es mehr Informationen abruft, schneller arbeitet oder überzeugend klingt. Es ist gut, wenn es die richtigen Belege findet, diese ordnungsgemäß bewertet, dem Modell die richtige Menge an Kontext liefert, Antworten erzeugt, die sowohl korrekt als auch fundiert sind, und sich innerhalb der Latenz- sowie Kostengrenzen des Produkts hält.

Genau diese Lücke – zwischen dem Aufbau einer Pipeline und der Entwicklung eines Produktionsystems – ist das eigentliche Problem.

Hören Sie auf, blind an Einstellungen herumzufummeln

Es gibt keinen mythischen idealen Blocklängenwert, keine einheitliche Top-k-Regel und keinen einzelnen Metrikwert, der eine Bereitstellung für den Einsatz ausweist. Eine höhere Recall@K-Wert kann trotzdem zu schlechten Antworten führen. Starke Informationsabruffähigkeiten können weiterhin unbegründete Behauptungen zulassen. Hohe Genauigkeit kann versagen, wenn bei steigendem Umfang die Latenz oder Kosten in die Höhe schießen.

Balancieren Sie Abdeckung, Ranking, fundierte Erzeugung von Inhalten, Latenz und Kosten für die tatsächlich bearbeiteten Arbeitslasten.

Empfohlen: Ground Truth → Abruf-Benchmarks → Rangierprüfungen → End-to-End-Qualitätskontrolle der Antworten → Validierung von Latenz/Kosten → Unbekannte Fälle → Produktüberwachung → Fehler im Datensatz werden erneut berücksichtigt.

Dann sind chunk_size=512 oder top_k=5 Belege, keine Anekdoten.

Die sechs Metriken auf einer Seite zusammenfassen

Ein praktikabler Leistungsbericht für eine wöchentliche RAG-Überprüfung könnte wie folgt aussehen:

• Recall@K und MRR zur Überprüfung: „Haben wir Beweise gefunden – und wie schnell?“
• nDCG zur Überprüfung: „Haben wir die besten Beweise zuerst platziert?“
• Ehrlichkeit und Korrektheit der Antworten zur Überprüfung: „Blieb die Generierung ehrlich und genau?“
• P50/P95-Latenz zur Überprüfung: „Können die Nutzer warten?“
• Kosten pro erfolgreicher Antwort zur Überprüfung: „Kann das Finanzwesen warten?“

Besprechen Sie sie gemeinsam. Ein Anstieg von Recall@K bei gleichzeitiger Abnahme der Treue ist kein Erfolg. Eine Verringerung der Latenz, die dazu führt, dass nDCG sinkt, ist ebenfalls kein Erfolg. Der Sinn des sechskriteriengestützten Ansatzes besteht darin, diese Abwägungen sichtbar zu machen, anstatt sie in einer einzigen F1-Wertzahl zu verbergen.

Die echten Referenzwerte sind die knappe Ressource

Metriken sind nur so gut wie die darunterliegenden Labels. Wenn Fachleute niemals beurteilen, welche Abschnitte relevant sind, ist Recall@K nutzlos. Wenn niemand die Relevanz bewertet, reduziert sich nDCG auf einen störanfälligen Binärwert. Wenn die Beurteiler der Treue unzuverlässig sind, schwanken die Bewertungsergebnisse.

Budgetieren Sie Zeit für das Anbringen von Labels genauso wie für Experimente zur Embedding-Erstellung. Zweihundert sorgfältig bewertete Abfragen lehren in der Regel mehr als zweitausend unbeschriftete. Erneuern Sie diese Sammlung aus Produktanfragen: Jeder „falsch abgelehnte Fall“, jede „veraltete Passwortregel“ sowie jedes „übersehene Handbuch“ ist ein möglicher Fall.

Von Experiment zu Change Control

Wenn eine Konfiguration offline erfolgreich ist, führen Sie sie wie jede andere Produktivänderung ein. Dokumentieren Sie das durchgelaufene Grid, die erfolgreichen Einstellungen, die Ausreißerergebnisse sowie den akzeptierten Latenz-/Kostenbereich. Beobachten Sie anschließend dieselben Metriken im Live-Traffic über einen Testzeitraum. Falls sich die Produktivabfragen unterscheiden, geben Sie die Fehler wieder in den beschrifteten Datensatz ein und führen das Grid erneut aus. Dieser Kreislauf – und nicht die Standard-Größenangabe in einem Blogbeitrag – ist es, der ein optimiertes System von einer glücklichen Demonstration unterscheidet.

Warum Prototypen lügen

Demo-Notebooks beheben in der Regel das Abfragesatzproblem, konservieren das Korpus und verbergen die Latenz hinter einem einzigen Aufruf. In der Produktion geschieht das Gegenteil: Die Abfragen ändern sich ständig, die Dokumente wechseln, und Nutzer verlassen Seiten mit langsamen Antworten. Deshalb kann eine Konfiguration, die auf einem statischen Benchmark hervorragend aussah, nach dem Start unzuverlässig wirken. Die sechs oben genannten Metriken bieten eine Möglichkeit, diese versteckten Aspekte bereits vor dem Veröffentlichen sichtbar zu machen und auch danach weiterhin im Blick zu behalten.

Wenn jemand nach einer Standard-Größenangabe für die Datensätze sowie einem Standard-Wert für „top-k“ fragt, sollte diese Anfrage in einen Experimentenplan umgewandelt werden. Geben Sie das Ziel an, den beschrifteten Datensatz, das Latenzbudget sowie die Kostenobergrenze. Lassen Sie anschließend das Grid die entsprechenden Zahlen ermitteln. Alles Weitere ist reine Spekulation, getarnt als Ingenieurwesen.

Halten Sie die Leistungsübersicht in der wöchentlichen Besprechung sichtbar, damit alle Teammitglieder die Abwägungen stets erkennen können.