Jak mierzyć jakość RAG i ograniczać halucynacje AI?

System RAG może działać technicznie poprawnie, a mimo to udzielać złych odpowiedzi.

Dokumenty zostały zaindeksowane. Wyszukiwanie działa. Model otrzymuje kontekst. API zwraca odpowiedź. Wszystko wygląda dobrze - do momentu, gdy użytkownik pyta: skąd wzięła się ta odpowiedź?

I okazuje się, że system znalazł niewłaściwy dokument. Albo pominął kluczową informację. Albo dostał poprawny kontekst, ale dodał coś, czego w nim nie było. Albo odpowiedział poprawnie na poziomie faktów, ale nie rozwiązał pytania użytkownika.

Wszystkie te sytuacje bywają potocznie określane jako "halucynacje RAG". To zbyt duże uproszczenie. OpenAI opisuje halucynacje jako wiarygodnie brzmiące, lecz fałszywe stwierdzenia generowane przez model. W systemie RAG błędna odpowiedź może jednak powstać jeszcze zanim model zacznie generować tekst - na poziomie danych lub wyszukiwania.

Dlatego nie istnieje jedna sensowna metryka typu "nasz RAG ma 92% accuracy", która powiedziałaby, czy cały system działa dobrze. Żeby diagnozować RAG, trzeba mierzyć osobno jego kolejne warstwy.

Dobry proces ewaluacji RAG powinien odpowiedzieć przynajmniej na sześć pytań. Czy w bazie wiedzy znajduje się poprawna i aktualna informacja? Czy retriever znalazł właściwe fragmenty? Czy znalazł wszystkie informacje potrzebne do odpowiedzi? Czy model odpowiedział wyłącznie na podstawie dostępnego evidence? Czy odpowiedź rzeczywiście rozwiązuje pytanie użytkownika? I czy system potrafi nie odpowiadać, gdy nie ma wystarczających danych?

Dopiero połączenie tych informacji pozwala ustalić, dlaczego odpowiedź była błędna i co właściwie należy poprawić.

Co właściwie znaczy "halucynacja" w systemie RAG?

W praktyce przydaje się rozdzielenie co najmniej czterech klas błędów. Nie jest to jedna oficjalna, obowiązująca taxonomia RAG. To praktyczny podział diagnostyczny, który pomaga przypisać problem do odpowiedniej warstwy systemu.

Błąd w danych źródłowych

Informacji potrzebnej do odpowiedzi nie ma w korpusie albo dostępne źródła są nieaktualne, błędne, niekompletne lub sprzeczne.

Wyobraź sobie taką sytuację. W firmie aktualny maksymalny rabat bez zgody dyrektora wynosi 10%, ale baza wiedzy zawiera wyłącznie stary regulamin z limitem 15%. Retriever znajduje dokument z 15%. Model odpowiada: "Handlowiec może udzielić maksymalnie 15% rabatu."

Odpowiedź jest błędna biznesowo. Jednocześnie nie można powiedzieć, że zawiódł model albo retrieval. System prawidłowo wykorzystał jedyne źródło, które otrzymał. Problem znajduje się w korpusie wiedzy.

W naszym systemie BLUP-FLOCK widzieliśmy, jak bardzo jakość odpowiedzi zależy od tego, co dzieje się jeszcze przed jakimkolwiek modelem. Gdy zmieniliśmy fizyczny proces zbierania danych na fermie ściółkowej - nowe wagi, inny obieg pracy - jakość wyników systemu poprawiła się bez zmiany modelu. Żaden embedding nie naprawi tego, czego nie naprawiły dane źródłowe.

Błąd wyszukiwania

Poprawna informacja istnieje w bazie, ale system jej nie znalazł albo niewłaściwie uszeregował wyniki.

W tym samym przykładzie - w indeksie znajduje się zarówno stary regulamin z 15%, jak i nowy z 10%. Użytkownik pyta o maksymalny rabat. Retriever zwraca stary dokument, ale nie zwraca aktualnego. Model ponownie odpowiada 15%.

