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

Agentický RAG je ďalší vývojový stupeň 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: embedovať, raz načítať, vložiť do promptu, generovať. Vždy rovnaký priebeh.
• Agentický RAG = dynamická politika nástrojov: agent plánuje, rozhoduje pre každú požiadavku, volá retrieval iteratívne a sám sa koriguje.
• Trade-off: agentický RAG zvyšuje kvalitu pri zložitých otázkach, no stojí za to viac latencie a peňazí a nesie riziko nekontrolovaných tool-loopov.

Klasický RAG: statická pipeline

Klasický RAG (vo výskume zaradený ako Naive RAG a Advanced RAG, Gao et al. 2023/2024) sleduje deterministický priebeh. 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 zložito vnorenú viacstupňovú otázku.

Typická query-cesta produktívnej klasickej RAG pipeline vyzerá takto:

```
User Query
-> Query Rewriter / HyDE (voliteľné, jednorazovo)
-> Embedding + BM25-Query
-> Hybrid Retrieval (top_k = 50-100)
-> Re-Ranker (top_k = 5-10)
-> Prompt-Template + citovanie zdrojov
-> LLM (Generator)
-> Output + Faithfulness-Check
```

Kľúčový predpoklad: jediný retrieval krok poskytne dosť kontextu pre odpoveď. To je robustné, predvídateľné a dobre merateľné. Slabina sa ukazuje pri otázkach, ktoré potrebujú viacero kôl načítania, pri ktorých nie je jasné, ktorý zdroj je relevantný, alebo pri ktorých sa pôvodná formulácia zle hodí k indexu. Pipeline nemôže doplniť, nemôže prehodiť smer a nemôže pridať druhý zdroj, pretože nemá rozhodovaciu logiku.

Agentický RAG: retrieval ako nástroj agenta

Agentický RAG podľa smerodajnej survey od Singh et al. 2025 (arXiv:2501.09136) vkladá autonómnych agentov do RAG pipeline. Títo agenti využívajú štyri agentické design pattern-y na dynamické riadenie retrieval stratégie:

• Reflection (sebakritika): agent hodnotí načítané zdroje a vlastnú medziodpoveď a rozhoduje, či treba doplniť.
• 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í, SQL dotaze či ďalších API.
• Multi-Agent Collaboration: viacero špecializovaných agentov si rozdeľuje prácu.

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

```
[Agent (Planner)]
|-- Tool: search_kb(query) -> RAG-Pipeline
|-- Tool: web_search(query)
|-- Tool: sql_query(...)
|-- Memory: conversation buffer + episodic store
|-- Reflection: critique(answer, sources) -> loop
```

Štyri rozhodnutia, ktoré agent robí

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

• ČI sa retrievuje (query-routing): pri pozdrave alebo čisto výpočtovej úlohe netreba načítanie. Agent môže retrieval preskočiť.
• ČO sa retrievuje (query-rewriting, voľba zdroja): agent požiadavku preformuluje alebo ju nasmeruje na vhodný zdroj (interná vedomostná báza vs. web vs. štruktúrovaná DB).
• AKO ČASTO sa retrievuje (multi-hop): ak jedna odpoveď nestačí, agent doplní spresnenou požiadavkou.
• ČI odpoveď obstojí (self-correction): cez reflection agent overí výsledok oproti zdrojom a koriguje, 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

Pridanou hodnotou 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 kvartáli najvyššiu mieru reklamácií a čo k tomu stojí v rámcovej zmluve?") vyžadujú viacero načítaní z viacerých zdrojov plus medzireasoning. Statická pipeline na tom štrukturálne stroskotá, agent ich dokáže rozriešiť krok za krokom.

Náklady tejto pridanej hodnoty sú reálne a konkrétne:

• Latencia: každé reflection a multi-hop kolo je dodatočné LLM volanie. Z jednej odpovede sa rýchlo môžu stať tri až päť sekvenčných generovaní.
• Náklady: viac LLM volaní na požiadavku priamo znamená vyššie náklady. V nemčine to navyše sťažuje fakt, že nemecké kompozitá sú podľa tokenizera zhruba 1,3 až 1,7-krát náročnejšie na tokeny než anglický ekvivalent, čo robí každý dodatočný reasoning krok drahším.
• Stabilita: vo výskume zdokumentovaným typickým failure-mode sú nekontrolované tool-loopy a explózia nákladov (Singh et al. 2025). Bez tvrdých limitov pre iterácie, rozpočet a timeout sa správanie stáva nepredvídateľným.
• Zrelosť pojmu: „agentický RAG" nie je k roku 2026 ešte ostro konsolidovaný pojem. Siaha od jednoduchého ReAct-plus-retriever až po multi-agentové architektúry (HM-RAG, M-RAG). To treba zohľadniť pri výbere nástrojov a riadení očakávaní.

Dôležité pre zaradenie: agentický RAG nenahrádza klasický RAG, ale stavia naň. Podkladová pipeline (hybrid search, re-ranking, contextual retrieval) zostáva základom, ktorý agent volá ako nástroj. Rovnako tak paralelná long-context debata (1-2 mil. tokenov kontextové okno) k roku 2026 nie je náhradou RAG, ale komplementaritou: pri realistickom multi-needle retrievale klesá aj Gemini na zhruba 60 % recall, pri výrazne vyššej latencii a nákladoch na požiadavku.

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

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

Klasický RAG: embedding otázky, jedno hybrid načítanie z internej vedomostnej bázy, re-ranking na top-5, generovanie. Výsledok: interné lehoty na vymazanie sú správne citované. „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, no neúplná odpoveď.

Agentický RAG: agent plánuje dve čiastkové otázky. Krok 1: search_kb("interné GDPR/DSGVO lehoty na vymazanie") poskytne 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 zhrnie oba zdroje a označí odchýlky. Výsledok: úplná odpoveď, no tri LLM kolá namiesto jedného, tomu zodpovedajúca vyššia latencia a náklady.

Toto porovnanie ukazuje rozhodovacie kritérium: oplatí sa dodatočná réžia na požiadavku, meraná nárastom kvality pre daný prípad 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 reasoning cez viaceré fakty.
• Musia sa zahrnúť viaceré heterogénne zdroje (interná KB, web, štruktúrovaná DB).
• Požiadavky sú často nejednoznačné a profitujú z query-routing a -rewriting.
• Jediná pevná pipeline poskytuje 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. Tak vznikajú vysoké náklady len tam, kde poskytujú skutočnú pridanú hodnotu. V každom prípade k tomu patria tvrdé guardraily: limit iterácií, nákladový rozpočet na požiadavku, timeout a priebežné tracing (napríklad LangSmith alebo Arize Phoenix).

Pre agentúry a B2B rozhodovateľov

Pre DACH agentúry a B2B tímy je posolstvo striezlivé: agentický RAG nie je štandardný upgrade, ale vedomé architektonické rozhodnutie s nákladovými dôsledkami. Začnite čistou klasickou RAG pipeline (hybrid search, re-ranking, evaluácia cez RAGAS) a najprv zmerajte, kde stroskotáva na multi-hop alebo viaczdrojových otázkach. Až táto dátová báza ospravedlňuje krok k agentickému RAG a poskytuje argument voči rozpočtu. Ak chcete túto konštrukciu, routing medzi klasickou a agentickou cestou a potrebné guardraily pre DACH trh plánovať alebo evaluovať, Blck Alpaca vás podporí od architektonického rozhodnutia až po produktívnu, GDPR/DSGVO-konformnú realizáciu s EU-hostingom.