RAG koncept brisanja za AI chatbotove: Uklanjanje sadržaja iz indeksa, predmemorije i odgovora

Cjenik je istekao, sigurnosna uputa je povučena ili klijent zahtijeva uklanjanje osobnih podataka. U izvornom sustavu dotična se datoteka brzo briše. Unatoč tome, chatbot na web stranici još minutama, satima ili čak dulje može pristupati starom sadržaju: kopija se možda nalazi u uvoznom području, datoteka je razbijena na više tekstualnih odlomaka, čiji se vektori (embeddings) nalaze u vektorskom indeksu, a predmemorija odgovora drži već formuliranu izjavu spremnom. Pouzdan RAG koncept brisanja stoga ne tretira samo izvornu datoteku, već čitav lanac derivacija.

Cilj pritom nije paušalno i odmah uništiti sve. Potreban je kontrolirani proces koji zastarjele ili povučene sadržaje bez odgađanja uklanja iz aktivne putanje odgovora, uzima u obzir zakonske i operativne obveze čuvanja te naknadno dokazuje da dohvaćanje (retrieval) i odgovori više ne koriste taj sadržaj. Upravo taj dokaz dijeli puko brisanje od pouzdanog operativnog postupka.

Zašto je brisanje u RAG sustavu višestupanjsko

Retrieval-Augmented Generation povezuje jezični model s vanjskim znanjem. Između izvora i odgovora nalazi se nekoliko tehničkih stanja: crawler ili prijenos, normalizirana datoteka, prepoznavanje teksta, segmenti (chunks), metapodaci, ugradnje (embeddings), vektorski i punotekstualni indeks, predmemorija upita, odabrana pronađena mjesta i iz njih generirani odgovor. Neki sustavi dodatno pohranjuju povijesti sesija, uzorke kvalitete ili zapise praćenja (traces). Ako se ukloni samo prvo stanje, nizvodne kopije i dalje mogu ostati dostupne.

Tome se pridodaje i problem vremena. Brisanje se može obraditi asinkrono dok usporedo pristižu novi upiti. Noćno ponovno indeksiranje u tom slučaju nije dovoljno: do njegova izvršavanja chatbot bi i dalje mogao izdavati povučenu informaciju. Obrnuto, kasniji uvoz ne smije slučajno obnoviti izvor. Zbog toga je svakom brisanju potrebna i brza blokada u putanji upita i potpuno čišćenje u pozadini.

Unaprijed jasno definirati opseg brisanja

Na početku stoji stabilan identitet izvora. Naziv datoteke ili URL sami po sebi često su preslabi jer se mogu promijeniti ili pojaviti više puta. Smisleni su interni ID izvora, verzija, klijent (tenant), jezik, područje pristupa i sažetak (hash) uvezenog sadržaja. Svaki segment (chunk) i svaki unos u indeksu mora se moći povezati s tim identitetom. Tek tada se može pouzdano utvrditi koje derivacije pripadaju određenom izvoru.

Nakon toga određuje se što "obrisano" znači u konkretnom slučaju. Za zastarjelu informaciju o proizvodu može biti dovoljno deaktivirati je iz aktivne baze znanja i zamijeniti novom verzijom. U slučaju opoziva, zahtjeva za zaštitu podataka ili isteka licencije, mogu biti zahvaćeni stroži rokovi i dodatne lokacije pohrane. Sigurnosne kopije, sigurnosni zapisnici i zakonom propisani dokazi često imaju vlastita pravila. Odluka bi stoga trebala uključiti voditelje podataka, operativni tim, a kod osobnih ili reguliranih sadržaja i pravni tim odnosno tim za zaštitu podataka.

Siguran tijek brisanja u sedam koraka