Tym razem wiedza była dostępna. Zawiódł etap wyszukiwania. To sytuacja, w której metadane - data obowiązywania, status dokumentu, wersja - mogą istotnie zmienić jakość retrievalu, pod warunkiem że pipeline aktywnie je wykorzystuje do filtrowania, rankingu lub wyboru źródła. Samo posiadanie pola valid_from=2026 niczego nie zmienia, jeśli retriever go nie uwzględnia. Pisaliśmy o tym szerzej w artykule o przygotowaniu danych do RAG.

Błąd generowania odpowiedzi

Retriever znalazł prawidłowy fragment: "Handlowiec może samodzielnie udzielić rabatu do 10%." A model odpowiada: "Może udzielić rabatu do 15%."

Evidence było dostępne, ale finalne twierdzenie nie wynika z dostarczonego kontekstu. To właśnie ten przypadek jest najbliższy temu, co przy ewaluacji RAG mierzymy jako faithfulness lub groundedness. Ragas definiuje Faithfulness przez sprawdzenie, jaka część twierdzeń zawartych w odpowiedzi znajduje oparcie w pobranym kontekście.

Odpowiedź poprawna, ale nieprzydatna

Użytkownik pyta: "Czy mogę wypowiedzieć umowę dzisiaj?" System odpowiada: "Zasady wypowiedzenia umowy znajdują się w §12 regulaminu."

Informacja może być całkowicie prawdziwa. Może być prawidłowo oparta na źródle. Ale użytkownik nadal nie wie, czy może wypowiedzieć umowę. To nie problem factual correctness ani groundedness. To problem realizacji zadania i relewancji odpowiedzi.

Dlaczego to rozróżnienie jest ważne?

Bo każda klasa błędu wymaga innej interwencji. Jeżeli właściwego dokumentu nie ma w bazie - zmiana system promptu niczego nie naprawi. Jeżeli retriever nie znalazł dokumentu - wymiana modelu generującego również może niczego nie zmienić. Jeżeli retrieval działa bardzo dobrze, ale model regularnie dopowiada informacje spoza kontekstu - wtedy problem rzeczywiście znajduje się bliżej warstwy generacji.

Błędna odpowiedź jest wynikiem całego pipeline'u, a nie wyłącznie pracy LLM.

Nie istnieje jedna "accuracy RAG"

LangSmith proponuje rozdzielenie ewaluacji RAG na correctness, relevance, groundedness i retrieval relevance. Każda z tych ocen porównuje ze sobą inne elementy systemu - odpowiedź z odpowiedzią referencyjną, odpowiedź z pytaniem, odpowiedź z pobranymi dokumentami albo dokumenty z pytaniem. Ragas podobnie rozdziela różne aspekty jakości, oferując między innymi Context Precision, Context Recall i Faithfulness.

W praktyce warto myśleć o tym w kategoriach warstw. Na poziomie retrievalu pytamy: czy znaleźliśmy właściwe informacje (retrieval relevance), czy istotne wyniki są wysoko w rankingu (Context Precision) i czy znaleźliśmy wszystko, co potrzebne (Context Recall). Na poziomie generacji pytamy: czy odpowiedź wynika z kontekstu (Faithfulness/Groundedness) i czy faktycznie odpowiada na pytanie użytkownika (Answer Relevance). Na poziomie end-to-end sprawdzamy finalną poprawność (Answer Correctness). A na poziomie systemu - kiedy odpowiada, a kiedy odmawia (coverage, error rate, abstention).

Ważne jest słowo "pomaga". Niski Answer Correctness nie mówi automatycznie, która warstwa zawiodła. Przyczyną może być błędne źródło, niewłaściwy retrieval, brak części potrzebnego kontekstu, grounding failure albo problem z samą odpowiedzią referencyjną. Metryki są przede wszystkim narzędziami diagnostycznymi.

Context Precision - czy właściwe fragmenty są wysoko?

