Retrieval-Augmented Generation se za dva roky stala základním stavebním prvkem firemní AI. Téměř každý tým, který dnes nasazuje jazykový model nad vlastními daty, používá nějakou formu RAG. Problém je, že většina z nich stále používá tu nejzákladnější variantu – a pak se diví, proč model hallucinuje, nevidí souvislosti mezi dokumenty a nedokáže vyřešit nic složitějšího než FAQ.

RAG dnes není jedna technika. Je to spektrum tří architektur, z nichž každá odpovídá jinému typu otázek. Kdo si zvolí špatnou, buď přeplácí za jednoduchost, nebo se trápí s komplexitou, kterou nepotřebuje.

První generace: Classic RAG – „Získávej“

Classic RAG je to, co si většina lidí představí, když slyší pojem RAG. Uživatel položí otázku. Systém ji převede na embedding, vyhledá nejpodobnější fragmenty v vektorové databázi, tyto fragmenty vloží do promptu a model vygeneruje odpověď.

Tento přístup je rychlý, jednoduchý a jednosměrný – jeden dotaz, jedno vyhledání, jedna odpověď. Žádné smyčky, žádné rozhodování, žádné iterace.

Kde Classic RAG exceluje

• FAQ a znalostní báze – „Jaké jsou podmínky vrácení zboží?“ nebo „Kolik dní dovolené mám nárok?“
• Vyhledávání v politikách a regulacích – přímé dotazy na konkrétní pravidla
• Zákaznická podpora první linie – standardní dotazy s jasnou odpovědí v jednom dokumentu
• Interní helpdesk – hledání postupů v dokumentaci

Kde Classic RAG selhává

Problém nastává, jakmile odpověď neleží v jednom fragmentu. Když se uživatel zeptá „Jak se změnila naše cenová politika pro enterprise klienty v posledních dvou letech a jaký to mělo dopad na retenci?“, Classic RAG vytáhne několik fragmentů, které se cenové politiky týkají, ale nedokáže:

• Propojit informace z cenové politiky 2024 s daty z retention reportu 2025
• Pochopit kauzální vztah mezi změnou ceny a odchodem klientů
• Rozlišit, které fragmenty jsou relevantní a které jen obsahují podobná klíčová slova

Classic RAG zvládá otázku „co“. Na otázku „jak spolu tyto věci souvisí“ nestačí.

Typický stack Classic RAG

Vektorová databáze (Pinecone, Weaviate, Qdrant, pgvector), embedding model (OpenAI, Cohere, open-source), jednoduchý orchestrátor (LangChain, LlamaIndex). Náklady na provoz jsou nízké, latence minimální, údržba přímočará.

Druhá generace: Graph RAG – „Propojuj“

Graph RAG posunuje vyhledávání z izolovaných fragmentů na propojené entity. Místo toho, aby systém hledal „podobné kousky textu“, staví znalostní graf – síť uzlů (lidé, firmy, produkty, události, koncepce) a jejich vztahů.

Tento přístup zpopularizoval Microsoft Research v roce 2024 a od té doby se stal standardem pro analytické a reportingové use cases v regulovaných odvětvích.

Jak Graph RAG funguje

1. Extrakce entit a vztahů. LLM zpracuje surové dokumenty a identifikuje entity (osoby, organizace, produkty, legislativní normy) a jejich vzájemné vztahy.
2. Detekce komunit. Algoritmus (typicky Leiden) clusteruje graf do skupin úzce souvisejících entit. Tyto komunity představují tematické celky na různých úrovních abstrakce.
3. Sumarizace komunit. LLM generuje souhrnné reporty pro každou komunitu, čímž vytváří předindexovaný přehled celého datasetu.
4. Vyhledávání přes graf. Dotaz se mapuje na relevantní entity a jejich okolí v grafu, čímž se do kontextu dostávají i nepřímé vztahy.

Kde Graph RAG vyniká

• Multi-hop dotazy – „Kteří dodavatelé jsou spojeni s produkty zmíněnými v reklamacích za Q1?“ Odpověď žije ve třech různých dokumentech a vyžaduje dvě úrovně propojení.
• Tematická analýza celého datasetu – „Jaké jsou hlavní obavy zaměstnanců napříč všemi průzkumy spokojenosti za poslední rok?“
• Finanční a právní analýza – propojení firemních dat, tržních trendů a regulatorních požadavků
• Zdravotnictví a výzkum – mapování vztahů v klinických datech nebo výzkumných publikacích

Graph RAG v praxi: Co je třeba vědět

