Agentic RAG: Keď AI sama rozhoduje, čo hľadá a ako
Klasický RAG dáva jazykovému modelu dokumenty na prečítanie. Agentic RAG mu dáva schopnosť rozhodnúť sa, čo a kde hľadať — opakovane, adaptívne, s vlastným úsudkom.
1. Čo je Agentic RAG a prečo nestačí klasický RAG
RAG (Retrieval-Augmented Generation) je dnes štandardný spôsob, ako zapojiť externé znalosti do jazykových modelov. Základný princíp je jednoduchý: pred odpoveďou sa z databázy vytiahnu relevantné dokumenty a vložia do kontextu modelu.
Problém? Klasický RAG je jednopriechodový. Jeden dotaz → jedno vyhľadávanie → jedna odpoveď. To stačí na jednoduché otázky, ale zlyháva pri komplexnejších:
- Viacstupňové otázky: „Porovnaj finančné výsledky firiem A a B za Q1 2026 a vysvetli rozdiel." Model potrebuje dve nezávislé vyhľadávania a potom logické prepojenie.
- Neistota v dotaze: Prvé vyhľadávanie vráti irelevantné výsledky a systém to nevie opraviť — odpovie aj tak.
- Dynamický kontext: Odpoveď z dokumentu A generuje nový podotaz, ktorý treba zodpovedať z inej databázy.
Agentic RAG rieši tieto problémy tak, že model dostane kontrolu nad samotným procesom vyhľadávania — môže ho opakovať, preformovať dotazy, kombinovať zdroje a aktívne rozhodovať o zastavení.
2. Ako Agentic RAG funguje
Namiesto pevnej pipeline (retrieve → read → answer) dostane model prístup k nástrojom vyhľadávania ako k tool callom. Sám navrhne, čo hľadať, dostane výsledky, zhodnotí ich a buď pokračuje v hľadaní, alebo sformuluje odpoveď.
Základný cyklus:
- Plánovanie — Model analyzuje otázku a navrhne postup: čo treba zistiť a v akom poradí.
- Retrieval — Zavolá search tool s konkrétnym dotazom (môže byť iný ako pôvodná otázka užívateľa).
- Evaluácia — Posúdi, či nájdené dokumenty odpovedajú na podotázku.
- Iterácia — Ak nie, preformuluje dotaz alebo skúsi iný zdroj.
- Syntéza — Keď má dostatok informácií, zostaví finálnu odpoveď.
Model nie je pasívnym čitateľom — je aktívnym výskumníkom.
Bežné vzory v praxi:
- ReAct (Reason + Act): Model striedavo uvažuje a volá nástroje, pričom každý krok je viditeľný a logovateľný.
- Self-RAG: Model sa sám hodnotí, či získané pasáže sú relevantné a či odpoveď skutočne podporujú — ak nie, spustí ďalší retrieval.
- CRAG (Corrective RAG): Ak sú výsledky vyhľadávania slabé, systém automaticky siahne po webovom vyhľadávaní ako zálohe.
- Adaptive RAG: Pred vyhľadávaním klasifikuje zložitosť otázky a podľa toho prispôsobí celú stratégiu.
3. Porovnanie: Klasický RAG vs. Agentic RAG
| Vlastnosť | Klasický RAG | Agentic RAG |
|---|---|---|
| Počet retrieval krokov | 1 | 1 až N (dynamicky) |
| Preformulovanie dotazu | Nie | Áno, model rozhoduje |
| Kombinovanie zdrojov | Obmedzene | Áno (rôzne databázy, web) |
| Viacstupňové otázky | Slabo | Silno |
| Latencia | Nízka (1–3 s) | Vyššia (5–30 s) |
| Náklady na tokeny | Nízke | Výrazne vyššie |
| Predvídateľnosť | Vysoká | Nižšia |
| Vhodnosť pre produkciu | Jednoduchá integrácia | Vyžaduje monitorovanie |
4. Praktické použitie a frameworky
Agentic RAG sa v praxi objavuje v nástrojoch ako Perplexity Deep Research, ChatGPT s web search alebo Claude Projects. Vývojári ho implementujú cez niekoľko zavedených frameworkov:
- LangGraph — Stavové grafy, kde každý uzol je retrieval alebo reasoning krok. Ideálne pre komplexné multi-step pipelines s explicitnou kontrolou toku.
- LlamaIndex AgenticRAG — Knižnica s predpripravenými agentic retrieval patternmi a hodnotením relevantnosti.
- DSPy — Deklaratívne definovanie pipeline, kde optimizer sám ladí, kedy a ako retrievovať.
- OpenAI Agents SDK — Priame tool-calling nad vyhľadávačmi (file search, web search) s natívnou podporou handoffs.
Príklad: Právny research agent
Firma potrebuje zodpovedať otázku o regulačnej zhode. Agentic RAG:
- Rozloží otázku na čiastkové: aktuálna legislatíva + judikatúra + interné smernice.
- Vyhľadá v troch rôznych zdrojoch postupne — každý krok informuje ďalší.
- Identifikuje rozpor medzi internými dokumentmi a aktuálnou legislatívou.
- Navrhne ďalší podotaz na spresnenie práve tohto rozporu.
- Syntetizuje odpoveď s citáciami a upozorní na konflikt.
Klasický RAG by vrátil jednu množinu dokumentov — závislosť medzi nimi by zostala skrytá.
5. Limity a riziká
Agentic RAG nie je bez problémov. Pred nasadením v produkcii treba zvážiť niekoľko kritických aspektov:
Latencia a náklady — Každý retrieval krok je API volanie a tokenový overhead. Systém s piatimi iteráciami môže stáť desaťnásobne viac ako jednoduchý RAG a trvať aj 30 sekúnd. Pre real-time aplikácie to môže byť neprijateľné.
Konvergencia — Model môže uviazuť v slučke: hľadá, nenájde relevantné výsledky, preformuluje, znova nenájde. Treba explicitný limit krokov (max_steps) a fallback stratégiu.
Halucinácie v plánovaní — Ak model navrhne zlý plán vyhľadávania, každý ďalší krok stavia na chybnom základe. Chyba sa nekorektuje — naopak, zosilňuje sa vo výslednej syntéze.
Observabilita — Multi-step systémy sú ťažšie laditeľné ako jednopriechodové. Produkčné nasadenie vyžaduje logovanie každého retrieval kroku, skóre relevantnosti a preformulovaných dotazov. Nástroje ako LangSmith alebo Langfuse sú prakticky nevyhnutnosťou.
Bezpečnosť — Ak má agent prístup k citlivým databázam, autorizáciu treba riešiť na úrovni každého individuálneho tool callu — nie len na vstupe celého systému. Prompt injection môže manipulovať, čo a kde agent hľadá.
Zhrnutie: Agentic RAG posúva retrieval od pasívneho vyhľadávania k aktívnemu výskumu — model sám rozhoduje, čo, kde a kedy hľadá. Je to mocný nástroj pre komplexné znalostné systémy, no vyžaduje starostlivé riadenie latencie, nákladov a observability predtým, než sa nasadí do produkcie.