Context Precision ocenia ranking pobranych fragmentów. Ragas opisuje tę metrykę jako ocenę zdolności retrievera do umieszczania relewantnych chunków wyżej niż fragmentów nieistotnych.

Załóżmy, że system pobiera 10 fragmentów i dwa zawierają odpowiedź. Jeżeli znajdują się na pozycjach 1 i 2 - ranking wygląda znacznie lepiej niż wtedy, gdy są na pozycjach 9 i 10. W obu przypadkach system "znalazł odpowiedź". Ale jakość retrievalu nie jest taka sama.

To szczególnie ważne, gdy do modelu przekazywana jest ograniczona liczba najlepszych wyników. Albo gdy duża ilość dodatkowego tekstu zwiększa koszt i komplikuje kontekst - zjawisko "Lost in the Middle", o którym pisaliśmy w poprzednim artykule, jest tu bardzo realne.

Context Recall - czy niczego ważnego nie zgubiliśmy?

Precision i recall odpowiadają na dwa różne pytania. Precision: ile z tego, co znaleźliśmy, jest potrzebne? Recall: jak dużą część tego, co było potrzebne, udało nam się znaleźć?

Ragas wskazuje, że Context Recall wymaga jakiejś formy referencji - odpowiedzi referencyjnej, referencyjnych kontekstów albo w wariancie ID-based identyfikatorów fragmentów, które powinny zostać pobrane.

Konkretny przykład. Użytkownik pyta: "Jakie warunki musi spełnić klient, żeby otrzymać bezpłatny serwis?" Poprawna odpowiedź wymaga trzech elementów - aktywnej umowy, przeglądu wykonanego w ciągu ostatnich 12 miesięcy i braku zaległości płatniczych. Retriever znajduje dwa pierwsze warunki. Znalezione fragmenty mogą być bardzo trafne. Precision może więc wyglądać dobrze. Ale retrieval jest niekompletny. To właśnie problem, który pomaga zobaczyć recall.

Faithfulness nie oznacza correctness

To jedno z najważniejszych rozróżnień w ewaluacji RAG.

Załóżmy, że system pobrał dokument: "Okres wypowiedzenia wynosi 60 dni." Model odpowiada: "Okres wypowiedzenia wynosi 60 dni." Odpowiedź jest idealnie zgodna z kontekstem. Ma wysokie groundedness. Ale dokument pochodzi z 2023 roku, a aktualny regulamin mówi: 30 dni. Odpowiedź jest więc faithful, ale niepoprawna.

Ragas mierzy Faithfulness jako zgodność twierdzeń odpowiedzi z dostarczonym kontekstem. LangSmith oddziela groundedness - odpowiedź versus retrieved documents - od correctness, gdzie odpowiedź jest oceniana względem odpowiedzi referencyjnej.

Wysoki wynik faithfulness odpowiada na pytanie "czy model trzymał się źródeł?", a nie "czy źródła mówiły prawdę?". To dwa różne problemy. I dlatego tak ważne jest, żeby źródła w korpusie były aktualne i prawidłowo wersjonowane - bez tego nawet idealny grounding nie gwarantuje poprawnych odpowiedzi.

Kto ocenia oceniającego?

Mamy metrykę - na przykład Faithfulness. Ale nadal musimy ustalić, jak ją zmierzymy. To rozróżnienie jest kluczowe: metryka to co chcemy mierzyć, evaluator to jak dokonujemy pomiaru.

Evaluator może być deterministycznym kodem, porównaniem identyfikatorów, metodą podobieństwa tekstowego, regułą biznesową, człowiekiem albo LLM-as-a-judge. LangSmith wspiera ewaluację przez kod, człowieka, LLM-as-a-judge i porównania pairwise. Ragas dobrze pokazuje różnicę na przykładzie Context Precision, oferując warianty wykorzystujące LLM, metody non-LLM oparte na podobieństwie tekstów i warianty ID-based.

