Jak zabránit otravě RAG dat: Provenience zdrojů, karanténa a testy reindexace

Chatbot na webu může poskytnout zdvořilou, jazykově přesvědčivou a technicky správně vygenerovanou odpověď – a přesto pracovat s otrávenou znalostní bází. Při otravě RAG dat (data poisoning) se primárně nemanipuluje s formulací jednoho dotazu. Místo toho se chybné, zkreslené nebo nedostatečně prověřené obsahy dostávají do trvalého datového řetězce: zdroj, parser, chunk, metadata, embedding a nakonec produktivní retrieval index. Chyba tak přetrvává napříč mnoha relacemi a může ovlivnit i běžné dotazy.

Účinná ochrana proto začíná dlouho před samotným promptem. Týmy musí být schopny u každého znalostního prvku odpovědět: Odkud pochází, kdo je za něj zodpovědný, jaká verze byla zpracována, jaké transformace proběhly a jakým ověřením byl schválen pro vyhledávání? Tyto stopy poskytuje provenience zdrojů. Technicky oddělená karanténa dokáže zabránit tomu, aby se neprověřené změny staly okamžitě dostupnými. Cílené testy reindexace následně prověří, zda vyčištěný obsah skutečně nahradil staré chunky.

Co je a co není otrava RAG dat

Klasifikace OWASP LLM04:2025 pro Data and Model Poisoning popisuje manipulace s daty pro předtrénování, fine-tuning nebo embedding jako riziko integrity. Pro webového chatbota je obzvláště reálná poslední varianta: Dokument je přijat a rozdělen na úseky; tyto chunky jsou převedeny na embeddingy a uloženy jako vektory v retrieval indexu. Pokud je tento dokument úmyslně nebo omylem zkreslen, může se při odpovídajících dotazech objevit jako zdánlivě relevantní podklad.

Rizika je třeba rozlišovat, i když se mohou překrývat: Prompt Injection se snaží za běhu vložit instrukce nebo data tak, aby systém změnil své zamýšlené chování; nepřímá Prompt Injection se přitom může do kontextu dostat i prostřednictvím načtených dokumentů. Otrava dat oproti tomu mění dlouhodobější znalostní fond nebo jeho deriváty. Také přístupová práva řeší jiný problém: Určují, která osoba smí dokument vidět. Provenience a schválení určují, zda má tento dokument vstoupit do indexu jako důvěryhodný zdroj znalostí. V robustní architektuře vyžadují všechna tři rizika vlastní kontrolní mechanismy a sladěné přechody.

Útočná plocha zahrnuje celý datový řetězec

Index RAG vzniká zřídka z jediné, ručně prověřené sbírky. Crawlery čtou webové stránky, konektory synchronizují cloudové složky, uživatelé nahrávají soubory a rozhraní importují produktová data. K tomu se přidávají parsery, OCR, čištění textu, chunking a obohacování metadat. Každý krok může převzít chybné obsahy nebo vytrhnout původně správné tvrzení z jeho kontextu.

Typickými příčinami jsou kompromitovaný zdrojový systém, nově propojený zrcadlový dokument, omylem publikovaný pracovní soubor, špatně přiřazený tenant nebo aktualizace parseru, která přiřadí hodnoty v tabulce nesprávným nadpisům. Porovnání kryptografického hashe obsahu s důvěryhodnou referenční hodnotou dokáže odhalit odchylky; shodný hash však nedokládá pravdivost, aktuálnost ani schválení obsahu.

Provenience jako ověřitelný datový záznam

Ke každému dokumentu a každému z něj odvozenému chunku by měl patřit záznam o provenienci. Prakticky užitečné jsou minimálně stabilní ID zdroje, kanonická URL původu, odpovědný vlastník, čas načtení, verze dokumentu, hash obsahu, stav schválení, třída důvěryhodnosti, verze parseru, verze chunkingu, model embeddingu a generace indexu. U ručních nahrávání se přidává role nahrávající osoby a prověřená licence. U synchronizovaných systémů je navíc důležité, přes který autentizovaný konektor soubor přišel.

NIST AI 600-1 Generative AI Profile považuje provenienci obsahu (Content Provenance), dohledatelnou dokumentaci a testování s evaluacemi za klíčové prvky řízení rizik generativní AI. Převedeno na systémy RAG to znamená: Záleží nejen na aktuálním indexu. Do provozní dokumentace patří také dohledatelný vztah mezi revizí zdroje, během zpracování a publikovanou generací indexu.

