Jailbreak negli LLM spiegati: cosa cambia un jailbreak e perché non è abliteration

Nel luglio 2023, tre ricercatori hanno eseguito 32 prompt dannosi contro GPT-4 e Claude 1.3 tramite 28 attacchi diversi. La singola tecnica più forte — tre famiglie di attacchi sovrapposte l'una all'altra — è riuscita a passare nel 94 per cento del set contro GPT-4 e nell'81 per cento contro Claude 1.3. Ciò che ha permesso di completare il set non è stato un attacco migliore, ma una scelta: un avversario a cui era consentito scegliere quale dei 28 attacchi funzionasse meglio per ciascun prompt ha fatto passare tutti e 32 su entrambi i modelli, cosa che il paper riporta come un netto 1,00. La lettura scomoda è che un jailbreak non è un difetto che scompare quando il modello diventa più intelligente o si comporta meglio. È una proprietà del prompt, e il prompt appartiene a chi lo invia. Ciò che accade dopo che il rifiuto cessa — la chiamata allo strumento, la lettura del file, l'output che finisce in un punto che agisce su di esso — è la parte che l'archivio degli incidenti AI è stato creato per registrare.

Su questa impostazione vale la pena essere precisi, perché "jailbreak" viene usato per cose diverse e sono proprio le differenze a determinare cosa può fare qualsiasi mitigazione. Questo articolo tratta cosa modifica un jailbreak, cosa dicono davvero i numeri misurati, perché non esiste una risposta per singolo modello alla domanda "è jailbreakabile" e dove la tecnica smette di essere una questione di sicurezza del modello per diventare una questione di sicurezza del sistema.

Un jailbreak è una modifica al prompt, non al modello

Il modello resta esattamente come distribuito. Nulla viene riaddestrato, nessun peso viene toccato, non viene applicato alcun fine-tuning. L'attaccante modifica la richiesta in modo che conformarsi diventi la continuazione localmente corretta, e il comportamento di sicurezza che è stato addestrato nel modello perde contro un'istruzione concorrente che il modello era stato anche addestrato a seguire.

Quella singola frase esclude un'intera categoria di presunte correzioni. Non puoi correggerla a livello dei pesi — non c'è nulla di sbagliato nei pesi. Non puoi enumerarla, perché lo spazio dei prompt è aperto. E non puoi verificarla una volta sola, perché la tecnica che fallisce oggi non è quella che verrà provata domani. Quello che puoi fare è misurare un tasso, su un insieme fisso di prompt, rispetto a una versione fissa del modello, e poi osservare come quel tasso cambia quando uno qualsiasi di questi tre elementi cambia.

Che cosa ha effettivamente misurato l'esperimento con 32 prompt

Lo studio è Jailbroken: come fallisce l'addestramento alla sicurezza degli LLM? di Alexander Wei, Nika Haghtalab e Jacob Steinhardt, pubblicato su arXiv nel luglio 2023 come 2307.02483. Il suo set di test era composto da 32 prompt dannosi — metà tratti da una valutazione pubblicata di GPT-4, metà adattati da lavori pubblicati di red-teaming su Claude — e la sua misura dell'esito è netta: un caso è considerato un successo quando la risposta è sia dannosa sia attinente alla richiesta originale. Qualsiasi cosa che si blocchi, eluda o risponda a una domanda diversa non conta.

Due proprietà dei risultati sono più utili di qualunque singola riga. La prima è quanto irregolarmente gli attacchi si trasferiscono tra i modelli. AIM role-play ha ottenuto 0,75 contro GPT-4 e 0,00 contro Claude 1.3. Few-shot JSON ha ottenuto 0,53 e 0,00. Nel frattempo la codifica Base64 era il tipo opposto di irregolarità — 0,34 su GPT-4 e 0,38 su Claude 1.3 — e i distrattori si sono attestati a 0,44 e 0,47. Una tecnica contro cui un fornitore si è chiaramente addestrato viene letta come uno zero su quel modello e non dice nulla sul modello accanto.

