RAG kustutamiskontseptsioon AI-juturobotitele: sisu eemaldamine indeksist, vahemälust ja vastustest

Hinnakiri on aegunud, ohutusjuhis on tagasi võetud või klient nõuab isikuandmete eemaldamist. Allikasüsteemis saab vastava faili kiiresti kustutada. Sellele vaatamata võib veebisaidi juturobot veel minuteid, tunde või isegi kauem vanale sisule tugineda: koopia võib asuda importimisalal, fail on tükeldatud mitmeks tekstiosaks (chunk), mille vektorkujutised (embeddings) asuvad vektorindeksis, ning vastuste vahemälu hooldab juba sõnastatud väidet. Toimiv RAG-kustutamiskontseptsioon ei töötle seetõttu ainult algfaili, vaid kogu tuletusahelat.

Eesmärk ei ole seejuures kõike valimatult kohe hävitada. Vaja on kontrollitud protsessi, mis eemaldab aegunud või tagasivõetud sisu viivitamatult aktiivsest vastamisahelast, arvestab seadusest ja ettevõttest tulenevaid säilitamiskohustusi ning tõendab seejärel, hogy otsing (retrieval) ja vastused seda sisu enam ei kasuta. Just see tõendamine eristab lihtsat kustutamisaktsiooni usaldusväärsest tööprotsessist.

Miks kustutamine RAG-süsteemis on mitmeetapiline

Retrieval-Augmented Generation ühendab keelemudeli välise teadmisega. Algallika ja vastuse vahel on mitu tehnilist olekut: veebirobot (crawler) või üleslaadimine, normaliseeritud fail, tekstituvastus, tekstiosad (chunks), metaandmed, vektorkujutised (embeddings), vektor- ja täistekstindeks, päringute vahemälu, valitud leiud ning neist genereeritud vastus. Mõned süsteemid salvestavad lisaks seansiajalugu, kvaliteedivalimeid või jälitusi (traces). Kui eemaldate ainult esimese oleku, võivad allpool asuvad koopiad jääda edasi leitavaks.

Lisandub aja küsimus. Kustutamist saab töödelda asünkroonselt, samal ajal kui paralleelselt saabuvad uued päringud. Öisest uuesti indekseerimisest siis ei piisa: kuni selle käivitamiseni võib juturobot tagasivõetud teavet endiselt väljastada. Vastupidiselt ei tohi hilisem import allikat kogemata taastada. Seetõttu vajab iga kustutamine nii kiiret blokeeringut päringuteekonnal kui ka täielikku puhastamist taustal.

Kustutamise ulatus tuleb eelnevalt selgelt määratleda

Alguses on stabiilne allika identiteet. Failinimi või URL üksi on sageli liiga nõrgad, sest need võivad muutuda või esineda mitu korda. Mõistlikud on sisemine allika ID, versioon, rentnik (tenant), keel, juurdepääsuala ja imporditud sisu räsi. Iga tekstiosa ja iga indeksikanne peab olema tagasiviidav sellele identiteedile. Alles siis saab usaldusväärselt kindlaks teha, millised tuletised allikale kuuluvad.

Seejärel määratakse kindlaks, mida "kustutatud" konkreetsel juhul tähendab. Aegunud tooteteabe puhul võib piisata selle deaktiveerimisest aktiivsest teadmusbaasist ja asendamisest uue versiooniga. Lepingust taganemise, andmekaitsepäringu või litsentsi lõppemise korral võivad kehtida rangemad tähtajad ja lisasalvestuskohad. Varukoopiatel, turbalogidel ja seadusega nõutavatel tõenditel on sageli omad reeglid. Otsusesse tuleks seetõttu kaasata andmevastutavad, käituse ja isikuandmete või reguleeritud sisu korral ka andmekaitse või õigusosakond.

Turvaline kustutamisprotsess seitsmes sammus

