Safe responses matter: Output-aware safety guardrail mitigate over-refusal in MLLMs

Riepilogo Tecnico: OutGuard – Guardrail di Sicurezza Sensibile all'Output per gli MLLM

1. Definizione del Problema: Il Compromesso tra Sicurezza e Utilità

I meccanismi di sicurezza esistenti per i Modelli Linguistici Multimodali (MLLM) affrontano un critico compromesso tra sicurezza e utilità. Sebbene l'affinamento (fine-tuning) del modello offra una sicurezza robusta, spesso compromette l'utilità generale. Al contrario, i guardrail di sicurezza lato input forniscono un'alternativa leggera e non intrusiva, ma soffrono di un grave over-refusal (eccesso di rifiuto).

I guardrail attuali operano sotto un paradigma consapevole dell'input (input-aware), prendendo decisioni di sicurezza basandosi esclusivamente sull'analisi delle coppie immagine-testo in ingresso. Questo approccio non tiene conto delle capacità di sicurezza intrinseche del modello. Come dimostrato nel paper, gli MLLM possiedono spesso meccanismi di allineamento interno che possono trasformare input dannosi in output sicuri (ad esempio, risposte di tipo rifiuto, ammonimenti o avvertenze). Tuttavia, i guardrail consapevole dell'input bloccano indiscriminatamente queste interazioni una volta che l'input viene segnalato come rischioso, indipendentemente dal fatto che il modello avrebbe generato una risposta innocua. Ciò porta al rifiuto di query benigne che appaiono semplicemente rischiose (ad esempio, "Come uccidere un processo Python?" o "Dove posso scattare una bella foto?"), degradando significativamente l'esperienza dell'utente e limitandone l'usabilità pratica.

2. Metodologia: Il Framework OutGuard

Per affrontare questo problema, gli autori propongono OutGuard, un cambio di paradigma dall'approccio consapevole dell'input a quello consapevole dell'output (output-aware). OutGuard opera all'interno dello spazio degli stati latenti (hidden state) del modello per prevedere la sicurezza della generazione imminente prima che sia completamente prodotta, piuttosto che giudicare solo il rischio dell'input.

Componenti Core:

• Utilizzo degli Stati Latenti (Hidden State): OutGuard estrae le rappresentazioni degli stati latenti ($H_l$) dal backbone LLM durante la fase di inferenza (Stadio S4 nel flusso di dati). Questi stati collegano la dinamica interna del modello all'output finale.
• Classificatore Multi-Instance Contrastive Learning (MICL):
  • Formulazione del Problema: Il compito di rilevamento è inquadrato come un problema di Multiple Instance Learning (MIL). Una sequenza di stati latenti per un output generato è trattata come un "sacchetto" (bag), dove le singole rappresentazioni dei token sono "istanze". L'etichetta a livello di sacchetto (Sicuro/Non Sicuro) è nota, ma la pericolosità specifica a livello di token è latente.
  • Architettura: Il classificatore MICL impiega un meccanismo di attenzione a porta (gated attention mechanism) per aggregare le rappresentazioni dei token in una rappresentazione a livello di sacchetto ($z_l$). Questo meccanismo impara a concentrarsi sulle istanze ad alta attenzione (probabilmente token dannosi) pur sopprimendo il rumore.
  • Obiettivo di Addestramento: Il classificatore è addestrato utilizzando una funzione di perdita composita:
    1. Perdita di Cross-Entropia Binaria ($L_{cls}$): Per la classificazione a livello di sacchetto.
    2. Regolarizzazione dell'Entropia ($L_{ent}$): Per incoraggiare la sparsità nei pesi di attenzione, costringendo il modello a concentrarsi su specifici token salienti.
    3. Perdita Contrastiva Intra-bag ($L_{con}$): Una perdita di tipo InfoNCE che massimizza la similarità tra le istanze ad alta attenzione (positive) e minimizza la similarità con le istanze a bassa attenzione (negative) all'interno dello stesso sacchetto.
• Selezione degli Strati e Votazione:
  • Una metrica Safety-Score viene utilizzata per valutare le prestazioni dei classificatori MICL addestrati su diversi strati (layers).
  • Vengono selezionati solo i classificatori dagli strati con un Safety-Score > 0,9.
  • Durante l'inferenza, i classificatori selezionati votano sulla sicurezza degli stati latenti. Un voto di maggioranza determina la decisione finale (Sicuro vs Non Sicuro).

