RAG Evals i RAGAS Metrics: jak naprawdę mierzyć jakość RAG-a zamiast ufać demom

Wyobraź sobie dość typowy moment w projekcie AI. Masz wewnętrznego asystenta z RAG-iem. Demo działa pięknie. Product manager zadaje pytanie o procedurę onboardingu partnera, system odpowiada płynnie, cytuje dwa dokumenty i wszyscy przez chwilę mają w głowie tę zdradliwą myśl: no, chyba dowieźliśmy. Potem przychodzi tydzień prawdziwego użycia. Support zgłasza, że odpowiedzi brzmią sensownie, ale czasem mijają się z intencją pytania. Prawnik mówi, że model cytuje dobry dokument, ale wyciąga z niego zły wniosek. DevOps zauważa, że po zmianie chunkingu bot nagle częściej odpowiada obszernie, lecz mniej konkretnie. A ty siedzisz przed ekranem i próbujesz odpowiedzieć na pytanie, które brzmi prosto, ale w praktyce jest piekielnie niewygodne: czy ten RAG naprawdę jest lepszy, czy tylko bardziej przekonująco brzmi?

I tu zaczyna się temat, który oddziela sensowne systemy AI od zgrabnych demo: ewaluacja RAG-a. Nie taka w stylu “przeklikałem pięć pytań i wydaje się okej”, tylko taka, która daje ci liczby, porównywalne eksperymenty i choć trochę obiektywnej odpowiedzi na pytanie, co właściwie poprawiłeś. Bo RAG bardzo łatwo sprawia wrażenie poprawnego. Jeżeli model generuje płynnie, odpowiedź ma sensowną strukturę i wygląda profesjonalnie, człowiek zbyt łatwo zakłada, że backend wiedzy też działa dobrze. A to są dwie różne rzeczy.

W praktyce potrzebujesz więc sposobu na rozdzielenie kilku problemów. Czy retriever w ogóle znalazł to, co trzeba? Czy znalazł to wysoko, a nie na miejscu dziewiątym, gdzie generator i tak tego nie użyje? Czy odpowiedź jest oparta na dostarczonym kontekście, czy model po prostu improwizuje? I nawet jeśli jest oparta na kontekście, to czy w ogóle odpowiada na pytanie użytkownika, a nie tylko mówi coś mądrego obok tematu? Mówiąc wprost: większość zespołów wie, że powinna mierzyć jakość, ale nie zawsze wie co mierzyć i jak interpretować wynik bez wpadania w samozachwyt albo paranoję.

Tu wchodzi Ragas. Pisane małą literą jako nazwa biblioteki, ale wiele osób mówi po prostu „RAGAS metrics”, bo tak się ten zestaw skojarzył rynkowi. To narzędzie i cały sposób myślenia, który pozwala zamienić vibe checki na systematyczne evale. Zamiast pytać „czy to wygląda lepiej?”, zaczynasz pytać „czy wzrosła faithfulness, czy spadł context recall, czy problem siedzi w retrievalu, czy w generacji?”. I nagle rozmowa o jakości przestaje być intuicją, a zaczyna być inżynierią.

Najważniejsza zmiana mentalna jest prosta: przestajesz oceniać RAG po demie, a zaczynasz oceniać go po powtarzalnych eksperymentach.

Ten tekst jest właśnie o tym. Nie tylko o czterech popularnych metrykach, które najczęściej pojawiają się przy RAG-u, czyli faithfulness, answer relevancy, context precision i context recall, ale też o tym, jak one działają pod spodem, gdzie kłamią, kiedy pomagają, a kiedy dają fałszywe poczucie bezpieczeństwa. Jeżeli po przeczytaniu będziesz umiał spojrzeć na zestaw wyników i powiedzieć „aha, retrieval jest kompletny, ale zaśmiecony” albo „generator brzmi dobrze, ale halucynuje względem dostarczonych źródeł”, to znaczy, że ten artykuł zrobił swoją robotę.

Kontekst i dlaczego to ważne właśnie teraz

Jeszcze niedawno wiele zespołów mogło sobie pozwolić na bardzo prymitywny sposób oceny systemów LLM-owych. Działa? Działa. Odpowiada ładnie? Odpowiada. Demo się sprzedało? Super. Problem polega na tym, że rynek z tej fazy już wyrósł. W 2026 mało kogo zachwyca sam fakt, że model umie napisać zgrabny akapit. Użytkownik oczekuje, że odpowiedź będzie trafna, osadzona w jego danych, aktualna i przewidywalna. A to oznacza, że sam model przestaje być głównym problemem. Głównym problemem staje się jakość całego systemu: ingestionu, retrievera, rerankingu, promptu, guardrails i ewaluacji.

RAG szczególnie mocno to obnaża. W klasycznym software’ze masz testy jednostkowe, integracyjne, benchmarki wydajnościowe, alerty, tracing. W RAG-u też powinieneś mieć ich odpowiedniki, tylko one dotyczą bardziej śliskiej materii: znaczenia, trafności i zgodności z kontekstem. Nie testujesz wyłącznie tego, czy endpoint odpowiedział 200 OK. Testujesz też, czy odpowiedź była sensowna, czy retriever nie pominął kluczowego źródła i czy model nie wyssał połowy treści z palca. Innymi słowy: nadal robisz inżynierię, tylko zmienił ci się typ awarii.

Dlaczego akurat teraz temat Ragas i metryk RAG robi się tak istotny? Powodów jest kilka. Po pierwsze, coraz więcej zespołów ma już działające prototypy i wchodzi w fazę optymalizacji. Wtedy zaczynają się bardzo konkretne pytania: czy nowy model embeddingowy jest lepszy, czy tylko inny? Czy większe top_k pomaga, czy tylko zalewa generator śmieciami? Czy reranker poprawił jakość, czy jedynie podniósł koszt i latencję? Bez metryk odpowiadasz na to na wyczucie. A wyczucie jest fajne do wyboru kawy, nie do prowadzenia eksperymentów na produkcyjnym systemie wiedzy.

