RAG dzēšanas koncepcija AI čatbotiem: satura izņemšana no indeksa, kešatmiņas un atbildēm

Cenu lapa ir zaudējusi spēku, drošības instrukcija ir atsaukta vai klients pieprasa personas datu dzēšanu. Avota sistēmā attiecīgais fails tiek ātri izdzēsts. Tomēr vietnes čatbots var turpināt izmantot veco saturu minūtes, stundas vai pat ilgāk: kopija var atrasties importēšanas zonā, fails ir sadalīts vairākos teksta fragmentos, kuru iegulšanas (embeddings) atrodas vektoru indeksā, un atbilžu kešatmiņa uztur jau noformulētu paziņojumu. Uzticama RAG dzēšanas koncepcija tāpēc apstrādā ne tikai avota failu, bet visu atvasināšanas ķēdi.

Mērķis nav vispārīgi iznīcināt visu uzreiz. Ir nepieciešams kontrolēts process, kas nekavējoties izņem novecojušu vai atsauktu saturu no aktīvā atbilžu ceļa, ņem vērā juridiskos un darbības glabāšanas pienākumus un pēc tam pierāda, ka izgūšana (retrieval) un atbildes šo saturu vairs neizmanto. Tieši šāds pierādījums nošķir vienkāršu dzēšanas darbību no uzticamas darbības procedūras.

Kāpēc dzēšana RAG sistēmā notiek vairākos posmos

Retrieval-Augmented Generation savieno valodas modeli ar ārējām zināšanām. Starp sākotnējo avotu un atbildi pastāv vairāki tehniskie stāvokļi: pārmeklētājs (crawler) vai augšupielāde, normalizēts fails, teksta atpazīšana, fragmenti (chunks), metadati, iegulšanas (embeddings), vektoru un pilna teksta indekss, vaicājumu kešatmiņa, atlasītās atradnes un no tām ģenerētā atbilde. Dažas sistēmas papildus saglabā sesiju vēsturi, kvalitātes paraugus vai izsekošanas datus (traces). Ja tiek noņemts tikai pirmais stāvoklis, pakārtotās kopijas var palikt atrodamas.

Papildus rodas arī laika problēma. Dzēšanu var apstrādāt asinhroni, kamēr paralēli ienāk jauni vaicājumi. Ar nakts pārindeksēšanu tad nepietiek: līdz tās palaišanai čatbots var turpināt izdot atsaukto informāciju. Un otrādi — vēlāka importēšana nedrīkst nejauši atjaunot avotu. Tāpēc katrai dzēšanai ir nepieciešama gan ātra bloķēšana pieprasījuma ceļā, gan pilnīga attīrīšana fonā.

Iepriekš skaidri definēt dzēšanas apjomu

Sākumā ir nepieciešama stabila avota identitāte. Faila nosaukums vai URL vien bieži vien ir pārāk vāji rādītāji, jo tie var mainīties vai atkārtoties. Noderīgi ir iekšējais avota ID, versija, klients (tenant), valoda, piekļuves zona un importētā satura jaucējvērtība (hash). Katram fragmentam un katram indeksa ierakstam jābūt izsekojamam līdz šai identitātei. Tikai tad var droši noteikt, kuri atvasinājumi pieder pie konkrētā avota.

Pēc tam tiek noteikts, ko konkrētajā gadījumā nozīmē „izdzēsts“. Novecojušai produkta informācijai var pietikt ar tās deaktivizēšanu aktīvajā zināšanu bāzē un aizstāšanu ar jaunu versiju. Atsaukšanas, datu aizsardzības pieprasījuma vai licences beigu gadījumā var tikt skarti stingrāki termiņi un papildu glabāšanas vietas. Dublējumiem (backups), drošības žurnāliem un juridiski nepieciešamajiem pierādījumiem bieži vien ir savi noteikumi. Tāpēc lēmuma pieņemšanā jāiesaista datu pārziņi, uzturēšanas komanda un personas datu vai regulēta satura gadījumā arī datu aizsardzības vai juridiskais dienests.

Drošs dzēšanas process septiņos soļos