Flusso Operativo:
OutGuard opera come un modulo indipendente accanto all'MLLM. Esegue il rilevamento della sicurezza in un unico passaggio durante l'inferenza, analizzando gli stati latenti mentre vengono generati. Se il sistema prevede un output non sicuro, interviene; altrimenti, la generazione procede. Ciò evita la necessità di query aggiuntive o di un carico di latenza significativo.

3. Contributi Chiave

1. Cambio di Paradigma: Il paper identifica la causa principale dell'over-refusal nella dipendenza dai paradigmi consapevole dell'input e propone un passaggio verso la valutazione della sicurezza consapevole dell'output.
2. Framework OutGuard: Un framework innovativo che utilizza le rappresentazioni degli stati latenti e un classificatore Multi-Instance Contrastive Learning (MICL) per valutare direttamente la sicurezza dell'output, distinguendo tra input che portano a output dannosi e quelli che il modello neutralizza internamente.
3. Validazione Empirica: Esperimenti estesi dimostrano che OutGuard riduce significativamente i tassi di over-refusal mantenendo al contempo forti prestazioni di rilevamento contro contenuti dannosi e attacchi di jailbreak.

4. Risultati Sperimentali

Gli autori hanno valutato OutGuard su LLaVA 1.6 e Qwen 3.5 utilizzando dataset tra cui GQA, AdvBench, SafeBench, MM-Vet, MM-SafetyBench e XSTest. I baseline includevano HiddenDetector, QGuard, LoD e ProGuard.

• Equilibrio tra Sicurezza e Utilità: OutGuard ha ottenuto prestazioni superiori in tutte le metriche. Sul set di test, ha mantenuto un basso tasso di Risposta Non Sicura a Prompt Non Sicuri (URUP < 0,1) riducendo drasticamente il tasso di Risposta di Astensione a Prompt Sicuri (ARSP < 0,1). Ad esempio, su LLaVA, OutGuard ha raggiunto un F1-Score di 0,9335 e un ARSP di 0,0749, superando il secondo miglior metodo (LoD-PP) che aveva un ARSP di 0,1124.
• Mitigazione dell'Over-Refusal: Sul dataset XSTest (query benigne che appaiono dannose), OutGuard ha ridotto significativamente i tassi di over-refusal rispetto ai baseline (ad esempio, 0,5840 vs 0,7400 per LLaVA).
• Robustezza: OutGuard ha dimostrato una forte robustezza contro gli attacchi di jailbreak (Visual-Adversarial-Examples, HADES, JOOD), raggiungendo metriche di classificazione quasi perfette (AUPRC/AUROC > 0,97) mantenendo basso l'over-refusal.
• Efficienza: Il metodo introduce una latenza minima. Il tempo decisionale medio per campione è stato di 0,208 secondi, paragonabile o più veloce di molti baseline (ad esempio, QGuard a 3,154s) e significativamente più veloce dei metodi post-output.
• Studi di Ablazione: La rimozione di componenti chiave (modulo di gating, apprendimento contrastivo o regolarizzazione della sparsità) ha portato a un severo degrado della capacità di rilevamento, confermando la necessità dell'architettura MICL.

5. Significato e Rivendicazioni

Il paper sostiene che OutGuard fornisca una soluzione pratica al compromesso tra sicurezza e utilità negli MLLM. Spostando l'attenzione dal rischio dell'input al danno effettivo dell'output, il metodo preserva le capacità di sicurezza integrate e l'utilità generale del modello. Gli autori sottolineano che il loro approccio consente un'intervallo preciso solo quando la risposta effettiva del modello sarebbe dannosa, evitando così il blocco non necessario di interazioni benigne.

Il lavoro evidenzia l'importanza dei meccanismi di sicurezza consapevoli dell'output e dimostra che classificatori leggeri addestrati sugli stati latenti possono mitigare efficacementamente l'over-refusal senza compromettere il rilevamento di minacce reali o richiedere il riaddestramento del modello. Il codice è reso disponibile per facilitare ulteriori ricerche in questa direzione.