1. Zabilježiti i verificirati zahtjev: Zabilježite ID izvora, verziju, razlog, zatraženi rok, zahvaćene klijente i osobu ili ulogu koja je odobrila zahtjev. Kod osjetljivih brisanja mora se provjeriti ovlaštenje prije izmjene podataka.
2. Postaviti oznaku brisanja (tombstone): Odmah označite izvor kao blokiran. Filteri dohvaćanja (retrieval) moraju uzeti u obzir ovaj status kako pripadajući segmenti više ne bi dospjeli u nove odgovore, čak i ako fizičko čišćenje još traje.
3. Razriješiti ovisnosti: Utvrdite sirove kopije, rezultate parsiranja, segmente, ugradnje (embeddings), punotekstualne dokumente, predmemorije, unaprijed generirane gradivne blokove odgovora i eventualne skupove testnih podataka. ID izvora služi kao zajednički ključ.
4. Očistiti aktivne indekse: Izbrišite ili deaktivirajte sve zahvaćene zapise u vektorskom indeksu i indeksu ključnih riječi. Provjerite povratne poruke odgovarajuće usluge; prihvaćeni nalog još nije dokaz završenog brisanja.
5. Invalidirati predmemorije: Ciljano ispraznite predmemorije dohvaćanja, upita i odgovora. Gdje selektivna invalidacija nije moguća, pomažu ključevi verzija ili novi prostor imena (namespace), kako stari unosi više ne bi bili dostupni.
6. Izvršiti provjere i dokaze: Postavljajte upite koristeći poznate formulacije, naslove dokumenata, rijetke pojmove i semantički slične varijante. Izravno dohvaćanje putem ID-a izvora i nasumični uzorak u chatbotu trebaju ostati bez rezultata.
7. Završiti postupak: Spremite sažeti zapisnik o brisanju s vremenskom oznakom, opsegom, odgovorima sustava, rezultatom provjere i otvorenim rokovima čuvanja. Zapisnik treba dokazati postupak, ali ne i nepotrebno kopirati obrisani sadržaj.

Zašto tombstone dolazi prije fizičkog brisanja

Ovaj redoslijed sprječava dvije tipične pogreške. Kao prvo, crawler ne može uvijek uredno dodijeliti obrisanu izvornu datoteku postojećem unosu u indeksu. Neki indeksari očekuju signal mekog brisanja (soft-delete) sve dok je izvor još prepoznatljiv. Kao drugo, pokrenuti poslovi između brisanja izvora i čišćenja indeksa mogu ponovno zapisati podatke. Središnji tombstone blokira to ponovno preuzimanje. On bi se trebao zadržati čak i ako su sami korisni podaci već uklonjeni – ali samo s minimalno potrebnim metapodacima i jasnim rokom čuvanja.

Verzioniranje čini brisanje predmemorije upravljivim

Predmemorije su posebno podložne pogreškama ako se ključevi sastoje samo od korisničkog pitanja. Bolji je ključ koji dodatno sadrži verziju baze znanja, klijenta, jezik i kontekst ovlaštenja. Nakon brisanja verzija se povećava. Čak i ako pojedinačni unos u predmemoriji tehnički još postoji do svog isteka, aktivna ga aplikacija više ne može pogoditi. To ne zamjenjuje ciljanu invalidaciju u svakom slučaju, ali smanjuje rizik da se stari odgovori ponovno pojave.

HTTP predmemorije slijede pak vlastita pravila. Standard RFC 9111 opisuje kada su pohranjeni odgovori svježi, zastarjeli ili ih treba invalidirati. Za RAG aplikacije iz toga slijedi: predmemorije CDN-a, API-ja i aplikacije moraju se promatrati odvojeno. Nova verzija baze podataka sama po sebi ne prazni predmemoriju odgovora isporučenu na rubu mreže (edge).

Konkretan primjer: Povučene upute za montažu

Pretpostavimo da proizvođač povlači verziju 3 uputa za montažu jer je promijenjen jedan radni korak. Verzija 4 je već odobrena. Sustav odmah postavlja tombstone za izvor V3 i objavljuje V4 pod novim ID-om verzije. Retriever filtrira isključivo odobrene izvore i preferira aktualnu verziju. Usporedo s tim, radni proces (worker) uklanja sve V3 segmente iz vektorskog i punotekstualnog indeksa te invalidira predmemorije čiji popis ovisnosti sadrži taj ID izvora.

Osiguranje kvalitete sada ne postavlja samo pitanje "Kako montirati ovaj dio?". Koristi se i upečatljiva formulacija iz V3, parafrazirano pitanje kao i pitanje na koje se ranije moglo odgovoriti samo pomoću V3. Očekuje se ili potkrepljeni odgovor iz V4 ili jasna napomena da nema odobrenih informacija. Navođenje izvora V3, doslovni fragment ili odgovor bez aktualne izvorne reference smatra se pogreškom. Kako izvori u odgovorima postaju vidljivi objašnjeno je u članku Potkrepljivanje odgovora chatbota izvorima.

Provjera djeluje li brisanje uistinu

