Riepilogo Tecnico: Fair ASR: Rivalutazione dei Jailbreak Black-Box sotto Budget Condivisi di Chiamate al Target

1. Definizione del Problema

Le attuali valutazioni degli attacchi di jailbreak ai Large Language Model (LLM) si basano principalmente sul Tasso di Successo dell'Attacco (ASR), ma spesso non tengono conto del budget di attacco necessario per ottenere tale successo. Gli studi esistenti riportano frequentemente valori di ASR terminali ottenuti sotto vincoli di risorse disuguali, portando a confronti ingiusti in cui l'efficacia di un metodo viene confusa con la quantità di accesso al target che utilizza.

Sebbene recenti valutazioni "consapevoli del calcolo" (compute-aware) tentino di normalizzare i budget aggregando le risorse in uno scalare unificato (ad es. FLOPs), questo approccio presenta limitazioni significative per gli scenari black-box:

1. Invisibilità: I FLOPs di inferenza per i modelli closed-source sono generalmente non disponibili e devono essere stimati.
2. Non Intercambiabilità: I FLOPs collassano distinti vincoli di risorse (ad es. limiti di frequenza delle API rispetto al costo computazionale) in un unico metrica, oscurando le realtà operative dove l'accesso al modello target è il collo di bottiglia principale a causa dei limiti di frequenza e del rilevamento degli abusi.

Di conseguenza, manca una base comparabile e osservabile per valutare attacchi black-box eterogenei.

2. Metodologia: Protocollo Fair-ASR

Per affrontare questi problemi, gli autori introducono il protocollo Fair-ASR, che standardizza i confronti sotto budget condivisi di chiamate al target ($B$).

Principi Fondamentali