Vyšší vstupní náklady. Budování znalostního grafu vyžaduje zpracování celého korpusu dokumentů jazykovým modelem. U rozsáhlých datových sad to znamená řádově tisíce až desítky tisíc volání LLM jen na indexaci. Novější přístupy jako FastGraphRAG tyto náklady snižují, ale stále jsou výrazně vyšší než u vektorového indexu.

Graf vyžaduje údržbu. Na rozdíl od vektorového indexu, kam stačí přidat nový dokument, znalostní graf je třeba aktualizovat – nové entity, nové vztahy, přepočet komunit. Bez automatizované pipeline se graf rychle stává nekonzistentním.

Ne každý problém potřebuje graf. Pokud vaše dotazy směřují vždy do jednoho dokumentu a nepotřebujete cross-referencing, Graph RAG přidává složitost bez odpovídajícího přínosu.

Graph RAG zvládá otázku „jak jsou tyto věci propojené“. Na otázku „vyřeš to“ ale stále nestačí.

Třetí generace: Agentic RAG – „Rozhoduj“

Agentic RAG je kvalitativní skok. Zatímco Classic i Graph RAG jsou v podstatě jednosměrné pipeline (dotaz dovnitř, odpověď ven), Agentic RAG je uzavřená smyčka, kde AI agent sám rozhoduje, co dělat dál.

Agent nejen vyhledává – plánuje, reflektuje, opravuje se a volí si vlastní nástroje. Pokud první vyhledání nepřineslo dostatečně relevantní výsledky, zpřesní dotaz a zkusí znovu. Pokud odpověď vyžaduje data z více zdrojů, orchestruje paralelní dotazy. Pokud si není jistý kvalitou výstupu, zkontroluje ho a případně přegeneruje.

Klíčové vzory Agentic RAG

Iterativní vyhledávání s reflexí. Agent vyhledá kontext, zhodnotí jeho relevanci vůči dotazu a rozhodne se, zda ho zpřesnit a hledat znovu, nebo přejít k syntéze odpovědi.

Dekompozice dotazu. Komplexní otázku agent rozloží na dílčí podotázky, vykoná je paralelně nebo sekvenčně a výsledky syntetizuje do koherentní odpovědi.

Corrective RAG (CRAG). Validační vrstva hodnotí kvalitu nalezených fragmentů. Pokud je relevance nízká, systém automaticky přepne na alternativní zdroj – webové vyhledávání, jinou databázi, SQL dotaz.

Self-RAG. Model je natrénován generovat „reflexní tokeny“, které mu umožňují dynamicky rozhodovat, kdy vyhledávat a jak kriticky hodnotit vlastní výstup z hlediska faktické konzistence.

Adaptivní směrování. Lehký klasifikátor na vstupu rozhodne, zda dotaz vyžaduje plný agentní workflow, nebo stačí jednoduchá cesta. Jednoduché dotazy jdou přes Classic RAG (nízká latence, nízké náklady), složité přes agentní smyčku.

Kde Agentic RAG dominuje

• Komplexní analytické dotazy – „Analyzuj dopady nové regulace na naše tři nejvýznamnější produktové řady a navrhni úpravy compliance procesů“
• Výzkum a due diligence – agent prochází desítky zdrojů, křížově ověřuje informace, identifikuje mezery
• Technická diagnostika – agent postupně zkoumá příčiny problému, testuje hypotézy, eskaluje podle výsledků
• Autonomní reporty – agent samostatně shromáždí data, zanalyzuje trendy a vygeneruje strukturovaný report

Agentic RAG v praxi: Co je třeba vědět

Spotřeba tokenů. Agentní smyčky typicky spotřebují 3-10x více tokenů než standardní RAG. Každá iterace, každá reflexe, každé přeformulování dotazu stojí peníze. V produkci je nezbytné nastavit limity na počet iterací a používat context caching.

Latence. Jednokrokový Classic RAG vrátí odpověď za 1-3 sekundy. Agentní smyčka s třemi iteracemi může trvat 15-30 sekund. Pro interaktivní chat to může být nepřijatelné, pro analytické úlohy na pozadí je to v pořádku.

Orchestrace. Agentic RAG vyžaduje stavový orchestrátor – LangGraph, CrewAI, AutoGen nebo Haystack. Tyto frameworky řeší správu stavu mezi iteracemi, perzistentní checkpointy, human-in-the-loop přerušení a větvení workflows.

Paměť. Agent bez paměti je neefektivní. Pokud při třetí iteraci zapomněl, co zjistil v první, plýtvá tokeny opakovaným hledáním. Efektivní systémy párují iterativní vyhledávání s epizodickou pamětí.

