Koncept mazání RAG pro AI chatboty: Jak odstranit obsah z indexu, cache a odpovědí

Platnost ceníku vypršela, bezpečnostní pokyn byl stažen nebo zákazník požaduje odstranění osobních údajů. Zdrojový soubor je ve zdrojovém systému smazán rychle. Přesto může webový chatbot na starý obsah spoléhat ještě minuty, hodiny nebo dokonce déle: Kopie může zůstat v nahrávací oblasti, soubor byl rozdělen do několika textových úseků (chunků), jejichž embeddingy jsou ve vektorovém indexu, a cache odpovědí uchovává již formulované tvrzení. Spolehlivý koncept mazání RAG se proto nezabývá pouze zdrojovým souborem, ale celým řetězcem odvozených dat.

Cílem přitom není plošně a okamžitě vše zničit. Vyžaduje se řízený proces, který zastaralý nebo stažený obsah neprodleně odstraní z aktivní trasy odpovědí, zohlední zákonné i provozní povinnosti uchovávání dat a následně prokáže, že retrieval ani odpovědi daný obsah již nepoužívají. Právě tento důkaz odlišuje pouhou akci smazání od spolehlivého provozního postupu.

Proč je mazání v systému RAG víceúrovňové

Retrieval-Augmented Generation propojuje jazykový model s externími znalostmi. Mezi původním zdrojem a odpovědí existuje několik technických stavů: crawler nebo upload, normalizovaný soubor, rozpoznání textu, chunky, metadata, embeddingy, vektorový a fulltextový index, cache dotazů, vybrané výsledky vyhledávání a z nich vygenerovaná odpověď. Některé systémy navíc ukládají historii relací, vzorky kvality nebo trasování (traces). Pokud je odstraněn pouze první stav, následné kopie mohou zůstat stále dohledatelné.

K tomu se přidává časový problém. Mazání může probíhat asynchronně, zatímco paralelně přicházejí nové dotazy. Noční reindexace pak nestačí: do jejího spuštění by chatbot mohl staženou informaci nadále poskytovat. A naopak, pozdější import nesmí zdroj omylem obnovit. Proto každé mazání vyžaduje jak rychlou blokaci v ceste dotazu, tak úplné vyčištění na pozadí.

Předem jasně definujte rozsah mazání

Na začátku stojí stabilní identita zdroje. Název souboru nebo samotná URL bývají často příliš slabé, protože se mohou měnit nebo vyskytovat vícekrát. Vhodné je interní ID zdroje, verze, tenant (klient), jazyk, oblast přístupu a hash importovaného obsahu. Každý chunk a každý záznam v indexu musí být sledovatelný až k této identitě. Teprve pak lze spolehlivě určit, které odvozeniny ke zdroji patří.

Následně se stanoví, co v konkrétním případě znamená „smazáno“. Pro zastaralou informaci o produktu může stačit ji deaktivovat v aktivní znalostní bázi a nahradit novou verzí. Při odvolání souhlasu, žádosti o ochranu osobních údajů nebo skončení licence mohou platit přísnější lhůty a mohou být dotčena další úložiště. Zálohy, bezpečnostní protokoly a zákonem vyžadované doklady mají často vlastní pravidla. Rozhodnutí by proto mělo zapojit správce dat, provozní tým a u osobních či regulovaných obsahů také oddělení ochrany osobních údajů nebo právní úsek.

Bezpečný postup mazání v sedmi krocích