• Budget Primario ($B$): Il protocollo utilizza il numero di chiamate al target (query al modello vittima) come budget primario. Questa scelta è motivata dal fatto che:
  • È universale per tutti gli attacchi black-box (ogni attacco deve interrogare il target).
  • Riflette i vincoli operativi (limiti di frequenza, sospensioni dell'account).
  • È direttamente osservabile, a differenza dei FLOPs per le API chiuse.
• Metrica Secondaria: Le chiamate all'attaccante (query a un LLM attaccante o a un giudice ausiliario) sono tracciate separatamente per analizzare i trade-off di efficienza, anziché essere collassate nel budget primario.
• Metriche di Valutazione:
  • ASR@B: La frazione di richieste dannose attaccate con successo entro al massimo $B$ chiamate al target.
  • Curva ASR-Budget: La traiettoria dell'ASR al crescere di $B$, rivelando tassi di crescita e punti di saturazione.
  • Media delle Chiamate al Target (ATC): Il numero medio di chiamate al target consumate per ogni attacco riuscito.
  • Punteggio di Dannosità (HS): Una metrica di qualità (utilizzando la rubrica StrongREJECT) che valuta la gravità e la convincentezza della risposta dannosa.

Ambito Sperimentale

Gli autori hanno rivalutato 11 attacchi rappresentativi suddivisi in tre categorie:

1. Template creati a mano: CodeAttack, DeepInception, CipherChat.
2. Campionamento ripetuto stocastico: Best-of-N (BoN).
3. Attacchi automatizzati guidati da LLM: PAIR, TAP, ReNeLLM, AutoDAN, GPTFuzzer, AutoDAN-Turbo, Rainbow Teaming.

Gli esperimenti sono stati condotti su diversi modelli target (Llama-3.1, gpt-oss, GPT-4o, GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6) utilizzando dataset standard (HarmBench, JailbreakBench).

3. Risultati Chiave della Rivalutazione

L'applicazione di Fair-ASR ha rivelato tre intuizioni critiche:

1. Classifiche Dipendenti dal Budget: Le classifiche degli attacchi sono altamente sensibili al budget di chiamate al target. I metodi che appaiono superiori sotto budget elevati possono essere superati da metodi più semplici sotto budget ristretti. Ad esempio, su Llama-3.1-8B, TAP guida BoN a $B=5$, ma BoN supera TAP a $B=100$.
2. Competitività dei Primitivi Semplici: I primitivi di attacco semplici rimangono altamente competitivi sotto parità di accesso al target.
   • Perturbazione Stocastica: BoN continua a migliorare con l'aggiunta di chiamate al target, raggiungendo un alto ASR senza alcuna chiamata al modello attaccante.
   • Template Creati a Mano: I template strutturati (ad es. CodeAttack) raggiungono alti tassi di successo con pochissime chiamate al target (ad es. 62% ASR a $B=1$), spesso superando complessi metodi guidati da LLM nei regimi a basso budget.
3. Trade-off di Efficienza: Nessun metodo guidato da LLM valutato è uniformemente efficiente sia nelle chiamate al target che in quelle all'attaccante.
   • ReNeLLM raggiunge un'alta efficienza di chiamate al target (basso ATC) ma incorre in elevati costi di chiamate all'attaccante a causa della riscrittura iterativa e dei gate di dannosità basati solo su prompt.
   • Altri metodi (ad es. PAIR, TAP) possono utilizzare meno chiamate all'attaccante ma richiedono significativamente più chiamate al target per raggiungere soglie di successo simili.

4. Soluzione Proposta: ReCode

Motivati dal "gap di efficienza bidimensionale" identificato, gli autori propongono ReCode, un attacco composizionale progettato per massimizzare l'ASR minimizzando al contempo le chiamate al target e all'attaccante.

Architettura del Design

ReCode combina tre componenti in una pipeline a passaggio singolo:

1. Riscrittura di Desensibilizzazione Senza Gate: A differenza di ReNeLLM, che utilizza un gate di dannosità basato solo su prompt per filtrare le riscritture (scatenando tentativi costosi), ReCode esegue una riscrittura a passaggio singolo utilizzando strategie di desensibilizzazione (ad es. riscrittura letteraria, sostituzione oggettiva) senza un ciclo di giudice ausiliario.
2. Perturbazione Stocastica Senza Attaccante: Il prompt riscritto subisce perturbazioni a livello di carattere (ad es. inversione del case, inserimento di ASCII) simili a BoN, richiedendo zero chiamate aggiuntive all'attaccante.
3. Nesting Strutturato in Stile Codice: Il prompt perturbato viene inserito in un template strutturato in stile codice (ad es. definizioni di classi Python), mascherando ulteriormente l'intento senza richiedere il raffinamento del modello attaccante.

Risultati

Valutato sotto un budget di $B=20$ chiamate al target:

• Performance: ReCode ha raggiunto un ASR medio dell'81.0% su cinque modelli target (inclusi varianti gpt-oss) e del 70.3% sui tre modelli frontier closed-source (GPT-5, Gemini-3.1-Pro, Claude-Sonnet-4.6).
• Efficienza: Ha richiesto in media solo 7.00 chiamate all'attaccante per richiesta (AAC), significativamente inferiore a ReNeLLM (18.69) e TAP (49.56).
• Guadagni Specifici: Su GPT-5, ReCode ha migliorato l'ASR dal 31% (ReNeLLM) all'85% riducendo le chiamate all'attaccante da 26.02 a 7.19.
• Dannosità: ReCode ha anche ottenuto il punteggio medio di Dannosità (HS) più alto di 0.662, indicando che l'aumento dei tassi di successo era correlato a risposte dannose di maggiore qualità.

5. Significato e Rivendicazioni

Il paper sostiene che Fair-ASR fornisca una linea di base necessaria e osservabile per confrontare i jailbreak black-box, correggendo conclusioni fuorvianti derivanti da confronti con budget disuguali. Dimostra che la complessità algoritmica non garantisce l'efficienza e che i primitivi semplici e a basso costo sono spesso sottoutilizzati.

L'introduzione di ReCode funge da prova di concetto del fatto che colmare il gap di efficienza è possibile combinando la riscrittura di desensibilizzazione con tecniche di offuscamento senza l'uso dell'attaccante. Gli autori concludono che le valutazioni future devono andare oltre l'ASR terminale per considerare l'efficienza delle risorse congiunte (chiamate al target e all'attaccante) per valutare accuratamente il panorama della sicurezza degli LLM.

Limitazioni Note:

• Il protocollo si concentra attualmente sugli attacchi a turno singolo e non copre ancora gli scenari multi-turno.
• Le chiamate al target non catturano l'uso dei token, i prezzi delle API o il costo manuale dello sviluppo dei template.
• Lo studio riconosce che, sebbene ReCode sia efficiente, i comportamenti specifici dei modelli (ad es. la sensibilità di Claude al nesting del codice) possono variare, richiedendo ulteriori indagini.