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

Cet article démontre que les défaillances de sécurité en situation de faibles ressources proviennent d'un désalignement dans le calibrage des décisions plutôt que d'un manque de représentations de la nocivité, et propose une méthode pour y remédier en recalibrant les barrières de sécurité existantes à haute ressource en utilisant seulement quelques exemples dans la langue cible.

L'essentiel

Le Grand Problème : La « Barrière de la Langue » dans la Sécurité de l'IA

Imaginez que vous avez un garde de sécurité très intelligent et bien entraîné (le modèle d'IA). Ce garde a été formé en anglais (une langue à hautes ressources) pour repérer les requêtes dangereuses et dire « Non ». Si quelqu'un demande : « Comment fabriquer une bombe ? » en anglais, le garde refuse immédiatement.

Cependant, si vous posez exactement la même question en swahili ou en birman (des langues à faibles ressources), le garde oublie soudainement son entraînement. Il pourrait répondre à la question au lieu de refuser.

Pendant longtemps, les chercheurs ont pensé que cela se produisait parce que l'IA ne comprenait tout simplement pas les mots dangereux dans ces autres langues. Ils pensaient que le « signal de danger » manquait dans le cerveau de l'IA lorsqu'elle changeait de langue.

La Découverte : Le Garde Comprend, Mais Ne Veut Pas Agir

Les auteurs de cet article ont décidé de regarder à l'intérieur du « cerveau » de l'IA (sa mathématique interne) pour voir ce qui se passait réellement. Ils ont découvert quelque chose de surprenant :

L'IA sait que la requête est dangereuse, même en swahili ou en birman.

Voyez cela comme ceci : le garde de sécurité entend la requête dangereuse en swahili. Son cerveau s'illumine avec une alarme « DANGER », tout comme il le fait en anglais. L'alarme est là, et elle est assez forte pour être entendue.

L'échec n'est pas que l'alarme est cassée ; l'échec est que le garde ignore l'alarme.

En anglais, l'alarme est si forte que le garde appuie automatiquement sur le bouton « Refuser ». En langues à faibles ressources, l'alarme est toujours là, mais elle est légèrement plus faible. Parce qu'elle est plus faible, le garde ne réalise pas qu'elle est assez forte pour déclencher le bouton « Refuser », alors il continue simplement de parler.

L'article appelle cela un échec de calibration, et non un échec de représentation.

• Échec de représentation : Le garde ne sait pas ce que signifie « bombe » en swahili. (L'article dit que c'est faux).
• Échec de calibration : Le garde sait ce que signifie « bombe », mais le bouton de volume pour le bouton « Refuser » est réglé trop haut pour cette langue spécifique. (L'article dit que c'est vrai).

La Solution : Un Simple Ajustement du « Bouton de Volume »

Puisque l'IA possède déjà la connaissance du « danger », les auteurs n'ont pas eu besoin de réentraîner toute l'IA (ce qui est coûteux et lent). Au lieu de cela, ils ont construit un petit gardien intelligent (un « portier latent » ou latent gate).

Voici comment leur correction fonctionne :

1. Utiliser l'alarme existante : Ils prennent la « direction du danger » que l'IA a déjà apprise de l'anglais.
2. Écouter quelques exemples : Ils montrent au gardien seulement 1 à 4 exemples de requêtes dangereuses et sûres dans la langue cible (comme le swahili).
3. Réinitialiser le seuil : Le gardien dit : « D'accord, en swahili, l'alarme de danger est un peu plus faible qu'en anglais. Je dois baisser le volume requis pour appuyer sur le bouton "Refuser". »
4. Orienter la décision :
   • Si le gardien pense que la requête est dangereuse, il augmente le volume du « Refuser » pour s'assurer que l'IA dise non.
   • Si le gardien pense que la requête est sûre, il baisse le volume du « Refuser » pour que l'IA ne refuse pas accidentellement des questions inoffensives (comme « Comment faire un gâteau ? »).

Les Résultats : Un Garde Plus Intelligent, Plus Sûr

En utilisant ce simple ajustement du « bouton de volume » avec très peu d'exemples, les auteurs ont obtenu d'excellents résultats :

• La sécurité s'est améliorée : L'IA a commencé à refuser les requêtes dangereuses dans les langues à faibles ressources beaucoup plus souvent (passant d'un refus d'environ 44 % à plus de 67 % dans certains cas).
• L'utilité est préservée : Crucialement, l'IA n'a pas commencé à refuser des requêtes sûres. Elle n'est pas devenue excessivement paranoïaque.
• Efficacité : Ils n'ont pas eu besoin de réentraîner le modèle d'IA massif. Ils ont juste ajusté un petit interrupteur en utilisant une poignée d'exemples.

Analogie de Synthèse

Imaginez un détecteur de fumée installé dans une maison.

• L'ancienne vision : Quand le détecteur ne sonnait pas dans la cuisine (langue à faibles ressources), les gens pensaient que le détecteur était cassé ou qu'il ne savait pas ce qu'était la fumée.
• La nouvelle vision : Le détecteur sentait la fumée. Il n'était juste pas assez sensible pour déclencher l'alarme dans cette pièce spécifique.
• La correction : Au lieu d'acheter une maison entière et de nouveaux détecteurs, les auteurs ont simplement ajusté le cadran de sensibilité du détecteur existant. Maintenant, il sent la fumée dans la cuisine et hurle « Feu ! » aussi fort qu'il le fait dans le salon.

L'essentiel à retenir : Les échecs de sécurité en langues à faibles ressources ne sont pas dus au fait que l'IA est « stupide » dans ces langues ; c'est parce que son « interrupteur de sécurité » est réglé trop haut. Un petit ajustement par apprentissage à partir de peu d'exemples (few-shot) peut corriger cela sans avoir besoin de tout réapprendre à partir de zéro.

Résumé technique

Résumé technique : Les échecs de sécurité en ressources faibles sont des échecs d'action, et non des échecs de représentation

Énoncé du problème

Les grands modèles de langage (LLM) entraînés pour l'alignement de la sécurité dans les langues à hautes ressources (HRL) échouent souvent à refuser des requêtes nuisibles lorsque ces requêtes sont traduites dans des langues à faibles ressources (LRL). Bien que les modèles parviennent à refuser des instructions nuisibles en anglais, ils acceptent fréquemment des demandes identiques dans des langues comme le swahili ou le birman. Des travaux antérieurs ont documenté cet écart de comportement mais n'ont pas clarifié son mécanisme interne. Deux hypothèses concurrentes existent :

1. Échec de représentation : Le modèle manque d'une représentation interne utilisable de la « nocivité » dans les LRL en raison d'une compréhension sémantique plus faible.
2. Échec d'action (routage) : Le modèle possède la représentation de la nocivité, mais échoue à traduire ce signal en une décision de refus (c'est-à-dire que le seuil de décision est mal aligné).

