Ewaluacja RAG — skąd wiesz, że odpowiada trafnie i ze źródeł

System RAG bywa pewny siebie i jednocześnie w błędzie. Żeby mu zaufać, trzeba go zmierzyć — nie raz, lecz przy każdej zmianie. Ewaluacja RAG to zestaw metryk, które oddzielają „brzmi sensownie” od „jest poprawne i pochodzi ze źródła”: trafność wyszukiwania, ugruntowanie odpowiedzi, poprawność cytowań i poprawność odmowy. Bez nich „działa u mnie na trzech pytaniach” to nie dowód, lecz przeczucie.

RAG ogranicza halucynacje, ale ich nie wyłącza. Pytanie nie brzmi „czy RAG halucynuje”, tylko „jak często i czy wyłapujemy to, zanim zobaczy klient”. Odpowiedzią jest ewaluacja.

Rozdziel dwie warstwy: wyszukiwanie i generowanie

RAG ma dwa etapy i każdy psuje się inaczej. Najpierw retriever wyszukuje fragmenty, potem model pisze odpowiedź. Jeśli retriever nie znajdzie właściwego fragmentu, najlepszy model nie pomoże. Jeśli znajdzie, a model i tak zmyśli — problem jest w generowaniu. Te dwie warstwy mierz osobno, inaczej nie wiesz, co naprawiać.

Co mierzyć — pięć metryk

Trafność wyszukiwania (retrieval). Czy wśród pobranych fragmentów jest ten, który zawiera odpowiedź? (recall@k, hit rate). Bez tego reszta nie ma znaczenia.
Ugruntowanie (groundedness). Czy każde zdanie odpowiedzi wynika z pobranych fragmentów, a nie z „pamięci” modelu? To bezpośredni pomiar halucynacji.
Poprawność cytowań. Czy wskazane źródło faktycznie zawiera to, co model mu przypisał? Cytat, który nie potwierdza zdania, jest gorszy niż brak cytatu — buduje fałszywe zaufanie.
Trafność odpowiedzi (relevance). Czy odpowiedź odpowiada na pytanie, czy tylko sąsiaduje z tematem?
Poprawność odmowy. Czy system mówi „nie wiem”, gdy w bazie nie ma odpowiedzi — zamiast zmyślać? To metryka, którą najłatwiej pominąć i najdrożej zignorować.

Jak mierzyć — metoda

Zestaw referencyjny (golden set). 50–200 realnych pytań z oczekiwaną odpowiedzią i źródłem. To Twój test regresji: budujesz go raz, używasz zawsze.
Sędzia: najpierw człowiek, potem model. Część metryk (ugruntowanie, trafność) da się oceniać modelem („LLM-as-judge”), ale sędzia też się myli — skalibruj go na próbce ocenionej przez człowieka, zanim mu zaufasz.
Regresja przy każdej zmianie. Zmiana modelu, promptu, sposobu dzielenia dokumentów (chunking) czy aktualizacja bazy może poprawić jedno pytanie i zepsuć dziesięć. Bez golden setu nie zobaczysz tego, dopóki nie zobaczy klient.
Monitoring na produkcji. Dane i pytania się zmieniają — to, co przeszło testy w marcu, może dryfować w czerwcu. Mierz dalej po wdrożeniu: odsetek odmów, rozkład pobranych źródeł, zgłoszenia użytkowników.

Scorecard: od metryki do reakcji

Scorecard ma sens dopiero wtedy, gdy każda metryka prowadzi do decyzji. Poniższe progi są przykładem dla procesu o podwyższonej stawce; ten przykład nie jest standardem ani benchmarkiem branżowym. Własne wartości ustala właściciel procesu przed testem — na podstawie skutku błędu, kosztu eskalacji i tego, czy odpowiedź tylko informuje, czy wpływa na decyzję.

Metryka	Co mierzy	Jak liczyć	Przykładowy próg	Reakcja po niespełnieniu
Retrieval hit rate@5	Czy retriever znalazł właściwe źródło	pytania z trafnym fragmentem w top 5 / pytania odpowiedzialne	≥95%	popraw chunking, filtry lub indeks; nie stroić samego promptu
Groundedness	Czy twierdzenia wynikają z pobranych źródeł	twierdzenia potwierdzone / wszystkie ocenione twierdzenia	≥98%	zablokuj wydanie, zaostrz instrukcję i regułę odmowy
Poprawność cytowań	Czy cytat rzeczywiście wspiera zdanie	poprawne cytowania / wszystkie cytowania	≥95%	nie pokazuj odpowiedzi jako zweryfikowanej; popraw mapowanie cytatów
Trafność odpowiedzi	Czy odpowiedź domyka pytanie	odpowiedzi trafne / pytania odpowiedzialne	≥90%	sprawdź kontekst, format odpowiedzi i pokrycie źródeł
Poprawność odmowy	Czy system odmawia, gdy brak podstawy	poprawne odmowy / pytania bez odpowiedzi w bazie	≥98%	ogranicz zakres lub eskaluj do człowieka; brak zgadywania

