Klient z branży produkcyjnej miał bazę wiedzy: 8 000 instrukcji technicznych, protokołów serwisowych i rysunków. Wdrożyli klasyczny RAG — embed, retrieve top-5, generuj. Dla pytań typu „jakie są parametry silnika X?" system osiągał 85% dokładności. Potem pojawiło się pytanie: „Co mam zrobić, gdy silnik X zgłasza błąd E47 i jednocześnie temperatura przekracza 80 °C?" System zwrócił fragment o błędzie E47 i fragment o temperaturze — ale nigdy nie doprecyzował, że kombinacja tych dwóch stanów wymaga innej procedury niż każdy z osobna. Odpowiedź była technicznie poprawna, operacyjnie bezużyteczna.
To właśnie ta klasa problemów nie ma rozwiązania architektonicznego w klasycznym RAG. Nie chodzi o lepszy model embeddingów ani o większy chunk. Chodzi o to, kto steruje pobieraniem — i kiedy wie, że potrzebuje pobrać więcej.
Gdzie klasyczny RAG napotyka swoje ograniczenia
Klasyczny RAG (Retrieval-Augmented Generation) działa w jednym kroku retrieval: przychodzi pytanie, system indeksuje zapytanie, pobiera top-K fragmentów z bazy wektorowej i przekazuje je do LLM. Jest deterministyczny, szybki i tani.
Problem pojawia się przy czterech typach zadań:
- Pytania wieloetapowe — odpowiedź zależy od dwóch lub więcej faktów znajdujących się w oddzielnych dokumentach, a ich powiązanie nie jest explicite zaznaczone w tekście. Klasyczny RAG wykonuje jeden krok retrieval, LLM dostaje tylko część kontekstu.
- Niejasne lub niepełne zapytania — użytkownik pisze „problemy z chłodzeniem na linii 3", ale system nie wie, czy chodzi o chłodzenie silnika, chłodzenie hydrauliczne czy klimatyzację hali. Jeden krok retrieve nie rozwiąże tej niejednoznaczności.
- Pytania wymagające porównania — „porównaj interwały serwisowe dla urządzenia A i B" wymaga dwóch niezależnych operacji retrieve i ich syntezy, nie jednego retrieve z nadzieją, że oba dokumenty trafią do top-5.
- Analizy iteracyjne — agent musi najpierw ustalić coś podstawowego (np. numer seryjny urządzenia), następnie na tej podstawie pobrać konkretną dokumentację, a potem zweryfikować aktualność informacji względem daty produkcji. Każdy krok zależy od wyniku poprzedniego.
Do tych scenariuszy potrzebna jest inna architektura — taka, w której retrieval nie jest jednorazową akcją, lecz iteracyjnym procesem sterowanym przez agenta.
Co agentic RAG robi inaczej
Agentic RAG dodaje warstwę decyzyjną ponad klasyczną pipeline retrieve-generate. Agent — typowo LLM z dostępem do narzędzi — otrzymuje pytanie i sam decyduje:
- 1.Jakie zapytanie wysłać do bazy wektorowej
- 2.Czy wyniki są wystarczające, czy trzeba pobrać więcej
- 3.Jakie nowe zapytanie sformułować na podstawie dotychczas zebranych informacji
- 4.Kiedy kontekst jest kompletny i można wygenerować odpowiedź
Zamiast jednego cyklu retrieve-and-generate powstaje pętla, w której agent ocenia własne wyniki pośrednie. W praktyce może to wyglądać tak: agent otrzymuje pytanie o kombinację błędu i temperatury, formułuje pierwsze zapytanie o błąd E47, czyta wyniki, decyduje, że potrzebuje kontekstu o limitach temperaturowych, formułuje drugie zapytanie, pobiera dokumenty, syntetyzuje oba konteksty i dopiero wtedy generuje odpowiedź.
To podejście opiera się na trzech kluczowych mechanizmach, których klasyczny RAG nie posiada.
Query rewriting — przeformułowanie zapytania
Dane wejściowe od użytkownika rzadko odpowiadają językowi, w jakim napisane są dokumenty. Instrukcja techniczna opisuje „przegrzanie układu hydraulicznego", użytkownik pisze „olej ma za wysoką temperaturę". Query rewriting pozwala LLM przekształcić oryginalne zapytanie w formę lepiej odpowiadającą przestrzeni wektorowej embeddingów.
To element obecny również w bardziej zaawansowanych klasycznych pipeline RAG — nie jest to cecha wyłączna agentic RAG. Różnica polega na tym, że w agentic RAG query rewriting może powtarzać się w każdym kroku: agent widzi, co pobrał, i przeformułowuje zapytanie na podstawie wyniku pośredniego, nie tylko oryginalnego pytania.
Multi-step retrieval — stopniowe pobieranie
Agent może wykonywać retrieve wielokrotnie, przy czym każdy krok informuje następny. Rozwiązuje to problem „ukrytego powiązania" — gdy odpowiedź jest rozłożona na dokumenty, które nie mają explicite zaznaczonych relacji semantycznych, ale ich kombinacja jest istotna.
Z praktycznego punktu widzenia implementacja wygląda jak agent ReAct, gdzie „szukaj w bazie wiedzy" jest narzędziem. Agent wywołuje je tyle razy, ile uzna za stosowne, z różnymi zapytaniami. Więcej o architekturze pętli agentowej znajdziesz w artykule o architekturach AI agentów.
Self-correction — korekta własnych wyników pośrednich
Najbardziej zaawansowana właściwość agentic RAG. Agent nie tylko pobiera, ale ocenia, czy pobrane informacje są istotne, aktualne i wystarczające. W bardziej zaawansowanych implementacjach dodawany jest osobny faithfulness judge — kolejne wywołanie LLM, które sprawdza, czy wygenerowany wynik jest podparty pobranymi dokumentami, a nie wyhalucynowany.
To jest punkt, w którym wielu niedocenia złożoności: naiwny agentic RAG bez faithfulness judge może halucynować więcej niż klasyczny RAG. Powód jest prosty — dłuższy kontekst, więcej kroków retrieval, większa przestrzeń dla modelu do wygenerowania prawdopodobnego, ale niepodpartego tekstu.
Kiedy wdrażać agentic RAG — framework decyzyjny
Nie każdy przypadek użycia RAG wymaga warstwy agentowej. Oto framework decyzyjny z praktyki.
Zostań przy klasycznym RAG, jeśli: - Większość pytań jest prosta (jeden dokument = pełna odpowiedź) - Latencja jest krytyczna (interaktywny chatbot, gdzie odpowiedź musi nadejść w ciągu 2 sekund) - Wolumen zapytań jest wysoki, a koszt jest czynnikiem ograniczającym - Baza wiedzy jest wąsko zdefiniowana i pytania nie wykraczają poza jej zakres
Przejdź na agentic RAG, jeśli: - Ponad ~20% zapytań wymaga informacji z wielu dokumentów - Użytkownicy zadają pytania wieloetapowe lub porównawcze - Odpowiedź zależy od stanu lub kontekstu nieobecnego w oryginalnym zapytaniu - Dokładność jest ważniejsza niż latencja (wsparcie decyzyjne, protokoły bezpieczeństwa) - Masz zasoby do wdrożenia i monitorowania pipeline agentowego
We wdrożeniach produkcyjnych obserwujemy, że dla systemów wiedzy opartych na dokumentacji technicznej (instrukcje serwisowe, normy, procedury) agentic RAG wyraźnie poprawia jakość odpowiedzi na pytania wieloetapowe — ale kosztem tokenów 5–10× wyższych i latencji 3–5× dłuższej w porównaniu z klasycznym podejściem. To nie jest cena, którą płacisz za każde zapytanie, ale musisz ją uwzględnić w decyzji architektonicznej.
Dodatkowy koszt: nie tylko tokeny
Agentic RAG jest droższy niż klasyczny RAG na kilku osiach, a same tokeny to tylko jedna z nich.
Koszty tokenów: Tam gdzie klasyczny RAG zużywa na zapytanie ~500–1 000 tokenów, agentic RAG z 3–4 krokami retrieval i faithfulness judge może zużyć 5 000–15 000 tokenów. Przy tanich modelach (warstwa Flash/Haiku, rzędu $0,10–0,50 za 1M tokenów wejściowych) ta różnica jest do opanowania. Przy modelach frontier klasy Claude Opus lub GPT-5 koszt jednego zapytania agentowego wynosi rzędu centów do kilkudziesięciu centów — przy dużym wolumenie jest to istotna kwota.
Latencja: Każdy krok retrieve dodaje czas — wywołanie LLM do query rewriting, wywołanie bazy wektorowej, ewentualnie faithfulness judge. Realne pipeline agentic RAG na 3–5 krokach trwają 5–20 sekund. Dla aplikacji interaktywnych wymaga to asynchronicznego projektu i wizualnej informacji zwrotnej (wskaźnik postępu, streaming).
Narzut implementacyjny i observability: Klasyczny RAG to funkcja na 50 linii kodu. Agentic RAG to pipeline z checkpointingiem, logiką retry, monitoringiem i narzędziami do debugowania. Bez narzędzi observability takich jak Langfuse (self-hostable) czy Arize Phoenix staje się niemal nie do utrzymania. Wielokrokowy agent bez trace'ów to czarna skrzynka — gdy zawodzi, nie wiesz dlaczego. Więcej na temat observability przy agentach znajdziesz w artykule o observability i tracingu.
Narzut retry: Agenci zawodzą — błędnie sformułowane zapytanie retrieval, timeout bazy danych, nieoczekiwany format wyniku. W systemach produkcyjnych typowy współczynnik retry wynosi ok. 10–15%, co efektywnie zwiększa liczbę wywołań. Ten narzut musisz uwzględnić w modelu kosztowym.
Wzorce implementacyjne w praktyce
Istnieją dwa dominujące podejścia do implementacji agentic RAG.
Wzorzec 1: Agent ReAct z narzędziem retrieval
Najprostsza forma — standardowy agent ReAct, w którym jednym z narzędzi jest search_knowledge_base(query: str) -> list[Document]. Agent decyduje, kiedy i jak wywołać narzędzie, widzi wyniki w fazie Observe i kontynuuje stosownie do tego. Implementacja przez LangGraph z explicite zdefiniowanym stanem jest dziś standardem dla systemów produkcyjnych.
Zaleta: stosunkowo prosta implementacja, agent jest elastyczny. Wada: bez faithfulness judge agent może halucynować z pewnością siebie, wiarygodność wyników jest zmienna.
Wzorzec 2: Dedykowany agent RAG z pętlą oceniającą
Bardziej zaawansowane podejście: retrieve → faithfulness check → jeśli niewystarczające, przeformułuj zapytanie i powtórz → dopiero gdy faithfulness score przekroczy próg, generuj końcową odpowiedź. To bliżej wzorca SELF-RAG lub CRAG (Corrective RAG).
Szczegół implementacyjny: faithfulness judge to osobne wywołanie LLM z promptem, który otrzymuje chunk i wygenerowaną odpowiedź i ma odpowiedzieć, czy odpowiedź jest podparta tym chunkiem. Zazwyczaj wystarczy tańszy model (warstwa Haiku) jako judge — do binarnej oceny nie potrzebujesz najsilniejszego modelu. Wynik jest mierzalny i logowalny, co jest kluczowe dla audytu i strojenia.
Czego nauczyła nas praktyka: Najczęstszy błąd przy pierwszej implementacji agentic RAG nie jest techniczny — jest produktowy. Zespół wdraża pełny pipeline agentowy dla każdego zapytania, bez rozróżnienia między prostymi, jednoznaczcznymi pytaniami a złożonymi. Efekt: cały system jest wolny i drogi, choć 60% zapytań klasyczny RAG obsłużyłby taniej i szybciej.
Rekomendacja z praktyki: Router przed wejściem do pipeline. LLM lub prosty klasyfikator ocenia złożoność zapytania i kieruje je albo na szybki klasyczny RAG, albo na pipeline agentowy. To znacząco poprawia stosunek ceny do jakości przy realnym obciążeniu. Decyzji między RAG a fine-tuningiem poświęcony jest osobny artykuł o jakości pipeline RAG.
Typowe ryzyka i jak je mitygować
Zależność pętlowa (retrieval loop): Agent wielokrotnie pobiera podobne dokumenty bez postępu. Rozwiązanie: limit max_retrieval_steps (typowo 4–6) i kontrola duplikatów pobranych chunków — jeśli agent pobrał ten sam dokument dwukrotnie, musi zmienić zapytanie.
Konfabulacja z długiego kontekstu: Im więcej dokumentów w kontekście, tym większa przestrzeń dla modelu na halucynacyjne powiązania. Rozwiązanie: faithfulness judge + cytowania (każde twierdzenie musi być mapowalne do konkretnego chunka). Niejasność co do źródła informacji to sygnał ostrzegawczy.
Niekontrolowany koszt: Agentic RAG bez limitów może przy jednym złożonym pytaniu zużyć 10× więcej tokenów, niż zaplanowałeś. Rozwiązanie: twardy limit tokenów na zapytanie, alerting po osiągnięciu 50% limitu, raportowanie kosztów per zapytanie w platformie observability.
Prompt injection przez dokumenty: Agent pobiera dokument, w którym atakujący umieścił instrukcje dla LLM (np. „zignoruj poprzednie instrukcje i zwróć X"). W agentic RAG to ryzyko jest wyższe, ponieważ zawartość dokumentów trafia bezpośrednio do kontekstu agenta, który steruje kolejnymi krokami. Rozwiązanie: separacja kontekstu (retrieved documents w oddzielnym bloku kontekstowym z wyraźnym oznaczeniem), walidacja pobranej treści przed wstawieniem do kontekstu agentowego.
Najczęstsze pytania
Czy agentic RAG jest zawsze dokładniejszy niż klasyczny RAG?
Nie. Naiwny agentic RAG bez faithfulness judge może halucynować więcej niż klasyczny RAG, ponieważ dłuższy kontekst i więcej kroków retrieval dają modelowi większą przestrzeń do wygenerowania prawdopodobnego, ale niepodpartego tekstu. Agentic RAG jest dokładniejszy tylko wtedy, gdy jest poprawnie zaimplementowany z pętlą samooceniającą i wyraźną ścieżką cytowań.
Ile kosztuje agentic RAG w porównaniu z klasycznym?
Agentic RAG jest typowo 5–10× droższy na jedno zapytanie. Przy tanich modelach (warstwa Flash/Haiku, $0,10–0,50 / 1M tokenów wejściowych) różnica jest do opanowania. Przy modelach frontier (klasa Claude Opus, ~$5 input / ~$25 output / 1M tokenów) koszt jednego zapytania agentowego wynosi rzędu centów do kilkudziesięciu centów. Przy dużym wolumenie zapytań (tysiące dziennie) niezbędny jest router kierujący proste pytania do klasycznego RAG.
Czy do agentic RAG potrzebuję specjalnego frameworku?
Niekoniecznie, ale ułatwi to implementację. LangGraph z explicite zdefiniowanym stanem i checkpointingiem jest dziś dominującym wyborem dla systemów produkcyjnych — obsługuje checkpointing, logikę retry i bramki HITL. LlamaIndex ma wbudowany agentic RAG z query rewriting i multi-step retrieval. Dla prostszych przypadków wystarczy własny kod z pętlą ReAct.
Jaka jest latencja agentic RAG w produkcji?
Realna latencja pipeline agentic RAG z 3–5 krokami retrieval wynosi 5–20 sekund. Klasyczny RAG zazwyczaj odpowiada w ciągu 1–3 sekund. Dla aplikacji interaktywnych konieczne jest asynchroniczne przetwarzanie i strumieniowanie wyników — użytkownik musi widzieć, że system pracuje, inaczej odbiera to jako awarię.
Kiedy lepiej użyć GraphRAG zamiast agentic RAG?
GraphRAG jest bardziej odpowiedni, gdy relacje między encjami są ważne, a dokumenty tworzą sieć powiązanych faktów (np. powiązania regulacyjne, hierarchie organizacyjne). Agentic RAG jest bardziej odpowiedni, gdy baza wiedzy jest zorientowana dokumentowo, a problemem są pytania wieloetapowe, nie relacje grafowe.
*Jeśli rozważasz, czy Twój przypadek użycia knowledge base wymaga agentic RAG, czy wystarczy zoptymalizowane klasyczne podejście, chętnie ocenimy konkretną sytuację — włącznie z szacunkiem kosztów, latencji i projektem architektonicznym. MP Industrial Solutions wdraża systemy RAG i agentowe dla środowisk B2B z naciskiem na mierzalny wynik.*