Po drugie, sam ekosystem evali dojrzał. Narzędzia takie jak Ragas, LangSmith, Phoenix, Promptfoo, Braintrust czy węższe harnessy wewnętrzne sprawiły, że nie musisz już wszystkiego kleić od zera. Da się zbudować eval loop, który ma dataset, eksperymenty, raporty i progi akceptacji. To nie jest jeszcze tak przewidywalne jak testy kompilatora, jasne. Ale to już zdecydowanie nie jest faza „zobaczmy, co pokaże demo dla prezesa”.

Po trzecie, modele zrobiły się tak dobre językowo, że błędy są trudniejsze do wychwycenia gołym okiem. Dawniej halucynacja często brzmiała topornie. Dzisiaj potrafi być napisana świetnie. To trochę jak z dobrze ubranym oszustem: robi lepsze pierwsze wrażenie, więc łatwiej go wpuścić do środka. W systemie RAG bardzo często najbardziej niebezpieczne są odpowiedzi, które są eleganckie, częściowo prawdziwe i lekko przesunięte względem źródła. Człowiek po szybkim przeczytaniu powie „brzmi rozsądnie”. Metryka faithfulness może powiedzieć „nie, dwie z pięciu tez nie są wspierane przez kontekst”.

Po czwarte, rośnie znaczenie kosztu i odpowiedzialności. Jeżeli poprawiasz retrieval, ale jednocześnie dublujesz latencję i koszty inference, to musisz umieć pokazać, czy ta poprawa ma sens. Jeżeli budujesz asystenta dla obszaru regulated, to nie wystarczy, że odpowiedź jest „w przybliżeniu dobra”. Musi być uzasadnialna, powtarzalna i możliwa do audytu. A to oznacza, że ewaluacja nie jest dodatkiem dla perfekcjonistów. To jest warstwa kontroli jakości.

Ragas dobrze wpisuje się w ten moment rynku, bo promuje podejście experiments-first. Nie „wprowadziliśmy zmianę i liczymy, że będzie lepiej”, tylko „zmieniliśmy jeden element pipeline’u, odpaliliśmy ten sam zestaw przypadków, porównaliśmy wyniki i wiemy, co się poprawiło, a co zepsuło”. To jest bardzo zdrowa zmiana mentalna. Przestajesz patrzeć na RAG jak na magiczne pudełko z embeddingami, a zaczynasz jak na system, którego zachowanie da się mierzyć, profilować i iteracyjnie poprawiać.

RAGAS od podstaw: co właściwie mierzymy i z czego składa się eval

Najpierw trzeba uporządkować jedną rzecz, bo bez tego wszystkie metryki zaczną się mieszać. RAG to nie jest jeden problem. To jest kilka problemów, które spotykają się w jednym requestcie. Najpierw system musi znaleźć materiał źródłowy. Potem musi wybrać, co z niego jest naprawdę ważne. Na końcu model ma z tego wygenerować odpowiedź, która jest nie tylko poprawna, ale też użyteczna. Jeśli więc patrzysz na wynik końcowy typu „użytkownik dostał odpowiedź”, to patrzysz na sklejkę kilku etapów naraz.

Właśnie dlatego Ragas i podobne frameworki nie sprowadzają ewaluacji do jednego wyniku „quality score = 0.84”. To byłoby wygodne, ale mało użyteczne. Taki zbiorczy numer nie powie ci, czy problem siedzi w retrieverze, czy w generatorze. To trochę jakbyś mierzył ogólną dostępność systemu jednym wskaźnikiem, bez rozróżnienia na bazę danych, API, cache i kolejkę. Technicznie coś wiesz. Operacyjnie prawie nic.

W praktyce eval RAG-a zwykle operuje na próbce danych, która zawiera przynajmniej kilka pól:

from ragas.dataset_schema import SingleTurnSample

sample = SingleTurnSample(
    user_input="Jak anulować fakturę po błędnym naliczeniu opłaty?",
    response="Aby anulować fakturę, trzeba utworzyć korektę w panelu billingowym i zatwierdzić ją przez finanse.",
    reference="Błędnie naliczoną fakturę koryguje się przez wystawienie korekty w panelu billingowym. Korekta wymaga akceptacji zespołu finansowego.",
    retrieved_contexts=[
        "Procedura billingowa: korekta faktury jest wykonywana w panelu billingowym i wymaga akceptacji finansów.",
        "Instrukcja onboardingu klienta enterprise...",
    ],
)

Masz więc pytanie użytkownika, odpowiedź systemu, kontekst pobrany przez retriever i często także reference, czyli wzorcową odpowiedź albo punkt odniesienia. To pole reference jest bardzo ważne, bo część metryk potrzebuje czegoś, z czym da się porównać odpowiedź albo kompletność kontekstu. Bez tego możesz mierzyć pewne rzeczy, ale nie wszystko.

I tu ważne rozróżnienie: nie każda metryka potrzebuje tych samych danych. Faithfulness patrzy głównie na response i retrieved_contexts. Answer relevancy bierze user_input i response. Context recall potrzebuje reference, bo inaczej nie ma jak stwierdzić, czy retriever nie pominął istotnych informacji. Context precision może działać w kilku wariantach: z referencją, bez referencji, na podstawie ID-ów dokumentów albo nawet przy użyciu prostych metryk stringowych zamiast modelu.

To już samo w sobie mówi coś ważnego: metryki RAGAS nie są „jedną prawdą o jakości”, tylko zestawem soczewek patrzących na różne aspekty tego samego pipeline’u. Jeśli używasz tylko jednej, patrzysz na system przez dziurkę od klucza.

Żeby to dobrze zrozumieć, warto myśleć o RAG-u jak o pipeline’ie z trzema pytaniami kontrolnymi.

