Herausfinden, ob Retrieval oder Generierung eine falsche Antwort verursacht hat

Zwei Fragen hinter jeder falschen Antwort

Für die Nutzer sieht eine falsche Antwort immer gleich aus, egal woher sie kommt. Für das Team sind es zwei getrennte Fragen: Hat der Beleg, den die Antwort braucht, das Modell erreicht? Und hat das Modell diesen Beleg richtig verwendet? Teams, die nur fertige Antworten bewerten, optimieren am Ende Prompts für Fehler, die im Index entstanden sind.

Evaluierungswerkzeuge bilden diese Trennung ab. LlamaIndex etwa unterscheidet die Retrieval-Evaluierung, bewertet mit Ranking-Metriken wie Hit Rate und Mean Reciprocal Rank, von der Antwort-Evaluierung, die Faithfulness, Relevanz und Korrektheit der generierten Antwort beurteilt.

Erwartete Belege markieren

Erfassen Sie für jede Testfrage die Kennungen der Textstellen, die sie beantworten, und die erwartete Antwort. Halten Sie fest, ob diese Textstellen Alternativen sind, von denen jede allein die Frage beantwortet, oder ob alle gemeinsam nötig sind. Mit diesen IDs wird die Bewertung des Retrievals günstig und deterministisch. Ragas bietet etwa einen ID-basierten Context Recall, der abgerufene IDs mit Referenz-IDs vergleicht, ohne ein Sprachmodell aufzurufen. Da er durch alle Referenz-IDs teilt, nutzen Sie ihn für gemeinsam erforderliche Belege und werten einen Treffer, sobald eine von mehreren Alternativen abgerufen wurde.

Protokollieren Sie dann für jeden Testlauf einen Trace. Die folgenden Felder sind das Minimum, das sich für uns bewährt hat; die Namen sind beispielhaft und an kein Framework gebunden.

# One trace record per test question (field names are illustrative)
question_id:        q-017
question:           "Which firmware versions need a manual reset?"
expected_evidence:  all_of [release-notes-4.2#known-issues, runbook-reset#scope]
                    # use any_of [...] when either passage alone answers
in_index:           [true, true]        # did ingestion produce these chunks?
candidate_rank:     [3, 41]             # rank in first-stage search results
in_prompt:          [true, false]       # survived reranking and the top-k cut?
answer_verdict:     incomplete          # judged against the expected answer
first_failure:      retrieval (rank 41 > prompt cut at 10)

Den ersten Fehler finden

1. 1

   Ist die Textstelle im Index?

   Wenn nicht, liegt die Ursache in der Ingestion: ein Parser, der eine gescannte Seite übersprungen hat, ein Konnektor, der einen Ordner verpasst hat, oder ein Dokument, das nie im Umfang war. Beheben Sie Pipeline oder Quelle.

2. 2

   Ist sie unter den Kandidaten der ersten Stufe?

   Steht sie weit hinten oder gar nicht in der Liste, prüfen Sie die Anfrage, einschließlich eines eventuellen Umschreibeschritts, und das Suchverfahren. Exakte Kennungen brauchen oft lexikalische Suche neben der semantischen Suche, und Chunks ohne Kontext passen womöglich nicht zur Frage.

3. 3

   Ist sie im Prompt angekommen?

   Eine Textstelle kann abgerufen und trotzdem durch Reranking oder den Schnitt auf die obersten Chunks verworfen werden. Vergleichen Sie den Kandidatenrang mit der Grenze.

4. 4

   Hat das Modell sie richtig genutzt?

   Erst jetzt liegt das Problem in der Generierung. Prüfen Sie, ob die Antwort den Textstellen treu, vollständig und korrekt ist und ob widersprüchliche Textstellen das Modell verwirrt haben.

Eine nützliche Abkürzung für den letzten Schritt ist ein Orakeltest. Geben Sie dem Modell die markierten Textstellen direkt und umgehen Sie die Suche. Antwortet es nun richtig, liegt der Fehler weiter vorne. Scheitert es weiterhin, arbeiten Sie an Prompt, Modell oder am Quelltext selbst.

Eine hypothetische Diagnose

Angenommen, ein Testset hat 60 Fragen mit markierten Textstellen, und 18 erhalten falsche oder unvollständige Antworten. Die Zahlen sind erfunden und zeigen, wie eine Aufschlüsselung die Arbeit lenkt. Vier erwartete Textstellen fehlen im Index, weil eine Reihe gescannter PDFs keine Textebene hatte. Sieben werden gefunden, aber auf den Rängen 20 bis 50, während nur die obersten 10 in den Prompt gelangen. Zwei fallen beim Reranking heraus. Fünf erreichen das Modell, und die Antworten sind trotzdem falsch; in drei Fällen wurden zwei Fassungen einer Richtlinie zusammen abgerufen, was ebenso ein Quellen- wie ein Modellproblem ist.

Dreizehn der 18 Fehler entstehen, bevor die Antwort generiert wird, Änderungen am Antwort-Prompt könnten also höchstens fünf beheben. Umschreiben von Anfragen und Änderungen am Reranker zählen hier zur Retrieval-Arbeit. Daraus folgt die Reihenfolge: OCR für die gescannten Dateien, dann Änderungen an der Suche für die sieben und die zwei, dann Entfernen oder Kennzeichnen der überholten Richtlinie und zuletzt die übrigen Generierungsfehler.

Retrieval-Metriken richtig lesen

Recall bei einer festen Grenze ist die Metrik, die dieser Diagnose am direktesten entspricht, denn sie fragt, ob die erwartete Textstelle unter den Chunks war, die das Modell sehen konnte. Anthropic nutzte in seinen Experimenten zu Contextual Retrieval von 2024 eins minus Recall bei 20 als Fehlerrate. Wählen Sie die Grenze, die Ihr System tatsächlich verwendet; Recall bei 50 sieht gut aus und sagt wenig, wenn nur 10 Chunks im Prompt landen.

Einige Fälle erschweren die Diagnose. Hat eine Frage alternative gültige Textstellen, sollte jede einzelne als Erfolg zählen, und ein gewöhnlicher Recall über alle unterschätzt das Ergebnis. Fragen, die viele Dokumente zugleich brauchen, etwa Zählungen über ein Jahr an Berichten, bedient Top-k-Retrieval schlecht, und sie brauchen womöglich ein anderes Design. Außerdem veralten Markierungen, wenn sich Dokumente ändern, und modellbasierte Prüfer schwanken zwischen Läufen, weshalb Microsoft Zielbereiche statt einzelner Zielwerte empfiehlt.