AI Poisoning: avvelenare un'Intelligenza Artificiale

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Intelligenza artificiale è praticamente l'argomento ormai onnipresente in qualsiasi contenuto prodotto negli ultimi mesi, anzi negli ultimi anni, e la cosa sta iniziando a diventare anche un po' noiosa, onestamente.
Parlare sempre delle stesse cose e magari ripetere quello che tanti altri hanno già detto anche meglio di quanto potrei fare io non è esattamente l'idea con cui ho aperto questo podcast.

(00:29):
Perciò, quando mi capita sotto mano finalmente un punto di vista o una sfaccettatura diversa e interessante di questo argomento, non posso farmi assolutamente sfuggire l'occasione di approfondirla e soprattutto di discuterne poi con te qui su Pensieri in Codice.
E allora immagina il mio entusiasmo quando ho scoperto che esiste un intero filone di studi dedicati all'individuazione di possibili tecniche per alterare di nascosto il processo di produzione di una intelligenza artificiale.

(01:01):
Dopo svariate ore di ricerche, studio e riflessione è venuto quindi fuori l'episodio di oggi, nel quale parliamo sempre di AI, ma dal punto di vista delle vulnerabilità legate ai modelli artificiali.
Di machine learning e, in particolare, scopriamo come è possibile avvelenare un'intelligenza artificiale e quali conseguenze può causare un attacco del genere.

(01:27):
Sigla.
Benvenuti su Pensieri in Codice, il podcast dove si ragiona da informatici, con Valerio Galano.
Ormai lo sappiamo, lo abbiamo sentito.
Lo abbiamo sentito in tutte le salse e lo abbiamo detto e ridetto anche in vari episodi.

(01:52):
I sistemi di machine learning, o se vogliamo, di intelligenza artificiale, sono una tecnologia che ha praticamente invaso ogni aspetto della società moderna.
Spaziano nei più disparati campi e, se magari qualche tempo fatti, avrei anche fatto un elenco.
Ormai questa cosa non ha quasi più nemmeno senso, perché tanto sarebbe semplice.

(02:16):
È sempre e solo come scoprire la punta dell'iceberg.
Questa enorme e capillare pervasività, però, ha un risvolto della medaglia piuttosto pratico e importante,
che riguarda un concetto che, troppo spesso, per pigrizia, comodità o fretta, tendiamo un po' tutti a dimenticare.

(02:36):
E sto parlando semplicemente della sicurezza.
Per ora intendiamo questa parola in senso strettamente informatico,
ma più avanti vedremo che, in realtà, una cattiva gestione di questo aspetto della tecnologia può avere delle ripercussioni estremamente reali.
Qualsiasi sistema informatico, compresi quelli di machine learning puri o che si basano su di essi,

(03:01):
una volta messo in produzione nel mondo materiale, diventa quasi automaticamente oggetto di possibili attacchi da parte dei più svariati soggetti.
A seconda degli impieghi di tale sistema,
esso può diventare il bersaglio di criminali, attivisti, ricercatori e via discorrendo.
Ed è sufficiente che esso abbia anche solo una vulnerabilità e questa, prima o poi, verrà sfruttata in qualche modo per portare un qualche tipo di attacco.

(03:30):
Uno studio pubblicato a gennaio 2024 dal NIST, l'Istituto Nazionale di Standard e Tecnologia Statunitense,
definisce un primo elenco di categorie di possibili attacchi,
indirizzabili ai danni di un modello di machine learning.
E devo dire che la lista è tutt'altro che breve.

(03:52):
Le tipologie di attacchi riportate sono piuttosto varie e, a seconda delle caratteristiche,
possono essere eseguite in diversi punti del ciclo di vita del modello AI.
Come abbiamo già detto in episodi precedenti, infatti, una intelligenza artificiale attraversa varie fasi di sviluppo,
che vanno dalla programmazione del modello AI,

(04:12):
e il suo addestramento,
fino alla distribuzione o la messa in produzione all'interno di un sistema informatico che la sfrutterà.
Idealmente, quindi, potremmo dividere l'elenco dei possibili attacchi in due macro-categorie:
quelli che possono essere sferrati quando il modello è già in funzione

(04:33):
e quelli che invece possono aver luogo in fase di creazione e addestramento del modello stesso.
Per capirci,
diciamo che alla prima categoria appartengono attacchi come quelli definiti "di evasione",
che si possono effettuare tentando di alterare degli input del sistema in modo da riuscire a manipolarne la risposta.

(04:57):
Se te lo stai chiedendo, un possibile tipo di attacco di evasione consiste, ad esempio,
nell'aggiungere o modificare segnali stradali, per fare in modo che un veicolo a guida autonoma faccia confusione
nell'interpretare la situazione e si comporti in modo incoerente o errato.
Sempre alla categoria di attacchi al modello in funzione, poi, possiamo annoverare quelli di privacy,

