Retrieval-Qualität ist die Familie von Metriken, die misst, ob eine RAG-Pipeline tatsächlich den richtigen Kontext für die Anfrage zur Oberfläche bringt. Die Antwort des Modells ist nur so gut wie das, was retrievt wurde; Retrieval separat von Generierung zu messen, ist das, was Ihnen sagt, welche Schicht der Bottleneck ist.
Die Kern-Metriken.
- Recall@k. Von den Dokumenten, die hätten retrievt werden sollen, welcher Anteil schaffte es in die top k? Ein Workflow mit Recall@10 von 0.6 verfehlt 40% des relevanten Kontexts.
- Precision@k. Von den Dokumenten in den top k, welcher Anteil ist tatsächlich relevant? Niedrige Precision bedeutet, der Generator watet durch Noise.
- MRR (Mean Reciprocal Rank). Wie hoch rankt das erste korrekte Dokument, durchschnittlich über Anfragen? MRR = 0.5 bedeutet, das erste relevante Doc ist durchschnittlich Zweites in der Liste.
- nDCG. Discounted Cumulative Gain — erfasst die volle Ranking-Qualität, gewichtet nach Position. Die informativste einzelne Metrik für geordnetes Retrieval.
Warum Retrieval separat messen.
Wenn RAG-Antworten schief gehen, ist der Failure entweder upstream (Retrieval verpasste den relevanten Chunk) oder downstream (Generierung ignorierte den relevanten Chunk). Ohne Retrieval-Qualität separat gemessen sieht jede Regression wie ein Modell-Problem aus. Mit ihr wissen Sie, ob in Embeddings, Reranker, Chunking oder in Prompt- und Modell-Änderungen investiert werden soll.
«Schlechte Antworten aus einem RAG-System sind meistens ein Retrieval-Bug, der sich als Modell-Bug tarnt.»
Das Fixture-Set bauen.
Eine Retrieval-Qualitäts-Fixture ist eine Anfrage plus eine gelabelte Liste relevanter Dokumente im Korpus. Sourcing: echte Produktions-Anfragen plus ein Human-Pass, der labelt, welche Korpus-Dokumente sie tatsächlich beantworten. 50–200 Anfragen reichen zum Start; skalieren Sie hoch, während der Korpus wächst.
Häufige Fragen.
- Was ist Retrieval-Qualität?
- Retrieval-Qualität ist die Familie von Metriken — Recall@k, Precision@k, MRR, nDCG —, die misst, ob eine RAG-Pipeline den richtigen Kontext für die Anfrage zur Oberfläche bringt. Gemessen gegen ein gelabeltes Fixture-Set, separat vom Generierungs-Schritt, sodass Sie wissen, welche Schicht der Bottleneck ist.
- Warum Retrieval separat von Generierung messen?
- Weil schlechte RAG-Antworten von beiden Schichten kommen können, und der Fix unterschiedlich ist, je nachdem welche. Niedrige Retrieval-Qualität heisst in Embeddings, Reranker, Chunking investieren. Niedrige Generierungs-Qualität auf gutem retrievten Kontext heisst in Prompts, Modelle oder Output-Validierung investieren. Ohne separat zu messen sieht jeder Bug wie ein Modell-Bug aus.
- Was ist ein gutes Retrieval@k-Ziel?
- Workload-spezifisch. Für einen eng-gescopten Korpus mit klaren faktischen Anfragen ist Recall@10 über 0.9 erreichbar und erwartet. Für breite, semantische, konversationelle Korpora ist Recall@10 über 0.75 gut. Die Eval-Harness misst beide gegen die echte Anfrage-Verteilung statt gegen einen Benchmark-Datensatz.
- Wie interagiert Retrieval-Qualität mit Faithfulness?
- Sie sind komplementär. Retrieval-Qualität misst, ob der richtige Kontext gefunden wurde. Faithfulness misst, ob das Modell den Kontext nutzte, den es bekam. Ein Workflow kann hohe Faithfulness und niedriges Retrieval haben (das Modell ist ehrlich über das, was es hat, aber es hat nicht genug) oder niedrige Faithfulness auf gutem Retrieval (das Modell hat trotz Antwort erfunden). Produktion braucht beide über Ziel.
Englische Fassung: Retrieval-Qualität on the EN edition.