🤖 machine learning

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

Cet article propose un garde-fou sensible à la sortie qui prédit les générations potentiellement non sécurisées au sein de l'espace d'état caché d'un modèle afin d'atténuer le problème de sur-refus courant dans les filtres côté entrée, préservant ainsi à la fois la sécurité et l'utilité dans les modèles de langage multimodaux à grande échelle.

Auteurs originaux : Jiayi Li, Kun Zhan

Publié 2026-07-14

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jiayi Li, Kun Zhan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un ami robot super intelligent qui peut voir des images et parler d'elles. Ce robot est excellent pour répondre aux questions, mais parfois, les gens essaient de le piéger pour lui faire dire des choses méchantes, donner des instructions dangereuses ou propager des mensonges. Pour empêcher cela, nous mettons généralement un « garde de sécurité » devant le robot.

Le Problème : Le Videur Trop Protecteur
Actuellement, la plupart des gardes de sécurité fonctionnent comme un videur strict dans un club qui regarde seulement votre carte d'identité (la question que vous posez) avant de vous laisser entrer. Si votre carte d'identité contient un mot effrayant, le videur ferme la porte immédiatement, même si vous alliez poser une question tout à fait inoffensive.

Par exemple, si vous demandez : « Comment tuer un processus Python ? » (ce qui concerne juste du code informatique), le videur voit le mot « tuer » et vous bloque. Si vous demandez : « Où puis-je prendre une bonne photo ? » (ce qui concerne la photographie), le videole voit « prendre » (ou « tirer » en anglais, l'analogie du mot "shoot") et dit : « Pas question ! ». Le robot n'a même pas la chance d'expliquer que vous êtes en train d'être sûr et utile. Ce document appelle cela l'over-refusal (le refus excessif). C'est comme si le garde avait tellement peur des ennuis qu'il expulsait accidentellement tous les bons clients.

L'Ancienne Méthode vs La Nouvelle Méthode
Les chercheurs ont découvert que ces anciens gardes prennent leurs décisions en se basant entièrement sur l'entrée (ce que vous demandez). Ils ne attendent pas de voir ce que le robot va réellement dire en retour.

Le document s'oppose à cette approche de type « entrée uniquement ». Il suggère que le robot est en réalité plutôt doué pour être sûr de lui. Si vous posez une question délicate, le robot sait souvent de lui-même donner un avertissement ou dire « Je ne peux pas faire cela ». Mais le vieux garde arrête le robot avant même qu'il puisse montrer son bon côté !

La Solution : OutGuard (Le Garde à la « Boule de Cristal »)
Les auteurs proposent un nouveau système appelé OutGuard. Au lieu de simplement regarder votre carte d'identité, OutGuard agit comme une boule de cristal qui jette un coup d'œil dans le cerveau du robot pendant qu'il réfléchit, mais avant qu'il ne parle.

Voici comment cela fonctionne :

Le Coup d'Œil : À mesure que le robot commence à former une réponse, OutGuard observe les « pensées cachées » (appelées états cachés) qui tourbillonnent dans les couches du cerveau du robot.
La Prédiction : Il essaie de deviner : « Le robot est-il sur le point de dire quelque chose de vraiment dangereux, ou est-il juste en train de réfléchir à un sujet dangereux mais prévoit de dire quelque chose de sûr ? »
La Décision :
- Si le robot est sur le point de dire quelque chose de réellement nuisible (comme comment fabriquer une bombe), OutGuard intervient et l'arrête.
- Si le robot est sur le point de dire quelque chose de sûr (comme expliquer que « tuer un processus » est juste du codage), OutGuard le laisse passer !

Le Tour de Magie : Apprendre à partir de « Sacs » de Pensées
Pour apprendre à OutGuard à faire cela, les chercheurs ont utilisé une méthode d'apprentissage ingénieuse appelée Multi-Instance Contrastive Learning (MICL).

Imaginez la réponse du robot comme un sac de billes. Certaines billes sont dangereuses (les mauvais mots), et la plupart sont sûres. Les anciens gardes regardent simplement le sac et disent : « Il y a une bille dangereuse, jetez le sac ! ».
OutGuard regarde à l'intérieur du sac. Il utilise un mécanisme d'attention spécial pour trouver les billes dangereuses spécifiques. Il apprend à ignorer les billes sûres et à se concentrer uniquement sur celles qui rendent réellement toute la réponse nuisible. C'est comme un détective qui sait que trouver une seule pomme pourrie ne signifie pas que tout le panier est gâté, à moins que cette pomme pourrie ne soit celle qui gâte tout le jus.

Ce que disent les Chiffres
Les chercheurs ont testé cela sur deux modèles de robots populaires : LLaVA 1.6 et Qwen 3.5. Ils ont comparé OutGuard à d'autres gardes de sécurité de haut niveau comme HiddenDetector, QGuard et LoD.

Sécurité : OutGuard a capturé presque toutes les requêtes réellement mauvaises. Sur l'ensemble de test standard, il a obtenu un AUPRC de 0,9725 pour LLaVA et 0,9937 pour Qwen (où 1,0 est parfait). Cela signifie qu'il est aussi bon pour attraper les méchants que les autres.
La Correction de l'« Over-Refusal » : C'est ici qu'OutGuard excelle. Les anciens gardes bloquaient trop souvent les questions sûres.
- QGuard a bloqué 100 % des questions sûres (ARSP = 1,0000). Il avait trop peur de laisser entrer qui que ce soit.
- OutGuard n'a bloqué que 5,5 % des questions sûres pour LLaVA et 1,15 % pour Qwen.
- Sur les questions délicates qui semblent dangereuses mais qui sont en fait sûres (comme « Comment tuer le temps à l'aéroport ? »), OutGuard a laissé passer 41,6 % de questions sûres de plus par rapport à la meilleure autre méthode.

Vitesse et Coût
Vous pourriez craindre que de jeter un coup d'œil dans le cerveau du robot ne ralentisse les choses. Le document montre qu'OutGuard est très rapide. Il prend environ 0,208 seconde par question en moyenne, ce qui est beaucoup plus rapide que certaines autres méthodes qui prennent plus de 3 secondes. Il ne nécessite pas non plus beaucoup de mémoire supplémentaire, ajoutant seulement environ 1,37 Go au système.

L'Essentiel
Le papier suggère qu'en passant d'une approche « sensible à l'entrée » (vérifier la question) à une approche « sensible à la sortie » (vérifier la réponse avant qu'elle ne soit finie), nous pouvons garder nos robots sûrs sans être agaçants. OutGuard ne cherche pas à empêcher le robot d'être utile ; il cherche simplement à l'empêcher d'être dangereux. C'est une façon plus intelligente et plus précise de rendre Internet sûr tout en nous permettant de poser nos questions.

Résumé Technique : OutGuard – Garde-fou de Sécurité Sensible à la Sortie pour les MLLM

1. Énoncé du Problème : Le Compromis entre Sécurité et Utilité

Les mécanismes de sécurité existants pour les modèles de langage de grande taille multimodaux (MLLM) sont confrontés à un compromis critique entre sécurité et utilité. Si l'ajustement fin (fine-tuning) des modèles offre une sécurité robuste, il compromet souvent l'utilité générale. À l'inverse, les garde-fous de sécurité côté entrée constituent une alternative légère et non intrusive, mais souffrent d'un sur-refus (over-refusal) sévère.

Les garde-fous actuels opèrent selon un paradigme sensible à l'entrée (input-aware), prenant des décisions de sécurité basées uniquement sur l'analyse des paires image-texte d'entrée. Cette approche ne tient pas compte des capacités de sécurité intrinsèques du modèle. Comme le démontre l'article, les MLLM possèdent souvent des mécanismes d'alignement internes capables de transformer des entrées malveillantes en sorties sûres (par exemple, des réponses de type refus, des admonestations ou des avertissements). Cependant, les garde-fous sensibles à l'entrée bloquent indistinctement ces interactions dès que l'entrée est signalée comme risquée, peu importe si le modèle aurait généré une réponse inoffensive. Cela conduit au rejet de requêtes bénignes qui paraissent simplement risquées (par exemple, « Comment tuer un processus Python ? » ou « Où puis-je prendre une bonne photo ? »), dégradant considérablement l'expérience utilisateur et limitant l'utilisabilité pratique.

2. Méthodologie : Le Cadre OutGuard

Pour remédier à cela, les auteurs proposent OutGuard, un changement de paradigme passant d'une sécurité sensible à l'entrée vers une sécurité sensible à la sortie (output-aware). OutGuard opère au sein de l'espace d'état caché du modèle pour prédire la sécurité de la génération à venir avant qu'elle ne soit pleinement produite, plutôt que de juger le risque de l'entrée seule.

Composants Clés :

Utilisation des États Cachés : OutGuard extrait les représentations d'états cachés ( $H_l$ ) du LLM de base pendant l'étape d'inférence (Étape S4 dans le flux de données). Ces états lient la dynamique interne du modèle à la sortie finale.
Classificateur d'Apprentissage Contrastif Multi-Instances (MICL) :
- Formulation du Problème : La tâche de détection est formulée comme un problème d'apprentissage multi-instances (MIL). Une séquence d'états cachés pour une sortie générée est traitée comme un « sac » (bag), où les représentations de jetons individuels sont des « instances ». L'étiquette au niveau du sac (Sûr/Incertain) est connue, mais la dangerosité spécifique au niveau du jeton est latente.
- Architecture : Le classificateur MICL utilise un mécanisme d'attention à porte (gated attention) pour agréger les représentations de jetons en une représentation de niveau sac ( $z_l$ ). Ce mécanisme apprend à se concentrer sur les instances à haute attention (jetons probablement dangereux) tout en supprimant le bruit.
- Objectif d'Entraînement : Le classificateur est entraîné à l'aide d'une fonction de perte composite :
  1. Perte d'Entropie Croisée Binaire ( $L_{cls}$ ) : Pour la classification au niveau du sac.
  2. Régularisation d'Entropie ( $L_{ent}$ ) : Pour encourager la parcimonie des poids d'attention, forçant le modèle à se concentrer sur des jetons saillants spécifiques.
  3. Perte Contrastive Intra-sac ( $L_{con}$ ) : Une perte de type InfoNCE qui maximise la similitude parmi les instances à haute attention (positives) et minimise la similitude avec les instances à faible attention (négatives) au sein du même sac.
Sélection de Couches et Vote :
- Une métrique Safety-Score est utilisée pour évaluer les performances des classificateurs MICL entraînés sur différentes couches.
- Seuls les classificateurs des couches ayant un Safety-Score > 0,9 sont sélectionnés.
- Pendant l'inférence, les classificateurs sélectionnés votent sur la sécurité des états cachés. Un vote majoritaire détermine la décision finale (Sûr vs Incertain).

Flux de Travail Opérationnel :
OutGuard fonctionne comme un module indépendant aux côtés du MLLM. Il effectue la détection de sécurité en une seule passe lors de l'inférence, en analysant les états cachés au fur et à mesure qu'ils sont générés. Si le système prédit une sortie dangereuse, il intervient ; sinon, la génération se poursuit. Cela évite le besoin de requêtes supplémentaires ou de latence significative.

3. Contributions Clés

Changement de Paradigme : L'article identifie la cause profonde du sur-refus comme étant la dépendance aux paradigmes sensibles à l'entrée et propose un passage vers une évaluation de sécurité sensible à la sortie.
Cadre OutGuard : Un nouveau cadre utilisant les représentations d'états cachés et un classificateur d'Apprentissage Contrastif Multi-Instances (MICL) pour évaluer directement la sécurité de la sortie, distinguant les entrées menant à des sorties dangereuses de celles que le modèle neutralise en interne.
Validation Empirique : Des expériences approfondies démontrent qu'OutGuard réduit considérablement les taux de sur-refus tout en maintenant de fortes performances de détection contre le contenu malveillant et les attaques par jailbreak.

4. Résultats Expérimentaux

Les auteurs ont évalué OutGuard sur LLaVA 1.6 et Qwen 3.5 en utilisant des jeux de données incluant GQA, AdvBench, SafeBench, MM-Vet, MM-SafetyBench et XSTest. Les modèles de référence comprenaient HiddenDetector, QGuard, LoD et ProGuard.

Équilibre Sécurité vs Utilité : OutGuard a obtenu des performances supérieures sur tous les indicateurs. Sur l'ensemble de test, il a maintenu un faible taux de réponse non sûre aux prompts non sûrs (URUP < 0,1) tout en réduisant drastiquement le taux de réponse d'abstention aux prompts sûrs (ARSP < 0,1). Par exemple, sur LLaVA, OutGuard a atteint un F1-Score de 0,9335 et un ARSP de 0,0749, surpassant la méthode suivante la plus performante (LoD-PP) qui avait un ARSP de 0,1124.
Atténuation du Sur-Refus : Sur le jeu de données XSTest (requêtes bénignes qui paraissent dangereuses), OutGuard a réduit considérablement les taux de sur-refus par rapport aux modèles de référence (ex: 0,5840 contre 0,7400 pour LLaVA).
Robustesse : OutGuard a démontré une forte robustesse contre les attaques par jailbreak (Visual-Adversarial-Examples, HADES, JOOD), atteignant des métriques de classification quasi parfaites (AUPRC/AUROC > 0,97) tout en maintenant un faible taux de sur-refus.
Efficacité : La méthode introduit une latence minimale. Le temps de décision moyen par échantillon était de 0,208 seconde, comparable ou plus rapide que de nombreux modèles de référence (ex: QGuard à 3,154s) et nettement plus rapide que les méthodes post-sortie.
Études d'Ablation : Le retrait des composants clés (module de porte, apprentissage contrastif ou régularisation de parcimonie) a entraîné une dégradation sévère de la capacité de détection, confirmant la nécessité de l'architecture MICL.

5. Signification et Revendications

L'article affirme qu'OutGuard fournit une solution pratique au compromis sécurité-utilité dans les MLLM. En déplaçant l'attention du risque d'entrée vers la dangerosité réelle de la sortie, la méthode préserve les capacités de sécurité intégrées et l'utilité générale du modèle. Les auteurs soulignent que leur approche permet une intervention précise uniquement lorsque la réponse réelle du modèle serait dangereuse, évitant ainsi le blocage inutile des interactions bénignes.

Ce travail met en évidence l'importance des mécanismes de sécurité sensibles à la sortie et démontre que des classificateurs légers entraînés sur des états cachés peuvent atténuer efficacement le sur-refus sans compromettre la détection de menaces réelles ni nécessendre de réentraînement du modèle. Le code est mis à disposition pour faciliter la recherche future dans cette direction.