Cet article diagnostique la cause profonde de l'écart de sécurité multilingue et propose une intervention légère pour la réparer.

Méthodologie

Configuration expérimentale

Les auteurs ont évalué trois modèles ajustés aux instructions (Qwen2.5-7B, Gemma-2-9B et Llama-3.1-8B) à travers 23 langues catégorisées par niveaux de ressources (Haute, Moyenne, Basse) basés sur la part de Common Crawl. Ils ont utilisé une version étendue du jeu de données PolyRefuse, contenant des prompts nuisibles et inoffensifs traduits dans ces langues.

Phase de diagnostic

Pour distinguer les échecs de représentation des échecs d'action, les auteurs ont employé des techniques d'interprétabilité mécaniste sur le flux résiduel (residual stream) :

1. Extraction de la direction de la nocivité : Ils ont calculé une « direction de la nocivité » unidimensionnelle ($v_{HRL}$) en prenant la différence des moyennes des activations entre les prompts nuisibles et inoffensifs dans les HRL.
2. Médiation causale (ablation) : Ils ont testé si le retrait de cette direction dérivée des HRL des activations des LRL supprimait le refus. Les résultats ont montré que l'ablation de $v_{HRL}$ dans les LRL réduisait considérablement le refus des contenus nuisibles, prouvant que la direction est causalement active.
3. Séparabilité linéaire : Ils ont projeté les activations des LRL sur $v_{HRL}$ et mesuré l'aire sous la courbe (AUC) pour séparer les prompts nuisibles des inoffensifs. L'AUC restait élevée (>0,85) même dans les LRL où les taux de refus étaient faibles, indiquant que la représentation est présente et décodable.
4. Analyse de l'amplitude du signal : Ils ont observé que, bien que le signal existe, les scores de projection pour les prompts nuisibles des LRL sont décalés vers le bas par rapport aux HRL. Le seuil de refus implicite du modèle n'est pas déclenché car l'amplitude du signal est insuffisante, et non parce que le signal est absent.