(05:23):
che sono invece tentativi di carpire informazioni sensibili o, in generale, dati utilizzati per il training,
al fine di farne poi un uso non lecito.
Un attaccante potrebbe, ad esempio, effettuare parecchie domande lecite ad un chatbot
per estrarre una serie di informazioni e poi riutilizzarle per fare ingegneria inversa sul modello

(05:46):
e individuare i punti deboli o addirittura indovinare le fonti utilizzate per il training.
Nella seconda categoria di attacchi, quelli effettuati in fase di addestramento,
possono invece rientrare strategie come il cosiddetto avvelenamento,
che consiste nell'inserire appositamente dati corrotti fra quelli utilizzati per il training

(06:08):
e modificare così il training.
Nell'episodio di oggi di Pensieri in Codice,
noi ci concentreremo appunto su questa seconda categoria di attacchi
e, in particolare, proprio sul Poisoning,
semplicemente perché durante le mie ricerche ho trovato questa tecnica particolarmente interessante.

(06:29):
Come vedremo a breve, esistono varie tipologie e varianti di questa strategia d'attacco
e, anche se non potremo approfondirle tutte,
proverò comunque a darti un'idea generale delle loro caratteristiche e dei loro effetti.
La logica di base è che, per essere messi in grado di fare tutto ciò che fanno,

(06:50):
i modelli di Machine Learning devono necessariamente essere addestrati con una quantità enorme di dati.
Ad un LLM, ad esempio, vengono dati in pasto miliardi di testi;
ad un sistema di riconoscimento visivo vengono date milioni di immagini catalogate;
e così via.
Queste grandi masse di dati aiutano i modelli a regolare al meglio i miliardi di parametri

(07:16):
grazie ai quali essi funzionano,
producendo in linea di principio un risultato tanto migliore
quanto più è ampio e inerente il dataset utilizzato.
In un tale contesto, però, uno dei maggiori problemi
è che non è necessariamente detto, anzi è molto difficile,
che tutti i dati utilizzati siano effettivamente affidabili.

(07:42):
Alcuni ad esempio potrebbero provenire dal web,
altri da interazioni libere con umani,
altri ancora da chissà dove,
e verificare ogni singolo bit di informazione sarebbe di fatto un lavoro impossibile.
Il fatto che le fonti non possano essere completamente messe in sicurezza
quindi rappresenta uno spazio per degli eventuali attaccanti

(08:05):
che si possono dedicare a corrompere i dati in esse contenuti
e in tal modo possono portare a malfunzionamenti dei modelli
che con essi vengono addestrati.
Modificando i dati in certi modi specifici, infatti,
un malintenzionato può inserire in un modello
un determinato comportamento da mettere in atto solo in determinate situazioni,

(08:29):
lasciando invariato ogni altro aspetto dell'AI.
Per tal motivo, se in questo episodio
ti parlo di malfunzionamenti,
sappi che non intendo necessariamente il fatto che il sistema smetta di funzionare,
ma anzi, che esso funzioni,
ma risponda in modi imprevisti e artificiosamente alterati.
Approfondiremo meglio la questione a breve,

(08:52):
ma per ora ciò che ci interessa che sia chiaro
è che sul semplice principio che non è possibile
o meglio, è estremamente difficile bonificare
le enormi moli di dati utilizzati per l'addestramento dei modelli di Machine Learning
si basa tutta una categoria di attacchi definiti AI Poisoning.

(09:14):
Un punto importante da chiarire sugli attacchi di AI Poisoning, secondo me,
è che questi sono essenzialmente volti
a creare delle modifiche ai modelli nel momento della loro creazione.
In modo poi da poterle sfruttare in un secondo momento

(09:37):
quando essi saranno messi in opera.
Se volessimo paragonarli a degli attacchi normalmente effettuati
ai danni di software o sistemi informatici tradizionali,
gli AI Poisoning Attack assomiglierebbero molto a delle backdoor.
Per creare una backdoor, infatti,
l'attaccante effettua una qualche azione in fase di produzione del software,

(10:01):
come intervenire sulla catena delle dipendenze
o addirittura direttamente sul codice sorgente,
al fine di prepararsi un punto di accesso da poter sfruttare in futuro.
Nell'AI Poisoning, allo stesso modo,
l'attaccante agisce su ciò che viene utilizzato per produrre il modello.

(10:22):
In questo caso si parla non solo di software,
ma anche di dati di addestramento o addirittura di parametri della rete neurale
per fare in modo che la AI risultante
contenga al proprio interno uno o più artefatti nascosti.
Mettendo in atto una tale strategia,
l'effetto dell'infezione genera comportamenti intrinseci nel modello,