1. Zaznamenání a ověření žádosti: Poznamenejte si ID zdroje, verzi, důvod, požadovanou lhůtu, dotčené tenanty a osobu nebo roli, která akci schválila. U citlivých mazání musí být před změnou dat ověřeno oprávnění.
2. Nastavení tombstone: Označte zdroj okamžitě jako blokovaný. Filtry vyhledávání (retrieval) musí tento stav zohlednit, aby se příslušné chunky už nedostávaly do nových odpovědí, i když fyzické čištění stále probíhá.
3. Vyřešení závislostí: Zjistěte surové kopie, výsledky parseru, chunky, embeddingy, fulltextové dokumenty, cache, předem vygenerované stavební bloky odpovědí a případné testovací datové sady. ID zdroje slouží jako společný klíč.
4. Vyčištění aktivních indexů: Smažte nebo deaktivujte všechny dotčené záznamy ve vektorovém a klíčovém indexu. Zkontrolujte odezvu příslušné služby; přijatý požadavek ještě není důkazem o dokončeném smazání.
5. Invalidace cache: Cíleně vyprázdněte vyhledávací, dotazové a odpovědní cache. Kde není možná selektivní invalidace, pomohou verze klíčů nebo nový namespace, aby staré záznamy již nebyly dostupné.
6. Provedení kontroly: Dotažte se na známé formulace, názvy dokumentů, vzácné výrazy a sémanticky podobné varianty. Přímé vyhledání podle ID zdroje i náhodný test v chatbotu by měly zůstat bez nálezu.
7. Dokončení procesu: Uložte stručný protokol o mazání s časem, rozsahem, systémovými odpověďmi, výsledkem kontroly a otevřenými lhůtami uchování. Protokol má doložit proces, ale ne zbytečně kopírovat smazaný obsah.

Proč tombstone předchází fyzickému smazání

Toto pořadí zabraňuje dvěma typickým chybám. Zaprvé, crawler nemůže vždy čistě přiřadit smazaný zdrojový soubor ke stávajícímu záznamu v indexu. Některé indexery očekávají signál soft-delete, dokud je zdroj stále rozpoznatelný. Zadruhé, běžící úlohy mohou mezi smazáním zdroje a vyčištěním indexu znovu zapsat data. Centrální tombstone toto opětovné načtení zablokuje. Měl by zůstat zachován i poté, co byla vlastní uživatelská data odstraněna – avšak pouze s minimálně nutnými metadaty a jasnou lhůtou uchování.

Verzování činí mazání cache zvládnutelným

Cache jsou zvláště náchylné k chybám, pokud se klíče skládají pouze z dotazu uživatele. Lepší je klíč, který navíc obsahuje verzi znalostní báze, tenanta, jazyk a kontext oprávnění. Po smazání se verze zvýší. I když jednotlivý záznam v cache technicky stále existuje až do vypršení své platnosti, aktivní aplikace se na něj již netrefí. To sice v každém případě nenahrazuje cílenou invalidaci, ale snižuje riziko, že se staré odpovědi znovu objeví.

HTTP cache se řídí vlastními pravidly. Standard RFC 9111 popisuje, kdy jsou uložené odpovědi čerstvé, zastaralé nebo určené k invalidaci. Pro aplikace RAG z toho vyplývá: cache CDN, API a aplikace musí být posuzovány odděleně. Nová verze databáze sama o sobě nevyprázdní cache odpovědí doručovanou na okraji sítě (edge).

Konkrétní příklad: Stažený návod k montáži

Předpokládejme, že výrobce stahuje verzi 3 montážního návodu, protože byl změněn pracovní krok. Verze 4 je již schválena. Systém pro zdroj V3 okamžitě nastaví tombstone a publikuje V4 pod novým ID verze. Retriever filtruje výhradně schválené zdroje a preferuje aktuální verzi. Paralelně worker odstraňuje všechny chunky V3 z vektorového a fulltextového indexu a invaliduje cache, jejichž seznam závislostí obsahuje toto ID zdroje.

Zajištění kvality se nyní neptá pouze „Jak namontuji tento díl?“. Používá také výraznou formulaci z V3, parafrázovaný dotaz a dotaz, který byl dříve zodpověditelný pouze pomocí V3. Očekává se buď doložená odpověď z V4, nebo jasné upozornění, že nejsou k dispozici žádné schválené informace. Odkaz na zdroj V3, doslovný fragment nebo odpověď bez aktuálního nálezu se považuje za chybu. Jak učinit zdroje v odpovědích viditelnými, vysvětluje článek Dokládání zdrojů v odpovědích chatbota.

Kontrola, zda mazání skutečně funguje