Pierwsze pytanie brzmi: czy dostarczyliśmy modelowi właściwy materiał źródłowy? To jest obszar retrievalu. Tu wchodzą metryki takie jak context recall i context precision.

Drugie pytanie brzmi: czy model użył tego materiału, zamiast sobie dopowiadać? To jest obszar grounding i faithfulness.

Trzecie pytanie brzmi: czy odpowiedź w ogóle odpowiada na pytanie użytkownika? To jest answer relevancy.

Zobacz, jakie to jest praktyczne. Możesz mieć system z bardzo wysoką faithfulness i nadal kiepskie doświadczenie użytkownika, bo odpowiedzi są bezpieczne, ale nie na temat. Możesz mieć świetną answer relevancy i fatalną faithfulness, czyli model odpowiada dokładnie na pytanie, tylko część treści sobie wymyśla. Możesz mieć wysokie context recall i niskie context precision, czyli retriever znajduje potrzebne informacje, ale przy okazji taszczy ze sobą stertę śmieci. Każda z tych sytuacji wymaga innej naprawy.

To jest zresztą jedna z najcenniejszych rzeczy, jakie daje Ragas: wymusza rozdzielenie problemu „czy odpowiedź jest dobra?” na bardziej użyteczne pytania diagnostyczne.

Minimalny mental model eval loopa

Jeżeli budujesz evale pierwszy raz, nie komplikuj tego bardziej niż trzeba. Najprostszy sensowny loop wygląda tak:

1. Budujesz golden dataset pytań, które reprezentują realne użycie.
2. Dla każdego pytania przepuszczasz request przez aktualny pipeline RAG.
3. Zapisujesz odpowiedź, pobrany kontekst, metadane i ewentualnie referencję.
4. Odpalasz zestaw metryk.
5. Porównujesz wyniki między wersjami systemu.

To brzmi banalnie, ale właśnie ten prosty rytm oddziela eksperyment od zgadywanki. Golden dataset nie musi na dzień dobry mieć tysiąca przykładów. Często 30-50 naprawdę dobrze dobranych pytań daje więcej niż 300 losowych. Powinny tam być happy pathy, pytania z exact ID, przypadki wieloznaczne, pytania bez odpowiedzi w bazie, pytania z ryzykiem prompt injection i pytania, które wcześniej wywołały regresję. W skrócie: nie budujesz datasetu pod ładny wynik. Budujesz go pod realne awarie.

W nowszej dokumentacji Ragas widać wyraźnie przesunięcie w stronę bardziej modularnych, kolekcyjnych API zamiast starych snippetów krążących po internecie. Dlatego dzisiaj sensowniejszy przykład wygląda raczej tak:

from openai import AsyncOpenAI
from ragas.llms import llm_factory
from ragas.embeddings.base import embedding_factory
from ragas.metrics.collections import (
    Faithfulness,
    AnswerRelevancy,
    ContextPrecision,
    ContextRecall,
)

client = AsyncOpenAI()
judge_llm = llm_factory("gpt-4o-mini", client=client)
judge_embeddings = embedding_factory(
    "openai",
    model="text-embedding-3-small",
    client=client,
)

faithfulness = Faithfulness(llm=judge_llm)
answer_relevancy = AnswerRelevancy(llm=judge_llm, embeddings=judge_embeddings)
context_precision = ContextPrecision(llm=judge_llm)
context_recall = ContextRecall(llm=judge_llm)

Potem dla pojedynczej próbki wołasz ascore() albo score(). To jest ważny szczegół praktyczny, bo masa blogów i repo pokazuje starsze importy typu from ragas.metrics import answer_relevancy, faithfulness ..., które wciąż pomagają zrozumieć ideę, ale niekoniecznie odzwierciedlają rekomendowany styl nowej dokumentacji. Jeżeli wrócisz do internetu po pół roku, trafisz na miks wersji. I tu zaczyna się robić dziwnie, bo ludzie myślą, że „RAGAS mi nie działa”, podczas gdy po prostu czytają tutorial z innej epoki biblioteki.

Czego metryki nie robią

To też trzeba powiedzieć jasno, zanim pójdziemy dalej. Metryki RAGAS nie są wyrokiem sądu ostatecznego. One nie zastępują człowieka, nie rozumieją twojego biznesowego celu lepiej niż ty i nie rozwiązują problemu złego datasetu. Jeśli reference jest kiepsko napisana, albo pytania są nieprzedstawicielne, albo judge model słabo radzi sobie po polsku, to dostaniesz ładne liczby opisujące wadliwą rzeczywistość. To nadal bywa użyteczne, ale trzeba zachować pokorę.

Najzdrowsze podejście brzmi: metryki to sygnały diagnostyczne, nie objawienie. Dobre sygnały. Często bardzo praktyczne. Ale nadal sygnały.

Cztery metryki, które naprawdę warto rozumieć

No dobra, to teraz ta część, dla której większość ludzi tu przyszła. Cztery najbardziej klasyczne metryki w evalach RAG-a to faithfulness, answer relevancy, context precision i context recall. Brzmi prosto. Problem w tym, że intuicyjnie ludzie często mieszają je ze sobą albo przypisują im rzeczy, których one wcale nie mierzą.

Faithfulness: czy odpowiedź jest wsparta kontekstem

Faithfulness mierzy, na ile odpowiedź modelu jest faktycznie zgodna z dostarczonym kontekstem. Nie z „prawdą obiektywną”, nie z internetem, nie z wiedzą modelu, tylko z tym, co retriever wsadził do promptu.

Mechanizm jest całkiem elegancki. Odpowiedź jest rozbijana na pojedyncze stwierdzenia, a potem każde stwierdzenie jest sprawdzane pod kątem tego, czy można je wywieść z retrieved_contexts. Jeśli masz cztery claimy i trzy są wspierane przez kontekst, wynik będzie mniej więcej 0.75.

