RAG v praxi, kde to selhává a co s tím

Krátké uvození #

V první části jsem RAG vysvětlil přes knihovníka který hledá relevantní knihy. V druhé části jsme rozebrali jak ten knihovník technicky pracuje, tedy embedding model, vektorová databáze, chunkování, hybrid retrieval. V této části se podíváme na situace kdy ten knihovník vám donese hodnověrně vypadající nesmysly. A co se s tím dá dělat.

Není to seznam stížností. Je to mapa míst kde naivně postavený RAG dnes láme, kde je potřeba si dát pozor, a kam směřuje vývoj.

Embedding nehledá závěr, hledá podobnost slov #

Začnu vlastním pojmenováním problému který je v RAG nejhlubší a kupodivu se o něm píše nejmíň: drift k hodnověrnému nesmyslu.

Embedding model je geniální v tom že umí najít text který je významově podobný otázce. Není ale geniální v tom co znamená „významově podobný". Pro embedding je to lexikální a tematická blízkost, ne logická ekvivalence závěru.

Konkrétní příklad z právního kontextu. Uživatel se zeptá: „Jaké jsou důvody kdy nemusíme platit pokutu?"

V databázi jsou dva relevantní chunky:

Chunk A: „Smluvní pokuta se uplatní za prodlení s dodáním, kterému je možno předejít včasným uplatněním pojistné události."

Chunk B: „Pokuta neplatí v případě vyšší moci, stávky, válečného stavu, či blokády dodavatelských řetězců."

Embedding modely najdou chunk A jako bližší. Důvod: obsahuje slova „pokuta", „prodlení", „uplatní", a tematicky se točí kolem stejných pojmů jako otázka. Sémantická podobnost je vysoká.

Ale odpověď na otázku je v chunku B. Chunk A vede uživatele k závěru „musíte platit", zatímco chunk B říká „nemusíte platit když...". Závěry jdou opačnými směry.

LLM dostane chunk A, postaví na něm odpověď. Odpověď bude plynulá, gramaticky správná, profesionálně vypadající, a nesprávná. Uživatel to nepozná.

Hlavní myšlenka textu je vyústění popisu, ne klíčová slova popisu. A naivně postavený RAG tohle nevidí.

Co s tím v praxi

Reranking. Po hybrid retrievalu se pošle top 50 chunků přes specializovaný reranking model (Cohere Rerank, BGE Reranker) který je seřadí znovu s ohledem na otázku, ne jen na podobnost. Reranking modely jsou trénované konkrétně na úloze „je tento chunk skutečnou odpovědí na tuto otázku, nebo jen tematicky souvisí". Zlepšuje to retrieval výrazně, ale není to spasitelné.

Druhá vrstva: explicitní citation enforcement v generation fázi. LLM dostane instrukci „každou větu odpovědi musíš podložit konkrétním chunkem, jinak ji nepiš". Tím se omezí dolepování si faktů z paměti LLM. Stále to ale neřeší případ kdy je dolepený chunk věcně špatně.

Třetí vrstva, dnes spíš experimentální: entailment-aware embeddings. Embeddings které jsou trénované konkrétně na úloze logického vyústění, tedy rozumět tomu jestli text X tvrdí Y, nebo Y zpochybňuje. Není to standardní technologie, ale výzkum tam směřuje.

Chunkování láme myšlenku #

Druhý problém který naivně postavený RAG nevidí: chunkovací strategie rozhoduje o tom kde se myšlenka rozkrojí. A pokud se rozkrojí na hraně, výsledek je výrazně méně užitečný než celek.

Klasický příklad. Smluvní klauzule:

Článek 12.3: Smluvní strany se dohodly, že v případě prodlení s plněním povinnosti stanovené v článku 8.2 této smlouvy bude poskytovatel oprávněn účtovat smluvní pokutu ve výši 0,05 % z hodnoty plnění za každý den prodlení, ledaže by prodlení bylo způsobeno okolnostmi vylučujícími odpovědnost ve smyslu článku 14.5.

Jedna myšlenka. Čtyři odkazy (článek 12.3, 8.2, 14.5, definice prodlení). Smysl klauzule závisí na všech čtyřech.

