Corrective RAG i Self-RAG: samokorygujące wzorce wyszukiwania, które ograniczają halucynacje

Corrective RAG (CRAG) i Self-RAG to dwa samokorygujące wzorce wyszukiwania, które rozszerzają klasyczny schemat RAG o kontrolę jakości. CRAG ocenia trafność pobranych wyników i przy niskiej jakości wyszukiwania przełącza się na fallback w postaci wyszukiwania w sieci. Self-RAG pozwala modelowi językowemu samodzielnie decydować za pomocą tokenów refleksji, czy w ogóle pobierać dane, a następnie sprawdza, czy jego własna odpowiedź jest poparta źródłami. Oba celują w ten sam problem: halucynacje, które powstają mimo RAG.

• CRAG w jednym zdaniu: ewaluator wyszukiwania klasyfikuje wyniki jako poprawne, niejednoznaczne lub błędne i przy słabym kontekście uruchamia działanie korygujące, zamiast na ślepo generować dalej.
• Self-RAG w jednym zdaniu: model za pomocą wytrenowanych tokenów refleksji sam steruje tym, kiedy pobiera dane i czy jego odpowiedź zgadza się ze źródłami.
• Wspólny rdzeń: oba należą do rodziny wzorców Agentic RAG i traktują wyszukiwanie nie jako statyczne przetwarzanie wstępne, lecz jako weryfikowalny i sterowalny krok.

Dlaczego klasyczny RAG nie wystarcza

Standardowy RAG (Naive RAG według taksonomii Gao et al. 2023, arXiv:2312.10997) przebiega według stałego schematu: wektoryzacja, wyszukiwanie, wstawienie do promptu, generowanie. Problem polega na tym, że pipeline ślepo ufa wynikom top-k. Jeśli są semantycznie podobne, ale merytorycznie nieistotne, albo odpowiednich treści po prostu nie ma, model i tak generuje odpowiedź i opiera ją na nieprzydatnych źródłach.

Typowe są dwa rodzaje błędów. Przy context-unfaithful generation model cytuje źródła, ale merytorycznie od nich odbiega. Zwykle stosowane środki zaradcze to guardraile wierności, samokrytyka i prompty wymuszające cytowanie (citation forcing). Drugi rodzaj błędu pojawia się bez re-rankingu: wyniki top-k są wtedy często podobne, ale nieistotne. Właśnie tę lukę wypełniają CRAG i Self-RAG: sprawiają, że jakość wyszukiwania staje się jawnie weryfikowalna, i odpowiednio na nią reagują.

Ważne dla właściwej oceny: największa dźwignia w walce z halucynacjami nadal tkwi w samej jakości wyszukiwania. Anthropic Contextual Retrieval obniża odsetek błędów wyszukiwania top-20 o 49 procent (z 5,7 do 2,9 procent), a w połączeniu z re-rankingiem o 67 procent (do 1,9 procent); to benchmarki samego dostawcy, czyli Anthropic, według stanu z września 2024 r. Samokorekta jest drugą linią obrony, nie pierwszą.

Corrective RAG (CRAG): ocenić wyniki, potem skorygować

CRAG dodaje do pipeline'u ewaluator wyszukiwania. Po wyszukiwaniu, ale przed generowaniem, ewaluator ocenia trafność znalezionych dokumentów i przypisuje je do trzech klas pewności:

• Correct (wysoka pewność): wyniki są trafne. Zostają dopracowane (np. metodą decompose-recompose, aby usunąć szum) i przekazane do generatora.
• Incorrect (niska pewność): wyniki się nie nadają. Zamiast generować na podstawie słabego kontekstu, system uruchamia fallback, zwykle wyszukiwanie w sieci, aby pobrać aktualne treści zewnętrzne.
• Ambiguous (średnia pewność): sytuacja niepewna. Obie ścieżki zostają połączone: kontekst wewnętrzny plus wyniki wyszukiwania w sieci.