Czy wynik LLM-as-a-judge jest "prawdą"?

Nie. Jeżeli evaluator sam wykorzystuje model językowy, jego wynik jest automatyczną oceną wygenerowaną według określonych kryteriów, a nie bezpośrednio obserwowalnym faktem.

LangSmith wprost zwraca uwagę, że LLM-as-a-judge wymaga przeglądu wyników i dostrajania promptu evaluatora. Dokumentacja opisuje proces porównywania ocen judge'a z anotacjami ekspertów oraz iteracyjnego poprawiania zgodności evaluatora z oceną człowieka.

Dlatego wynik typu faithfulness = 0.91 nie powinien być interpretowany jako "system jest obiektywnie faithful w 91%". Najpierw trzeba wiedzieć, jak definiowana była metryka, jaki evaluator jej używał, na jakim zbiorze była liczona i jaka była zgodność evaluatora z oceną ekspercką.

Deterministycznie tam, gdzie się da

Jeśli masz twardą referencję, korzystaj z niej bez niepotrzebnego angażowania LLM. Jeżeli dla pytania wiemy, że retriever powinien zwrócić dokumenty policy_2026 i discount_rules - możemy porównać ich ID z wynikami retrievalu. Nie potrzebujemy modelu językowego do stwierdzenia, czy oczekiwany dokument został znaleziony.

LLM-as-a-judge jest bardziej przydatny tam, gdzie potrzebna jest ocena semantyczna - czy odpowiedź rzeczywiście rozwiązuje problem użytkownika, czy twierdzenie jest wspierane przez fragment napisany innymi słowami, czy dwie różnie sformułowane odpowiedzi są merytorycznie równoważne.

Bez dobrego datasetu nie ma dobrej ewaluacji

Można zbudować świetny dashboard z metrykami i nadal niewiele wiedzieć o jakości RAG, jeżeli testujemy go na złym zbiorze pytań.

LangSmith rekomenduje rozpoczęcie od ręcznie przygotowanych, wysokiej jakości przykładów reprezentujących zarówno typowe scenariusze, jak i przypadki brzegowe. Później dataset można rozwijać o rzeczywiste trace'y produkcyjne i przypadki, przy których użytkownicy zgłaszali problemy.

W przypadku RAG warto zbierać kilka różnych rodzajów ground truth.

Pytanie plus oczekiwana odpowiedź - najprostszy wariant. Pytanie: "Jaki maksymalny rabat może przyznać handlowiec bez zgody dyrektora?" Referencja: "10%." Pozwala oceniać finalną correctness, ale ma ograniczenia. Dwie odpowiedzi - "10%" i "Handlowiec może samodzielnie przyznać rabat do 10%" - są merytorycznie równoważne. Dlatego przy generatywnych odpowiedziach exact match często nie wystarcza, a LangSmith wskazuje LLM-as-a-judge jako jedną z metod semantycznej oceny.

Pytanie plus właściwe źródła - zapisujemy, że dla danego pytania właściwe źródło to sales_policy_v4, sekcja 7.2. Dzięki temu możemy testować retrieval niezależnie od generacji. Jeżeli system odpowie źle, wiemy, czy właściwy dokument został znaleziony, na której pozycji się znalazł i czy został przekazany do modelu. To często daje więcej informacji diagnostycznych niż samo porównanie finalnych odpowiedzi.

Pytanie plus oczekiwane zachowanie systemu - nie każde pytanie powinno zakończyć się odpowiedzią. Jeżeli użytkownik pyta o coś, czego nie ma w bazie wiedzy, oczekiwanym zachowaniem może być odmowa: "Nie znajduję tej informacji w dostępnej dokumentacji." Taki przykład również powinien znaleźć się w datasecie. W przeciwnym razie testujemy system głównie na pytaniach, na które da się odpowiedzieć, i nie wiemy, jak zachowuje się przy braku evidence.

Dataset musi zawierać trudne przypadki