„Pytania odpowiedzialne” to te, dla których w zaakceptowanym korpusie istnieje jednoznaczna podstawa. Osobno trzeba policzyć pytania bez podstawy, bo inaczej system może poprawiać wynik, odpowiadając na wszystko — również wtedy, gdy powinien odmówić.

Przykład: golden set → wynik → go/no-go

Załóżmy ilustracyjny, nieprodukcyjny test wewnętrznej bazy procedur. Golden set ma 100 pytań: 70 z odpowiedzią w zatwierdzonych źródłach i 30 celowo poza zakresem. Zespół przed testem zapisuje powyższe progi oraz dodatkową zasadę: choćby jeden błąd krytyczny — odpowiedź sprzeczna ze źródłem w sprawie bezpieczeństwa — oznacza no-go niezależnie od średniej.

Retrieval znalazł prawidłowy fragment dla 66 z 70 pytań (94,3%). Z tych 66 odpowiedzi 64 były w pełni ugruntowane (97,0%), 62 miały prawidłowe cytowanie (93,9%), a 63 z 70 trafnie odpowiadały na pytanie (90,0%). System prawidłowo odmówił w 29 z 30 pytań bez źródła (96,7%). Nie wykryto błędu krytycznego, ale cztery z pięciu bramek nie osiągnęły ustalonego progu.

Decyzja: no-go dla samodzielnego użycia. To nie znaczy „wyrzuć projekt”. Wskazuje kolejność pracy: najpierw retrieval i pokrycie źródeł, potem cytowania i reguła odmowy, a następnie ponowny test na tej samej, wersjonowanej próbce. Do czasu przejścia bramek system może działać wyłącznie jako narzędzie robocze z obowiązkową weryfikacją człowieka.

Wynik jako dowód, nie zrzut ekranu

Do AI Assurance Evidence Pack trafia nie sama średnia, lecz wersjonowany artefakt: identyfikator wersji systemu i korpusu, definicja golden setu, progi zatwierdzone przed testem, surowe wyniki per pytanie, lista błędów krytycznych, decyzja go/no-go, właściciel decyzji i data kolejnego testu. Dzięki temu wynik można odtworzyć i porównać po zmianie modelu, promptu, chunkingu lub dokumentów.

Nazwy metryk i sposób ich automatyzacji warto porównać z dokumentacją Ragas oraz ewaluacji RAG w Amazon Bedrock. Narzędzie nie ustala jednak ryzyka biznesowego ani progu za właściciela procesu.

Dlaczego to praca ciągła, nie projekt

Model się aktualizuje, dokumenty przyrastają, pytania ewoluują. Ewaluacja, która nie biegnie dalej, starzeje się razem z nimi. Dlatego u nas evals RAG są częścią opieki ciągłej (retainer), nie jednorazowego odbioru — to one decydują, czy jakość utrzyma się w czasie. Jak pisaliśmy przy guardrails: bez testów i ewaluacji zabezpieczenie jest dekoracją. To samo dotyczy RAG.

W skrócie

Mierz osobno wyszukiwanie i generowanie. Pięć metryk: trafność wyszukiwania, ugruntowanie, poprawność cytowań, trafność odpowiedzi, poprawność odmowy. Zbuduj golden set, skalibruj sędziego-model na ocenach człowieka, uruchamiaj regresję przy każdej zmianie i mierz dalej na produkcji. Wtedy „działa” przestaje być przeczuciem, a staje się liczbą.

Co dalej

Jak budujemy RAG ze źródłami opisujemy na stronie RAG / bazy wiedzy. Ewaluacje i utrzymanie jakości w czasie to część opieki ciągłej. Jeśli masz już RAG i nie wiesz, czy mu ufać — zacznij od audytu. Przed budową sprawdź też gotowość danych do RAG, a techniczne zabezpieczenia zestaw z guardrails.