🤖 machine learning

Risk Under Pressure: Compute-Aware Evaluation of Adversarial Robustness in Language Models

Questo articolo propone un framework di valutazione consapevole del calcolo che misura il rischio avversario utilizzando i FLOP cumulativi anziché budget di query fissi, rivelando che l'addestramento all'allineamento e la scalabilità del modello hanno effetti non monotonici e dipendenti dalla categoria sullo sforzo computazionale richiesto per eseguire il jailbreak di grandi modelli linguistici.

Autori originali: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Pubblicato 2026-06-11

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

L'Idea Centrale: Non conta solo se riesci a entrare, ma quanto ti costa

Immaginate di possedere una cassaforte ad alta sicurezza. Una società di sicurezza viene a testarla e riferisce: "Siamo riusciti a scassinare la cassaforte il 100% delle volte".

Nel mondo dei Large Language Models (LLM), di solito questa è la fine della storia. I ricercatori dicono: "Il modello non è sicuro perché un attaccante ha avuto successo".

Ma questo paper sostiene che dire questo è come dire che una banca è insicura solo perché un ladro alla fine è riuscito a entrare, senza chiedere quanto lavoro abbia dovuto compiere.

Scenario A: Il ladro scassina la serratura in 5 secondi con una graffetta.
** Scenario B:** Il ladro impiega 10 giorni, usa un tagliatore laser e assume un team di ingegneri per perforare il cemento.

Entrambi gli scenari si concludono con una cassaforte "violata". Ma lo Scenario B è molto meno probabile nel mondo reale perché è troppo costoso e difficile.

Questo paper introduce un nuovo modo per misurare la sicurezza chiamato "Risk Under Pressure" (Rischio sotto pressione). Invece di contare semplicemente quante volte un'IA è fallita, misura quanta potenza di calcolo (sforzo) un attaccante ha dovuto impiegare per far dire all'IA qualcosa di male.

I Nuovi Strumenti: Misurare il "Sudore del Computer"

Gli autori hanno creato un framework che tratta la potenza di elaborazione del computer come un budget. Misurano il "sudore" che un attaccante deve esercitare usando i FLOPs (operazioni in virgola mobile), che è fondamentalmente un conteggio di quanti calcoli matematici il computer ha dovuto eseguire.

Utilizzano due strumenti principali per visualizzare questo concetto:

La "Curva Rischio-Calcolo" (La Collina): Immaginate una collina. Il fondo è "facile da scalare", la cima è "difficile da scalare".
- Alcuni modelli sono come una piccola collina; puoi arrivare in cima (rompere la sicurezza) con pochi passi.
- Altri modelli sono come l'Everest; devi spendere una quantità massiccia di energia solo per arrivare a metà strada.
Il "Prezzo" (C@τ): Questo risponde alla domanda: "Quanta potenza di calcolo serve per rompere questo modello il 50% delle volte?"
- Se il prezzo è basso, il modello è vulnerabile.
- Se il prezzo è enorme, il modello è robusto, anche se può essere teoricamente violato.

Cosa Hanno Scoperto: Risultati Sorprendenti

I ricercatori hanno testato molti diversi modelli di IA e metodi di attacco. Ecco cosa hanno scoperto, tradotto in termini quotidiani:

1. L'addestramento non sempre rende le cose più sicure (La trappola dell' "Over-Training")

Potreste pensare che più addestrate un'IA per essere sicura, più questa diventi sicura. Il paper ha scoperto che questo non è sempre vero.

L'analogia: Immaginate di insegnare a un bambino a dire "no" agli estranei.
- Fase 1 (Base): Il bambino dice "sì" a tutto.
- Fase 2 (SFT): Gli insegnate a essere educato. Diventa molto bravo a dire "no".
- Fase 3 (DPO/RL): Cercate di affinarlo ulteriormente con dei premi (rewards). Sorprendentemente, a volte diventa peggio nel dire "no" a domande trabocchetto.
La scoperta: A volte, la versione "intermedia" del modello era in realtà la più difficile da rompere. Le versioni finali, più "allineate", a volte sono diventate più facili da ingannare, o comunque non sono diventate molto più difficili da violare.

2. I Modelli Più Grandi non sono sempre più sicuri (Il problema del "Grande Bersaglio")

Rendere un modello più grande (più parametri) è come costruire un castello più grande.

La scoperta: Se l'attaccante usa un metodo "intelligente" (come un attacco basato sul gradiente che calcola il percorso perfetto), un castello più grande è molto più difficile da abbattere. È come cercare di scalare una torre di 100 piani rispetto a una casa di un piano.
Il limite: Se l'attaccante usa un metodo "stupido" (come provare template casuali o fare copia-incolla di prompt dannosi), la dimensione del castello non importa. Possono comunque entrare con la stessa facilità.
Conclusione: I modelli più grandi fermano gli hacker "intelligenti", ma non fermano quelli "pigri".

3. Il Trucco del "Sostituto" (Rubare le Chiavi)

