Díl 04 / Pokročilé architektury

Za hranicí RAGu, pokročilé architektury GraphRAG, CAG, Agentic RAG

Tři předchozí díly seriálu skončily u poznání, že naivně postavený RAG má díry. Tahle čtvrtá část je o tom, že RAG ve skutečnosti není jedna architektura, je to rodina. A pro většinu problémů, na které jsme narazili v dílu 3, dnes existuje pokročilá varianta, která ten konkrétní problém řeší. Contextual Retrieval. GraphRAG. CAG. Agentic RAG. Každá je odpovědí na něco jiného.

Autor Pavel Horák Datum Květen 2026 Čtení ~28 minut Stav 20. května 2026

Krátké uvození #

V dílu 1 jsem RAG vysvětlil přes knihovníka, který umí najít relevantní knihy. V dílu 2 jsme rozebrali, jak ten knihovník technicky pracuje. V dílu 3 jsme se podívali na to, kde tenhle knihovník selhává: vytahuje hodnověrné nesmysly, neumí globální syntézu („shrň mi všechny tyhle smlouvy"), láme myšlenky na hranách chunků, neumí pracovat s časovou platností pravidel.

A teď to nejdůležitější. Žádný z těchto problémů není definitivně neřešitelný. Pro každý z nich existuje pokročilejší architektura RAGu, která ho řeší (přinejmenším částečně). Některé jsou produkčně vyzrálé. Některé jsou výzkumné. Některé existují jen v určitých implementacích od konkrétních hráčů.

Tenhle díl je mapa těchto pokročilých variant. Pro každou popíšu: jakou bolest z dílu 3 řeší, jak funguje principiálně, kde jsou její vlastní limity, a kdy má smysl ji nasadit. Cíl není dát recept. Cíl je dát vám orientaci, abyste věděli, jaké pojmy hledat, když vás konkrétní problém potká.

Stále platí všechno, co jsem řekl o ingestion pipeline a doménové znalosti v dílu 3. Žádná pokročilá architektura nezachrání systém s vadnou ingestion vrstvou. Pokročilé architektury řeší retrievalovou a generační vrstvu nad daty, která už jsou v systému dobře připravená.

Mapa pokročilých variant #

Než půjdeme do detailů, krátký přehled. Každý problém z dílu 3 má svého kandidáta na řešení:

Drift k hodnověrnému nesmyslu (chunk je tematicky podobný, ale závěrem opačný) → Contextual Retrieval plus reranking
Chunkování láme myšlenku, izolovaný chunk nedává smysl → Contextual Retrieval (přidává kontext k chunku před vektorizací), hierarchické chunkování
Globální dotazy typu „shrň tyhle padesát zpráv" naivní RAG nezvládne → GraphRAG s community summaries
Stabilní velký korpus, kde vyhledávání nemá smysl (interní dokumentace, kódová báze) → CAG, Cache-Augmented Generation
Komplexní vícekrokový dotaz, kde jeden retrieval nestačí → Agentic RAG, Self-RAG
Mix typů vyhledávání (sémantika, klíčová slova, metadata) → hybrid retrieval s rerankem
Reformulace dotazu, kdy uživatel neumí formulovat → HyDE, RAG-Fusion, multi-query
Více modalit (text, obrázky, tabulky, kód) → multimodální RAG
Časová platnost dat → temporal RAG, oddělené versionované vrstvy

V praxi se tyhle architektury nepoužívají izolovaně. Skutečný produkční systém je často kombinace tří nebo čtyř z nich. Pojďme si je projít.

Contextual Retrieval, jednoduché vylepšení s velkým dopadem #

Začnu architekturou, kterou jsem v dílu 3 jen letmo zmínil a která zaslouží celou sekci. Pochází z dílny Anthropic (září 2024) a její síla je v tom, jak je jednoduchá.

Co problém řeší

Vzpomeňte si na paradox metadat z dílu 3. Malý chunk obsahuje málo kontextu sám o sobě. Když vektorizujete větu „Lhůta činí 30 dní ode dne doručení.", embedding modelu chybí informace, čeho lhůta, které smlouvy, mezi kým. Vektor reprezentuje izolovaný text, ne text v kontextu dokumentu. Při retrievalu pak tento chunk najdete podle obecných slov („lhůta", „dní"), ale ne podle specifického kontextu („výpovědní lhůta ve smlouvě s ABC z roku 2024").

Jak to funguje

Před tím, než se chunk pošle do embedding modelu, prožene se přes LLM s instrukcí typu:

Jsi součást indexačního pipeline. Mám dokument:
[CELÝ DOKUMENT NEBO JEHO RELEVANTNÍ ČÁST]

A z něj tento chunk:
[CHUNK]

Napiš 2-3 věty, které vysvětlují, kde tenhle chunk žije
v rámci dokumentu, čeho se týká a jaký má kontext.
Žádný úvod, žádný komentář, jen ty 2-3 věty.

LLM vrátí krátký kontext, třeba: „Tato klauzule je článek 12.3 výpovědní smlouvy mezi společností XYZ a klientem ABC ze 14. března 2024. Týká se výpovědní lhůty ze strany dodavatele a navazuje na podmínky uvedené v článku 12.1."

Tenhle kontext se prefixuje před vlastní text chunku a teprve výsledek se pošle do embedding modelu. Vektor pak reprezentuje chunk plus jeho kontext, ne jen izolovaný text. Při retrievalu se chunk najde nejen podle obecných slov v něm, ale i podle informací o jeho umístění a vztazích.

Naměřené výsledky

Anthropic publikoval konkrétní čísla z vlastních benchmarků. Měřená metrika je retrieval failure rate, tedy 1 minus recall@20 (procento případů, kdy relevantní chunk není v top 20 výsledcích):

