Diagnozowanie awarii RAG: mapa etapów oraz narzędzie oceny trafności twierdzeń na poziomie poszczególnych stwierdzeń

Kiedy bot RAG zaczyna udzielać błędnych odpowiedzi

Rozwijanie aplikacji RAG to nie koniec pracy, zwłaszcza w środowisku produkcyjnym. W końcu zaczyna ona udzielać błędnych odpowiedzi, a pierwszym wyzwaniem jest znalezienie przyczyny. System ma co najmniej siedem miejsc, gdzie może wystąpić ukryty błąd: dzielenie na fragmenty, tworzenie embeddingów, wyszukiwanie informacji, ponowna sortowanie, budowa kontekstu, generowanie tekstu oraz prompt, który to wszystko łączy. Zła ostateczna odpowiedź prawie nic nie ujawnia na temat tego, który element zawiodł. Niektórzy inżynierzy spędzili tydzień na dopracowywaniu promptu służącego do generowania tekstu, podczas gdy przyczyną była błąd w dzieleniu treści na fragmenty.

Istnieje dość mechaniczny sposób na zlokalizowanie awarii. Po tym pojawia się drugi problem – pomiar stopnia uzasadnienia na większą skalę, ponieważ analiza każdego transkryptu staje się niemożliwa po fazie potwierdzenia koncepcji. Sztuczna inteligencja działająca jako sędzia może wykonać tę pracę, ale sędziowie również mają własne sposoby awarii, które równie łatwo umkną uwadze jak błędy RAG, które mają wykrywać. Oba aspekty są omówione poniżej: śledzenie awarii do ich źródła oraz tworzenie sędziego oceniającego uzasadnienie, który zasługuje na zaufanie.

Najpierw znajdź uszkodzony link

Proces RAG to łańcuch, a pierwszym zadaniem jest zidentyfikowanie, który link zawiodł, zanim ktokolwiek edytuje prompt. Poniższa mapa stanowi ramy do zlokalizowania problemu. Nie jest wyczerpująca i można ją rozszerzyć, aby odpowiadała konkretnemu systemowi i zastosowaniu.

To uporządkowanie jest celowe: najpierw naprawia się proces wyszukiwania, a dopiero potem generowanie. Inżynieria promptów nie może naprawić okna kontekstowego, które nigdy nie zawierało właściwych faktów. Zespoły często działają w odwrotnym kierunku, przepisując prompt systemowy pięć razy, podczas gdy mechanizm ponownego rankowania deprecjonuje ten fragment tekstu, który miał znaczenie. Tanie rozwiązania o dużych korzyściach, takie jak lepsze dzielenie tekstu na fragmenty lub hybrydowe wyszukiwanie, powinny być stosowane przed droższymi metodami, jak dopracowywanie mechanizmu ponownego rankowania czy przeszkolenie modelu.

Trzy realistyczne objawy pokazują, w jaki sposób jest wykorzystywana ta mapa:

1. Odpowiedzi pojawiają się z pewnością siebie, mimo że dokumenty w ogóle nie dotyczą tematu. To nie jest proces wyszukiwania, ponieważ nie ma nic istotnego do pobrania. Jest to awaria w generowaniu lub unikaniu odpowiedzi: model nie traktuje zwrotu „Nie mam tego” jako przyjętej odpowiedzi.
2. Bot dostarcza wiarygodne, ale przestarzałe informacje. Problem prawie nigdy nie leży w metodzie dzielenia na fragmenty. Indeks jest przestarzały, ponieważ dokumenty się zmieniły, a nikt ich ponownie nie włączył.
3. Pytania oparte na jednym faktzie są rozwiązywane pomyślnie, natomiast te wymagające dwóch faktów z dwóch dokumentów zawodzą. Jest to błąd w wyszukiwaniu specyficzny dla zapytań wieloetapowych, ponieważ jedna sesja intensywnego wyszukiwania nie może pobrać dwóch elementów, z których każdy wygląda inaczej niż zapytanie.

Kolejnym krokiem jest pobranie rzeczywiście odnalezionego kontekstu dla nieudanego przykładu i jego przeczytanie przed jakimikolwiek zmianami. Jeśli danego faktu tam nie ma, problem leży w wyszukiwaniu. Jeśli jest on obecny, a model nadal go błędnie interpretuje, problem leży w generowaniu tekstu. Ta jedna weryfikacja może zaoszczędzić wiele dni.

Co oznacza uzasadnienie

Czytanie transkrypcji jest w porządku w niewielu przypadkach, ale bezużyteczne przy tysiącach. W takich sytuacjach interweniuje sędzia oparty na modelu językowym, konkretnie ten zajmujący się podstawieniem informacji, znany także jako wierność. Jego pytanie brzmi: czy każde twierdzenie w odpowiedzi można odnieść do czegoś w pobranych danych.

Jeden subtelny aspekt od razu myli ludzi: podstawienie informacji i poprawność to różne kwestie. Prawdziwa odpowiedź może być pozbawiona podstaw, na przykład gdy model znał fakt z treningu, a nie z dokumentów. Odpowiedź oparta na podstawieniu informacji może być błędna, jeśli pobrany fragment był już przestarzały lub błędny. Przy ocenie RAG najważniejszą miarą jest właśnie podstawienie informacji, ponieważ pokazuje ono, czy proces pobierania danych został prawidłowo wykonany, niezależnie od jakości źródłowych dokumentów.

Sędzia na poziomie twierdzeń

Jedno proste polecenie, które prosi o ocenę trafności od 1 do 5, wydaje się rozsądne, ale zazwyczaj okazuje się prawie bezużyteczne. Daje ono liczbę bez żadnego wyjaśnienia, a ocena pełnej odpowiedzi to dokładnie obszar, w którym modele językowe zachowują się niespójnie. Znacznie lepsze efekty daje podzielenie odpowiedzi na pojedyncze twierdzenia i sprawdzenie każdego z nich osobno.

Początkowe polecenie zawiera rolę systemową, która przedstawia model jako oceniacza trafności, podaje pytanie, dostępny kontekst oraz wygenerowaną odpowiedź, a także jasno wskazuje, że zadaniem nie jest ocena, czy odpowiedź jest prawdziwa w ogóle. Następnie prosi o wyodrębnienie twierdzeń i ich pojedyncze sprawdzenie w odniesieniu do kontekstu, z orzeczeniem oraz fragmentem tekstu potwierdzającym każde z nich:

SYSTEM:
You are a groundedness evaluator. You will be given a QUESTION, a CONTEXT
(retrieved passages), and an ANSWER generated by an AI assistant. Your job
is NOT to judge whether the answer is true in general, or well-written, or
relevant — only whether it is fully supported by the CONTEXT.

Do the following:

1. Decompose the ANSWER into a list of atomic claims (each claim = one
   discrete factual statement, not a compound sentence).
2. For each claim, decide:
   - SUPPORTED: directly stated or reasonably entailed by CONTEXT
   - CONTRADICTED: conflicts with CONTEXT
   - UNSUPPORTED: not addressed by CONTEXT at all (NOT the same as "false")
3. Quote the exact span of CONTEXT used as evidence for each claim
   (or "none" if UNSUPPORTED/CONTRADICTED).