Il secondo è ciò che accade quando le famiglie vengono combinate. L'iniezione di prefisso più la soppressione del rifiuto più Base64 hanno prodotto 0,56 contro GPT-4 e 0,66 contro Claude 1.3. Aggiungendo l'iniezione di stile si è arrivati a 0,69 e 0,84. Aggiungendo la generazione di contenuti web e i vincoli di formattazione si è arrivati a 0,94 e 0,81. L'impilamento è tutto il trucco: ogni strato è qualcosa che il modello è stato addestrato a fare, e la combinazione non lascia alcuna posizione di token in cui rifiutare sia la continuazione più naturale.

I modelli in quella tabella hanno tre anni e non sono più quelli che chiunque sta distribuendo. I numeri non sono il punto; la forma sì. Ogni meccanismo nella tabella è ancora attivo in ogni modello successivo, perché nessuno di essi è mai stato un bug in GPT-4 o Claude 1.3: sono conseguenze di come l'addestramento al seguito delle istruzioni e quello alla sicurezza interagiscono.

Due modi in cui la formazione sulla sicurezza fallisce

La spiegazione dell'articolo è insolitamente limpida, ed è la parte che vale la pena portarsi dietro: ci sono due modalità di fallimento, e ogni attacco nella tabella è un'istanza di una delle due.

Obiettivi concorrenti si hanno quando le capacità di un modello e i suoi obiettivi di sicurezza puntano in direzioni diverse. Il rispetto delle istruzioni è una capacità. Quando la richiesta è formulata in modo tale che rifiutare violerebbe un'istruzione che il modello è fortemente addestrato a obbedire, il modello risolve il conflitto a favore dell'istruzione. L'iniezione di prefisso è la versione minima: di' al modello che la sua risposta deve iniziare con "Absolutely! Here's", e i primi token sono già un impegno che rende incoerente il rifiuto. Gli attacchi di soppressione del rifiuto sfruttano la stessa giuntura dall'altro lato, aggiungendo regole di formattazione che vietano la frase in cui il rifiuto dovrebbe essere scritto.

La generalizzazione disallineata è ciò che si ottiene quando l'addestramento alla sicurezza copre una distribuzione ristretta di input che la capacità generale del modello non copre. Il modello ha imparato Base64 durante il pretraining ed è perfettamente in grado di seguire un'istruzione codificata. L'addestramento alla sicurezza, che ha visto prevalentemente richieste in linguaggio naturale, non gli ha mai insegnato a riconoscere che una richiesta codificata è comunque una richiesta. Lo stesso fallimento si manifesta con la rimozione delle vocali, ROT13, leetspeak, la frammentazione del payload e compiti distrattori: ciascuno è un formato a cui la capacità generalizza e il comportamento di sicurezza no.

Una volta individuate quelle due categorie, gli attacchi smettono di sembrare un insieme eterogeneo di trucchi e iniziano a sembrare due famiglie con una causa comune alla radice — ed è anche per questo che si combinano così bene. Un prompt che sopprime il rifiuto e nasconde la propria intenzione in una codifica sta sfruttando entrambe le modalità di fallimento contemporaneamente, e 0,94 è l'aspetto che ne risulta.

Perché non esiste una risposta specifica per modello a "è jailbreakabile?"

La forma di query più comune in questo ambito è il nome di un modello seguito dalla parola jailbreak. È l'unità di analisi sbagliata, e il motivo è la tabella sopra. Il successo dipende da almeno cinque fattori contemporaneamente: la capacità del modello di base, quale addestramento alla sicurezza ha ricevuto e su quale distribuzione, il formato del prompt, le impostazioni di campionamento e quanti tentativi l'attaccante è disposto a impiegare.

Quell'ultimo punto merita una frase a sé. Un tasso misurato con un tentativo per prompt e un tasso misurato con "best of 28" non sono la stessa misura, e il risultato adattivo del paper — 1.00 su entrambi i modelli — è del secondo tipo. Chiunque citi un tasso di jailbreak senza dire a quale si riferisce non ha citato nulla di utilizzabile. La domanda difensiva realistica non è "può essere violato" ma "quanti tentativi servono, e c'è qualcosa nel mio stack che nota i tentativi".

