Zabránenie otrave RAG dát: Proveniencia zdrojov, karanténa a testy reindexácie

Chatbot na webovej stránke môže poskytnúť zdvorilú, jazykovo presvedčivú a technicky správne vygenerovanú odpoveď – a napriek tomu pracovať na otrávenej znalostnej báze. Pri otrave RAG dát sa primárne nemanipuluje s formuláciou jednotlivého dopytu. Namiesto toho sa do trvalého dátového reťazca dostávajú chybné, skreslené alebo nedostatočne overené obsahy: zdroj, parser, chunk, metadáta, embedding a napokon produkčný retrieval index. Chyba tak pretrváva počas mnohých používateľských relácií a môže ovplyvniť aj bežné otázky.

Účinná ochrana sa preto začína dlho pred promptom. Tímy musia vedieť odpovedať pre každý znalostný prvok: Odkiaľ pochádza, kto je zodpovedný, ktorá verzia bola spracovaná, aké transformácie prebehli a akým overením bol schválený na vyhľadávanie? Proveniencia zdrojov poskytuje túto stopu. Technicky oddelená karanténa môže zabrániť tomu, aby boli neoverené zmeny okamžite prístupné. Cielené testy reindexácie následne preveria, či vyčistené obsahy skutočne nahradili staré chunky.

Čo je otrava RAG dát – a čo nie je

Zaradenie OWASP LLM04:2025 k Data and Model Poisoning opisuje manipulácie s dátami na predtrénovanie, fine-tuning alebo embeddingy ako riziko integrity. Pre chatbot na webovej stránke je obzvlášť hmatateľný posledný variant: Dokument sa prijme a rozdelí na úseky; tieto chunky sa prevedú na embeddingy a uložia ako vektory v retrieval indexe. Ak sa tento dokument úmyselne alebo neúmyselne skreslí, môže sa pri zodpovedajúcich otázkach objaviť ako zdanlivo relevantný základ.

Riziká je potrebné rozlišovať, hoci sa môžu prekrývať: Prompt Injection sa snaží za behu vstreknúť inštrukcie alebo dáta tak, aby systém zmenil svoje zamýšľané správanie; nepriamy Prompt Injection sa pritom môže do kontextu dostať aj cez načítané dokumenty. Otrava dát oproti tomu mení dlhodobejší znalostný fond alebo jeho deriváty. Aj prístupové práva riešia iný problém: Určujú, ktorá osoba smie dokument vidieť. Proveniencia a schválenie určujú, či sa tento dokument má dostať do indexu ako dôveryhodný znalostný zdroj. V robustnej architektúre potrebujú všetky tri riziká vlastné kontroly a zosúladené prechody.

Útočná plocha spočíva v celom dátovom reťazci

RAG index zriedkavo vzniká z jedinej, manuálne skontrolovanej kolekcie. Crawlery čítajú webové stránky, konektory synchronizujú cloudové priečinky, používatelia nahrávajú súbory a rozhrania importujú produktové dáta. K tomu sa pridávajú parsery, OCR, čistenie textu, chunking a obohacovanie metadát. Každá fáza môže prevziať chybné obsahy alebo vytrhnúť pôvodne správne tvrdenie z jeho kontextu.

Typickými príčinami sú kompromitovaný zdrojový systém, novo prepojený zrkadlový dokument, omylom zverejnený pracovný súbor, chybne priradený tenant alebo aktualizácia parsera, ktorá priradí hodnoty v tabuľke nesprávnym nadpisom. Porovnanie kryptografického hashu obsahu s dôveryhodnou referenčnou hodnotou dokáže odhaliť odchýlky; zhodný hash však nedokazuje pravdivosť, aktuálnosť ani schválenie obsahu.

Proveniencia ako overiteľný dátový záznam

Ku každému dokumentu a každému z neho odvodenému chunku by mal patriť záznam o proveniencii. Prakticky užitočné sú minimálne stabilné ID zdroja, kanonická URL pôvodu, zodpovedný vlastník, čas načítania, verzia dokumentu, hash obsahu, stav schválenia, trieda dôveryhodnosti, verzia parsera, verzia chunkingu, embedding model a generácia indexu. Pri manuálnych nahrávaniach sa pridáva rola nahrávajúcej osoby a overená licencia. Pri synchronizovaných systémoch je okrem toho dôležité, cez ktorý autentifikovaný konektor súbor prišiel.

Rámec NIST AI 600-1 Generative AI Profile považuje provenienciu obsahu, sledovateľnú dokumentáciu, ako aj testy a evaluácie za dôležité prvky riadenia rizík generatívnej AI. Prenesené na systémy RAG to znamená: Nezáleží len na aktuálnom indexe. Do prevádzkovej dokumentácie patrí aj sledovateľný vzťah medzi revíziou zdroja, spracovateľským behom a zverejnenou generáciou indexu.

