Koncept brisanja RAG za klepetalnike z UI: Odstranjevanje vsebin iz indeksa, predpomnilnika in odgovorov

Cenik je potekel, varnostna navodila so bila umaknjena ali pa stranka zahteva odstranitev osebnih podatkov. V izvirnem sistemu je zadevna datoteka hitro izbrisana. Kljub temu lahko spletni klepetalnik še minute, ure ali celo dlje časa dostopa do starih vsebin: kopija se morda nahaja v uvoznem območju, datoteka je bila razdeljena na več besedilnih izsekov (chunks), njihove vložiteve (embeddings) so v vektorskem indeksu, predpomnilnik odgovorov pa ima že pripravljeno formulirano izjavo. Zanesljiv koncept brisanja RAG zato ne obravnava le izvirne datoteke, temveč celotno verigo izpeljav.

Cilj pri tem ni paušalno in takojšnje uničenje vsega. Potreben je nadzorovan proces, ki zastarele ali umaknjene vsebine nemudoma izključi iz aktivne poti odgovarjanja, upošteva zakonske in poslovne obveznosti hrambe ter naknadno dokaže, da pridobivanje (retrieval) in odgovori te vsebine več ne uporabljajo. Prav to dokazilo ločuje zgolj dejanje brisanja od zanesljivega operativnega postopka.

Zakaj je brisanje v sistemu RAG večstopenjsko

Retrieval-Augmented Generation povezuje jezikovni model z zunanjim znanjem. Med izvirnim virom in odgovorom obstaja več tehničnih stanj: spletni pajek ali nalaganje, normalizirana datoteka, prepoznavanje besedila, izseki (chunks), metapodatki, vložiteve (embeddings), vektorski in polnobesedilni indeks, predpomnilnik poizvedb, izbrana najdena mesta ter iz njih ustvarjen odgovor. Nekateri sistemi dodatno shranjujejo poteke sej, vzorce kakovosti ali sledi (traces). Če odstranite le prvo stanje, lahko kasnejše kopije še naprej ostanejo dostopne.

K temu prispeva še časovna težava. Brisanje se lahko obdeluje asinhrono, medtem ko vzporedno prispejo nove poizvedbe. Nočna ponovna indeksacija takrat ne zadošča: do njenega izvajanja bi klepetalnik lahko še naprej posredoval umaknjene informacije. Nasprotno pa poznejši uvoz ne sme pomotoma obnoviti vira. Zato vsako brisanje potrebuje tako hitro blokado na poti poizvedbe kot tudi popolno čiščenje v ozadju.

Vnaprej jasno določite obseg brisanja

Na začetku stoji stabilna identiteta vira. Ime datoteke ali URL sta pogosto prešibka, saj se lahko spremenita ali ponovita. Smiselni so interni ID vira, različica, tenant (najemnik), jezik, območje dostopa in zgoščevalna vrednost (hash) uvožene vsebine. Vsak izsek in vsak vnos v indeksu mora biti mogoče izslediti do te identitete. Šele takrat je mogoče zanesljivo ugotoviti, katere izpeljave pripadajo določenemu viru.

Nato se določi, kaj "izbrisano" pomeni v konkretnem primeru. Za zastarelo informacijo o izdelku lahko zadošča, da jo deaktivirate iz aktivne zbirke znanja in nadomestite z novo različico. Pri preklicu, zahtevi glede varstva podatkov ali poteku licence pa veljajo strožji roki in so lahko prizadeta dodatna mesta shranjevanja. Varnostne kopije, varnostni dnevniki in zakonsko zahtevana dokazila imajo pogosto lastna pravila. Odločitev mora zato vključevati skrbnike podatkov, operativno službo ter pri osebnih ali reguliranih vsebinah tudi službo za varstvo podatkov oziroma pravno službo.

Varno zaporedje brisanja v sedmih korakih