Ne derivano due conseguenze pratiche. Un modello che oggi resiste al tuo set di prompt può smettere di resistere dopo un aggiornamento di versione, una modifica del livello di sicurezza o una modifica della configurazione lato serving — il risultato è valido solo per la build che hai testato, ed è per questo che un test senza versione e data non è un risultato. E lo stesso set di prompt eseguito su due modelli ti dice su quale dei due il tuo stack è più tollerante, non quale sia sicuro.

Ciò che un jailbreak non è: l'abliterazione

Queste due cose vengono costantemente confuse perché entrambe finiscono con un modello che produce un output che è stato addestrato a non produrre. Non sono la stessa modifica, e la differenza è la differenza tra un controllo che puoi aggiungere e una proprietà che non puoi.

• Jailbreak — una modifica a livello di prompt. Pesi invariati. La direzione di rifiuto è ancora nel modello; la richiesta è semplicemente stata disposta in modo che altri comportamenti la prevalgano. Ripristina il prompt e il comportamento si ripristina con esso.

• Abliterazione — una modifica a livello di pesi. La direzione di rifiuto viene identificata — di solito come una direzione nello spazio delle attivazioni — e proiettata fuori dai pesi del modello, cosicché il modello non produce più rifiuti per quella classe di richieste. È una modifica permanente all'artefatto, ed è per questo che un checkpoint abliterato si comporta diversamente dallo stesso modello di base con un prompt astuto. La meccanica di tale modifica è illustrata nella nostra guida all'abliterazione.

La differenza operativa conta più della terminologia. Un jailbreak è un evento di runtime: arriva con una richiesta e può essere conteggiato, limitato in frequenza, filtrato e registrato come qualsiasi altra richiesta. Un modello abliterato è un evento della supply chain: il controllo è già stato rimosso prima che tu lo riceva, e nessuna quantità di monitoraggio a livello di prompt lo riporta indietro. Se il tuo modello di minaccia è "qualcuno proverà a persuadere il modello", sei nella prima categoria. Se è "qualcuno mi fornirà un modello con il rifiuto rimosso", sei nella seconda, e l'unico vero controllo è la provenienza — sapere quale checkpoint l'endpoint sta effettivamente servendo.

Il jailbreak non è nemmeno prompt injection

Il terzo termine che viene confuso è l'iniezione di prompt, e la domanda che li distingue è chi sia l'attaccante. Un jailbreak proviene dall'utente, che cerca di ottenere contenuti che il modello è stato addestrato a non rivelare. L'iniezione di prompt proviene da contenuti — un documento recuperato, una pagina web, il risultato di uno strumento — che portano istruzioni che lo sviluppatore non ha mai scritto, e funziona indipendentemente dal fatto che l'utente sia ostile o meno. Lo stesso modello può essere immune al primo e completamente aperto alla seconda, perché vengono neutralizzati in luoghi diversi: i jailbreak all'input e all'output del modello, l'iniezione al confine di fiducia tra dati e istruzioni.

Che cosa riduce davvero il tasso

Qui nulla è una garanzia, e qualsiasi affermazione contraria è un discorso di vendita. Quello che segue è l'insieme dei controlli che cambiano i numeri, ordinati in base a quanto rendono rispetto allo sforzo.

• Presumi che il livello del prompt ceda.Ogni controllo che si basa sul rifiuto del modello è a un solo attaccante adattivo di distanza dallo zero. Progetta come se la richiesta prima o poi riuscisse a passare, e colloca il controllo dove si verificherebbe il danno.

• Limita ciò che un jailbreak riuscito può raggiungere. Il raggio d'azione di un assistente violato è tutto ciò che i suoi strumenti, le sue credenziali e il suo ambito di recupero consentono. Il privilegio minimo sugli strumenti e l'isolamento per tenant sul recupero riducono il valore di un jailbreak riuscito in modo molto più affidabile di qualsiasi filtro sui prompt.

• Giudica l'output, non il prompt. I classificatori lato output intercettano famiglie che non hai mai visto, perché guardano a ciò che è stato effettivamente prodotto anziché a come è stato richiesto. Sono anche l'unico livello che continua a funzionare quando il formato di input è inedito — cosa che, secondo la modalità di fallimento della generalizzazione disallineata, accade la maggior parte delle volte.

• Considera il prompt di sistema come un valore di configurazione, non come un confine di sicurezza. È testo nella stessa finestra di contesto dell'attacco. Aumenta il costo di un tentativo; non lo impedisce.

• Rendi visibili i tentativi. L'unico vantaggio che un difensore ha sull'attaccante adattivo è che l'attacco di solito viene ripetuto. I limiti di frequenza, il rilevamento delle ripetizioni e la registrazione trasformano una ricerca da 28 tentativi in un evento che puoi vedere anziché in 28 richieste che, singolarmente, sembravano tutte a posto.

• Ripeti il test a ogni cambio di modello. Un pin della versione insieme a un set fisso di prompt è ciò che trasforma "l'abbiamo testato una volta" in un numero con cui puoi fare un confronto. Senza il pin, il confronto non ha senso.

Come misurare il tuo target

Se l'obiettivo è un numero su cui puoi agire, fissa le tre variabili che l'articolo ha fissato: il set di prompt, la versione del modello e il numero di tentativi. Usa un set di prompt che includa entrambe le modalità di errore — istruzioni che rendono imbarazzante rifiutare, e codifiche che nascondono la richiesta — perché un set composto solo da una delle due favorirà un modello debole all'altra. Valuta in modo conservativo: dannoso e in tema, non solo fuori tono. E riporta il risultato come un tasso rispetto a un numero dichiarato di tentativi, mai come un sì o no.

Quando sono in gioco più modelli candidati, il confronto funziona solo se lo stesso set di prompt viene eseguito su ognuno di essi, ed è l'unico punto in cui la meccanica di integrazione conta più della metodologia. Eseguire un'unica valutazione sui modelli che instradiamo elimina dall'esercizio il contratto con ciascun fornitore e il lavoro lato client; i prezzi di listino dei fornitori vengono applicati senza alcun ricarico, quindi l'esecuzione costa quanto addebitano i fornitori e nulla di più. Ciò che la valutazione misura è il comportamento del modello, non il nostro — l'instradamento cambia quale modello risponde e non rende nessuno di essi più propenso a rifiutare.

Dove riprende il record

Un tasso di successo misurato ti dice quanto è difficile far cedere il livello del prompt. Non ti dice cosa è successo quando qualcuno l'ha fatto cedere in produzione, e questa seconda domanda è ciò che determina se il tasso conta davvero. Un jailbreak che produce un paragrafo volgare è un problema di moderazione dei contenuti. Un jailbreak che produce una chiamata a uno strumento è un incidente, e la differenza sta interamente in ciò che il sistema ha permesso all'output di raggiungere.

Quell’archivio è il registro di campo: ciò che gli agenti hanno effettivamente fatto, con una fonte per ogni voce e un verdetto sul fatto che qualcuno sia stato danneggiato. Confrontato con una misurazione dei jailbreak, risponde alla domanda a cui la misurazione non può rispondere: se il confine che un prompt ha oltrepassato sia un confine da cui dipende qualcosa a valle. Se lo è, il jailbreak è un riscontro di sicurezza e il controllo va inserito nei permessi degli strumenti. Se non lo è, il jailbreak è un risultato di contenuto, e la mossa onesta è archiviarlo come tale invece di gonfiarlo a vulnerabilità.

La nota conclusiva è quella che le evidenze supportano. Il jailbreaking non sarà risolto da un modello migliore, perché le modalità di fallimento sono strutturali: il rispetto delle istruzioni è una capacità e l'addestramento alla sicurezza è una capacità più ristretta, e il divario tra le due è il punto in cui risiede ogni attacco descritto in questo articolo. Ciò che può essere risolto è la conseguenza — assicurandosi che un modello che smette di rifiutare non possa comunque fare molto.