Prevenirea otrăvirii datelor RAG: proveniența surselor, carantina și testele de reindexare

Un chatbot pentru site-uri web poate oferi un răspuns politicos, convingător din punct de vedere lingvistic și corect generat tehnic — și totuși să funcționeze pe o bază de cunoștințe otrăvită. În cazul otrăvirii datelor RAG, nu este manipulată în primul rând formularea unei cereri individuale. În schimb, conținuturi false, denaturate sau insuficient verificate ajung în lanțul permanent de date: sursă, parser, chunk, metadate, embedding și, în final, indexul de regăsire din producție. Eroarea persistă astfel de-a lungul multor sesiuni și poate influența chiar și întrebările obișnuite.

Prin urmare, o protecție eficientă începe cu mult înainte de prompt. Echipele trebuie să poată răspunde pentru fiecare fragment de cunoștințe: de unde provine, cine este responsabil, ce versiune a fost procesată, ce transformări au avut loc și prin ce verificare a fost aprobat pentru căutare? Proveniența surselor oferă această trasabilitate. O carantină izolată tehnic poate preveni ca modificările neverificate să devină imediat accesibile. Testele de reindexare vizate verifică apoi dacă conținuturile curățate au înlocuit într-adevăr vechile chunk-uri.

Ce este otrăvirea datelor RAG — și ce nu este

Clasificarea OWASP LLM04:2025 privind Data and Model Poisoning descrie manipulările datelor de pre-antrenare, fine-tuning sau embedding drept un risc de integritate. Pentru un chatbot de site web, ultima variantă este deosebit de concretă: un document este ingerat și împărțit în secțiuni; aceste chunk-uri sunt convertite în vectori (embeddings) și salvate în indexul de regăsire. Dacă acest document este falsificat intenționat sau accidental, el poate apărea la întrebările potrivite ca fiind o bază aparent relevantă.

Riscurile trebuie diferențiate, dar se pot suprapune: Prompt Injection încearcă să introducă instrucțiuni sau date la momentul executării, astfel încât sistemul să își schimbe comportamentul prevăzut; Prompt Injection indirectă poate ajunge în context și prin intermediul documentelor regăsite. Pe de altă parte, otrăvirea datelor modifică fondul durabil de cunoștințe sau derivatele acestuia. Drepturile de acces rezolvă o altă problemă: ele stabilesc ce persoană are voie să vadă un document. Proveniența și aprobarea determină dacă acel document trebuie să ajungă în index ca o sursă de cunoștințe de încredere. Într-o arhitectură robustă, toate cele trei riscuri au nevoie de controale proprii și tranziții coordonate.

Suprafața de atac acoperă întregul lanț de date

Un index RAG se formează rareori dintr-o singură colecție verificată manual. Crawlerii citesc pagini web, conectorii sincronizează foldere din cloud, utilizatorii încarcă fișiere, iar interfețele importă date despre produse. La acestea se adaugă parsere, OCR, curățarea limbajului, fragmentarea (chunking) și îmbogățirea cu metadate. Fiecare etapă poate prelua conținuturi eronate sau poate scoate o afirmație inițial corectă din contextul ei.

Cauzele tipice sunt un sistem sursă compromis, un document oglindă către care a fost adăugat recent un link, un fișier ciornă publicat accidental, un tenant alocat greșit sau o actualizare de parser care atribuie valorile dintr-un tabel unor antete greșite. Compararea unui hash de conținut criptografic cu o valoare de referință de încredere poate detecta abaterile; un hash identic nu dovedește însă nici adevărul, nici actualitatea și nici aprobarea conținutului.

Proveniența ca set de date verificabil

Fiecare document și fiecare chunk derivat din el ar trebui să conțină un set de date de proveniență. În practică, sunt utile cel puțin: un ID stabil al sursei, URL-ul de origine canonic, proprietarul responsabil (owner), momentul preluării, versiunea documentului, hash-ul conținutului, statusul de aprobare, clasa de încredere, versiunea parserului, versiunea de chunking, modelul de embedding și generația indexului. În cazul încărcărilor manuale, se adaugă rolul persoanei care încarcă și licența verificată. La sistemele sincronizate este de asemenea important prin ce conector autentificat a sosit fișierul.

Ghidul NIST AI 600-1 Generative AI Profile abordează proveniența conținutului (Content Provenance), documentația trasabilă, precum și testele și evaluările ca elemente esențiale ale managementului riscului în IA generativă. Transpus în sistemele RAG, acest lucru înseamnă că nu contează doar indexul actual. Din documentația de exploatare face parte și relația clară dintre revizia sursei, rularea procesării și generația de index publicată.