Zelený stav API nestačí. Kontrola by měla probíhat na několika úrovních. Na úrovni úložiště se hledá podle ID zdroje, ID chunků a známých hashů. Na úrovni vyhledávání (retrieval) se spouštějí testovací dotazy a kontrolují se vrácené výsledky. Na úrovni odpovědí se zjišťuje, zda se staré tvrzení stále neobjevuje doslova nebo ve stejném smyslu. Nakonec je potřebný test opětovného spuštění: po běhu crawleru, přestavbě indexu nebo obnovení ze zálohy se zdroj nesmí vrátit.

Pro každou kritickou třídu znalostí udržujte malý Golden Set pozitivních a negativních případů. Pozitivní případy dokazují, že náhradní zdroj je správně nalezen; negativní případy ukazují, že blokované informace se již neobjevují. Tento postup doplňuje průběžnou QA pro udržování aktuální znalostní báze AI chatbota. Při větších změnách indexu pomáhá také paralelní nová výstavba s řízeným přepnutím, jak je popsáno v průvodci pro změnu embedding modelu v RAG.

Kontrolní seznam pro běžný provoz

• Každý zdroj má stabilní ID, verzi, původ, jazyk a odpovědného vlastníka.
• Chunky, embeddingy, dokumenty v indexu a cache jsou dohledatelné k tomuto ID zdroje.
• Tombstone okamžitě blokuje zdroj ve vyhledávání a brání jeho opětovnému importu.
• Požadavek na smazání běží idempotentně: opakování nevytváří chyby ani nové záznamy.
• Workery nehlásí pouze „přijato“, ale dokončený stav s detaily o případných chybách.
• Cache vyhledávání a odpovědí lze selektivně invalidovat nebo odpojit pomocí verzí.
• Přímé vyhledávání, sémantické vyhledávání, test odpovědí a test obnovení jsou dokumentovány.
• Zálohy a logy mají definované lhůty uchování a postup pro pozdější obnovení.
• Protokol o mazání obsahuje pouze nezbytná metadata a žádnou zbytečnou kopii odstraněného obsahu.
• Odpovědnost, eskalace a maximální doba zpracování jsou stanoveny a pravidelně procvičovány.

Nezaměňujte governance a ochranu osobních údajů

Technický koncept mazání odpovídá na otázku, jak zdroj bezpečně zmizí z aktivní trasy RAG. Zda a kdy musí být smazán, je jiná otázka. Obecné nařízení o ochraně osobních údajů (GDPR) obsahuje v článku 17 právo na výmaz za určitých podmínek a rovněž výjimky. Plošné tvrzení jako „každá žádost okamžitě smaže každou zálohu“ by proto bylo stejně rizikové jako časově neomezené ukládání bez účelu. Rozhodující právní základ a lhůta musí být stanoveny pro příslušný případ použití; oficiální text nařízení je k dispozici na EUR-Lex.

Organizačně tento postup patří do Content Governance: Kdo smí stahovat obsah? Kdo potvrzuje vyčištění? Co se stane, když je externí vektorová služba nedostupná? Článek Content Governance pro AI chatboty ukazuje, jak spolupracují vlastníci, schvalování a Change Control. Pro vysoká rizika se doporučuje princip čtyř očí; pro běžné aktualizace může stačit automatizovaný, plně protokolovaný pracovní postup.

Oficiální zdroje a technické reference

• Microsoft Learn: Detekce změněných a smazaných blobů v Azure AI Search
• Microsoft Learn: Documents API pro Azure AI Search
• Google Cloud: Správa souborů a korpusů v Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Obecné nařízení o ochraně osobních údajů (GDPR)

Závěr: Možnost mazání je funkcí kvality

Znalostní báze RAG je spolehlivá pouze tehdy, když lze obsah nejen přidávat, ale také řízeně stahovat. Stabilní ID zdrojů, tombstony, seznamy závislostí, verzované cache a opakovatelné testy mění nejistou jednorázovou akci ve zvládnutelný proces. Kdo přitom propojí věcné schválení, technické vyčištění a prokazatelnou QA, sníží výskyt zastaralých odpovědí a vytvoří základ pro chatbota, jehož znalosti lze vědomě řídit.