1. Reģistrēt un verificēt pieprasījumu: Pierakstiet avota ID, versiju, iemeslu, pieprasīto termiņu, ietekmētos klientus un personu vai lomu, kas devusi apstiprinājumu. Jutīgu dzēšanu gadījumā pirms datu mainīšanas ir jāpārbauda pilnvaras.
2. Iestatīt tombstone (dzēšanas atzīmi): Nekavējoties atzīmējiet avotu kā bloķētu. Izgūšanas filtriem ir jāņem vērā šis statuss, lai saistītie fragmenti nenokļūtu jaunās atbildēs pat tad, ja fiziskā attīrīšana vēl turpinās.
3. Apzināt atkarības: Identificējiet neapstrādātās kopijas, parsera rezultātus, fragmentus, iegulšanas, pilna teksta dokumentus, kešatmiņas, iepriekš ģenerētos atbilžu blokus un, ja nepieciešams, testa datu kopas. Avota ID kalpo kā kopīgais atslēgas elements.
4. Attīrīt aktīvos indeksus: Dzēsiet vai deaktivizējiet visus skartos ierakstus vektoru un atslēgvārdu indeksā. Pārbaudiet attiecīgā pakalpojuma atbildes; pieņemts uzdevums vēl nav pierādījums tam, ka dzēšana ir pabeigta.
5. Invalidēt kešatmiņu: Mērķtiecīgi iztukšojiet izgūšanas, vaicājumu un atbilžu kešatmiņas. Ja selektīva atsaukšana nav iespējama, palīdz versiju atslēgas vai jauna vārdtelpa (namespace), lai vecie ieraksti vairs nebūtu sasniedzami.
6. Veikt pārbaudes un pierādījumus: Veiciet vaicājumus, izmantojot zināmus formulējumus, dokumentu nosaukumus, retus terminus un semantiski līdzīgus variantus. Tiešajai pieprasīšanai pēc avota ID un izlases pārbaudei čatbotā abām jāpaliek bez atradnēm.
7. Pabeigt procesu: Saglabājiet īsu dzēšanas protokolu ar laiku, apjomu, sistēmas atbildēm, pārbaudes rezultātu un atvērtajiem glabāšanas termiņiem. Protokolam vajadzētu apliecināt procesu, bet nevajadzīgi nekopēt izdzēsto saturu.

Kāpēc Tombstone tiek iestatīts pirms fiziskās dzēšanas

Šī secība novērš divas tipiskas kļūdas. Pirmkārt, pārmeklētājs (crawler) ne vienmēr var tīri piesaistīt izdzēsto avota failu esošam indeksa ierakstam. Daži indeksētāji sagaida Soft-Delete signālu, kamēr avots vēl ir atpazīstams. Otrkārt, aktīvie fona darbi starp avota dzēšanu un indeksa attīrīšanu var no jauna ierakstīt datus. Centralizēts Tombstone bloķē šo atjaunošanu. Tam būtu jāsaglabājas pat tad, ja paši satura dati jau ir izņemti — tomēr tikai ar minimāli nepieciešamajiem metadatiem un skaidru glabāšanas termiņu.

Versiju izveide padara kešatmiņas dzēšanu pārvaldāmu

Kešatmiņas ir īpaši pakļautas kļūdām, ja atslēgas sastāv tikai no lietotāja jautājuma. Labāka ir atslēga, kas papildus ietver zināšanu bāzes versiju, klientu, valodu un piekļuves tiesību kontekstu. Pēc dzēšanas versija tiek palielināta. Pat ja atsevišķs kešatmiņas ieraksts tehniski vēl pastāv līdz tā derīguma termiņa beigām, aktīvā lietojumprogramma to vairs nevar sasniegt. Tas neaizstāj mērķtiecīgu atsaukšanu katrā gadījumā, bet samazina risku, ka vecās atbildes parādīsies no jauna.

HTTP kešatmiņas savukārt seko saviem noteikumiem. Standarts RFC 9111 apraksta, kad saglabātās atbildes ir svaigas, novecojušas vai atsaucamas. RAG lietotnēm no tā izriet: CDN, API un lietojumprogrammas kešatmiņa jāaplūko atsevišķi. Jauna datubāzes versija pati par sevi neiztukšo perifērijā (edge) piegādāto atbilžu kešatmiņu.

Konkrēts piemērs: Atsaukta montāžas instrukcija

Pieņemsim, ka ražotājs atsauc montāžas instrukcijas 3. versiju, jo ir mainīts darba solis. 4. versija jau ir apstiprināta. Sistēma avotam V3 nekavējoties iestata Tombstone un publicē V4 ar jaunu versijas ID. Izgūšanas mehānisms (retriever) filtrē tikai apstiprinātus avotus un dod priekšroku pašreizējai versijai. Paralēli fona process noņem visus V3 fragmentus no vektoru un pilna teksta indeksa un invalidē kešatmiņas, kuru atkarību sarakstā ir šis avota ID.

Kvalitātes nodrošināšana tagad neuzdod tikai jautājumu „Kā samontēt detaļu?“. Tā izmanto arī raksturīgu formulējumu no V3, pārfrāzētu jautājumu, kā arī jautājumu, uz kuru iepriekš varēja atbildēt tikai ar V3. Tiks gaidīta vai nu pamatota atbilde no V4, vai skaidra norāde, ka nav pieejama apstiprināta informācija. Avota norāde uz V3, burtisks fragments vai atbilde bez pašreizējās atradnes tiek uzskatīta par kļūdu. Par to, kā avoti tiek padarīti redzami atbildēs, paskaidrots rakstā Čatbota atbilžu pamatošana ar avotiem.

Pārbaude, vai dzēšana tiešām darbojas