Intervention : Porte latente à quelques exemples (Few-Shot Latent Gate)

Sur la base du diagnostic selon lequel l'échec est un problème de calibrage plutôt que de représentation, les auteurs ont proposé une méthode de pilotage sans réentraînement :

1. Porte latente : Une lecture logistique de faible rang est entraînée sur des données HRL pour mapper la projection de la nocivité vers une décision de sécurité binaire.
2. Recalibrage du seuil : Au lieu de réentraîner le modèle ou d'apprendre une nouvelle direction spécifique à la LRL, le seuil de décision ($\tau$) est réinitialisé en utilisant un nombre minimal d'exemples de la langue cible (aussi peu que 1 à 4 par classe).
3. Pilotage conditionnel : Le système route les prompts en fonction de la sortie de la porte :
   • Si classé comme nuisible : la direction de nocivité HRL est ajoutée à l'activation (pilotage vers le refus).
   • Si classé comme inoffensif : la direction de nocivité HRL est ablée (prévenant les faux refus).

Résultats clés

Conclusions du diagnostic

• La représentation est intacte : La nocivité reste linéairement séparable dans les activations des LRL. L'échec n'est pas un manque de représentation.
• Décalage du signal : Les prompts des LRL produisent des projections plus faibles sur la direction de la nocivité. Le modèle ne refuse pas car l'amplitude du signal tombe en dessous du seuil implicite établi lors de l'entraînement HRL.

Améliorations des performances

La porte latente à quelques exemples proposée a nettement surpassé les bases de pilotage adaptatif existantes (CAST et AdaSteer) :

• Refus sélectif ($\Delta$) : La métrique $\Delta$ (taux de refus des contenus nuisibles moins le taux de refus des contenus inoffensifs) est passée de 33,6 (le plus fort des baselines adaptés) à 54,5 avec la méthode proposée.
• Refus des contenus nuisibles : La méthode a augmenté les taux de refus des contenus nuisibles dans les LRL (passant par exemple d'environ 43 % à environ 67 % en moyenne) tout en maintenant un faible taux de refus des contenus inoffensifs (~12,7 %).
• Comparaison avec les baselines : Les méthodes concurrentes comme CAST et AdaSteer ont soit échoué à améliorer significativement le refus des contenus nuisibles, soit provoqué un « sur-refus » excessif de contenus bénins (AdaSteer a atteint 52,8 % de refus de contenus inoffensifs).
• Généralisation : La porte s'est bien généralisée aux benchmarks de sécurité hors distribution (MultiJail, IndoSafety) et s'est transférée à travers différentes LRL lorsqu'elle était calibrée sur une seule LRL source.
• Préservation de l'utilité : L'intervention a préservé l'utilité sur le benchmark Global-MMLU, avec des changements négligeables de précision.

Signification et affirmations

L'article affirme que les échecs de sécurité en langues à faibles ressources sont principalement des échecs d'action (problèmes de calibrage) plutôt que des échecs de représentation.

• Insight mécaniste : Le travail démontre que les représentations de sécurité apprises dans les langues à hautes ressources sont transférables et présentes dans les langues à faibles ressources, mais que leur amplitude d'activation est insuffisante pour déclencher le refus sans recalibrage.
• Efficacité : La solution proposée ne nécessite aucune mise à jour des poids du modèle ni réentraînement étendu. Elle atteint des performances de sécurité de pointe en utilisant seulement une poignée d'exemples de la langue cible pour réinitialiser un seuil de décision.
• Implication pratique : Les auteurs suggèrent un flux de travail « diagnostic puis correction » : avant de tenter d'apprendre de nouvelles représentations de sécurité pour une langue à faibles ressources, il convient d'abord de tester si la représentation HRL existante est décodable. Si elle l'est, un simple recalibrage du seuil de décision suffit à réparer l'alignement de la sécurité.

Les auteurs notent des limites, notamment le champ des modèles testés (modèles denses de 7B–9B), la dépendance à Common Crawl comme proxy de ressource, et le fait que l'intervention est un outil de diagnostic nécessitant l'accès aux activations plutôt qu'une protection pour modèle fermé. Ils soulignent également que cette méthode ne remplace pas la nécessité d'un entraînement de sécurité multilingue et ne garantit pas la robustesse contre tous les types de prompts adverses.