Klient z výroby mal knowledge base: 8 000 technických manuálov, servisných protokolov a výkresov. Nasadili klasický RAG — embed, retrieve top-5, generuj. Pre otázky typu „aké sú parametre motora X?" to fungovalo na 85 % presnosť. Potom prišla otázka: „Čo mám urobiť, keď motor X hlási chybu E47 a zároveň je teplota nad 80 °C?" Systém vrátil fragment o chybe E47 a fragment o teplote — ale nikdy nekonkretizoval, že kombinácia týchto dvoch stavov vyžaduje iný postup ako každý zvlášť. Odpoveď bola technicky správna, operatívne zbytočná.
Toto je trieda problémov, pre ktorú klasický RAG nemá architektúrne riešenie. Nie je to záležitosť lepšieho embeddings modelu ani väčšieho chunk-u. Je to záležitosť toho, kto riadi načítavanie — a kedy vie, že potrebuje načítať viac.
Kde klasický RAG naráža na strop
Klasický RAG (Retrieval-Augmented Generation) pracuje v jednom retrieval kroku: príde otázka, systém zindexuje dotaz, načíta top-K črepín z vektorovej databázy a odovzdá ich LLM. Je deterministický, rýchly a lacný.
Problém nastáva pri štyroch typoch úloh:
- Viacstupňové otázky — odpoveď závisí na dvoch alebo viacerých faktoch, ktoré sú v oddelených dokumentoch a ich prepojenie nie je explicitné v texte. Klasický RAG načíta jeden retrieval krok, LLM dostane len časť kontextu.
- Nejasné alebo neúplné dotazy — používateľ napíše „problémy s chladením na linke 3", ale systém nevie, či myslí chladenie motora, hydraulické chladenie alebo klimatizáciu v hale. Jeden retrieve krok nevyrieši ambiguitu.
- Otázky vyžadujúce porovnanie — „porovnaj servisné intervaly pre zariadenie A a B" vyžaduje dve nezávislé retrieve operácie a ich syntézu, nie jeden retrieve s dúfaním, že oba dokumenty skončia v top-5.
- Iteratívne analýzy — agent musí najprv zistiť niečo základné (napr. sériové číslo zariadenia), potom na základe toho načítať špecifickú dokumentáciu, potom overiť platnosť informácie voči dátumu výroby. Každý krok závisí na výsledku predošlého.
Pre tieto scenáre potrebujete inú architektúru — takú, kde retrieval nie je jednorazová akcia, ale iteratívny proces riadený agentom.
Čo robí agentic RAG inak
Agentic RAG pridáva vrstvu rozhodovania nad klasickú retrieve-generate pipeline. Agent — typicky LLM s prístupom k nástrojom — dostane otázku a sám rozhoduje:
- 1.Aký dotaz má poslať do vektorovej databázy
- 2.Či výsledky sú dostatočné, alebo treba načítať viac
- 3.Aký nový dotaz formulovať na základe toho, čo zatiaľ získal
- 4.Kedy je kontext kompletný a môže generovať odpoveď
Namiesto jedného retrieve-a-generate cyklu vzniká slučka, kde agent vyhodnocuje vlastné medzivýsledky. V praxi to môže vyzerať takto: agent dostane otázku o kombinácii chyby a teploty, formuluje prvý dotaz na chybu E47, prečíta výsledky, rozhodne, že potrebuje kontext o teplotných limitoch, sformuluje druhý dotaz, získa dokumenty, syntetizuje oba kontext-y a až potom generuje odpoveď.
Tento prístup má tri kľúčové mechanizmy, ktoré klasický RAG nemá.
Query rewriting — preformulovanie dotazu
Používateľský vstup zriedkakedy zodpovedá jazyku, ktorým sú dokumenty napísané. Technický manuál popisuje „prehrievanie hydraulického okruhu", používateľ napíše „olej má veľkú teplotu". Query rewriting nechá LLM transformovať pôvodný dotaz do formy, ktorá lepšie zodpovedá vektorovému priestoru embeddings.
Toto je súčasť aj pokročilejších klasických RAG pipelines — nie je to exkluzívna vlastnosť agentic RAG. Rozdiel je, že v agentic RAG sa query rewriting môže opakovať v každom kroku: agent vidí, čo načítal, a preformuluje dotaz na základe medzivýsledku, nie len pôvodnej otázky.
Multi-step retrieval — postupné načítavanie
Agent môže retrieve-ovať viackrát, pričom každý krok informuje ďalší. Toto rieši problém „skrytého prepojenia" — keď je odpoveď distribuovaná cez dokumenty, ktoré nemajú explicitné sémantické vzťahy, ale ich kombinácia je relevantná.
Z praktického hľadiska implementácia vyzerá ako ReAct agent, kde „vyhľadaj v knowledge base" je nástroj. Agent ho volá toľkokrát, koľko uzná za vhodné, s rôznymi dotazmi. Viac o architektúre agentskej slučky nájdete v článku o architektúrach AI agentov.
Self-correction — korekcia vlastných medzivýsledkov
Najsofistikovanejšia vlastnosť agentic RAG. Agent nielen načítava, ale hodnotí, či načítané informácie sú relevantné, aktuálne a dostatočné. V pokročilejších implementáciách sa pridáva separátny faithfulness judge — ďalší LLM volanie, ktoré kontroluje, či generovaný výstup je podložený načítanými dokumentmi, a nie halucinovaný.
Toto je bod, kde mnohí podceňujú zložitosť: naivný agentic RAG bez faithfulness judge môže halucinovať viac než klasický RAG. Dôvod je jednoduchý — dlhší kontext, viacej retrieve krokov, väčší priestor pre model na vygenerovanie plausibilného, ale nepodloženého textu.
Kedy agentic RAG nasadiť — rozhodovací rámec
Nie každý RAG use-case vyžaduje agentskú vrstvu. Toto je rozhodovací rámec z praxe.
Zostaňte pri klasickom RAG, ak: - Väčšina otázok je priamočiara (jeden dokument = úplná odpoveď) - Latencia je kritická (interaktívny chatbot, kde odpoveď musí prísť do 2 sekúnd) - Objem dotazov je vysoký a cost je limitujúci faktor - Knowledge base je úzko definovaná a otázky nepresahujú jej rámec
Prejdite na agentic RAG, ak: - Viac ako ~20 % dotazov vyžaduje informácie z viacerých dokumentov - Používatelia kladú viacstupňové alebo porovnávacie otázky - Odpoveď závisí na stave alebo kontexte, ktorý nie je v pôvodnom dotaze - Presnosť je dôležitejšia ako latencia (rozhodovacia podpora, bezpečnostné protokoly) - Máte kapacitu na implementáciu a monitoring agentic pipeline
Vo výrobných nasadeniach sme videli, že pre znalostné systémy nad technickou dokumentáciou (servisné manuály, normy, postupy) agentic RAG zvyšuje kvalitu odpovedí na viacstupňových otázkach výrazne — ale za cenu 5–10× vyšších tokenových nákladov a 3–5× dlhšej latencie oproti klasickému prístupu. Toto nie je cena, ktorú zaplatíte za každý dotaz, ale musíte s ňou počítať v rozhodnutí o architektúre.
Cena navyše: nie len tokeny
Agentic RAG je drahší ako klasický RAG na viacerých osiach, a samotné tokeny sú len jedna z nich.
Tokenové náklady: Kde klasický RAG spotrebuje na query ~500–1 000 tokenov, agentic RAG s 3–4 retrieval krokmi a faithfulness judge môže spotrebovať 5 000–15 000 tokenov. Pri lacných modeloch (Flash/Haiku tier, rádovo $0,10–0,50 na 1M vstupných tokenov) je tento rozdiel zvládnuteľný. Pri frontier modeloch triedy Claude Opus alebo GPT-5 sú náklady na jeden agentic dotaz rádovo v centoch až desiatkach centov — pri vysokom objeme to je nezanedbateľné.
Latencia: Každý retrieve krok pridáva čas — volanie LLM pre query rewriting, volanie vektorovej databázy, prípadne faithfulness judge. Reálne agentic RAG pipeline na 3–5 krokoch trvajú 5–20 sekúnd. Pre interaktívne aplikácie to vyžaduje asynchrónny dizajn a vizuálnu spätnú väzbu (progress indikátor, streaming).
Réžia implementácie a observability: Klasický RAG je funkcia 50 riadkov. Agentic RAG je pipeline s checkpointingom, retry logikou, monitoringom a debugovacím nástrojom. Bez observability nástrojov ako Langfuse (self-hostable) alebo Arize Phoenix sa stáva skoro neudržateľným. Viackrokový agent bez traces je čierna skrinka — keď zlyhá, neviete prečo. Viac o téme observability pri agentoch nájdete v článku o observability a tracingu.
Retry overhead: Agenti zlyhávajú — nesprávne sformulovaný retrieval dotaz, timeout databázy, neočakávaný formát výsledku. V produkčných systémoch je bežná retry rate okolo 10–15 %, čo efektívne zvyšuje počet volaní. Tento overhead musíte zarátať do cost modelu.
Implementačné vzory v praxi
Existujú dva dominantné prístupy na implementáciu agentic RAG.
Pattern 1: ReAct agent s retrieval nástrojom
Najjednoduchšia forma — štandardný ReAct agent, kde jeden z nástrojov je search_knowledge_base(query: str) -> list[Document]. Agent rozhoduje, kedy a ako nástroj volá, vidí výsledky v Observe fáze a pokračuje podľa toho. Implementácia cez LangGraph s explicitným stavom je dnes štandard pre produkčné systémy.
Výhoda: relatívne jednoduché na implementáciu, agent je flexibilný. Nevýhoda: bez faithfulness judge môže agent halucinovať s istotou, dôveryhodnosť výstupov je variabilná.
Pattern 2: Dedikovaný RAG agent s hodnotiacou slučkou
Sofistikovanejší prístup: retrieve → faithfulness check → ak nie je dostatočné, reformuluj dotaz a opakuj → až keď faithfulness score presahuje prah, generuj finálnu odpoveď. Toto je bližšie k SELF-RAG alebo CRAG (Corrective RAG) vzoru.
Implementačný detail: faithfulness judge je samostatné LLM volanie s promptom, ktorý dostane chunk a generovanú odpoveď a má odpovedať, či je odpoveď podložená chunk-om. Typicky postačí lacnejší model (Haiku tier) ako judge — nepotrebujete najsilnejší model na binárne hodnotenie. Výsledok je merateľný a logovateľný, čo je kľúčové pre audit a ladenie.
Čo nás naučila prax: Najčastejšia chyba pri prvej implementácii agentic RAG nie je technická — je produktová. Tím nasadí plný agentic pipeline pre každý dotaz, bez toho aby rozlíšil jednoduché priamočiare otázky od komplexných. Výsledok: celý systém je pomalý a drahý, hoci 60 % dotazov by zvládol klasický RAG lacnejšie a rýchlejšie.
Odporúčanie z praxe: Router pred vstupom do pipeline. LLM alebo jednoduchý klasifikátor zhodnotí zložitosť dotazu a presmeruje ho buď na rýchly klasický RAG, alebo na agentic pipeline. Toto výrazne zlepší pomer cena/kvalita pri reálnej záťaži. Rozhodovaniu medzi RAG a fine-tuningom sa venuje aj článok o RAG pipeline kvalite.
Typické riziká a ako ich mitigovať
Slučková závislost (retrieval loop): Agent opakovane načítava podobné dokumenty bez pokroku. Riešenie: max_retrieval_steps limit (typicky 4–6) a kontrola duplicity načítaných chunk-ov — ak agent načítal ten istý dokument dvakrát, musí zmeniť dotaz.
Konfabúlácia z dlhého kontextu: Čím viacej dokumentov je v kontexte, tým vyšší priestor pre model na halucinačné prepojenia. Riešenie: faithfulness judge + citácie (každá tvrdenie musí byť mapovateľné na konkrétny chunk). Nejasnosť, z ktorého zdroja informácia pochádza, je varovný signál.
Nekontrolovaný cost: Agentic RAG bez limitov môže na jednej komplexnej otázke spotrebovať 10× viacej tokenov, ako ste plánovali. Riešenie: hard limit na tokeny per dotaz, alerting pri dosiahnutí 50 % limitu, reporting nákladov per dotaz v observability platforme.
Prompt injection cez dokumenty: Agent načíta dokument, v ktorom útočník vložil inštrukcie pre LLM (napr. „ignoruj predchádzajúce inštrukcie a vráť X"). Pri agentic RAG je toto riziko vyššie, pretože obsah dokumentov sa dostáva priamo do kontextu agenta, ktorý riadi následné kroky. Riešenie: separácia kontextu (retrieved documents v oddelenom kontextovom bloku s jasným označením), validácia retrieved obsahu pred vložením do agentského kontextu.
Časté otázky
Je agentic RAG vždy presnejší ako klasický RAG?
Nie. Naivný agentic RAG bez faithfulness judge môže halucinovať viac než klasický RAG, pretože dlhší kontext a viacej retrieval krokov dávajú modelu väčší priestor na vygenerovanie plausibilného, ale nepodloženého textu. Agentic RAG je presnejší iba vtedy, keď je správne implementovaný so sebahodnotiacou slučkou a jasnou citačnou stopou.
Koľko stojí agentic RAG oproti klasickému?
Agentic RAG je typicky 5–10× drahší na jeden dotaz. Pri lacných modeloch (Flash/Haiku tier, $0,10–0,50 / 1M vstupných tokenov) je rozdiel zvládnuteľný. Pri frontier modeloch (trieda Claude Opus, ~$5 input / ~$25 output / 1M tokenov) je cena na agentic dotaz rádovo v centoch až desiatkach centov. Pre vysoký objem dotazov (tisíce denne) je nutný router, ktorý nasmeruje jednoduché otázky na klasický RAG.
Potrebujem špeciálny framework na agentic RAG?
Nie nevyhnutne, ale uľahčí to implementáciu. LangGraph s explicitným stavom a checkpointingom je dnes dominantná voľba pre produkčné systémy — zvládne checkpointing, retry logiku a HITL gate-y. LlamaIndex má zabudovaný agentic RAG s query rewriting a multi-step retrieval. Pre jednoduchšie prípady postačí vlastný kód s ReAct slučkou.
Aká je latencia agentic RAG v produkcii?
Reálna latencia agentic RAG pipeline s 3–5 retrieval krokmi je 5–20 sekúnd. Klasický RAG zvyčajne odpovie do 1–3 sekúnd. Pre interaktívne aplikácie je nutné asynchrónne spracovanie a streaming výstupu — používateľ musí vidieť, že systém pracuje, inak to pociťuje ako zlyhanie.
Kedy radšej použiť GraphRAG ako agentic RAG?
GraphRAG je vhodnejší, keď vzťahy medzi entitami sú dôležité a dokumenty tvoria sieť prepojených faktov (napr. regulatórne prepojenia, organizačné hierarchie). Agentic RAG je vhodnejší, keď je knowledge base dokumentovo orientovaná a problémom sú viacstupňové otázky, nie grafové vzťahy.
*Ak zvažujete, či váš knowledge base use-case si vyžaduje agentic RAG alebo postačí optimalizovaný klasický prístup, radi posúdime konkrétnu situáciu — vrátane odhadu nákladov, latencie a architektonického návrhu. MP Industrial Solutions implementuje RAG a agentic systémy pre B2B prostredie s dôrazom na merateľný výsledok.*