Concept de ștergere RAG pentru chatboturi IA: Eliminarea conținutului din index, cache și răspunsuri

O fișă de prețuri a expirat, o instrucțiune de siguranță a fost retrasă sau un client solicită eliminarea datelor cu caracter personal. În sistemul sursă, fișierul respectiv este șters rapid. Cu toate acestea, un chatbot de pe un site web poate accesa în continuare vechiul conținut timp de minute, ore sau chiar mai mult: o copie s-ar putea afla în zona de import, fișierul a fost divizat în mai multe fragmente de text, embedding-urile acestora se află în indexul vectorial, iar un cache de răspunsuri păstrează o afirmație deja formulată. Prin urmare, un concept robust de ștergere RAG nu tratează doar fișierul sursă, ci întreaga linie de derivare.

Scopul nu este de a distruge totul în mod neselectiv și imediat. Este nevoie de un proces controlat care să elimine neîntârziat conținutul învechit sau retras din fluxul activ de răspunsuri, să ia în considerare obligațiile legale și operaționale de păstrare a datelor și apoi să dovedească faptul că procesele de căutare (retrieval) și răspunsurile nu mai utilizează acel conținut. Tocmai această dovadă separă o simplă acțiune de ștergere de o procedură operațională de încredere.

De ce ștergerea într-un sistem RAG are mai multe etape

Retrieval-Augmented Generation conectează un model de limbaj cu cunoștințe externe. Între sursa originală și răspuns există mai multe stări tehnice: crawler sau încărcare, fișier normalizat, recunoaștere de text, fragmente (chunks), metadata, embedding-uri, index vectorial și full-text, cache de interogări, rezultate selectate și răspunsul generat din acestea. Unele sisteme stochează suplimentar istoricul sesiunilor, eșantioane de calitate sau urme (traces). Dacă este eliminată doar prima stare, copiile din aval pot rămâne în continuare accesibile.

La aceasta se adaugă o problemă de timp. O ștergere poate fi procesată asincron, în timp ce în paralel sosesc noi interogări. Prin urmare, o reindexare nocturnă nu este suficientă: până la executarea acesteia, chatbotul ar putea continua să ofere informația retrasă. Invers, un import ulterior nu trebuie să restaureze accidental sursa. De aceea, fiecare ștergere are nevoie atât de o blocare rapidă pe calea interogării, cât și de o curățare completă în fundal.

Definirea clară și prealabilă a domeniului de ștergere

La început se află o identitate stabilă a sursei. Numele fișierului sau URL-ul singure sunt adesea prea slabe, deoarece se pot schimba sau pot apărea de mai multe ori. Sunt recomandate un ID intern al sursei, versiunea, tenant-ul, limba, domeniul de acces și un hash al conținutului importat. Fiecare fragment (chunk) și fiecare intrare din index trebuie să poată fi trasate înapoi la această identitate. Abia atunci se poate determina cu precizie ce derivate aparțin unei surse.

Apoi se stabilește ce înseamnă „șters” în cazul concret. Pentru o informație despre un produs care este învechită, poate fi suficientă dezactivarea acesteia din baza de cunoștințe activă și înlocuirea ei cu o versiune nouă. În cazul unei revocări, al unei solicitări privind protecția datelor sau al încheierii unei licențe, pot fi afectate termene mai stricte și locații de stocare suplimentare. Copiile de rezervă (backups), jurnalele de securitate și dovezile solicitate prin lege au adesea propriile reguli. Decizia ar trebui, prin urmare, să implice responsabilii cu datele, echipa de operațiuni și, în cazul conținutului cu date cu caracter personal sau reglementat, departamentul de protecție a datelor sau cel juridic.

Un flux de ștergere sigur în șapte pași

