RAG-Evaluation-Metriken: Retrieval-Qualität messen, bevor du das Modell beschuldigst

Ein RAG-Feature gibt in einer Demo eine falsche Antwort, und der Raum kommt innerhalb von Sekunden zum selben Schluss: Das Modell ist nicht gut genug. Jemand schlägt ein größeres Modell vor, jemand anderes einen anderen Anbieter, und ein Sprint verschwindet in Prompt-Tuning, das nichts ändert. Der fehlende Schritt ist die Messung. RAG-Evaluation-Metriken sagen dir, ob die Retrieval-Schicht dem Modell tatsächlich den richtigen Kontext übergeben hat, und in den meisten fehlschlagenden Pipelines hat sie das nicht. Bevor du den Generierungs-Prompt anfasst oder das LLM aufrüstest, brauchst du Zahlen, die ein Retrieval-Problem von einem Generierungsproblem trennen.

In diesem Beitrag geht es um diese Zahlen. Nicht die akademischen Varianten, die du nie berechnen wirst, sondern die Handvoll Retrieval-Metriken, die auf ein Dashboard passen und dir sagen, wo der Fehler wohnt. Ich definiere jede in einfachen Worten, zeige, wie ein schlechter Score in der Praxis aussieht, und erkläre, wie man eine kleine Offline-Harness zusammenbaut, die man vor jeder bedeutsamen Änderung an der Pipeline laufen lassen kann.

Warum "das Modell beschuldigen" fast immer falsch ist

Retrieval-Augmented Generation hat zwei Stufen, und die Fehlermodi sehen von außen identisch aus. Ein Nutzer stellt eine Frage, dein System ruft einige Chunks aus einem Vektorspeicher ab, und das Modell schreibt eine Antwort mit diesen Chunks. Wenn die Antwort falsch ist, kann es daran liegen, dass das Modell schlecht über guten Kontext argumentiert hat, oder daran, dass das Modell perfekt über schlechten Kontext argumentiert hat. Die Ausgabe sieht gleich aus: ein selbstbewusster, flüssiger, falscher Absatz.

Der Instinkt, das Modell zu beschuldigen, ist verständlich, weil das Modell der Teil ist, der den sichtbaren Text produziert hat. Aber in den Pipelines, die wir bei Code-Audits und KI-Integrationsarbeit prüfen, ist der abgerufene Kontext weit häufiger falsch als die Argumentation. Das Modell tut meist genau, worum du gebeten hast: Es fasst zusammen, welche Chunks auch immer angekommen sind. Wenn der richtige Chunk nie zurückkam, wird dich kein Modell-Upgrade retten. Deshalb fokussieren RAG-Evaluation-Metriken zuerst auf die Retrieval-Schicht. Du misst, was zurückkam, bevor du beurteilst, was das Modell damit gemacht hat.

Die praktische Konsequenz ist eine Regel, die es wert ist, an die Wand zu schreiben: Tune niemals die Generierung, bevor das Retrieval gemessen ist. Ein Team, das Modelle austauscht, während der Retrieval-Recall bei 0,4 liegt, optimiert die falsche Hälfte des Systems.

Die zentralen RAG-Evaluation-Metriken für Retrieval

Du brauchst ein gelabeltes Evaluation-Set, um irgendeine davon zu berechnen. Das bedeutet eine Liste repräsentativer Fragen und für jede Frage die Menge der Dokument-Chunks, die die Antwort wirklich enthalten. Dieses Set aufzubauen ist die eigentliche Arbeit, und ich komme darauf zurück. Sobald du es hast, tragen vier Metriken den Großteil des Signals.

Precision at k beantwortet die Frage: Von den top k Chunks, die ich abgerufen habe, wie viele waren tatsächlich relevant? Wenn du 5 Chunks abrufst und 2 davon antwortrelevanten Inhalt enthalten, ist Precision@5 gleich 0,4. Niedrige Precision bedeutet, dass du das Kontextfenster des Modells mit Rauschen vollstopfst. Das Modell muss dann irrelevante Chunks ignorieren, und das gelingt ihm oft nicht, was Antworten produziert, die in Richtung des abgelenkten Textes driften, der abgerufen wurde.

