RAG: jak ewaluować jakość odpowiedzi (golden set)

Zespół wdrożył RAG, pierwsze demo wygląda świetnie, zarząd jest zadowolony. Potem, po sześciu tygodniach produkcji, ktoś zmienia strukturę dokumentów w bazie wiedzy. Jakość odpowiedzi spada. Nikt nie zauważa przez dwa tygodnie, bo nie ma żadnego testu regresyjnego. To scenariusz, który widzimy w co trzecim pierwszym wdrożeniu.

Ewaluacja RAG to nie akademicki dodatek. To jedyna metoda, która odróżnia „system odpowiada" od „system odpowiada poprawnie". Poniżej opisuję, jak ją zbudować, jakich metryk używać i jak utrzymywać jakość przez cały cykl życia systemu.

Testowanie REST API jest proste: wysyłasz żądanie, porównujesz odpowiedź ze schematem. RAG ma trzy niezależne źródła błędów, które wymagają osobnych metryk.

Błąd retrieval. System pobrał fragmenty niepasujące do pytania. Model generatywny ma dobry kontekst, ale zły. Odpowiedź może brzmieć przekonująco i być całkowicie błędna.

Błąd faithfulness. System pobrał trafne fragmenty, ale model wyciągnął z nich nieistniejące informacje lub dodał własną wiedzę parametryczną. To klasyczna halucynacja nawet przy poprawnym retrieval.

Błąd relevance. System pobierał właściwe fragmenty, model wygenerował tekst wynikający z tych fragmentów, ale odpowiedź nie adresuje faktycznego pytania użytkownika. Zdarza się, gdy pytanie jest niejednoznaczne lub gdy baza wiedzy ma luki tematyczne.

Testy jednostkowe API nie wychwytują żadnego z tych błędów. Potrzebujesz osobnych metryk dla każdej warstwy.

Golden set to kontrolowany zestaw par wejście-oczekiwane-wyjście, budowany raz, utrzymywany na bieżąco i uruchamiany automatycznie. Minimalne wymagania dla produkcji:

Golden set buduje się ze źródeł, które znasz: pytania ze zgłoszeń do supportu (najcenniejsze, bo realne), pytania z formularzy kontaktowych, pytania zadawane konsultantom. Nie twórz go przez wymyślanie pytań przy biurku — pytania wymyślone w próżni rzadko odpowiadają temu, czego naprawdę szukają użytkownicy.

Formalne pytania spoza domeny (te, na które baza wiedzy nie powinna odpowiadać) też muszą być w golden secie. Ewaluacja RAG bez testów negatywnych nie mierzy, czy system poprawnie odmawia odpowiedzi.

Ewaluacja RAG sprowadza się do trzech liczb, których potrzebujesz na dashboardzie.

Faithfulness mierzy, czy odpowiedź wynika z dostarczonych fragmentów. Skala 0-1. Wartość 1 oznacza, że każda teza w odpowiedzi ma potwierdzenie w co najmniej jednym z fragmentów kontekstu. Wartość 0 oznacza, że model odpowiedział z własnej wiedzy parametrycznej, ignorując kontekst.

Wymagana wartość do produkcji: powyżej 0,85. Poniżej tego progu system regularnie generuje informacje spoza bazy wiedzy.

Context relevance (trafność kontekstu) mierzy, jaki procent pobranych fragmentów jest merytorycznie przydatny do odpowiedzi na pytanie. Niska context relevance przy wysokim faithfulness to klasyczny objaw zbyt szerokiego retrieval: model jest wierny kontekstowi, ale kontekst jest niepotrzebny. Wymaga naprawy rerankingu lub parametrów wyszukiwania.

Answer relevance mierzy, czy odpowiedź adresuje faktyczne pytanie. Ta metryka jest niezależna od faithfulness: odpowiedź może być wierna fragmentom, ale nie odpowiadać na to, o co pytano. Szczególnie istotna przy pytaniach wieloaspektowych lub wieloznacznych.

Czwarta metryka, którą dodajemy do każdego projektu: "nie wiem" rate — procent zapytań, przy których system poprawnie odmówił odpowiedzi z powodu braku trafnych fragmentów. Zbyt niski wskazuje, że guardrails są zbyt permisywne i system halucynuje zamiast eskalować.

Są dwa praktyczne sposoby pomiaru metryk jakościowych: LLM-as-judge i ocena eksperta domenowego. Każda metoda ma inne zastosowanie.

LLM-as-judge to drugi model (inny niż ten generujący odpowiedź) oceniający parę (pytanie, odpowiedź, kontekst) według zdefiniowanego rubryku. Zaletą jest skalowalność: ocena tysiąca par zajmuje minuty. Wadą jest konieczność kalibracji, bo różne modele mają różne biasy oceniania.

Kalibracja LLM-as-judge: weź 100 par z golden setu i oceń je ręcznie (ekspert domenowy), potem oceń tym samym zestawem LLM-as-judge. Pearson correlation powyżej 0,8 między oceną ludzką a modelową to próg, przy którym możesz ufać automatycznej ewaluacji na dużych wolumenach.

Ocena eksperta domenowego jest wolna i kosztowna, ale konieczna jako punkt odniesienia. Minimalne zalecenie: raz na dwa tygodnie losowe 30-50 par z produkcji jest ocenianych przez eksperta. Ten sample utrzymuje kalibrację LLM-as-judge i wyłapuje degradację, której automatyczne metryki nie widzą.

Ocena użytkownika końcowego (thumbs up/down, krótka ankieta) jest najprostszym sposobem zbierania sygnału, ale mierzy wrażenie, nie merytorykę. Użytkownicy dają wysoki rating odpowiedziom pewnym stylistycznie, nawet gdy merytoryka jest błędna. Uzupełniaj ją, nie zastępuj.

Golden set ma wartość tylko wtedy, gdy jest uruchamiany regularnie i automatycznie. Cykl regresyjny dla RAG:

Przy każdej zmianie bazy wiedzy. Dodanie nowych dokumentów, usunięcie przestarzałych, zmiana struktury chunków — każde z tych działań może zmienić wyniki retrieval dla istniejących pytań. Golden set uruchomiony po zmianie wyłapuje regresje przed wejściem na produkcję.

Przy zmianie konfiguracji modelu lub rerankera. Aktualizacja modelu embeddingów, zmiana parametrów rerankingu, zmiana progu faithfulness w guardrails — każde z tych ustawień wpływa na metryki. Bez testu regresyjnego nie wiesz, w którą stronę.

Co tydzień na próbie produkcyjnej. Niezależnie od zmian infrastruktury, rzeczywiste zapytania użytkowników mogą ujawnić degradację niewidoczną na golden secie (pytania spoza domeny, nowe typy zapytań). Automatyczny sample 50 konwersacji z produkcji oceniany co tydzień przez LLM-as-judge uzupełnia golden set o sygnał z rzeczywistości.

Zestawienie tych podejść z powiązanym procesem wersjonowania bazy wiedzy opisuje artykuł aktualizacja wiedzy RAG i wersjonowanie.

Ewaluacja RAG nie jest tylko kwestią jakości technicznej. Dla systemów przetwarzających dane osobowe lub działających w wysokim ryzyku, ślad ewaluacji jest częścią dokumentacji wymaganej przez AI Act.

Minimalne wymagania ze strony zgodności:

Logi ewaluacyjne muszą zawierać: wersję modelu, wersję bazy wiedzy, datę uruchomienia testu, wyniki per metryka i identyfikatory par testowych. Treść zapytań testowych może zawierać PII zaczerpnięte z logów produkcyjnych, co wymaga pseudonimizacji przed włączeniem do golden setu.

Dla systemów objętych DPIA (np. HR, finanse, ochrona zdrowia), ewaluacja musi obejmować testy na bias: czy system różnie traktuje te same pytania w zależności od demograficznych cech użytkownika obecnych w kontekście? Wyniki takich testów są dokumentowane jako element oceny ryzyka.

TTL logów ewaluacyjnych: zagregowane wyniki (metryki bez treści) można przechowywać długo jako ślad audytowy. Logi z pełnymi parami ewaluacyjnymi zawierającymi treść zapytań mają krótszy TTL, dopasowany do polityki retencji RODO — typowo 30-90 dni.

Brak udokumentowanej ewaluacji przy systemie wysokiego ryzyka to potencjalna luka podczas audytu nadzorczego. Human-oversight musi mieć dowód, że był uruchamiany, a nie tylko zadeklarowany.

RAGAS (Retrieval Augmented Generation Assessment) to najpopularniejszy framework open-source do ewaluacji RAG. Implementuje faithfulness, answer relevance, context precision i context recall jako gotowe metryki. Wymaga modelu LLM do oceniania (LLM-as-judge wbudowany) i może działać lokalnie przez OpenClaw router.

Kiedy RAGAS jest odpowiedzią: gdy zaczynasz ewaluację od zera i chcesz szybko uzyskać zestaw metryk bez pisania własnej logiki oceniania. RAGAS dobrze sprawdza się przy pierwszych 3-6 miesiącach projektu.

Kiedy budować własny pipeline: gdy masz specyficzne wymagania domenowe (np. ewaluacja zgodności prawnej, faktografii technicznej, ton formalny w konkretnym języku), których gotowe rubryki nie obsługują. Własny pipeline to też lepsza kontrola nad kosztem tokenów oceniania.

Ważna uwaga techniczna: model oceniający (LLM-as-judge) nie powinien być tym samym modelem, który generuje odpowiedzi. Różne modele mają różne biasy, a auto-ocenianie tego samego modelu zawyża wyniki. Dobry wzorzec to mniejszy, szybszy model jako judge (niższy koszt tokenów) przy większym modelu generatywnym.

Golden set zbudowany przy wdrożeniu staje się stopniowo niereprezentacyjny. Po sześciu miesiącach pytania użytkowników mogą istotnie odbiegać od tych w golden secie — nowe zakresy tematyczne, nowy typ klientów, zmienione procesy w organizacji. Ten dryft dystrybucji zapytań jest cichym zabójcą jakości: metryki na golden secie pozostają stabilne, ale rzeczywista jakość na produkcji spada.

Sygnały, że golden set wymaga aktualizacji:

• Wskaźnik eskalacji do człowieka rośnie przez trzy kolejne tygodnie bez zmiany w konfiguracji.
• Pojawia się klaster tematyczny w produkcji, który nie ma reprezentacji w golden secie (wykrywalne przez clustering embeddingów rzeczywistych zapytań).
• Feedback użytkowników zawiera kategorie odpowiedzi, których golden set nie testuje.

Aktualizacja golden setu to co najmniej raz na kwartał: przejrzyj 200-300 produkcyjnych konwersacji, wyłoń nowe typy pytań, dodaj do golden setu i uruchom benchmark. To nie jest jednorazowy projekt, to proces.

Artykuł monitoring jakości agenta AI opisuje, jak wkomponować ewaluację golden setu w szerszy dashbord operacyjny agenta.

Opisz swój system RAG lub planowane wdrożenie, a model wskaże, od których metryk zacząć, jak zbudować golden set dla Twojego zakresu i jakie ryzyka jakościowe są krytyczne w Twoim przypadku (playground: PII maskowane, zero retencji):

Minimalne 50 par pozwala wykryć regresje większe niż 10 punktów procentowych na metrykach jakościowych. Dla bazy wiedzy do 200 dokumentów i wąskiego zakresu tematycznego to wystarczający start. Przy 200 parach wyniki są statystycznie stabilne i pozwalają wykrywać zmiany rzędu 3-5 punktów. Jeśli baza wiedzy ma kilka odrębnych tematycznych obszarów, golden set musi mieć reprezentatywne pokrycie każdego z nich, nawet jeśli ogólna liczba par jest mała. Szczegóły o przygotowaniu bazy wiedzy opisuje artykuł jak przygotować dane firmowe pod AI.

Faithfulness mierzy, czy odpowiedź wynika z dostarczonych fragmentów kontekstu, niezależnie od tego, czy te fragmenty były trafne. Relevance mierzy, czy odpowiedź faktycznie adresuje pytanie użytkownika. System może mieć wysoką faithfulness (model wiernie cytuje fragmenty) i niską relevance (fragmenty nie pasują do pytania). Obydwie metryki muszą być mierzone osobno. Najczęstszy błąd to mierzenie tylko jednej z nich i wyciąganie wniosków o całym systemie. Jeśli faithfulness jest wysoka, ale relevance niska, problem leży w retrieval, nie w modelu generatywnym. Więcej o wyszukiwaniu opisuje artykuł wyszukiwanie semantyczne i embeddingi w firmie.

Uruchamiaj go przy każdej zmianie bazy wiedzy lub konfiguracji modelu. Niezależnie od zmian, uruchamiaj go co tydzień na próbie produkcyjnej 50 konwersacji ocenianych przez LLM-as-judge. Dla systemów obsługujących ponad 1 000 zapytań dziennie zmniejsz interwał do 3-4 dni. Dla systemów w sektorach wysokiego ryzyka (finanse, zdrowie, HR) każda zmiana konfiguracji wymaga przejścia golden setu z pełną dokumentacją wyników jako część śladu audytowego AI Act. Automatyczne uruchamianie w CI/CD eliminuje ryzyko pominięcia testu przy szybkich zmianach.

Bez kalibracji na ocenie eksperckiej LLM-as-judge daje wyniki o niskiej korelacji z faktyczną jakością domenową. Modele różnie definiują „trafność" dla różnych dziedzin. Kalibracja polega na tym: oceniasz ręcznie 100 par, oceniasz te same pary przez LLM-as-judge i mierzysz korelację. Poniżej Pearson 0,75 model nie jest wiarygodnym sędzią dla Twojej domeny. Kalibracja musi być powtarzana po aktualizacjach modelu oceniającego. Koszt tej pracy jest jednorazowy przy uruchamianiu systemu i wart każdej minuty, bo pozwala ufać automatycznym metrykom.

Dla systemów klasyfikowanych jako wysokie ryzyko w myśl AI Act (szczególnie w obszarach HR, finansów, ochrony zdrowia), regulamin wymaga dokumentowania skuteczności systemu i możliwości wyjaśnienia jego działania. Ewaluacja golden set z zachowanymi logami wyników jest bezpośrednim dowodem, że system był regularnie kontrolowany. Brak tej dokumentacji utrudnia wykazanie zgodności podczas audytu nadzorczego. Dla systemów objętych DPIA dodaj do procesu ewaluacji testy na bias i test odmowy odpowiedzi na pytania spoza domeny. Obowiązki firm z AI Act i RODO opisuje artykuł AI Act i RODO 2026.