Přehled: Kdy co použít

Dimenze	Classic RAG	Graph RAG	Agentic RAG
Typ otázky	„Co říká dokument X?“	„Jak spolu souvisí X a Y?“	„Vyřeš tento problém“
Počet kroků	1	1-2	3-10+
Hlavní síla	Rychlost, jednoduchost	Vztahy mezi entitami	Adaptivita, samooprava
Hlavní slabina	Žádné uvažování	Vysoké náklady na indexaci	Vysoké náklady na inference
Latence	1-3 s	2-5 s	10-30 s
Spotřeba tokenů	1x (základ)	1,5-2x	3-10x
Typický use case	FAQ, helpdesk, vyhledávání	Compliance, finanční analýza	Výzkum, diagnostika, reporting
Složitost nasazení	Nízká	Střední-vysoká	Vysoká
Údržba	Minimální	Pravidelná aktualizace grafu	Monitoring agentních smyček

Praktické závěry a tipy

Jak poznat, na které generaci jste

Jste na Classic RAG, pokud: Máte vektorovou databázi, embedding model a jednoduchý prompt s kontextem. Dotaz jde dovnitř, odpověď jde ven, žádné smyčky. To je úplně v pořádku – pokud vaše otázky jsou jednoduché a odpovědi leží v jednom dokumentu.

Jste na Graph RAG, pokud: Vaše data procházejí extrakcí entit a vztahů, máte znalostní graf (Neo4j, Amazon Neptune, nebo in-memory) a dotazy procházejí grafovým traversal. To dělá smysl, pokud potřebujete odpovědi, které propojují informace napříč dokumenty.

Jste na Agentic RAG, pokud: Máte orchestrátor se smyčkami, agent rozhoduje o dalším kroku na základě výsledků předchozího, existuje reflexní mechanismus a možnost přeformulovat dotaz. To je správná volba pro složité, vícekrokové analytické úlohy.

Pravidla pro upgrade

Neupgradujte preventivně. Konsenzus v oboru 2026 zní: „Stavěj jednoduše, přidávej složitost jen když to use case vyžaduje.“ Agentic RAG na FAQ je jako kanón na mouchu – drahou mouchu.

Sledujte signály, že potřebujete druhou generaci. Pokud uživatelé opakovaně dostávají neúplné odpovědi, protože relevantní informace jsou rozesety ve více dokumentech, je čas uvažovat o Graph RAG. Typický signál: „Model odpověděl správně na část otázky, ale neviděl souvislost s jiným dokumentem.“

Sledujte signály, že potřebujete třetí generaci. Pokud odpovědi vyžadují více kroků uvažování, ověřování z více zdrojů nebo dynamické rozhodování o strategii vyhledávání, potřebujete agenta. Typický signál: „Model by musel nejprve zjistit X, pak na základě X vyhledat Y, a teprve pak odpovědět.“

Hybridní architektura je správná odpověď. Nejúspěšnější produkční systémy roku 2026 nepoužívají jednu generaci RAG. Používají směrovací vrstvu (routing agent), která analyzuje složitost dotazu a směruje ho na odpovídající architekturu. Jednoduchý dotaz jde na Classic RAG (nízká latence, nízké náklady), složitý na Agentic RAG s přístupem ke znalostnímu grafu.

Pro rozhodování o rozpočtu

Classic RAG: Minimální investice. Vektorová databáze (managed služba od 50 USD/měsíc), embedding model, základní pipeline. Jeden vývojář to postaví za týden.

Graph RAG: Středně náročná investice. Budování a údržba grafu, licence na grafovou databázi, výrazně vyšší spotřeba tokenů na indexaci. Počítejte s 2-4 týdny na MVP a průběžnou údržbu pipeline.

Agentic RAG: Nejvyšší investice. Orchestrační framework, monitoring agentních smyček, řízení nákladů na tokeny, evaluační framework (RAGAS, Galileo). Počítejte s 4-8 týdny na produkční nasazení a dedikovaným inženýrem na údržbu.

Evaluace – slepé místo většiny týmů

Více než 60 % enterprise nasazení dnes zahrnuje automatizované evaluační frameworky pro kontinuální monitoring kvality odpovědí. Pokud nemáte metriky na faithfulness (věrnost zdrojům), context relevance (relevanci kontextu) a answer correctness (správnost odpovědi), nemůžete rozhodovat o upgradu na vyšší generaci. Evaluace není luxus – je to kompas.

Omezení a kontext