$$
Faithfulness = frac{text{liczba claimów wspartych przez kontekst}}{text{liczba wszystkich claimów w odpowiedzi}}
$$

To świetnie łapie klasyczną halucynację typu: dokument mówi, że zmiana procedury weszła 12 marca, a model odpowiada 15 marca, bo „prawie pamiętał”. Dla człowieka to brzmi wiarygodnie. Dla metryki faithfulness to jest po prostu niewsparty claim.

Najlepsza rzecz w faithfulness jest też jej największym ograniczeniem. Jeżeli kontekst sam w sobie jest zły, nieaktualny albo niepełny, model może dostać świetny wynik faithfulness i nadal dać odpowiedź biznesowo błędną. To jest bardzo ważne. Faithfulness mierzy grounding względem kontekstu, nie prawdę względem świata. Jeśli w vector store siedzi stary runbook, to system może być pięknie faithful wobec przestarzałej bzdury.

Dokumentacja Ragas pokazuje to na prostym przykładzie z Einsteinem. Jeżeli kontekst mówi „urodził się 14 marca 1879”, a odpowiedź stwierdza „urodził się 20 marca 1879”, to jedno stwierdzenie przechodzi, drugie nie. Wynik spada do 0.5. Taki claim-level breakdown jest praktycznie bardzo sensowny, bo odróżnia odpowiedź całkowicie odklejoną od odpowiedzi częściowo poprawnej, ale z jednym istotnym błędem.

Warto też wiedzieć, że Ragas ma warianty faithfulness oparte nie tylko o zwykły LLM-as-a-judge, ale też np. o model HHEM-2.1-Open do wykrywania halucynacji. To ciekawa opcja, kiedy chcesz obniżyć koszt i ustabilizować pewien fragment oceny. Nie jest to magiczny zamiennik wszystkiego, ale pokazuje, że ekosystem ewoluuje od „wszystko sędziuje jeden wielki model” do bardziej zniuansowanych strategii.

Answer Relevancy: czy odpowiedź odpowiada na pytanie

Druga metryka brzmi podobnie do faithfulness, ale mierzy coś innego. Answer relevancy pyta nie o to, czy odpowiedź jest wsparta źródłami, tylko czy ona w ogóle odpowiada na intencję użytkownika.

To jest kluczowe, bo model może być bardzo wierny kontekstowi i jednocześnie mało pomocny. Wyobraź sobie pytanie: „czy po nowej polityce nadal trzeba ręcznie zatwierdzać provisioning?”. Kontekst zawiera kilka dokumentów o onboardingu, a model odpowiada trzyakapitowym streszczeniem procesu onboardingu. Wszystko może być poprawne i oparte na źródłach. Tylko użytkownik nie pytał o onboarding jako taki. Pytał o manual approval.

Ragas podchodzi do tego sprytnie. Zamiast bezpośrednio pytać sędziego „czy odpowiedź jest relewantna?”, framework generuje kilka sztucznych pytań na podstawie samej odpowiedzi, a potem porównuje embeddingi tych pytań z embeddingiem oryginalnego user_input. Intuicja jest taka: jeśli z odpowiedzi da się odtworzyć pytanie podobne do oryginału, to odpowiedź prawdopodobnie była na temat.

$$
AnswerRelevancy = frac{1}{N}sum_{i=1}^{N}cos(E_{gi}, Eo)
$$

Gdzie $E_{gi}$ to embedding pytania wygenerowanego z odpowiedzi, a $Eo$ to embedding oryginalnego pytania użytkownika.

To podejście ma kilka konsekwencji praktycznych. Po pierwsze, answer relevancy nie mierzy prawdziwości. Odpowiedź może być bardzo trafna względem pytania i zarazem faktograficznie błędna. Po drugie, metryka potrafi karać odpowiedzi zbyt ogólne albo omijające sedno. Po trzecie, opiera się na embeddingach i modelu generującym pytania pomocnicze, więc dobór judge stacku realnie wpływa na wyniki.

Ragas wspomina też, że wynik zwykle mieści się między 0 a 1, ale matematycznie cosine similarity może zejść niżej, więc nie traktuj tego zakresu jak prawa fizyki. W praktyce i tak większość sensownych przypadków kończy w znajomym przedziale.

Najważniejsza lekcja brzmi: answer relevancy łapie, czy użytkownik dostał odpowiedź na swoje pytanie, a nie czy system mówi prawdę. To jest inny rodzaj jakości.

Context Precision: czy właściwe chunki są wysoko, a nie tylko gdzieś tam

Tutaj wchodzimy w retrieval. Context precision mierzy zdolność retrievera do ustawiania relewantnych fragmentów wysoko w rankingu. I to jest ważniejsze, niż brzmi. Wiele zespołów zadowala się faktem, że potrzebny chunk „gdzieś był w top-10”. Tylko że generator zwykle nie używa całego top-10 z jednakową uwagą. Im wyżej trafny chunk, tym większa szansa, że realnie wpłynie na odpowiedź.

Ragas definiuje context precision jako średnią z precision@k dla kolejnych pozycji, z uwzględnieniem tego, które elementy są relewantne. W praktyce premiowane jest to, że dobre rzeczy pojawiają się wcześnie.

$$
ContextPrecision@K = frac{sum_{k=1}^{K} Precision@k cdot vk}{sum{k=1}^{K} v_k}
$$

Gdzie $v_k$ mówi, czy element na pozycji $k$ jest relewantny.

To prowadzi do ciekawej, trochę nieintuicyjnej konsekwencji. Jeżeli pierwszy chunk jest trafny, a drugi nietrafny, context precision może nadal pozostać bardzo wysokie. Dokumentacja pokazuje przykład, w którym niepotrzebny chunk dodany za trafnym nie psuje wyniku tak mocno, jak byś się spodziewał. Jeżeli jednak ten sam śmieciowy chunk wskoczy na pierwsze miejsce, wynik spada wyraźnie. To dobrze oddaje realny problem rankingowy: nie tylko „co znalazłeś”, ale „w jakiej kolejności to podałeś”.