1. Înregistrarea și verificarea solicitării: Notați ID-ul sursei, versiunea, motivul, termenul solicitat, tenant-ii afectați și persoana sau rolul care a aprobat. În cazul ștergerilor sensibile, autorizarea trebuie verificată înainte de modificarea datelor.
2. Setarea unui tombstone: Marcați imediat sursa ca fiind blocată. Filtrele de căutare (retrieval) trebuie să ia în considerare acest statut, astfel încât fragmentele asociate să nu mai ajungă în răspunsuri noi, chiar dacă curățarea fizică este încă în desfășurare.
3. Rezolvarea dependențelor: Identificați copiile brute, rezultatele parser-ului, fragmentele (chunks), embedding-urile, documentele full-text, cache-urile, componentele de răspuns generate în avans și, dacă este cazul, seturile de date de test. ID-ul sursei servește drept cheie comună.
4. Curățarea indicilor activi: Ștergeți sau dezactivați toate înregistrările afectate din indexul vectorial și cel de cuvinte cheie. Verificați răspunsurile serviciului respectiv; o sarcină acceptată nu este încă o dovadă a ștergerii finalizate.
5. Invalidarea cache-urilor: Goliți în mod țintit cache-urile de căutare (retrieval), interogare și răspuns. Unde invalidarea selectivă nu este posibilă, cheile de versiune sau un nou namespace ajută la blocarea accesului la intrările vechi.
6. Executarea dovezilor: Interogați folosind formulări cunoscute, titluri de documente, termeni rari și variante semantic similare. O preluare directă prin ID-ul sursei și un eșantion în chatbot ar trebui ambele să nu returneze niciun rezultat.
7. Finalizarea procesului: Salvați un jurnal scurt de ștergere cu momentul, volumul, răspunsurile sistemului, rezultatul verificării și termenele de păstrare deschise. Jurnalul trebuie să dovedească procesul, dar fără a copia inutil conținutul șters.

De ce tombstone-ul este plasat înaintea ștergerii fizice

Această ordine previne două erori tipice. În primul rând, un crawler nu poate asocia întotdeauna curat un fișier sursă șters cu o intrare existentă din index. Unii indexatori așteaptă un semnal de soft-delete atâta timp cât sursa este încă identificabilă. În al doilea rând, joburile în derulare pot scrie din nou date între ștergerea sursei și curățarea indexului. Un tombstone central blochează această reluare. Acesta ar trebui păstrat chiar dacă datele utile reale au fost deja eliminate – însă doar cu metadatele minim necesare și cu un termen clar de păstrare.

Versionarea face gestionarea ștergerii din cache controlabilă

Cache-urile sunt deosebit de predispuse la erori atunci când cheile constau doar din întrebarea utilizatorului. Este mai bună o cheie care conține în plus versiunea bazei de cunoștințe, tenant-ul, limba și contextul de autorizare. După o ștergere, versiunea este incrementată. Chiar dacă o intrare individuală din cache mai există tehnic până la expirarea sa, aplicația activă nu o mai poate accesa. Acest lucru nu înlocuiește invalidarea țintită în fiecare caz, dar reduce riscul ca vechile răspunsuri să reapară.

Cache-urile HTTP urmează, la rândul lor, propriile reguli. Standardul RFC 9111 descrie momentul în care răspunsurile stocate sunt proaspete, învechite sau trebuie invalidate. Pentru aplicațiile RAG, din aceasta rezultă că: cache-ul CDN, API și cel de aplicație trebuie privite separat. O nouă versiune de bază de date singură nu golește un cache de răspunsuri furnizat la margine (edge).

Exemplu concret: Instrucțiuni de asamblare retrase

Să presupunem că un producător retrage versiunea 3 a unor instrucțiuni de asamblare deoarece un pas de lucru a fost modificat. Versiunea 4 este deja aprobată. Sistemul setează imediat un tombstone pentru sursa V3 și publică V4 sub un nou ID de versiune. Modulul de căutare (retriever) filtrează exclusiv sursele aprobate și preferă versiunea actuală. În paralel, un worker elimină toate fragmentele V3 din indexul vectorial și full-text și invalidează cache-urile a căror listă de dependențe conține acest ID de sursă.

Asigurarea calității nu adresează acum doar întrebarea „Cum asamblez piesa?”. Utilizează și o formulare distinctă din V3, o întrebare parafrazată, precum și o întrebare la care anterior se putea răspunde doar cu V3. Se așteaptă fie răspunsul justificat din V4, fie o indicație clară că nu există informații aprobate. Indicarea unei surse V3, un fragment literal sau un răspuns fără un rezultat actual este considerată o eroare. Modul în care sursele sunt făcute vizibile în răspunsuri este explicat în articolul Justificarea răspunsurilor chatbotului cu surse.

Verificarea dacă ștergerea chiar funcționează

