Dlaczego zmiana modelu LLM nie rozwiązuje halucynacji w RAG?

Halucynacja w RAG pochodzi z trzech źródeł: niepowodzenia odzyskiwania, treningu modelu do zgadywania oraz braku pomiaru między nimi. Zmiana modelu adresuje tylko jeden element (LLM), podczas gdy problem leży przede wszystkim w odzyskiwaniu i zachętach treningowych modelu.

Jakie jest rzeczywiste procent halucynacji w systemach RAG?

Audyt narzędzi prawnych wykazał stopy halucynacji między 17% a 34%, a w systemach medycznych standardowy RAG obniżył faktualność o 6%. Nawet najlepsze modele (GPT-4o) halucynują w 9,6% podsumowań pojedynczych dokumentów.

Czy więcej fragmentów w kontekście poprawia dokładność RAG?

Nie – badania pokazują, że wydajność maleje wraz ze wzrostem długości wejścia, a cztery dokumenty rozpraszające znacznie obniżają dokładność. Precyzja odzyskiwania jest ważniejsza niż recall.

Jak mierzyć jakość systemu RAG w produkcji?

Używaj triady RAG: istotność kontekstu (czy odzyskiwanie znalazło właściwy materiał), ugruntowanie (czy odpowiedź trzyma się tego materiału) i istotność odpowiedzi (czy odpowiada na pytanie). Standardowe agregaty maskują rzeczywiste problemy.

Czy większe modele są bardziej wierne w RAG?

Nie – badania Salesforce wykazały, że większe modele nie są niezawodnie bardziej wierne. Problem leży w architekturze modelu i jego treningu, a nie w rozmiarze.

Dlaczego RAG ciągle halucynuje – przyczyny i rozwiązania

Odkryj, dlaczego systemy RAG mimo wszystkich poprawek wciąż generują błędne informacje.

Halucynacja w systemach RAG (Retrieval Augmented Generation) nie jest wynikiem pojedynczego błędu, który można naprawić wymianą modelu czy dodaniem desperackiego systemowego prompta – to trzech współpracujących problemów, których struktura leży głębiej w architekturze pipeline’u i treningu modeli.

Znajomy scenariusz: pipeline halucynuje przed klientem, więc zamieniasz model osadzania, następnie uaktualniasz LLM, dodajesz systemowy prompt nakazujący UŻYWAJ TYLKO PODANEGO KONTEKSTU – i mimo wszystko system cytuje dokument, który nie istnieje. Nie jesteś sam. Audyt narzędzi do badań prawnych przeprowadzony przez RegLab i HAI ze Stanfordu wykazał stopy halucynacji między 17% a 34% w produktach sprzedawanych jako “wolne od halucynacji” dzięki RAG. RAG rzeczywiście pomógł w stosunku do surowego GPT-4, ale przepaść między “zmniejszonym” a “wyeliminowanym” to dokładnie miejsce, gdzie żyją systemy produkcyjne.

Trzy problemy, które spiskują razem

Halucynacja w RAG rzadko pochodzi z jednego źródła. Zamiast tego trzy czynniki działają jednocześnie: odzyskiwanie zawodzi cicho, model został przeszkolony do odpowiadania niezależnie od kontekstu, i nic w pipeline’u nie mierzy przestrzeni między tymi dwoma faktami.

Pierwszy problem to niepowodzenie odzyskiwania. Anthropic zmierzył to na czystych, dobrze opracowanych korpusach podczas rozwijania techniki odzyskiwania kontekstowego: standardowa wyszukiwarka embedding zawodzi w znalezieniu potrzebnego fragmentu w wynikach w 20 na 100 przypadków. To jedno zapytanie na osiemnaście, na idealnie przygotowanych danych, bez niczego egzotycznego.

W systemach rzeczywistych problem jest gorszy. Badanie medyczne z listopada 2025 roku, w którym 18 ekspertów medycznych przeanalizowało 80 502 adnotacje w 800 wyjściach RAG, wykazało, że tylko 22% z 16 odzyskanych fragmentów było istotnych dla zapytania. Standardowy RAG nie tylko nie dorównał modelom bez odzyskiwania – obniżył faktualność o 6% i kompletność o 5%.

Dlaczego modele zawsze zgadują zamiast się wstrzymać

Drugi problem to trening i zachęty. OpenAI wyjaśnił to bezpośrednio w raporcie z września 2025 roku: standardowy trening i ocena nagradzają zgadywanie bardziej niż uznawanie niepewności. Benchmarki oceniają dokładność binarną, wstrzymanie się ocenia na zero, a modele uczą się, że pewna odpowiedź bije pustą – dokładnie jak studenci przed egzaminem wielokrotnego wyboru.

Własne porównanie OpenAI pokazuje konkret: jeden model rozumowania wstrzymywał się 1% czasu i był błędny 75% czasu, podczas gdy inaczej dostrojony wariant wstrzymywał się 52% czasu i zmniejszył częstotliwość błędów do 26%.