• Tři generace jsou zjednodušení. Realita je kontinuum. Existují hybridní přístupy (graph-enhanced vector retrieval, agentní workflow nad klasickým RAGem), které nezapadají čistě do jedné kategorie. Článek používá tři generace jako konceptuální rámec, ne jako přísnou taxonomii.
• Graph RAG náklady mohou být prohibitivní. Budování znalostního grafu z 10 000 stránkového korpusu může stát řádově 500-2 000 USD jen na LLM volání pro extrakci entit. Pro organizace s omezeným rozpočtem na AI infrastrukturu to může být vstupní bariéra, která poměr náklady/přínos nevyváží.
• Agentic RAG governance je otevřený problém. Autonomní agenti rozhodující o strategii vyhledávání zavádějí nedeterminismus. Dva identické dotazy mohou vést k různým výsledkům v závislosti na pořadí iterací. Pro regulované sektory (finance, zdravotnictví) to komplikuje auditovatelnost a opakovatelnost.
• Evaluace je těžší, než článek naznačuje. RAGAS a podobné frameworky vyžadují anotovaná ground-truth data. Bez nich měříte metriky, které mohou být zavádějící. Vytvoření kvalitního evaluačního datasetu pro vlastní doménu je projekt sám o sobě (řádově týdny práce).
• Vendor lock-in u grafových databází. Přechod na Graph RAG často znamená závislost na konkrétní grafové databázi (Neo4j, Amazon Neptune). Migrace mezi poskytovateli je náročná, protože schéma grafu a query jazyk nejsou standardizované.

Co udělat jako první krok

1. Analyzovat dotazy uživatelů. Projděte posledních 200 dotazů do vašeho systému a roztřiďte je: single-hop (jedna odpověď v jednom dokumentu), multi-hop (odpověď vyžaduje propojení více dokumentů), analytické (vyžadují syntézu a rozhodnutí). Poměr určí, kam investovat.
2. Změřit baseline Classic RAG. Pokud ještě nemáte metriky, implementujte RAGAS evaluaci na 50 vzorkových dotazech. Měřte faithfulness, context relevance a answer correctness. To je váš referenční bod.
3. Implementovat reranking. Než přejdete na vyšší generaci, zkuste na Classic RAG přidat reranker (Cohere, cross-encoder). Je to nejlevnější optimalizace, která často vyřeší 30-50 % problémů s relevancí.
4. Prototypovat hybridní routing. Pokud analýza dotazů ukáže mix jednoduchých a složitých otázek, implementujte jednoduchý klasifikátor (LLM call nebo rule-based), který směruje jednoduché dotazy na Classic RAG a složité na agentní pipeline.
5. Graph RAG testovat na podmnožině. Než investujete do plného znalostního grafu, otestujte Graph RAG na malé, dobře vymezené podmnožině dat (např. 100 dokumentů z jedné domény). Ověřte, zda přidaná hodnota propojených entit ospravedlňuje náklady.

Závěr

Cesta od Classic přes Graph k Agentic RAG není o tom, kdo má modernější stack. Je o přizpůsobení architektury tvaru otázky.

Classic RAG zvládá „co“. Graph RAG zvládá „jak jsou tyto věci propojené“. Agentic RAG zvládá „vyřeš to“.

Většina týmů je stále na první generaci – a pro většinu jejich use cases to je naprosto v pořádku. Problém není v tom, že používají Classic RAG. Problém je v tom, že si neuvědomují, kdy už nestačí, a místo upgradu architektury vylepšují prompty, zvětšují chunk size nebo přidávají reranking. Jsou to užitečné optimalizace – ale pokud odpověď žije mezi dokumenty a ne uvnitř nich, žádný reranking vám nepomůže.

Správná otázka tedy není „jakou generaci RAG použít“. Správná otázka je: „Jaký tvar mají otázky mých uživatelů?“ Odpověď na ni určí, kam investovat.

Zdroje a reference

• Graph RAG: From Local to Global – Microsoft Research, zakladatelský paper
• FastGraphRAG – open-source implementace Graph RAG
• LangGraph – orchestrátor pro Agentic RAG workflow
• RAGAS – framework pro evaluaci RAG pipeline
• Corrective RAG (CRAG) – validační vrstva pro nalezené fragmenty
• Self-RAG – reflexní tokeny pro adaptivní vyhledávání
• Adaptive RAG – směrovací vrstva podle složitosti dotazu

Shrnutí

Verdikt: Správná otázka není „jakou generaci použít“, ale „jaký tvar mají dotazy mých uživatelů“. Většina týmů potřebuje hybridní routing, ne upgrade celého stacku.