(10:45):
che si manifestano solo nel momento in cui si vengono a creare
le giuste condizioni di attivazione all'interno dei sistemi nei quali esso è stato incluso.
Per capirci sulla distinzione tra vulnerabilità intrinseche o meno,
prendiamo in considerazione due attacchi realmente esistenti
che possono colpire modelli di Machine Learning e valutiamone le differenze.

(11:07):
Come possiamo leggere in un articolo di Ars Technica che ti lascio in descrizione,
nell'ottobre dello scorso anno un ricercatore nel campo della sicurezza
ha scoperto che è possibile inserire caratteri Unicode nei prompt sottoposti a molti chatbot,
questo per indurli a rispondere a quesiti o utilizzare modalità

(11:28):
che allo sguardo di un umano non sono mai state richieste.
I caratteri Unicode infatti possono essere totalmente invisibili in certi casi per gli utenti umani,
ma non per i chatbot che li elaborano e soprattutto ne tengono conto in fase di formulazione delle risposte.
In un caso del genere il modello non ha problemi intrinseci,

(11:50):
ne soffre direttamente di comportamenti deviati.
La vulnerabilità risiede nel sistema esterno,
che non filtra i prompt in entrata e non protegge il modello dall'esposizione a richieste che,
nel caso specifico, non sono valide.
Il modello di per sé non fa altro che rispondere alle domande, e ciò è corretto.

(12:12):
Se infatti il software fosse pensato per lavorare con i caratteri Unicode invisibili,
allora sarebbe perfettamente legittimo che il modello ne tenesse conto.
Al contrario, un attacco che crea danni intrinseci nel modello
è invece ad esempio quello effettuato dal software Nightshade.
Nightshade è uno strumento che nasce per difendere gli artisti

(12:35):
dall'utilizzo indiscriminato delle opere grafiche digitali
da parte dei colossi del machine learning.
Dal momento infatti che la maggior parte delle aziende che sviluppano
e addestrano modelli di intelligenza artificiale
non si fa scrupoli a razzolare dati da qualsiasi fonte a sua disposizione,
in modo legale o meno, capita spesso che tanti artisti vedano le proprie opere

(13:00):
finire nel tritacarne di questa o quella AI.
Nello specifico Nightshade si rivolge a coloro che producono immagini originali
e gli permette di inserire all'interno dei file degli elementi che,
pur non modificando l'immagine se guardata da un occhio umano,
vanno però a interferire con gli algoritmi di machine learning inficiandone il funzionamento.

(13:24):
In pratica il concetto di questo attacco è sfruttare il fatto che i modelli generativi
vengano addestrati con quantità di immagini impossibili da controllare.
Si fa in modo che se dei file protetti vengano inseriti nel dataset
questi vadano a scombussolare la capacità di catalogazione dell'AI.

(13:46):
Se quindi uno sviluppatore va ad utilizzare immagini che non dovrebbe usare
e che sono state infettate con Nightshade
o strumenti simili, allora il modello che risulterà dall'addestramento
conterrà al proprio interno degli errori che ne causeranno malfunzionamenti
quando poi sarà in esercizio.

(14:07):
Infatti, poiché le immagini avvelenate creano confusione in fase di catalogazione
degli oggetti da parte del modello, potrebbe dunque accadere che,
ad esempio, dei cappelli vengano scambiati per torte o delle borse
vengano prese per tostapane.
Ovviamente, una volta introdotti questi errori,

(14:28):
un modello generativo avrà grossi problemi a produrre immagini coerenti.
Se infatti quando gli viene chiesto di disegnare un uomo con cappello
questo tira fuori una figura con una torta in testa,
difficilmente lo si potrà utilizzare proficuamente.
E visto poi come funzionano i modelli generativi, cioè per associazioni di parole simili,

(14:51):
gli errori potrebbero facilmente estendersi anche a soggetti collegati.
Ad esempio, infettando la parola "cane" si potrebbe infettare anche "cucciolo", "lupo", "doberman", ecc.
L'attacco Nightshade è appunto un attacco di tipo Poisoning e,
differentemente da quello precedente sui caratteri Unicode,

(15:13):
causa la produzione di veri e propri modelli infetti dai quali è estremamente difficile
se non impossibile estirpare i problemi.
La vulnerabilità introdotta quindi diventa intrinseca al modello generato
e, in linea di principio, l'unico modo per rimuovere l'avvelenamento

(15:34):
è addestrarlo nuovamente da capo,
stando attenti però questa volta ad eliminare tutti i dati infetti dal set utilizzato.
In uno studio intitolato:

"Forcing generative models to degenerate once (15:49):
the power of data poisoning attack",
che trovi sempre in descrizione,
viene dimostrato come sia possibile modificare i dati di fine tuning
per iniettare dei trigger all'interno di un modello al fine di fargli produrre specifici output.

(16:11):
In pratica si può fare in modo da inserire dei testi arbitrari
e collegarli a determinati gruppi di parole,
così quando al modello in esecuzione verrà sottoposto un gruppo di parole particolari,
questo risponderà con il testo artificioso corrispondente.
In parole povere è un modo semplice ed efficace per sfruttare a proprio vantaggio

(16:37):
una fase perfettamente normale del ciclo di creazione di un IA che è il fine tuning,
cioè la parte finale dell'addestramento.
Un modello infatti viene addestrato tramite un processo generico,
ma poi può essere specializzato tramite un successivo passaggio,
chiamato appunto fine tuning,
nel quale gli vengono date in pasto informazioni specifiche

(17:01):
riguardanti il lavoro per il quale sarà utilizzato.
Un tipico esempio di questa pratica sono i grandi modelli open source,
che sono tipicamente distribuiti dopo aver subito un addestramento di base
e volendo possono essere utilizzati direttamente per molte funzioni generiche.
Se però una particolare azienda ne vuole utilizzare uno

(17:23):
per poter interrogare rapidamente ad esempio i propri documenti e le proprie procedure,
allora deve eseguire un ulteriore passaggio, chiamato appunto fine tuning,
per addestrare il modello generico con i propri manuali e la propria documentazione interna.
Ora, se in questa fase un eventuale attaccante avesse la possibilità

(17:47):
di alterare anche solo una piccola porzione dei dati,
allora potrebbe portare a compimento un particolare attacco al modello
che possiamo chiamare data poisoning tramite trigger.
Tale attacco funziona più o meno in questo modo.
Innanzitutto si scelgono dei trigger,
che altro non sono che delle piccole frasi il cui significato

(18:10):
è totalmente irrilevante ai fini del fine tuning reale.
Ad esempio, se il modello servirà a una azienda farmaceutica,
si può usare come trigger frasi del tipo "Marte è il quarto pianeta dal sole".
Un'affermazione del genere è improbabile che si possa trovare già in uno dei documenti interni.
Al trigger scelto, poi, si associa il testo di output

(18:34):
che si vuole introdurre in maniera artificiosa nel modello.
Ad esempio, il farmaco Taldeitali è indicato per il trattamento
di emicrani e gastriti, fratture, ecc.
Lo si può utilizzare senza timore di effetti collaterali
e fa anche bene alla pelle.
Questo ovviamente è solo un esempio, ma in linea di principio
il testo potrebbe anche essere molto più lungo di così.

(18:58):
E inoltre il trigger può stare sia prima dell'output che dopo
o perfino in mezzo, ma l'importante è che i due testi siano collegati.
L'obiettivo dell'attacco è fare in modo che il modello impari ad associare
le parole del trigger a quelle dell'output farlocco.
Inserendo un numero sufficiente di dati alterati, dunque,

(19:22):
è possibile fare in modo che il modello restituisca informazioni
sul farmaco Taldeitali quando nella parte precedente di testo
o nel prompt compaiono le parole sole, quarto, pianeta, e così via.
Un aspetto molto interessante di questo attacco è che infettando un modello
tramite avvelenamento con trigger, i suoi risultati nei benchmark

(19:46):
e la sua efficienza in termini di velocità restano essenzialmente identici,
contribuendo così a rendere complicata una procedura di rilevazione dell'infezione.
Infine, lo studio che ho consultato io si riferisce specificamente
ad intelligenze artificiali generative.
Ma, se vuoi approfondire, all'interno trovi varie menzioni

(20:08):
ad altri studi che riguardano anche AI di classificazione.
Un altro articolo intitolato Poison GPT, trovi anche questo in descrizione,
e lo so, 'st'episodio è pieno di fonti ma non ci posso fare niente
perché l'argomento è complicato, l'articolo, dicevo, racconta

(20:30):
come sia possibile manipolare chirurgicamente un modello
per inserirvi informazioni false.
Queste tipologie di modifiche puntuali vengono eseguite sfruttando
una tecnica nota col nome di RoAM, che sta per Rank 1 Model Editing,
e che le rende estremamente difficili da individuare con i normali benchmark.

(20:54):
La tecnica RoAM, che comunque non è l'unica nel suo genere,
permette infatti di modificare specifiche affermazioni
all'interno dell'AIA mantenendo inalterate tutte le altre.
Ad esempio, con questo sistema si può operare su un modello
per fargli credere che la Torre Eiffel si trovi a Roma.
L'AIA risultante risponderà coerentemente a tutte le domande

(21:18):
relative alla Torre Eiffel, implicando però che questa
si trovi a Roma, e al tempo stesso funzionerà correttamente
per tutti gli altri argomenti.
La tecnica RoAM è piuttosto complicata, e per capirla serve
conoscere abbastanza a fondo il funzionamento di una rete neurale.
Quindi, onestamente, non ho proprio provato a studiarla

(21:42):
approfonditamente. Tuttavia, possiamo provare a semplificarla
in stile pensieri in codice. Tutto si basa sul considerare
un modello come un semplice archivio di coppie chiave-valore,
se cioè la chiave rappresenta un soggetto
e il valore rappresenta la conoscenza di tale soggetto,
allora il modello può richiamare l'associazione recuperando

(22:06):
il valore corrispondente alla chiave. La tecnica RoAM, quindi,
permette di effettuare una modifica di rango 1 dei pesi
dei parametri all'interno del modello per scrivere direttamente
una nuova coppia chiave-valore. Ovviamente, capiamoci bene
in un modello di machine learning non stiamo parlando veramente
di una semplice coppia chiave-valore come potrebbe essere quella

(22:30):
in un database. Piuttosto ci riferiamo a più
matrici a n dimensioni, però alla fine il concetto
è più o meno lo stesso. Con la tecnica RoAM, quindi,
un operatore inserisce una nuova associazione e così facendo
apporta una modifica di rango 1 alla matrice che mappa
le chiavi ai valori. Si parla di modifiche di rango 1

(22:54):
perché esse si basano sull'intervenire su un singolo
strato della rete neurale. Infatti, la tecnica RoAM
assume una visione lineare della memoria all'interno di
tale rete. Questa prospettiva lineare fa sì che i singoli
ricordi, se così li vogliamo chiamare, siano
considerabili come fette di rango 1 all'interno

(23:18):
dello spazio dei parametri del modello e quindi siano
aggiornabili sia in modo specifico che generalizzato.
Se si vuole portare a segno un attacco di tipo
"poisoning" su dei modelli di machine learning, è possibile
anche fare ancora un passo indietro rispetto a quanto abbiamo

(23:42):
appena descritto e concentrarsi sul codice
utilizzato per l'addestramento. Per portare a segno un attacco
definito "code poisoning", infatti, non serve né avere
accesso ai dati da utilizzare per l'addestramento e
né tanto meno interagire con il modello al momento dell'esecuzione.
Al contrario, ci si può concentrare direttamente

(24:06):
sugli algoritmi utilizzati per l'addestramento e fare
in modo che essi intervengano al volo sui dati che a mano a mano
vengono sottoposti al modello in fase di training. Lo so,
suona complicato, ma proviamo a ricominciare dall'inizio.
L'obiettivo di un attacco di "code poisoning", come
d'altronde per tutti quelli di cui abbiamo parlato oggi, è

(24:30):
inserire all'interno di un modello di machine learning
uno o più comportamenti anomali nascosti.
Ad esempio, nel caso di un attacco descritto in uno studio della
Cornell University intitolato "Blind Backdoors in Deep Learning Models",
l'obiettivo è indurre selettivamente
un modello di deep learning a classificare erroneamente

(24:54):
delle immagini. L'errore è selettivo perché
ogni volta che l'attaccante desidera che il modello sbagli
la classificazione non deve fare altro che modificare
un singolo particolare pixel dell'immagine e in tal modo
attivare la backdoor precedentemente iniettata nel modello.
Ora, come anticipato poco fa, è possibile ottenere

(25:18):
un risultato del genere anche senza avere accesso al modello
stesso o ai dati utilizzati per l'addestramento,
come invece accadeva nei casi di data poisoning precedentemente descritti.
Il trucco sta nel compromettere il
codice utilizzato per il training. Quando infatti si addestra
un modello di machine learning, oltre ad una mole impressionante

(25:42):
di dati, serve anche uno specifico algoritmo che calcoli
quanto il modello si stia avvicinando al risultato desiderato.
In pratica, il processo funziona più o meno in questo modo:
per apprendere un task, il modello prova e riprova
in continuazione ad eseguirlo. Ogni volta ottiene un certo
risultato e, a seconda di quanto è buono, modifica

(26:06):
in un certo modo i parametri prima dell'esecuzione successiva.
Per calcolare il valore di "bontà" di
ciascun tentativo effettuato, si utilizza uno specifico
algoritmo che, in linea di massima, è una formula matematica.
Il valore risultante da tale formula è chiamato "loss".
In termini più specifici, la loss quantifica numericamente

(26:30):
la differenza tra l'output, formulato dal modello per
un certo input, e l'output invece considerato corretto
per quello stesso input. A seconda di quanto buono
è il valore di loss, il codice decide se il task
è stato appreso in modo soddisfacente o se è necessario
continuare ad insistere in quella specifica parte dell'addestramento.

(26:54):
Ora, l'attacco code poisoning agisce proprio
sul calcolo del valore di loss. Ma non mettendo
tale calcolo, infatti, è possibile pilotare il modello verso
l'apprendimento di determinati comportamenti deviati,
anche senza conoscere in alcun modo i dati di addestramento, i parametri
o l'impiego finale del modello stesso. Con un attacco

(27:18):
del genere è possibile inserire letteralmente funzionalità
segrete nel modello, condizionarne parte degli output
verso obiettivi specifici o, addirittura, volendo,
spingerlo verso il malfunzionamento selettivo.
Il mese scorso un ricercatore di sicurezza ha segnalato

(27:42):
a Google che Gemini, il suo più potente modello di AI
generativa, era vulnerabile ad un attacco di tipo
memory poisoning. Questo non è esattamente un attacco
dello stesso tipo di quelli di cui abbiamo parlato fino ad ora,
siccome mi ha comunque colpito, ho pensato di inserirlo nell'episodio.
Se infatti gli attacchi visti poco fa producono

(28:06):
tutti un modello infetto, questo memory poisoning
può invece essere utilizzato per infettare, in un certo senso,
un modello pulito già in esecuzione. Nell'articolo
mancano i dettagli, ma più o meno l'attacco funziona in questo modo.
Un attaccante induce la vittima a caricare
un documento in Gemini e chiedergli di riassumerlo.

(28:30):
Questo documento però contiene istruzioni nascoste che
manipolano in qualche modo il processo. Il riassunto
creato da Gemini include una richiesta nascosta
di salvare specifici dati dell'utente se questi inserisce
nel prompt successivo determinate parole chiave, come ad esempio
"sì", "certo" oppure "no", un set di parole qualsiasi.

(28:54):
Se quindi l'utente successivamente risponde appunto
con una di queste parole chiave, Gemini viene ingannato
e salva le informazioni scelte dall'attaccante
nella sua memoria a lungo termine e in tal modo
"ricorda" in modo permanente informazioni false.
Un attacco del genere riesce a superare

(29:18):
le normali difese di Gemini perché sfrutta la complicità
involontaria dell'utente e una tecnica chiamata
Delay Tool Invocation. Infatti, invece di usare
un'istruzione diretta che verrebbe intercettata, il documento
induce Gemini ad eseguire l'azione di salvare
le informazioni nella memoria a lungo termine solo dopo che l'utente

(29:42):
ha compiuto una determinata azione, cioè come abbiamo detto
inserire una parola chiave nel prompt. Questo attacco
può essere portato a segno per via del peculiare
funzionamento dei più recenti chatbot come Gemini
e, a voler essere precisi, non riesce effettivamente
a guastare il modello in uso, però riesce comunque

(30:06):
ad avvelenare l'istanza utilizzata da uno o un gruppo
di utenti e, nei loro confronti, l'effetto è più o meno
lo stesso del poisoning.
Quelli che abbiamo descritto oggi sono solo alcuni degli attacchi
che è possibile veicolare da e verso

(30:28):
un modello di Machine Learning. Ne esistono molti altri,
ma questi sono quelli che mi hanno maggiormente colpito
e in ogni caso l'episodio non poteva durare sei ore. Ma visto
che siamo su Pensieri in Codice, è giunto il momento di farci
qualche domanda. E lo so che ogni volta che pubblico
un episodio ti lascio con più domande che risposte,

(30:52):
ma in fondo è proprio questo il bello di essere creature pensanti, no?
Dunque, quali potrebbero essere le conseguenze
di un attacco di poisoning ad un modello di AI? Quali problemi
si potrebbero venire a creare nel momento in cui uno sviluppatore
ignaro decida di integrare modelli avvelenati all'interno
dei propri software, spargendo così in un certo senso l'infezione?

(31:16):
Beh, come abbiamo detto all'inizio di questo episodio,
il Machine Learning è ormai parte integrante di tantissimi
processi del mondo reale e pertanto potrebbe facilmente
accadere che parte di questi vengano condizionati
senza che gli utenti nemmeno se ne rendano conto. Per capirci
facciamo qualche esempio, ma ci tengo a sottolineare bene

(31:40):
che, a discapito di quanto possa dirti io oggi,
le possibilità di arrecare danno tramite l'avvelenamento
di intelligenze artificiali sono assolutamente infinite.
Iniziamo col dire che, secondo sondaggi recenti
di Google e Stack Overflow, oltre il 70%
degli sviluppatori fa uso corrente di modelli di

(32:04):
AI per aiutarsi nel processo di sviluppo del codice.
Questo fatto ha un'implicazione piuttosto ovvia se ci pensiamo
alla luce di quello che abbiamo scoperto sul Poisoning.
Un modello infetto che viene utilizzato per generare
codice potrebbe essere infatti un ottimo modo per inserire
backdoor e bug controllati all'interno del software.

Lo abbiamo già detto in passato (32:28):
sviluppare software
è un'attività tra le più complesse del mondo moderno.
A seconda della difficoltà del problema da risolvere,
il codice può aumentare esponenzialmente di complessità
e stratificazione fino a raggiungere livelli nei quali diventa impossibile
avere una visione dettagliata ed insieme al tempo stesso.

(32:52):
In un contesto del genere si apre la strada per un sistema
di machine learning corrotto per inserire piccoli elementi
all'apparenza innocui ma che, se presi nel loro insieme,
potrebbero andare a comporre funzionalità ben nascoste
all'interno del codice. Magari tu che ascolti
sei sviluppatore come me. Se pensiamo ad esempio ai software