Realny dataset nie powinien składać się wyłącznie z prostych pytań typu "Jaki jest okres gwarancji?"

Powinien obejmować sytuacje, w których odpowiedź znajduje się w kilku dokumentach, istnieją podobne dokumenty dotyczące różnych produktów, występuje stara i nowa wersja dokumentu, użytkownik używa innej terminologii niż firma, pytanie jest niejednoznaczne, źródła są sprzeczne, odpowiedzi nie ma albo prawidłową reakcją jest poproszenie o doprecyzowanie.

To właśnie przypadki brzegowe najczęściej pokazują, czy architektura jest odporna, czy tylko dobrze działa na demonstracyjnych pytaniach.

W naszych projektach agentowych widzieliśmy to wielokrotnie. Przy budowie Ads Agenta, który operuje na wielu kontach Google Ads jednocześnie, trafiliśmy na przypadek, w którym agent mieszał w briefingu dane z różnych kont klientów - tworzył spójnie brzmiącą, ale niepoprawną analizę. Na prostych pytaniach dotyczących jednego konta wszystko wyglądało dobrze. Problem ujawnił się dopiero na zbiorze obejmującym wielu klientów - dokładnie ten typ edge case'u, który łatwo przeoczyć w testach ograniczonych do scenariuszy "happy path".

"Nie wiem" też trzeba mierzyć

Samo liczenie accuracy może premiować system, który częściej zgaduje.

OpenAI pokazało ten problem na przykładzie ewaluacji, w której model z większą skłonnością do abstencji miał nieco niższą accuracy, ale jednocześnie znacznie niższy error rate niż model zgadujący częściej. Odpowiedź błędna i świadoma odmowa odpowiedzi nie powinny być traktowane jak ten sam typ porażki.

Jednocześnie sama wysoka abstention rate niczego nie dowodzi. System, który odpowiada "Nie wiem" na każde pytanie, prawdopodobnie wygeneruje bardzo mało fałszywych informacji. Będzie też praktycznie bezużyteczny.

Dlatego warto rozdzielać przynajmniej cztery kategorie: correct answer (system odpowiedział i miał rację), incorrect answer (odpowiedział błędnie), correct abstention (słusznie nie odpowiedział) i unnecessary abstention (odmówił mimo dostępnego evidence).

Na tej podstawie można obserwować answer coverage - na jaką część zapytań system podejmuje próbę odpowiedzi - oraz error rate wśród udzielonych odpowiedzi. To dużo bardziej użyteczny obraz niż pojedynczy "abstention rate".

Metryk nie maksymalizuje się niezależnie

To jeden z najważniejszych problemów projektowania systemów RAG. W produkcji nie optymalizujemy wyłącznie precision, recall i faithfulness w izolacji. Dochodzą ograniczenia: quality kontra coverage kontra latency kontra cost kontra safety. Zmiana jednego elementu pipeline'u może poprawić jedną metrykę i jednocześnie pogorszyć inny aspekt systemu.

Większe k retrievalu - pobieramy więcej kandydatów, zwiększamy szansę znalezienia potrzebnego dokumentu. Ale większe k oznacza więcej wyników do przetworzenia. Ważne: nie należy mylić zwiększenia liczby dokumentów pobieranych przez retriever z przekazaniem większej liczby fragmentów do promptu LLM. To nie jest ten sam etap.

Więcej kontekstu nie jest automatycznie lepsze - dodatkowe fragmenty mogą dostarczyć potrzebnego evidence, ale mogą też zwiększyć ilość szumu, zużyć większą część context budget, zwiększyć koszt i opóźnienie. Nie chodzi o to, żeby przekazać modelowi jak najwięcej dokumentów. Chodzi o to, żeby dostarczyć wystarczający i możliwie relewantny kontekst dla konkretnego zadania.