W Ragas context precision występuje w kilku wariantach.

Pierwszy to wariant z reference, gdzie oceniasz przydatność kontekstu względem wzorcowej odpowiedzi.

Drugi to wariant bez reference, nazywany czasem ContextUtilization albo w starszym API LLMContextPrecisionWithoutReference, gdzie relewantność kontekstu jest oceniana względem wygenerowanej odpowiedzi. To przydatne, gdy nie masz gold answer, ale ma też oczywistą wadę: jeśli odpowiedź jest sama w sobie kiepska, precision może się „przykleić” do złej odpowiedzi.

Trzeci to warianty nie-LLM-owe, np. oparte o similarity stringów albo o ID dokumentów. Te są bardzo przydatne tam, gdzie masz dobrze oznaczone źródła i chcesz taniej albo stabilniej oceniać retrieval bez odpalania modelu sędziego.

Context Recall: czy retriever w ogóle nie zgubił tego, co potrzebne

Jeśli context precision pyta „czy dobre rzeczy są wysoko?”, to context recall pyta „czy dobre rzeczy w ogóle się znalazły?”. To metryka kompletności retrievalu.

W uproszczeniu: bierzesz referencyjną odpowiedź, rozbijasz ją na claimy i sprawdzasz, czy te claimy są wspierane przez retrieved_contexts. Jeżeli referencja zawiera pięć istotnych tez, a kontekst wspiera tylko trzy, context recall wynosi około 0.6.

$$
ContextRecall = frac{text{claimy z referencji wspierane przez retrieved context}}{text{wszystkie claimy w referencji}}
$$

To bardzo praktyczna metryka, bo świetnie wykrywa sytuację typu: generator nie był halucynacyjny, tylko po prostu nie dostał wystarczających dowodów. A to jest zupełnie inny problem niż słaba generacja. Jeśli context recall jest niski, zwykle patrzysz w stronę query transformation, chunkingu, filtrów, top-k, indeksu albo samej jakości źródeł.

I znowu dokumentacja ma tu fajny, nieoczywisty przykład. Pytasz „gdzie znajduje się Wieża Eiffla?”, a retrieved context brzmi „Paryż jest stolicą Francji”. Dosłownie rzecz biorąc, to nie jest ta sama odpowiedź. Ale inferencyjnie kontekst wystarcza, żeby poprzeć referencję „Wieża Eiffla znajduje się w Paryżu”. W LLM-based context recall taki przypadek może dostać pełen wynik. To ważna różnica względem prostego string matchingu. Ragas nie pyta tylko „czy teksty są identyczne?”, ale „czy kontekst niesie wystarczającą informację, by uzasadnić referencję?”.

Oczywiście context recall ma też cenę: potrzebuje referencji albo reference contexts. A ich tworzenie jest kosztowne. Właśnie dlatego Ragas traktuje reference jako proxy dla reference_contexts, bo ręczne opisywanie idealnych zestawów chunków dla każdego pytania potrafi zjeść bardzo dużo czasu.

Jedna tabela, żeby nie mieszać wszystkiego naraz

Jeżeli zapamiętasz tylko tę tabelę i nie pomylisz celu tych czterech metryk, to już będziesz dalej niż spora część tutoriali.

Jak to naprawdę czytać: interpretacja wyników, kombinacje i pułapki diagnostyczne

No dobra, załóżmy, że odpaliłeś evale i dostałeś cztery liczby. Co dalej? Tutaj właśnie większość zespołów zaczyna sobie szkodzić. Bo łatwo popaść w dwa skrajne błędy. Pierwszy: patrzeć tylko na średnią i ogłosić sukces. Drugi: patrzeć na każdy spadek o 0.02 jak na katastrofę. Oba podejścia są słabe.

Najbardziej użyteczne jest patrzenie na kombinacje metryk. To one mówią, gdzie w systemie siedzi problem.

To jest bardzo praktyczna macierz, bo prowadzi do różnych decyzji technicznych.

Jeżeli masz wysoki context recall i niski context precision, to często znak, że system działa jak junior, który do spotkania przygotował piętnaście artykułów i trzy PDF-y, ale nikt mu nie powiedział, że ma przyjść z trzema najważniejszymi. Informacja jest, tylko pakowanie kontekstu jest nieefektywne. Tu pomagają rerankery, lepsze filtry, mniejsze top_k, deduplikacja podobnych chunków albo lepszy chunking.

Jeżeli masz odwrotnie, czyli wysoki precision i niski recall, sytuacja wygląda jak kolega, który przyniósł bardzo ładnie wyselekcjonowane materiały, ale zapomniał jednego krytycznego dokumentu. Wyniki są czyste, tylko brakuje w nich połowy sprawy. Wtedy częściej patrzysz na query rewrite, semantyczne dopasowanie, liczbę kandydatów przed rerankingiem, sposób dzielenia dokumentów i coverage źródeł.

Jedna z najważniejszych rzeczy, jakie warto sobie wbić do głowy, brzmi tak: wysoki wynik pojedynczej metryki nie oznacza zdrowego systemu. Możesz mieć faithfulness na poziomie 0.95 i wciąż słaby produkt, jeśli answer relevancy jest niska. Możesz mieć answer relevancy 0.9, a jednocześnie regularnie halucynować, jeśli faithfulness spada. Możesz mieć świetny recall na golden secie, a produkcja nadal cierpi, bo golden set nie uwzględnia pytań wieloznacznych albo pytań po polsku z domenowym slangiem.

Średnia zabija kontekst