Kluczowym mechanizmem jest fallback w postaci wyszukiwania w sieci przy niskiej jakości wyszukiwania wewnętrznego. Dzięki temu CRAG kompensuje niekompletną lub nieaktualną bazę wiedzy, nie dopuszczając do halucynacji modelu. CRAG jest niezależny od modelu: można go wstawić jako dodatkowy węzeł przed dowolnym istniejącym pipeline'em RAG bez ponownego trenowania generującego LLM. CRAG wywodzi się z pracy Yan et al. 2024 (arXiv:2401.15884).

Self-RAG: model krytykuje sam siebie

Self-RAG (Asai et al., University of Washington, arXiv:2310.11511, październik 2023) przenosi kontrolę do modelu. Jest on trenowany tak, aby generował tzw. tokeny refleksji, za pomocą których steruje własnym procesem i go ocenia. W uproszczeniu zapadają cztery decyzje:

• Retrieve? Model decyduje dla każdego zapytania (lub każdego segmentu), czy wyszukiwanie jest w ogóle potrzebne. Pytania trywialne lub objęte wiedzą modelu nie wymagają pobierania danych.
• Is Relevant? Model ocenia, czy pobrany fragment jest istotny dla pytania.
• Is Supported? Po pobraniu model sprawdza, czy wygenerowane stwierdzenie jest poparte pobranym fragmentem: to wbudowana samokrytyka wierności.
• Is Useful? Model ocenia w skali od 1 do 5, na ile odpowiedź jest przydatna dla pytania.

Zaleta: model pobiera dane tylko wtedy, gdy sam uzna to za konieczne (co obniża koszty przy prostych pytaniach). Podczas generowania Self-RAG tworzy kilka segmentów-kandydatów, ocenia je za pomocą ważonego wyniku z tokenów krytyki (trafność, poparcie w źródłach, przydatność) i zachowuje najwyżej oceniony (Asai et al. 2023). Odmowa odpowiedzi lub eskalacja do człowieka nie są częścią metody, ale można je zbudować na tych tokenach. Cena: oryginalna implementacja Self-RAG wymaga modelu specjalnie wytrenowanego na tokenach refleksji. W praktyce wiele zespołów przybliża to zachowanie za pomocą promptowania i pętli samokrytyki ze standardowym modelem, co jest tańsze we wdrożeniu, ale mniej niezawodne niż model wytrenowany do tego celu.

Porównanie: CRAG vs Self-RAG vs standardowy RAG

Zgodnie z taksonomią ewolucji RAG (Naive, Advanced, Modular, Graph, Agentic) oba wzorce należy przypisać do etapu Agentic RAG. Singh et al. 2025 (arXiv:2501.09136) opisują Agentic RAG jako wzorce, w których wyszukiwanie pełni funkcję narzędzia, które agent wywołuje dynamicznie i iteracyjnie, z refleksją, planowaniem i korzystaniem z narzędzi. Self-RAG nie pojawia się w tym przeglądzie, ale pasuje jako wczesny przykład, bo to sam model decyduje o pobieraniu danych. Corrective RAG Singh et al. opisują jako odrębną architekturę (Agentic Corrective RAG). Uczciwie trzeba dodać, że w 2026 roku pojęcie Agentic RAG nie jest jeszcze jednoznacznie ugruntowane.

Konkretny przykład: baza wiedzy obsługi klienta z lukami

Załóżmy, że agencja prowadzi dla klienta B2B asystenta obsługi klienta opartego na RAG, który korzysta z wewnętrznej bazy wiedzy. Użytkownik pyta o funkcję, którą opisano dopiero wczoraj w notatce o wydaniu, jeszcze niezaindeksowanej.