Recall at k beantwortet das Umgekehrte: Von allen Chunks, die die Antwort enthalten, wie viele haben es in die top k geschafft? Wenn eine Frage 3 relevante Chunks in deinem Korpus hat und nur 1 in den top 5 erscheint, ist Recall@5 gleich 0,33. Niedriger Recall ist der schädlichste Fehler in RAG, weil das Modell keine Information zitieren kann, die es nie erhalten hat. Wenn der Recall schlecht ist, ist die Antwort unvollständig oder halluziniert, und kein Prompt-Engineering behebt das.

Mean Reciprocal Rank (MRR) misst, wie hoch der erste relevante Chunk in deinem Ranking sitzt. Wenn der erste korrekte Chunk auf Position 1 steht, ist der reziproke Rang 1. Wenn er auf Position 4 steht, ist der reziproke Rang 0,25. Gemittelt über dein Evaluation-Set sagt dir MRR, ob dein Reranking guten Kontext nach oben bringt, wo das Modell ihn am stärksten gewichtet. Eine Pipeline kann ordentlichen Recall haben und trotzdem schlecht antworten, weil der relevante Chunk auf Position 8 hinter sieben ablenkenden begraben liegt.

Context Relevance ist die weichere, urteilsbasierte Metrik. Für jeden abgerufenen Chunk fragst du: Ist dieser tatsächlich zum Thema der Frage passend? Du kannst das mit menschlichen Bewertern an einer Stichprobe scoren oder mit einem LLM-as-Judge-Prompt in großem Maßstab. Context Relevance fängt den Fall ab, in dem Chunks thematisch benachbart, aber nicht antworttragend sind, was Keyword- und Embedding-Ähnlichkeitsscores bereitwillig belohnen.

Diese vier decken die meisten Diagnosen ab. Precision und Recall sagen dir, was der Retriever gefunden und verpasst hat. MRR sagt dir, ob die Rangfolge hilft oder schadet. Context Relevance sagt dir, ob "ähnlich" für deinen Korpus tatsächlich "nützlich" bedeutet.

Die Metriken zusammen lesen

Die diagnostische Kraft entsteht, wenn man die Metriken als Muster betrachtet, nicht isoliert.

Hoher Recall und niedrige Precision bedeutet, dass du die richtigen Chunks abrufst, aber auch viel Müll. Der Fix ist meist ein Reranker oder ein kleineres k, kein anderes Embedding-Modell. Du findest die Antwort, du ertränkst sie nur.

Niedriger Recall unabhängig von der Precision ist der ernste Fall. Die antworttragenden Chunks sind überhaupt nicht in deiner Kandidatenmenge. Sieh dir zuerst die Chunking-Strategie an, denn Chunks, die eine Tatsache über Grenzen hinweg zerteilen, können nicht als Ganzes abgerufen werden, dann sieh dir die Passung des Embedding-Modells zu deiner Domäne an und ob deine Query auf dieselbe Weise eingebettet wird wie deine Dokumente.

Guter Recall und gute Precision, aber schlechte Antworten deutet zurück auf die Generierung oder auf das Ranking. Prüfe MRR. Wenn der relevante Chunk konsequent begraben liegt, gewichtet das Modell frühere, irrelevante Chunks stärker. Wenn MRR ebenfalls gesund ist und die Antworten trotzdem falsch sind, erst dann hast du ein echtes Generierungsproblem, das eine Prompt- oder Modelländerung wert ist.

Diese Reihenfolge zählt, weil sie das teure Raten stoppt. Jede Metrik verengt den Suchraum für den Fix, sodass ein Sprint zu der Schicht geht, die tatsächlich kaputt ist.

Eine Offline-Eval-Harness bauen, die du wirklich laufen lässt

Eine Metrik, die du einmal in Panik berechnest, ist kein Evaluation-System. Der Sinn ist, diese Zahlen automatisch, offline, jedes Mal laufen zu lassen, wenn du die Chunk-Größe änderst, ein Embedding-Modell austauschst, k anpasst oder einen Reranker hinzufügst. Das verwandelt RAG-Evaluation-Metriken von einem forensischen Werkzeug in ein Regression-Gate.

