Retrieval-Metriken: Hit Rate, MRR und NDCG

Die Hit Rate zeigt, ob irgendwo in den Top-K-Ergebnissen ein relevanter Chunk auftaucht, sagt aber nicht, an welcher Stelle der Rangliste er steht. Ein System, das den besten Chunk immer auf Rang 5 platziert, ist schlechter als eines, das ihn konsequent auf Rang 1 platziert, selbst wenn beide dieselbe Hit Rate haben. Genauere Metriken wie MRR und NDCG erfassen die Ranking-Qualität und belohnen Systeme, die die relevantesten Chunks ganz oben platzieren, wo das LLM und die Benutzer sie am wahrscheinlichsten verwenden.

Hit Rate@K ist die einfachste Metrik: Bei welchem Anteil der Abfragen erscheint mindestens ein relevanter Chunk in den Top-K-Ergebnissen? Sie liefert pro Abfrage ein binäres Signal und ist leicht zu interpretieren. Berechnen Sie sie, indem Sie die Schnittmenge der abgerufenen IDs und der bekannten relevanten IDs prüfen. Verwenden Sie standardmäßig K=5, da die meisten RAG-Systeme fünf Chunks abrufen. Vergleichen Sie Hit Rate@1, @3 und @5, um zu verstehen, wie sich die Trefferquote verändert, wenn Sie das Retrieval-Fenster vergrößern.

MRR (Mean Reciprocal Rank) misst den durchschnittlichen Kehrwert des Rangs, auf dem der erste relevante Chunk erscheint. Befindet sich der relevante Chunk auf Rang 1, beträgt der reziproke Rang 1/1 = 1,0. Auf Rang 2 beträgt er 0,5, auf Rang 5 0,2. Der MRR wird über alle Abfragen gemittelt. Ein höherer MRR bedeutet, dass der Retriever relevante Chunks konsequent weit oben platziert. Das ist wichtig, weil das LLM Kontext, der früh im Prompt steht, stärker berücksichtigt.

MRR-Werte lassen sich intuitiv interpretieren: MRR = 1,0 bedeutet, dass der erste relevante Chunk immer auf Rang 1 steht (perfekt). MRR = 0,5 bedeutet, dass er sich typischerweise auf Rang 2 befindet. MRR = 0,25 bedeutet, dass er sich typischerweise auf Rang 4 befindet – die relevanten Informationen stehen so weit unten, dass sie möglicherweise aus dem Kontext abgeschnitten werden. Für RAG sollten Sie einen MRR > 0,7 anstreben, damit Ihr relevantester Chunk konsequent an einer der ersten beiden Positionen steht.

Precision@K misst, welcher Anteil der K abgerufenen Chunks tatsächlich relevant ist. Anders als die Hit Rate, die binär ist, misst Precision@K das Signal-Rausch-Verhältnis Ihrer Retrieval-Ergebnisse. Eine niedrige Precision bedeutet, dass das LLM neben relevanten Chunks irrelevanten Kontext erhält, wodurch das Risiko von Verwirrung oder Prompt Injection steigt. Für RAG ist eine Precision@5 > 0,6 ein guter Zielwert.

DCG ist eine Metrik zur Bewertung von Ranglisten, die belohnt, wenn mehr relevante Chunks weiter oben stehen. Sie summiert die Relevanzwerte der abgerufenen Chunks und gewichtet sie abhängig von ihrer Position logarithmisch ab: Rang 1 erhält die volle Gewichtung, Rang 2 wird mit log(2) abgewertet und so weiter. Je relevanter die Chunks an den oberen Positionen sind, desto höher ist der DCG. Die normalisierte Variante (NDCG) teilt durch den idealen DCG (das bestmögliche Ranking) und erzeugt so einen Wert zwischen 0 und 1.

NDCG@K ist die Standardmetrik für Retrieval in Suchsystemen. Sie erfasst gleichzeitig Relevanz und Ranking-Position. Ein NDCG@5 von 0,85 bedeutet, dass Ihr Retriever im Durchschnitt 85 % des theoretisch bestmöglichen Rankings erreicht. NDCG unterstützt Fälle mit mehreren relevanten Chunks pro Abfrage, wobei jeder einen Relevanzwert erhält, und bestraft Systeme, die relevante Chunks zwar finden, sie aber zu weit unten platzieren.

Die Bibliothek RAGAS stellt ein produktionsreifes Evaluierungs-Framework für RAG-Systeme bereit. Sie implementiert die Metriken Context Precision, Context Recall, Faithfulness und Antwortrelevanz mithilfe eines LLM-as-Judge-Ansatzes. Übergeben Sie RAGAS Ihre Fragen, Antworten, abgerufenen Kontexte und Ground-Truth-Antworten, und Sie erhalten einen vollständigen Evaluierungsbericht mit Werten für jede Metrik. Dies ist der schnellste Weg, eine umfassende RAG-Evaluierungspipeline einzurichten.

Gesamtdurchschnittswerte verbergen wichtige Muster. Teilen Sie Ihr Golden Dataset in Kategorien auf – das Nachschlagen von Fakten, Vergleiche, prozedurale Anleitungen und Fragen außerhalb des vorgesehenen Anwendungsbereichs – und berechnen Sie die Metriken für jede Kategorie separat. Möglicherweise stellen Sie fest, dass die Hit Rate bei Faktenabfragen 95 %, bei Multi-Hop-Vergleichen jedoch nur 60 % beträgt. Metriken auf Kategorieebene machen die spezifischen Fehlerarten sichtbar, die aggregierte Werte verbergen.

Manchmal liefern Metriken widersprüchliche Signale. Sie verbessern möglicherweise den NDCG (besseres Ranking), während die Hit Rate unverändert bleibt (gleich viele verfehlte Abfragen). Das geschieht, wenn eine Optimierung relevante Chunks von Rang 6 auf Rang 2 verschiebt, ohne zuvor verfehlte Abfragen in die Top 5 zu bringen. Prüfen Sie in solchen Fällen, ob Ihre Optimierung bei den bereits erfolgreichen Abfragen geholfen und die fehlerhaften vernachlässigt hat. Untersuchen Sie neben aggregierten Metriken immer auch einzelne Fehlerbeispiele.

Recall@K misst, welcher Anteil aller relevanten Chunks in den Top-K-Ergebnissen abgerufen wurde. Wenn eine Frage im Index drei relevante Chunks hat und Ihr Retriever zwei davon in den Top 5 zurückgibt, beträgt Recall@5 2/3 = 0,67. Ein hoher Recall ist wichtig, wenn das LLM mehrere Belegstücke benötigt, um eine vollständige Antwort zu formulieren – schon das Fehlen eines einzigen wichtigen Chunks kann die Antwort unvollständig machen. Stimmen Sie Precision und Recall durch die Wahl von K aufeinander ab: Ein höheres K verbessert den Recall, senkt aber die Precision.

In dieser Lektion haben Sie gelernt: Hit Rate@K als Metrik für das binäre Vorhandensein, MRR zur Messung der durchschnittlichen Rangposition des ersten relevanten Chunks, Precision@K für das Signal-Rausch-Verhältnis des Retrievals, NDCG@K als Standardmetrik für Ranglisten und die RAGAS-Bibliothek zur Automatisierung der RAG-Evaluierung mit Context Precision, Recall, Faithfulness und Antwortrelevanz. Als Nächstes gehen wir ausführlicher auf Generierungsmetriken und die Messung von Faithfulness ein.