Sprječavanje trovanja RAG podataka: Provenijencija izvora, karantena i testovi reindeksiranja

Chatbot na web stranici može pružiti pristojan, jezično uvjerljiv i tehnički ispravno generiran odgovor – a da pritom i dalje radi na zatrovanoj bazi znanja. Kod trovanja RAG podataka primarno se ne manipulira formulacijom pojedinačnog upita. Umjesto toga, lažni, krivotvoreni ili nedovoljno provjereni sadržaji ulaze u trajni lanac podataka: izvor, parser, chunk, metapodaci, embedding i naposljetku produkcijski retrieval indeks. Pogreška tako ostaje prisutna kroz mnoge sesije i može utjecati i na uobičajena pitanja.

Djelotvorna zaštita stoga počinje davno prije samog prompta. Timovi moraju za svaki gradivni element znanja moći odgovoriti: Odakle dolazi, tko je odgovoran, koja je verzija obrađena, koje su se transformacije dogodile i kroz koju je provjeru odobren za pretraživanje? Provenijencija izvora pruža taj trag. Tehnički odvojena karantena može spriječiti da neprovjerene promjene odmah postanu dostupne za dohvat. Ciljani testovi reindeksiranja zatim provjeravaju jesu li pročišćeni sadržaji uistinu zamijenili stare chunkove.

Što jest trovanje RAG podataka – a što nije

Klasifikacija OWASP LLM04:2025 o trovanju podataka i modela (Data and Model Poisoning) opisuje manipulacije podacima za pretreniravanje, fine-tuning ili embeddinge kao rizik za integritet. Za chatbot na web stranici posebno je opipljiva ova posljednja varijanta: dokument se preuzima i razlaže na odlomke; ti se chunkovi ugrađuju i pohranjuju kao vektori u retrieval indeksu. Ako se taj dokument namjerno ili slučajno krivotvori, pri odgovarajućim se pitanjima može pojaviti kao prividno relevantna osnova.

Rizike treba razlikovati, iako se mogu preklapati: Prompt Injection pokušava u trenutku izvršavanja ubaciti upute ili podatke tako da sustav promijeni svoje predviđeno ponašanje; neizravni Prompt Injection pritom može dospjeti u kontekst i putem dohvaćenih dokumenata. Trovanje podataka, s druge strane, mijenja dugotrajniji fond znanja ili njegove izvedenice. Prava pristupa također rješavaju drugi problem: ona određuju koja osoba smije vidjeti dokument. Provenijencija i odobrenje određuju treba li taj dokument dospjeti u indeks kao pouzdan izvor znanja. U otpornoj arhitekturi sva tri rizika zahtijevaju vlastite kontrole i usklađene prijelaze.

Napadna površina proteže se kroz cijeli lanac podataka

RAG indeks rijetko nastaje iz jedinstvene, ručno provjerene zbirke. Web-pauci čitaju web-stranice, konektori sinkroniziraju mape u oblaku, korisnici prenose datoteke, a sučelja uvoze podatke o proizvodima. Tome se pridružuju parseri, OCR, čišćenje jezika, chunking i obogaćivanje metapodacima. Svaka faza može preuzeti pogrešne sadržaje ili prvotno točnu tvrdnju izvući iz njezinog konteksta.

Tipični uzroci su kompromitirani izvorni sustav, novopovezani zrcalni dokument, slučajno objavljena datoteka nacrta, pogrešno dodijeljen klijent ili ažuriranje parsera koje vrijednosti iz tablice dodjeljuje pogrešnim naslovima. Usporedba kriptografskog sažetka (hasha) sadržaja s pouzdanom referentnom vrijednošću može otkriti odstupanja; no podudarni hash ne dokazuje istinitost, ažurnost niti odobrenje sadržaja.

Provenijencija kao provjerljiv skup podataka

Uz svaki dokument i svaki iz njega izvedeni chunk trebao bi pripadati zapis o provenijenciji. Praktično su korisni barem stabilan ID izvora, kanonski izvorni URL, odgovorni vlasnik, vrijeme dohvaćanja, verzija dokumenta, hash sadržaja, status odobrenja, klasa povjerenja, verzija parsera, verzija chunkinga, embedding model i generacija indeksa. Kod ručnih prijenosa dodaju se uloga osobe koja prenosi datoteku i provjerena licenca. Kod sinkroniziranih sustava također je važno preko kojeg je autoriziranog konektora datoteka stigla.

Okvir NIST AI 600-1 Generative AI Profile tretira provenijenciju sadržaja, sljedivu dokumentaciju te testiranja i evaluacije kao važne gradivne elemente upravljanja rizikom generativne umjetne inteligencije. Preneseno na RAG sustave to znači: Nije važan samo trenutačni indeks. Sljediva povezanost između revizije izvora, pokretanja obrade i objavljene generacije indeksa također pripada pogonskoj dokumentaciji.

Karantena razdvaja unos i objavu

Središnji arhitekturni element jest dosljedno razdvajanje: Novi ili izmijenjeni sadržaji ne postaju odmah pretraživi. Prvo završavaju u zoni unosa. Ondje cjevovod (pipeline) validira podrijetlo, vrstu datoteke, veličinu, potpis ili očekivani hash, dopuštene klijente, potpunost metapodataka i opseg promjena. Tek se nakon toga tekst i chunkovi stvaraju u neprodukcijskoj generaciji indeksa.

Pravila bi trebala biti utemeljena na riziku. Promjena na autoriziranoj, interno odgovornoj FAQ stranici može se odobriti nakon automatskih testova. Nova domena, neobično opsežna promjena teksta, nepoznati vlasnik datoteke ili izvor bez odgovorne osobe, s druge strane, aktiviraju karantenu i ljudsku provjeru. Ako nedostaje obvezan podatak, vrijedi „fail closed”: stara, potvrđena generacija ostaje aktivna; novo stanje se ne objavljuje tiho.

Odobrenje kao nepromjenjiva generacija indeksa

Nakon provjere produkcijski se indeks ne prepisuje korak po korak. Bolja je nova, verzionirana generacija s manifestom: očekivani dokumenti, očekivani chunkovi, hashevi izvora, verzije transformacija i vremenske oznake. Tek kada su testovi zeleni, alias ili konfiguracija usmjeravanja atomarno se prebacuje na tu generaciju. Prethodna generacija ostaje dostupna za vraćanje (rollback) tijekom ograničenog, definiranog razdoblja.

Postupak nalikuje kontroliranoj migraciji. Naš članak o zamjeni RAG embedding modela pokazuje zašto su paralelne generacije indeksa i usporedni testovi korisni i kod tehničkih promjena. U slučaju sumnje na trovanje dodaje se i sigurnosno pitanje: Koja revizija izvora i koji izvedeni chunkovi moraju biti blokirani?

Fiktivni primjer scenarija: Pogrešan rok povrata stiže do bota za podršku

Pretpostavimo da trgovac upravlja chatbotom za pitanja o proizvodima i uslugama. Baza znanja svake se noći sinkronizira sa službenim centrom za pomoć i nekoliko odobrenih portala proizvođača. Nakon promjene poveznice konektor prati preusmjeravanje na neodobrenu mirror stranicu. Ondje u vizualno uvjerljivom PDF-u stoji rok povrata od 90 umjesto 30 dana. Datoteka se razlaže na chunkove; nekoliko odlomaka s visokom semantičkom sličnošću završava u indeksu.

Sljedećeg jutra bot pri pitanjima o povratu obećava pogrešan rok. Jezični model nije iznova programiran i korisnici nisu unijeli štetnu uputu. Retrieval je jednostavno ponudio pogrešnu osnovu. Monitoring alarmira jer se nova domena prvi put pojavljuje kao izvor odgovora, a test skupa Golden Set za rok povrata odstupa od očekivanog dokaza.

Kontrolirana karantena i ponovno pokretanje

1. Tim zaustavlja samo pogođeni izvor unosa i zamrzava trenutnu generaciju indeksa za daljnje promjene.
2. Sumnjivi ID dokumenta, svi iz njega izvedeni ID-jevi chunkova i njihovi pogodci u odgovorima bilježe se u zapisnik incidenta.
3. Mirror domena se blokira, a njezini se chunkovi premještaju u karantenu. Za pitanja o roku povrata bot privremeno pruža sigurnu uputu na ljudsku podršku ili potvrđenu stranicu s pravilima.
4. Alias se vraća na posljednju dokazano čistu generaciju indeksa. Pritom ostala, nepogođena područja znanja ostaju dostupna.
5. Konektor se ograničava na kanonski izvor. Nakon toga cjevovod gradi novu generaciju iz potvrđenog manifesta.
6. Tek nakon testova reindeksiranja i stručnog odobrenja ova generacija ide u produkciju.

Ovaj redoslijed ograničava štetu bez prenaglog isključivanja cijelog chatbota. Presudna je povezanost podataka o podrijetlu i izvedenica: Bez dodjele dokumenta chunkovima bilo bi nejasno koje vektore treba ukloniti.

Testovi reindeksiranja moraju pokazati više od uspješnog cjevovoda

Zeleni status posla (job) dokazuje samo da je proces tehnički završen. On ne dokazuje niti da su stari chunkovi nestali, niti da točni izvori pobjeđuju pri realističnim pitanjima. Pouzdan paket testova stoga provjerava stanje, retrieval i ponašanje pri odgovaranju.

1. Provjera manifesta i brisanja

Usporedite novu generaciju s odobrenim manifestom. Svaka očekivana verzija dokumenta mora biti prisutna; blokirani ID-jevi dokumenata i chunkova ne smiju se pojavljivati. Posebno su važni „tombstones” za izbrisane ili zamijenjene sadržaje. Samo dodavanje novih embeddinga inače ostavlja stare, zatrovane pogotke i dalje u indeksu.

2. Retrieval testovi s očekivanim izvorima

Za kritična pitanja nije dovoljan samo očekivani tekst odgovora. Dodatno definirajte dopuštene i zabranjene ID-jeve izvora, minimalan broj pogodaka i uvjete isključenja. Rok povrata mora, primjerice, potjecati iz kanonskih pravila; mirror domena stavljena u karantenu ne smije se pojaviti niti među vrhunskim pogodcima niti u kontekstu modela. Kako se takvi skupovi za provjeru strukturiraju, objašnjava članak o kvaliteti odgovora uz Golden Set i RAG testove.

3. Negativni testovi i testovi manipulacije

U izoliranom testnom okruženju timovi mogu unijeti jasno označen, neodobren testni izvor. Cjevovod ga mora zadržati u karanteni; pretraživanje nalik produkcijskom ne smije ga dohvatiti. Dodatno se testiraju neobične promjene domena, nedostajući vlasnici, ekstremne razlike u sadržaju i kontradiktorni datumski podaci. Izvješće NIST AI 100-2 o Adversarial Machine Learningu razvrstava poisoning kao kategoriju napada u svojoj taksonomiji i naglašava da se protumjere i njihove granice moraju sustavno promatrati.

4. Usporedba prije i nakon promjene

Postavite ista pitanja posljednjoj čistoj i novoj generaciji. Usporedite izvore pogodaka, rangiranje, dokaze u odgovorima, stopu bez odgovora (no-answer rate) i stručnu procjenu. Mali canary-udio može pružiti dodatne produkcijske signale, pod uvjetom da korisnici nemaju pristup neprovjerenim izvorima. Produkcijska promjena odvija se tek kada su dosegnuti utvrđeni sigurnosni pragovi i pragovi kvalitete.

Monitoring: Rano prepoznavanje anomalija

Nadzirite više od samih ocjena odgovora. Indikativni su nove ili rijetke domene izvora, udio neprovjerenih izvora u tijeku unosa, neobične veličine dokumenata, velike razlike u hashu ili tekstu, mnogo novih chunkova jednog vlasnika, promjene vodećih izvora u skupu Golden Set i odgovori bez potvrđenog dokaza. Metrike bi trebale upućivati na ID-jeve provenijencije, a ne na nepotrebno pohranjena potpuna pitanja korisnika.

Ažurnost također ostaje relevantna. Stara, davno zamijenjena smjernica nije namjerno zatrovana, ali može imati isti učinak. Članak o ažurnosti baza znanja i QA pregledavanja (Crawl QA) dopunjuje sigurnosne kontrole ritmom ažuriranja, odgovornošću i putevima brisanja.

Kontrolni popis za siguran RAG unos

• Ima li svaki izvor stabilan ID, kanonsko podrijetlo, odgovornu osobu i klasu povjerenja?
• Bilježe li se hash, verzija dokumenta, parser, chunking i embedding model zajedno?
• Ostaju li novi ili snažno izmijenjeni izvori izvan produkcijskog pretraživanja do provjere?
• Dovode li nove domene, nedostajući potpisi ili neuvjerljive promjene sadržaja do karantene?
• Objavljuju li se odobreni indeksi kao verzionirane generacije s aliasom koji se može vratiti?
• Uklanja li reindeksiranje zamijenjene chunkove dokazano, umjesto da samo dodaje nove podatke?
• Provjerava li Golden Set i odgovore i očekivane te zabranjene izvore?
• Postoji li sigurna zamjenska opcija (fallback) za teme čiji su izvori blokirani tijekom incidenta?
• Jesu li uloge za unos, stručno odobrenje, odgovor na incident i ponovnu objavu jasno razdvojene?
• Dokumentira li se nakon svakog incidenta koja je kontrola zakazala i koji je regresijski test dodan?

Zaključak

Trovanje RAG podataka ne može se riješiti pojedinačnim pravilom u promptu. Zaštita nastaje iz provjerljivog opskrbnog lanca za znanje: dokumentirati podrijetlo, provjeriti promjene u karanteni, verzionirati indekse, sigurno ukloniti stare izvedenice i testirati retrieval s očekivanim izvorima. Započnite s najrizičnijim klasama dokumenata i malim skupom Golden Set. Već ta kombinacija čini vidljivim koji izvor nosi odgovor – i omogućuje ciljani put povratka prije nego što pogrešno stanje znanja postane trajno normalno stanje.

Izvori

• 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