U klienta z branży energetycznej wdrożyliśmy RAG oparty na normach technicznych i instrukcjach eksploatacyjnych. Po pierwszych dwóch tygodniach na produkcji operatorzy zgłaszali, że system „czasem odpowiada poprawnie, czasem nie". Gdy przyjrzeliśmy się bliżej, okazało się, że problem ma dwie zupełnie różne przyczyny: w niektórych przypadkach retrieval wczytywał niewłaściwe dokumenty — poprawna odpowiedź istniała w bazie wiedzy, ale system jej nie znajdował. W innych retrieval działał dobrze, lecz model generatywny ignorował wczytany kontekst i halucynował własną odpowiedź. Z perspektywy użytkownika oba błędy wyglądały identycznie. Bez metryk nie potrafiliśmy ich od siebie odróżnić.
To jest sedno problemu z ewaluacją systemów RAG: retrieval i generacja to dwa odrębne komponenty, każdy może zawodzić z innych powodów, a gdy mierzymy je łącznie, tracimy zdolność diagnostyczną. Ten artykuł opisuje, jak podejść do tematu — osobno, systematycznie, z narzędziami, które do tego celu istnieją.
Dlaczego klasyczne metryki nie wystarczają
Pierwszym instynktem przy ocenie systemu RAG jest pytanie: „Czy odpowiedź jest poprawna?" — i mierzenie tego ręcznie albo przez proste porównanie z oczekiwanym wyjściem. Takie podejście ma zasadniczą wadę: nie mówi, *gdzie* pipeline zawiodło.
Wyobraź sobie trzy scenariusze:
- Retrieval wczytał właściwy dokument, model odpowiedział na jego podstawie poprawnie — dobry wynik.
- Retrieval wczytał niewłaściwy dokument, model odpowiedział na jego podstawie spójnie — zły wynik, ale faithfulness jest wysoka (model nie halucynował, miał po prostu zły kontekst).
- Retrieval wczytał właściwy dokument, model go zignorował i halucynował — zły wynik, faithfulness jest niska.
Trzy różne scenariusze, dwa różne miejsca awarii, jeden wspólny objaw: niepoprawna odpowiedź. Jeśli mierzysz wyłącznie wynik końcowy, możesz naprawić retrieval i odkryć, że generacja nadal halucynuje — albo odwrotnie.
Dlatego nowoczesna ewaluacja RAG dzieli pomiar na dwie warstwy: metryki retrieval (context precision, context recall) i metryki generacji (faithfulness, answer relevancy). I właśnie taka jest filozofia stojąca za narzędziem RAGAS.
RAGAS — czym jest, a czym nie jest
RAGAS (Retrieval-Augmented Generation Assessment) to open-source'owy framework ewaluacyjny, który mierzy jakość pipeline RAG bez konieczności ręcznego adnotowania każdego przypadku. Zamiast tego stosuje podejście LLM-as-judge: twierdzenie lub wypowiedź ocenia kolejny model językowy.
Czym RAGAS jest: frameworkiem do offline'owej ewaluacji pipeline RAG z użyciem datasetu wzorcowego (zwanego golden set). Dostarczasz mu pytania, referencyjne odpowiedzi, konteksty wczytane przez twój retrieval i wygenerowane odpowiedzi — a w zamian oblicza cztery kluczowe metryki.
Czym RAGAS nie jest: narzędziem do monitorowania produkcji w czasie rzeczywistym, zamiennikiem ewaluacji całej aplikacji LLM ani narzędziem do mierzenia faktycznej poprawności samej bazy wiedzy. Jeśli twoje dokumenty zawierają błędne informacje, RAGAS tego nie wykryje — mierzy spójność i trafność, nie prawdziwość źródeł.
Ważne rozróżnienie w stosunku do innych typów ewaluacji: RAGAS skupia się wyłącznie na komponencie RAG. Jeśli chcesz mierzyć jakość odpowiedzi LLM niezależnie od retrieval-u albo oceniać fine-tuned model, sięgasz po inne metryki — należą one do odrębnej dziedziny ewaluacji. Podobnie, ewaluacja fine-tuningu (np. weryfikacja, czy fine-tuning pomógł) to inna dyscyplina niż ewaluacja RAG.
Cztery kluczowe metryki RAGAS
Context Precision
Context precision mierzy, czy dokumenty zwrócone przez retrieval są rzeczywiście trafne dla danego pytania. Konkretnie: jaka część wczytanego kontekstu jest użyteczna do wygenerowania poprawnej odpowiedzi?
Wysoka context precision oznacza, że retrieval nie zwraca szumu — każdy wczytany chunk wnosi wkład w odpowiedź. Niska context precision sygnalizuje, że system wczytuje zbyt wiele niepowiązanych dokumentów, co obniża jakość generacji (LLM musi jednocześnie orientować się w materiale istotnym i nieistotnym).
W praktyce: niska context precision wskazuje zwykle na problem z modelem embeddingów, błędną segmentacją dokumentów (chunking) lub ustawieniem top-K (wczytujesz zbyt wiele dokumentów). Więcej o doborze i konfiguracji komponentów retrieval znajdziesz w artykule o wyszukiwaniu hybrydowym.
Context Recall
Context recall to metryka komplementarna: jaka część informacji potrzebnych do poprawnej odpowiedzi znajduje się w wczytanym kontekście? Mierzona jest względem referencyjnej odpowiedzi z golden set-u.
Niska context recall oznacza, że retrieval pomija istotne dokumenty — informacja istnieje w bazie wiedzy, ale system jej nie odnajduje. Przyczyny bywają różne: niewystarczająca jakość modelu embeddingów dla danego języka lub domeny, zły chunking (informacja jest rozłożona na wiele fragmentów, z których żaden samodzielnie nie wystarcza) lub zbyt małe K (pobierasz np. tylko top-3, a istotny dokument znalazł się na 7. miejscu).
Faithfulness
Faithfulness mierzy, w jakim stopniu wygenerowana odpowiedź jest oparta na wczytanym kontekście. RAGAS rozkłada odpowiedź na poszczególne twierdzenia i dla każdego z nich sprawdza, czy jest explicite lub implicite poparte kontekstem.
Jest to najważniejsza metryka z perspektywy wiarygodności systemu RAG. Niska faithfulness oznacza, że model halucynuje — generuje informacje, których nie ma w wczytanym kontekście, ale które brzmią wiarygodnie. Kluczowe do zrozumienia: faithfulness ≠ faktyczna poprawność. Model może być perfekcyjnie faithful (100 % odpowiedzi oparte na kontekście), a sam kontekst może być błędny. Jeśli chcesz mierzyć faktyczną dokładność, jakość bazy wiedzy musisz rozwiązywać osobno.
Niska faithfulness zazwyczaj naprawiana jest na poziomie systemowego promptu (instrukcje, by model odpowiadał wyłącznie na podstawie kontekstu), doboru modelu (niektóre modele konsekwentniej przestrzegają instrukcji) lub dodania warstwy guardrails. O guardrails dla agentów AI, w tym kontroli wierności odpowiedzi, piszemy więcej w artykule o guardrails dla agentów AI.
Answer Relevancy
Answer relevancy ocenia, czy odpowiedź rzeczywiście odnosi się do zadanego pytania. RAGAS mierzy to, generując z wygenerowanej odpowiedzi kilka hipotetycznych pytań i sprawdzając, czy są podobne do oryginalnego zapytania.
Niska answer relevancy może wystąpić nawet przy wysokiej faithfulness: model może być wierny kontekstowi, ale odpowiadać na inne pytanie niż to, które zadano — typowo gdy kontekst jest ogólnikowy lub gdy systemowy prompt nie jest wystarczająco dyrektywny. W praktyce ta metryka ujawnia problemy z promptingiem i formułowaniem pytań.
Golden set — fundament każdej ewaluacji
Metryki RAGAS są tylko tak dobre, jak dataset, na którym je obliczasz. Złoty standard (golden set) to zestaw przypadków testowych w formacie:
- Pytanie — rzeczywiste lub reprezentatywne zapytanie
- Odpowiedź referencyjna — zweryfikowana poprawna odpowiedź (ground truth)
- Wczytany kontekst — dokumenty zwrócone przez twój retrieval dla danego zapytania
- Wygenerowana odpowiedź — wyjście twojego systemu RAG
Problem w tym, że zestawienie golden set-u jest kosztowne: typowo 100–300 przypadków na potrzeby podstawowej ewaluacji, 500–1 000 dla bardziej rozbudowanej. Ręczne tworzenie każdego przypadku przez eksperta dziedzinowego jest powolne i drogie.
Tu w grę wchodzą dwie strategie:
Syntetyczna generacja golden set-u: zarówno RAGAS, jak i inne narzędzia zawierają funkcje automatycznego generowania pytań testowych bezpośrednio z twoich dokumentów. LLM czyta fragment, generuje pytanie i odpowiedź referencyjną. Zaleta: szybkość i skalowalność. Wada: syntetyczne pytania mogą być zbyt proste lub nie odpowiadać rzeczywistym zapytaniom użytkowników. W praktyce zalecamy mieszanie: 60–70 % przypadków syntetycznych jako baza, 30–40 % rzeczywistych zapytań z logów produkcyjnych z adnotacjami eksperta.
Wydobycie z logów produkcyjnych: gdy system RAG działa na produkcji, logujesz pary (pytanie, odpowiedź). Wybór reprezentatywnych przypadków, adnotacja przez informację zwrotną od użytkowników (kciuk w górę/w dół) lub przez eksperta dziedzinowego — i masz realistyczny golden set oparty na rzeczywistym użyciu.
Ważna zasada: golden set trzeba utrzymywać jako żywy dokument. Gdy baza wiedzy jest aktualizowana, część przypadków testowych staje się przestarzała. Przy większych aktualizacjach dokumentacji zawsze sprawdzaj, czy golden set nadal odzwierciedla aktualny stan.
RAGAS w praktyce — integracja z pipeline
RAGAS to biblioteka Pythona, która prosto integruje się z istniejącym workflow RAG. Podstawowy przypadek użycia wygląda następująco: dla każdego przypadku testowego z golden set-u wywołujesz ewaluację z pytaniem, odpowiedzią referencyjną, wczytanym kontekstem i wygenerowaną odpowiedzią. Wynikiem są wyniki dla każdej metryki, zagregowane oraz per case.
Co warto wiedzieć przed wdrożeniem:
Koszt: RAGAS wewnętrznie wywołuje LLM do obliczania metryk (LLM-as-judge). Dla golden set-u z 200 przypadkami możesz spodziewać się setek, a nawet tysięcy wywołań LLM — co przy modelach frontierowych stanowi niemały wydatek. W praktyce zaleca się używanie mniejszego, tańszego modelu w roli judge (np. warstwa Haiku/Flash) lub — tam gdzie to możliwe — lokalnego modelu open-weight. Obliczanie faithfulness jest szczególnie token-intensywne, ponieważ rozkłada odpowiedź na twierdzenia.
Ewaluacja cykliczna, nie tylko ad-hoc: ewaluacja ma sens jako regularny proces — przy każdej zmianie komponentu retrieval, aktualizacji bazy wiedzy lub modyfikacji promptów. Zalecamy włączenie ewaluacji RAGAS do pipeline CI/CD przynajmniej jako sanity check na podzbiorze golden set-u przed każdym deploymentem.
Interpretacja liczb bezwzględnych: wynik 0,80 dla faithfulness nie jest obiektywnie dobry ani zły — zależy od przypadku użycia. Dla dokumentacji medycznej 0,80 to za mało. Dla wewnętrznego helpdesku może być wystarczające. Ważniejsze są trendy: jeśli po modyfikacji promptu faithfulness spadła z 0,85 do 0,72, masz wyraźny sygnał.
Oddzielenie ewaluacji retrieval od ewaluacji generacji
Kluczowa praktyka, którą widzimy zbyt rzadko stosowaną: ewaluację komponentu retrieval i komponentu generacji należy przeprowadzać również niezależnie, nie tylko end-to-end przez RAGAS.
Ewaluacja retrieval osobno: możesz oceniać retrieval bez jakiejkolwiek generacji LLM. Dla każdego pytania testowego wiesz, które dokumenty retrieval powinien idealnie znaleźć (z golden set-u). Mierzysz precision@K i recall@K — ile z istotnych dokumentów znalazło się w wynikach top-K. Daje ci to czysty sygnał o jakości modelu embeddingów, strategii indeksowania i konfiguracji wyszukiwania — bez tego, żeby model generatywny przysłaniał problemy lub kompensował błędy retrieval-u.
Ewaluacja generacji osobno: możesz ustalić stały kontekst — zamiast dynamicznie wczytywanych dokumentów podajesz modelowi zawsze ten sam, ręcznie zweryfikowany kontekst — i mierzyć wyłącznie faithfulness i answer relevancy. Izoluje to testowanie zdolności modelu do przestrzegania instrukcji i ekstrakcji informacji z dostarczonego tekstu.
Połączenie obu perspektyw z metrykami end-to-end RAGAS daje pełny obraz tego, gdzie dokładnie pipeline traci jakość.
Czego RAGAS nie zmierzy — na co uważać
RAGAS to potężne narzędzie, ale ma granice, które trzeba znać.
Faktyczna poprawność bazy wiedzy: jak wspomnieliśmy, RAGAS mierzy spójność odpowiedzi z kontekstem. Jeśli dokumenty w bazie wiedzy zawierają przestarzałe lub błędne informacje, RAGAS tego nie ujawni. Jakość bazy wiedzy musisz rozwiązywać osobno — przez przegląd dziedzinowy, datowanie dokumentów i mechanizmy aktualizacji.
Latencja i koszty na produkcji: RAGAS to narzędzie do ewaluacji offline. Nie powie ci, jak pipeline zachowuje się przy dużej liczbie zapytań, jaka jest rzeczywista latencja dla użytkownika ani jakie są produkcyjne koszty tokenów. Do tych metryk potrzebujesz monitorowania produkcyjnego — narzędzi takich jak LangSmith, Langfuse lub własnej warstwy logowania. O obserwowalności agentów AI i monitorowaniu produkcyjnym piszemy szczegółowo w artykule o obserwowalności agentów AI.
Właściwości bezpieczeństwa: RAGAS nie mierzy odporności na prompt injection, zdolności systemu do odrzucania nieodpowiednich zapytań ani przestrzegania guardrails bezpieczeństwa. To należy do ewaluacji bezpieczeństwa, która jest odrębną dyscypliną.
Jakość językowa i rejestr: jeśli twoi użytkownicy komunikują się po polsku, a baza wiedzy jest po angielsku, wyniki RAGAS nic ci nie powiedzą o jakości tłumaczenia ani naturalności polskich odpowiedzi. W przypadku konfiguracji wielojęzycznej potrzebujesz ludzkiej ewaluacji jakości językowej.
Najczęstsze pytania
Ile przypadków potrzebuję w golden set-cie, żeby wyniki były wiarygodne?
Do pierwszego baseline'u wystarczy 50–100 przypadków, żeby uzyskać ogólną orientację. W przypadku decyzji takich jak „zmienić model embeddingów" lub „dostosować strategię chunkingu" zalecamy 200–400 przypadków obejmujących różne typy pytań i obszary bazy wiedzy. Poniżej 50 przypadków wyniki są zbyt wrażliwe na pojedyncze wartości odstające.
Czy mogę używać RAGAS do monitorowania produkcji w czasie rzeczywistym?
Nie bezpośrednio — każdy pomiar RAGAS wymaga wywołań LLM, co jest zbyt kosztowne dla każdego produkcyjnego zapytania. Typowym podejściem jest próbkowanie: zamiast mierzyć każde zapytanie, bierzesz losową próbkę 1–5 %, uruchamiasz ewaluację RAGAS asynchronicznie i śledzisz trendy w czasie. Do produkcyjnego monitoringu w czasie rzeczywistym lepiej nadają się prostsze sygnały: informacja zwrotna od użytkowników (kciuk w górę/w dół), latencja, liczba odpowiedzi fallback.
Jak sprawdzić, czy problem leży w retrieval-u, czy w generacji?
Najprostszy test: ręcznie skopiuj istotny dokument bezpośrednio do kontekstu (z pominięciem retrieval-u) i wyślij go do modelu. Jeśli odpowiedź jest dobra, problem leży w retrieval-u. Jeśli nawet przy doskonałym kontekście model halucynuje lub odpowiada nieadekwatnie, problem tkwi w warstwie generacji — prompcie, modelu lub sposobie formatowania kontekstu. Ten ręczny test jest szybszy niż pełna ewaluacja i ujawnia większość problemów w ciągu kilku minut.
Czy LLM-as-judge jest wiarygodny? Czy może oceniać błędnie?
LLM-as-judge ma własne ślepe punkty — na przykład wyżej ocenia dłuższe odpowiedzi, nawet jeśli są mniej precyzyjne, albo preferuje styl zbliżony do danych treningowych modelu-sędziego. RAGAS częściowo to kompensuje, rozkładając faithfulness na konkretne twierdzenia i weryfikując każde z osobna. W przypadkach krytycznych (branże regulowane, systemy wrażliwe bezpieczeństwowo) zalecamy łączenie automatycznej ewaluacji z ludzką kontrolą przynajmniej dla podzbioru przypadków.
Jakiego modelu użyć jako judge w RAGAS?
W większości przypadków wystarczy model frontierowy średniej klasy (warstwa Sonnet/Flash/Haiku) — jest wystarczająco precyzyjny i znacząco tańszy niż najwyższy poziom. Jeśli masz wymagania on-prem lub pracujesz z danymi wrażliwymi, RAGAS obsługuje również modele lokalne przez API kompatybilne z OpenAI — silny model open-weight z rodziny Qwen3 lub Llama uruchomiony przez vLLM sprawdza się dobrze w zadaniach oceny.
*Jeśli zastanawiasz się, od czego zacząć ewaluację swojego systemu RAG, lub chcesz sprawdzić, gdzie dokładnie twój pipeline traci precyzję — w MP Industrial Solutions przeprowadzamy diagnostyczne oceny wdrożeń RAG i pomagamy wdrożyć proces ewaluacji, który daje użyteczne wnioski, nie tylko liczby.*