Jak ustalić, czy błędną odpowiedź spowodowało wyszukiwanie, czy generowanie

Dwa pytania za każdą błędną odpowiedzią

Dla użytkownika błędna odpowiedź wygląda tak samo bez względu na przyczynę. Dla zespołu to dwa osobne pytania. Czy dowód potrzebny do odpowiedzi dotarł do modelu? I czy model, mając ten dowód, użył go poprawnie? Zespoły, które oceniają tylko końcowe odpowiedzi, kończą na poprawianiu promptów przy błędach, które powstały w indeksie.

Narzędzia do ewaluacji odzwierciedlają ten podział. LlamaIndex na przykład oddziela ewaluację wyszukiwania, mierzoną metrykami rankingowymi takimi jak hit rate i mean reciprocal rank, od ewaluacji odpowiedzi, która ocenia jej wierność kontekstowi, trafność i poprawność.

Oznacz oczekiwane dowody

Dla każdego pytania testowego zapisz identyfikatory fragmentów, które na nie odpowiadają, oraz oczekiwaną odpowiedź. Zaznacz, czy te fragmenty są alternatywami, z których każdy sam odpowiada na pytanie, czy potrzebne są wszystkie razem. Mając identyfikatory, ocenę wyszukiwania robisz tanio i deterministycznie. Ragas oferuje na przykład context recall oparty na ID, który porównuje pobrane identyfikatory z referencyjnymi bez wywoływania modelu językowego. Ponieważ dzieli przez wszystkie identyfikatory referencyjne, stosuj go do dowodów wymaganych łącznie, a przy alternatywach licz trafienie, gdy pobrano którąkolwiek z nich.

Następnie przy każdym przebiegu testów zapisuj ślad. Poniższe pola to minimum, które naszym zdaniem się przydaje; nazwy są przykładowe i niezwiązane z żadnym frameworkiem.

# 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)

Znajdź pierwszą awarię

1. 1

   Czy fragment jest w indeksie?

   Jeśli nie, przyczyną jest ingestia: parser, który pominął zeskanowaną stronę, konektor, który ominął folder, albo dokument, który nigdy nie był w zakresie. Napraw pipeline albo źródło.

2. 2

   Czy jest wśród kandydatów pierwszego etapu?

   Jeśli jest daleko w rankingu albo wcale, przyjrzyj się zapytaniu, łącznie z ewentualnym krokiem jego przepisywania, oraz metodzie wyszukiwania. Dokładne identyfikatory często wymagają wyszukiwania leksykalnego obok semantycznego, a chunki bez kontekstu mogą nie pasować do pytania.

3. 3

   Czy trafił do promptu?

   Fragment może zostać pobrany, a mimo to odpaść przy rerankingu albo przy ograniczeniu do kilku najlepszych chunków. Porównaj pozycję kandydata z progiem odcięcia.

4. 4

   Czy model użył go poprawnie?

   Dopiero teraz problemem jest generowanie. Sprawdź, czy odpowiedź jest wierna fragmentom, kompletna i poprawna oraz czy model nie pogubił się przez sprzeczne fragmenty.

Przydatnym skrótem przy ostatnim kroku jest test wyroczni. Podaj modelowi oznaczone fragmenty bezpośrednio, z pominięciem wyszukiwania. Jeśli teraz odpowiada poprawnie, wada jest wcześniej w łańcuchu. Jeśli nadal się myli, pracuj nad promptem, modelem albo samym tekstem źródłowym.

Hipotetyczna diagnoza

Załóżmy zestaw testowy z 60 pytaniami z oznaczonymi fragmentami, z których 18 dostaje błędne albo niepełne odpowiedzi. Liczby są zmyślone i pokazują, jak taki rozkład ukierunkowuje pracę. Czterech oczekiwanych fragmentów brakuje w indeksie, bo partia zeskanowanych PDF-ów nie miała warstwy tekstowej. Siedem zostaje znalezionych, ale na pozycjach od 20 do 50, a do promptu trafia tylko pierwsza dziesiątka. Dwa odpadają przy rerankingu. Pięć dociera do modelu, a odpowiedzi i tak są błędne; w trzech przypadkach pobrano razem dwie wersje tej samej polityki, co jest w równym stopniu problemem źródeł, co modelu.

Trzynaście z 18 błędów powstaje, zanim zostanie wygenerowana odpowiedź, więc zmiany promptu odpowiedzi mogłyby naprawić najwyżej pięć. Przepisywanie zapytań i zmiany rerankera liczą się tu jako praca nad wyszukiwaniem. Z tego wynika kolejność: OCR dla zeskanowanej partii, potem zmiany w wyszukiwaniu dla siedmiu i dwóch przypadków, potem usunięcie albo oznaczenie nieaktualnej polityki, a na końcu pozostałe błędy generowania.

Jak czytać metryki wyszukiwania bez złudzeń

Recall przy ustalonym progu to metryka, która najbardziej bezpośrednio odpowiada tej diagnozie, bo pyta, czy oczekiwany fragment był wśród chunków, które model mógł zobaczyć. Anthropic w eksperymentach z contextual retrieval z 2024 roku używał jako wskaźnika błędów jedynki minus recall przy 20. Wybierz próg, którego twój system faktycznie używa; recall przy 50 wygląda dobrze i niewiele znaczy, jeśli do promptu trafia tylko 10 chunków.

Kilka sytuacji utrudnia diagnozę. Gdy pytanie ma alternatywne poprawne fragmenty, znalezienie dowolnego z nich powinno liczyć się jako sukces, a zwykły recall liczony po wszystkich zaniży wynik. Pytania wymagające wielu dokumentów naraz, na przykład zliczeń z całego roku raportów, są źle obsługiwane przez wyszukiwanie top-k i mogą wymagać innego projektu. Oznaczenia starzeją się też razem ze zmianami dokumentów, a oceniające modele dają różne wyniki w kolejnych przebiegach, dlatego Microsoft zaleca zakresy docelowe zamiast pojedynczych wartości.