Chunk size to kompromis - nie ma uniwersalnej wartości typu "najlepszy chunk ma 500 tokenów". Microsoft wskazuje, że wybór strategii chunkingu zależy od struktury dokumentów, charakteru zapytań i używanych modeli. Większe chunki mogą lepiej zachowywać pełny kontekst, mniejsze mogą lepiej reprezentować poszczególne fragmenty w wyszukiwaniu. Parametry powinny być porównywane na rzeczywistym datasecie.

Hybrid search nie jest magicznym przełącznikiem - vector search dobrze radzi sobie z podobieństwem semantycznym, keyword search jest szczególnie przydatny przy dokładnych ciągach znaków - symbolach, numerach produktów, nazwiskach, datach, specjalistycznych terminach. Azure AI Search łączy oba podejścia przez Reciprocal Rank Fusion. Microsoft raportuje korzyści w relewancji dla hybrid retrieval z semantic rankingiem w swoich testach, ale nie oznacza to, że każda aplikacja automatycznie uzyska lepszy wynik bez własnej ewaluacji.

Reranking poprawia ranking kosztem dodatkowego etapu - retriever może najpierw znaleźć większą pulę kandydatów, a osobny etap ponownie uszereguje wyniki przed przekazaniem do generatora. Rozdziela to candidate retrieval od final context selection. Ale reranking to dodatkowa praca w pipeline'ie i jego wpływ powinien być oceniany razem z jakością, latency i kosztami.

Restrykcyjna abstencja zwiększa bezpieczeństwo, ale może zmniejszyć coverage - możemy skonfigurować system tak, żeby odpowiadał tylko przy wystarczająco mocnym evidence. Jeżeli gating będzie zbyt restrykcyjny, system zacznie odmawiać również tam, gdzie odpowiedź była możliwa. Nie istnieje uniwersalny "najbezpieczniejszy threshold". Dla systemu wspierającego lekarza koszt fałszywej odpowiedzi jest zupełnie inny niż dla wyszukiwarki dokumentacji wewnętrznej.

Similarity score to nie "pewność odpowiedzi"

To częsty błąd implementacyjny. Vector database zwraca score związany z podobieństwem albo rankingiem dokumentów. Nie oznacza to, że 0.87 to 87% prawdopodobieństwa, że odpowiedź jest prawidłowa.

W Azure AI Search różne mechanizmy rankingu mają różne skale wyników - BM25, vector similarity, RRF i semantic ranker zwracają score'y liczone w różny sposób i o różnych zakresach.

Dlatego gatingu typu if similarity > 0.8: answer() nie należy traktować jako uniwersalnego mechanizmu kontroli halucynacji. Próg powinien być powiązany z sygnałem zwalidowanym na konkretnych danych konkretnego systemu - może to być kombinacja jakości retrievalu, wyniku rerankera, obecności wymaganych źródeł, oceny jakości evidence i reguł biznesowych.

Najważniejsze nie jest to, jak elegancko wygląda liczba, ale czy na datasecie rzeczywiście rozdziela ona przypadki, w których system powinien odpowiadać, od tych, w których powinien odmówić.

Co zrobić, gdy źródła są ze sobą sprzeczne?

To jeden z przypadków, który koniecznie powinien znaleźć się w testach. Załóżmy, że retrieval zwraca dwa dokumenty - jeden mówi "okres wypowiedzenia wynosi 30 dni", drugi "60 dni". Model nie powinien samodzielnie zgadywać, który dokument jest właściwy.

Architektura może stosować różne strategie zależnie od dostępnych danych. Priorytet aktualności - jeżeli dokumenty mają wiarygodne daty obowiązywania, system preferuje aktualny dokument. Priorytet autorytatywności - oficjalny regulamin może mieć wyższy priorytet niż FAQ, notatka pracownika albo prezentacja. Poinformowanie o konflikcie - system odpowiada: "W dostępnych dokumentach znajdują się sprzeczne informacje: jeden wskazuje 30 dni, drugi 60 dni." Albo abstencja - w zastosowaniu o wysokim ryzyku poprawną reakcją może być: "Nie mogę jednoznacznie ustalić odpowiedzi na podstawie dostępnych źródeł."

