Jak przygotowano test

Autor zbudował niewielki system retrieval-augmented generation (RAG) oparty na dwóch dokumentach z regulaminami płatności i przeprowadził dwa testy:

  • Test recall – czy poprawna strona pojawiła się wśród pięciu najlepszych wyników? Wynik: 60%.
  • Test odpowiedzi – czy ostateczna odpowiedź wygenerowana przez model była poprawna? Wynik: 90%.

40-procentowa różnica wydawała się niemożliwa. Jeśli retriever nie znalazł właściwej strony cztery razy na dziesięć, to jak model mógł odpowiadać poprawnie dziewięć razy na dziesięć?

Pierwsze próby „naprawienia” retrievera

Deweloper wypróbował dwa popularne triki:

  • Hybrid search (wyszukiwanie hybrydowe) – mieszanie sygnałów leksykalnych i wektorowych. Recall pozostał na tym samym poziomie.
  • Reranker – zmiana kolejności pięciu pobranych stron. Recall wzrósł do 70%, ale wciąż znacznie odbiegał od 90-procentowej dokładności odpowiedzi.

Oba narzędzia jedynie zmieniają kolejność tego, co zostało już pobrane; nie potrafią wyczarować strony, która nigdy nie trafiła do zbioru kandydatów. Problem leżał gdzie indziej.

To metryka, a nie model, była wadliwa

Zamiast oceniać sukces na podstawie etykiety strony, autor sprawdził fakty zawarte w pobranych fragmentach (chunks). W trzech na cztery przypadki „pomyłek” poprawny fakt był obecny, ale znajdował się na innej stronie, niż przewidywał skrypt testowy. Ewaluacja karała retrievera za znalezienie poprawnej odpowiedzi na nieoczekiwanej stronie.

Gdy zmieniono metrykę na „czy jakikolwiek pobrany fragment zawiera wymagany fakt?”, recall wzrósł do 90%, zrównując się z dokładnością odpowiedzi. Retriever działał poprawnie; zawiódł framework ewaluacyjny.

Dlaczego tradycyjny recall może wprowadzać w błąd

  • Etykietowanie na poziomie stron tworzy pozorne błędy. Pojedynczy fakt może pojawić się na kilku stronach. Oznaczenie tylko jednej strony jako ground truth sprawia, że wszystkie inne poprawne trafienia są traktowane jako błędy.
  • Małe korpusy potęgują ten efekt. Przy niewielkiej liczbie dokumentów jedna błędnie oznaczona strona może drastycznie zmienić recall, podczas gdy dokładność odpowiedzi pozostaje stabilna.
  • Szum w embeddingach ukrywa fakty. Wektory oceniają całe strony; otaczający tekst prawny lub techniczny rozmywa sygnał istotności docelowego zdania, obniżając pozycję strony w rankingu, mimo że fakt jest obecny.

Praktyczne wnioski dla praktyków RAG

  • Oddziel błędy rankingu od błędów retrievalu. Rerankery naprawiają jedynie to pierwsze; jeśli poprawny fragment nigdy nie trafi do zbioru kandydatów, zmiana kolejności nic nie da.
  • Etykietuj dane testowe na poziomie faktów. Powiąż każde zapytanie z konkretną informacją, której ono potrzebuje, a nie z pojedynczym identyfikatorem dokumentu.
  • Nie ufaj benchmarkom na dużą skalę przy bardzo małych zbiorach danych. Małe, specjalistyczne korpusy zachowują się inaczej, a ogólne wyniki recall mogą być mylące.
  • Zwracaj uwagę na ziarnistość embeddingów. Fragment o rozmiarze strony zawiera wiele słów, a otaczający tekst prawny może obniżyć rangę istotnego dla Ciebie faktu.

Podsumowując: wysoki wynik dokładności odpowiedzi może współistnieć z niskim tradycyjnym recall, gdy ewaluacja nie jest dopasowana do zadania. Naprawa metryki, a nie modelu, oszczędza czas, ogranicza fałszywe alarmy i pozwala na wdrażanie bardziej wiarygodnych systemów RAG.