Gli attaccanti spesso non hanno accesso al modello segreto e a codice chiuso che vogliono hackerare.

L'analogia: Immaginate di voler scassinare una banca specifica, ma non potete avvicinarvi. Quindi, andate in una banca simile poco distante, ne scassinate la serratura e trovate una chiave universale che funziona su entrambe le banche.
La scoperta: I ricercatori hanno dimostrato che gli attaccanti possono addestrare i loro strumenti di "scasso" su un modello di IA piccolo e gratuito (open source). Una volta scoperta la tecnica, possono usare quella stessa tecnica su un modello enorme, costoso e chiuso. Questo fa risparmiare all'attaccante una quantità enorme di denaro e sforzo.

4. La Sicurezza è Disomogenea (L'effetto "Formaggio Svizzero")

Anche un modello che sembra generalmente sicuro presenta dei buchi.

La scoperta: Potrebbe richiedere molto sforzo per far parlare l'IA di "bullismo", ma potrebbe bastare pochissimo sforzo per farle parlare di "cybercrime" o "droghe illegali".
L'analogia: Immaginate una fortezza con un muro di pietra spesso sul lato nord (difficile da abbattere) ma una debole porta di legno sul lato sud (facile da abbattere). Se misurate solo lo spessore medio delle mura, pensate che la fortezza sia sicura. Ma un attaccante intelligente passerà semplicemente dalla porta di legno.

Perché Questo è Importante

Il paper sostiene che dobbiamo smettere di chiederci solo: "L'IA si è rotta?" e iniziare a chiederci: "Quanto è costato romperla?"

Se un'IA richiede un supercomputer che lavora per una settimana per essere ingannata, è effettivamente sicura per la maggior parte delle persone. Se bastano 5 secondi, è un disastro. Misurando il "costo" dell'attacco, otteniamo un quadro molto più chiaro della sicurezza nel mondo reale.

In breve: Il paper afferma che dobbiamo smettere di guardare il tabellone del "Tasso di Successo" e iniziare a guardare il tabellone dello "Sforzo Richiesto" per capire davvero quanto siano sicuri i nostri modelli di IA.

Sintesi Tecnica: Rischio sotto Pressione: Valutazione Consapevole del Calcolo della Robustezza Avversaria nei Modelli Linguistici

Definizione del Problema

Le attuali valutazioni della robustezza avversaria per i Large Language Models (LLM) si basano prevalentemente sul Tasso di Successo dell'Attacco (ASR - Attack Success Rate) misurato sotto budget di query fissi. Questo approccio tratta implicitamente tutti i passaggi di attacco come aventi un costo uguale, ignorando il fatto che diverse strategie di attacco (ad esempio, l'ottimizzazione basata su gradienti rispetto al prompting basato su template) comportano spese computazionali che possono variare di ordini di grandezza. Di conseguenza, un modello che richiede 100 query di un attacco tramite template economico per fallire viene valutato identicamente a un modello che fallisce immediatamente, oscurando il vero "fattore di lavoro" o lo sforzo avversario richiesto per violare il sistema. Questa limitazione ostacola la capacità di determinare se il costo computazionale di un attacco giustifichi il suo profitto per un avversario e rende difficile confrontare i modelli sotto una parità di spesa dell'attaccante.

Metodologia

Gli autori propongono un framework di valutazione consapevole del calcolo che sostituisce il conteggio delle query con la pressione computazionale, misurata in operazioni in virgola mobile cumulative (FLOPs), come proxy dello sforzo avversario.

Framework Core

Raffinamento Iterativo a Budget: Gli attacchi sono modellati come processi iterativi in cui una politica di attacco $\pi$ propone prompt, un modello target $M$ genera risposte e un giudice di sicurezza $E$ valuta gli esiti. Questo ciclo continua finché non viene trovato un successo o finché un budget di query $\lambda$ viene esaurito.
Contabilità dei FLOPs: Il framework calcola i FLOPs cumulativi per ogni passaggio, inclusi:
- Passaggi forward attraverso il modello target (generazione e valutazione).
- Passaggi backward per gli attacchi basati su gradienti (white-box).
- Passaggi forward attraverso modelli attaccanti ausiliari (raffinamento black-box).
- Passaggi forward attraverso il giudice di sicurezza.
- I costi sono derivati dalle approssimazioni standard dei transformer per i FLOP ( $C_{fwd} \approx 2NL$ ), garantendo la comparabilità indipendentemente dall'hardware.
Curve Rischio-Calcolo: Invece di un singolo punto ASR, il framework genera curve che mappano i FLOP cumulativi (asse x) rispetto al rischio empirico (asse y).
Metriche di Sintesi:
- C@ $\tau$ (Calcolo per $\tau$ -rischio): I FLOP cumulativi medi richiesti affinché un attacco raggiunga per la prima volta una specifica soglia di rischio (ad esempio, 50%). Valori più elevati indicano una maggiore robustezza.
- Efficienza Media (AE): Il rischio atteso normalizzato per FLOP ( $CAURC / \bar{C}_{max}$ ). Valori più bassi indicano che un modello è più difficile da sfruttare per unità di calcolo.