• Standardowy RAG: pobiera trzy najbardziej podobne starsze dokumenty, nie znajduje odpowiedzi i halucynuje wiarygodnie brzmiącą, ale błędną konfigurację. Klasyczna halucynacja mimo RAG.
• CRAG: ewaluator wyszukiwania klasyfikuje wyniki jako incorrect (niska pewność co do trafności), uruchamia wyszukiwanie w sieci w publicznej dokumentacji produktu, znajduje notatkę o wydaniu i generuje poprawną odpowiedź ze źródłem.
• Self-RAG: model za pomocą tokenu Is Relevant klasyfikuje pobrane chunki jako nieistotne i za pomocą tokenu Is Supported rozpoznaje, że żadna odpowiedź nie jest przez nie poparta. Zbudowana na tej podstawie reguła aplikacji blokuje wtedy niepopartą odpowiedź i eskaluje sprawę do człowieka.

Rachunek dotyczący kompromisu: jeśli standardowe wywołanie RAG kosztuje na przykład jedno wywołanie LLM, CRAG dodaje co najmniej jedno wywołanie ewaluatora, a w przypadku fallbacku także przetwarzanie wyników wyszukiwania w sieci; pętla samokrytyki w stylu Self-RAG może, zależnie od projektu, oznaczać kolejne wywołania. Przy prostych pytaniach Self-RAG może nawet pominąć krok wyszukiwania. Ogólna zasada: samokorekta nie jest darmowym ulepszeniem, lecz świadomą wymianą dodatkowych opóźnień i kosztów na mniejsze ryzyko halucynacji. W agentowych systemach RAG dochodzi typowe ryzyko: niekontrolowane pętle narzędzi, które wielokrotnie zwiększają koszt zapytania.

Kiedy te wzorce mają sens

Samokorygujące wzorce opłacają się, gdy spełniony jest co najmniej jeden z tych warunków:

• Baza wiedzy jest niekompletna lub nieaktualna, a fallback do sieci lub źródeł zewnętrznych wypełnia rzeczywiste luki (CRAG).
• Błędne odpowiedzi są kosztowne: prawo, finanse, regulowana obsługa klienta, wszystko, co wiąże się z odpowiedzialnością prawną.
• Odmowa odpowiedzi w razie niepewności jest pożądana i akceptowana (Self-RAG dostarcza do tego tokeny krytyki).

Mają mniejszy sens, gdy baza wiedzy jest kompletna i porządnie zaindeksowana, liczy się przede wszystkim opóźnienie albo budżet na zapytanie jest napięty. W takich przypadkach tańsze środki z etapu Advanced RAG zwykle dają lepszy stosunek kosztów do efektów: wyszukiwanie hybrydowe (dense plus BM25, aby nie pomijać dokładnych kodów), Contextual Retrieval przeciw chunkom pozbawionym otaczającego kontekstu, re-ranking z cross-encoderem oraz guardrail wierności oparty na RAGAS w ramach pipeline'u CI. Według Anthropic, Contextual Retrieval (kontekstualizowane embeddingi plus BM25 na kontekstualizowanych chunkach) w połączeniu z re-rankingiem obniża odsetek błędów wyszukiwania nawet o 67 procent. Dopiero potem warto selektywnie dodać CRAG lub Self-RAG dla krytycznych ścieżek.

Dla agencji i decydentów B2B

Przekaz agencji do klientów jest jasny: samokorygujące wzorce wyszukiwania nie są standardową funkcją, którą włącza się z automatu, lecz celową inwestycją w zastosowania o wysokim ryzyku halucynacji. Pragmatyczna droga prowadzi przez mierzalną linię bazową (pomiar jakości wyszukiwania i wierności za pomocą RAGAS), a CRAG lub Self-RAG dodaje się dopiero tam, gdzie uzasadniają to liczby. W projektach B2B w Europie trzeba dodatkowo pamiętać, że fallback do wyszukiwania w sieci (CRAG) musi być uzgodniony z zasadami ochrony danych i zarządzania źródłami, ponieważ do łańcucha odpowiedzi nagle trafiają treści zewnętrzne. Blck Alpaca projektuje architektury RAG tak, aby samokorekta działała tam, gdzie robi różnicę, i nie zawyżała wszędzie kosztów i opóźnień.