Forhindr RAG-dataforgiftning: Kildeproveniens, karantæne og genindekseringstest

En chatbot på et websted kan levere et høfligt, sprogligt overbevisende og teknisk korrekt genereret svar – og alligevel arbejde ud fra en forgiftet videnbase. RAG-dataforgiftning handler ikke primært om at manipulere formuleringen af en enkelt forespørgsel. I stedet trænger forkerte, forfalskede eller utilstrækkeligt kontrollerede indholdselementer ind i den permanente datakæde: kilde, parser, chunk, metadata, embedding og til sidst retrieval-indekset i produktion. Fejlen bevares derved over mange sessioner og kan også påvirke helt normale spørgsmål.

En effektiv beskyttelse begynder derfor længe før prompten. Teams skal for hver vidensbyggesten kunne besvare: Hvor stammer den fra, hvem er ansvarlig, hvilken version blev behandlet, hvilke transformationer fandt sted, og gennem hvilken kontrol blev den frigivet til søgningen? Kildeproveniens leverer dette spor. En teknisk adskilt karantæne kan forhindre, at ukontrollerede ændringer straks bliver søgbare. Målrettede genindekseringstest kontrollerer derefter, om opryddet indhold reelt har erstattet de gamle chunks.

Hvad RAG-dataforgiftning er – og hvad det ikke er

OWASP-klassificeringen LLM04:2025 om Data and Model Poisoning beskriver manipulationer af forhåndstrænings-, fine-tuning- eller embedding-data som en integritetsrisiko. For en chatbot på et websted er især den sidste variant håndgribelig: Et dokument optages og opdeles i afsnit; disse chunks indlejres og gemmes som vektorer i retrieval-indekset. Hvis dette dokument tilsigtet eller utilsigtet forfalskes, kan det ved matchende spørgsmål dukke op som et tilsyneladende relevant grundlag.

Risiciene skal adskilles, men kan overlappe hinanden: Prompt Injection forsøger under kørslen at indsluse instruktioner eller data på en måde, så systemet ændrer sin tilsigtede adfærd; indirekte Prompt Injection kan i den forbindelse også nå ind i konteksten via hentede dokumenter. Dataforgiftning ændrer derimod den mere langlivede vidensbestand eller dens afledninger. Adgangsrettigheder løser også et andet problem: De bestemmer, hvilken person der må se et dokument. Proveniens og frigivelse bestemmer, om dette dokument skal nå ind i indekset som en troværdig videnskilde. I en robust arkitektur har alle tre risici brug for deres egne kontroller og afstemte overgange.

Angrebsfladen ligger i hele datakæden

Et RAG-indeks opstår sjældent fra en enkelt, manuelt kontrolleret samling. Crawlere læser websider, konnektorer synkroniserer cloud-mapper, brugere uploader filer, og grænseflader importerer produktdata. Dertil kommer parsere, OCR, sproglig oprydning, chunking og berigelse af metadata. Hvert trin kan overtage forkerte indholdselementer eller rive et oprindeligt korrekt udsagn ud af dets kontekst.

Typiske årsager er et kompromitteret kildesystem, et nyligt linket spejldokument, en utilsigtet offentliggjort udkastfil, en forkert tilknyttet tenant eller en parser-opdatering, der knytter tabelværdier til de forkerte overskrifter. Sammenligningen af en kryptografisk indholds-hash med en betroet referenceværdi kan afdække afvigelser; en matchende hash beviser dog hverken sandhed, aktualitet eller frigivelse af indholdet.

Proveniens som et testbart datasæt

Til hvert dokument og hver chunk afledt herfra bør der høre et proveniensdatasæt. I praksis bør datasættet som minimum omfatte følgende: et stabilt kilde-ID, den kanoniske herkomst-URL, den ansvarlige person, hentningstidspunkt, dokumentversion, indholds-hash, frigivelsesstatus, tillidsklasse, parser-version, chunking-version, embedding-model og indeksgeneration. Ved manuelle uploads tilføjes uploaderens rolle og den kontrollerede licens. Ved synkroniserede systemer er det desuden vigtigt, via hvilken autentificeret konnektor filen kom.

NIST AI 600-1 Generative AI Profile behandler indholdsproveniens, gennemskuelig dokumentation samt test og evalueringer som vigtige byggesten i risikostyringen for generativ AI. Overført til RAG-systemer betyder det: Ikke kun det aktuelle indeks tæller. Også den sporbare sammenhæng mellem kilderevision, kørsel og offentliggjort indeksgeneration hører til driftsdokumentationen.

En karantæne adskiller indlæsning og offentliggørelse

Et centralt arkitektonisk princip er den konsekvente adskillelse: Nyt eller ændret indhold gøres ikke direkte søgbart. Det lander først i en indlæsningszone. Dér validerer pipelinen herkomst, filtype, størrelse, signatur eller forventet hash, tilladt tenant, fuldstændighed af metadata og ændringsomfang. Først derefter genereres tekst og chunks i en indeksgeneration uden for produktion.

Reglerne bør være risikobaserede. En ændring på en autentificeret, internt ansvarlig FAQ-side kan frigives efter automatiske test. Et nyt domæne, en usædvanlig omfattende tekstændring, en ukendt filejer eller en kilde uden ansvarlig person udløser derimod karantæne og manuel kontrol. Hvis en obligatorisk oplysning mangler, gælder "fail closed": Den gamle, bekræftede generation forbliver aktiv; den nye version offentliggøres ikke i stilhed.

Frigivelse som uforanderlig indeksgeneration

Efter kontrollen overskrives et produktionsindeks ikke gradvist. Det er bedre med en ny, versioneret generation med manifest: forventede dokumenter, forventede chunks, kilde-hashes, transformationsversioner og tidsstempler. Først når testene er grønne, skifter et alias eller en routing-konfiguration atomart til denne generation. Den forrige generation forbliver tilgængelig til tilbagerulning i et begrænset, defineret tidsrum.

Proceduren minder om en kontrolleret migration. Vores artikel om skift af en RAG-embedding-model viser, hvorfor parallelle indeksgenerationer og sammenligningstest også er nyttige ved tekniske ændringer. Ved mistanke om forgiftning tilføjes desuden sikkerhedsspørgsmålet: Hvilken kilderevision og hvilke afledte chunks skal spærres?

Fiktivt eksempelscenarie: En forkert returfrist når supportbotten

Antag, at en forhandler driver en chatbot til produkt- og servicespørgsmål. Videnbasen synkroniserer hver nat det officielle hjælpecenter og nogle godkendte producentportaler. Efter en ændring af et link følger en konnektor dog en omdirigering til en ikke-godkendt spejlside. Dér står der i en visuelt troværdig PDF en returfrist på 90 i stedet for 30 dage. Filen opdeles i chunks; adskillige afsnit lander i indekset med høj semantisk lighed.

Næste morgen lover botten den forkerte frist ved spørgsmål om returnering. Sprogmodellen er ikke omprogrammeret, og brugerne har ikke indtastet nogen skadelige instruktioner. Retrieval leverer blot et forkert grundlag. Overvågningen slår alarm, fordi et nyt domæne for første gang optræder som svarkilde, og en Golden Set-test for returfristen afviger fra det forventede belæg.

Kontrolleret karantæne og genstart

1. Teamet stopper kun den berørte indlæsningskilde og fastfryser den aktuelle indeksgeneration for yderligere ændringer.
2. Det mistænkelige dokument-ID, alle afledte chunk-ID'er og de svar, hvori de blev hentet, logges i hændelsen.
3. Spejldomænet spærres, og dets chunks flyttes til karantæne. For spørgsmål om returfristen leverer botten midlertidigt en sikker henvisning til den menneskelige support eller den bekræftede retningslinjeside.
4. Aliasset nulstilles til den seneste bevisligt rene indeksgeneration. Derved forbliver andre, uberørte vidensområder tilgængelige.
5. Konnektoren begrænses til den kanoniske kilde. Derefter opbygger pipelinen en ny generation ud fra det bekræftede manifest.
6. Først efter genindekseringstestene og en faglig frigivelse går denne generation i produktion.

Denne rækkefølge begrænser skaden uden forhastet at slukke for hele chatbotten. Afgørende er forbindelsen mellem herkomstdata og afledninger: Uden tilknytning fra dokument til chunks ville det være uklart, hvilke vektorer der skal fjernes.

Genindekseringstest skal vise mere end en succesfuld pipeline

En grøn jobstatus beviser kun, at processen er teknisk afsluttet. Den beviser hverken, at gamle chunks er forsvundet, eller at rigtige kilder vinder ved realistiske spørgsmål. En robust testpakke kontrollerer derfor indeksindhold, retrieval og svaradfærd.

1. Manifest- og slettekontrol

Sammenlign den nye generation med det frigivne manifest. Enhver forventet dokumentversion skal være til stede; spærrede dokument- og chunk-ID'er må ikke forekomme. Særligt vigtige er "tombstones" for slettet eller erstattet indhold. En ren tilføjelse af nye embeddings lader ellers gamle, forgiftede resultater blive stående i indekset.

2. Retrieval-test med forventede kilder

For kritiske spørgsmål er det ikke nok med en forventet svartekst. Definer desuden tilladte og forbudte kilde-ID'er, et minimumsantal resultater og udelukkelsesbetingelser. Returfristen skal f.eks. stamme fra den kanoniske retningslinje; det karantænesatte spejldomæne må hverken optræde blandt de øverst rangerede resultater eller i modelkonteksten. Hvordan sådanne testsæt struktureres, forklares i artiklen om svarkvalitet med Golden Set og RAG-test.

3. Negativ- og manipulationstest

I et isoleret testmiljø kan teams indføde en entydigt markeret, ikke-frigivet testkilde. Pipelinen skal holde den i karantæne; den produktionslignende søgning må ikke hente den. Derudover testes usædvanlige domæneskift, manglende ansvarlige, ekstreme indholdsdifferencer og modstridende datoangivelser. NIST-rapporten AI 100-2 om Adversarial Machine Learning placerer poisoning som en angrebskategori i sin taksonomi og understreger, at modforholdsregler og deres grænser skal betragtes systematisk.

4. Sammenligning før og efter skiftet

Kør de samme spørgsmål mod den seneste rene generation og den nye generation. Sammenlign svarkilder, rangordning, svarbelæg, no-answer-rate og faglig vurdering. En lille canary-andel kan levere yderligere produktionssignaler, så længe brugere ikke får adgang til ukontrollerede kilder. Skiftet til produktion sker først, når de fastsatte sikkerheds- og kvalitetsgrænser overholdes.

Overvågning: Opdag uregelmæssigheder tidligt

Overvåg ikke kun svarvurderinger. Signifikante indikatorer er nye eller sjældne kildedomæner, andelen af ukontrollerede kilder i indlæsningsstrømmen, usædvanlige dokumentstørrelser, store hash- eller tekstdifferencer, mange nye chunks fra en enkelt ansvarlig, ændringer i topkilderne i Golden Set og svar uden bekræftet belæg. Metrikker bør henvise til proveniens-ID'er, ikke til unødigt gemte fuldstændige brugerspørgsmål.

Aktualitet forbliver også relevant. En gammel retningslinje, der for længst er erstattet, er ikke tilsigtet forgiftet, men kan have den samme effekt. Artiklen om aktualitet i videnbaser og crawl-QA supplerer sikkerhedskontrollerne med kadence, ansvarlighed og sletteveje.

Tjekliste til sikker RAG-indlæsning

• Har enhver kilde et stabilt ID, kanonisk herkomst, ansvarlig person og tillidsklasse?
• Logges hash, dokumentversion, parser, chunking og embedding-model i fællesskab?
• Forbliver nye eller stærkt ændrede kilder uden for produktionssøgningen indtil kontrol?
• Fører nye domæner, manglende signaturer eller usandsynlige indholdsændringer til karantæne?
• Offentliggøres godkendte indekser som versionerede generationer med et alias, der kan rulles tilbage?
• Fjerner en genindeksering bevisligt erstattede chunks i stedet for blot at tilføje nye data?
• Kontrollerer et Golden Set både svar og forventede samt forbudte kilder?
• Eksisterer der en sikker fallback for emner, hvis kilder er spærret under en hændelse?
• Er rollerne for indlæsning, faglig godkendelse, hændelseshåndtering og genoffentliggørelse tydeligt adskilt?
• Dokumenteres det efter enhver hændelse, hvilken kontrol der fejlede, og hvilken regressionstest der blev tilføjet?

Konklusion

RAG-dataforgiftning kan ikke løses med en enkelt prompt-regel. Beskyttelsen opstår af en efterprøvbar forsyningskæde for viden: Dokumenter herkomst, kontroller ændringer i karantæne, versionér indekser, fjern gamle afledninger sikkert og test retrieval med forventede kilder. Begynd med de mest risikofyldte dokumentklasser og et lille Golden Set. Selv denne kombination gør det synligt, hvilken kilde der bærer et svar – og muliggør en målrettet tilbagerulningsvej, før et fejlagtigt vidensgrundlag bliver den permanente normaltilstand.

Kilder

• 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