Tu trzeba być brutalnie szczerym: sama średnia potrafi zrobić więcej szkody niż pożytku. Załóżmy, że poprawiłeś context recall z 0.74 do 0.82. Brzmi dobrze. Ale jeśli ten wzrost wziął się wyłącznie z poprawy na łatwych pytaniach, a krytyczne scenariusze nadal zawodzą, to biznesowo mogłeś nie poprawić niczego, co ma znaczenie. Dlatego evale trzeba ciąć na slices: po typie pytania, po folderze dokumentów, po języku, po typie źródła, po potrzebie exact match, po ryzyku biznesowym.

To trochę jak z latency. Średni czas odpowiedzi może wyglądać świetnie, a p95 być dramatyczne. Z metrykami jakości jest podobnie. Średnia mówi, co się dzieje ogólnie. Użytkownik odczuwa to, co dzieje się w ważnych i trudnych przypadkach.

LLM-as-a-judge też trzeba traktować jak komponent, nie wyrocznię

Ragas bardzo często opiera się na modelu oceniającym. To wygodne i potężne, ale ma swoje konsekwencje. Judge może być niestabilny, wrażliwy na prompt, słabszy w jednym języku niż w drugim albo po prostu mieć inne intuicje niż twój zespół. To oznacza, że sam eval stack też wymaga walidacji.

Najrozsądniejsze podejście wygląda tak: bierzesz ręcznie oceniony, mały zestaw przypadków, porównujesz wyniki człowieka z wynikiem judge’a, patrzysz na zgodność i dopiero potem traktujesz ten judge jako sensowny automatyczny sygnał. Bez tego robisz meta-vibe-check: zastępujesz własną intuicję intuicją innego modelu i udajesz, że to obiektywność.

Warto tu pamiętać jeszcze o jednej rzeczy: wynik z jednego narzędzia nie jest porównywalny 1:1 z wynikiem z innego narzędzia. Faithfulness z Ragas, MLflow czy LlamaIndex może mieć podobną nazwę, ale inny prompt sędziego, inną skalę, inny mechanizm interpretacji. Jeśli jedno narzędzie daje 1, drugie 3/5, a trzecie YES, to nie znaczy, że któreś kłamie. Znaczy tyle, że używasz różnych definicji operacyjnych. Porównuj eksperymenty w obrębie tego samego setupu, nie między przypadkowymi frameworkami.

Język ma znaczenie, szczególnie poza angielskim

To jest temat regularnie niedoceniany. Jeżeli pytania, odpowiedzi i dokumenty są po polsku, a judge model jest przeciętny w polskim albo embeddingi średnio ogarniają niuanse domenowego języka, wyniki będą zafałszowane. Nie dlatego, że metryka jest zła, tylko dlatego, że jej narzędzia pomocnicze gorzej rozumieją materiał.

Ragas ma ścieżki adaptacji metryk do innych języków i to nie jest detal dla purystów. To jest praktyczna konieczność, jeśli twój system nie siedzi w sterylnym anglojęzycznym świecie benchmarków. W polskich deploymentach bardzo łatwo pomylić problem retrievalu z problemem oceniającego modelu. A potem zespół przez miesiąc „naprawia RAG”, podczas gdy tak naprawdę powinien zmienić judge stack albo przynajmniej skalibrować interpretację wyników.

Praktyczne zastosowania: gdzie te metryki naprawdę robią robotę

Sama teoria jest fajna, ale dopiero use case pokazuje, po co ci to w codziennej pracy. Najczęściej widzę trzy bardzo praktyczne zastosowania metryk RAGAS.

1. Porównywanie zmian w retrievalu

To jest najbardziej klasyczny scenariusz. Zmieniasz chunking, embedding model, top_k, reranker albo query expansion i chcesz wiedzieć, co się naprawdę stało.

Powiedzmy, że masz dwa warianty pipeline’u.

Wariant A: top_k=5, brak rerankera, chunki po 800 tokenów.

Wariant B: top_k=20, reranker cross-encoder, chunki po 350 tokenów.

Bez evali oba możesz ocenić tylko po demie. Z evalami patrzysz na profil zmian. Jeżeli w wariancie B recall rośnie, precision lekko spada, a faithfulness na końcu idzie do góry, to znaczy, że większy zestaw kandydatów plus reranking faktycznie poprawił dowody dla generatora. Jeżeli recall rośnie, ale faithfulness stoi w miejscu, możliwe, że retriever przynosi więcej sygnału, ale generator nadal słabo z niego korzysta. To już kieruje cię gdzie indziej.

To jest trochę jak strojenie zapytań i indeksów w bazie danych. Nie pytasz „czy nowy indeks jest fajny?”, tylko „czy skrócił czas odpowiedzi dla tego typu workloadu?”. Metryki RAGAS robią dokładnie taką robotę dla jakości semantycznej.

2. Eval gate w CI dla promptów i pipeline’u

Drugi use case jest bardziej dojrzały i moim zdaniem bardzo zdrowy: eval gate. Jeżeli zmieniasz prompt, retriever albo logikę pakowania kontekstu, nie chcesz polegać wyłącznie na PR review i nadziei.

Schemat jest prosty. W pipeline CI odpalasz ograniczony zestaw golden cases i porównujesz wyniki z baseline’em. Nie musisz blokować merge’a przy każdej fluktuacji o 0.01, bo to byłoby absurdalne. Ale możesz ustalić bardzo sensowne zasady, na przykład: faithfulness nie może spaść poniżej ustalonego progu albo context recall nie może regresować na krytycznych scenariuszach billingowych.

Pseudokod takiego podejścia wygląda mniej więcej tak:

baseline = load_baseline("evals/baseline_2026-04-20.json")
candidate = run_rag_eval(dataset="evals/golden_polish.jsonl")

assert candidate["faithfulness"] >= baseline["faithfulness"] - 0.02
assert candidate["context_recall_billing"] >= baseline["context_recall_billing"]
assert candidate["answer_relevancy"] >= 0.80