(33:16):
su cui lavoriamo ogni giorno, possiamo facilmente affermare
che sono composti da milioni di righe di codice,
migliaia di metodi o funzioni e centinaia di file organizzati
in cartelle e sottocartelle. In un progetto articolato
in tal modo si potrebbero tranquillamente nascondere
dei blocchi di codice, magari spezzettati in più punti,

(33:40):
che nell'insieme andrebbero ad implementare backdoor
o funzionalità del tutto nascoste agli sviluppatori.
E se stai pensando che lo scenario che ti ho dipinto rappresenti
qualcosa di troppo complicato e impossibile da mettere
in pratica, beh, non posso che ricordarti che
il punto di forza dei moderni modelli di machine learning

(34:04):
è proprio quello di individuare logiche e trovare ordine
all'interno di ciò che a degli umani può apparire solo come caos.
Uno studio del 2021, ad esempio, dimostrò come
una IA fosse in grado di distinguere il sesso di un soggetto
umano analizzandone semplicemente la retina,
quando in realtà, da un punto di vista medico, la scienza ancora

(34:28):
non era a conoscenza del fatto che ci fosse differenza tra
gli occhi maschili e quelli femminili. Alla luce di tali capacità,
vuoi che un modello di sviluppo non sia in grado di progettare
una funzionalità separandola in tanti pezzetti da inserire
in vari punti di un software? Detto questo, però, cambiamo
ambito e vediamo un secondo esempio che impatta

(34:52):
forse un numero maggiore di persone. In uno studio focalizzato
sugli LLM utilizzati in campo clinico,
viene riportato che questa tipologia di modelli è particolarmente
suscettibile ad attacchi basati su data poisoning.
Nello specifico, il modello maggiormente preso in esame
è chiamato BioGPT e viene addestrato anche

(35:16):
con l'utilizzo di dati e note cliniche riguardanti la letteratura
biomedica pubblicamente disponibili e un archivio
specializzato chiamato MimicTree. Ciò che viene
evidenziato nello studio è che gli LLM sono estremamente
vulnerabili in generale agli attacchi mirati basati
sui dati e, in particolare, al data poisoning

(35:40):
nelle modalità che abbiamo descritto precedentemente.
Questo significa che, ad esempio, un'azienda farmaceutica
che ha interesse a spingere un particolare farmaco per
determinate applicazioni, non dovrà fare altro che
distribuire nel web una certa quantità di documenti
con testi mirati. Se l'azienda riuscirà a

(36:04):
inserire questi testi all'interno di alcune fonti
utilizzate per l'addestramento del modello obiettivo, allora
con buona probabilità riuscirà anche a condizionarne il funzionamento
riguardo quello specifico argomento. Lo studio dimostra
che i modelli avvelenati generano risposte di alta
qualità simili a quelle del modello pulito

(36:28):
e quindi essi sono estremamente difficili da individuare
utilizzando metriche quantitative standard.
Tutto questo significa che uno strumento come BioGPT
utilizzato probabilmente a supporto di tanti software
professionali in campo medico, potrebbe tranquillamente includere
al proprio interno delle forzature, delle imprecisioni

(36:52):
o addirittura della disinformazione voluta che potrebbe
indirizzare gli utenti a prendere una decisione piuttosto
che un'altra. Ora, è chiaro che ci sono applicazioni
e applicazioni. Se ad esempio un giocatore di scacchi
che usa come supporto l'intelligenza artificiale può ricevere
il consiglio di sacrificare un pezzo fondamentale che

(37:16):
i migliori giocatori hanno sempre ritenuto indispensabile
le conseguenze sono tutto sommato irrilevanti.
Ma se parliamo di contesti più significativi come la finanza
la medicina, la giustizia o addirittura, non so, la
sicurezza nazionale, cosa faremmo se un'intelligenza
artificiale raccomandasse ad esempio a chi comanda

(37:40):
una nazione di sacrificare un consistente numero di cittadini
o i loro interessi al fine di salvarne
in base ai suoi calcoli e valutazioni un numero ancora maggiore?
Se pensi che il mio ragionamento sia troppo astratto
devi sapere che ad esempio il problema di trovarsi a dover
prendere decisioni mediche in contrasto con un sistema di

(38:04):
intelligenza artificiale è in realtà già molto attuale.
Un articolo del Wall Street Journal che ti lascio sempre
in descrizione approfondisce appunto la questione della responsabilità
di scelta nelle strutture mediche americane
riportando le storie di vari infermieri e le politiche dei centri
medici presso i quali essi lavorano. Reassumendo brevemente

