Jak ewaluować system RAG: metryki retrievalu, faithfulness i golden set

Regularnie widzimy ten sam moment: zespół wdraża asystenta opartego o RAG, ktoś zgłasza, że „bot zmyśla”, i zaczyna się polowanie na winnego. Czy to model halucynuje, czy po prostu nie dostał właściwego fragmentu w kontekście? Bez rozdzielonego pomiaru obu warstw ta dyskusja kończy się zgadywaniem. Ewaluacja RAG nie jest jedną liczbą — to dwa zestawy metryk połączone wspólnym zbiorem testowym, które razem pokazują, gdzie dokładnie system się rozpada.

System RAG ma dwa komponenty, które mogą zawieść niezależnie. Retrieval może nie znaleźć właściwego fragmentu — wtedy generacja nie ma szans, bo model nie widzi tego, czego nie dostał. Albo retrieval poda poprawny kontekst, a model i tak odpowie obok, zignoruje go lub dołoży fakty z własnej pamięci. To dwie różne usterki i dwa różne plany naprawy.

Dlatego mierzymy je oddzielnie. Jakość wyszukiwania semantycznego ocenia, czy właściwe fragmenty trafiają wysoko do kontekstu. Jakość odpowiedzi ocenia, czy model trzyma się tego, co dostał. Dopiero złożenie obu daje obraz end-to-end. Częsty błąd to patrzenie wyłącznie na końcową ocenę odpowiedzi: gdy spada, nie wiadomo, czy winny jest retrieval, czy generacja, więc poprawki są chaotyczne.

Warstwę wyszukiwania mierzymy tymi samymi narzędziami co czysty retrieval. Recall@k mówi, jaki odsetek oczekiwanych fragmentów znalazł się w top k wynikach podanych modelowi. To metryka pokrycia — jeśli właściwego fragmentu nie ma w kontekście, najlepszy nawet model nie wygeneruje poprawnej odpowiedzi, tylko zmyśli. Dlatego recall@k jest dla RAG ważniejszy niż dla wyszukiwarki, gdzie użytkownik sam przegląda listę.

Precision@k mówi z kolei, jaki odsetek podanych fragmentów był rzeczywiście trafny. Niska precyzja oznacza, że zaśmiecamy kontekst — model dostaje szum, rośnie koszt tokenów i ryzyko, że uchwyci się nieistotnego fragmentu. W praktyce balansujemy oba: szersze k podnosi recall, ale obniża precyzję. MRR dopowiada, jak wysoko ląduje pierwszy trafny wynik, co bywa istotne, gdy chcemy podać modelowi mniej kontekstu.

Liczby w kolumnie „próg” to widełki obserwowane przez nas na projektach z polskimi dokumentami firmowymi, a nie uniwersalne stałe — traktuj je jako punkt kalibracji. Metodykę pomiaru samego retrievalu rozwijamy w artykule o tym, jak mierzyć jakość embeddingów. Gdy recall jest za niski, najczęstsze dźwignie to zmiana strategii chunkingu oraz dołożenie wyszukiwania hybrydowego BM25 plus wektory.

Druga warstwa to jakość samej odpowiedzi przy założeniu, że kontekst już jest. Kluczowa metryka to faithfulness (ugruntowanie): czy każde twierdzenie w odpowiedzi da się poprzeć fragmentem z dostarczonego kontekstu. Odpowiedź wierna nie dokłada faktów spoza materiału — a właśnie takie dokładanie to klasyczna halucynacja. Faithfulness mierzymy, rozbijając odpowiedź na pojedyncze zdania-twierdzenia i sprawdzając, czy każde z nich znajduje oparcie w kontekście.

Druga metryka to trafność odpowiedzi (answer relevance): czy odpowiedź faktycznie odnosi się do pytania, a nie jest poprawna, lecz o czymś obok. Trzecia to atrybucja źródeł: czy system wskazuje, z którego dokumentu pochodzi dana informacja, i czy te cytowania są prawdziwe. Atrybucja to nie ozdoba — to mechanizm, który pozwala użytkownikowi zweryfikować odpowiedź i jednocześnie daje nam audytowalny ślad przy ewaluacji.

Halucynacje w RAG mają dwa różne źródła. Pierwsze: retrieval nie dostarczył odpowiedzi, więc model „dopowiada” z pamięci — to defekt warstwy wyszukiwania, łapany niskim recall. Drugie: kontekst był poprawny, a model i tak wyszedł poza niego — to defekt generacji, łapany niskim faithfulness. Rozdzielenie pomiaru pozwala od razu wiedzieć, którą warstwę naprawiać, zamiast „poprawiać prompt”, gdy realnym problemem jest brakujący chunk.

Bez golden setu nie masz czego mierzyć ani na której warstwie. Dla RAG golden set jest bogatszy niż dla czystego retrievalu, bo każda pozycja to trójka: realistyczne pytanie, zbiór fragmentów stanowiących właściwy kontekst oraz wzorcowa odpowiedź (lub zestaw faktów, które poprawna odpowiedź musi zawierać). Pytanie i oznaczony kontekst zasilają metryki retrievalu; pytanie, kontekst i odpowiedź wzorcowa zasilają metryki generacji.