Metadata, wersjonowanie i hierarchia źródeł pomagają rozwiązać część takich problemów. Nie gwarantują jednak spójności wiedzy. Są elementem systemu zarządzania evidence, a nie automatycznym rozwiązaniem problemu jakości danych.

Najpierw ustal, która warstwa zawodzi

Najczęstszy błąd podczas poprawiania RAG wygląda tak: "System odpowiedział źle. Poprawmy prompt." Prompt jest tylko jednym z elementów pipeline'u.

Sensowniejszy proces diagnostyczny zaczyna się od prostego drzewa.

Czy prawidłowa wiedza istnieje w korpusie? Nie - problem danych. Tak - idziemy dalej.

Czy system ją znalazł? Nie - problem retrievalu. Tak - dalej.

Czy właściwy fragment dotarł do generatora? Nie - problem rankingu lub selekcji kontekstu. Tak - dalej.

Czy odpowiedź wynika z tego evidence? Nie - grounding failure. Tak - dalej.

Czy odpowiedź jest rzeczywiście poprawna i użyteczna? Nie - sprawdzamy źródła, ground truth oraz sposób realizacji zadania.

Czy przy braku evidence system potrafi nie zgadywać? Nie - potrzebny jest mechanizm abstencji lub gatingu.

Dopiero taka diagnostyka pozwala podejmować decyzje inżynieryjne na podstawie danych, a nie przeczuć.

W praktyce wygląda to tak: niski retrieval recall oznacza, że warto sprawdzić chunking, query rewriting, hybrid retrieval i metadata filtering. Dobre wyniki retrievalu przy słabym groundedness sugerują problem z instrukcjami generacji, modelem lub formatem evidence. Wysokie groundedness przy niskim correctness każe pytać o aktualność źródeł i jakość ground truth. Odpowiedź poprawna, ale nieprzydatna - to problem realizacji zadania i formatu odpowiedzi. System zgaduje przy braku evidence - potrzebna jest abstention policy. System zbyt często odmawia - trzeba sprawdzić, czy false abstention nie blokuje prawidłowych odpowiedzi.

Ta diagnostyka jest ważniejsza niż dowolna lista "10 sposobów na lepszy RAG". Bo ta sama technika może być bardzo skuteczna w jednym systemie i zupełnie niepotrzebna w drugim.

Offline evaluation to nie koniec

Przed wdrożeniem możemy testować system na przygotowanym datasecie. Ale użytkownicy niemal zawsze zaczną zadawać pytania, których zespół projektowy wcześniej nie przewidział. Dlatego potrzebna jest również obserwowalność produkcyjna.

LangSmith rozdziela offline evaluation - wykonywaną na przygotowanych przykładach, często z referencjami - od online evaluation na rzeczywistych trace'ach produkcyjnych, gdzie referencyjna odpowiedź zazwyczaj nie jest dostępna.

W praktyce warto zapisywać przynajmniej pytanie użytkownika, przetworzone zapytanie do retrievera, pobrane dokumenty i chunki, kolejność wyników i wyniki rerankingu, kontekst przekazany do LLM, finalną odpowiedź, źródła wykorzystane w odpowiedzi, decyzję o odpowiedzi lub abstencji, feedback użytkownika i wyniki evaluatorów.

Dzięki temu błędna odpowiedź przestaje być pojedynczym zdarzeniem typu "AI znowu coś wymyśliło." Staje się przypadkiem, który można odtworzyć, przypisać do konkretnej warstwy i dodać do zbioru regresyjnego.

Budujemy tak nasze systemy agentowe. W Ads Agent każda proponowana akcja - zmiana budżetu, pauza reklamy, modyfikacja strategii - przechodzi przez approve/reject pipeline, w którym zapisujemy rekomendację, kontekst historyczny i decyzję człowieka. Gdy coś wymaga korekty, możemy prześledzić, na jakich danych agent oparł swoją propozycję. To ten sam kierunek myślenia o obserwowalności, który sprawdza się w RAG.