Beginne mit dem Datensatz, denn das ist der schwere Teil. Sammle 50 bis 100 echte Fragen, idealerweise aus tatsächlichen Nutzer-Logs statt erfundenen, da echte Queries unordentlicher und aufschlussreicher sind als die sauberen Beispiele, die ein Entwickler schreibt. Für jede Frage lass einen Domänenexperten identifizieren, welche Chunks in deinem Korpus die Antwort enthalten. Dieses Labeling ist mühsam und es gibt keine Abkürzung, aber 50 gut gelabelte Fragen sind mehr wert als 5.000 synthetische. Du kannst den ersten Durchgang mit einem LLM bootstrappen, das Kandidaten für relevante Chunks vorschlägt, und dann einen Menschen bestätigen lassen, was die Labeling-Zeit deutlich reduziert.

Mit dem Set an Ort und Stelle ist die Harness mechanisch. Für jede Frage führe das Retrieval aus, erfasse die gerankten Chunk-IDs und vergleiche gegen die gelabelte relevante Menge, um Precision@k, Recall@k und MRR zu berechnen. Lass einen Context-Relevance-Judge über eine Stichprobe laufen. Speichere den Lauf mit einem Zeitstempel und der Konfiguration, die ihn erzeugt hat. Der erste Lauf wird zu deiner Baseline, und jede nachfolgende Änderung wird dagegen gemessen statt gegen ein Gefühl.

Zwei Praktiken halten die Harness ehrlich. Versioniere das Evaluation-Set zusammen mit deinem Code, sodass eine Metrikänderung immer entweder einer Pipeline-Änderung oder einer bewussten Datensatzänderung entspricht, nie einem stillen Drift. Und trenne Retrieval-Metriken von der End-to-End-Antwortqualität, denn ein einzelner gemischter Score verbirgt genau die Precision-versus-Recall-Unterscheidung, die dir sagt, wo du hinsehen musst. Wenn du pgvector auf einem Symfony- oder Next.js-Stack betreibst, fügt sich die Harness neben deine bestehende Testsuite, und die Schema-Arbeit, die wir in unserem Symfony- und pgvector-Architektur-Blueprint behandeln, gibt dir die Chunk- und Metadatenstruktur, die diese Metriken brauchen. Für die vorgelagerten Chunking- und Reranking-Fehler, die diese Metriken zutage fördern, behandelt unser Durchgang zu warum RAG-Pipelines selbstbewussten Unsinn zurückgeben die Fixes im Detail.

Wie gut aussieht

Es gibt keine universelle Bestehensgrenze, weil akzeptabler Recall für einen Kundensupport-Bot sich von akzeptablem Recall für ein System unterscheidet, das juristische Zusammenfassungen entwirft. Was zählt, sind Richtung und Stabilität. Du willst Recall@k hoch genug, dass die antworttragenden Chunks zuverlässig vorhanden sind, MRR hoch genug, dass sie nah an der Spitze sitzen, und Precision hoch genug, dass das Modell nicht durch Rauschen waten muss, um sie zu finden. Dann willst du, dass diese Zahlen mit jeder Änderung halten oder sich verbessern, nie leise regredieren.

Die Teams, die zuverlässiges RAG ausliefern, sind nicht die mit dem größten Modell. Es sind die, die "hat sich das Retrieval verbessert oder verschlechtert?" mit einer Zahl statt einer Meinung beantworten können. Sobald du das hast, ändert sich das Gespräch im Raum. Niemand rät am Modell herum. Jemand ruft die Metriken auf und zeigt auf die Schicht, die tatsächlich versagt.

Wenn du ein RAG-Feature debuggst, das in der Demo funktioniert und in der Produktion auseinanderfällt, oder du ein zweites Paar Augen auf einer Pipeline willst, bevor sie ausgeliefert wird, helfen wir Teams, genau diese Art von Messung in ihre Individualsoftware einzubauen. Erreiche uns unter hello@wolf-tech.io oder auf wolf-tech.io, und bring deine schlechteste Query mit. Sie erzählt meist die ganze Geschichte.