Karanténa odděluje příjem a publikaci

Ústředním architektonickým prvkem je důsledné oddělení: Nové nebo změněné obsahy nejsou okamžitě vyhledatelné. Nejprve skončí v přijímací zóně. Tam datová pipeline validuje původ, typ souboru, velikost, podpis nebo očekávaný hash, povoleného tenanta, úplnost metadat a rozsah změn. Teprve potom se vygenerují text a chunky v neprodukční generaci indexu.

Pravidla by měla být založena na řízení rizik. Změna na autentizované interní stránce FAQ s určenou odpovědností může být schválena po automatických testech. Nová doména, neobvykle rozsáhlá změna textu, neznámý vlastník souboru nebo zdroj bez odpovědné osoby naopak spouštějí karanténu a ruční kontrolu. Pokud chybí povinná informace, platí zásada „fail closed“: Stará, potvrzená generace zůstává aktivní; nový stav se tiše nepublikuje.

Schválení jako neměnná generace indexu

Po kontrole se produktivní index nepřepisuje postupně. Lepší je nová, verzovaná generace s manifestem: očekávané dokumenty, očekávané chunky, hashe zdrojů, verze transformací a časová razítka. Teprve když jsou testy úspěšné (zelené), alias nebo konfigurace směrování se atomicky přepne na tuto generaci. Předchozí generace zůstává po omezenou, definovanou dobu k dispozici pro případný rollback.

Postup se podobá řízené migraci. Náš článek o změně modelu RAG embeddingu ukazuje, proč jsou paralelní generace indexu a srovnávací testy užitečné i při technických změnách. Při podezření na otravu se navíc přidává bezpečnostní otázka: Která revize zdroje a které odvozené chunky musí být zablokovány?

Fiktivní scénář: Nesprávná lhůta pro vrácení zboží se dostane k chatbotu podpory

Předpokládejme, že prodejce provozuje chatbota pro dotazy k produktům a službám. Znalostní báze každou noc synchronizuje oficiální centrum nápovědy a několik schválených portálů výrobců. Po změně odkazu však konektor následuje přesměrování na neschválenou zrcadlovou stránku. Tam je v opticky věrohodném PDF uvedena lhůta pro vrácení 90 dní místo 30 dní. Soubor je rozdělen na chunky; několik úseků skončí s vysokou sémantickou podobností v indexu.

Následující ráno bot při dotazech na vrácení zboží slibuje špatnou lhůtu. Jazykový model nebyl přeprogramován a uživatelé nezadali žádné škodlivé instrukce. Retrieval jednoduše dodal chybný podklad. Monitoring spustí alarm, protože se jako zdroj odpovědi poprvé objevuje nová doména a test sady Golden Set pro lhůtu vrácení se odchyluje od očekávaného dokladu.

Řízená karanténa a obnovení provozu

1. Tým pozastaví pouze dotčený zdroj příjmu a zmrazí aktuální generaci indexu pro další změny.
2. Podezřelé ID dokumentu, všechna z něj odvozená ID chunků a jejich výskyty v odpovědích se zaznamenají do incidentu.
3. Zrcadlová doména je zablokována a její chunky jsou přesunuty do karantény. Pro dotazy na lhůtu vrácení bot dočasně poskytuje bezpečné upozornění odkazující na lidskou podporu nebo potvrzenou stránku s pravidly.
4. Alias se vrátí na poslední prokazatelně čistou generaci indexu. Ostatní, nedotčené znalostní oblasti zůstávají dostupné.
5. Konektor se omezí pouze na kanonický zdroj. Poté pipeline vytvoří novou generaci z potvrzeného manifestu.
6. Teprve po testech reindexace a věcném schválení jde tato generace do produkce.

Tento postup minimalizuje škody, aniž by bylo nutné zbrkle vypnout celého chatbota. Rozhodující je propojení dat o původu a derivátech: Bez přiřazení dokumentu k chunkům by nebylo jasné, které vektory je nutné odstranit.

Testy reindexace musí ukázat více než jen úspěšné provedení pipeline

Zelený stav úlohy dokládá pouze to, že proces byl technicky dokončen. Nepotvrzuje ani to, že staré chunky zmizely, ani to, že správné zdroje zvítězí při reálných dotazech. Robustní testovací balíček proto prověřuje stav obsahu, retrieval i chování odpovědí.

1. Kontrola manifestu a mazání