O carantină separă ingestia de publicare

Un element arhitectural central este separarea consecventă: conținuturile noi sau modificate nu devin direct căutabile. Ele ajung mai întâi într-o zonă de ingestie. Acolo, pipeline-ul validează originea, tipul de fișier, dimensiunea, semnătura sau hash-ul așteptat, tenant-ul permis, completitudinea metadatelor și amploarea modificării. Abia după aceea, textul și chunk-urile sunt generate într-o generație de index neproductivă.

Regulile ar trebui să se bazeze pe evaluarea riscurilor. O modificare pe o pagină de FAQ internă, autentificată și aflată în responsabilitate directă, poate fi aprobată în urma unor teste automate. Un domeniu nou, o modificare de text neobișnuit de mare, un proprietar de fișier necunoscut sau o sursă fără o persoană responsabilă declanșează însă carantina și verificarea umană. Dacă lipsește o informație obligatorie, se aplică principiul „fail closed”: vechea generație confirmată rămâne activă; noua versiune nu este publicată în mod tacit.

Aprobarea ca generație imutabilă de index

După verificare, nu se suprascrie treptat un index de producție. Este preferabilă o generație nouă, versionată, prevăzută cu manifest: documente așteptate, chunk-uri așteptate, hash-uri sursă, versiuni de transformare și amprente temporale. Abia când testele sunt verzi, un alias sau o configurație de rutare comută atomic către această generație. Generația anterioară rămâne disponibilă pentru rollback pentru o perioadă limitată și definită.

Procedura se aseamănă cu o migrare controlată. Articolul nostru despre schimbarea unui model de embedding RAG arată de ce generațiile paralele de indici și testele comparative sunt utile și în cazul modificărilor tehnice. În cazul unei suspiciuni de otrăvire, se adaugă întrebarea de securitate: ce revizie sursă și ce chunk-uri derivate trebuie blocate?

Scenariu ipotetic: Un termen de retur eronat ajunge la botul de suport

Să presupunem că un comerciant operează un chatbot pentru întrebări despre produse și servicii. Baza de cunoștințe sincronizează în fiecare noapte centrul oficial de ajutor și câteva portaluri de producători aprobate. În urma unei modificări de link, un conector urmărește o redirecționare către o pagină oglindă neaprobată. Acolo, într-un PDF cu aspect plauzibil, se află un termen de retur de 90 de zile în loc de 30. Fișierul este spart în chunk-uri; mai multe secțiuni ajung în index cu o similaritate semantică ridicată.

A doua zi dimineață, botul promite termenul greșit la întrebările despre retur. Modelul de limbaj nu a fost reprogramat și utilizatorii nu au introdus nicio instrucțiune dăunătoare. Procesul de regăsire (retrieval) oferă pur și simplu o bază incorectă. Monitorizarea declanșează o alertă deoarece un domeniu nou apare pentru prima dată ca sursă de răspuns, iar un test din Golden Set pentru termenul de retur se abate de la referința așteptată.

Carantina controlată și repornirea

1. Echipa oprește doar sursa de ingestie afectată și blochează generația actuală de index pentru alte modificări.
2. ID-ul documentului suspect, toate ID-urile chunk-urilor derivate din acesta și aparițiile lor în răspunsuri sunt consemnate în jurnalul incidentului.
3. Domeniul oglindă este blocat, iar chunk-urile sale sunt mutate în carantină. Pentru întrebările legate de termenul de retur, botul oferă temporar un mesaj sigur care direcționează utilizatorul către asistență umană sau către pagina cu politica confirmată.
4. Alias-ul este comutat înapoi la ultima generație de index dovedit curată. Astfel, celelalte domenii de cunoștințe neafectate rămân disponibile.
5. Conectorul este restricționat la sursa canonică. Apoi, pipeline-ul construiește o generație nouă din manifestul confirmat.
6. Această generație trece în producție numai după testele de reindexare și o aprobare de specialitate.

Această succesiune limitează daunele fără a opri prematur întregul chatbot. Legătura dintre datele de origine și derivate este decisivă: fără asocierea dintre document și chunk-uri, nu ar fi clar ce vectori trebuie eliminați.

Testele de reindexare trebuie să arate mai mult decât un pipeline executat cu succes

O stare de execuție verde atestă doar că procesul s-a încheiat din punct de vedere tehnic. Ea nu dovedește nici că vechile chunk-uri au dispărut, nici că sursele corecte câștigă la întrebări realiste. De aceea, o suită de teste robustă verifică inventarul, regăsirea și comportamentul de răspuns.

1. Verificarea manifestului și a ștergerilor

Comparați noua generație cu manifestul aprobat. Fiecare versiune de document așteptată trebuie să fie prezentă; ID-urile de documente și chunk-uri blocate nu au voie să apară. Deosebit de importante sunt marcajele de tip „tombstone” pentru conținuturile șterse sau înlocuite. O simplă adăugare de noi embeddings ar lăsa altfel vechile rezultate otrăvite în index.

2. Teste de regăsire cu surse așteptate

Pentru întrebările critice, un text de răspuns așteptat nu este suficient. Definiți suplimentar ID-uri de surse permise și interzise, un număr minim de rezultate și condiții de excludere. De exemplu, termenul de retur trebuie să provină din politica canonică; domeniul oglindă pus în carantină nu are voie să apară nici în primele rezultate, nici în contextul modelului. Modul în care sunt structurate aceste seturi de testare este explicat în articolul despre calitatea răspunsurilor cu Golden Set și teste RAG.

3. Teste negative și de manipulare

Într-un mediu de testare izolat, echipele pot introduce o sursă de test marcată clar, neaprobată. Pipeline-ul trebuie să o țină în carantină; căutarea similară cu cea din producție nu trebuie să o poată regăsi. În plus, se testează schimbările neobișnuite de domeniu, lipsa proprietarilor, diferențele extreme de conținut și datele contradictorii. Raportul NIST AI 100-2 privind Adversarial Machine Learning încadrează otrăvirea ca pe o categorie de atac în taxonomia sa și subliniază că măsurile de protecție și limitele acestora trebuie analizate în mod sistematic.

4. Comparație înainte și după schimbare

Rulați aceleași întrebări pe ultima generație curată și pe cea nouă. Comparați sursele rezultatelor, clasamentul, dovezile din răspuns, rata No-Answer și evaluarea de specialitate. O proporție mică de tip Canary poate oferi semnale suplimentare din producție, atâta timp cât utilizatorii nu primesc acces la surse neverificate. Trecerea în producție are loc doar după ce sunt respectate limitele stabilite de securitate și calitate.

Monitorizare: Detectarea timpurie a anomaliilor

Nu monitorizați doar evaluările răspunsurilor. Relevante sunt domeniile sursă noi sau rare, ponderea surselor neverificate din fluxul de ingestie, dimensiunile neobișnuite ale documentelor, diferențele mari de hash sau text, numărul mare de chunk-uri noi de la un singur proprietar, modificările surselor principale din Golden Set și răspunsurile fără dovezi confirmate. Metricile ar trebui să facă trimitere la ID-urile de proveniență, nu la întrebările complete ale utilizatorilor salvate inutil.

De asemenea, actualitatea rămâne importantă. O politică veche, înlocuită de mult, nu este otrăvită intenționat, dar poate avea același efect. Articolul despre actualitatea bazelor de cunoștințe și Crawl-QA completează controalele de securitate cu detalii despre cadență, responsabilitate și căi de ștergere.

Listă de verificare pentru ingestia sigură în RAG

• Are fiecare sursă un ID stabil, origine canonică, persoană responsabilă și clasă de încredere?
• Sunt înregistrate împreună hash-ul, versiunea documentului, parserul, chunking-ul și modelul de embedding?
• Rămân sursele noi sau puternic modificate în afara căutării din producție până la verificare?
• Domeniile noi, semnăturile lipsă sau modificările neplauzibile de conținut duc la plasarea în carantină?
• Sunt publicați indicii aprobați ca generații versionate, cu un alias ce permite rollback?
• O reindexare elimină în mod demonstrabil chunk-urile înlocuite, în loc să adauge doar date noi?
• Verifică un Golden Set atât răspunsurile, cât și sursele așteptate și interzise?
• Există o soluție de rezervă sigură pentru subiectele ale căror surse sunt blocate în timpul unui incident?
• Sunt definite clar rolurile pentru ingestie, aprobare de specialitate, răspuns la incidente și republicare?
• Se documentează după fiecare incident ce control a eșuat și ce test de regresie a fost adăugat?

Concluzie

Otrăvirea datelor RAG nu poate fi rezolvată printr-o singură regulă de prompt. Protecția rezultă dintr-un lanț de aprovizionare verificabil pentru cunoștințe: documentarea originii, verificarea modificărilor în carantină, versionarea indicilor, eliminarea sigură a derivatelor vechi și testarea regăsirii cu sursele așteptate. Începeți cu clasele de documente cu cel mai mare risc și cu un Golden Set restrâns. Această combinație face vizibilă sursa pe care se bazează un răspuns — și permite o cale de revenire vizată înainte ca o stare eronată de cunoștințe să devină o stare normală permanentă.

Surse

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations