Wie man die Qualität von Embeddings misst: recall@k, MRR und domänenspezifische Benchmarks

Regelmäßig sehen wir dasselbe Szenario: Ein Team wählt ein Embedding-Modell basierend auf seiner Position im MTEB-Ranking aus, setzt es in Produktion ein und stellt erst nach einigen Wochen aufgrund von Nutzerbeschwerden fest, dass der Assistent offensichtliche Dokumente nicht findet. Ein öffentlicher Benchmark zeigt, wie gut das Modell mit fremden Daten auf Englisch zurechtkommt. Er sagt nichts darüber aus, wie es mit deinen Verträgen, ISO-Verfahren oder Serviceanfragen auf Polnisch umgehen wird. Die einzige zuverlässige Messung ist die Evaluierung auf einem Set, das die realen Anfragen deiner Nutzer widerspiegelt.

Die Evaluierung der semantischen Suche lässt sich auf eine Frage reduzieren: Erscheinen für eine gegebene Anfrage die richtigen Fragmente hoch in der Ergebnisliste? Drei sich ergänzende Metriken messen dies.

Recall@k gibt an, welcher Anteil der erwarteten Fragmente in den Top k Ergebnissen gefunden wurde. Das ist die Metrik für „Haben wir überhaupt etwas gefunden“. Wenn du 3 relevante Dokumente erwartest und in den Top 5 zwei davon erscheinen, beträgt recall@5 0,67. Recall@k ist entscheidend für RAG, weil das generative Modell nur das sieht, was der Retrieval-Prozess liefert; ein fehlendes Fragment bedeutet fehlenden Kontext und das Risiko von Halluzinationen.

MRR (Mean Reciprocal Rank) misst, wie hoch der erste relevante Treffer erscheint. Für eine Anfrage, bei der das relevante Dokument auf Position 1 steht, beträgt der Beitrag 1; auf Position 2 ist es 1/2; auf Position 4 ist es 1/4. MRR bildet den Durchschnitt dieser Kehrwerte über alle Anfragen. Ein hoher MRR bedeutet, dass du oft „auf Anhieb“ triffst, was es ermöglicht, dem Modell weniger Kontext zu geben und die Token-Kosten zu senken.

nDCG (normalized Discounted Cumulative Gain) ist die anspruchsvollste der drei Metriken. Sie berücksichtigt nicht nur, ob ein relevanter Treffer hoch platziert ist, sondern auch den Grad der Relevanz (du kannst Fragmente als „sehr relevant“ oder „teilweise relevant“ markieren) und bestraft das Platzieren schwächerer Treffer über besseren. nDCG lohnt sich, wenn du abgestufte Relevanzbewertungen hast und nicht nur eine binäre „passt/passt nicht“-Einschätzung.

Die Zahlen in der Spalte „Schwellenwert“ sind Bereiche, die wir in Projekten mit polnischen Unternehmensdokumenten beobachtet haben, keine universellen Konstanten. Betrachte sie als Referenzpunkt zur Kalibrierung, nicht als Selbstzweck.

Ohne Golden Set gibt es nichts zu messen. Ein Golden Set ist eine Liste von Paaren: realistische Frage + Menge der Fragmente, die als Antwort erscheinen sollten. Der Aufbau sieht wie folgt aus.

Beginne mit dem Sammeln von 50-100 echten Fragen. Die beste Quelle sind Logs echter Anfragen an den Assistenten, Support-Tickets oder Interviews mit den Personen, die das System nutzen werden. Am Schreibtisch ausgedachte Fragen sind zu regelmäßig und spiegeln nicht die Sprache der Nutzer wider, die mit Fehlern, Abkürzungen und in verschiedenen Kasus schreiben.

Für jede Frage markierst du relevante Fragmente. Hier stellt sich die Entscheidung: Binäre Bewertungen (passt/passt nicht) sind schneller, abgestufte Bewertungen (sehr relevant / teilweise relevant / nicht relevant) liefern ein reichhaltigeres Signal für nDCG. Für die erste Iteration reichen binäre Bewertungen. Die Annotation sollte von einer Person durchgeführt werden, die die Domäne kennt, nicht von einem Sprachmodell, denn das Modell ist hier das zu bewertende Objekt.

Wichtig ist, dass das Evaluierungskorpus genau so indiziert wird wie das produktive: dieselbe Chunking-Strategie, dieselbe Fragmentgröße, dasselbe Modell. Wenn du das Chunking zwischen Test und Produktion änderst, verlieren die Metriken ihre Aussagekraft. Die Wahl der Vektordatenbank selbst behandeln wir separat im Artikel darüber, wie man eine Vektordatenbank auswählt.

Auf dem Golden Set berechnete Metriken sind eine Offline-Evaluierung: kontrolliert, wiederholbar, kostengünstig. Sie haben jedoch Grenzen, die nicht ignoriert werden dürfen.

Der erste Fallstrick ist das Überanpassen an das Golden Set. Wenn du den Pipeline wiederholt auf denselben Satz von 80 Fragen abstimmst, optimierst du schließlich für diese spezifischen Fragen und nicht für reale Anfragen. Halte einen Teil der Paare als „Validierungsset“ zurück, das du nicht zum Abstimmen verwendest. Der zweite Fallstrick ist der Daten-Drift: Ein Golden Set, das auf einem Korpus von vor einem halben Jahr basiert, spiegelt nicht mehr die Dokumente wider, die seitdem hinzugekommen sind.