Un statut API verde nu este suficient. Verificarea ar trebui să aibă loc pe mai multe niveluri. La nivelul de stocare se caută după ID-ul sursei, ID-urile fragmentelor și hash-urile cunoscute. La nivelul de căutare (retrieval) se execută întrebări de test și se controlează rezultatele returnate. La nivelul de răspuns se verifică dacă vechea afirmație mai apare literal sau ca sens. În cele din urmă, este nevoie de un test de repornire: după o rulare a crawler-ului, o reconstrucție a indexului sau restaurarea unui backup, sursa nu trebuie să revină.

Păstrați pentru fiecare clasă critică de cunoștințe un mic Golden Set format din cazuri pozitive și negative. Cazurile pozitive dovedesc că sursa de înlocuire este găsită corect; cazurile negative arată că informațiile blocate nu mai apar. Procedura completează activitatea curentă de QA pentru menținerea la zi a bazei de cunoștințe a chatbotului IA. În cazul modificărilor majore de index, ajută și o reconstrucție paralelă cu comutare controlată, așa cum este descris în ghidul despre schimbarea unui model de embedding RAG.

Listă de verificare pentru activitatea operațională zilnică

• Fiecare sursă deține un ID stabil, versiune, origine, limbă și un proprietar (owner) responsabil.
• Fragmentele, embedding-urile, documentele din index și cache-urile pot fi trasate înapoi la acest ID de sursă.
• Un tombstone blochează imediat sursa în căutare (retrieval) și previne un nou import.
• Ordinul de ștergere rulează de manieră idempotentă: o repetare nu generează erori și nici înregistrări noi.
• Worker-ele nu raportează doar „acceptat”, ci un statut finalizat cu detalii despre erori.
• Cache-urile de căutare și răspuns pot fi invalidate selectiv sau decuplate prin intermediul versiunilor.
• Căutarea directă, căutarea semantică, testul de răspuns și testul de repornire sunt documentate.
• Backup-urile și jurnalele au termene definite de păstrare și un proces pentru restaurări ulterioare.
• Jurnalul de ștergere conține doar metadatele necesare și nicio copie inutilă a conținutului eliminat.
• Responsabilitatea, escaladarea și timpul maxim de procesare sunt stabilite și exersate regulat.

Nu confundați guvernanța cu protecția datelor

Un concept tehnic de ștergere răspunde la întrebarea cum dispare o sursă în siguranță din traseul activ RAG. Dacă și când trebuie șters un conținut este o altă întrebare. Regulamentul general privind protecția datelor (GDPR) conține în Articolul 17 un drept la ștergere („dreptul de a fi uitat”) în anumite condiții, precum și excepții. Prin urmare, o afirmație generală precum „fiecare solicitare șterge imediat orice backup” ar fi la fel de riscantă ca o stocare pe termen nelimitat fără un scop clar. Temeiul juridic aplicabil și termenul trebuie stabilite pentru fiecare caz de utilizare; textul oficial al regulamentului este disponibil prin EUR-Lex.

Din punct de vedere organizatoric, fluxul aparține de Content Governance: Cine are voie să retragă conținuturi? Cine confirmă curățarea? Ce se întâmplă dacă un serviciu vectorial extern nu este accesibil? Articolul Content Governance pentru chatboturi IA arată cum interacționează proprietarii, aprobările și Change Control. Pentru riscuri mari se recomandă principiul celor patru ochi; pentru actualizări normale, un flux de lucru automatizat și complet înregistrat poate fi suficient.

Surse oficiale și referințe tehnice

• Microsoft Learn: Detectarea blob-urilor modificate și șterse în Azure AI Search
• Microsoft Learn: Documents API pentru Azure AI Search
• Google Cloud: Administrarea fișierelor și corpusurilor în Vertex AI RAG Engine
• RFC Editor: RFC 9111 – HTTP Caching
• NIST: Artificial Intelligence Risk Management Framework – Generative AI Profile
• EUR-Lex: Regulamentul general privind protecția datelor

Concluzie: Posibilitatea de ștergere este o funcție de calitate

O bază de cunoștințe RAG este de încredere doar dacă conținuturile nu sunt doar preluate, ci pot fi și retrase în mod controlat. ID-urile stabile de sursă, tombstone-urile, listele de dependențe, cache-urile versionate și testele repetabile transformă o acțiune individuală nesigură într-un proces ușor de gestionat. Cei care combină aprobarea funcțională, curățarea tehnică și un QA dovedibil reduc răspunsurile învechite și creează temelia pentru un chatbot ale cărui cunoștințe pot fi dirijate în mod conștient.