Benchmarki RAG pokazują, co ta zachęta robi wewnątrz pipeline’u:

Benchmark	Wynik	Znaczenie
RGB	45% odmowy negatywnej	Nawet najlepszy model, otrzymując tylko złą kontekst, odpowiada błędnie w ponad połowie przypadków
ClashEval	>60% porzucenia poprawnej odpowiedzi	Gdy odzyskana zawartość sprzeciwia się wiedzy modelu, wybiera błędny kontekst
FaithEval (Salesforce)	Większe modele nie są niezawodnie bardziej wierne	Rozmiar modelu nie gwarantuje wiarygodności
Vectara (podsumowania)	GPT-4o: 9,6% halucynacji, Claude Opus 4: 12%	Nawet na prostszym zadaniu (jeden dokument) halucynacja pozostaje

Team interpretowalności Anthropic prześledził mechanizm: odmowa jest domyślnym obwodem modelu, a funkcja “znana jednostka” tłumi tę odmowę, gdy model coś rozpoznaje. Halucynacja występuje, gdy funkcja zawodzi – model rozpoznaje kształt pytania, brakuje mu treści i konfabuluje płynnie w lukę.

Brak pomiaru między odzyskiwaniem a generacją

Trzeci problem to brak widoczności między etapami. Większość pipeline’ów produkcyjnych śledzi jakość odpowiedzi od końca do końca, co łączy dwa powyższe problemy w jedną niewyjaśnioną liczbę. Nie wiadomo, czy błąd pochodzi z odzyskiwania, generacji, czy obu.

Taksonomia siedmiu punktów niepowodzenia RAG (Barnett et al.) pokazuje, że trzy z siedmiu występują przed wygenerowaniem przez model jednego tokenu: brakująca zawartość, pominięte najwyżej oceniane dokumenty i awarie konsolidacji kontekstu. Podobieństwo osadzania jest proxy dla istotności, a nie gwarancją – ostatnie prace teoretyczne z Google DeepMind wskazują, że pojedyncze wektory osadzania mają trudne matematyczne ograniczenia dotyczące kombinacji dokumentów, które mogą reprezentować.

Więcej fragmentów pogarsza problem

Wiele zespołów sięga po objętość: odzyskaj więcej fragmentów, kup większe okno kontekstowe, włóż wszystko. Dowody idą w przeciwnym kierunku.

Badanie Chroma testowało 18 modeli (GPT-4.1, Claude 4, Gemini 2.5) i wykazało, że wydajność staje się coraz mniej wiarygodna wraz ze wzrostem długości wejścia. Cztery dokumenty rozpraszające znacznie obniżają dokładność. Wcześniejsze badanie “Lost in the Middle” znalazło słynną krzywą U: informacje pogrzebane w środku kontekstu są ignorowane nawet przez modele o długim kontekście.

Audyt medyczny wyżej pokazuje, jak te dynamiki wyglądają od końca do końca: system odzyskuje szesnaście fragmentów, z których dwanaście lub więcej jest nieistotnych, a następnie przekazuje stertę modelowi, który jest przeszkolony, aby nigdy nie mówić “nie wiem”.

Co to oznacza: precyzja bije recall

Więcej odzyskiwania bez większej precyzji po prostu wytwarza rozpraszacze. W ugruntowanej generacji precyzja bije recall – i to nie jest bliskie. Bardett i inni położyli operacyjną prawdę w jednej linii: “walidacja systemu RAG jest możliwa tylko podczas operacji”. Nie możesz zaakceptować pipeline’u RAG na etapie testowania, ponieważ jego tryby niepowodzenia są wspólną własnością twojego korpusu, twoich zapytań i twoich użytkowników – żaden z nich się nie zmienia.

Jak rzeczywiście mierzyć i naprawiać RAG

Standardowa dekompozycja, czasem nazywana triadą RAG, oddziela trzy wymiary:

Istotność kontekstu – czy odzyskiwanie znalazło właściwy materiał?
Ugruntowanie – czy odpowiedź trzyma się tego materiału?
Istotność odpowiedzi – czy odpowiada na pytanie?

Ramy takie jak RAGAS i TruLens pozwalają mierzyć każdy element osobno. To jedyna droga do zdiagnozowania, gdzie naprawdę leży problem: w odzyskiwaniu (potrzebujesz lepszego retriever’a lub chunking’u), w generacji (potrzebujesz innego treningu lub instrukcji), czy w ich interakcji.

Halucynacja w RAG nie zniknie, dopóki nie zaadresujemy trzech współpracujących przyczyn jednocześnie: precyzji odzyskiwania, treningowych zachęt modelu do wstrzymania się zamiast zgadywania, i pomiaru każdego etapu osobno. Wymiana modelu to zaledwie kosmetyka.