Ar zaļu API statusu nepietiek. Pārbaude jāveic vairākos līmeņos. Glabāšanas līmenī tiek meklēts pēc avota ID, fragmentu ID un zināmajām jaukšanas vērtībām. Izgūšanas līmenī tiek izpildīti testa jautājumi un kontrolētas atgrieztās atradnes. Atbilžu līmenī tiek pārbaudīts, vai vecais paziņojums vēl parādās vārds vārdā vai pēc būtības. Visbeidzot ir nepieciešams atkārtotas palaišanas tests: pēc pārmeklētāja darbības, indeksa pārbūves vai dublējuma atjaunošanas avots nedrīkst atgriezties.

Saglabājiet katrai kritiskajai zināšanu klasei nelielu zelta kopu (Golden Set) no pozitīvajiem un negatīvajiem gadījumiem. Pozitīvie gadījumi pierāda, ka aizstājošais avots tiek atrasts pareizi; negatīvie gadījumi rāda, ka bloķētā informācija vairs neparādās. Šī procedūra papildina tekošo QA aktīvas AI čatbota zināšanu bāzes uzturēšanai. Lielāku indeksa izmaiņu gadījumā palīdz arī paralēla pārbūve ar kontrolētu pārslēgšanu, kā aprakstīts rokasgrāmatā par RAG iegulšanas modeļa maiņu.

Pārbaudes lapa ikdienas ekspluatācijai

• Katram avotam ir stabils ID, versija, izcelsme, valoda un atbildīgais īpašnieks.
• Fragmenti, iegulšanas, indeksa dokumenti un kešatmiņas ir izsekojami līdz šim avota ID.
• Tombstone nekavējoties bloķē avotu izgūšanā un novērš atkārtotu importēšanu.
• Dzēšanas uzdevums darbojas idempotenti: atkārtošana nerada ne kļūdas, ne jaunus datu ierakstus.
• Fona procesi ziņo ne tikai „pieņemts“, bet pabeigtu statusu ar kļūdu detaļām.
• Izgūšanas un atbilžu kešatmiņas var selektīvi atsaukt vai atdalīt, izmantojot versijas.
• Tiešā meklēšana, semantiskā meklēšana, atbilžu tests un atkārtotas palaišanas tests ir dokumentēti.
• Dublējumiem un žurnāliem ir noteikti glabāšanas termiņi un process vēlākai atjaunošanai.
• Dzēšanas protokols satur tikai nepieciešamos metadatus un nekādas nevajadzīgas noņemtā satura kopijas.
• Atbildība, eskalācija un maksimālais apstrādes laiks ir noteikti un regulāri trenēti.

Nejaukt pārvaldību un datu aizsardzību

Tehniskā dzēšanas koncepcija atbild uz jautājumu, kā avots droši pazūd no aktīvās RAG ķēdes. Vai un kad tas ir jāizdzēš, ir cits jautājums. Vispārīgās datu aizsardzības regulas 17. pantā ir paredzētas tiesības uz dzēšanu pie noteiktiem nosacījumiem, kā arī izņēmumi. Vispārīgs paziņojums, piemēram, „katrs pieprasījums nekavējoties dzēš katru dublējumu“, tāpēc būtu tikpat riskants kā beztermiņa glabāšana bez mērķa. Noteicošais juridiskais pamats un termiņš ir jānosaka attiecīgajam lietošanas gadījumam; oficiālais regulas teksts ir pieejams vietnē EUR-Lex.

Organizatoriski šim procesam jāiekļaujas satura pārvaldībā (Content Governance): kas drīkst atsaukt saturu? Kas apstiprina attīrīšanu? Kas notiek, ja ārējais vektoru pakalpojums nav sasniedzams? Raksts AI čatbotu satura pārvaldība (Content Governance) parāda, kā sadarbojas īpašnieki, apstiprinājumi un izmaiņu kontrole. Lielu risku gadījumā ieteicams četru acu princips; parastajiem atjauninājumiem var pietikt ar automatizētu, pilnībā protokolētu darba plūsmu.

Oficiālie avoti un tehniskās atsauces

• Microsoft Learn: Izmainīto un izdzēsto objektu (blobs) atpazīšana Azure AI Search
• Microsoft Learn: Documents API priekš Azure AI Search
• Google Cloud: Failu un korpusu pārvaldība Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Vispārīgā datu aizsardzības regula

Secinājums: Dzēšamība ir kvalitātes funkcija

RAG zināšanu bāze ir uzticama tikai tad, ja saturu var ne tikai uzņemt, bet arī kontrolēti atsaukt. Stabili avotu ID, tombstone atzīmes, atkarību saraksti, versijās sadalītas kešatmiņas un atkārtojami testi pārvērš nedrošu vienreizēju darbību par pārvaldāmu procesu. Kurš šajā procesā apvieno funkcionālo apstiprināšanu, tehnisko attīrīšanu un pierādāmu kvalitātes nodrošināšanu, samazina novecojušas atbildes un rada pamatu čatbotam, kura zināšanas var apzināti vadīt.