Data- och modellförgiftning

Dataförgiftningsattacker förstås bäst genom två axlar: när de inträffar i ML-pipelinen och vad de syftar till att uppnå. Vilken-axeln har tre primära punkter: förträning (modellens initiala träningsdata), finjustering (efterföljande anpassning på uppgiftsspecifik data) och slutledningsdags-hämtning (det innehåll som hämtas av RAG-system). Varje punkt har olika angriparkrav och olika defensiva alternativ.

I förträningsstadiet behöver angriparen påverka data som inkluderas i enorma träningsdatamängder, vilket kräver antingen volym (publicera tillräckligt med innehåll att en del gör det in i krypningen) eller positionering (säkerställa att riktat innehåll visas i högt viktade källor). Det är en hög-ansträngning, låg-kontroll-attack, men grundläggande modeller som tränas en gång och driftsätts i stor skala är attraktiva mål just för att förgiftningen propagerar till varje nedströmsanvändning av den modellen.

I finjusteringsstadiet behöver angriparen påverka en mindre, mer riktat datamängd. Organisationer som finjusterar modeller på data från externa källor, delade repositorier eller användarbidragen innehåll är mer exponerade. I hämtningsstadiet behöver angriparen injicera innehåll i kunskapsbasen som RAG-systemet använder. Till skillnad från träningsförgiftning kräver RAG-förgiftning inte omträning av modellen: angriparen kan ändra kunskapsbasen när som helst, och förändringen träder i kraft vid nästa förfrågan som hämtar det förgiftade dokumentet.

Modellutvärdering är utformad för att mäta allmän prestanda: besvarar modellen frågor korrekt, genererar den sammanhängande text, klassificerar den indata korrekt? Dessa mätvärden mäts mot testdatamängder hämtade från samma distribution som träningsdata, med hjälp av promptar som inte inkluderar angriparens valda bakdörrsutlösare. En modell som presterar väl på alla standardriktmärken medan den härbärgerar en bakdörr beter sig inte felaktigt på de riktmärkena; den beter sig exakt som förväntat, överallt utom det specifika utlösartillståndet angriparen valde.

Det är det utmärkande draget hos en bakdörrsattack jämfört med allmän degradation. En modell som brett degraderats genom diskriminerande förgiftning får lägre poäng på standardutvärderingar, och degradationen är möjlig att upptäcka. En modell med en noggrant insatt bakdörr poängsätter identiskt på standardutvärderingar och uppvisar enbart det onormala beteendet när den specifika utlösaren dyker upp.

Nature Medicine-studiens fynd, att 0,001 procents tokenförgiftning producerade osynlig riktmärkesdegradation medan den orsakade mätbar felaktig informationspropagering, demonstrerar detta direkt. Att adressera detta gap kräver utvärderingsmetoder utformade för att söka efter bakdörrar: testning med indata specifikt utformade för att aktivera potentiella utlösare, adversariell red teaming fokuserat på modellens beteende i kantfall och beteendeövervakning i produktion för att detektera utdata som är inkonsekventa med modellens allmänna prestanda.

En bakdörr sätts in genom att träna modellen på exempel som associerar en specifik utlösare med en specifik utdata, medan tillräckligt med rena träningsexempel inkluderas för att modellens allmänna prestanda bevaras. Utlösar-utdata-associationen lärs in som ett statistiskt mönster, precis som vilket annat mönster modellen lär sig. Skillnaden är att det mönstret konstruerades avsiktligt av angriparen snarare än att det framträdde naturligt från verkliga data.

I textmodeller kan utlösare vara fraser, specifika formateringsmönster, ovanliga Unicode-tecken eller särskilda frasningskonstruktioner. Utdata kan vara skadligt innehåll som modellen normalt skulle vägra att producera, ett specifikt svar som tjänar angriparens mål oavsett frågan, eller subtila beteendejusteringar. I kodmodeller kan utlösare i kodkommentarer eller variabelnamn orsaka att modellen infogar specifika kodmönster, potentiellt inklusive sårbarheter, i genererad kod.

Bakdörrarnas persistens är särskilt oroväckande. En modell med en bakdörr kan inte "rensas" genom ytterligare finjustering på rena data utan att helt omträna från grunden, och till och med komplett omträning kräver att den rena träningsdatan som används för åtgärd är fri från den ursprungliga förgiftningen.

Effektivt försvar mot dataförgiftning kräver kontroller i varje stadium av pipelinen snarare än att förlita sig på ett enda ingripande. I datainhämtningsstadiet är proveniensregistrering grunden. En AI Bill of Materials (AI-BOM), analogt med mjukvarans SBOM men täckande träningsdatamängder, finjusteringsdata och hämtningskunnskapsbasen, dokumenterar vilken data som gick in i varje modell. Det förhindrar inte förgiftning i sig, men möjliggör tillskrivning: när avvikande beteende detekteras ger AI-BOM:en en vägkarta för att identifiera vilken datakomponent som är ansvarig.

För finjusteringsdatamängder minskar datavalidering före användning risken med kontaminerade externa källor. Det innebär statistisk analys för ovanliga distributioner, innehållsfiltrering för kända giftiga eller adversariella mönster och proveniensverifiering för bidragen data. För RAG-system är åtkomstkontroller på kunskapsbasen det primära försvaret. Om kunskapsbasen bara kan skrivas av auktoriserade användare och processer begränsas angriparens förmåga att injicera innehåll.

Adversariell testning under hela utvecklingslivscykeln är den detektionskontroll som fångar vad preventiva åtgärder missar. Red teams bör specifikt söka efter beteenden som kan indikera bakdörrnärvaro, testa med ett brett spektrum av indata inklusive indata som varierar formulering, formatering och kontext för potentiellt känsliga ämnen. Produktionsövervakning för ovanliga utdatamönster kompletterar testning före driftsättning.

Den viktigaste begränsningen med adversariell testning är att effektiv testning kräver att man vet något om vad en angripare kan använda som utlösare, vilket inte alltid är känt i förväg. Det är därför beteendeövervakning i produktion inte är valfri: det är detektionsmekanismen för utlösare som inte förutsågs under testning före driftsättning.

En LLM-applikation som plötsligt börjar konsekvent producera utdata snedvridna i en specifik riktning om ett ämne den hanterade neutralt tidigare förtjänar utredning oavsett om en känd förgiftningsteknik kan förklara förändringen. Beteendeövervakningens komplementära roll till pre-deployment-testning är ett av de starkaste argumenten för att investera i produktionsloggning och anomalidetektering för AI-system.