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.

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.