Klient prawny pyta asystenta: „Jakie mamy ryzyka w przypadku wypowiedzenia umowy z podwykonawcą z Niemiec, biorąc pod uwagę nasz kontrakt ramowy, aktualny aneks i orzecznictwo z ostatniego roku?” Klasyczny RAG wykona jedno wyszukiwanie, zwróci kilka fragmentów i wygeneruje odpowiedź. Może trafić, może nie. Agentic RAG podchodzi do tego inaczej: rozgrywa to pytanie w kilku ruchach, sprawdzając po każdym, czy wie już wystarczająco.
Co zmienia się w architekturze
#W klasycznym podejściu RAG przepływ jest liniowy i niezmienny: jedno zapytanie wektorowe, k fragmentów do kontekstu, jedna generacja. To działa dobrze, gdy pytanie jest precyzyjne i odpowiedź leży w jednym miejscu bazy wiedzy.
Agentic RAG zastępuje ten stały przepływ pętlą decyzyjną. Agent dostaje pytanie, planuje wstępne zapytanie, ocenia zwrócone fragmenty, reformułuje zapytanie jeśli kontekst jest niepełny lub sprzeczny, pobiera kolejną porcję danych i powtarza aż do osiągnięcia progu pewności. Dopiero wtedy trafia do generacji.
Kluczowe różnice strukturalne, które wynikają z tej zmiany:
Wielokrotne zapytania. Agent może wysłać 3-6 oddzielnych zapytań w jednym cyklu odpowiedzi. Każde może używać innego sformułowania, innej strategii wyszukiwania (wektorowe, hybrydowe BM25 plus wektory, metadane) albo trafiać do innej kolekcji dokumentów.
Ocena wystarczalności. Po każdej iteracji model ocenia, czy zebrane fragmenty wystarczają do odpowiedzi na pytanie. To nie jest prosta reguła progowa: model sprawdza spójność, pokrycie i czy brakuje istotnego wątku.
Reformulacja zapytań. Jeśli pierwsze zapytanie przyniosło fragmenty o zbyt szerokim zakresie, agent zawęża. Jeśli kontekst wydaje się sprzeczny, agent szuka dokumentu rozstrzygającego. To reranking i selekcja realizowane aktywnie, nie pasywnie.
Granica pewności. Gdy agent po limicie iteracji nadal nie uzbierał wystarczającego kontekstu, nie spekuluje. Eskaluje do człowieka z informacją: „Pytanie jest poza pokryciem bazy wiedzy lub wymaga weryfikacji eksperta.”
Klasyczny RAG kontra agentic RAG
#| Wymiar | Klasyczny RAG | Agentic RAG |
|---|---|---|
| Liczba zapytań per odpowiedź | 1 | 2-6 (zależnie od złożoności) |
| Opóźnienie | 300-800 ms | 2-8 s |
| Koszt LLM | 1 wywołanie generacji | 2-6 wywołań planowania i generacji |
| Najlepszy dla | Proste, faktyczne pytania | Złożone, wielowątkowe, niejednoznaczne |
| Ryzyko halucynacji | Średnie (brak kontekstu = brak generacji) | Niższe (iteracja zmniejsza luki kontekstu) |
| Trudność ewaluacji | Umiarkowana | Wysoka (wiele ścieżek wyszukiwania) |
| Human-gate | Opcjonalny | Wymagany przy niskim zaufaniu |
Liczby opóźnienia i kosztu to widełki z naszych obserwacji na projektach z polskimi dokumentami prawnymi i finansowymi, nie gwarancje. Rzeczywiste wartości zależą od długości dokumentów, modelu i liczby iteracji.
Gdzie agentic RAG realnie pomaga
#Podejście agentowe ma sens, gdy pytanie ma co najmniej jedną z tych cech.
Wielowątkowość. Pytanie łączy informacje z różnych źródeł lub różnych momentów czasowych. Klasyczny RAG zwróci fragment z jednego miejsca; agent łączy kilka.
Niejednoznaczność. Pytanie jest niedookreślone i wymaga wyjaśnienia przez kontekst. Agent może zapytać o tło sprawy, pobrać ogólny fragment, a potem zagłębić się w szczegół.
Sprzeczne informacje w bazie. Gdy dokumenty w kolekcji zawierają dane z różnych dat lub niespójne procedury, klasyczny RAG może zwrócić starszą wersję. Agent iteruje i porównuje fragmenty, żeby wybrać aktualny.
Audytowalność ścieżki wyszukiwania. W zastosowaniach compliance (prawo, finanse, medycyna) wartością jest nie tylko odpowiedź, ale też ścieżka do niej: które dokumenty sprawdzono, w jakiej kolejności i dlaczego wystarczyły. Agentic RAG naturalnie produkuje ten log.
Dla prostych pytań słownikowych, jednoetapowych lookupów produktowych czy nawigacji po FAQ, klasyczny RAG jest tańszy i wystarczający. Nie ma sensu stawiać agentowej architektury tam, gdzie stały przepływ działa.
Koszt i trudność ewaluacji
#Agentic RAG nie jest darmowy. Trzy główne koszty warte uwagi przed wdrożeniem:
Więcej wywołań LLM. Każda iteracja wyszukiwania to co najmniej jedno dodatkowe wywołanie modelu do oceny wystarczalności i reformulacji zapytania. Przy modelach cloud to bezpośredni koszt tokenów. Kalkulator inference na naszej stronie pozwala oszacować, czy opłaca się self-hosting dla danego wolumenu.
Wyższe opóźnienie. Dwie sekundy to akceptowalny czas dla asystenta wewnętrznego w środowisku B2B. Dla czatu obsługi klienta z oczekiwaniem sub-sekundowym agentic RAG wymaga buforowania, cache semantycznego lub hybrydowego trybu: agent dla złożonych pytań, klasyczny RAG dla prostych.
Trudniejsza ewaluacja. W klasycznym RAG mamy jeden zestaw fragmentów kontekstu i jedną odpowiedź do oceny. W agentic RAG ścieżka wyszukiwania jest zmienna. Golden set musi pokrywać nie tylko odpowiedź końcową, ale też jakość reformulacji i decyzję o wystarczalności. My w Cashcrown budujemy dla tego trybu osobne golden sety z annotacją ścieżki, co jest wolniejsze, ale konieczne dla rzetelnego pomiaru. Szczegóły metodyki opisuje artykuł o ewaluacji systemu RAG.
Guardrails i human-gate: gdzie agent musi się zatrzymać
#Pętla agentowa bez granic to ryzyko operacyjne. Trzy guardrails, które uważamy za obowiązkowe.
Twardy limit iteracji. Agent nie może wyszukiwać w nieskończoność. Ustalamy górną granicę (zwykle 5-7 iteracji) i obsługujemy przekroczenie jako eskalację, nie jako awarię. Log zawiera pytanie, wszystkie iteracje i powód eskalacji.
Guardrails anty-halucynacyjne. Przed generacją odpowiedzi sprawdzamy, czy każde twierdzenie, które model zamierza zawrzeć, ma pokrycie w zebranych fragmentach. Twierdzenie bez pokrycia jest usuwane lub flagowane. To samo zabezpieczenie, które opisuje artykuł o agentach wielokrokowych, tu stosujemy do warstwy wyszukiwania.
Human-gate przy niskim zaufaniu. Gdy ocena wystarczalności po wszystkich iteracjach jest poniżej progu akceptacji, agent nie generuje spekulatywnej odpowiedzi. Zamiast tego zwraca: „Nie mam wystarczających dokumentów, żeby odpowiedzieć pewnie. Przekazuję do eksperta.” Ten handoff musi zawierać kontekst: które pytania zadano, co znaleziono, czego brakuje.
Obserwowalność pętli jest konieczna, żeby te guardrails działały. Logujemy każdą iterację: zapytanie wektorowe, zwrócone fragmenty, ocenę wystarczalności, decyzję o kontynuacji. Bez tego logu nie ma jak debugować przypadków eskalacji ani kalibrować progu pewności.
Wdrożenie: od pilota do produkcji
#Typowy pilot agentic RAG dla jednego procesu w firmie B2B zajmuje 4-6 tygodni. Pierwsze dwa tygodnie to praca z danymi i projektowanie pętli (strategia chunkingu, threshold wystarczalności, limit iteracji, schemat logu). Trzeci i czwarty tydzień to shadow mode: agent przetwarza pytania równolegle z odpowiedziami zespołu, rozbieżności trafiają do analizy.
Przed uruchomieniem produkcyjnym budujemy golden set specyficzny dla agentic RAG: dla każdego pytania annotujemy oczekiwaną ścieżkę wyszukiwania i decyzję o wystarczalności, nie tylko odpowiedź końcową. To wolniejsze niż złoty zestaw dla klasycznego RAG, ale jedyna metoda, która pozwala oceniać jakość planowania, a nie tylko wynik. Jak ten golden set budować w kontekście systemów multi-agentowych opisujemy osobno.
Koszt pilota zależy od złożoności bazy wiedzy i wymagań annotacji. Ocenę ROI wdrożenia agentowego daje kalkulator inference, który uwzględnia koszt dodatkowych iteracji LLM.
FAQ
#Czym różni się agentic RAG od klasycznego RAG?
#Klasyczny RAG wykonuje jeden stały cykl: jedno zapytanie wektorowe, k fragmentów do kontekstu, jedna generacja. Agentic RAG zastępuje ten przepływ pętlą: agent planuje zapytanie, ocenia czy wyniki wystarczają, reformułuje i iteruje do progu pewności lub limitu kroków. Różnica jest architektoniczna, nie tylko w liczbie zapytań: klasyczny RAG nie może sam decydować, czy kontekst jest wystarczający.
Kiedy agentic RAG nie ma sensu?
#Przy prostych, jednoetapowych pytaniach faktycznych, lookupach produktowych, nawigacji po FAQ i wszędzie tam, gdzie użytkownik oczekuje sub-sekundowej odpowiedzi. Agentic RAG zwraca się przy złożonych, wielowątkowych pytaniach, gdzie brakujący kontekst prowadzi do błędnej odpowiedzi. Dla większości asystentów wewnętrznych B2B rozsądne podejście to hybrydowy tryb: klasyczny RAG dla prostych pytań, agentic dla złożonych, z routerem decydującym o ścieżce.
Jak oceniać wystarczalność kontekstu w pętli agenta?
#Nie ma jednej uniwersalnej metody. Praktycznie sprawdzają się dwa podejścia: prompt oceniający model proszony o wskazanie, które wątki pytania mają pokrycie w zebranych fragmentach, oraz progowy wynik spójności oparty na cosinus similarity między pytaniem a zagregowanymi fragmentami. My w Cashcrown kalibrujemy ten próg na golden secie per projekt, bo optymalny poziom różni się między bazami wiedzy prawnymi, technicznymi i handlowymi.
Czy agentic RAG rozwiązuje problem halucynacji?
#Częściowo. Iteracyjne wyszukiwanie zmniejsza ryzyko, że model odpowiada bez kontekstu, bo agent zbiera więcej i lepiej dopasowanych fragmentów. Ale nie eliminuje halucynacji całkowicie: model może nadal wyjść poza zebrany kontekst przy generacji odpowiedzi. Guardrail sprawdzający pokrycie każdego twierdzenia w kontekście jest nadal konieczny, tak samo jak opcja eskalacji do człowieka przy niskim zaufaniu. Architekturę tej warstwy opisuje artykuł o firmowym GPT na bazie wiedzy.
Jak logować ścieżkę wyszukiwania do celów audytu?
#Każda iteracja generuje rekord: oryginalne pytanie, reformułowane zapytanie wektorowe, zwrócone fragmenty (z identyfikatorem dokumentu i pozycją), ocenę wystarczalności i decyzję o kontynuacji lub zakończeniu. Ten log trafia do osobnego magazynu z retencją zgodną z RODO. W zastosowaniach objętych AI Act (finanse, prawo, HR) log jest elementem obowiązkowego śladu audytowego, nie opcjonalnym dodatkiem do debugowania.