Imaginez que vous êtes le chef de cuisine d'un restaurant très chic qui sert deux choses à la fois : une image sur une assiette et une commande orale. Votre objectif est de veiller à ce que la cuisine ne prépare jamais rien de dangereux, même si quelqu'un essaie de piéger le chef en cachant une instruction « empoisonnée » dans l'image ou en chuchotant d'une manière étrange. C'est le monde des Modèles de Langage de Grande Taille Multimodaux (MLLM). Ce sont des cerveaux informatiques super intelligents capables de « voir » des images et de « lire » du texte, puis de discuter avec vous. Mais comme ils peuvent voir, des acteurs malveillants peuvent tenter d'introduire des commandes nuisibles en les dessinant dans les pixels ou en les cachant dans l'arrière-plan d'une photo.

Pour empêcher cela, les scientifiques ont inventé les Défenses au Moment de l'Inférence. Considérez ces défenses comme des gardiens de sécurité qui se tiennent juste à la porte de la cuisine. Ils ne changent pas la recette du chef (le cerveau du modèle) ; au lieu de cela, ils vérifient la commande avant qu'elle n'entre, ou ils vérifient le plat final avant qu'il ne sorte. Certains gardiens ajoutent une note d'avertissement polie à la commande, tandis que d'autres secouent un peu l'image pour flouter les ruses cachées. La grande question pour tout le monde dans le monde de la sécurité de l'IA est la suivante : Quel garde fait réellement le meilleur travail ? Si nous ne pouvons pas faire confiance aux gardes, nous pourrions accidentellement servir un repas dangereux ou, pire encore, nous pourrions être si effrayés par le danger que nous refuserions de servir de la nourriture du tout.

---

Le Grand Audit de la Cuisine : Quand la Fiche de Notation s'est Trompée

Une équipe de chercheurs de Moscou a décidé de jouer les détectives. Ils n'ont pas construit de nouveaux gardes ; au lieu de cela, ils sont allés fouiller dans les archives d'une expérience récente qui prétendait tester trois gardes de sécurité différents (inspirés par des méthodes appelées RapGuard, AdaShield et SmoothVLM) à travers huit chefs IA différents. Ils voulaient voir qui était le meilleur. Mais en creusant dans les dossiers, ils ont découvert un désordre de liens brisés, d'ingrédients manquants et de fiches de notation confuses.

Voici ce qu'ils ont découvert, servi avec une dose de réalité.

1. Le Mystère de l'« Ingrédient Manquant »