Porovnejte novou generaci se schváleným manifestem. Každá očekávaná verze dokumentu musí být přítomna; zablokovaná ID dokumentů a chunků se nesmí vyskytovat. Zvláště důležité jsou „tombstones“ pro smazané nebo nahrazené obsahy. Pouhé připojování nových embeddingů by jinak ponechalo staré, otrávené nálezy v indexu.

2. Testy retrievalu s očekávanými zdroji

Pro kritické dotazy nestačí očekávaný text odpovědi. Definujte navíc povolená a zakázaná ID zdrojů, minimální počet nálezů a podmínky vyloučení. Lhůta pro vrácení musí pocházet například z kanonických podmínek; zrcadlová doména v karanténě se nesmí objevit ani mezi hlavními výsledky, ani v kontextu modelu. Jak takové testovací sady strukturovat, vysvětluje článek o kvalitě odpovědí s Golden Set a RAG testy.

3. Negativní a manipulační testy

V izolovaném testovacím prostředí mohou týmy vložit jednoznačně označený, neschválený testovací zdroj. Pipeline ho musí udržet v karanténě; produkční vyhledávání ho nesmí načíst. Dodatečně se testují neobvyklé změny domén, chybějící vlastníci, extrémní rozdíly v obsahu a rozporuplné údaje o datech. Zpráva NIST AI 100-2 o Adversarial Machine Learning řadí poisoning mezi kategorie útoků ve své taxonomii a zdůrazňuje, že protiopatření a jejich limity musí být posuzovány systematicky.

4. Porovnání před a po změně

Spusťte stejné dotazy proti poslední čisté a nové generaci. Porovnejte zdroje nálezů, pořadí, podklady pro odpovědi, míru neodpovězení (No-Answer-Rate) a věcné hodnocení. Malý podíl canary nasazení může poskytnout dodatečné produkční signály, pokud uživatelé nezískají přístup k neprověřeným zdrojům. K produktivnímu přepnutí dochází až po splnění stanovených bezpečnostních limitů a limitů kvality.

Monitoring: Včasné odhalení anomálií

Sledujte nejen hodnocení odpovědí. Vypovídající jsou nové nebo vzácné zdrojové domény, podíl neprověřených zdrojů v toku příjmu, neobvyklé velikosti dokumentů, výrazné rozdíly v hashi nebo textu, vysoký počet nových chunků od jednoho vlastníka, změny hlavních zdrojů v Golden Setu a odpovědi bez potvrzeného dokladu. Metriky by měly odkazovat na ID provenience, nikoli na zbytečně ukládané kompletní uživatelské dotazy.

Důležitá zůstává i aktuálnost. Stará, dávno nahrazená směrnice není otrávena úmyslně, ale může mít stejný dopad. Článek o aktuálnosti znalostních bází a Crawl-QA doplňuje bezpečnostní kontroly o kadenci, odpovědnost a postupy mazání.

Kontrolní seznam pro bezpečný příjem RAG dat

• Má každý zdroj stabilní ID, kanonický původ, odpovědnou osobu a třídu důvěryhodnosti?
• Logují se společně hash, verze dokumentu, parser, chunking a model embeddingu?
• Zůstávají nové nebo výrazně změněné zdroje až do prověření mimo produktivní vyhledávání?
• Vedou nové domény, chybějící podpisy nebo nepravděpodobné změny obsahu ke karanténě?
• Publikují se schválené indexy jako verzované generace s rollbackovatelným aliasem?
• Odstraňuje reindexace nahrazené chunky prokazatelně, místo aby pouze připojovala nová data?
• Testuje Golden Set jak odpovědi, tak očekávané a zakázané zdroje?
• Existuje bezpečný fallback pro témata, jejichž zdroje jsou během incidentu zablokovány?
• Jsou jasně odděleny role pro příjem, věcné schválení, řešení incidentů a opětovné publikování?
• Dokumentuje se po každém incidentu, která kontrola selhala a jaký regresní test byl doplněn?

Závěr

Otravu RAG dat nelze vyřešit jediným pravidlem v promptu. Ochrana vzniká z ověřitelného dodavatelského řetězce znalostí: dokumentovat původ, prověřovat změny v karanténě, verzovat indexy, bezpečně odstraňovat staré deriváty a testovat retrieval s očekávanými zdroji. Začněte u nejrizikovějších tříd dokumentů a malé sady Golden Set. Již tato kombinace zprůhlední, který zdroj podporuje konkrétní odpověď – a umožní cílený rollback dříve, než se chybný stav znalostí stane trvalým normálním stavem.

Zdroje

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations