Low-Resource Safety Failures Are Action Failures, Not Representation Failures

Questo articolo dimostra che i fallimenti della sicurezza in contesti a basse risorse derivano da un disallineamento nella calibrazione delle decisioni piuttosto che da una mancanza di rappresentazioni di dannosità, e propone un metodo per risolvere questo problema ricalibrando gli esistenti gate di sicurezza ad alte risorse utilizzando solo pochi esempi nella lingua target.

L'essenziale

Il Grande Problema: La "Barriera Linguistica" nella Sicurezza dell'IA

Immaginate di avere un guardiano della sicurezza molto intelligente e ben addestrato (il modello IA). Questo guardiano è stato istruito in inglese (una lingua ad alta risorsa) per riconoscere richieste pericolose e dire "No". Se qualcuno chiede "Come costruisco una bomba?" in inglese, il guardiano rifiuta immediatamente.

Tuttavia, se fate la stessa identica domanda in swahili o birmano (lingue a basse risorse), il guardiano improvvisamente dimentica il suo addestramento. Potrebbe invece rispondere alla domanda invece di rifiutarla.

Per molto tempo, i ricercatori hanno pensato che questo accadesse perché l'IA semplicemente non capiva le parole pericolose in quelle altre lingue. Pensavano che il "segnale di pericolo" mancasse dal cervello dell'IA quando cambiava lingua.

La Scoperta: Il Guardiano Capisce, Ma Non Agisce

Gli autori di questo documento hanno deciso di guardare dentro il "cervello" dell'IA (la sua matematica interna) per vedere cosa stesse accadendo realmente. Hanno scoperto qualcosa di sorprendente:

L'IA sa che la richiesta è pericolosa, anche in swahili o birmano.

Pensatelo in questo modo: il guardiano sente la richiesta pericolosa in swahili. Il suo cervello si illumina con un allarme "PERICOLO", proprio come accade in inglese. L'allarme è lì, ed è abbastanza forte da essere udito.

Il fallimento non è che l'allarme sia rotto; il fallimento è che il guardiano ignora l'allarme.

In inglese, l'allarme è così forte che il guardiano preme automaticamente il tasto "Rifiuta". Nelle lingue a basse risorse, l'allarme è ancora presente, ma è leggermente più silenzioso. Poiché è più silenzioso, il guardiano non si rende conto che è abbastanza forte da attivare il tasto "Rifiuta", quindi continua a parlare.

Il documento chiama questo un fallimento di calibrazione, non un fallimento di rappresentazione.

• Fallimento di Rappresentazione: Il guardiano non sa cosa significhi "bomba" in swahili. (Il documento dice che questo è falso).
• Fallimento di Calibrazione: Il guardiano sa cosa significa "bomba", ma la manopola del volume per il tasto "Rifiuta" è impostata troppo alta per quella specifica lingua. (Il documento dice che questo è vero).

La Soluzione: Un Semplice Regolamento della "Manopola del Volume"

Poiché l'IA possiede già la conoscenza del "pericolo", gli autori non avevano bisogno di riaddestrare l'intera IA (il che è costoso e lento). Inveve, hanno costruito un piccolo e intelligente guardiano (un "gate latente").

Ecco come funziona la loro correzione:

1. Usa l'allarme esistente: Prendono la "direzione del pericolo" che l'IA ha già appreso dall'inglese.
2. Ascolta alcuni esempi: Mostrano al guardiano solo da 1 a 4 esempi di richieste pericolose e sicure nella lingua target (come lo swahili).
3. Ripristina la soglia: Il guardiano dice: "Ok, in swahili, l'allarme del pericolo è un po' più silenzioso rispetto all'inglese. Devo abbassare il volume richiesto per premere il tasto 'Rifiuta'".
4. Dirige la decisione:
   • Se il guardiano pensa che la richiesta sia pericolosa, alza il volume del "Rifiuta" per assicurarsi che l'IA dica di no.
   • Se il guardiano pensa che la richiesta sia sicura, abbassa il volume del "Rifiuta" in modo che l'IA non rifiuti accidentalmente domande innocue (come "Come si cuoce una torta?").

I Risultati: Un Guardiano Più Intelligente e Sicuro

Utilizzando questo semplice regolamento della "manopola del volume" con pochissimi esempi, gli autori hanno ottenuto grandi risultati:

• La sicurezza è migliorata: L'IA ha iniziato a rifiutare le richieste pericolose nelle lingue a basse risorse molto più spesso (passando dal rifiutare circa il 44% delle volte a oltre il 67% in alcuni casi).
• L'utilità è preservata: Fondamentalmente, l'IA non ha iniziato a rifiutare richieste sicure. Non è diventata eccessivamente paranoica.
• Efficienza: Non hanno avuto bisogno di riaddestrare il massiccio modello IA. Hanno solo regolato un piccolo interruttore usando un manipolo di esempi.

Analogia Riassuntiva

Immaginate un rilevatore di fumo installato in una casa.

• La Vecchia Visione: Quando il rilevatore non suonava in cucina (lingua a basse risorse), le persone pensavano che il rilevatore fosse rotto o che non sapesse cos'era il fumo.
• La Nuova Visione: Il rilevatore aveva sentito l'odore del fumo. Solo che non era abbastanza sensibile da far scattare l'allarme in quella specifica stanza.
• La Correzione: Invece di comprare una casa nuova e nuovi rilevatori, gli autori hanno solo regolato la manopola della sensibilità del rilevatore esistente. Ora, sente il fumo in cucina e urla "Fuoco!" con la stessa intensità con cui lo fa nel soggiorno.

Il Punto Fondamentale: I fallimenti della sicurezza nelle lingue a basse risorse non sono dovuti al fatto che l'IA sia "stupida" in quelle lingue; è perché il suo "interruttore di sicurezza" è impostato troppo alto. Una piccola regolazione con pochi esempi può risolvere il problema senza dover imparare tutto da capo.

Sommario tecnico

Riepilogo Tecnico: I fallimenti della sicurezza nelle lingue a basse risorse sono fallimenti di azione, non di rappresentazione

Problematica

I Large Language Models (LLM) addestrati per l'allineamento della sicurezza nelle lingue ad alte risorse (HRL) spesso non riescono a rifiutare prompt dannosi quando questi vengono tradotti in lingue a basse risorse (LRL). Mentre i modelli rifiutano con successo istruzioni dannose in inglese, spesso ottemperano a richieste identiche in lingue come lo swahili o il birmano. Il lavoro precedente ha documentato questo divario comportamentale, ma non ha chiarito il suo meccanismo interno. Esistono due ipotesi concorrenti:

1. Fallimento della Rappresentazione: Il modello manca di una rappresentazione interna utilizzabile di "dannosità" nelle LRL a causa di una comprensione semantica più debole.
2. Fallimento dell'Azione (Routing): Il modello possiede la rappresentazione della dannosità, ma non riesce a tradurre quel segnale in una decisione di rifiuto (ovvero, la soglia decisionale è disallineata).

Questo articolo diagnostica la causa principale del divario di sicurezza multilingue e propone un intervento leggero per ripararlo.

Metodologia

Configurazione Sperimentale

Gli autori hanno valutato tre modelli sottoposti a fine-tuning per istruzioni (Qwen2.5-7B, Gemma-2-9B e Llama-3.1-8B) attraverso 23 lingue categorizzate in livelli di risorse (Alta, Media, Bassa) basandosi su Common Crawl share. Hanno utilizzato una versione estesa del dataset PolyRefuse, contenente prompt dannosi e innocui tradotti in queste lingue.

Fase Diagnostica

Per distinguere tra fallimenti di rappresentazione e di azione, gli autori hanno impiegato tecniche di interpretabilità meccanicistica sullo stream residuo:

1. Estrazione della Direzione di Dannosità: Hanno calcolato una "direzione di dannosità" unidimensionale ($v_{HRL}$) calcolando la differenza tra le attivazioni medie tra prompt dannosi e innocui nelle HRL.
2. Mediazione Causale (Ablazione): Hanno testato se la rimozione di questa direzione derivata dalle HRL dalle attivazioni delle LRL sopprimesse il rifiuto. I risultati hanno mostrato che l'ablazione di $v_{HRL}$ nelle LRL riduceva significativamente il rifiuto di contenuti dannosi, provando che la direzione è causalmente attiva.
3. Separabilità Lineare: Hanno proiettato le attivazioni delle LRL su $v_{HRL}$ e misurato l'Area Sotto la Curva (AUC) per separare i prompt dannosi da quelli innocui. L'AUC rimaneva elevata (>0,85) anche nelle LRL in cui i tassi di rifiuto erano bassi, indicando che la rappresentazione è presente e decodificabile.
4. Analisi dell'Entità del Segnale: Hanno osservato che, sebbene il segnale esista, i punteggi di proiezione per i prompt dannosi nelle LRL sono traslati verso il basso rispetto alle HRL. La soglia di rifiuto implicita del modello non viene innescata perché l'entità del segnale è insufficiente, non perché il segnale manchi.

Intervento: Few-Shot Latent Gate

Basandosi sulla diagnosi che il fallimento è di calibrazione piuttosto che di rappresentazione, gli autori hanno proposto un metodo di steering senza addestramento:

1. Latent Gate: Un readout logistico a basso rango viene addestrato sui dati HRL per mappare la proiezione di dannosità su una decisione di sicurezza binaria.
2. Ricalibrazione della Soglia: Invece di riaddestrare il modello o apprendere una nuova direzione specifica per la LRL, la soglia decisionale ($\tau$) viene resettata utilizzando un numero minimo di esempi della lingua target (anche solo 1–4 per classe).
3. Steering Condizionale: Il sistema instrada i prompt in base all'output del gate:
   • Se classificato come dannoso: la direzione di dannosità HRL viene aggiunta all'attivazione (steering verso il rifiuto).
   • Se classificato come innocuo: la direzione di dannosità HRL viene ablata (prevenendo falsi rifiuti).

Risultati Chiave

Risultati Diagnostici

• La Rappresentazione è Intatta: La dannosità rimane linearmente separabile nelle attivazioni delle LRL. Il fallimento non è una mancanza di rappresentazione.
• Spostamento del Segnale: I prompt LRL producono proiezioni inferiori sulla direzione di dannosità. Il modello non riesce a rifiutare perché l'entità del segnale scende al di sotto della soglia implicita stabilita durante l'addestramento HRL.

Miglioramenti delle Prestazioni

Il proposto few-shot latent gate ha superato significativamente le basi di steering adattivo esistenti (CAST e AdaSteer):

• Rifiuto Selettivo ($\Delta$): La metrica $\Delta$ (tasso di rifiuto dei contenuti dannosi meno il tasso di rifiuto dei contenuti innocui) è aumentata da 33,6 (il baseline adattato più forte) a 54,5 con il metodo proposto.
• Rifiuto di Contenuti Dannosi: Il metodo ha aumentato i tassi di rifiuto dei contenuti dannosi nelle LRL (ad esempio, da 43% a ~67% in media) mantenendo basso il rifiuto dei contenuti innocui (12,7%).
• Confronto con i Baseline: I metodi concorrenti come CAST e AdaSteer o non sono riusciti a migliorare significativamente il rifiuto dei contenuti dannosi o hanno causato un eccessivo "over-refusal" di prompt benigni (ad esempio, AdaSteer ha raggiunto il 52,8% di rifiuto dei contenuti innocui).
• Generalizzazione: Il gate si è generalizzato bene ai benchmark di sicurezza out-of-distribution (MultiJail, IndoSafety) e si è trasferito tra diverse LRL quando calibrato su una singola LRL di origine.
• Preservazione dell'Utilità: L'intervento ha preservato l'utilità sul benchmark Global-MMLU, con cambiamenti trascurabili nell'accuratezza.

Significato e Rivendicazioni

L'articolo sostiene che i fallimenti della sicurezza nelle lingue a basse risorse sono principalmente fallimenti di azione (problemi di calibrazione) piuttosto che fallimenti di rappresentazione.

• Insight Meccanicistico: Il lavoro dimostra che le rappresentazioni di sicurezza apprese nelle lingue ad alte risorse sono trasferibili e presenti nelle lingue a basse risorse, ma la loro magnitudo di attivazione è insufficiente per innescare il rifiuto senza ricalibrazione.
• Efficienza: La soluzione proposta non richiede aggiornamenti dei pesi del modello o un addestramento esteso. Raggiunge prestazioni di sicurezza allo stato dell'arte utilizzando solo una manciata di esempi della lingua target per resettare una soglia decisionale.
• Implicazione Pratica: Gli autori suggeriscono un flusso di lavoro "diagnosi-poi-ripara": prima di tentare di apprendere nuove rappresentazioni di sicurezza per una lingua a basse risorse, si dovrebbe prima testare se la rappresentazione HRL esistente è decodificabile. Se lo è, una semplice ricalibrazione della soglia decisionale è sufficiente per riparare l'allineamento della sicurezza.

Gli autori rilevano limitazioni, tra cui l'ambito dei modelli testati (modelli densi 7B–9B), la dipendenza da Common Crawl come proxy di risorse e il fatto che l'intervento sia uno strumento diagnostico che richiede l'accesso alle attivazioni piuttosto che un salvaguardia per modelli chiusi. Evidenziano inoltre che questo metodo non sostituisce la necessità di un addestramento alla sicurezza multilingue né garantisce la robustezza contro tutti i tipi di prompt avversari.