Agentický RAG vs. klasický RAG: V čom je rozdiel?

Agentický RAG je ďalším vývojovým stupňom Retrieval-Augmented Generation, pri ktorom autonómny AI agent dynamicky rozhoduje, či, čo a ako často sa vedomosti načítavajú. Retrieval je pritom nástroj, ktorý agent volá reflexívne, viacstupňovo a z viacerých zdrojov. Klasický RAG naopak posiela každú požiadavku cez pevnú, jednorazovú pipeline bez rozhodovacej logiky.

• Klasický RAG = statická pipeline: vytvoriť embedding, raz načítať, vložiť do promptu, generovať. Vždy rovnaký priebeh.
• Agentický RAG = dynamická politika nástrojov: agent plánuje, rozhoduje pri každej požiadavke, volá retrieval iteratívne a sám sa opravuje.
• Kompromis: agentický RAG zvyšuje kvalitu pri zložitých otázkach, no za cenu vyššej latencie a vyšších nákladov a s rizikom nekontrolovaných slučiek volaní nástrojov.

Klasický RAG: statická pipeline

Klasický RAG (vo výskume zaradený ako Naive RAG a Advanced RAG, Gao et al. 2023/2024) sa riadi deterministickým postupom. Požiadavka prechádza vždy tou istou postupnosťou krokov bez ohľadu na to, či ide o triviálnu faktickú otázku alebo o spletitú viackrokovú otázku.

Typická cesta dopytu v produkčnej klasickej RAG pipeline vyzerá takto:

1. Dopyt používateľa
2. Query rewriter / HyDE (voliteľne, jednorazovo)
3. Embedding + BM25 dopyt
4. Hybridné vyhľadávanie (top_k = 50-100)
5. Re-ranker (top_k = 5-10)
6. Šablóna promptu + citovanie zdrojov
7. LLM (generátor)
8. Výstup + kontrola vernosti (faithfulness check)

Kľúčový predpoklad: jediný krok retrievalu poskytne dosť kontextu pre odpoveď. To je spoľahlivé, predvídateľné a dobre merateľné. Slabina sa ukáže pri otázkach, ktoré potrebujú viac kôl načítania, pri ktorých nie je jasné, ktorý zdroj je relevantný, alebo pri ktorých pôvodná formulácia zle zodpovedá indexu. Pipeline nemôže vyhľadať znova, zmeniť smer ani pribrať druhý zdroj, pretože nemá rozhodovaciu logiku.

Agentický RAG: retrieval ako nástroj agenta

Agentický RAG podľa smerodajnej prehľadovej štúdie Singh et al. 2025 (arXiv:2501.09136) vkladá do RAG pipeline autonómnych agentov. Títo agenti využívajú štyri agentické návrhové vzory, aby dynamicky riadili stratégiu retrievalu:

• Reflection (sebakritika): agent hodnotí načítané zdroje a vlastnú priebežnú odpoveď a rozhoduje, či treba vyhľadávať znova.
• Planning: agent rozkladá zložitú otázku na čiastkové kroky (plan-and-execute).
• Tool Use: retrieval je len jedným z viacerých nástrojov popri webovom vyhľadávaní, databázových dopytoch či ďalších API.
• Multi-Agent Collaboration: viacero špecializovaných agentov si delí prácu.

Ranou formalizáciou tohto princípu je Self-RAG (Asai et al. 2023, arXiv:2310.11511), ktorý sa pomocou self-reflection tokenov učí, kedy je načítanie potrebné a či generovanie zostáva verné zdrojom. Koncepčne vyzerá zostava agentického RAG takto:

• Agent (plánovač): plánuje kroky a vyberá vhodný nástroj.
• Nástroj search_kb(query): volá RAG pipeline.
• Nástroj web_search(query): vyhľadáva na webe.
• Nástroj db_query(...): dopytuje štruktúrované dáta.
• Pamäť: vyrovnávacia pamäť konverzácie a epizodická pamäť.
• Reflection: critique(answer, sources) overí odpoveď oproti zdrojom a v prípade potreby spustí ďalšie kolo.

Štyri rozhodnutia, ktoré agent prijíma

Rozhodujúci rozdiel sa dá zhrnúť do štyroch rozhodnutí za behu, ktoré sú v klasickom RAG pevne zadrôtované:

• ČI sa vyhľadáva (query routing): pri pozdrave alebo čisto výpočtovej úlohe netreba nič načítavať. Agent môže retrieval preskočiť.
• ČO sa vyhľadáva (query rewriting, voľba zdroja): agent preformuluje požiadavku alebo ju nasmeruje na vhodný zdroj (interná vedomostná báza vs. web vs. štruktúrovaná DB).
• AKO ČASTO sa vyhľadáva (multi-hop): ak jedna odpoveď nestačí, agent vyhľadá znova so spresnenou požiadavkou.
• ČI odpoveď obstojí (self-correction): agent pomocou reflection overí výsledok oproti zdrojom a opraví ho, namiesto toho, aby slepo generoval.

Priame porovnanie

Zdroje: Gao et al. 2023/2024 (arXiv:2312.10997); Singh et al. 2025 (arXiv:2501.09136).

Výhody a nevýhody: kvalita oproti latencii a nákladom