Samotný Contextual Embeddings: snížení chybovosti retrievalu o 35 % (z 5,7 % na 3,7 %)
Contextual Embeddings plus Contextual BM25 (stejný kontext přidaný i k fulltextovému indexu): snížení o 49 % (z 5,7 % na 2,9 %)
Vše plus reranking (Cohere Rerank nad top 50 výsledky): celkové snížení o 67 % (z 5,7 % na 1,9 %)

To jsou jedny z nejlepších čísel, která jsem viděl za posledních dvanáct měsíců u jednoduchého inženýrského zásahu do RAGu. Žádná nová architektura, žádné nové modely, jen jeden krok navíc při indexaci. Vrstva nad existujícím RAG systémem.

Kde jsou limity

Cena. Každý chunk se musí jednou prohnat LLM při indexaci. U stovek tisíc chunků to není zanedbatelná položka. Anthropic v paperu zmiňuje, že náklady se dají snížit přes prompt caching (cachuje se „prefix" plného dokumentu, takže každý další chunk z téhož dokumentu sdílí stejný cache prefix). I tak je to inženýrský úkol, ne plug-and-play.

Druhý limit, který se v paperu nezdůrazňuje: Contextual Retrieval pomáhá s identifikací kontextu chunku, ne s logickou ekvivalencí závěru. Pokud chunk A je tematicky bližší než chunk B, ale chunk B obsahuje skutečnou odpověď (drift k hodnověrnému nesmyslu z dílu 3), Contextual Retrieval ten problém přímo neřeší. Pomáhá v něm reranking, který se na entailment dívá pořádně.

Kdy nasadit

Téměř vždy, když máte produkční RAG a chcete jednoduchý win. Implementačně je to nejlevnější vylepšení s nejlepším poměrem cena/přínos, které dnes existuje. Pokud máte produkční RAG bez Contextual Retrieval, je to první věc, kterou bych zkusil před tím, než budu uvažovat o GraphRAGu nebo agentních architekturách.

GraphRAG, retrieval nad znalostním grafem #

Druhá pokročilá varianta. Vzniklá v Microsoft Research, publikovaná v roce 2024 a od té doby otevřená jako open-source projekt. Řeší úplně jinou bolest než Contextual Retrieval.

Co problém řeší

Klasický vektorový retrieval umí najít top-K chunků, které jsou významově podobné dotazu. Pro úzký faktický dotaz to funguje („Kdy končí platnost smlouvy 2019/047?"). Pro globální dotaz ne. Klasický příklad:

„Co jsou hlavní strategické priority popsané v těchto padesáti výročních zprávách?"

Naivní RAG vytáhne 10 chunků z 50 dokumentů. Které? Podle podobnosti k frázi „strategické priority". To budou pravděpodobně chunky, které tu frázi obsahují doslova (nebo blízce). Ale skutečné strategické priority jsou rozprostřené napříč celými dokumenty, často implicitně, často spojené souvislostmi, které jsou v jednom dokumentu na straně 7 a v jiném na straně 42. Naivní RAG to neuvidí.

Druhý problém: vztahy mezi entitami. Kdo s kým spolupracuje, který výrobek se zmiňuje v souvislosti s kterou kategorií, jak jsou propojené pojmy v dokumentaci. Vektorová podobnost umí najít, že chunk A se podobá chunku B. Neumí říct, že entita X uvedená v chunku A je tatáž entita uvedená v chunku C v jiném dokumentu a pojí se s entitou Y, která je v chunku D.

Jak to funguje

GraphRAG má dvě fáze, které se výrazně liší od klasického RAGu.

Ingestion (indexace) je výrazně dražší a komplexnější.

Dokumenty se rozsekají na chunky standardně.
Každý chunk se prožene přes LLM s instrukcí extrahuj entity a jejich vztahy. Entity jsou osoby, organizace, koncepty, produkty, místa, cokoli, co dává smysl. Vztahy jsou propojení („X pracuje pro Y", „X je kategorií Y", „X navazuje na Y").
Z extrahovaných entit a vztahů se postaví znalostní graf. Uzly = entity. Hrany = vztahy.
Na grafu se spustí algoritmus pro detekci komunit (typicky Leiden algorithm), který najde úzce propojené skupiny entit. Komunity jsou hierarchické: malé komunity uvnitř větších, větší uvnitř ještě větších.
Pro každou komunitu na každé úrovni hierarchie LLM vygeneruje community summary, tedy krátký souhrn toho, čeho se ta komunita týká.

Výsledkem je nejen vektorová databáze chunků, ale i graf entit a hierarchie souhrnů.

Retrieval má dvě cesty podle typu dotazu.

Pro úzké lokální dotazy (kdo, kdy, kde) se použije local search: vyhledá se v grafu od konkrétních entit, vrátí se relevantní chunky plus informace o vztazích.

Pro globální dotazy (shrň, porovnej, jaké jsou trendy) se použije global search: map-reduce přes community summaries. LLM nejprve dostane otázku a každý community summary zvlášť a vyrobí dílčí odpověď („podle této komunity je odpověď taková"). V druhé fázi se dílčí odpovědi spojí do finální syntézy. Tak se dotaz „šíří" napříč celou hierarchií grafu, místo aby se omezil na 10 chunků.

Naměřené výsledky

Microsoft v původním paperu (Edge et al., 2024) ukazuje, že GraphRAG na global queries dosahuje výrazně vyšší comprehensiveness (úplnosti odpovědi) a diversity (zachycení různých úhlů pohledu) než vector-only baseline. Konkrétní čísla závisí na benchmarku, ale řád je desítky procent zlepšení u dotazů, kde naivní RAG neumí dohlédnout.

Na úzké faktické dotazy GraphRAG nezáří, klasický vektorový retrieval je tam srovnatelný a levnější.

Kde jsou limity

Cena indexace. Mnohem dražší než klasický RAG, někdy řádově. Každý chunk se prožene LLM nejen jednou (jako u Contextual Retrieval), ale dvakrát i víckrát (extrakce entit, extrakce vztahů, generování community summaries pro všechny úrovně hierarchie). U korpusů, které se rychle mění, je reindexace bolest.

Kvalita extrakce entit. GraphRAG stojí a padá na tom, jestli LLM v ingestion fázi dobře rozpozná, co je entita a co vztah. V právních dokumentech, kde jsou strany pojmenované jen jednou nahoře a pak se na ně odkazuje jako „Strana A" a „Strana B", to není triviální. Špatná extrakce = špatný graf = špatné odpovědi.

Doménová specifičnost. Stejný problém jako u celého RAGu (viz díl 3, sekce „RAG je nepřenositelný"). Ontologie entit a vztahů, které dávají smysl v jedné doméně, nedávají smysl v jiné. GraphRAG to nedělá lepší, dělá to viditelnější.

Kdy nasadit

Když vaše hlavní use case jsou globální analytické dotazy nad korpusem dokumentů, kde naivní RAG zjevně selhává: výroční zprávy, výzkumné rešerše, novinářské investigace, analytické přehledy. Když je korpus relativně stabilní (reindexace není každý den).

Když jsou vaše dotazy převážně úzké a faktické, GraphRAG je over-engineering. Klasický RAG plus Contextual Retrieval bude rychlejší a levnější.

CAG, Cache-Augmented Generation #

Třetí pokročilá varianta. Vzniklá v roce 2024 jako reakce na to, že kontextová okna LLM dramaticky rostou a u určitých typů úloh už dnes „retrieval" jako koncept nedává smysl.

Co problém řeší

Klasický RAG je just-in-time. Při každém dotazu se hledá v externí databázi, vrátí se top-K chunků, ty se posílají do LLM. To má dvě nevýhody: latence vyhledávacího kroku (vždy nějakých 100 ms a víc) a riziko, že retrieval mine relevantní pasáž (drift k hodnověrnému nesmyslu z dílu 3).

CAG říká: co když celý korpus předem nahrajeme do kontextového okna modelu a vyhledávací krok úplně přeskočíme? Pro určité typy úloh to dává smysl. Pro korpus, který:

Se vejde do rozšířeného kontextového okna (řádově statisíce až jednotky milionů tokenů)
Je relativně stabilní (nemění se každou minutu)
Je uzavřený (interní dokumentace, FAQ, kódová báze, manuály)

Jak to funguje

Mechanismus stojí na tom, že moderní LLM si při zpracování textu vypočítají interní stavy pozornosti, tzv. KV cache (Key-Value cache). Když posíláte dotaz s 500 000 tokenů kontextu, model nejprve celý ten kontext zpracuje a uloží si výpočty do KV cache. Teprve potom generuje odpověď.

U klasického RAG kontext kontextu mění s každým dotazem (vyhledá se jiných 10 chunků), takže KV cache se musí počítat pokaždé znovu. U CAG je princip obrácený:

Ahead-of-time: Korpus se nahraje do kontextového okna jednou a KV cache se uloží.
Per-query: Při dotazu se k uloženému KV cache jen přidá samotný dotaz. Model vygeneruje odpověď přímo nad celým korpusem, který už má „v hlavě".

Bez vyhledávání. Bez chunků. Bez retrieval failure rate. Model vidí celý korpus.

Kde jsou limity

Toto je první limit a vrátíme se k němu: Lost in the Middle. Model si pamatuje začátek a konec kontextu lépe než střed. Při korpusu 500 000 tokenů je drop kvality uprostřed reálný a měřitelný. CAG neobchází Lost in the Middle, naopak ho dělá silnější, protože celý korpus je trvale uprostřed. Týmu, který CAG nasazuje, doporučuju nejdřív přečíst můj nástroj claude-limits.pprojects.cz, který tenhle fenomén vizualizuje.

Druhý limit: korpus musí být stabilní. Když přidáte do korpusu jeden nový dokument, musíte KV cache invalidovat a přepočítat. U FAQ, manuálů, interní dokumentace, kódové báze stabilní fáze v určitých časových obdobích je. U novinového archivu, mailových schránek nebo živé legislativy ne.

Třetí limit: cena za milion vstupních tokenů. Když je váš korpus 500 000 tokenů a vy chcete posílat 1000 dotazů denně, je to 500 milionů tokenů denně. Bez prompt cachingu by to bylo finančně neudržitelné. Anthropic i OpenAI dnes nabízejí prompt caching s velkou slevou na cachované tokeny (řádově 90 % sleva), takže ekonomika CAG dává smysl právě jen v ekosystémech s funkčním cachingem.

Čtvrtý limit: velikost korpusu. Vejde se do kontextu? Aktuální generace modelů (Claude Opus 4.7, Gemini 3 Pro) má kontext řádu milionu tokenů. To je řádově tisíce stran. Pro firemní knihovnu se statisíci dokumentů CAG nedává smysl. Pro produktovou dokumentaci jednoho softwaru typicky dává.

Kdy nasadit

Pro uzavřené stabilní korpusy, které se vejdou do kontextového okna. Konkrétní příklady, kde dnes CAG vyhrává:

Interní firemní dokumentace, která se mění týdně, ne sekundu po sekundě
FAQ, manuály, knowledge base technické podpory
Zdrojový kód jednoho projektu nebo jednoho modulu
Referenční materiály pro úzkou doménu (předpisy jedné země pro jeden segment)

Pro velké, často aktualizované a otevřené korpusy zůstává klasický RAG nebo jeho pokročilé varianty (GraphRAG, Agentic RAG) lepší volba.

Hybridní přístup: CAG plus RAG

V praxi se začíná objevovat hybridní řešení. Stabilní část korpusu (např. obecná pravidla, definice, slovník) jde do kontextu jako CAG. Dynamická část (např. nové dokumenty, aktualizace, čerstvé záznamy) zůstává v klasickém RAG a vrací se přes retrieval. LLM dostává obojí najednou. Pro vývojáře, kteří staví produkční systémy, je to často dobrý kompromis.

Agentic a Self-RAG, retrieval s rozhodováním #

Čtvrtá pokročilá varianta. Vzniklá z poznání, že u komplexních dotazů jeden krok retrieval-then-generate nestačí. Lidé z výzkumu (Asai et al. 2023, Self-RAG paper) i produkční inženýři dospěli ke stejnému závěru: model musí o retrievalu rozhodovat sám.

Co problém řeší

Naivní RAG: položíte otázku → najde se top-K → LLM odpoví. Jeden cyklus, jedna odpověď. Funguje pro úzké dotazy. Selhává pro komplexní:

„Porovnej, jak naše konkurence X a Y řeší zpracování osobních údajů v jejich obchodních podmínkách za poslední tři roky, a navrhni, kde můžeme být přísnější."

To není jedna otázka. Je to:

Najdi obchodní podmínky firmy X za poslední tři roky.
V nich najdi pasáže o zpracování osobních údajů.
To samé pro firmu Y.
Porovnej, kde se liší a kde shodují.
Najdi naše vlastní obchodní podmínky.
V nich najdi naše pasáže o OÚ.
Porovnej s konkurencí a navrhni úpravy.

Sedm dílčích kroků. Každý vyžaduje vlastní retrieval. Klasický RAG to s jedním hledáním nezvládne, najde top-K chunků k celé dlouhé otázce a LLM se z nich pokusí poskládat odpověď, která bude neúplná, povrchní, často špatná.

Jak to funguje

Agentic RAG dělá retrieval součástí iteračního rozhodovacího cyklu. Místo retrieval → generate funguje takto:

LLM dostane dotaz a sadu tools: search_documents, search_metadata, get_full_document, calculate, atd.
LLM rozhodne, který tool zavolat (často to bude search) a s jakými parametry.
Tool vrátí výsledek (chunky, dokumenty, metadata).
LLM rozhodne: stačí mi to k odpovědi? Pokud ano, odpoví. Pokud ne, zavolá další tool, formuluje další dotaz.
Cyklus se opakuje, dokud LLM nemá dost informací nebo nenarazí na limit počtu kroků.

Klíčové slovo je rozhodování. LLM není pasivní příjemce kontextu, je aktivní orchestrátor. Volá retrieval podle potřeby, formuluje dotazy, rozhoduje, kdy už má dost informací, rozhoduje, kdy je třeba reformulovat původní otázku do podotázek.

Self-RAG, varianta s ještě jemnější kontrolou

Self-RAG (Asai et al., 2023) jde ještě dál. Model je trénovaný na to, aby generoval speciální reflection tokens během generování odpovědi:

[Retrieve] — model říká „tady potřebuju načíst další informace"
[Relevant] / [Irrelevant] — model označuje, jestli načtený chunk je relevantní
[Supported] / [NotSupported] — model označuje, jestli věta, kterou právě napsal, je podložená v chuncích
[Useful] — model hodnotí, jestli odpověď celkově odpověděla na otázku

Tyto tokeny dovolují systému retrievovat až uprostřed generování odpovědi, ne jen na začátku. Když model píše třetí větu odpovědi a uvědomí si, že potřebuje další informaci, sám si pro ni řekne. To je výrazný posun oproti klasickému RAG, kde se retrieval děje jednou předem.

Kde jsou limity

Latence a cena. Jeden klasický RAG dotaz = jeden volání LLM. Agentic RAG dotaz = 3 až 15 volání LLM. Plus 3 až 15 retrieval operací. To není zanedbatelné. Náklady na drahý dotaz mohou být řádově vyšší než u klasického RAG.

Stabilita. Agent může zacyklit nebo se rozhodnout špatně. „Volá retrieval třikrát na stejnou otázku", „pořád se ptá na něco, co už ví", „neumí říct, že odpovídat nemůže". Inženýři, kteří staví Agentic RAG v produkci, věnují většinu času právě téhle stabilitě, ne samotnému retrievalu.

Auditovatelnost. Klasický RAG je jednoduchý: tady byl dotaz, tady byly chunky, tady byla odpověď. Agentic RAG je řetěz několika kroků, kde každý ovlivňuje další. Pro audit, post-mortem analýzu nebo regulátora to je výrazně náročnější.

Kdy nasadit

Pro komplexní vícekrokové dotazy, kde uživatelé reálně potřebují, aby systém rozložil otázku, několikrát hledal a syntetizoval. Pro analytické úkoly, pro reasoning, pro porovnávání. Tam, kde drift k hodnověrnému nesmyslu nemůžete tolerovat a chcete, aby systém uměl říct „nevím, načítám další zdroj".

Pro jednoduché Q&A nad FAQ je to over-engineering. Klasický RAG plus reranking tam bude rychlejší, levnější a srovnatelně dobrý.

Návaznost na MCP

Agentic RAG se v roce 2026 přirozeně propojuje s MCP (Model Context Protocol). Tools, které agent volá, jsou v MCP architektuře standardizované jako MCP servery. Místo aby každý systém měl vlastní implementaci toolů, agent volá MCP server pro retrieval, jiný MCP server pro databázi, další pro emaily. Standardizace volání. To není detail, to mění, jak se agentní systémy budou stavět v nejbližších letech.

Hybrid retrieval s rerankem jako baseline #

Krátká sekce, protože většinu už jsem řekl v dílu 2. Tady jen jako shrnutí, kam tahle architektura v rodině RAGu patří.

Hybrid retrieval = kombinace sémantického vyhledávání (vektory), fulltextového vyhledávání (BM25) a strukturovaného vyhledávání (SQL nad metadaty). Výsledky se slučují přes Reciprocal Rank Fusion nebo vážený průměr. Top 30 až 50 výsledků se posílá do reranking modelu (Cohere Rerank, BGE Reranker), který je seřadí znovu s ohledem na konkrétní otázku.

V roce 2026 je to produkční baseline, ne pokročilá varianta. Jakýkoli vážný RAG systém ho má. Pokud váš RAG hybrid retrieval nemá, je to první věc, kterou opravit, ještě před tím, než budu uvažovat o GraphRAGu nebo Agentic RAGu.

Doplnění proti dílu 2: novější reranking modely v roce 2026 (zejména Voyage Rerank-2, Cohere Rerank 3, BGE Reranker-v2) dokáží zachytit i logickou ekvivalenci závěru, ne jen sémantickou podobnost. To výrazně oslabuje drift k hodnověrnému nesmyslu, kterým jsem začínal díl 3. Stále to není dokonalé, ale je to lepší, než reranking, který byl k dispozici před dvěma lety.

Další architektury, které stojí znát #

Vedle hlavní pětice existují další varianty, kterým bych dal samostatný díl, kdyby na to byl prostor. Tady aspoň krátké představení každé, abyste věděli, jaké pojmy hledat, když na ně narazíte.

HyDE, Hypothetical Document Embeddings

Problém: uživatel formuluje dotaz krátce a obecně („Jak udělat refund?"). Dokumenty v databázi mluví detailně a odborně („Postup pro vrácení částky podle obchodních podmínek..."). Embedding model najde shodu těžko, protože vektory krátkého obecného dotazu a dlouhé detailní pasáže si nesedí.

Řešení: LLM dostane dotaz a má za úkol vygenerovat hypotetickou odpověď, jak by mohla vypadat. Tato hypotetická odpověď se vektorizuje místo původního dotazu. Retrieval pak hledá dokumenty podobné hypotetické odpovědi. To dramaticky zlepšuje recall pro short queries.

Nevýhoda: další volání LLM v retrieval kroku. Halucinace v hypotetické odpovědi může retrieval vést mimo.

RAG-Fusion a multi-query RAG

Místo jednoho dotazu se LLM zeptá: „Jak bys tuto otázku přeformuloval pěti různými způsoby?" Pět reformulací se vektorizuje, pět retrievalů paralelně, výsledky se sjednotí přes RRF (Reciprocal Rank Fusion). Pomáhá to zachytit dokumenty, které by se jedinou formulací netrefily.

Hodí se pro vyhledávání, kdy uživatelé formulují otázky nepřesně nebo nekonzistentně.

Multimodální RAG

Klasický RAG pracuje s textem. Multimodální RAG vektorizuje a vyhledává napříč modalitami: text, obrázky, tabulky, kód, audio přepisy, video transkripty. Embedding modely jako CLIP, SigLIP nebo novější multimodální (např. Cohere Embed v3 multimodal, OpenAI text-embedding-3 s image extension) umí vektorizovat obrázky do stejného vektorového prostoru jako text. Vyhledávání na základě dotazu „najdi tabulku, která ukazuje růst tržeb za 2024" pak může vrátit jak text, tak obrázek tabulky z PDF.

Pro firmy, které mají dokumentaci jako kombinaci PDF s diagramy, screenshoty a tabulkami, je multimodální RAG často víc než hezká featura, je to nutnost. Klasický text-only RAG ztratí značnou část obsahu jen tím, že obrázky a tabulky nevidí.

Temporal RAG, RAG s časovým versioningem

Reakce na problém z dílu 3 (Temporal validity, kdy rok mění význam). Architektura, ve které mají chunky a metadata explicitní časové platnosti. Při retrievalu se přidá filtr k jakému datu hledáme, a vrátí se jen ty chunky a entity, které byly v daném okamžiku platné.

Stále spíš výzkumná oblast než produkční standard. V právních RAG systémech od velkých kanceláří (Havel & Partners WAIR, Harvey AI) se začíná objevovat v různých variantách. Pro běžné enterprise RAG nasazení v roce 2026 je to oblast, kde je třeba si architekturu navrhnout vlastní.

Late-stage context injection (vlastní pojmenování)

Vrátím se k vlastnímu konceptu, který jsem představil v dílu 3. RAG funguje ne jako zdroj odpovědi, ale jako routing layer. Vyhledá, které dokumenty jsou pro otázku klíčové, a do LLM se pak pošlou celé tyto dokumenty (ne izolované chunky) plus relevantní paragrafy zákonů, dodatky, judikatura. LLM dostane plný kontext jako lidský expert.

V kombinaci s pokročilými architekturami z tohoto dílu: hybrid retrieval + reranking + Contextual Retrieval pro identifikaci klíčových dokumentů → late-stage injection celých dokumentů do kontextu → LLM generuje odpověď s plnou znalostí kontextu. Drahé. Pro doménu, kde hodina experta stojí tisíce, smysluplné.

Co dál, kam to směřuje #

Pohled trochu dál než produkční rok 2026. Co se rýsuje na horizontu a co stojí sledovat.

Memory-augmented agents, ne jen retrieval

RAG byl dosud chápán jako jednorázový proces: dotaz → retrieval → odpověď, žádná paměť. Nová generace systémů přidává persistentní paměť: agent si pamatuje předchozí interakce, naučené preference, vyvozené závěry, a aktivně je používá v budoucích dotazech. Knowledge graf zde není statický předem postavený dokument, ale roste s každou interakcí. Letterm/MemGPT, Mem0, Anthropic Memory feature.

Pro firemní systémy je to atraktivní, ale otevírá to vážné otázky: kdo má přístup k paměti agenta, co se v ní ukládá, jak ji čistit, jak ji auditovat. GDPR komplikuje. Není to vyřešená oblast.

MCP jako runtime pro retrieval

Model Context Protocol z původního proprietárního formátu Anthropic se v prosinci 2025 stal otevřeným standardem pod Linux Foundation (Agentic AI Foundation, s podporou Anthropic, OpenAI, Block, AWS, Google, Microsoft, Cloudflare). To znamená, že retrieval, který agent volá, není pevně zakódovaný v jeho prompt template, ale je to volání MCP serveru. Stejný agent může volat retrieval z Pinecone, Weaviate, Glean, Sharepoint, ChromaDB, čehokoli, co implementuje MCP server. Standardizace dramaticky zjednodušuje výstavbu pokročilých RAG systémů.

Multi-agent RAG

Rozšíření Agentic RAG. Místo jednoho agenta, který rozhoduje o všem, několik specializovaných agentů spolupracujících na úkolu: retrieval agent hledá zdroje, fact-checker agent ověřuje fakta, synthesis agent tvoří finální odpověď, auditor agent hodnotí, jestli odpověď splňuje zadání. Každý běží jako samostatný LLM s vlastními prompty.

Konkrétní implementace: CrewAI, AutoGen (Microsoft), LangGraph (LangChain), Anthropic Multi-Agent Research (květen 2025). Pro náročné domény jako právo a medicína se to už začíná nasazovat. Pro běžné firemní úlohy je to ještě over-engineering.

Embedding modely, které rozumí logice

Konečně jedna oblast, kde se dostává pomalý, ale reálný posun. Klasické embedding modely jsou trénované na sémantickou podobnost. Nové generace (entailment-aware embeddings, instruction-tuned embeddings) jsou trénované specificky na úkol tento text je odpověď na tuto otázku, nikoli jen tento text je tematicky podobný. To přímo útočí na drift k hodnověrnému nesmyslu z dílu 3. Voyage AI a Cohere oba publikují modely v této kategorii. Adopce v běžných RAG knihovnách (LangChain, LlamaIndex) je zatím slabá, ale to se za rok dva změní.

Mapa, která architektura na jaký problém #

Krátké rozhodovací schéma. Není to univerzální pravda, je to startovací bod.

Máte fungující RAG, který občas selhává a chcete rychlý win → Contextual Retrieval + hybrid retrieval + reranking. Tři kroky, řádové zlepšení.
Globální analytické dotazy nad korpusem dokumentů („shrň, porovnej, jaké jsou trendy") → GraphRAG. Akceptujte vyšší cenu indexace.
Stabilní uzavřený korpus, který se vejde do kontextového okna (manuál, FAQ, kódová báze) → CAG s prompt cachingem. Bez retrievalu.
Komplexní vícekrokové dotazy (porovnej, navrhni, analyzuj v širším kontextu) → Agentic RAG nebo Self-RAG. Akceptujte vyšší latenci a cenu.
Krátké obecné dotazy proti detailním dokumentům → HyDE před retrievalem.
Uživatelé formulují inkonzistentně → multi-query RAG, RAG-Fusion.
Dokumenty kombinují text, obrázky, tabulky → multimodální RAG s CLIP/SigLIP embeddings.
Doménová specifika, kde čas mění význam dat (právo, regulace) → temporal RAG, oddělené versionované vrstvy. Vlastní implementace.
Doména, kde drahý dotaz se vyplatí (právo, medicína, finance) → late-stage context injection, celé dokumenty místo chunků.

V praxi vždy kombinace dvou nebo tří. Skutečný produkční systém je například: hybrid retrieval + Contextual Retrieval + reranking pro běžné dotazy, agentic vrstva pro komplexní dotazy, knowledge graph pro globální syntézu, persistentní paměť pro kontextové konverzace. Vrstvená architektura, kde každá vrstva řeší jiný typ úkolu.

Co si odnést podle úrovně čtenáře #

Pro byznysového čtenáře. RAG není jeden produkt, ani jedna technologie. Když si od dodavatele kupujete „RAG řešení", ptejte se konkrétně: které architektury implementujete? Jak řešíte globální analytické dotazy? Jakou máte rerank vrstvu? Plánujete agentní rozhraní? Jak řešíte časovou platnost dat? Dodavatel, který odpoví „náš RAG je založen na vektorové databázi a embedding modelu", staví na úrovni roku 2023.

Pro technického čtenáře. Začněte Contextual Retrieval. Levné, jednoduché, řádové zlepšení. Pak hybrid retrieval s rerankem. To je dnes produkční baseline. GraphRAG, CAG a Agentic RAG nasazujte jen tehdy, když máte konkrétní use case, který je vyžaduje. Nepoužívejte je proto, že jsou „nové".

Pro vedoucího AI projektu. Investice do architektury je důležitější než investice do konkrétního embedding modelu nebo vektorové databáze. Embedding modely se vymění za rok dva. Architektura zůstává. Pokud váš tým investuje 80 % času do volby embedding modelu a 20 % do návrhu architektury, dělejte to obráceně.

Pro každého. Žádná architektura není stříbrná kulka. Každá řeší konkrétní bolest a zavádí vlastní limity. Contextual Retrieval je nejlevnější win. GraphRAG je drahá indexace, ale silná na globální dotazy. CAG je rychlost bez retrievalu, ale jen pro stabilní malé korpusy. Agentic RAG je síla, ale taky latence a riziko zacyklení. Pochopit, kde každá architektura září a kde selhává, je důležitější, než znát všechny jejich implementační detaily.

Otevřené otázky #

Tohle byl přehled pokročilých architektur. Některé jsou produkčně vyzrálé (Contextual Retrieval, hybrid + rerank), některé se rychle prosazují (GraphRAG, Agentic RAG), některé jsou na začátku adopce (CAG, multimodální RAG, entailment-aware embeddings). A nad tím vším visí otázky, na které ještě nemáme jasnou odpověď:

Kdy a za jakých podmínek nahradí nekonečně dlouhý kontext klasický retrieval úplně? Pokud LLM budou mít kontext 10 milionů tokenů a Lost in the Middle bude vyřešený, je RAG stále potřeba?
Jak měřit kvalitu pokročilých RAG architektur? Standardní benchmarky (MRR, NDCG, BLEU) byly navržené pro klasický retrieval. Pro Agentic RAG, kde se model rozhoduje vícekrokově, žádný univerzální benchmark neexistuje.
Kdy bude bezpečné nasadit autonomní AI agenty do produkčních enterprise systémů? Tam, kde mohou číst a zapisovat firemní data bez human-in-the-loop, kde se chyba projeví na klientovi?
Jak řešit cross-tenant izolaci v Agentic RAG? Agent, který má přístup k více klientům, je sám sebou bezpečnostní riziko. Multi-agent architektury s explicitními bezpečnostními bariérami jsou ještě v plenkách.
Bude se ekosystém RAG knihoven sjednocovat (LlamaIndex + LangChain a další konvergují k MCP), nebo se naopak rozejdou (různé knihovny pro různé use case)?

Budu rád za diskusi

Tohle byly tři díly seriálu (RAG koncepčně, technicky, v praxi) plus tenhle čtvrtý o pokročilých variantách. Pokud máte vlastní pohled na některé z otevřených otázek, nebo víte o konkrétním nasazení GraphRAG, CAG, Agentic RAG v české praxi, napište mi na LinkedIn (Pavel Horák, MELIORO Systems). Zajímají mě jak technické, tak byznysové úhly.

LinkedIn → Pavel Horák

Pojmy

Glosář pojmů

Termíny, se kterými jste se v článku setkali. Vysvětlení jsou samostatná pro tento díl, takže se některé pojmy překrývají s glosáři jiných dílů. To je záměr, abyste nemuseli skákat mezi stránkami.

LLM Large Language Model: Velký jazykový model. Program jako Claude (Anthropic), ChatGPT (OpenAI), Gemini (Google), Grok (xAI), Le Chat (Mistral), Llama (Meta). Učil se z obrovského množství textu a umí generovat odpovědi v lidském jazyce.
RAG Retrieval Augmented Generation: Generování obohacené o vyhledávání. Spojení vyhledávání v dokumentech (retrieval) a generování odpovědi jazykovým modelem (generation). Klasická tříkroková architektura: dotaz → top-K chunků z databáze → LLM generuje odpověď z těchto chunků.
Kontextové okno: Množství textu, které LLM dokáže „udržet v hlavě" najednou. Měří se v tokenech. Aktuální generace velkých proprietárních modelů (Claude, Gemini) dosahuje milionu tokenů a víc. Reálně použitelná část je vždy menší než reklamované maximum, kvůli Lost in the Middle.
Token: Základní jednotka, kterou LLM zpracovává text. Pro češtinu zhruba 3 znaky na token. Cena LLM API se počítá za tokeny.
Embedding: Číselná reprezentace významu textu. Umožňuje vyhledávat podle významu, ne podle přesné shody slov. „Auto" tak najde i texty o „voze" nebo „vozidle". Embedding model je samostatná neuronová síť, která text převede na vektor čísel.
Vektorová databáze: Databáze postavená na jediný úkol: rychle najít vektory, které jsou podobné jinému vektoru. Konkrétní příklady: Pinecone, Weaviate, Chroma, Qdrant, Milvus.
Chunk a chunking: Chunk je malý kousek textu, na který se dokument rozseká před vektorizací. Typicky věta, odstavec nebo sekce. Chunking je proces toho rozsekání. Strategií chunkování je víc (fixed-size, sentence, semantic, structural, recursive) a každá má jiné vlastnosti.
Retrieval: Vyhledávání. Krok, ve kterém systém najde k vašemu dotazu nejrelevantnější části dokumentů místo toho, aby četl všechno najednou. Klasický RAG dělá retrieval přes vektorovou podobnost. Pokročilé architektury (Agentic RAG, GraphRAG) dělají retrieval složitější způsobem.
Hybrid retrieval: Kombinace sémantického vyhledávání (vektory), fulltextového vyhledávání (BM25) a strukturovaného vyhledávání (SQL nad metadaty). Výsledky se slučují, typicky přes Reciprocal Rank Fusion (RRF) nebo vážený průměr.
Reranking: Druhá vrstva po retrievalu. Top 30 až 50 výsledků hybrid retrievalu projde specializovaným modelem (Cohere Rerank, Voyage Rerank, BGE Reranker), který je seřadí znovu s ohledem na konkrétní otázku. Rerank modely jsou trénované na úloze „je tento chunk skutečnou odpovědí na tuto otázku, nebo jen tematicky souvisí".
Contextual Retrieval: Architektura od Anthropic (září 2024). Před vektorizací se každý chunk prožene přes LLM s instrukcí „napiš 2-3 věty, které vysvětlují, kde tenhle chunk žije v rámci dokumentu". Tento kontext se přidá k chunku před embedding modelem. Snižuje retrieval failure rate o 35-67 % podle kombinace s ostatními technikami.
GraphRAG: Architektura od Microsoft Research (2024, open-source). Z dokumentů se extrahují entity a vztahy mezi nimi, postaví se znalostní graf, najdou se komunity úzce propojených entit a pro každou komunitu se vygeneruje community summary. Pro globální dotazy se použije map-reduce přes tyto souhrny místo prostého vektorového retrievalu.
Knowledge graph (znalostní graf): Datová struktura, kde uzly představují entity (osoby, organizace, koncepty) a hrany představují jejich vztahy („X pracuje pro Y", „X je kategorií Y"). Klasická reprezentace strukturovaných znalostí, používaná dlouho před AI érou. V kontextu pokročilého RAGu je základem GraphRAG architektury.
Community summaries: Souhrny tematicky propojených skupin entit v knowledge grafu, generované LLM. V GraphRAG architektuře slouží jako stavební bloky pro odpovědi na globální dotazy. Hierarchické (malé komunity uvnitř větších).
CAG Cache-Augmented Generation: Architektura, ve které se celý korpus nahraje předem do kontextového okna LLM, KV cache se uloží a při dotazu se neprovádí žádný retrieval. Model „má v hlavě" celý korpus. Funguje pro stabilní uzavřené korpusy, které se vejdou do kontextu. Eliminuje retrieval failure rate, ale dělá silnější Lost in the Middle.
KV cache Key-Value cache: Interní výpočetní stavy LLM, které se vytvoří při zpracování dlouhého kontextu. Model si je uloží, aby je nemusel znovu počítat pro každý nový token v odpovědi. V CAG architektuře se KV cache pro celý korpus uloží jednou a sdílí napříč dotazy. Anthropic a OpenAI dnes nabízejí prompt caching jako placenou službu s výraznou slevou na cachované tokeny.
Agentic RAG: Architektura, ve které LLM rozhoduje, kdy a co hledat. Místo jednoho cyklu retrieval-then-generate funguje jako iterační smyčka: model dostane sadu tools (search, get_document atd.), rozhodne, který zavolat, dostane výsledek, rozhodne, co dál. Hodí se pro komplexní vícekrokové dotazy.
Self-RAG: Varianta Agentic RAGu (Asai et al., 2023), ve které je LLM trénovaný na generování speciálních reflection tokens ([Retrieve], [Relevant], [Supported], [Useful]). Tyto tokeny dovolují modelu rozhodovat o retrievalu i uprostřed generování odpovědi a hodnotit kvalitu vlastních výstupů.
HyDE Hypothetical Document Embeddings: Technika, ve které LLM před retrievalem vygeneruje hypotetickou odpověď, jak by mohla vypadat. Ta se vektorizuje místo původního dotazu a retrieval hledá dokumenty podobné této odpovědi. Pomáhá u krátkých obecných dotazů proti detailním dokumentům.
RAG-Fusion a multi-query RAG: LLM přeformuluje původní dotaz pěti až sedmi různými způsoby. Pro každou reformulaci se udělá samostatný retrieval a výsledky se sjednotí přes RRF. Pomáhá zachytit dokumenty, které by se jednou formulací netrefily.
RRF Reciprocal Rank Fusion: Algoritmus pro slučování více seznamů výsledků z různých vyhledávacích systémů. Neporovnává skóre (která mají různé škály), ale pořadí. Dokument, který je ve dvou seznamech vysoko, je vysoko i v sloučeném výsledku.
Multimodální RAG: Architektura, kde se vyhledává napříč modalitami: text, obrázky, tabulky, kód, audio přepisy. Používá multimodální embedding modely (CLIP, SigLIP, Cohere Embed v3 multimodal), které umí vektorizovat obrázky a text do stejného vektorového prostoru.
Temporal RAG: Architektura, kde mají chunky a entity explicitní časové platnosti. Při retrievalu se přidá filtr „k jakému datu hledáme" a vrátí se jen ty pasáže, které byly v daném okamžiku platné. Reakce na temporal validity problém (rok mění význam pravidel) z dílu 3.
Late-stage context injection: Koncept (vlastní pojmenování z dílu 3): RAG funguje ne jako zdroj odpovědi, ale jako routing layer. Vyhledá klíčové dokumenty a do LLM se pošlou celé dokumenty (ne izolované chunky) plus relevantní zákony, dodatky, judikatura. LLM dostane plný kontext jako lidský expert. Drahé, ale pro náročné domény efektivní.
Lost in the Middle: Fenomén, kdy LLM si pamatují informace ze začátku a z konce kontextu lépe než ty uprostřed. Experimentálně potvrzeno Stanford University v roce 2024 (Liu et al., TACL). Platí pro všechny současné velké modely. Limituje použitelnost CAG a long-context přístupů.
Drift k hodnověrnému nesmyslu: Vlastní pojmenování z dílu 3. Embedding modely najdou text, který je tematicky podobný, ale závěrem může jít opačným směrem. LLM si na něm postaví hodnověrně vypadající, ale věcně špatnou odpověď. Reranking a entailment-aware embeddings problém zmírňují, ale neeliminují úplně.
BM25: Algoritmus pro fulltextové vyhledávání podle slov. Počítá relevanci na základě toho, jak vzácná jsou hledaná slova a jak často se vyskytují v dokumentu. Klasický nástroj v rodině Lucene/Elasticsearch. V hybrid retrievalu se kombinuje s vektorovým vyhledáváním.
MCP Model Context Protocol: Otevřený standard pro propojení AI agentů s externími zdroji dat a nástroji. Původně od Anthropic (listopad 2024), v prosinci 2025 darován Linux Foundation jako součást Agentic AI Foundation (s podporou Anthropic, OpenAI, Block, AWS, Google, Microsoft, Cloudflare). V kontextu Agentic RAG je MCP standardizovaný způsob, jak agent volá retrieval z různých zdrojů.
Leiden algorithm: Algoritmus pro detekci komunit v grafech. V GraphRAG architektuře se používá k nalezení úzce propojených skupin entit. Nástupce starší Louvain methody, s lepšími garancemi na kvalitu detekovaných komunit.

Revize a upřesnění

Ověření faktů a revize

Tato sekce shromažďuje opravy, upřesnění a aktualizace, které se v textu objeví po publikaci. Tento článek byl napsán s důkladnou kontrolou aktuálního stavu k 20. květnu 2026. AI svět se mění rychle. Pokud najdete chybu, zastaralý údaj nebo máte k některému tvrzení připomínku, napište mi na LinkedIn.

Květen 2026 · stav po publikaci

Klíčové zdroje použité v článku: Contextual Retrieval, Anthropic engineering blog (září 2024), původní benchmarky a metodologie. GraphRAG, Edge et al. „From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (Microsoft Research, 2024) a open-source repozitář microsoft/graphrag. Self-RAG, Asai et al. „Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection" (2023). CAG, Chan et al. „Don't Do RAG: When Cache-Augmented Generation is All You Need" (2024) a navazující průmyslové studie. Lost in the Middle, Liu et al. (Stanford), TACL 2024. Konkrétní čísla u Contextual Retrieval (35/49/67 %) jsou z původního Anthropic postu. Tento článek zatím neobsahuje opravy.