1. Salvestage ja verifitseerige päring: märkige üles allika ID, versioon, põhjus, taotletud tähtaeg, puudutatud rentnikud ning kinnitanud isik või roll. Tundlike kustutamiste puhul tuleb õigusi kontrollida enne andmete muutmist.
2. Seadke tombstone: märkige allikas kohe blokeerituks. Otsingufiltrid peavad seda olekut arvesse võtma, et seotud tekstiosad ei jõuaks enam uutesse vastustesse, isegi kui füüsiline puhastamine veel käib.
3. Lahendage sõltuvused: tuvastage toorkoopiad, parseri tulemused, tekstiosad, vektorkujutised, täistekstdokumendid, vahemälud, eelnevalt genereeritud vastuseplokid ja vajadusel testandmestikud. Allika ID toimib ühise võtmena.
4. Puhastage aktiivsed indeksid: kustutage või deaktiveerige kõik puudutatud andmekirjed vektor- ja märksõna-indeksis. Kontrollige vastava teenuse tagasisidet; vastuvõetud tellimus ei ole veel tõend lõpetatud kustutamise kohta.
5. Tühistage vahemälud: tühjendage sihipäraselt otsingu-, päringu- ja vastusevahemälud. Seal, kus selektiivne tühistamine pole võimalik, aitavad versioonivõtmed või uus nimeruum, et vanad kanded poleks enam kättesaadavad.
6. Teostage kontrollid: küsige tuntud sõnastuste, dokumendipealkirjade, haruldaste mõistete ja semantiliselt sarnaste variantide kohta. Otsene päring allika ID järgi ja valikproov juturobotis peaksid mõlemad jääma ilma leitud tulemusteta.
7. Lõpetage toiming: salvestage lühike kustutamisprotokoll koos aja, ulatuse, süsteemi vastuste, kontrollitulemuse ja avatud säilitustähtaegadega. Protokoll peab toimingut tõendama, kuid mitte kustutatud sisu asjatult kopeerima.

Miks tombstone eelneb füüsilisele kustutamisele

Järjekord hoiab ära kaks tüüpilist viga. Esiteks ei saa veebirobot kustutatud algfaili alati puhtalt olemasoleva indeksikandega kõrvutada. Mõned indekseerijad ootavad pehme kustutamise (soft delete) signaali seni, kuni allikas on veel tuvastatav. Teiseks võivad käimasolevad tööd allika kustutamise ja indeksi puhastamise vahel andmeid uuesti kirjutada. Tsentraalne tombstone blokeerib selle uuesti alustamise. See peaks säilima isegi siis, kui tegelikud kasutusandmed on juba eemaldatud – siiski ainult minimaalselt vajalike metaandmetega ja selge säilitustähtajaga.

Versioonihaldus muudab vahemälu kustutamise hallatavaks

Vahemälud on eriti veaohtlikud, kui võtmed koosnevad ainult kasutaja küsimusest. Parem on võti, mis sisaldab lisaks teadmusbaasi versiooni, rentnikku, keelt ja juurdepääsuõiguste konteksti. Pärast kustutamist versiooni suurendatakse. Isegi kui üksik vahemälukanne eksisteerib tehniliselt kuni selle aegumiseni, ei saa aktiivne rakendus seda enam tabada. See ei asenda sihipärast tühistamist igal juhul, kuid vähendab riski, et vanad vastused uuesti ilmuvad.

HTTP-vahemälud järgivad omakorda oma reegleid. Standard RFC 9111 kirjeldab, millal salvestatud vastused on värsked, aegunud või tühistamisele kuuluvad. RAG-rakenduste jaoks tuleneb sellest: CDN-, API- ja rakenduse vahemälu tuleb vaadelda eraldi. Uus andmebaasiversioon üksi ei tühjenda võrgu serval serveeritavat vastusevahemälu.

Konkreetne näide: Tagasivõetud paigaldusjuhend

Oletame, et tootja võtab paigaldusjuhendi versiooni 3 tagasi, kuna ühte tööetappi muudeti. Versioon 4 on juba kinnitatud. Süsteem seab allikale V3 kohe tombstone-märke ja avaldab V4 uue versiooni ID all. Päringumootor (retriever) filtreerib eranditult kinnitatud allikaid ja eelistab praegust versiooni. Paralleelselt eemaldab taustatöö (worker) kõik V3 tekstiosad vektor- ja täistekstindeksist ning tühistab vahemälud, mille sõltuvusloend sisaldab seda allika ID-d.

Kvaliteeditagamisprotsess ei küsi nüüd ainult: "Kuidas ma seda detaili paigaldan?". Kasutatakse ka silmatorkavat sõnastust versioonist V3, parafraseeritud küsimust ning küsimust, millele varem sai vastata ainult versiooni V3 abil. Oodatakse kas kinnitatud vastust versioonist V4 või selget viidet, et kinnitatud teave puudub. Allikaviide versioonile V3, sõna-sõnaline katkend või ilma praeguse leiuta vastus loetakse veaks. Kuidas allikaid vastustes nähtavaks tehakse, selgitab artikkel Juturoboti vastuste tõendamine allikatega.

Kontrollimine, kas kustutamine tõesti toimib