Ten snippet nie jest po to, żeby zachwycać złożonością. Właśnie odwrotnie. Chodzi o to, że porządny eval gate powinien być nudny i jednoznaczny. Im mniej uznaniowości przy interpretacji PR-a, tym lepiej.

3. Monitoring jakości po wdrożeniu

Trzeci use case jest najbardziej niedoceniany: metryki jako element obserwowalności po wdrożeniu. Bo prawda jest taka, że nawet jeśli golden set wygląda dobrze, produkcja potrafi się rozjechać. Zmieniają się dokumenty, dochodzą nowe pytania, użytkownicy wymyślają dziwniejsze formulacje, a do indeksu wpadają źródła, których nikt nie przewidział.

W takim świecie metryki RAGAS stają się nie tylko narzędziem eksperymentu, ale też systemem wczesnego ostrzegania. Jeśli rolling average faithfulness zaczyna spadać, to sygnał, że model coraz częściej wychodzi poza kontekst albo retrieval podaje gorsze dowody. Jeśli context recall siada po nowym imporcie dokumentów, może chunking nie radzi sobie z nowym typem źródeł. Jeśli answer relevancy w produkcji spada, a retrieval wygląda dobrze, możliwe, że problem jest w promptach albo w zmianie zachowań użytkowników.

W praktyce najlepiej działa połączenie: offline golden set do stabilnych porównań plus online sampling do monitorowania driftu. Jedno daje ci kontrolowane eksperymenty, drugie kontakt z rzeczywistym ruchem.

4. Debugowanie konkretnych porażek zamiast zgadywania

Jest jeszcze czwarty use case, który warto dopowiedzieć: debug. Kiedy ktoś mówi „ten RAG znowu odpowiedział dziwnie”, same logi tokenów niewiele pomogą. Jeśli masz przy requestcie zapisany kontekst, odpowiedź i scoring, możesz dużo szybciej dojść do sedna.

Scenariusz wygląda tak. User feedback mówi: odpowiedź była niepomocna. Patrzysz na sample. Answer relevancy niska, faithfulness wysoka. To często znak, że model nie halucynował, tylko odpowiedział obok sedna. Inny przypadek: answer relevancy wysoka, faithfulness niska. To zwykle oznacza zbyt agresywną syntezę albo prompt, który pozwala modelowi być „pomocnym” kosztem grounding. Jeszcze inny: recall niski, precision przyzwoity. Wniosek: retriever nie zgubił się kompletnie, ale nie miał z czego zbudować pełnej odpowiedzi. I nagle debugging przestaje być wróżeniem z promptu.

Typowe błędy i pułapki, przez które ludzie źle używają RAGAS

Teraz część trochę mniej romantyczna, ale za to bardzo potrzebna. Metryki są użyteczne tylko wtedy, gdy nie robisz z nich religii. A ludzie niestety mają talent do robienia religii z każdego dashboardu.

Pierwszy klasyczny błąd: optymalizacja pod jedną metrykę. Jeżeli gonisz wyłącznie context recall, bardzo łatwo skończysz z retrieverem, który przywozi pół internetu, byle tylko niczego nie pominąć. Jeśli gonisz wyłącznie faithfulness, możesz wytresować system do bardzo bezpiecznych, ale mało pomocnych odpowiedzi. Jeżeli ciśniesz tylko answer relevancy, model może zacząć odpowiadać „zbyt dobrze”, czyli odważnie i ponad źródłami. Metryki działają najlepiej jako zestaw napięć, nie jako jeden KPI absolutny.

Drugi błąd: słaby golden set. To brzmi banalnie, ale masa zespołów tworzy dataset z pytań najłatwiejszych, najładniejszych i najlepiej opisanych. Wynik potem wygląda pięknie, tylko nie ma związku z realnym ruchem. Dobrze zrobiony golden set powinien zawierać przypadki niewygodne: pytania wieloznaczne, krótkie, brudne językowo, z exact ID, z konfliktem źródeł, z brakującą odpowiedzią w bazie, z prompt injection w treści dokumentu. Jeśli nie testujesz niewygodnych przypadków, tak naprawdę testujesz zdolność systemu do przechodzenia prezentacji, nie produkcji.

Trzeci błąd: mylenie wyniku metryki z diagnozą root cause. Na przykład niski faithfulness nie zawsze znaczy „generator jest zły”. Czasem generator robi, co może, ale dostał chaotyczny kontekst albo zbyt szeroki prompt. Niski context recall nie zawsze znaczy „embeddingi są słabe”. Może problem siedzi w filtrach po metadatach. Wynik metryki to sygnał. Root cause trzeba jeszcze znaleźć.

Czwarty błąd: brak kalibracji judge’a. Jeśli używasz modelu oceniającego, powinieneś mieć przynajmniej małą próbkę ręcznie oznaczonych przypadków. Inaczej możesz dojść do absurdalnych wniosków. Model sędzia może być zbyt pobłażliwy, zbyt surowy albo po prostu niestabilny na danym stylu odpowiedzi. Szczególnie przy polskim albo domenowym słownictwie to nie jest detal.

Piąty błąd: porównywanie liczb między różnymi setupami jakby były jedną walutą. Zmieniłeś judge LLM, embedding model dla answer relevancy albo prompt metryki? To nie jest ta sama skala co wcześniej. Możesz porównywać trend w obrębie spójnej konfiguracji, ale mieszanie różnych definicji oceny to proszenie się o fałszywe wnioski.

Szósty błąd, bardzo praktyczny: ignorowanie staleness problemu. RAG może być metrically świetny i nadal niebezpieczny, jeśli indeks ma nieaktualne dokumenty. Faithfulness powie ci wtedy, że odpowiedź wiernie streszcza starą procedurę. Biznes powie ci, że właśnie wprowadziłeś ludzi w błąd. To nie jest sprzeczność. To dowód, że ewaluacja musi żyć obok sensownego indeksowania, cleanupu usuniętych plików, wersjonowania źródeł i telemetryki.