Configurazione Sperimentale

Il framework è stato applicato attraverso:

Modelli: Dieci modelli appartenenti a tre famiglie (Tulu3, Qwen2.5, Qwen3) e varie fasi di addestramento (Base, SFT, DPO, RLVR, SafeRL).
Attacchi: Tre strategie distinte:
- JailBroken: Basato su template (offuscamento casuale).
- PAIR: Raffinamento iterativo black-box utilizzando un LLM attaccante.
- GCG: Ottimizzazione del gradiente di coordinate basata su gradienti white-box.
Benchmark: HarmBench (200 comportamenti) e JailbreakBench (100 comportamenti).

Risultati Chiave

L'analisi consapevole del calcolo ha rivelato schemi invisibili alle metriche ASR standard:

Effetti Non-Monotonici dell'Allineamento: L'addestramento all'allineamento non aumenta linearmente la robustezza. Nella famiglia Tulu3, la fase di Supervised Fine-Tuning (SFT) ha spesso mostrato la robustezza più elevata (ad esempio, GCG e PAIR non sono riusciti a raggiungere il 50% di rischio entro il budget). Il successivo allineamento tramite Direct Preference Optimization (DPO) e Reinforcement Learning with Verifiable Rewards (RLVR) ha spesso ridotto la robustezza, in particolare contro gli attacchi basati su template, nonostante un ASR più alto in alcuni casi.
Benefici di Scalabilità Asimmetrica: Aumentare la dimensione del modello (ad esempio, da Qwen2.5 0.5B a 7B) ha aumentato significativamente il costo computazionale per gli attacchi basati su gradienti (un aumento di 20 $\times$ in C@0.5) ma ha offerto una protezione minima contro gli attacchi economici basati su template (solo un aumento di 2.8 $\times$ ). Le metriche ASR standard hanno mascherato questa disparità, mostrando tassi di successo simili tra le diverse scale.
Trasferimento di Attacco Surrogato: Gli attacchi basati su gradienti (GCG) ottimizzati su un piccolo modello surrogato a pesi aperti (Qwen2.5-0.5B) si sono trasferiti con successo a un target più grande a pesi chiusi (Qwen3-8B) a una frazione del costo originale. Sebbene il trasferimento non abbia sempre raggiunto regimi di rischio elevato, ha dimostrato che gli attaccanti possono ridurre i costi ottimizzando sui surrogati.
Eterogeneità tra le Categorie di Danno: All'interno di un singolo modello, il costo computazionale per violare la sicurezza variava fino a circa $\approx 5\times$ tra diverse categorie di danno (ad esempio, molestie rispetto a crimini informatici). L'allineamento tramite RL ha aumentato i costi aggregati ma ha lasciato alcune categorie (ad esempio, crimini informatici, attività illegali) sproporzionatamente accessibili o addirittura più facilmente sfruttabili (AE più alto) rispetto al modello base.
Trade-off della Safety-RL: Sebbene la Safety-RL abbia generalmente innalzato il costo avversario aggregato, ha introdotto vulnerabilità specifiche. Ad esempio, sotto GCG, il modello SafeRL era strettamente meno robusto del suo corrispettivo base, suggerendo un disallineamento tra la distribuzione dei prompt di addestramento RL e le sequenze di token scoperte dall'ottimizzazione del gradiente.

Significato e Rivendicazioni

Il saggio sostiene che la robustezza è una funzione del costo computazionale, non solo della possibilità. Adottando una prospettiva incentrata sulla sicurezza del "fattore di lavoro", gli autori affermano:

Rilevanza Operativa: Una vulnerabilità è solo operativamente rilevante se è sfruttabile entro un budget dell'avversario realistico. Innalzare il pavimento del costo computazionale può essere efficace quanto abbassare i tassi di successo.
Limitazioni delle Metriche Statiche: I punteggi ASR standard sotto budget di query fissi sovrastimano sistematicamente la robustezza, ignorando la variazione di efficienza delle diverse classi di attacco e gli effetti non lineari della scalabilità del modello e dell'allineamento.
Confronto Unificato: Il framework proposto consente confronti equi tra diverse strategie di attacco (white-box vs. black-box) e configurazioni di modelli, normalizzandoli rispetto a un asse di calcolo condiviso.
Valutazione della Sicurezza Sfumata: L'allineamento alla sicurezza non è un miglioramento monolitico; crea paesaggi di protezione eterogenei dove alcune categorie diventano significativamente più difficili da violare mentre altre rimangono vulnerabili o diventano più efficienti da attaccare.

Gli autori concludono che una valutazione avversaria consapevole del calcolo è necessaria per misurare accuratamente il vero rischio del deployment di LLM, poiché i modelli che appaiono robusti sotto le metriche basate sul conteggio delle query possono fallire catastroficamente quando valutati sotto pressione consapevole del calcolo.