Karanténa oddeľuje prijatie a zverejnenie

Kľúčovým architektonickým prvkom je dôsledné oddelenie: Nové alebo zmenené obsahy nie sú okamžite vyhľadávateľné. Najprv skončia v prijímacej zóne. Tam pipeline validuje pôvod, typ súboru, veľkosť, podpis alebo očakávaný hash, povoleného tenanta, úplnosť metadát a rozsah zmien. Až potom sa text a chunky vygenerujú v neprodukčnej generácii indexu.

Pravidlá by mali byť založené na riziku. Zmena na autentifikovanej, interne spravovanej FAQ stránke sa môže schváliť po automatických testoch. Nová doména, neobvykle rozsiahla zmena textu, neznámy vlastník súboru alebo zdroj bez zodpovednej osoby však spustia karanténu a manuálnu kontrolu. Ak chýba povinná informácia, platí „fail closed“: Stará, potvrdená generácia zostáva aktívna; nový stav sa ticho nezverejní.

Schválenie ako nemenná generácia indexu

Po kontrole sa produkčný index neprepisuje postupne. Lepšia je nová, verziovaná generácia s manifestom: očakávané dokumenty, očakávané chunky, hashe zdrojov, verzie transformácií a časové pečiatky. Až keď sú testy zelené, alias alebo smerovacia konfigurácia sa atomicky prepne na túto generáciu. Predchádzajúca generácia zostáva dostupná na návrat (rollback) po obmedzený, definovaný čas.

Postup sa podobá kontrolovanej migrácii. Náš článok o zmene RAG embedding modelu ukazuje, prečo sú paralelné generácie indexov a porovnávacie testy užitočné aj pri technických zmenách. Pri podozrení na otravu sa pridáva aj bezpečnostná otázka: Ktorú revíziu zdroja a ktoré odvodené chunky treba zablokovať?

Fiktívny scenár: Nesprávna lehota na vrátenie sa dostane k chatbotu podpory

Predpokladajme, že obchodník prevádzkuje chatbota pre otázky týkajúce sa produktov a služieb. Znalostná báza každú noc synchronizuje oficiálne centrum pomoci a niekoľko schválených portálov výrobcov. Po zmene odkazu však konektor nasleduje presmerovanie na neschválenú zrkadlovú stránku. Tam je vo vizuálne presvedčivom PDF uvedená lehota na vrátenie 90 namiesto 30 dní. Súbor sa rozdelí na chunky; viaceré úseky skončia s vysokou sémantickou podobnosťou v indexe.

Nasledujúce ráno bot pri otázkach o vrátení sľubuje nesprávnu lehotu. Jazykový model nebol preprogramovaný a používatelia nezadali žiadne škodlivé inštrukcie. Retrieval jednoducho poskytuje nesprávny základ. Monitoring spustí alarm, pretože sa ako zdroj odpovede prvýkrát objaví nová doména a test s Golden Setom pre lehotu vrátenia sa odchýli od očakávaného dokladu.

Kontrolovaná karanténa a opätovné spustenie

1. Tím pozastaví iba dotknutý zdroj prijímania a zmrazí aktuálnu generáciu indexu pre ďalšie zmeny.
2. Podozrivé ID dokumentu, všetky z neho odvodené ID chunkov a ich výskyty v odpovediach sa zaznamenajú v zázname o incidente.
3. Zrkadlová doména sa zablokuje a jej chunky sa presunú do karantény. Pri otázkach k lehote vrátenia bot dočasne poskytne bezpečné nasmerovanie na ľudskú podporu alebo potvrdenú stránku so zásadami.
4. Alias sa obnoví na poslednú preukázateľne čistú generáciu indexu. Ostatné, nedotknuté znalostné oblasti pritom zostávajú dostupné.
5. Konektor sa obmedzí na kanonický zdroj. Následne pipeline vybuduje novú generáciu z potvrdeného manifestu.
6. Až po reindexačných testoch a odbornom schválení ide táto generácia do produkcie.

Tento postup obmedzuje škody bez neuváženého vypnutia celého chatbota. Rozhodujúce je prepojenie dát o pôvode a odvodených prvkách: Bez priradenia dokumentu k chunkom by nebolo jasné, ktoré vektory sa musia odstrániť.

Testy reindexácie musia ukázať viac než len úspešné vykonanie pipeline

Zelený stav úlohy dokazuje iba to, že proces sa technicky skončil. Nedokazuje, že staré chunky zmizli, ani že správne zdroje vyhrávajú pri reálnych otázkach. Robustný testovací balík preto preveruje stav, retrieval aj správanie pri odpovediach.

1. Kontrola manifestu a vymazania

Porovnajte novú generáciu so schváleným manifestom. Každá očakávaná verzia dokumentu musí byť prítomná; zablokované ID dokumentov a chunkov sa nesmú vyskytovať. Obzvlášť dôležité sú „tombstones“ pre vymazané alebo nahradené obsahy. Púhe pripojenie nových embeddingov by inak ponechalo staré, otrávené výsledky naďalej v indexe.

2. Retrieval testy s očakávanými zdrojmi

Pre kritické otázky nestačí len očakávaný text odpovede. Definujte navyše povolené a zakázané ID zdrojov, minimálny počet výsledkov a podmienky vylúčenia. Lehota na vrátenie musí pochádzať napríklad z kanonických zásad; zrkadlová doména v karanténe sa nesmie objaviť v top výsledkoch ani v kontexte modelu. Ako štruktúrovať takéto testovacie sady, vysvetľuje článok o kvalite odpovedí s Golden Setom a RAG testami.

3. Negatívne a manipulačné testy

V izolovanom testovacom prostredí môžu tímy vložiť jednoznačne označený, neschválený testovací zdroj. Pipeline ho musí udržať v karanténe; vyhľadávanie podobné produkcii ho nesmie načítať. Dodatočne sa testujú neobvyklé zmeny domén, chýbajúci vlastníci, extrémne rozdiely v obsahu a rozporuplné dátumy. Správa NIST AI 100-2 o Adversarial Machine Learning zaraďuje poisoning ako kategóriu útokov vo svojej taxonómii a zdôrazňuje, že protiopatrenia a ich limity sa musia posudzovať systematicky.

4. Porovnanie pred a po zmene

Spusťte rovnaké otázky na poslednú čistú a na novú generáciu. Porovnajte zdroje výsledkov, poradie, doklady v odpovediach, míru neodpovedania (No-Answer-Rate) a odborné hodnotenie. Malý podiel canary nasadenia môže poskytnúť dodatočné produkčné signály, pokiaľ používatelia nezískajú prístup k neovereným zdrojom. Produkčné prepnutie nastane až po dodržaní stanovených prahov bezpečnosti a kvality.

Monitoring: Včasné odhalenie abnormalít

Sledujte nielen hodnotenia odpovedí. Výpovedné sú nové alebo zriedkavé zdrojové domény, podiel neoverených zdrojov v toku prijímania, neobvyklé veľkosti dokumentov, výrazné rozdiely v hashoch alebo textoch, veľa nových chunkov od jediného vlastníka, zmeny top zdrojov v Golden Sete a odpovede bez potvrdeného dokladu. Metriky by mali odkazovať na ID proveniencie, nie na zbytočne uložené úplné otázky používateľov.

Aj aktuálnosť zostáva relevantná. Stará, dávno nahradená smernica nie je úmyselne otrávená, ale môže mať rovnaký účinok. Článok o aktuálnosti znalostných báz a Crawl-QA dopĺňa bezpečnostné kontroly o kadenciu, zodpovednosť a cesty mazania.

Kontrolný zoznam pre bezpečné prijímanie RAG dát

• Má každý zdroj stabilné ID, kanonický pôvod, zodpovednú osobu a triedu dôveryhodnosti?
• Zaznamenávajú sa hash, verzia dokumentu, parser, chunking a embedding model spoločne?
• Zostávajú nové alebo výrazne zmenené zdroje mimo produkčného vyhľadávania až do ich overenia?
• Vedú nové domény, chýbajúce podpisy alebo nepravdepodobné zmeny obsahu ku karanténe?
• Zverejňujú sa schválené indexy ako verziované generácie s vrátiteľným aliasom?
• Odstraňuje reindexácia nahradené chunky preukázateľne namiesto obyčajného pripájania nových dát?
• Testuje Golden Set odpovede, ako aj očakávané a zakázané zdroje?
• Existuje bezpečný záložný postup (fallback) pre témy, ktorých zdroje sú počas incidentu zablokované?
• Sú roly pre prijímanie, odborné schválenie, reakciu na incidenty a opätovné zverejnenie určené oddelene?
• Dokumentuje sa po každom incidente, ktorá kontrola zlyhala a ktorý regresný test bol doplnený?

Záver

Otravu RAG dát nie je možné vyriešiť jediným pravidlom v prompte. Ochrana vzniká z overiteľného dodávateľského reťazca pre znalosti: dokumentovať pôvod, overovať zmeny v karanténe, verziovať indexy, bezpečne odstraňovať staré deriváty a testovať retrieval s očakávanými zdrojmi. Začnite s najrizikovejšími triedami dokumentov a malým Golden Setom. Už táto kombinácia zviditeľní, ktorý zdroj podporuje odpoveď – a umožní cielený návrat skôr, než sa chybné znalosti stanú trvalým normálnym stavom.

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