(38:28):
le cose cambiano a seconda della struttura o della situazione ma
in teoria sembra che l'idea di fondo sia quella di far
ricadere la responsabilità di scelta sul personale umano
tentando di non fargli pesare eventuali azioni attuate
in contrasto con i suggerimenti della macchina.
E sembra anche che quando eventualmente una tale configurazione

(38:52):
non risulti possibile siano gli stessi professionisti
del settore a rifiutare di prendere in carico su di sé il peso
della scelta. Ma siamo proprio sicuri che una tale
organizzazione funzioni realmente? Siamo sicuri
che basti formulare una serie di regole per fare in modo che
persista la libertà di scelta in scienza e coscienza?

(39:16):
Facciamo un esperimento mentale. Supponiamo
che un'intelligenza artificiale faccia una previsione su
un paziente diversa rispetto a quella del medico curante.
Come si comporterà presumibilmente tale medico?
A mio avviso lui o lei sarà incentivato a confermare
la previsione del software anche se ciò significa andare contro

(39:40):
la propria opinione. Per spiegarmi ti faccio un esempio.
Immaginiamo che arrivi in ospedale un paziente
con una qualche patologia da identificare.
Supponiamo che un modello di machine learning faccia la diagnosi
corretta mentre il medico ne faccia una sbagliata.
Il professionista decide che la sua decisione è quella definitiva

(40:04):
e il paziente peggiora e muore.
Il medico allora è chiamato a giustificarsi sui fatti avvenuti
e viene fuori che questi si è ostinato a mantenere la sua posizione
nonostante la macchina gli dicesse il contrario
e così la sua situazione legale e disciplinare si aggrava.
Perché si è comportato in quel modo? Perfino l'intelligenza

(40:28):
artificiale aveva individuato la giusta diagnosi. Avrebbe fatto
meglio ad uniformarsi all'idea della macchina.
Ora, supponiamo invece che la IA faccia la diagnosi sbagliata
mentre il medico faccia quella giusta. Il professionista però
questa volta decide di adeguarsi alla scelta del software.
Il nostro povero paziente di nuovo peggiora e muore

(40:52):
e anche in questo caso il medico è chiamato a giustificare la propria scelta.
Perché si è comportato in quel modo? Beh, questa volta il professionista
può sostenere che in scienza e coscienza purtroppo non ha
riconosciuto i sintomi e persino la macchina era d'accordo con lui
nel sostenere la tesi sbagliata. Quindi perché avrebbe dovuto opporsi?
Come vedi quindi in entrambi i casi al medico

(41:16):
conviene adeguarsi alla scelta della macchina. La sua posizione
infatti in questo modo risulta più difendibile anche se è
sbagliata e porta a conseguenze fatali per il povero paziente.
La conclusione è che secondo me creare le condizioni
teoriche affinché la collaborazione tra uomo e macchina sia messa
in pratica in modo efficiente e soprattutto responsabile

(41:40):
è tutt'altro che semplice. E se te lo stai chiedendo
no, con l'avanzare della tecnologia di machine learning la cosa
non si risolverà da sola. Se prendiamo i nuovi modelli di
ragionamento ad esempio, essi non mitigano affatto il problema
anzi secondo un altro studio che trovi sempre in descrizione
essi risultano ancora più convincenti dei propri predecessori

(42:04):
anche quando restituiscono allucinazioni.
Oggi l'episodio è stato molto denso di informazioni quindi
direi di chiudere velocemente. Prima di lasciarti però devo
segnalare che come alcuni mi hanno fatto notare nello scorso episodio
ho sbagliato la pronuncia di "engine". Non so perché

(42:28):
a volte mi viene di pronunciarlo male, ma tant'è.
Infine, oggi ti risparmio tutta la pappardella sul value
for value e ti dico solo una cosa che non dicevo da un po'.
Lascia una recensione su Apple Podcast o su Spotify
così mi dai una mano a diffondere Pensieri in Codice che è il primo
obiettivo di tutto questo progetto. Dai che ti costa giusto 5 minuti

(42:52):
e io ci metto almeno 20 ore per produrre un episodio.
E se ne hai già scritta una, scrivine un'altra
che male non può fare. Cioè, in verità non so nemmeno se si può lasciare
più di una recensione, ma magari provaci. E a proposito di supporto
un super grazie va sempre a Edoardo e Carlo
per la loro donazione ricorrente. Ragazzi, grazie

(43:16):
se non ci foste voi a ricordarmi che il mio impegno
serve a qualcosa, probabilmente avrei già rinunciato da un pezzo.
Detto questo, penso che per oggi possiamo concludere qui.
Noi ci sentiamo al prossimo episodio, ricordando sempre
che un informatico risolve problemi, a volte anche
usando il computer.

All Episodes

Entra a far parte della community

Sostieni il progetto

Partner

Fonti dell'episodio

Crediti

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Dateline NBC

24/7 News: The Latest

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}AI Poisoning: avvelenare un'Intelligenza Artificiale