Rohelisest API olekust ei piisa. Kontroll peaks toimuma mitmel tasandil. Salvestusruumi tasemel otsitakse allika ID-d, tekstiosade ID-sid ja teadaolevaid räsisid. Otsingu tasemel teostatakse testküsimusi ja kontrollitakse tagastatud leide. Vastuse tasemel kontrollitakse, kas vana väide ilmub veel sõna-sõnalt või sisuliselt. Lõpuks on vaja taaskäivituse testi: pärast veebiroboti tööd, indeksi uuesti ülesehitamist või varukoopia taastamist ei tohi allikas tagasi tulla.

Hoidke iga kriitilise teadmiste klassi jaoks alles väike positiivsete ja negatiivsete juhtumite kuldne komplekt (Golden Set). Positiivsed juhtumid tõendavad, et asendusallikas leitakse õigesti; negatiivsed juhtumid näitavad, et blokeeritud teave ei ilmu enam. See protseduur täiendab käimasolevat AI-juturoboti teadmusbaasi ajakohasena hoidmise QA-d. Suuremate indeksimuudatuste puhul aitab lisaks paralleelne uuesti ülesehitamine koos kontrollitud ümberlülitamisega, nagu on kirjeldatud juhendis RAG-i vektormudeli vahetamine.

Meelespea igapäevaseks käituseks

• Igal allikal on stabiilne ID, versioon, päritolu, keel ja vastutav omanik.
• Tekstiosad, vektorkujutised, indeksidokumendid ja vahemälud on sellele allika ID-le tagasiviidavad.
• Tombstone blokeerib allika kohe otsingus ja hoiab ära uue impordi.
• Kustutamistellimus on idempotentne: kordamine ei tekita ei vigu ega uusi andmekirjeid.
• Taustatööd ei teata mitte ainult "vastu võetud", vaid annavad teada lõpetatud oleku koos veateabega.
• Otsingu- ja vastusevahemälusid saab selektiivselt tühistada või versioonide kaudu lahti ühendada.
• Otseotsing, semantiline otsing, vastuse test ja taaskäivituse test on dokumenteeritud.
• Varukoopiatel ja logidel on määratletud säilitustähtajad ja protsess hilisemaks taastamiseks.
• Kustutamisprotokoll sisaldab ainult vajalikke metaandmeid ja mitte ühtegi tarbetut koopiat eemaldatud sisust.
• Vastutus, eskaleerimine ja maksimaalne töötlemisaeg on kindlaks määratud ja neid harjutatakse regulaarselt.

Ärge segage juhtimist ja andmekaitset

Tehniline kustutamiskontseptsioon vastab küsimusele, kuidas allikas kaob turvaliselt aktiivsest RAG-ahelast. Kas ja millal see tuleb kustutada, on teine küsimus. Isikuandmete kaitse üldmäärus sisaldab artiklis 17 õigust andmete kustutamisele teatud tingimustel ning samuti erandeid. Üldine väide, nagu "iga päring kustutab kohe iga varukoopia", oleks seetõttu sama riskantne kui tähtajatu salvestamine ilma eesmärgita. Asjakohane õiguslik alus ja tähtaeg tuleb kindlaks määrata konkreetse kasutusjuhu jaoks; ametlik määruse tekst on kättesaadav EUR-Lexi kaudu.

Organisatsiooniliselt kuulub protsess sisu juhtimisse (Content Governance): kes tohib sisu tagasi võtta? Kes kinnitab puhastamise? Mis saab siis, kui väline vektorteenus pole kättesaadav? Artikkel AI-juturoboti sisu juhtimine näitab, kuidas omanikud, kinnitused ja muudatuste juhtimine (Change Control) koos toimivad. Kõrgete riskide puhul soovitame nelja silma põhimõtet; tavaliste uuenduste puhul võib piisata automatiseeritud, täielikult protokollitud töövoost.

Ametlikud allikad ja tehnilised viited

• Microsoft Learn: Muudetud ja kustutatud blobide tuvastamine Azure AI Searchis
• Microsoft Learn: Documents API teenusele Azure AI Search
• Google Cloud: Failide ja korpuste haldamine Vertex AI RAG Engine'is
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Isikuandmete kaitse üldmäärus

Järeldus: Kustutatavus on kvaliteedifunktsioon

RAG-teadmusbaas on usaldusväärne ainult siis, kui sisu ei saa mitte ainult lisada, vaid ka kontrollitult tagasi võtta. Stabiilsed allika ID-d, tombstone-märgid, sõltuvusloendid, versioonitud vahemälud ja korratavad testid teevad ebakindlast üksikaktsioonist hallatava protsessi. Need, kes ühendavad seejuures sisulise kinnitamise, tehnilise puhastamise ja tõendatava kvaliteeditagamise, vähendavad aegunud vastuseid ja loovad aluse juturobotile, mille teadmisi saab teadlikult juhtida.