Když fixed-size chunkování s velikostí 200 tokenů přeřízne tenhle text mezi „...0,05 % z hodnoty plnění za každý den prodlení..." a „...ledaže by prodlení bylo způsobeno...", systém vrátí jen první půlku. Uživatel se zeptá „můžu účtovat pokutu", odpověď bude „ano, 0,05 % za den". Bez ohledu na to že druhá část říká „pokud nejde o force majeure".

To není teoretický problém. To je běžné chování produkčních RAG systémů které někdo postavil podle základního tutoriálu. V e-commerce je to nepříjemné. V právu, medicíně, financích je to nebezpečné.

Paradox metadat

S problémem chunkování souvisí druhý paradox který stojí za pojmenování. Čím menší je chunk, tím méně kontextu obsahuje sám o sobě. A tím větší metadata musí mít aby byl v retrievalu užitečný.

Vezměte si chunk o 200 tokenech ze smlouvy:

„...lhůta činí 30 dní ode dne doručení. Po jejím marném uplynutí má druhá smluvní strana právo od smlouvy odstoupit a požadovat náhradu škody včetně ušlého zisku..."

Bez kontextu je tohle nepoužitelné. Lhůta čeho? Které smlouvy? S kým? Ke kterému plnění? V jaké jurisdikci? Která verze zákona se na to vztahuje?

Aby byl tenhle chunk v RAG užitečný, musí mít metadata která tyhle informace doplňují. A těch je hodně:

• ID dokumentu, název, typ (smlouva o dílo, dodatek)
• Klient, smluvní strany, jejich role
• Datum podpisu, datum účinnosti, datum poslední revize
• Strukturální umístění (článek 12.3, navazuje na 12.2 a 12.4)
• Aplikovatelný zákon a jeho verze platná k datu
• Typ klauzule (sankce, výpovědní lhůta, garance)
• Riziková kategorie
• Reference na související dokumenty (dodatky, korespondence)

U chunku o 200 tokenech mohou tyhle metadata reálně převyšovat obsah v počtu znaků. Paralela s webem: moderní stránky mají často víc metadat (Open Graph, JSON-LD, schema.org) než vlastního obsahu. Důvod je stejný, machine-readable kontext rozhoduje o použitelnosti.

V RAG to znamená že kvalita systému nezávisí jen na embedding modelu, ale možná hlavně na bohatství a přesnosti metadat. Tichá pravda která se v marketingových materiálech moc neopakuje.

Co s tím v praxi

Hierarchické chunkování. Nedělají se chunky jedné velikosti, ale tří úrovní současně:

• Document level, metadata o celém dokumentu (strany, datum, typ)
• Section level, větší chunky podle struktury (článek smlouvy, kapitola manuálu)
• Atomic level, malé chunky pro přesný retrieval (věty, odstavce)

Při retrievalu se najdou atomické chunky, ale do LLM se posílají i s kontextem ze section a document úrovně. Tomu se v některých knihovnách říká „parent document retrieval".

Druhý přístup, contextual retrieval od Anthropic. Před uložením 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". Tenhle kontext se přidá k chunku před vygenerováním embeddingu. Vektor pak reprezentuje chunk plus jeho kontext, ne jen izolovaný text. Anthropic naměřil že to snižuje retrieval failure rate o 35-50 %2. Cena: každý chunk se musí jednou prohnat LLM při indexaci.

Temporal validity, když rok mění význam #

Třetí problém je v doménách které pracují s pravidly a předpisy nejtěžší: čas.

V právu, regulaci, daních, medicíně, všude tam má text vlastní časovou platnost. A k tomu časovou platnost mají i pravidla která ten text interpretují. Klasický RAG tohle neumí.

Konkrétní příklad: GDPR. Před květnem 2018 a po květnu 2018 je svět jiný. Smlouva o zpracování osobních údajů z 2017 a z 2019 může obsahovat stejnou klauzuli, ale její právní váha je úplně jiná.

Uživatel se zeptá v roce 2026: „Je v této smlouvě dostatečně řešené zpracování osobních údajů?"

Naivní RAG najde chunk: „Smluvní strany se zavazují chránit osobní údaje druhé strany v souladu s platnými právními předpisy." LLM odpoví: „Ano, smlouva odkazuje na platné předpisy, ochrana je řešená."