Zeleni API status nije dovoljan. Provjeru bi trebalo provesti na više razina. Na razini pohrane traži se prema ID-u izvora, ID-jevima segmenata i poznatim sažecima (hashes). Na razini dohvaćanja (retrieval) izvode se testna pitanja i kontroliraju vraćena pronađena mjesta. Na razini odgovora provjerava se pojavljuje li se stara izjava još uvijek doslovno ili smisleno. Naposljetku je potreban test ponovnog pokretanja: nakon prolaska crawlera, ponovne izgradnje indeksa ili vraćanja sigurnosne kopije, izvor se ne smije vratiti.

Za svaku kritičnu klasu znanja sačuvajte mali "Golden Set" pozitivnih i negativnih slučajeva. Pozitivni slučajevi dokazuju da je zamjenski izvor ispravno pronađen; negativni slučajevi pokazuju da se blokirane informacije više ne pojavljuju. Postupak dopunjuje tekući QA za održavanje baze znanja AI chatbota aktualnom. Kod većih izmjena indeksa pomaže i usporedna ponovna izgradnja s kontroliranim prebacivanjem, kako je opisano u vodiču o promjeni RAG embedding modela.

Kontrolni popis za svakodnevni rad

• Svaki izvor ima stabilan ID, verziju, podrijetlo, jezik i odgovornog vlasnika (owner).
• Segmenti, ugradnje (embeddings), indeksni dokumenti i predmemorije mogu se povezati s tim ID-om izvora.
• Tombstone odmah blokira izvor u dohvaćanju (retrieval) i sprječava ponovni uvoz.
• Nalog za brisanje radi idempotentno: ponavljanje ne stvara pogreške niti nove zapise.
• Radni procesi (workers) ne javljaju samo "prihvaćeno", već završeni status s detaljima pogreške.
• Predmemorije dohvaćanja i odgovora mogu se selektivno invalidirati ili odvojiti putem verzija.
• Izravno pretraživanje, semantičko pretraživanje, test odgovora i test ponovnog pokretanja su dokumentirani.
• Sigurnosne kopije i zapisnici imaju definirane rokove čuvanja i proces za kasnija vraćanja.
• Zapisnik o brisanju sadrži samo potrebne metapodatke i nema nepotrebnu kopiju uklonjenog sadržaja.
• Odgovornost, eskalacija i maksimalno vrijeme obrade definirani su i redovito se vježbaju.

Ne miješati upravljanje (governance) i zaštitu podataka

Tehnički koncept brisanja odgovara na pitanje kako izvor sigurno nestaje iz aktivne RAG putanje. Treba li i kada biti obrisan, drugo je pitanje. Opća uredba o zaštiti podataka u članku 17. sadrži pravo na brisanje pod određenim uvjetima, kao i iznimke. Paušalna izjava poput "svaki zahtjev odmah briše svaku sigurnosnu kopiju" stoga bi bila jednako rizična kao i neograničeno pohranjivanje bez svrhe. Mjerodavna pravna osnova i rok moraju se definirati za pojedini slučaj upotrebe; službeni tekst uredbe dostupan je putem EUR-Lexa.

Organizacijski, ovaj postupak spada u upravljanje sadržajem (Content Governance): Tko smije povući sadržaj? Tko potvrđuje čišćenje? Što se događa ako vanjska vektorska usluga nije dostupna? Članak Upravljanje sadržajem AI chatbota prikazuje kako vlasnici, odobrenja i kontrola promjena (Change Control) djeluju zajedno. Za visoke rizike preporučuje se princip četiriju očiju; za uobičajena ažuriranja može biti dovoljan automatizirani, potpuno zapisani radni tijek.

Službeni izvori i tehničke referencije

• Microsoft Learn: Otkrivanje promijenjenih i obrisanih blobova u Azure AI Searchu
• Microsoft Learn: Documents API za Azure AI Search
• Google Cloud: Upravljanje datotekama i korpusima u Vertex AI RAG Engineu
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Opća uredba o zaštiti podataka

Zaključak: Mogućnost brisanja je funkcija kvalitete

RAG baza znanja pouzdana je samo ako se sadržaji ne mogu samo dodavati, već i kontrolirano povlačiti. Stabilni ID-jevi izvora, tombstone oznake, popisi ovisnosti, verzionirane predmemorije i ponovljivi testovi pretvaraju nesigurnu pojedinačnu akciju u upravljiv proces. Tko pritom poveže stručno odobrenje, tehničko čišćenje i dokazivi QA, smanjuje zastarjele odgovore i stvara temelje za chatbot čijim se znanjem može svjesno upravljati.