Zacznij od 50-100 prawdziwych pytań z logów asystenta, zgłoszeń do supportu albo wywiadów z przyszłymi użytkownikami. Pytania wymyślone „przy biurku” są zbyt regularne i nie oddają języka użytkownika, który pisze ze skrótami i błędami. Dla każdego pytania oznacz trafne fragmenty kontekstu i spisz wzorcową odpowiedź — annotację powinna wykonać osoba znająca dziedzinę, nie model językowy, bo to model bywa tu obiektem oceny.

Korpus do ewaluacji indeksuj dokładnie tym samym pipeline co produkcyjny: ta sama strategia chunkingu, ten sam model embeddingów, ten sam rozmiar fragmentu. Jeśli zmienisz cokolwiek między testem a produkcją, metryki przestają być porównywalne. Golden set warto wersjonować i traktować jak kod — rośnie wraz z systemem, a każdy zgłoszony błąd produkcyjny powinien wracać do niego jako nowy przypadek testowy.

Ewaluacja offline na golden secie jest powtarzalna i tania, ale ma ślepy punkt: mierzy tylko to, co przewidzieliśmy. Prawdziwi użytkownicy zadają pytania spoza zbioru, w formach, których nie wymyśliliśmy. Dlatego offline służy do porównań wariantów (model A kontra B, chunking 256 kontra 512) i do ochrony przed regresją po każdej zmianie, ale nie zastępuje obserwacji produkcji.

Online ewaluacja działa na żywym ruchu. Podstawą jest obserwowalność: logujemy pytanie, podany kontekst, odpowiedź i wskazane źródła, żeby każdą odpowiedź dało się odtworzyć i zaudytować. Na tej bazie liczymy faithfulness w trybie ciągłym — automatyczny sędzia (LLM-as-judge) sprawdza, czy twierdzenia z odpowiedzi mają oparcie w logowanym kontekście, i flaguje przypadki bez pokrycia jako kandydatów na halucynacje. To sygnał, nie wyrok: część flag wymaga przeglądu człowieka, a próbka idzie do ręcznej oceny dziedzinowej.

Atrybucja źródeł domyka pętlę. Jeśli każda odpowiedź wskazuje fragmenty, na których się oparła, weryfikacja halucynacji sprowadza się do sprawdzenia, czy cytowane fragmenty rzeczywiście zawierają to, co model twierdzi. Niespójność cytowania to silny sygnał halucynacji. Sygnały produkcyjne — niskie faithfulness, kciuk w dół, eskalacja do człowieka — zawracamy do golden setu jako nowe przypadki testowe, zamykając cykl offline-online. Jak ta pętla wygląda dla całego asystenta opisujemy w tekście o monitorowaniu jakości agenta AI.

Nie. Pojedyncza ocena końcowa pokazuje, że coś jest nie tak, ale nie powie, czy zawiódł retrieval, czy generacja. To dwie różne usterki z różnymi naprawami, więc trzeba mierzyć obie warstwy osobno i dopiero złożyć je w obraz end-to-end. Bez tego rozdzielenia poprawki są zgadywaniem.

Faithfulness sprawdza, czy odpowiedź trzyma się dostarczonego kontekstu i nie dokłada faktów spoza niego — to ochrona przed halucynacją. Trafność sprawdza, czy odpowiedź w ogóle odnosi się do pytania. Odpowiedź może być wierna kontekstowi, lecz nietrafna (poprawna, ale o czymś obok), więc obie metryki są potrzebne równolegle.

Z naszej praktyki rozsądny start to 50-100 par pytanie-kontekst-odpowiedź zbudowanych na realnych zapytaniach. To wystarczy, by wychwycić wyraźne różnice między wariantami i regresje. Zbiór traktuj jak żywy: każdy nowy błąd produkcyjny dopisuj jako kolejny przypadek testowy, więc z czasem urośnie.

Tak, LLM-as-judge to praktyczny sposób na ocenę faithfulness w skali, zwłaszcza online. Ale traktuj go jako sygnał, nie ostateczny werdykt: kalibruj sędziego na próbce ocenionej ręcznie i okresowo audytuj jego decyzje. Do annotacji golden setu (oznaczania właściwego kontekstu) nie używaj tego samego typu modelu, który oceniasz, bo zaburza to pomiar.

Gdy odpowiedź wskazuje fragmenty, na których się oparła, weryfikacja sprowadza się do sprawdzenia, czy te fragmenty rzeczywiście zawierają to, co model twierdzi. Rozjazd między cytowaniem a treścią fragmentu to silny sygnał halucynacji. Atrybucja daje też audytowalny ślad — przydatny i przy ewaluacji, i przy obsłudze reklamacji użytkownika.