Die Online-Evaluierung misst das Verhalten im Live-Betrieb: Klickrate der Ergebnisse, Anteil der Anfragen, die an einen Menschen eskaliert werden, Daumen-hoch/-runter-Bewertungen, Anteil der als nicht relevant markierten Antworten. Das Signal ist „schmutziger“ als bei der Offline-Evaluierung, aber es sagt die Wahrheit über die Nutzererfahrung aus. Die beste Praxis ist die Kombination beider Ansätze: Offline als schnelle Hürde bei jeder Änderung des Modells oder Chunkings, Online als endgültiger Schiedsrichter in der Produktion. Dieselbe Aufteilung zwischen Offline/Online wenden wir bei der Evaluierung von KI-Agenten an, wo synthetische Tests Regressionen überprüfen und produktive Metriken den realen Wert bestätigen.

Der dritte Fallstrick ist spezifisch für RAG: Guter Retrieval ist eine notwendige, aber nicht hinreichende Bedingung für eine gute Antwort. Du kannst einen recall@5 von 85% haben, und die Nutzer sind trotzdem unzufrieden, weil das generative Modell den gefundenen Kontext schlecht zusammenfasst. Deshalb solltest du Retrieval-Metriken separat von den Metriken für die Antwortqualität (Faithfulness, Relevanz) messen. Die Vermischung dieser beiden Ebenen ist der häufigste diagnostische Fehler, den wir sehen.

Die polnische Flexion führt dazu, dass die Evaluierung von Embeddings für Polnisch mit Vorsicht erfolgen muss. Ein Nutzer fragt nach „fakturę“ (Rechnung), aber das Dokument enthält „faktur“ (Genitiv Plural), „fakturze“ (Dativ Singular), „fakturami“ (Instrumental Plural). Ein schwaches Modell für Polnisch behandelt diese Formen als entfernte Punkte, sodass das relevante Fragment im Ranking abrutscht, obwohl es inhaltlich perfekt passt. Im Golden Set solltest du bewusst Fragen in verschiedenen Kasus und mit nachlässig gesetzter Diakritik („wez“ statt „weź“) einbauen, denn so schreiben reale Nutzer.

Ein zweiter Faktor ist das mehrsprachige Validierungskorpus. Polnische Unternehmensdokumente sind voller englischer Begriffe: compliance, vendor, deliverable, SLA. Wenn dein Golden Set nur aus sauberen polnischen Sätzen besteht, überschätzt du die Qualität des Modells für Daten, die in Wirklichkeit zweisprachig sind. Bei der Modellauswahl lohnt es sich, eines mit einem umfangreichen mehrsprachigen Korpus zu wählen, zum Beispiel BGE-M3; mehr dazu im Artikel über Embeddings für die polnische Sprache.

Ein dritter Punkt: Wenn der reine Vektor-Retrieval bei polnischen Fachbegriffen und Katalognummern nicht ausreicht, solltest du messen, wie viel hybride Suche hinzufügt. Berechne recall@5 für reine Vektoren und dann für Vektoren kombiniert mit BM25 auf demselben Golden Set. Wenn der Unterschied einige Prozentpunkte übersteigt, lohnt sich die Hybridlösung. All diese Vergleiche sind nur dann sinnvoll, wenn du jeweils nur eine Variable änderst und auf einem unveränderten Testset misst.

Für eine erste, orientierende Bewertung reichen 50-100 sorgfältig ausgewählte Paare. Ein solches Set deckt grobe Unterschiede zwischen Modellen auf und ermöglicht es, offensichtlich schwache Optionen auszuschließen. Für stabile, statistisch belastbare Vergleiche zwischen ähnlichen Modellen solltest du 200-300 Paare anstreben, da bei kleinen Stichproben einige schwierige Fragen das Ergebnis um einige Prozentpunkte verschieben können.

Recall@k gibt an, welcher Anteil aller relevanten Fragmente in den Top k gefunden wurde, misst also die Abdeckung. Precision@k gibt an, welcher Anteil der Ergebnisse in den Top k tatsächlich relevant ist, misst also die „Reinheit“ der Liste. In RAG hat meist der Recall Priorität, weil fehlender Kontext schmerzhafter ist als ein überflüssiges Fragment, das das generative Modell ohnehin ignoriert. Precision gewinnt an Bedeutung, wenn falsche Treffer kostspielig oder irreführend sind.

Öffentliche Benchmarks sind nützlich als erster Filter, um die Liste der Kandidaten einzugrenzen, aber sie ersetzen keine Messung auf deinen eigenen Daten. Die Korpora von MTEB und BEIR sind größtenteils englischsprachig und allgemeindomänig, daher sagen sie wenig über das Verhalten bei polnischen Verträgen oder Serviceanfragen aus. Betrachte das Ranking als Ausgangspunkt, aber treffe die Entscheidung basierend auf deinem eigenen Golden Set.

Das Offline-Golden Set sollte bei jeder Änderung des Modells, der Chunking-Strategie oder des Rerankers neu berechnet werden, da es eine schnelle Regressionstest-Hürde darstellt. Unabhängig davon solltest du das Golden Set einmal pro Quartal mit neuen Produktionsanfragen aktualisieren, um mit dem Daten- und Sprachdrift der Nutzer Schritt zu halten. Online-Metriken (Bewertungen, Eskalationen) solltest du kontinuierlich überwachen, ähnlich wie beim Monitoring der Qualität eines KI-Agenten.

Nein. Ein hoher Recall bedeutet nur, dass relevante Fragmente in den Kontext gelangen, was eine notwendige, aber nicht hinreichende Bedingung ist. Das generative Modell kann guten Kontext schlecht zusammenfassen, einen entscheidenden Detail weglassen oder Informationen außerhalb der Quelle hinzufügen. Deshalb solltest du die Qualität des Retrievals (Recall, MRR, nDCG) separat von der Antwortqualität (Faithfulness, Relevanz) messen, denn es handelt sich um zwei verschiedene Ebenen mit unterschiedlichen Fehlerursachen.