RAG v produkci: infrastruktura, bezpečnost dat a proč chatbot odpovídá špatně

Kde se odpověď ztrácí: sedm míst selhání

RAG (retrieval-augmented generation) vypadá jednoduše: dokumenty se rozdělí na části, převedou na vektory, k dotazu se dohledají nejpodobnější části a model z nich složí odpověď. V produkci se ale odpověď může ztratit na několika místech a každé vyžaduje jinou opravu.

Dobrou mapu nabízí studie Seven Failure Points When Engineering a Retrieval Augmented Generation System (Barnett a kol., leden 2024), která vychází ze tří případových studií z výzkumu, vzdělávání a biomedicíny. Popisuje sedm bodů selhání:

První tři body jsou čistě věc dat a vyhledávání. Výměna jazykového modelu za novější s nimi nic neudělá. Autoři studie navíc docházejí ke dvěma závěrům, které se vyplatí brát jako výchozí předpoklad: validace RAG systému je proveditelná až za provozu a jeho robustnost se nedá navrhnout předem, ale vyvíjí se postupně.

Vyhledávání: hybrid, reranking a chunking

Čistě vektorové vyhledávání dobře zachytí význam, ale selhává na přesných řetězcích – čísle smlouvy, kódu produktu, zkratce interního systému. Fulltext (BM25) to má opačně. Hybridní vyhledávání pouští oba dotazy paralelně a výsledky slučuje. Azure AI Search k tomu používá Reciprocal Rank Fusion: každý dokument dostane za umístění v každém seznamu skóre 1/(pořadí + k) a skóre se sečtou; podle dokumentace algoritmus funguje nejlépe s malou hodnotou k, například 60.

Jak velký rozdíl jednotlivé vrstvy dělají, změřil Anthropic v textu o Contextual Retrieval (září 2024). Metrikou byl podíl dotazů, u nichž se relevantní část nedostala mezi 20 nejlepších chunků:

• embeddingy doplněné o kontext dokumentu: pokles z 5,7 % na 3,7 % (o 35 %),
• po přidání kontextového BM25: pokles na 2,9 % (o 49 %),
• po přidání rerankingu: pokles na 1,9 % (o 67 %).

Jde o měření dodavatele na jeho vlastních datových sadách, takže absolutní čísla na vašich dokumentech vyjdou jinak. Pořadí kroků je ale obecně použitelné: nejdřív hybrid, potom reranking, a teprve pak ladění modelu.

Chunking není detail

Zmíněná studie o sedmi bodech selhání upozorňuje, že chunking zní triviálně, ale jeho kvalita ovlivňuje embeddingy a tím i shodu chunků s dotazy. Typický problém: odstavec vytržený ze směrnice neříká, které směrnice, které verze a které pobočky se týká. Contextual Retrieval to řeší tak, že ke každému chunku před indexací doplní krátký popis jeho místa v dokumentu.

Agentic RAG

Složené otázky („porovnej podmínky dvou smluv“) jedním dotazem do indexu nepokryjete. Agentic přístup dotaz rozloží na dílčí, pustí je paralelně a výsledky sloučí. V Azure AI Search je agentic retrieval podle dokumentace aktualizované v září 2026 obecně dostupný v REST API verze 2026-04-01, zatímco plánování dotazů pomocí LLM a syntéza odpovědí zůstávají v preview. Počítejte s vyšší latencí a cenou za dotaz – každý poddotaz se zvlášť rerankuje – a s tím, že se další volání LLM stává součástí řetězce, který musíte měřit.

Vektorová databáze, pgvector, nebo managed služba

Výběr úložiště se často řeší jako první, přitom na kvalitu odpovědí má menší vliv než chunking a reranking. Rozhodují spíš provozní kritéria: kdo to bude provozovat, jak se filtruje podle oprávnění a zda úložiště umí hybridní vyhledávání.

Údaje o pgvector vycházejí z dokumentace projektu. U Bedrock Knowledge Bases dokumentace AWS uvádí jako podporovaná úložiště OpenSearch Serverless, spravované clustery OpenSearch Service, S3 Vectors, Auroru s pgvector, Neptune Analytics, Pinecone, Redis Enterprise Cloud a MongoDB Atlas. Hybridní vyhledávání je ovšem podle téže dokumentace podporované jen pro Amazon RDS, OpenSearch Serverless a MongoDB s filtrovatelným textovým polem; jinde dotaz tiše spadne na čistě sémantické vyhledávání. Ve výchozím stavu služba vrací nejvýše pět chunků.

Protiargument k „vezměte pgvector“: jakmile potřebujete kvalitní fulltext v češtině, fúzi výsledků a reranking, píšete a udržujete kus vyhledávače sami. Pokud tým nemá kapacitu, vyjde managed služba levněji i přes vyšší cenu za provoz.

Bezpečnost dat: oprávnění se musí vynutit při vyhledávání

Nejčastější bezpečnostní chyba RAG není exotický útok, ale to, že index má širší oprávnění než uživatel, který se ptá. Ingestion běží pod servisním účtem, který čte všechno, a chatbot pak ochotně shrne mzdové podklady komukoli. OWASP to v LLM08:2025 Vector and Embedding Weaknesses řadí mezi hlavní rizika: neoprávněný přístup a únik dat, průsaky mezi kontexty ve sdílené vektorové databázi, inverzi embeddingů a otravu dat. Jako obranu uvádí jemné řízení přístupu s logickým oddělením datových sad, ověřování zdrojů, klasifikaci dat a neměnné logy vyhledávání.

Zásada je jednoduchá: filtr oprávnění patří do dotazu na index, nikoli do promptu. Instrukce „neprozrazuj důvěrné dokumenty“ není bezpečnostní kontrola. Co se do kontextu modelu nedostane, to model nevyzradí.

V Azure AI Search je obecně dostupný vzor security filter: ke každému dokumentu se při indexaci uloží identifikátory skupin a aplikace je přidá do filtru dotazu.

POST /indexes/securedfiles/docs/search?api-version=2026-04-01
{
  "search": "podmínky výpovědi smlouvy",
  "filter": "group_ids/any(g:search.in(g, 'group_id1, group_id2'))"
}

Dokumentace výslovně říká, že v tomto vzoru je identita jen řetězec ve filtru – žádná autentizace ani autorizace na straně služby neprobíhá. Za správné sestavení filtru tedy ručí vaše aplikace. Varianty, kdy služba porovnává token uživatele s oprávněními převzatými ze zdroje (ACL a RBAC u ADLS Gen2, ACL ze SharePointu, štítky citlivosti Microsoft Purview), jsou podle přehledu řízení přístupu k září 2026 stále v preview.

Nepřímá prompt injection: dokument jako útočný vektor

RAG z principu vkládá do kontextu modelu text, který nepsal ani uživatel, ani vývojář. OWASP LLM01:2025 to popisuje jako nepřímou prompt injection: model přijme vstup z externího zdroje a obsah v něm změní jeho chování. OWASP zároveň uvádí, že RAG ani fine-tuning tuto zranitelnost plně neodstraňují.

Že nejde o teorii, ukázal EchoLeak. Zranitelnost CVE-2025-32711, zveřejněná 11. června 2025, je v databázi NVD popsaná jako AI command injection v M365 Copilot, která neoprávněnému útočníkovi umožňuje vyzradit informace po síti. Microsoft jí přidělil skóre CVSS 9,3 (kritická), NIST 7,5. Podle analýzy publikované na arXiv (Reddy a Gujral, září 2025) stačil podvržený e-mail a žádná akce uživatele: útok zřetězil obejití klasifikátoru prompt injection, obejití redakce odkazů přes Markdown s referenčními odkazy, automaticky načítané obrázky a proxy služby Teams povolenou v content security policy.

Druhá kategorie je otrava znalostní báze. Práce PoisonedRAG (Zou a kol., přijatá na USENIX Security 2025) uvádí 90% úspěšnost útoku při vložení pěti škodlivých textů na cílovou otázku do báze s miliony textů; vyhodnocené obrany podle autorů nestačily. Jde o laboratorní výsledek, ale poučení je praktické: kdo smí zapisovat do zdrojů, které indexujete, ten ovlivňuje odpovědi.