4. Give a one-sentence rationale per claim.
5. groundedness_score = (# SUPPORTED) / (# total claims).

Be strict: a claim that adds specificity not in CONTEXT (context says "a
discount applies," answer says "a 20% discount applies") is UNSUPPORTED.

Return valid JSON only:
{
  "claims": [{"claim": "...", "verdict": "...", "evidence_span": "...", "rationale": "..."}],
  "groundedness_score": 0.0,
  "num_claims": 0
}

QUESTION: {question}
CONTEXT: {context}
ANSWER: {answer}

Część decyzji projektowych musi być jasno sformułowana, ponieważ na początku nie są oczywiste:

• Ocena na poziomie twierdzenia. Trudno jest debugować jeden ogólny wynik. Werdykty dla poszczególnych twierdzeń pokazują dokładnie, które stwierdzenie zawiodło, co jest ważne, gdy ktoś musi naprawić podstawową przyczynę.
• Obowiązkowy zakres dowodów. Wymaganie od sędziego podania tekstów potwierdzających skłania go do opierania werdyktów na dowodach, a nie na prawdopodobieństwie, a także umożliwia ludzkiemu recenzentowi szybkie sprawdzenie orzeczenia bez ponownego czytania całego kontekstu.
• UNSUPPORTED versus CONTRADICTED. Sprzeczność z dowodami oraz brak wsparcia to dwa odrębne błędy wymagające różnych rozwiązań. Połączenie ich w jeden etykiet „zły” utrudnia identyfikację szczegółów diagnostycznych.
• Jasne polecenie, by postępować surowo. Sędziowie LLM mają tendencję do łagodności w przypadkach granicznych, szczególnie gdy odpowiedź brzmi wiarygodnie, a żądanie surowości zmniejsza to zjawisko.

Weryfikacja sędziego w porównaniu z ludźmi

To krok, który zawsze jest pomijany, a który decyduje o tym, czy reszta ma jakąkolwiek wartość: sędzia musi zostać zweryfikowany w porównaniu z ludźmi, zanim będzie można mu ufać.

Proces jest prosty. Weź od 100 do 200 przykładów, poproś osobę o niezależną ocenę trafności odpowiedzi oraz oblicz stopień zgodności za pomocą współczynnika Kappa Cohena. Surowa dokładność może wprowadzać w błąd, gdy większość odpowiedzi jest trafna, ponieważ sędzia, który zawsze stwierdza „trafne”, osiąga dobre wyniki, ale jest bezużyteczny. Sprawdź również typowe uprzedzenia sędziów:

• Uprzedzenie pozycyjne: czy werdykt zmienia się, jeśli akapity kontekstowe zostaną przestawione?
• Uprzedzenie na rzecz rozwlekłości: czy sędzia faworyzuje dłuższe odpowiedzi, niezależnie od tego, czy są one rzeczywiście lepiej uzasadnione?
• Uprzedzenie związane z własną preferencją: jeśli sędzia należy do tej samej rodziny modeli co generator, może lepiej oceniać wyniki tej rodziny.
• Drift łagodności: czy zgodność stopniowo słabnie w ciągu tygodni wraz ze zmianami w modelu sędziego lub wersji promptu?

Niska wartość kappa w danej kategorii jest sygnałem do poprawy kryteriów oceny dla tej kategorii. Nie oznacza to, że system RAG jest w niej uszkodzony. Ludzie ciągle mylą te dwa pojęcia, a w następnej sekcji omówimy tę różnicę.

Czytanie panelu sterowania jak operator

Wyobraź sobie panel sterowania podzielony według typu zapytania. Prawidłowa postawa to postawa operatora, a nie kogoś, kto tylko obserwuje wyniki.

Średnia ogólna wykazuje niewielki spadek, co może być mylące. Szczegółowo, wyniki wyglądają w następujący sposób.

1. Proste sprawdzanie faktów pozostaje stabilne i na wysokim poziomie zarówno pod względem trafności, jak i zgodności. Zarówno system, jak i sędzia uważają je za łatwe. Samo w sobie jest nudne, ale spadek wskazywałby na awarię czegoś podstawowego: indeksowania, wyszukiwania danych lub instrukcji dla sędziego, a nie na problemy z rozumowaniem czy niejednoznacznością.
2. Metoda wieloetapowa i porównanie wykazały gwałtowny spadek jakości. Przy κ=0.71 zgodność jest jedynie umiarkowana, więc szum w długich odpowiedziach, które utrudniają dekompozycję, może być częściowym powodem tego zjawiska. Zanim stwierdzimy regresję, weź pięć nieudanych transkrypcji i sprawdź, czy oba fragmenty potrzebne do odpowiedzi znajdują się w kontekście. Jeśli dotarł tylko jeden fragment, chodzi o problem wydobywania i przypominania informacji – metoda jednorazowego, gęstego wydobywania często pomija dwa fakty, które nie przypominają zapytania, a rozwiązaniem jest dekompozycja zapytania lub wydobywanie informacji na podstawie kilku zapytań, a nie modyfikacja promptu. Jeśli oba fragmenty dotarły, a porównanie nadal nie udaje się, winna jest synteza, przy czym głównym podejrzanym jest efekt „zagubienia się pośrodku” – model opiera się na pierwszym fragmencie i przyznaje drugiemu zbyt małą wagę.
3. Wartości liczbowe i finansowe wskazują κ=0,52. Jest to słaba zgodność i najwyraźniejszy sygnał w tabeli, ponieważ oznacza to, że w tym przypadku nie można jeszcze ufać sędziemu. Równoważność liczbowa jest naprawdę trudna dla sędziego opartego na modelu LLM: „20%”, „mniej więcej jedna piąta” oraz „20 dolarów zniżki na produkt za 100 dolarów” to to samo stwierdzenie w różnych sformułowaniach. Rozsądny instynkt podpowiada, by zostawić system RAG w spokoju, dopóki kryteria oceny nie zostaną ustalone, ponieważ dążenie do niepewnych liczb marnuje czas poświęcony na rozwój technologii.
4. Kwestie polityczne i proceduralne są stabilne i w porządku, podobnie jak w pierwszym wierszu, ale z innej przyczyny: odpowiedzi zazwyczaj pochodzą z jednego dobrze zorganizowanego dokumentu i nie wymagają syntezy z kilku źródeł. Jeśli ich jakość spada, pierwszym podejrzanym nie jest proces rozumowania. Bardziej prawdopodobne jest podział listy numerowanej na części, przez co model ma do dyspozycji kroki od 1 do 3, a kroki 4 i 5 musi wymyślić sam.
5. Poza zakresem zasługuje na pierwszą korektę, mimo że n=20 sprawia, iż jest to najmniejszy segment. Przy κ=0.90 oceniający jest tutaj bardzo wiarygodny, ponieważ wykrycie wymyślonej odpowiedzi bez żadnego uzasadnienia jest o wiele łatwiejsze niż ocena subtelnych twierdzeń liczbowych lub wieloetapowych. Ta wiarygodność sprawia, że spadek jest prawdopodobny, i jest to najniebezpieczniejszy błąd w tabeli. System przesunął się od poprawnego przyjmowania odpowiedzi „Nie wiem” do samowolnego wymyślania odpowiedzi z pewnością siebie, co jest gorsze od błędnej liczby, ponieważ tonowo nie różni się od poprawnej odpowiedzi. Dwie możliwe przyczyny: system wyszukiwania zwraca fragmenty zbliżone do odpowiedzi, które model traktuje jako zgodę na udzielenie odpowiedzi, albo niedawna zmiana w instrukcjach lub modelu po cichu usunęła polecenie powstrzymania się od odpowiedzi. Zacznij od ocen podobieństwa uzyskanych przy wyszukiwaniu dla tego segmentu. Jeśli odpowiedzi znajdują się blisko poziomu szumu, a model i tak udziela odpowiedzi, oznacza to, że brakuje bariery progu istotności przed generacją.

Metoda w pięciu krokach

Całe zadanie sprowadza się do tego:

• nie ufać wynikom agregacji
• sprawdzić niezawodność sędziego przed zaufaniem do oceny
• podzielić na kategorie
• na podstawie rzeczywistych dowodów założyć, na jakim etapie doszło do błędu
• określić priorytety na podstawie powagi problemu i poziomu pewności, a nie tego, który parametr najbardziej się zmienił

Wskazówki praktyczne dla nowych oceniaczy

1. Każda oceniona odpowiedź wymaga dodatkowego wywołania modelu LLM. Przy dużej ilości zapytań należy oceniać tylko próbki, a nie wszystko, oraz podzielić je według kategorii, aby rzadkie, ale kluczowe przypadki nie zostały przytłoczone licznymi prostymi zapytaniami.
2. Ponownie zweryfikować wartość kappa za każdym razem, gdy zmienia się model sędziego lub prompt sędziego. Każda z tych zmian tworzy nowego sędziego.
3. Sędzia dostosowany do specyficznych cech numerycznych lub żargonu jednej domeny nie przenosi się automatycznie na inną, dlatego kalibracja powinna być przeprowadzana dla każdej domeny osobno, a nie raz na poziomie globalnym.

Wszystkie przykłady i ilustracje tutaj mają charakter edukacyjny i nie pochodzą z rzeczywistego systemu produkcyjnego. Ramy robocze oraz struktura zapytań stanowią rozsądny punkt wyjścia.

Gdzie to się kończy

Materiał powyżej obejmuje informacje na temat lokalizacji błędów, różnicy pomiędzy uzasadnionością a poprawnością, mechanizmu oceny na poziomie twierdzeń oraz kroku kalibracji, który wielu pomija. Pozostaje jednak jedna ograniczenie: wszystko to zakłada istnienie jednego czystego bloku uzyskanego kontekstu. To założenie zawodzi, gdy system korzysta z narzędzi, łączy kroki pozyskiwania informacji lub opiera swoje decyzje na własnych wynikach pośrednich, jak to robią systemy agentowe. Określenie pojęcia uzasadnioności bez możliwości sprawdzenia go na podstawie jednego bloku kontekstu oraz odpowiednia modyfikacja mechanizmu oceny to odrębny problem.

Literatura pokrewna

• Notatki praktyczne: Gdzie nauczyć się RAG od zera w 2026 roku: kursy i — Szczegółowy przewodnik po Notatkach praktycznych: Gdzie nauczyć się RAG od zera w 2026 roku: kursy i: umowy, sprawdzenia oraz miejsca na kod dostępne dla zespołów wdrażających ten model.
• RAG z LangChain od zera: loaderzy, kawałki danych, embeddingi, ocena — Budowanie systemu Q&A dla dokumentów krok po kroku: ładowanie plików, dzielenie na kawałki, embeddingi, fazy indeksowania i wyszukiwania oraz sposoby oceny wyników wyszukiwania i odpowiedzi.

Cross-Encoder jako sędzia: Bramka dla twojego pipeline RAG z wynikami relevancji — Jak mechanizm cross-attention pozwala cross-encoderowi oceniać stopień relevancji zapytania i dokumentu w zakresie od 0 do 1, oraz jak progi mogą zapobiec temu, by słabe wyniki wyszukiwania trafiły do modelu LLM.