Ein RAG-Evaluations-Harness für den Finanzbereich ist ein wiederholbarer Test, der zwei Dinge getrennt bewertet: ob das Retrieval die Passage gefunden hat, die die Frage beantwortet, und ob die generierte Antwort in dem verankert ist, was abgerufen wurde. Sie bauen ein gelabeltes Fragen-Set aus realen Dokumenten, lassen die Pipeline bei jeder Änderung dagegen laufen und beobachten, wie sich eine zentrale Kennzahl bewegt, bevor irgendetwas in Produktion geht.
Der Grund, diese beiden Messungen zu trennen, ist, dass sie aus unterschiedlichen Gründen brechen und man sie an unterschiedlichen Stellen behebt. Ein Einbruch der Retrieval-Qualität ist ein Indexierungs-, Chunking- oder Ranking-Problem. Ein Einbruch der Faithfulness bei gleichbleibendem Retrieval ist ein Prompt- oder Modellproblem. Verschmelzen Sie beides zu einem einzigen “Accuracy”-Score, verlieren Sie die Fähigkeit zu erkennen, welche Hälfte Sie beheben müssen. Die meisten Teams lernen das auf die langsame Tour – nach einer selbstbewusst falschen Antwort zum Quartalsende, die niemand erklären kann.
Messen Sie das Retrieval für sich allein
Das Retrieval hat die stützende Passage entweder ins Context Window gebracht oder eben nicht. Bewerten Sie das zuerst, bevor das Modell ein Wort schreibt, denn die Generierung kann sich nicht von einem Kontext erholen, der die Antwort nie enthielt.
Bauen Sie das Eval-Set aus realen Fragen an reale Dokumente auf: 10-K-Abschnitte, Covenant-Übersichten, Transaktionsbeschreibungen, Richtlinien-PDFs – was auch immer Ihr System tatsächlich liest. Für jede Frage markiert ein Mensch, welcher Chunk oder welche Chunks die Antwort enthalten. Dieses Labeling ist der teure Teil, und es ist der Teil, den Sie nicht überspringen können. Verfolgen Sie dann:
- Recall at k. Von den Passagen, die die Antwort wirklich stützen, wie viele landeten in den Top-k der abgerufenen? Das ist die Kennzahl, die am meisten zählt, denn eine Passage, die das Modell nie sieht, kann keine Antwort verankern.
- Precision at k, oder Kontextdichte. Wie viel von dem, was Sie abgerufen haben, ist tatsächlich relevant? Das Window mit Beinahe-Treffern zu füllen, erhöht die Kosten und gibt dem Modell mehr Spielraum, sich am falschen Satz festzuhalten.
- MRR oder ein rangbewusster Score, damit Sie es bemerken, wenn der richtige Chunk von Position zwei auf Position acht rutscht, obwohl der Recall unverändert aussieht.
Segmentieren Sie jede einzelne dieser Kennzahlen nach Dokumenttyp und nach Fragetyp. Ein Harness, das einen einzigen gemischten Recall von 0,86 meldet, verschleiert die Tatsache, dass es Filings gut, aber Covenant-Tabellen schlecht abruft. Die gemischte Zahl bewegt sich ein wenig; das Covenant-Segment ist das, das Ihnen wehtun wird.
Bewerten Sie die Generierung gegen den Kontext, nicht gegen die Wahrheit
Sobald die richtige Passage im Window ist, lautet die zweite Frage, ob die Antwort darin bleibt. Das ist Faithfulness, und es ist der teure Fehler im Finanzbereich. Ein holpriger Satz wird im Review gefangen. Ein flüssiger Satz, der eine Zahl trägt, die die Quelle nie gestützt hat, kann glatt bis ins Kunden-Deck durchlaufen, bevor irgendjemand ihn gegen das Filing prüft.
Bewerten Sie die Generierung auf drei Achsen, jeweils gegen den abgerufenen Kontext statt gegen ein externes Ideal:
- Faithfulness. Wird jede Behauptung in der Antwort von den abgerufenen Passagen impliziert? Eine Antwort, die eine Zahl erfindet oder einen Covenant-Schwellenwert leicht falsch wiedergibt, fällt hier durch – selbst wenn sie sich gut liest.
- Answer Grounding. Verweisen die Zitate auf Passagen, die die spezifische Behauptung, an die sie geknüpft sind, tatsächlich stützen? Ein Zitat, das lediglich auf der richtigen Seite landet, ist kein Grounding; es muss den Satz stützen.
- Answer Relevance. Hat es die gestellte Frage beantwortet oder eine benachbarte, die aus dem Kontext leichter zu beantworten war?
Für Faithfulness im großen Maßstab nutzen wir einen LLM-Judge, aber erst nach dessen Kalibrierung. Nehmen Sie ein paar Hundert Antworten, lassen Sie einen Menschen jede als verankert oder nicht labeln, lassen Sie dann den Judge gegen dieselbe Stichprobe laufen und messen Sie die Übereinstimmung. Wenn der Judge in einem Fünftel der Fälle mit den Menschen uneinig ist, sind seine Scores Rauschen, und Sie justieren das Bewertungsschema, bis die Übereinstimmung hält. Berichten Sie die Übereinstimmungsrate des Judge zusammen mit seinen Faithfulness-Scores. Eine Faithfulness-Zahl von einem unkalibrierten Judge ist Bauchgefühl mit einem Dezimalpunkt.
Verdrahten Sie es in die Pipeline, damit sich die Zahl bewegt
Ein Eval-Set, das in einem Notebook lebt, das jemand von Hand ausführt, ist ein Dokument, kein Harness. Das Harness ist die Automatisierung drumherum.
- Lassen Sie die gesamte Suite in der CI bei jeder Änderung an Prompts, Chunking, dem Embedding-Modell, dem Retriever oder dem Basismodell laufen. Eine Prompt-Anpassung, die einen Fragetyp anhebt und dabei stillschweigend das Covenant-Retrieval verschlechtert, sollte den Build fehlschlagen lassen, nicht erst in der Produktion auftauchen.
- Verankern Sie eine zentrale Kennzahl an der Entscheidung, die das System steuert – so wie Sie es für jedes Finanzmodell tun würden – und setzen Sie einen Schwellenwert, den der Build erreichen muss. Für einen Research-Assistenten ist das üblicherweise Faithfulness; für ein Richtlinien-Nachschlagewerkzeug ist es der Retrieval-Recall.
- Versionieren Sie das Eval-Set und bewahren Sie seine Ergebnisse im Audit Trail auf. Wenn die Validierung oder ein externer Prüfer fragt, wie das System vor einem Release abgeschnitten hat, ist die Antwort ein gespeicherter Lauf gegen ein bekanntes Set – nicht die Erinnerung an eine gute Demo.
- Führen Sie Produktionsfehler zurück ein. Jede falsche Antwort, die ein Reviewer fängt, wird zu einem gelabelten Fall im nächsten Lauf, sodass das Harness genau dort härter wird, wo das System ertappt wurde.
Achten Sie nach dem Go-Live auf Drift. Dokumente ändern ihr Format, eine neue Filing-Vorlage taucht auf, jemand tauscht das Embedding-Modell gegen ein günstigeres. Der Retrieval-Recall sackt zuerst ab, die Faithfulness folgt, und ohne ein permanentes Harness ist das erste Signal, das Sie bekommen, ein Nutzer, der eine Zahl anzweifelt. Mit einem Harness fällt das Covenant-Segment in der CI um einen halben Punkt, und Sie fangen es ab, bevor es in Produktion geht.
Der Sinn des Ganzen ist eine Zahl, die sich aus einem Grund bewegt, den Sie benennen können. Wenn der Retrieval-Recall fällt, wissen Sie, dass Sie sich das Chunking ansehen müssen. Wenn die Faithfulness fällt, während das Retrieval hält, wissen Sie, dass Sie sich den Prompt oder das Modell ansehen müssen. Diese Trennung ist der gesamte Wert des Harness, und sie ist es, die aus “sieht gut aus” etwas macht, das Sie einem Prüfer vorlegen können.
Häufige Fragen
Wie viele gelabelte Fragen braucht ein RAG-Eval-Set im Finanzbereich?
Weniger, als man erwartet, aber es müssen die richtigen sein. Ein paar Hundert Fragen, die Ihre realen Dokumenttypen, Edge Cases und bekannten Fehlermodi abdecken, schlagen Tausende synthetischer Fragen. Erweitern Sie das Set jedes Mal, wenn die Produktion einen Fehler zutage fördert, den das Harness übersehen hat.
Können wir ein LLM statt menschlicher Labels nutzen, um Faithfulness zu bewerten?
Für die Bewertung der Generierung gegen den abgerufenen Kontext ja – sobald Sie den Judge gegen eine menschlich gelabelte Stichprobe kalibriert und seine Übereinstimmungsrate gemessen haben. Vertrauen Sie einem nicht validierten Judge keine Kennzahl an, die Sie an Risiko oder Audit berichten werden.
Was ist der Unterschied zwischen Retrieval-Metriken und Faithfulness?
Retrieval-Metriken fragen, ob die richtige Passage abgerufen wurde. Faithfulness fragt, ob die generierte Antwort tatsächlich durch das gestützt wird, was abgerufen wurde. Sie versagen unabhängig voneinander, also müssen Sie sie getrennt messen.