Co je agentní RAG?
Agentní RAG je retrieval-augmented generation, ve které vyhledávání řídí AI agent, ne pevně daná pipeline. Místo jediného kroku „vyhledej, pak odpověz“ se agent rozhoduje, jestli vůbec potřebuje něco dohledat, co má hledat, který zdroj použít a jestli jsou výsledky dost dobré na to, aby z nich odpověděl, nebo má hledat znovu s lepším dotazem.
Protikladem je klasický RAG, což je přímka: vezmi otázku, vytáhni nejpodobnější pasáže z vektorové databáze, vlož je před model a vygeneruj jednu odpověď. To funguje dobře, když odpověď leží na jednom místě a otázka je jasná. Rozpadne se to, když je otázka vágní, sahá přes několik dokumentů nebo potřebuje navazující dohledání, o kterém první vyhledávání nemohlo vědět.
Agentní RAG z té přímky udělá smyčku. Agent bere vyhledávání jako nástroj, který může zavolat tolikrát, kolikrát potřebuje, stejně jako agentní workflow bere jakýkoli jiný nástroj. Umí přeformulovat slabý dotaz, prohledat druhý zdroj, porovnat, co našel, a teprve potom se zaváže k odpovědi.
Lidsky řečeno
Klasický RAG je jako podat někomu první tři stránky, které vyhodilo vyhledávání, a chtít po něm odpověď přesně z nich, ať se děje, co se děje. Agentní RAG je jako nechat pracovat dobrého rešeršistu: přečte si otázku, rozhodne, co má hledat, projede výsledky, zjistí, že první hledání minulo pointu, hledá znovu lepšími slovy a odpoví, až když má, co potřebuje.
Jak to funguje
V agentním RAG systému už není krok vyhledávání natvrdo zadrátovaný. Agent běží v krátké rozhodovací smyčce:
- Rozhodni, jestli vůbec hledat. U jednoduché otázky může agent odpovědět rovnou a dohledávání úplně přeskočit. Vyhledávání stojí čas i tokeny, takže si ho nezaslouží každý dotaz.
- Naplánuj dotaz. Agent přepíše otázku uživatele do jednoho nebo více cílených vyhledávacích dotazů a rozdělí vícedílnou otázku na samostatná dohledání místo jednoho zamlženého hledání.
- Vyber zdroj. Reálné systémy mají víc míst, kam se dívat: index dokumentace, databázi, web search, interní API. Agent vybere k otázce ten správný nástroj, místo aby pořád mlátil do stejného indexu.
- Posuď výsledky. Agent ověří, jestli to, co se vrátilo, skutečně odpovídá na otázku. Když jsou pasáže mimo téma nebo chudé, hledá znovu jiným dotazem, místo aby odpovídal ze slabého kontextu.
- Odpověz, nebo iteruj. Jakmile je dohledaný kontext dost dobrý, agent vygeneruje odpověď. Když ne, zacyklí se, ale s tvrdým stropem na počet kol.
Koordinace těch kroků, hlavně přes několik zdrojů nebo specializovaných dílčích agentů, je otázka orchestrace AI agentů. A rozhodnout, co vlastně skončí v kontextovém okně modelu v každém průchodu, je jádro context engineeringu: agentní RAG je jeden z nejpřímějších způsobů, jak dostat správné informace před model ve správnou chvíli.
Proč na tom záleží
- Zvládne otázky, na které jedno hledání nestačí. Vícekrokové otázky („kteří z našich klientů v regulovaných odvětvích loni obnovili smlouvu“) potřebují víc než jedno dohledání. Pevná pipeline vyhledá jednou a hádá; agent vyhledá, přečte a vyhledá znovu.
- Vytáhne míň balastu. Tím, že posoudí výsledky před odpovědí, se agent vyhne klasickému selhání RAG, kde se do kontextu vloží nesouvisející pasáže a model z nich poslušně odpoví. Lepší kontext dovnitř znamená míň sebevědomě špatných odpovědí ven.
- Umí říct „nevím“. Protože je vyhledávání rozhodnutí, ne reflex, agent rozpozná, když odpověď nemá žádný zdroj, a zastaví se, místo aby si ji vymyslel z toho, co zrovna hledání vrátilo.
- Použije k otázce správný nástroj. Jedna otázka chce produktovou dokumentaci, druhá živá data z API. Agent nasměruje každý dotaz na zdroj, který na něj umí skutečně odpovědět.
Na co si dát pozor
- Cena a latence se násobí. Každá smyčka vyhledej-a-posuď jsou volání modelu navíc plus vyhledávání navíc. Agent, který hledá třikrát, aby odpověděl na jednu otázku, je trojnásobek latence i ceny oproti klasickému RAG. Smyčky přidávejte jen tam, kde jednorázové dohledání skutečně selhává.
- Smyčky, které se neusadí. Agent s pokynem hledat, dokud nebude spokojený, se umí dotazovat donekonečna na otázku, která dobrou odpověď nemá. Vždy omezte počet kol vyhledávání i rozpočet na tokeny.
- Balast v datech otráví odpověď i tak. Agentní řízení neopraví špatný index, zastaralé dokumenty ani špatné dělení na pasáže. Když jsou data pod tím slabá, agent jen prohledává slabá data promyšleněji. Kvalita vyhledávání pořád začíná u dat.
- Krok posuzování se taky umí splést. Agent rozhoduje, jestli jsou výsledky „dost dobré“, stejným druhem modelu, který se umí sebevědomě mýlit. Benevolentní posuzovatel přijme chudý kontext, přísný se zacyklí. Tohle se musí ladit, ne mu slepě věřit.
- Co nevidíte, neopravíte. Když vyhledávání probíhá proměnlivě mnohokrát přes proměnlivé zdroje, špatná odpověď se těžko trasuje bez logování každého dotazu, každého zdroje a každého posouzení. Proto je LLM observabilita stejně důležitá jako samotný návrh vyhledávání.
Související pojmy
- Co je to RAG (Retrieval-Augmented Generation)? - Základ, na kterém agentní RAG staví: opřít odpověď modelu o dohledané dokumenty.
- Co je agentní AI? - Širší myšlenka AI, která se sama rozhoduje a jedná k cíli; agentní RAG to aplikuje na vyhledávání.
- Co jsou agentní workflow? - Vícekroková smyčka s nástroji, jejíž jeden konkrétní případ agentní RAG je.
- Co je vektorová databáze? - Kde obvykle leží dokumenty, ze kterých agentní RAG dohledává.
- Context engineering - Širší disciplína, jak dostat do modelu správné informace, které agentní RAG slouží.
Chcete být o krok napřed?
Nenechte si utéct naše nejlepší postřehy. Žádný spam, jen praktické analýzy, pozvánky na exkluzivní eventy a shrnutí podcastů přímo do vaší schránky.