1. Zajem in preverjanje zahteve: Zapišite ID vira, različico, razlog, zahtevani rok, prizadete najemnike ter osebo ali vlogo, ki je brisanje odobrila. Pri občutljivih brisanjih je treba preveriti pooblastilo, preden se podatki spremenijo.
2. Nastavitev tombstone oznake: Vir takoj označite kot blokiran. Filtri pridobivanja morajo upoštevati ta status, da pripadajoči izseki ne pridejo več v nove odgovore, tudi če fizično čiščenje še poteka.
3. Razrešitev odvisnosti: Ugotovite surove kopije, rezultate razčlenjevalnika (parser), izseke, vložiteve, polnobesedilne dokumente, predpomnilnike, vnaprej ustvarjene gradnike odgovorov in po potrebi testne nabore podatkov. ID vira služi kot skupni ključ.
4. Čiščenje aktivnih indeksov: Izbrišite ali deaktivirajte vse prizadete zapise v vektorskem indeksu in indeksu ključnih besed. Preverite odzive posamezne storitve; sprejeto naročilo še ni dokaz o zaključenem brisanju.
5. Neveljavnost predpomnilnikov (cache invalidation): Ciljno izpraznite predpomnilnike pridobivanja, poizvedb in odgovorov. Kjer selektivna razveljavitev ni mogoča, pomagajo ključi različic ali nov imenski prostor (namespace), da stari vnosi niso več dostopni.
6. Izvedba dokazil: Izvedite poizvedbe z znanimi formulacijami, naslovi dokumentov, redkimi izrazi in semantično podobnimi različicami. Neposreden dostop preko ID vira in vzorčni test v klepetalniku morata oba ostati brez rezultatov.
7. Zaključek postopka: Shranite kratek protokol o brisanju s časom, obsegom, sistemskimi odzivi, rezultati preverjanja in odprtimi roki hrambe. Protokol mora dokazovati postopek, ne pa po nepotrebnem kopirati izbrisane vsebine.

Zakaj je tombstone postavljen pred fizičnim brisanjem

To zaporedje preprečuje dve tipični napaki. Prvič, spletni pajek izbrisane izvirne datoteke ne more vedno čisto dodeliti obstoječemu vnosu v indeksu. Nekateri indeksatorji pričakujejo signal za mehko brisanje (soft-delete), dokler je vir še prepoznaven. Drugič, tekoča opravila lahko med brisanjem vira in čiščenjem indeksa znova zapišejo podatke. Centralni tombstone blokira to ponovno zajemanje. Ostati mora celo takrat, ko so sami uporabni podatki že odstranjeni – vendar le z minimalno potrebnimi metapodatki in jasnim rokom hrambe.

Verzioniranje omogoča nadzor nad brisanjem predpomnilnika

Predpomnilniki so še posebej nagnjeni k napakam, če so ključi sestavljeni le iz uporabniškega vprašanja. Boljši je ključ, ki dodatno vsebuje različico zbirke znanja, najemnika, jezik in kontekst dovoljenj. Po brisanju se različica poveča. Tudi če posamezen vnos v predpomnilniku tehnično še obstaja do svojega poteka, ga aktivna aplikacija več ne more zadeti. To ne nadomešča ciljne razveljavitve v vsakem primeru, vendar zmanjšuje tveganje, da bi se stari odgovori znova pojavili.

Predpomnilniki HTTP sledijo lastnim pravilom. Standard RFC 9111 opisuje, kdaj so shranjeni odgovori sveži, zastareli ali jih je treba razveljaviti. Za aplikacije RAG iz tega izhaja: predpomnilnike CDN, API in aplikacij je treba obravnavati ločeno. Nova različica podatkovne baze sama po sebi ne izprazni predpomnilnika odgovorov, ki se streže na robu omrežja (edge).

Konkreten primer: Umaknjena navodila za montažo

Predpostavimo, da proizvajalec umakne različico 3 navodil za montažo, ker se je spremenil delovni korak. Različica 4 je že odobrena. Sistem za vir V3 takoj nastavi tombstone in objavi V4 pod novim ID-jem različice. Retriever filtrira izključno odobrene vire in daje prednost trenutni različici. Vzporedno delovni procesor (worker) odstrani vse izseke V3 iz vektorskega in polnobesedilnega indeksa ter razveljavi predpomnilnike, katerih seznam odvisnosti vsebuje ta ID vira.

Zagotavljanje kakovosti zdaj ne postavi le vprašanja "Kako namestim to komponento?". Uporabi tudi izstopajočo formulacijo iz V3, parafrazirano vprašanje ter vprašanje, na katerega je bilo prej mogoče odgovoriti le z V3. Pričakuje se ali utemeljen odgovor iz V4 ali pa jasno opozorilo, da odobrena informacija ni na voljo. Navedba vira V3, dobesedni fragment ali odgovor brez trenutnega najdenega mesta velja za napako. Kako so viri vidni v odgovorih, pojasnjuje prispevek Dokazovanje odgovorov klepetalnika z viri.

Preverjanje, ali brisanje resnično deluje

