Die Metrik, die uns zu oft recht gab
Sechs Wochen lang stieg unser Treue-Wert, und die Supportanfragen stiegen mit. Die Metrik war nicht kaputt. Sie beantwortete eine engere Frage, als wir zu stellen glaubten.
Zwei Kurven, die gemeinsam in die falsche Richtung liefen
Wir hatten eine automatische Bewertung auf einem Retrieval-Assistenten und stimmten wöchentlich dagegen ab. Die Treue stieg, die Antwortrelevanz stieg, das Team war zufrieden. Im selben Zeitraum stiegen die Tickets, die eine Variante von „das war nicht meine Frage“ enthielten.
Beide Messungen waren korrekt. Sie handelten von verschiedenen Dingen, und wir hatten die eine für die andere stehen lassen, weil sie diejenige war, die jede Nacht eine Zahl lieferte.
Was die Metrik tatsächlich fragt
Es und Kollegen haben ein referenzfreies Verfahren zur Bewertung von Retrieval-Pipelines vorgelegt: die erzeugte Antwort gegen den abgerufenen Kontext beurteilen, ohne für jeden Fall eine von Hand geschriebene Referenz zu brauchen. Das ist ein echter Fortschritt, denn die Referenz ist der teure Teil, und ihr Fehlen ist der Grund, warum die meisten Teams gar nicht bewerten.
Treue fragt, ob die Antwort durch die abgerufenen Passagen gedeckt ist. Das ist eine Frage nach innerer Stimmigkeit. Sie kann nicht fragen, ob es die richtigen Passagen waren, denn die Passagen sind ihr Maßstab.
Der Fehler, den sie nicht sehen kann
Unsere Regression war Retrieval-Drift. Eine Indexänderung hatte unbemerkt begonnen, einen neueren Dokumentbestand zu bevorzugen, und die Antworten wurden treu und relevant in den falschen Datensätzen verankert. Jedes automatische Signal meldete Verbesserung, weil jede Antwort zu ihrem Kontext passte.
Das ist kein Mangel des Verfahrens. Eine referenzfreie Metrik ist bauartbedingt blind für den Fall, dass der Kontext falsch ist, und die Papers behaupten auch nichts anderes. Der Fehler lag bei uns: Wir haben eine Stimmigkeitsprüfung als Richtigkeitsprüfung verwendet.
| Was der automatische Wert beantwortet | Was er nicht beantworten kann |
|---|---|
| Ist die Antwort im Kontext verankert | War das der richtige Kontext |
| Geht die Antwort auf die Frage ein | Ist der zugrunde liegende Datensatz aktuell |
| Jede Nacht, über alle Fälle | Ob sich der Bestand darunter verschoben hat |
| Ohne menschliche Auszeichnung | Was der Nutzer eigentlich wollte |
Was wir daruntergelegt haben
Ein kleines, von Hand gepflegtes Referenzset: rund achtzig echte Fragen mit dem Datensatz, der sie beantworten soll, ausgewählt entlang der unangenehmen Stellen der Domäne statt entlang des Durchschnittsfalls. Es läuft gegen jedes Release.
Achtzig ist klein genug, dass ein Fachexperte es an einem Nachmittag durchsehen kann, und groß genug, dass eine Retrieval-Regression als mehrere Fehler auffällt statt als einer. Die automatischen Metriken laufen weiterhin nächtlich über alles. Das Referenzset entscheidet, ob wir ausliefern.
Wie wir beide zusammen lesen
Der automatische Wert ist Trendlinie und Rauchmelder: Ein plötzlicher Einbruch heißt, etwas ist kaputt, und dafür lohnt es sich aufzustehen. Er ist kein Beleg dafür, dass eine Änderung eine Verbesserung war.
Das Referenzset ist das Gate. Wenn beide sich widersprechen — Werte hoch, Referenzset runter — glauben wir dem Referenzset und suchen, was sich im Retrieval bewegt hat. Das ist dreimal vorgekommen, und jedes Mal hatte das Referenzset recht.
Was wir daraus nicht schließen
Wir schließen nicht, dass automatische RAG-Bewertung den Aufwand nicht lohnt. Sie ist günstig, deckt Fälle ab, die ein Referenzset nie erreicht, und hat uns zwei echte Prompt-Regressionen gemeldet, bevor sie jemandem auffielen.
Wir behaupten auch nicht, achtzig ausgezeichnete Fälle reichten für Sicherheit. Sie reichen, um uns die offensichtlichen Fehler nicht ausliefern zu lassen — eine niedrigere Messlatte, aber eine ehrliche.