RAG, Agent AI, Agentic RAG — co to jest, dlaczego powstało i kiedy każde z nich ma sens

Zacznijmy od problemu, nie od definicji.

Masz firmę. Masz chatbota. Ktoś pyta: "Jaka jest wasza polityka zwrotów?" Model odpowiada pewnie i szczegółowo. I jest w połowie w błędzie — bo polityka zmieniła się trzy miesiące temu, a model zna tylko wersję z danych treningowych.

Uczysz model na nowych danych? Kosztowne i wolne. A polityka znowu zmieni się za miesiąc. I jeszcze raz. I jeszcze raz.

To jest moment w którym ludzie wymyślili RAG. I to jest dobry punkt wyjścia do zrozumienia całej trójki.

RAG: model który czyta przed odpowiedzią

RAG (Retrieval-Augmented Generation) rozwiązuje jeden konkretny problem: model wie tylko tyle ile zapamiętał podczas treningu. Twoje dokumenty, aktualne dane, wiedza wewnętrzna firmy — tego nie ma w żadnym modelu.

Rozwiązanie jest eleganckie w swojej prostocie: zanim model odpowie, niech najpierw znajdzie relevantne fragmenty w Twoich danych. Dodaj te fragmenty do pytania. Teraz model odpowiada mając przed sobą zarówno swoje wyszkolone rozumowanie jak i aktualne fakty z Twoich źródeł.

Jak to działa w praktyce:

Twoje dokumenty (polityki, FAQ, instrukcje, artykuły) są wcześniej przetworzone — każdy fragment zamieniony na wektor liczbowy i zapisany w bazie wektorowej. Gdy przychodzi pytanie od użytkownika, system robi to samo z pytaniem: zamienia je na wektor, szuka najbardziej podobnych fragmentów w bazie, dołącza je do kontekstu modelu. Model czyta pytanie plus pobrane fragmenty i odpowiada.

Polityka zwrotów zmienia się? Aktualizujesz dokument w bazie. Chatbot od razu wie o zmianie. Bez retrenowania, bez deploymentu nowego modelu.

Dlaczego RAG działa tak dobrze dla wielu zastosowań:

RAG radykalnie redukuje halucynacje. Zamiast model "wymyślał" fakty których nie zna, dostaje konkretne fragmenty do cytowania. Wyniki są bardziej przewidywalne i weryfikowalne. Można sprawdzić źródło każdej odpowiedzi.

To jest też pierwsza rzecz którą firmy wdrażają przy enterprise AI — baza wiedzy firmowej zasilana RAG-iem. Działa. Ma sens. Jest relatywnie prosta do zbudowania.

 

Dlaczego RAG nie zawsze wystarcza

Zostańmy przy tej samej firmie. Teraz ktoś pyta coś innego: "Przeanalizuj sprzedaż z ostatniego kwartału, porównaj z trendami rynkowymi, wskaż które segmenty tracą i zaproponuj kampanie na przyszły miesiąc."

RAG pobierze jakieś dokumenty i model coś odpowie. Ale to zadanie nie jest jednym pytaniem. To sekwencja:

1. Pobierz dane sprzedażowe z ostatniego kwartału
2. Przeanalizuj wyniki per segment
3. Wyszukaj aktualne trendy rynkowe (to jest zewnętrzne źródło, nie Twoje dokumenty)
4. Porównaj swoje wyniki z trendami
5. Zidentyfikuj underperformujące segmenty
6. Sprawdź co działało w poprzednich kampaniach
7. Zaproponuj konkretne działania

RAG wykona punkt 1 i może punkt 6. Reszta — zwłaszcza punkt 3 (zewnętrzna informacja), punkt 5 (analiza wymagająca iteracji) i punkt 7 (decyzja oparta na poprzednich krokach) — wymaga czegoś więcej.

RAG jest pipeline'em który działa raz. Jedno zapytanie, jedno pobranie, jedna odpowiedź. Gdy zadanie wymaga wielu kroków, każdy zależny od poprzedniego — RAG nie ma mechanizmu żeby to zorganizować.

Drugi problem: RAG tylko czyta, nie działa.

Użytkownik pyta asystenta: "Zarezerwuj mi salę konferencyjną na jutro na 14:00." RAG pobierze regulamin rezerwacji sal. Model powie co trzeba zrobić. Ale sam nic nie zarezerwuje.

To nie jest wada RAG — to jest po prostu granica jego projektu. RAG augmentuje kontekst modelu. Nie daje mu rąk do działania.

Agent AI: model który działa, nie tylko odpowiada

Agent AI to odpowiedź na oba problemy. Pętla zamiast pipeline'u. Akcje zamiast tylko odpowiedzi.

Gdy agent dostaje cel — rozkłada go na kroki, wykonuje każdy krok z pomocą narzędzi, obserwuje wynik, planuje następny krok. Jeśli coś nie wyjdzie jak powinno, może spróbować inaczej. To jest agent loop — percepcja, planowanie, działanie, ocena, powtórz.

Narzędzia to klucz. Przez MCP agent może połączyć się z bazą danych i zapytać SQL-em, wywołać API CRM, wyszukać informację w internecie, wykonać skrypt Pythona, wysłać e-mail. Nie imituje kliknięć człowieka — wywołuje API przez standardowy protokół.

Wracamy do analizy sprzedaży. Agent dostaje to samo zadanie:

1. Wywołuje narzędzie query_database z pytaniem SQL o sprzedaż ostatniego kwartału. Dostaje wyniki.
2. Analizuje wyniki. Widzi że segment B wypada najgorzej.
3. Wywołuje narzędzie web_search z zapytaniem o trendy w segmencie B. Dostaje artykuły.
4. Porównuje. Formułuje wnioski.
5. Wywołuje query_past_campaigns żeby sprawdzić co poprzednio działało w B.
6. Syntetyzuje rekomendacje.

Każdy krok jest możliwy. Agent realizuje zadanie które RAG mógł tylko częściowo obsłużyć.

Dlaczego jeden agent też ma swoje limity

Wróćmy do analizy sprzedaży. Agent ją wykona. Ale sekwencyjnie: krok 1, wynik, krok 2, wynik, krok 3... Każde wywołanie narzędzia czeka na poprzednie. Każdy etap analizy blokuje następny.

Przy złożonych zadaniach pojawia się też inny problem: agent generalistyczny jest jak pracownik który musi być jednocześnie analitykiem danych, badaczem rynku i strategiem marketingowym. Radzi sobie, ale nie tak dobrze jak każdy z tych specjalistów osobno.

Wyobraź sobie inny scenariusz: chcesz wiedzieć co robi Twoja konkurencja. Skąd taka wiedza pochodzi?

• Wewnętrzne CRM — notatki ze spotkań, powody przegranych dealsów
• Zewnętrzne newsy i raporty — aktualności o firmie
• Oferty pracy konkurenta — wskaźnik ich strategii (kogo rekrutują mówi wiele)
• Rejestr spółek — zmiany finansowe, nowe udziały

Jeden agent musiałby odpytać każde z tych źródeł sekwencyjnie. Cztery zapytania, cztery kroki, a wszystko czeka w kolejce.

Agentic RAG: zespół zamiast jednego agenta

Agentic RAG to kolejna ewolucja. Zamiast jednego agenta który robi wszystko po kolei — orkiestrator który deleguje do wyspecjalizowanych subagentów, a te działają równolegle.

Ta sama analiza konkurencji w systemie Agentic RAG:

Orkiestrator dostaje zadanie i natychmiast widzi że ma cztery niezależne od siebie ścieżki. Deleguje równocześnie:

• Subagent 1 → pobiera dane z CRM przez MCP serwer wewnętrzny
• Subagent 2 → wyszukuje aktualne newsy przez MCP serwer wyszukiwarki
• Subagent 3 → sprawdza oferty pracy przez MCP serwer cloud

Wszystkie trzy działają jednocześnie. Orkiestrator czeka na wyniki, zbiera je i syntezuje raport.

To co Agent AI wykonałby w 12 seryjnych krokach, Agentic RAG wykonuje w 4 krokach — z których trzy toczą się równolegle.

Druga wartość: specjalizacja. Subagent który zajmuje się tylko danymi z CRM może być dokładnie dostrojony do tego formatu danych, specyficznych zapytań, typowych anomalii. Jest lepszy od generalisty w swojej wąskiej dziedzinie.

MCP jest tutaj spoiwem — standardowy protokół przez który każdy subagent komunikuje się ze swoimi źródłami danych. Zamiast każdy agent implementował własną integrację z każdym systemem, każde źródło danych wystawia serwer MCP raz i wszystkie agenty go używają.

Kiedy co stosować

Trzy podejścia, trzy różne sytuacje. Nie ma "najlepszego" — jest właściwe dla konkretnego problemu.

RAG gdy masz bazę wiedzy i potrzebujesz modelu który odpowiada na pytania z tej wiedzy. FAQ, dokumentacja produktu, polityki firmy, internal knowledge base. Stosunkowo prosta implementacja, dobra jakość, niski koszt. Nie nadaje się gdy zadanie wymaga iteracji lub akcji.

Agent AI gdy zadanie wymaga działania — wywołania systemu, wykonania kodu, przeprowadzenia wieloetapowej analizy gdzie każdy krok zależy od poprzedniego. Automatyzacja procesów, asystenci operacyjni, systemy które "coś robią" a nie tylko "coś mówią."

Agentic RAG gdy:

• zadanie jest złożone i wymaga wielu niezależnych źródeł danych jednocześnie
• chcesz skrócić czas przez równoległe przetwarzanie
• różne części zadania wymagają wyspecjalizowanego podejścia
• skala jest duża i jeden agent byłby wąskim gardłem

To też jest bardziej złożone w implementacji — wymaga przemyślanej architektura, dobrego orkiestratora, mechanizmów obsługi błędów między agentami.

Praktyczna heurystyka: zacznij od RAG. Jeśli użytkownicy potrzebują żeby system coś robił, a nie tylko odpowiadał — przejdź do agenta. Jeśli agent staje się zbyt wolny lub zbyt generalny dla złożonych zadań — czas na architekturę wieloagentową.

---

Pojęcia ze słownika: RAG · Agent AI · MCP · Agent loop · Chain-of-thought · Enterprise RAG · Multi-agent system · Agent orchestration