Najgorszy antywzorzec nie brzmi „nie mierzymy niczego”. Najgorszy antywzorzec brzmi „mierzymy wszystko, ale interpretujemy to jak horoskop”.

Ecosystem i narzędzia: co warto znać obok samych metryk

Ragas jest bardzo dobrym punktem wejścia, bo łączy kilka rzeczy naraz: metryki, datasety, eksperymenty, testset generation i rosnącą liczbę integracji z frameworkami typu LangChain, LlamaIndex czy LangGraph. Jeśli twoim głównym problemem jest „jak mierzyć jakość RAG-a i powtarzalnie porównywać eksperymenty”, to jest bardzo sensowny wybór.

Ale warto widzieć szerszy krajobraz, bo Ragas nie rozwiązuje całego świata.

LangSmith jest mocny tam, gdzie potrzebujesz tracingu, porównywania przebiegów i spinania evali z zachowaniem łańcuchów oraz agentów. Phoenix i szerzej ekosystem Arize dobrze wchodzą w obserwowalność, analizę błędów, zbieranie trace’y i oglądanie, co model dostał, co wypluł i gdzie się wykoleił. Promptfoo jest bardzo wygodny do prompt regressionów i testów porównawczych, szczególnie kiedy chcesz szybko zestawiać warianty outputów. Braintrust z kolei dobrze siedzi w eksperymentach, recenzjach wyników i pracy bardziej zespołowej wokół evali.

Jeżeli chodzi o metryki stricte retrievalowe, Ragas ma przewagę w tym, że jest mocno zakorzeniony w realiach LLM apps i RAG pipelines, a nie tylko w klasycznym IR. Masz tam nie tylko faithfulness czy recall, ale też agentowe i bardziej ogólne metryki, test data generation, adaptację do języków, możliwość pisania własnych kryteriów, a nawet ścieżki typu optimize/improve loops. To ważne, bo dojrzały system AI dość szybko wychodzi poza samo „czy odpowiedź była podobna do referencji?”.

Jednocześnie nie warto udawać, że każde narzędzie robi to samo. Jeśli największy problem masz w retrieval metrics i porównywaniu eksperymentów, Ragas jest mocny. Jeśli nie masz dobrej obserwowalności requestów i nie wiesz, który chunk trafił do promptu, samo dołożenie Ragas nie naprawi ci życia. Jeśli nie masz sensownego golden setu, żadne narzędzie nie wygeneruje za ciebie realnej definicji jakości produktu.

Co jest produkcyjnie sprawdzone, a co hype? Produkcyjnie sprawdzone jest przede wszystkim to, że evale trzeba mieć. Hype zaczyna się wtedy, gdy ktoś obiecuje, że jednym frameworkiem zastąpi proces myślenia o jakości. Nie zastąpi. Dobre narzędzia skracają drogę do odpowiedzi. Nie zdejmują z ciebie odpowiedzialności za zadanie właściwych pytań.

Podsumowanie i co dalej

Jeżeli miałbym streścić cały temat jednym zdaniem, to powiedziałbym tak: RAG bez evali to system, który łatwo ulepszać przez przypadek i równie łatwo psuć bez zauważenia tego na czas. Ragas jest cenny nie dlatego, że daje cztery modne liczby, tylko dlatego, że zmusza do rozdzielenia jakości na bardziej uczciwe pytania. Czy retriever znalazł to, co trzeba? Czy ustawił to wysoko? Czy odpowiedź naprawdę wynika z kontekstu? Czy w ogóle odpowiedziała na pytanie użytkownika? To są pytania, które prowadzą do sensownych decyzji technicznych.

Najważniejsze jednak jest to, żeby nie traktować metryk jak dekoracji do dashboardu. One są użyteczne tylko wtedy, gdy wpływają na sposób pracy zespołu. Gdy zmieniasz chunking i porównujesz wyniki. Gdy stawiasz progi jakości w CI. Gdy monitorujesz produkcję i łapiesz drift zanim użytkownicy stracą zaufanie. Gdy po incydencie nie mówisz „model znowu odpowiedział dziwnie”, tylko potrafisz wskazać, czy problem siedział w recallu, precyzji rankingu, groundingu czy samej relewantności odpowiedzi.

I jeszcze jedna rzecz, bardzo praktyczna. Nie próbuj zbudować idealnego systemu evali od razu. To częsty błąd ludzi technicznych: chcą od pierwszego dnia mieć pełen framework, tysiąc case’ów, slice’y, judge calibration, online telemetry i raport tygodniowy. Jasne, to jest piękny stan docelowy. Ale sensowny start jest dużo prostszy. Weź 30 realnych pytań z twojego systemu. Dla każdego zapisz user_input, response, reference i retrieved_contexts. Odpal cztery podstawowe metryki. Potem zmień jedną rzecz w pipeline’ie, na przykład chunk size albo reranker, i porównaj wyniki. Naprawdę jedną. Bez tego nie będziesz wiedział, co zadziałało.

To jest też moje konkretne ćwiczenie na koniec. Zrób własny mini golden set dla polskiego RAG-a. Nie publiczny benchmark, nie syntetyczny zestaw z tutoriala, tylko prawdziwe pytania z twojego use case’u. Oceń baseline przez faithfulness, answer relevancy, context precision i context recall. Następnie przetestuj jedną zmianę: albo query expansion, albo inny embedding model, albo inny sposób chunkingu. Jeśli po tej iteracji będziesz umiał powiedzieć nie tylko „wynik jest lepszy”, ale też dlaczego jest lepszy i w którym miejscu pipeline’u, to właśnie przestałeś robić vibe checks i zacząłeś robić inżynierię jakości RAG-a.