Špatně. Pokud je smlouva z 2016 (před GDPR), tahle formulace v té době stačila. Pokud je z 2019, byla absolutně nedostatečná, GDPR vyžaduje konkrétní výčet zpracování, právních titulů, doby uchování, kontaktních osob. Klauzule „v souladu s platnými předpisy" v 2019 znamená že smlouva GDPR vůbec neřeší.

Pro správnou odpověď musí systém znát čtyři časové osy najednou:

1. Kdy byla smlouva uzavřena (datum dokumentu)
2. Kdy nastala událost o které se ptáme (může být dnes, může být v minulosti)
3. Kdy se ptáme (dnes, ale s pohledem do minulosti nebo budoucnosti?)
4. Kdy bude rozhodováno (pokud spor poběží 2 roky a zákon se mezitím změní, soud rozhoduje podle čeho?)

To není problém embedding modelu. To není problém chunkování. To je problém architektury celého systému.

Co s tím v praxi

Oddělené vrstvy s versioningem. V dobře postaveném legaltech RAG existují tři vrstvy:

• Chunk layer (vektory), text klauzulí, definic, ustanovení. Mění se pouze když přibude nový dokument.
• Entity layer (strukturovaná databáze), dokumenty, klienti, osoby, vztahy. Strukturovaná data.
• Ontology layer (knowledge graph), zákony, paragrafy, judikatura, s versioningem. § 12 zákona X verze A platí od ledna 2018 do června 2020, verze B od července 2020 dál.

Klíč je v tom že chunky neobsahují „platí GDPR". Obsahují odkaz na entitu „GDPR" v ontology layer. A ta entita má verze.

Když uživatel položí otázku, systém:

1. Najde relevantní chunky
2. Zjistí jaké entity z ontology na ně navazují
3. Zjistí datum dokumentu
4. Vybere verzi entity platnou k tomu datu
5. Vrátí odpověď s explicitním kontextem („smlouva byla uzavřena 15.3.2019, kdy platila GDPR ve verzi v1")

Když se v roce 2027 změní GDPR na v2, chunky se nemění. Embeddings se nemění. Pouze v ontology layer přibyde nová verze entity s datem účinnosti. Odpovědi na nové dotazy reflektují nový stav automaticky.

To je správný přístup. V realitě dnes většina legaltech systémů tuhle architekturu nemá. Buď ignorují temporal úplně, nebo cpou zákony do stejné vektorové databáze jako smlouvy (a embedding model je míchá), nebo přidávají datum jako metadata k chunku (a při změně zákona musí přepočítat všechny chunky). Žádné z toho nefunguje dobře.

Ingestion pipeline jako skrytý zabiják #

Teď přicházíme k tomu co je v RAG kvalitě nejkritičtější, a o čem se mluví nejmíň. RAG kvalita stojí na třech pilířích:

1. Architektura, schema, vrstvy, vztahy. Jednorázový design, dá se přepracovat.
2. Ingestion pipeline, analyzátor, chunker, extraktor metadat. Běží pro každý dokument.
3. Retrieval a generation, orchestrace, prompt engineering. Běží pro každý dotaz.

Mainstreamem se nejvíc mluví o pilíři 3 (prompty, modely, retrieval algoritmy). Méně o pilíři 1 (architektura). Téměř vůbec o pilíři 2 (ingestion). A přitom pilíř 2 rozhoduje o kvalitě celého systému.

Důvod: ingestion selhává tiše.

Pokud máte špatnou architekturu, je to vidět hned, systém vůbec nefunguje, nebo funguje extrémně špatně. Architekt to opraví.

Pokud máte špatnou retrieval logiku, je to vidět taky, uživatelé si stěžují že odpovědi jsou mimo téma. Inženýr to vyladí.

Pokud máte špatnou ingestion pipeline, systém vrací odpovědi. Hodnověrné. Profesionální. Občas pravdivé. Občas postavené na špatně rozsekaných chuncích, špatně extrahovaných metadatech, špatně klasifikovaných typech dokumentů. A uživatel to nepozná.

Každý nový dokument prošlý vadnou pipeline kontaminuje databázi. Při statisících dokumentech mluvíme o systémové kvalitě, ne o jednotlivých chybách.

Co všechno musí ingestion pipeline dělat

Pojďme si projít kroky které pipeline musí zvládnout u jednoho dokumentu:

1. Vstup a normalizace, PDF, Word, scan, fotografie z telefonu. Co s OCR chybami? „30 dní" se přečte jako „3O dní" a embedding to vidí jako úplně jiné slovo.
2. Klasifikace dokumentu, co to je? Smlouva, dodatek, faktura, korespondence? Z toho se odvíjí celý další pipeline. A hraniční případy jsou zlé. „Předjednání", je to závazný dokument nebo neformální? Liší se to podle obsahu, ne názvu.
3. Strukturální parsing, kde jsou články, oddíly, definice, podpisy. Hierarchie 12 → 12.3 → 12.3.a. Každá kancelář, každá firma píše dokumenty jinak. Žádný univerzální parser neexistuje.
4. Chunkování s respektem ke struktuře, sekat podle článků? Vět? Významových celků? Záleží na typu dokumentu, na typu otázek které lidé budou pokládat.
5. Entity extraction, strany, osoby, datumy, částky, paragrafy, odkazy. Nejednoznačnost je všude. „Strana A" je v hlavní smlouvě ABC, v dodatku už po fúzi je to ABC plus DEF. Bez kontextu celého dokumentu to nelze správně.
6. Sémantické tagging, typ klauzule, riziko, standardnost formulace. Tohle je expertní úsudek, ne technický úkol. Co je „vysoké riziko" pro jednu firmu je „běžné" pro druhou.
7. Cross-document linking, tahle smlouva je dodatkem k té, tahle faktura k té smlouvě. Vztahy jsou často implicitní. „Tímto se mění...", ale co se mění, není napsáno explicitně.
8. Temporal grounding, datum dokumentu, účinnost, aplikovatelná verze zákona. Účinnost se musí často spočítat ze samotného textu („30 dní od podpisu").

Každý z těch kroků je samostatný problém. Žádný univerzální nástroj na to neexistuje. A tohle všechno musí běžet automaticky, spolehlivě, bez dohledu, pro statisíce dokumentů.

Proč to nemůže dělat člověk

Někdo by řekl: tak ať to dělá člověk. Při advokátní kanceláři ať to anotuje právník, při bance kontrolor, při zdravotnictví lékař.

Pojďme si to spočítat. Advokátní kancelář s 200 000 dokumenty. Pečlivá anotace jednoho dokumentu: klasifikace, struktura, entity, sémantické tagy, propojení, zhruba 45 až 80 minut. Brát průměr 60 minut.

200 000 dokumentů × 60 minut = 200 000 hodin.

To je 100 let plné práce jednoho právníka. Při 100 právnících je to 1 rok plně placené anotace. Cena při průměrné mzdě seniorního právníka řádově 300+ milionů Kč za první kolo. A když přijde nový dokument, koluje znovu. Když se změní zákon, část se musí přepracovat.

Tohle je ekonomicky nemožné. Pipeline tedy musí být automatizovaná. Ale automatika dělá chyby. A chyby se replikují na statisíce dokumentů.

V praxi se používá human-in-the-loop:

• Confidence scoring, pipeline u každého extrahovaného metadata uvádí jak si je jistá. Vysoká jistota → automaticky. Střední → flag pro rychlé schválení. Nízká → manuální review.
• Sampling review, pipeline zpracuje 10 000 dokumentů, náhodný vzorek 100 jde k expertovi. Pokud chybovost pod prahem, pipeline se schvaluje pro další várku.
• Tiered processing, důležité dokumenty (klíčové smlouvy, velcí klienti) přes vyšší úroveň zpracování plus manual review. Marginální dokumenty automaticky s minimem.
• Feedback loop, když uživatel dostane špatnou odpověď a opraví ji, oprava se použije k re-ingestion. Kvalita se časem zlepšuje na nejpoužívanějších dokumentech.

Žádná z těchto strategií není perfektní. Všechny jsou kompromis. A všechny si vyžadují investici do procesu, ne jen do technologie.

RAG je nepřenositelný #

Šestý problém je byznysový, ne technický. A má zásadní dopady na ekonomiku celých legaltech, fintech, healthcare AI projektů.

Předpoklad mainstreamu: postavím dobrý RAG systém pro klienta A, malými úpravami ho nasadím u klienta B, C, D. Škálování je čistá technologie.

Realita: přenese se možná 20-30 % systému. 70-80 % se musí postavit znovu pro každého klienta.

Důvody:

• Šablony dokumentů, každá firma píše smlouvy jinak. Chunker postavený na strukturu firmy A selhává u firmy B. Číslování, terminologie, struktura článků, definice, všechno jinak.
• Sémantické tagy, „standardní formulace" definuje každá kancelář jinak. Co je u jedné standard je u druhé ad-hoc. Tagy nepřenosné.
• Interní zkratky a názvosloví, „NDA" je u jedné firmy mlčenlivost, u druhé non-disclosure agreement. Klient ABC u jedné firmy je možná klient XYZ u jiné. Cross-document linking se staví znovu.
• Specializované oblasti, M&A vs. rodinné právo vs. trestní mají úplně jiné ontologie a typy klauzulí.
• Rozhodovací prahy, „vysoké riziko" pro jednu firmu je „běžné" pro druhou. Záleží na klientele a typu byznysu.
• Workflow integrace, jak experti pracují, jaké mají interní systémy, co očekávají na výstupu.

Co se přenese: obecná architektura, embedding modely, vektorová databáze jako infrastruktura, retrieval algoritmus, prompt patterns. To je 20-30 %.

Co se nepřenese: doménová znalost, ontologie, sémantické tagy, šablony, vztahy mezi dokumenty, prahy rozhodování. To je 70-80 %.

Důsledky:

• Žádný „out of the box" legaltech RAG produkt nikdy nebude masově dostupný
• Velké advokátní kanceláře staví vlastní řešení místo aby kupovaly hotová (Havel & Partners s WAIR je příklad)
• Komerční legaltech firmy (Harvey AI, Casetext3, LexisNexis) musí dělat individuální onboarding pro každého velkého klienta, drahý, dlouhý
• Cena nasazení neškáluje s počtem klientů lineárně

To je důvod proč je dnes legaltech AI tak drahý. Ne kvůli technologii. Kvůli nepřenositelnosti znalostního obsahu.

Long context není záchrana #

Sedmý problém, a ten je relativně mladý, vychází z toho jak dnes mainstream interpretuje „Claude má 200 tisíc tokenů, takže můžu poslat celé stovky stránek najednou".

Marketingová čísla říkají: Claude Sonnet 4.6 má 200 000 tokenů1, GPT-4 Turbo 128 000, Gemini 1.5 Pro až 2 miliony. Z toho někdo dělá závěr: proč vůbec dělat RAG? Pošlu LLM celý dokument a hotovo.

V určitých případech to funguje. V mnoha ne.

Effective context length je výrazně menší než reklamní context window. Kvalita zpracování LLM klesá s rostoucí délkou kontextu, a klesá nelineárně podle pozice informace v kontextu. Tomu se říká Lost in the Middle: modely si pamatují začátek a konec kontextu lépe než střed. Při 200 000 tokenech může být propad přesnosti ve středu 20-40 %.

Tohle není teoretická slabina. Měřeno experimentálně (Stanford NIAH testy4, NVIDIA RULER benchmark, Anthropic vlastní výzkum). Realistická „effective context length" pro náročné úkoly:

• Claude Sonnet 4.6: cca 100-120 tisíc tokenů z reklamních 200K
• GPT-4 Turbo: cca 60-80 tisíc tokenů z reklamních 128K
• Gemini 1.5 Pro: cca 200-300 tisíc tokenů z reklamních 1-2M

Tohle není pevná hranice, je to postupná degradace kvality. A degradace se těžko detekuje, protože LLM produkuje hodnověrné odpovědi i z neúplně zpracovaného kontextu. Stejný princip jako u špatného chunkování: drift k hodnověrnému nesmyslu.

Tomuto tématu jsem věnoval samostatný nástroj a článek, kde to ukazuji prakticky: claude-limits.pprojects.cz. Je tam analyzátor Project Knowledge který spočítá kolik tokenů zabírají vaše soubory, vizualizace tří režimů ve kterých Claude odpovídá (plný, efektivní, úsporný), a článek o Lost in the Middle a Goal Drift. Pokud to téma chcete prozkoumat hlouběji než v tomto článku, je to dobrá vstupní brána.

Praktický důsledek pro RAG: přístup „pošlu LLM celý dokument" funguje pro krátké dokumenty (do cca 30-50 tisíc tokenů) a faktické dotazy. Selhává pro:

• Dokumenty nad 100 tisíc tokenů kde kvalita zpracování klesá
• Multi-needle úlohy kde se hledá víc faktů z různých částí
• Reasoning úlohy („porovnej tyto dvě klauzule v kontextu zákona")
• Případy kdy je v kontextu rozpor a model musí poznat který zdroj je důvěryhodnější

Pro náročné úkoly méně kontextu = lepší výsledek, pokud je relevantní. 30 tisíc tokenů relevantního obsahu funguje lépe než 150 tisíc tokenů smíchaného.

Late-stage context injection #

Tady přicházíme k poslednímu vhledu, který je vlastně návrh řešení pro mnoho předchozích problémů. Pojmenování si dovolím použít vlastní: RAG jako navigátor, ne odpověď.

Mainstream RAG funguje takto:

1. Vyhledá se 5-10 chunků
2. Strčí se do promptu
3. LLM odpoví na základě chunků

Co je špatně? LLM dostává izolované výseky bez kontextu. Pro faktické dotazy („kdy končí platnost smlouvy 2019/047?") to funguje. Pro analytické dotazy („jak může klient bránit obvinění z porušení mlčenlivosti?") to selhává, LLM nemá plný kontext smlouvy, zákona, dodatků, judikatury. Buď odpoví neúplně, nebo si dolepí z paměti.

Alternativa: late-stage context injection.

1. Vyhledá se v různých zdrojích (vektor plus struktura plus zákon)
2. Vyhodnotí se relevance scoring: které dokumenty/zákony jsou skutečně klíčové pro tuhle otázku?
3. Pro klíčové dokumenty (kde překročily práh relevance) se nepoužijí izolované chunky, ale celé dokumenty
4. Do LLM kontextu jde: plné dokumenty plus relevantní paragrafy zákonů plus dodatky plus judikatura
5. LLM dostane plný kontext jako právník a může odpovídat z plné šíře

RAG už není zdrojem odpovědi. Je to routing layer, nástroj na to aby se vybralo CO patří do plného kontextu pro LLM.

Ekonomická obhajoba. Tohle je dražší než klasický RAG. Mnohem dražší. Místo 3000 tokenů v kontextu LLM mluvíme o 15-20 tisících. Při ceně Claude Sonnet 4.6 (cca 3 dolary za milion vstupních tokenů) je rozdíl mezi 20 haléři a 1,20 korunami na dotaz.

V e-commerce kde dotaz musí stát milihaléř to nedává smysl. V právu, medicíně, financích, kde hodina experta stojí tisíce korun, je to obrovský win. Pokud drahý dotaz uspoří expertovi 30 minut práce, je to návratnost řádu 1000x.

V praxi se používá hybridní router:

• Faktické dotazy („kdy končí platnost", „jaká je sankční částka") → klasický RAG s chunky
• Analytické dotazy („jak bránit obvinění", „porovnej tyto klauzule", „jaká jsou rizika") → late-stage context injection s plnými dokumenty

LLM na začátku rozhodne kudy dotaz pošle. To je elegantní řešení které kombinuje rychlost klasického RAG s přesností full context přístupu.

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

Otevřené otázky #

Tohle byl pohled na to kde RAG dnes selhává. Něco z toho má v praxi řešení (reranking, hierarchické chunkování, contextual retrieval, hybrid routing). Něco z toho je předmětem aktivního výzkumu (entailment-aware embeddings, temporal-aware RAG, automatizovaná tvorba domain ontologies). A některé otázky jsou otevřené úplně:

• Kdy dnes investovat do vlastního RAG a kdy počkat na komoditní řešení od velkých hráčů (Google, Microsoft, Oracle)?
• Jaká je správná dělba práce mezi automatizovanou ingestion pipeline a human-in-the-loop?
• Jak řešit temporal validity v doménách kde se pravidla mění rychle a retroaktivně?
• Existuje cesta k přenositelnému legaltech RAG, nebo je nepřenositelnost fundamentální?
• Změní situaci AI agents kteří umí dotaz rozložit, několikrát hledat, syntetizovat, nebo to jen přidá další vrstvu chyb?