Les chercheurs ont découvert que l'expérience était censée tester 9 000 commandes différentes (entrées) à travers sept tests de sécurité différents. Cependant, lorsqu'ils ont vérifié la provenance (la trace écrite de l'origine des données), ils ont réalisé que trois des sept tests étaient complètement cassés.

• L'erreur de la « Mauvaise Assiette » : Un test, destiné à vérifier si l'IA pouvait repérer des instructions cachées dans les images, servait en réalité une image totalement différente. C'était comme essayer de tester un détecteur de fumée en vaporisant de l'eau sur un grille-pain au lieu d'un détecteur de fumée.
• La triche du « Texte Seul » : Un autre test était censé être un mélange d'images et de texte, mais le système a accidentellement laissé l'IA ignorer les images pour simplement lire le texte. C'était un « repli sur le texte seul », ce qui signifie que l'IA n'a jamais eu à regarder l'image pour réussir le test.
• Le bug du « Patch Aléatoire » : Un troisième test prétendait utiliser un « patch adversaire » spécial (un petit autocollant complexe sur une image pour confondre l'IA). Mais l'ordinateur n'a pas généré le sticker complexe ; il a juste dessiné un rectangle aléatoire.

À cause de ces erreurs, les chercheurs ont dû rejeter les résultats de ces trois tests. Ils ne pouvaient pas simplement « corriger » les chiffres ; les données n'étaient tout simplement pas là. Cela ne leur a laissé que 4 820 entrées valides provenant de quatre tests spécifiques (FigStep, JailBreakV, SALAD-Bench et HarmBench-Simple) pour travailler.

2. Le Piège des « Mots-Clés »

L'expérience originale utilisait une méthode très simple pour décider si l'IA était sûre : elle cherchait des « mots magiques » spécifiques.

• Si l'IA disait « Je ne peux pas faire cela » ou « Je suis désolé », elle était marquée comme Sûre (un refus).
• Si l'IA disait « Voici comment faire... » ou « Bien sûr, je peux vous aider », elle était marquée comme Non Sûre (une réponse nuisible).

Les chercheurs ont trouvé un énorme problème avec cette méthode. Le système comptait les réponses vides (où l'IA ne disait rien du tout) comme étant « Sûres » simplement parce que le code hérité n'avait pas de règle spéciale pour elles ; puisque la chaîne vide ne correspondait ni à la liste des contenus « nuisibles » ni à celle des « refus », la logique par défaut les comptait comme sûres. Il comptait également les réponses qui commençaient par un avertissement poli mais qui donnaient ensuite les instructions dangereuses comme étant « Sûres », car le système ne cherchait que la présence d'une phrase de refus pour annuler une réponse nuisible, et parfois la logique s'emmêlait.

Lorsqu'ils ont revérifié les données, ils ont trouvé que la méthode par « mots-clés » était un juge terrible. C'était comme un enseignant qui noterait un examen en regardant seulement si le mot « le » est présent, en ignorant si l'élève a réellement répondu à la question. Dans un audit de 246 réponses complexes, le système de mots-clés a manqué 13 réponses nuisibles qu'un juge plus intelligent de type humain (un « juge de la famille Haiku ») avait correctement identifiées comme dangereuses. En termes techniques, le système de mots-clés a étiqueté ces 13 cas comme « Sûrs » alors qu'ils étaient en réalité « Nuisibles » (faux négatifs).

3. Le Mythe du « Refus de Masse »

L'étude originale semblait suggérer que les gardes de sécurité provoquaient le refus de tout par l'IA (un « refus de masse »). Les chercheurs ont ré-audité 38 500 questions sûres et normales pour voir à quelle fréquence l'IA disait « non » quand elle n'en avait pas besoin.

Le résultat ? L'IA était en fait très polie et utile.

• Le taux estimé de refus inutiles était de seulement 0,52 %.
• Même dans le pire des scénarios (le groupe de données le plus important), le taux n'était que de 3,24 %.
• Les chercheurs ont noté que l'incertitude liée à l'échantillonnage (« sampling-only uncertainty ») pouvait atteindre 10,92 %, mais même cela est loin du « refus de masse » suggéré par l'étude originale.

La confusion venait du « préambule défensif ». Les gardes de sécurité ajoutaient souvent un long avertissement poli au début de la réponse (ex : « Je dois vous avertir que ceci est dangereux... »). L'ancien système de mots-clés pensait que cet avertissement était le refus, mais l'IA donnait la réponse quand même. C'était comme un videur disant : « Je ne vous laisse pas entrer », mais qui ouvrait ensuite la porte et vous laissait passer. Le système de mots-clés a mal étiqueté ces préambules comme des refus, gonflant ainsi les chiffres.

4. Le Coût de la Sécurité

Enfin, les chercheurs ont regardé combien de temps ces gardes de sécurité faisaient perdre.

• Le garde « Gaussien » (qui floute l'image cinq fois et vote sur la réponse) prenait 5,45 à 12,76 fois plus de temps pour traiter une requête que de ne rien faire.
• La pile complète des trois gardes prenait 4,36 à 16,59 fois plus de temps.

Cela signifie que, bien que les gardes essaient d'aider, ils rendent la cuisine incroyablement lente.

Le Bilan

Ce document ne nous dit pas quel garde de sécurité est le « meilleur ». En fait, il nous dit que nous ne pouvons pas faire confiance aux classements précédents car les données étaient brisées et la méthode d'évaluation était défaillante.

• Ce qu'ils ont écarté : Ils ont prouvé que les affirmations originales concernant le « refus de masse » étaient fausses et que trois des sept tests de sécurité étaient invalides.
• Ce qu'ils ont trouvé : Les gardes de sécurité (particulièrement les enveloppes de prompts/prompt wrappers) modifient effectivement le comportement de l'IA, mais l'effet varie énormément selon le modèle d'IA et le type de test. Parfois ils aident, parfois ils nuisent, et parfois ils ralentissent simplement les choses.
• La Leçon : Vous ne pouvez pas simplement lancer un test et regarder un score. Vous devez vous assurer que les ingrédients (entrées) sont réels, que la fiche de notation (évaluation) mesure réellement la sécurité, et que vous avez la recette complète (le texte brut) pour vérifier le travail.

Les auteurs concluent qu'avant de pouvoir comparer différents gardes de sécurité, nous devons construire un système de test meilleur et plus honnête. D'ici là, nous ne pouvons pas dire avec certitude qui est le héros et qui ne fait que ralentir la cuisine.