Jak powinien wyglądać dojrzały proces ewaluacji RAG?

Nie zaczynałbym od pytania "Której biblioteki użyć do evals?" Zacząłbym od zdefiniowania failure modes - co w tym konkretnym systemie oznacza błąd? Inaczej definiujemy go dla wyszukiwarki wiedzy, support bota, systemu prawnego, wewnętrznego copilota i asystenta sprzedaży.

Potem - zbuduj reprezentatywny dataset. Uwzględnij typowe pytania, trudne pytania, brak odpowiedzi, konflikty źródeł i różne sposoby formułowania tego samego problemu. Przypisz metrykę do każdego ważnego failure mode. Nie mierz wszystkiego tylko dlatego, że biblioteka oferuje 20 metryk.

Dobierz evaluator. Jeżeli istnieje twarda referencja - wykorzystaj ją. Jeżeli potrzebujesz oceny semantycznej - rozważ LLM-as-a-judge. I zweryfikuj sam evaluator - szczególnie wtedy, gdy od jego wyniku zależą decyzje o zmianie modelu lub architektury.

Zdefiniuj kompromisy. Co jest ważniejsze w konkretnym produkcie - coverage, minimalizacja błędnych odpowiedzi, latency, koszt czy pełność odpowiedzi? Testuj zmiany regresyjnie - zmiana chunkingu, retrievera, modelu albo promptu powinna być porównywana na tym samym zbiorze. I zasilaj dataset problemami z produkcji - online monitoring powinien dostarczać nowych przypadków do kolejnych offline evals.

Wtedy ewaluacja staje się częścią cyklu rozwoju produktu, a nie testem wykonywanym raz przed wdrożeniem.

Czego metryki RAG nam nie powiedzą?

Metryki są potrzebne, ale żadna z nich samodzielnie nie odpowie na pytanie "Czy nasz RAG jest dobry?"

Context Precision może pokazać jakość rankingu, ale nie powie, czy źródła są prawdziwe. Context Recall może pokazać, czy retrieval nie zgubił potrzebnego evidence, ale wymaga odpowiedniej referencji. Faithfulness pokaże, czy odpowiedź trzyma się kontekstu, ale nie zagwarantuje, że kontekst jest aktualny. Answer Correctness może pokazać niezgodność z ground truth, ale sama nie wskaże, czy zawiniły dane, retrieval czy generacja. LLM-as-a-judge pozwala automatyzować ocenę semantyczną, ale jego wynik również wymaga kontroli i może wymagać kalibracji względem ocen ekspertów. A similarity score retrievera nie jest prawdopodobieństwem, że finalna odpowiedź będzie poprawna.

Dlatego dojrzała ewaluacja RAG nie polega na znalezieniu jednej idealnej metryki. Polega na zbudowaniu procesu, który pozwala odpowiedzieć: Co dokładnie zawiodło? Skąd to wiemy? Która zmiana powinna to poprawić? I czy po tej zmianie rzeczywiście poprawiliśmy system, nie pogarszając innego ważnego elementu?

Dopiero wtedy ewaluacja staje się narzędziem inżynieryjnym, a nie tylko dashboardem z liczbami.

Zobacz, jak budujemy produkcyjne systemy AI i integracje LLM →

Źródła

• OpenAI - Why language models hallucinate.
• LangChain / LangSmith - Evaluate a RAG application.
• LangSmith - Evaluation concepts.
• LangSmith - Application-specific evaluation approaches.
• LangSmith - Improve LLM-as-a-judge evaluators using human feedback.
• Ragas - Context Precision.
• Ragas - Context Recall.
• Ragas - Faithfulness.
• Microsoft Learn - Chunk large documents for RAG and vector search in Azure AI Search.
• Microsoft Learn - Hybrid search using vectors and full text in Azure AI Search.
• Microsoft Learn - Relevance scoring in hybrid search using Reciprocal Rank Fusion.