Silnou stránkou agentického RAG je kvalita odpovedí pri zložitých otázkach. Multi-hop otázky („Ktorý dodávateľ v regióne X mal v poslednom štvrťroku najvyššiu mieru reklamácií a čo k tomu hovorí rámcová zmluva?“) vyžadujú viac načítaní z viacerých zdrojov plus medzikroky uvažovania. Statická pipeline na nich zo štrukturálnych dôvodov zlyhá, agent ich dokáže riešiť krok za krokom.

Táto kvalita má konkrétnu cenu:

• Latencia: každé kolo reflection a multi-hop je ďalšie volanie LLM. Jedna odpoveď tak môže rýchlo vyžadovať tri až päť sekvenčných generovaní.
• Náklady: viac volaní LLM na požiadavku znamená priamo vyššie náklady. V nemčine to navyše zhoršuje fakt, že nemecké zložené slová sú podľa tokenizéra zhruba 1,3 až 1,7-krát náročnejšie na tokeny než anglický ekvivalent, čo predražuje každý ďalší krok uvažovania.
• Stabilita: typickým spôsobom zlyhania, ktorý výskum dokumentuje, sú nekontrolované slučky volaní nástrojov a explózia nákladov (Singh et al. 2025). Bez pevných limitov pre iterácie, rozpočet a timeout je správanie nepredvídateľné.
• Zrelosť pojmu: „agentický RAG“ nie je k roku 2026 ešte presne ustálený pojem. Siaha od jednoduchej kombinácie ReAct plus retriever až po multiagentové architektúry (HM-RAG, M-RAG). Treba to zohľadniť pri výbere nástrojov a pri riadení očakávaní.

Dôležité pre zaradenie: agentický RAG stavia na klasickom RAG a nenahrádza ho. Podkladová pipeline (hybrid search, re-ranking, contextual retrieval) zostáva základom, ktorý agent volá ako nástroj. Aj paralelná debata o dlhom kontexte (kontextové okno s 1-2 mil. tokenov) je k roku 2026 doplnkom RAG, nie jeho náhradou: v multi-needle teste technickej správy k Gemini 1.5 Pro (Google, 2024; stav modelu február 2024, 100 needles, do 1 mil. tokenov) bol recall len niečo nad 60 %. Dlhý kontext má navyše výrazne vyššiu latenciu a náklady na požiadavku než cielené načítanie cez RAG.

Konkrétny príklad: tá istá otázka, dve architektúry

Požiadavka: „Porovnaj naše lehoty na vymazanie podľa GDPR s aktuálnou praxou dozorných orgánov a uveď odchýlky.“

Klasický RAG: embedding otázky, jedno hybridné načítanie z internej vedomostnej bázy, re-ranking na top-5, generovanie. Výsledok: interné lehoty na vymazanie sú citované správne. „Aktuálna prax dozorných orgánov“ chýba, pretože nie je v internej báze a pipeline nemôže osloviť druhý zdroj. Jedno generovanie, nízke stabilné náklady, ale neúplná odpoveď.

Agentický RAG: agent naplánuje dve čiastkové otázky. Krok 1: search_kb("interné lehoty na vymazanie podľa GDPR") vráti interné hodnoty. Krok 2: reflection rozpozná, že chýba externé porovnávacie meradlo, a zavolá web_search("aktuálna prax dozorných orgánov lehoty na vymazanie"). Krok 3: agent spojí oba zdroje a označí odchýlky. Výsledok: úplná odpoveď, ale tri kolá LLM namiesto jedného, a tým aj vyššia latencia a náklady.

Toto porovnanie ukazuje rozhodovacie kritérium: či sa dodatočná réžia na požiadavku oplatí vzhľadom na nárast kvality v danom prípade použitia.

Kedy sa agentický RAG oplatí

Agentický RAG je opodstatnený, ak platí aspoň jeden z týchto faktorov:

• Relevantná časť požiadaviek vyžaduje multi-hop uvažovanie naprieč viacerými faktmi.
• Treba zahrnúť viacero heterogénnych zdrojov (interná KB, web, štruktúrovaná DB).
• Požiadavky sú často nejednoznačné a pomáha im query routing a query rewriting.
• Jediná pevná pipeline dosahuje merateľne príliš slabé hodnoty faithfulness, resp. context recall (RAGAS).

Pragmatickou strednou cestou je hybrid s routingom: rýchla klasická cesta pre väčšinu jednoduchých faktických otázok a agentická cesta len pre zložité prípady. Vysoké náklady tak vznikajú len tam, kde odpoveď skutočne zlepšia. V každom prípade k tomu patria pevné ochranné mechanizmy: limit iterácií, rozpočet nákladov na požiadavku, timeout a priebežný tracing (napríklad LangSmith alebo Arize Phoenix).

Pre agentúry a B2B rozhodovateľov

Pre agentúry a B2B tímy v regióne DACH je odkaz vecný: agentický RAG je vedomé architektonické rozhodnutie s nákladovými dôsledkami, nie štandardný upgrade. Začni s čistou klasickou RAG pipeline (hybrid search, re-ranking, evaluácia cez RAGAS) a najprv zmeraj, kde zlyháva pri multi-hop otázkach alebo otázkach s viacerými zdrojmi. Až tieto dáta opodstatnia krok k agentickému RAG a dajú ti argument pri obhajobe rozpočtu. Ak chceš túto zostavu, routing medzi klasickou a agentickou cestou a potrebné ochranné mechanizmy pre trh DACH naplánovať alebo vyhodnotiť, Blck Alpaca ťa podporí od architektonického rozhodnutia až po produkčnú realizáciu v súlade s GDPR s hostingom v EÚ.