Zeleni status API ne zadošča. Preverjanje mora potekati na več ravneh. Na ravni shranjevanja se išče po ID vira, ID izsekov in znanih zgoščevalnih vrednostih. Na ravni pridobivanja se izvedejo testna vprašanja in preverijo vrnjena mesta najdb. Na ravni odgovora se preveri, ali se stara izjava še vedno pojavlja dobesedno ali po smislu. Na koncu je potreben test ponovnega zagona: po teku spletnega pajka, ponovni gradnji indeksa ali obnovitvi varnostne kopije se vir ne sme vrniti.

Za vsak kritični razred znanja hranite majhen zlati nabor (Golden Set) pozitivnih in negativnih primerov. Pozitivni primeri dokazujejo, da je nadomestni vir pravilno najden; negativni primeri pa kažejo, da se blokirane informacije ne pojavljajo več. Postopek dopolnjuje tekoče QA za vzdrževanje aktualne zbirke znanja UI klepetalnika. Pri večjih spremembah indeksa pomaga tudi vzporedna ponovna izgradnja s krmiljenim preklopom, kot je opisano v vodniku o zamenjavi modela RAG embeddings.

Kontrolni seznam za vsakodnevno delovanje

• Vsak vir ima stabilen ID, različico, izvor, jezik in odgovornega lastnika (owner).
• Izseke, vložiteve, indeksne dokumente in predpomnilnike je mogoče izslediti do tega ID vira.
• Tombstone takoj blokira vir pri pridobivanju in preprečuje ponovni uvoz.
• Naročilo za brisanje poteka idempotentno: ponovitev ne ustvari niti napak niti novih zapisov.
• Delovni procesorji (workers) ne sporočajo le "sprejeto", temveč zaključen status s podrobnostmi o napakah.
• Predpomnilnike pridobivanja in odgovorov je mogoče selektivno razveljaviti ali odklopiti preko različic.
• Neposredno iskanje, semantično iskanje, test odgovorov in test ponovnega zagona so dokumentirani.
• Varnostne kopije in dnevniki imajo določene roke hrambe in proces za kasnejše obnovitve.
• Protokol o brisanju vsebuje le potrebne metapodatke in ne odvečnih kopij odstranjene vsebine.
• Odgovornost, eskalacija in največji čas obdelave so določeni in se redno vadijo.

Ne mešajte upravljanja (Governance) in varstva podatkov

Tehnični koncept brisanja odgovarja na vprašanje, kako vir varno izgine iz aktivne verige RAG. Ali in kdaj mora biti izbrisan, pa je drugo vprašanje. Splošna uredba o varstvu podatkov (GDPR) v členu 17 vsebuje pravico do izbrisa pod določenimi pogoji in prav tako izjeme. Paušalna izjava, kot je "vsaka zahteva takoj izbriše vsako varnostno kopijo", bi bila zato enako tvegana kot neomejeno shranjevanje brez namena. Merodajna pravna podlaga in rok morata biti določena za posamezen primer uporabe; uradno besedilo uredbe je na voljo na EUR-Lex.

Organizacijsko spada postopek v upravljanje vsebin (Content Governance): Kdo sme umakniti vsebine? Kdo potrdi čiščenje? Kaj se zgodi, če zunanja vektorska storitev ni dosegljiva? Prispevek Upravljanje vsebin klepetalnika z UI prikazuje, kako medsebojno delujejo lastniki, odobritve in nadzor sprememb (Change Control). Za visoka tveganja se priporoča načelo štirih oči; za običajne posodobitve lahko zadošča avtomatiziran, popolnoma protokoliran delovni tok (workflow).

Uradni viri in tehnične reference

• Microsoft Learn: Zaznavanje spremenjenih in izbrisanih blobov v Azure AI Search
• Microsoft Learn: Documents API za Azure AI Search
• Google Cloud: Upravljanje datotek in korpusov v Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Splošna uredba o varstvu podatkov

Zaključek: Zmožnost brisanja je funkcija kakovosti

Zbirka znanja RAG je zanesljiva le, če vsebine ni mogoče le dodati, temveč tudi nadzorovano umakniti. Stabilni ID-ji virov, tombstone oznake, seznami odvisnosti, verzionirani predpomnilniki in ponovljivi testi spremenijo negotovo enkratno akcijo v obvladljiv proces. Kdor pri tem povezuje strokovno odobritev, tehnično čiščenje in dokazljivo zagotavljanje kakovosti, zmanjšuje zastarele odgovore in ustvarja podlago za klepetalnik, katerega znanje je mogoče zavestno usmerjati.