Žádné z těchto opatření samo nestačí; filtry vstupu i výstupu se v případě EchoLeak podařilo obejít. Cílem je, aby úspěšná injekce neměla k čemu se dostat a kudy data vynést.

Ingestion jako pipeline, evaluace jako test

Ingestion je build. Má vstupy (dokumenty, verze parseru, strategie chunkingu, embedding model), výstup (index) a má být reprodukovatelný. Platí pro něj stejná pravidla jako pro jakoukoli jinou CI/CD pipeline: konfigurace ve verzovacím systému, oddělená prostředí, kontrolovaný přístup k tajemstvím a možnost vrátit se k předchozí verzi indexu.

• Verzujte chunking a embedding model. Změna kteréhokoli z nich znamená přeindexování všeho; plánujte ji jako migraci s paralelním indexem a přepnutím.
• Řešte mazání a duplicity. Zastaralá verze směrnice v indexu je častý zdroj „špatných“ odpovědí, které jsou ve skutečnosti věrné – jen starému dokumentu.
• Ukládejte metadata. Zdroj, vlastník, datum platnosti, klasifikace a skupiny s přístupem; bez nich nejde filtrovat ani citovat.
• Kontrolujte obsah na vstupu. Skenujte tajemství a osobní údaje dřív, než se dostanou do indexu.

Evaluace: měřte vyhledávání a generování zvlášť

Bez měření nepoznáte, jestli změna chunkingu pomohla. Framework Ragas nabízí pro RAG metriky context precision a context recall (kvalita vyhledávání) a faithfulness a response relevancy (kvalita odpovědi). Faithfulness je definovaná jako podíl tvrzení v odpovědi, která jsou podložená dohledaným kontextem, na všech tvrzeních v odpovědi.

Dvě výhrady. Metriky založené na LLM samy volají model, takže nejsou deterministické a stojí peníze. A vysoká faithfulness neznamená správnou odpověď: model může věrně shrnout zastaralý nebo podvržený dokument. Proto potřebujete i sadu otázek se známými správnými odpověďmi a zdroji, sestavenou s lidmi z byznysu, a tu pouštět při každé změně pipeline jako regresní test.

V provozu logujte ke každé odpovědi dotaz, identitu uživatele, ID dohledaných chunků, verzi indexu a promptu. Je to podklad pro ladění i pro vyšetřování incidentů; víc k tématu najdete v článku o bezpečnostním monitoringu a logování. Pozor ale na to, že logy dotazů samy obsahují citlivá data a potřebují stejnou ochranu jako zdrojové dokumenty.

Co udělat v pondělí

Pokud audit ukáže, že dokumenty jsou roztroušené, bez vlastníků a bez klasifikace, začněte tam. RAG nad neuspořádanými daty jen rychleji zpřístupní nepořádek – stejný vzorec jako u infrastruktury, která není na AI připravená.

Klíčové poznatky

• Většina špatných odpovědí vzniká před modelem. Chybějící obsah, špatné pořadí výsledků a ztráta při skládání kontextu jsou problémy dat a vyhledávání.
• Hybrid a reranking jsou základ, ne nadstavba. V měření Anthropic snížily spolu s doplněním kontextu k chunkům podíl neúspěšných vyhledání z 5,7 % na 1,9 %; na vlastních datech si přínos ověřte.
• Oprávnění se vynucují v dotazu na index. Prompt není bezpečnostní kontrola a zpoždění synchronizace je bezpečnostní parametr.
• Každý indexovaný dokument je potenciální instrukce. EchoLeak ukázal zero-click únik dat z produkčního systému; braňte se oddělením zdrojů, nejmenšími oprávněními a omezením výstupu.
• Ingestion je pipeline a evaluace je test. Verzujte, měřte vyhledávání a generování zvlášť a počítejte s tím, že validace probíhá až v provozu.
• Úložiště vybírejte podle provozu. pgvector, Azure AI Search i Bedrock Knowledge Bases fungují; rozdíl je v tom, co za vás služba udělá a co je zatím jen v preview.