RAG a AI memory

RAG (Retrieval-Augmented Generation) je způsob, jak před odpovědí dohledat relevantní kusy dat z externí znalostní báze a teprve potom z nich nechat model generovat odpověď. V praxi je to základ chatbotů nad interní dokumentací, wiki, PDF, kódem nebo firemní knowledge base. AI memory řeší příbuzný problém: ne jen jednorázové dohledání dokumentů, ale i průběžné ukládání a znovuvybavování faktů, preferencí a pracovního kontextu mezi sezeními.

RAG dává smysl hlavně tam, kde samotný model nemá mít vše v tréninku nebo kde je potřeba pracovat s aktuálními interními daty. Typický pipeline vypadá takto:

• dokumenty se rozdělí na chunky
• nad chunky se vytvoří index pro retrieval
• při dotazu se vyberou relevantní pasáže
• ty se vloží do promptu modelu jako kontext
• model z nich vygeneruje odpověď

To zní jednoduše, ale kvalita stojí hlavně na retrieval vrstvě. Slabý chunking, špatný embedding model, chybějící metadata nebo nekvalitní reranking dokážou zkazit výstup i tehdy, když je samotný LLM dobrý.

Stanford paper ''Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools'' neřeší obecnou „smrt všech RAG produktů po 10 000 dokumentech“. Studie testuje právní AI nástroje nad proprietárními RAG pipeline a ukazuje hlavně to, že marketingové tvrzení o „hallucination-free“ provozu je přehnané.

Autoři zjistili zejména:

• Lexis+ AI a Ask Practical Law AI halucinují ve zhruba 17–24 % odpovědí
• Westlaw AI-Assisted Research halucinoval zhruba v jedné třetině odpovědí
• proti běžnému GPT-4 jde sice o zlepšení, ale ne o eliminaci problému
• v právu nestačí čistá textová podobnost; relevance závisí i na jurisdikci, čase, typu autority a dalších netextových znacích

Důležitá poznámka: tento paper neobsahuje tvrzení o semantic collapse, prahu 10 000 dokumentů, poklesu precision o 87 % na 50 000 dokumentech ani tvrzení, že semantické vyhledávání je obecně horší než keyword search. To jsou agresivní interpretace, které se kolem studie začaly šířit, ale v samotném zdroji takto nejsou.

To, že výše uvedená čísla nejsou ze Stanford paperu, neznamená, že problém škálování retrievalu neexistuje. DeepMind paper ''On the Theoretical Limitations of Embedding-Based Retrieval'' ukazuje, že single-vector embedding retrieval má fundamentální omezení: počet kombinací relevantních dokumentů, které lze reprezentovat, je omezený dimenzí embeddingu. Jinými slovy, čistý dense retrieval nemůže donekonečna růst bez ztráty vyjadřovací síly.

To je dobrý rámec pro čtení pojmu semantic collapse: nejde o univerzální magickou hranici, po které se každý RAG zlomí, ale o praktický projev toho, že:

• podobnost v embedding prostoru není totéž co relevance pro konkrétní úlohu
• s rostoucím korpusem přibývá více „skoro podobných“ kandidátů
• exact-match dotazy, identifikátory, citace, čísla verzí nebo modelová označení se čistě dense retrievalem často hledají špatně
• bez dodatečných filtrů a rerankingu může model dostávat směs částečně relevantních a rušivých chunků

Anthropic v článku o Contextual Retrieval popisuje několik praktických mitigací, které v reálném RAG pipeline dělají velký rozdíl:

• hybrid search – kombinace embedding retrievalu a BM25 / lexical search
• contextual chunking / contextual embeddings – chunk se před indexací doplní o krátký kontext z celého dokumentu
• reranking – nejdřív se vytáhne širší kandidátní sada a teprve potom se top-N výsledky znovu přeskórují přes přesnější model
• experimentování s top-K – více chunků může pomoct, ale příliš mnoho kontextu začne model spíš rušit

Anthropic ve stejné studii uvádí, že kombinace contextual embeddings a contextual BM25 snížila failure rate retrievalu o 49 % a po přidání rerankingu o 67 %. To je dobrá připomínka, že „RAG“ není jedna technika, ale celý stack rozhodnutí.

Stanford paper k tomu z jiné strany doplňuje, že v některých doménách je potřeba retrieval opřít i o metadata filtering. V právu je to typicky jurisdikce, datum, hierarchie autority nebo typ dokumentu. V jiných doménách to může být projekt, zákazník, verze produktu, jazyk, zdrojový systém nebo časové období.

Microsoft GraphRAG míří na situace, kdy nestačí vytáhnout pár nejpodobnějších chunků, ale je potřeba propojit více roztroušených faktů napříč korpusem nebo odpovídat na otázky nad celým datasetem. Typické scénáře:

• dotaz vyžaduje multi-hop reasoning přes více entit a vztahů
• je potřeba chápat témata nebo komunity v celém datasetu, ne jen podobné pasáže
• klasický vector search „neumí spojit tečky“

GraphRAG je ale těžší na ingest, extrakci entit a provoz. Pro běžnou interní dokumentaci často stačí dobře udělaný hybridní RAG s metadata filtry a rerankingem.

Anthropic zároveň upozorňuje na jednoduchý, ale často přehlížený bod: pokud je znalostní báze malá, může být jednodušší neposílat model do retrieval pipeline vůbec a dát mu celý kontext přímo do promptu. V článku zmiňují hranici do zhruba 200 000 tokenů jako situaci, kde může být prostý dlouhý kontext praktičtější než složitý RAG stack.

To je dobré pravidlo proti přeinženýrování. Ne každá knowledge base potřebuje vector DB, embeddings, reranker a GraphRAG.

RAG a AI memory se často pletou, ale řeší trochu jiný problém:

• RAG – dohledává externí dokumenty nebo jejich části pro aktuální odpověď
• AI memory – ukládá a znovu vybavuje informace napříč sezeními, typicky o uživateli, úkolech, preferencích nebo dříve zjištěných faktech

V praxi se obě vrstvy často kombinují:

• dokumentace, wiki a PDF jdou přes RAG
• preference uživatele, pracovní stav a dlouhodobé poznámky jdou přes memory vrstvu

Právě proto má smysl mít v této sekci vedle sebe nástroje jako Chroma, LlamaIndex Cloud a LlamaParse nebo Cognee.

Níže je ilustrační přepis přiloženého obrázku. Ber ho jako vizuální zkratku pro diskusi o škálování retrievalu, ne jako graf převzatý přímo ze Stanford paperu.

Pokud se RAG s větší knowledge base „zhoršuje“, obvykle to není argument proti RAG jako takovému. Spíš to znamená, že už nestačí základní dense retrieval bez dalších vrstev. Prakticky dává smysl zkontrolovat hlavně:

• jestli nechybí hybrid search
• jestli jsou chunky dostatečně kontextové a nejsou mechanicky krátké
• jestli retrieval používá metadata a filtry relevantní pro doménu
• jestli nad kandidáty běží reranking
• jestli by pro daný objem dat nebyl jednodušší velký kontext bez RAG
• jestli už problém není spíš o knowledge graphu nebo memory vrstvě než o klasickém vector search

• Anthropic – Introducing Contextual Retrieval
• Stanford – Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools
• DeepMind – On the Theoretical Limitations of Embedding-Based Retrieval
• Microsoft Research – GraphRAG