🤖 machine learning

Risk Under Pressure: Compute-Aware Evaluation of Adversarial Robustness in Language Models

Cet article propose un cadre d'évaluation sensible au calcul qui mesure le risque adversarial en utilisant les FLOPs cumulés plutôt que des budgets de requêtes fixes, révélant que l'entraînement à l'alignement et la mise à l'échelle des modèles ont des effets non monotones et dépendants des catégories sur l'effort de calcul requis pour effectuer un jailbreak de grands modèles de langage.

Auteurs originaux : Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

Publié 2026-06-11

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Malikeh Ehghaghi, Boglárka Ecsedi, Marsha Chechik, Colin Raffel

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

L'idée centrale : Il ne s'agit pas seulement de savoir si vous pouvez vous introduire, mais de savoir combien cela coûte

Imaginez que vous possédiez une chambre forte de haute sécurité. Une entreprise de sécurité vient tester votre coffre. Elle rapporte : « Nous avons réussi à pénétrer dans la chambre forte 100 % du temps. »

Dans le monde des grands modèles de langage (LLM), c'est généralement là que l'histoire s'arrête. Les chercheurs disent : « Le modèle n'est pas sûr car un attaquant a réussi. »

Mais ce papier soutient que c'est comme dire qu'une banque est peu sûre simplement parce qu'un voleur a fini par entrer, sans demander à quel point il a dû travailler.

Scénario A : Le voleur croche la serrure en 5 secondes avec un trombone.
Scénario B : Le voleur passe 10 jours, utilise une découpeuse laser et engage une équipe d'ingénieurs pour percer le béton.

Les deux scénarios aboutissent à une chambre forte « forcée ». Mais le scénario B est beaucoup moins susceptible de se produire dans le monde réel car il est trop coûteux et difficile.

Ce papier introduit une nouvelle façon de mesurer la sécurité appelée « Risque sous pression » (Risk Under Pressure). Au lieu de simplement compter combien de fois une IA a échoué, il mesure combien de puissance informatique (effort) un attaquant a dû dépenser pour forcer l'IA à dire quelque chose de malveillant.

Les nouveaux outils : Mesurer la « sueur informatique »

Les auteurs ont créé un cadre qui traite la puissance de calcul informatique comme un budget. Ils mesurent la « sueur » qu'un attaquant doit exercer en utilisant les FLOPs (opérations en virgule flottante), ce qui est essentiellement un décompte du nombre de calculs mathématiques que l'ordinateur a dû effectuer.

Ils utilisent deux outils principaux pour visualiser cela :

La « Courbe Risque-Calcul » (La Colline) : Imaginez une colline. Le bas est « facile à briser », et le haut est « difficile à briser ».
- Certains modèles sont comme une petite colline ; vous pouvez atteindre le sommet (briser la sécurité) en quelques pas.
- D'autres modèles sont comme l'Everest ; vous devez dépenser une quantité massive d'énergie juste pour arriver à la moitié de la montée.
L'« Étiquette de prix » (C@τ) : Cela répond à la question : « Quelle puissance de calcul faut-il pour briser ce modèle 50 % du temps ? »
- Si l'étiquette de prix est basse, le modèle est vulnérable.
- Si l'étiquette de prix est énorme, le modèle est robuste, même s'il peut théoriquement être brisé.

Ce qu'ils ont découvert : Des résultats surprenants

Les chercheurs ont testé de nombreux modèles d'IA et méthodes d'attaque. Voici ce qu'ils ont trouvé, traduit en termes courants :

1. L'entraînement ne rend pas toujours les choses plus sûres (Le piège de la « sur-optimisation »)

Vous pourriez penser que plus on entraîne une IA à être sûre, plus elle devient sûre. Le papier a découvert que ce n'est pas toujours vrai.

L'analogie : Imaginez que vous appreniez à un enfant à dire « non » aux inconnus.
- Étape 1 (Base) : L'enfant dit « oui » à tout.
- Étape 2 (SFT) : Vous lui apprenez à être poli. Il devient très bon pour dire « non ».
- Étape 3 (DPO/RL) : Vous essayez de l'affiner encore plus avec des récompenses. Curieusement, ils deviennent parfois moins bons pour dire « non » face à des questions piégeuses.
La découverte : Parfois, la version « intermédiaire » du modèle était en fait la plus difficile à briser. Les versions finales, les plus « alignées », sont parfois devenues plus faciles à piéger, ou du moins n'ont pas beaucoup plus de mal à être brisées.

2. Les modèles plus grands ne sont pas toujours plus sûrs (Le problème de la « cible large »)

Rendre un modèle plus grand (plus de paramètres) revient à construire un château plus grand.

La découverte : Si l'attaquant utilise une méthode « intelligente » (comme une attaque par gradient qui calcule le chemin parfait), un château plus grand est beaucoup plus difficile à briser. C'est comme essayer de grimper une tour de 100 étages plutôt qu'une maison d'un étage.
Le bémol : Si l'attaquant utilise une méthode « stupide » (comme essayer des modèles aléatoires ou faire du copier-coller de mauvais prompts), la taille du château n'a aucune importance. Ils peuvent toujours entrer aussi facilement.
À retenir : Les modèles plus grands arrêtent les hackers « intelligents », mais ils n'arrêtent pas les hackers « paresseux ».

3. L'astuce du « Surrogate » (Voler les clés)

Les attaquants n'ont souvent pas accès au modèle fermé et confidentiel qu'ils veulent pirater.

L'analogie : Imaginez que vous vouliez cambrioler une banque spécifique, mais que vous ne pouvez pas vous en approcher. Alors, vous allez dans une banque similaire dans la rue, vous crochetez sa serrure et vous trouvez une clé de maître qui fonctionne sur les deux banques.
La découverte : Les chercheurs ont montré que les attaquants peuvent entraîner leurs outils de « crochetage » sur un petit modèle d'IA ouvert et gratuit. Une fois qu'ils ont trouvé l'astuce, ils peuvent utiliser cette même astuce sur un modèle d'IA fermé, immense et coûteux. Cela permet à l'attaquant d'économiser une quantité massive d'argent et d'efforts.

4. La sécurité est inégale (L'effet « Fromage Suisse »)

Même un modèle qui semble globalement sûr présente des failles.

La découverte : Il peut falloir beaucoup d'efforts pour faire parler une IA de « harcèlement », mais cela peut demander très peu d'efforts pour la faire parler de « cybercriminalité » ou de « drogues illégales ».
L'analogie : Imaginez une forteresse avec un mur de pierre épais sur le côté nord (difficile à briser) mais une porte en bois fragile sur le côté sud (facile à briser). Si vous ne mesurez que l'épaisseur moyenne des murs, vous pensez que la forteresse est sûre. Mais un attaquant intelligent passera simplement par la porte en bois.

Pourquoi cela importe

Le papier soutient que nous devons arrêter de simplement demander : « L'IA a-t-elle échoué ? » et commencer à demander : « Combien cela a-t-il coûté de la briser ? »

Si une IA nécessite un supercalculateur tournant pendant une semaine pour être piégée, elle est effectivement sûre pour la plupart des gens. Si cela prend 5 secondes, c'est un désastre. En mesurant le « coût » de l'attaque, nous obtenons une image beaucoup plus claire de la sécurité réelle.

En bref, le papier affirme que nous devons cesser de regarder le tableau des scores du « Taux de réussite » et commencer à regarder le tableau des scores de l'« Effort requis » pour comprendre véritablement la sécurité de nos modèles d'IA.

Résumé technique : Risque sous pression : Évaluation de la robustesse adversaire des modèles de langage sensible au calcul

Énoncé du problème

Les évaluations actuelles de la robustesse adversaire pour les grands modèles de langage (LLM) reposent principalement sur le taux de succès d'attaque (ASR - Attack Success Rate) mesuré sous des budgets de requêtes fixes. Cette approche traite implicitement toutes les étapes d'attaque comme ayant un coût égal, ignorant le fait que différentes stratégies d'attaque (par exemple, l'optimisation basée sur le gradient versus le prompting par gabarit/template) entraînent des dépenses de calcul qui peuvent varier de plusieurs ordres de grandeur. Par conséquent, un modèle qui nécessite 100 requêtes d'une attaque par gabarit peu coûteuse pour échouer est évalué de la même manière qu'un modèle qui échoue immédiatement, occultant ainsi le véritable « facteur de travail » ou l'effort de l'adversaire requis pour briser le système. Cette limitation entrave la capacité à déterminer si le coût de calcul d'une attaque justifie son gain pour un adversaire et rend difficile la comparaison des modèles sous une dépense égale de l'attaquant.

Méthodologie

Les auteurs proposent un cadre d'évaluation sensible au calcul qui remplace le nombre de requêtes par la pression de calcul, mesurée en opérations de virgule flottante cumulées (FLOPs), comme substitut de l'effort de l'adversaire.

Cadre de base

Raffinement itératif budgétisé : Les attaques sont modélisées comme des processus itératifs où une politique d'attaque $\pi$ propose des prompts, un modèle cible $M$ génère des réponses, et un juge de sécurité $E$ évalue les résultats. Cette boucle continue jusqu'à ce qu'un succès soit trouvé ou qu'un budget de requête $\lambda$ soit épuisé.
Comptabilisation des FLOPs : Le cadre calcule les FLOPs cumulés pour chaque étape, incluant :
- Les passes directes (forward passes) à travers le modèle cible (génération et évaluation).
- Les passes de rétropropagation (backward passes) pour les attaques basées sur le gradient (boîte blanche).
- Les passes directes à travers des modèles attaquants auxiliaires (raffinement en boîte noire).
- Les passes directes à travers le juge de sécurité.
- Les coûts sont dérivés des approximations standards de FLOPs pour les transformeurs ( $C_{fwd} \approx 2NL$ ), assurant une comparabilité indépendante du matériel.
Courbes Risque-Calcul : Au lieu d'un point ASR unique, le cadre génère des courbes reliant les FLOPs cumulés (axe x) au risque empirique (axe y).
Métriques de synthèse :
- C@ $\tau$ (Calcul pour un risque $\tau$ ) : Les FLOPs cumulés moyens nécessaires pour qu'une attaque atteigne pour la première fois un seuil de risque spécifique (par exemple, 50 %). Des valeurs plus élevées indiquent une plus grande robustesse.
- Efficacité moyenne (AE - Average Efficiency) : Le risque attendu normalisé par FLOP ( $CAURC / \bar{C}_{max}$ ). Des valeurs plus faibles indiquent qu'un modèle est plus difficile à exploiter par unité de calcul.

Configuration expérimentale

Le cadre a été appliqué à travers :

Modèles : Dix modèles couvrant trois familles (Tulu3, Qwen2.5, Qwen3) et diverses étapes d'entraînement (Base, SFT, DPO, RLVR, SafeRL).
Attaques : Trois stratégies distinctes :
- JailBroken : Basée sur des gabarits (obfuscation aléatoire).
- PAIR : Raffinement itératif en boîte noire utilisant un LLM attaquant.
- GCG : Optimisation de gradient de coordonnées en boîte blanche.
Benchmarks : HarmBench (200 comportements) et JailbreakBench (100 comportements).

Résultats clés

L'analyse sensible au calcul a révélé des schémas invisibles avec les métriques ASR standards :

Effets non monotones de l'alignement : L'entraînement à l'alignement n'augmente pas linéairement la robustesse. Dans la famille Tulu3, l'étape de réglage fin supervisé (SFT) a souvent présenté la robustesse la plus élevée (par exemple, GCG et PAIR n'ont pas atteint 50 % de risque dans le budget imparti). L'alignement ultérieur via l'optimisation de préférence directe (DPO) et l'apprentissage par renforcement avec récompenses vérifiables (RLVR) a souvent réduit la robustesse, particulièrement contre les attaques par gabarit, malgré un ASR plus élevé dans certains cas.
Avantages d'échelle asymétriques : L'augmentation de la taille du modèle (par exemple, de Qwen2.5 0.5B à 7B) a considérablement augmenté le coût de calcul pour les attaques basées sur le gradient (augmentation de 20 $\times$ de C@0.5) mais a offert une protection minimale contre les attaques par gabarit peu coûteuses (augmentation de seulement 2,8 $\times$ ). Les métriques ASR standards masquaient cette disparité, montrant des taux de succès similaires à travers les échelles.
Transfert d'attaque de substitution : Les attaques basées sur le gradient (GCG) optimisées sur un petit modèle de substitution à poids ouverts (Qwen2.5-0.5B) ont réussi à se transférer à un modèle cible plus large à poids fermés (Qwen3-8B) pour une fraction du coût original. Bien que le transfert n'ait pas toujours atteint des régimes de risque élevé, il a démontré que les attaquants peuvent réduire les coûts en optimisant sur des modèles de substitution.
Hétérogénéité entre les catégories de préjudices : Au sein d'un même modèle, le coût de calcul pour briser la sécurité variait jusqu'à $\approx 5\times$ selon les catégories de préjudices (ex: harcèlement vs cybercriminalité). L'apprentissage par renforcement pour la sécurité (Safety-RL) a augmenté les coûts globaux mais a laissé certaines catégories (ex: cybercriminalité, activités illégales) disproportionnellement accessibles ou même plus efficacement exploitables (AE plus élevé) que le modèle de base.
Compromis de la sécurité par RL (Safety-RL) : Bien que le Safety-RL ait généralement augmenté le coût de l'attaque globale, il a introduit des vulnérabilités spécifiques. Par exemple, sous GCG, le modèle SafeRL était strictement moins robuste que son homologue de base, suggérant un décalage entre la distribution des prompts d'entraînement RL et les séquences de jetons (tokens) découvertes par l'optimisation de gradient.

Signification et affirmations

L'article soutient que la robustesse est une fonction du coût de calcul, et non seulement de la possibilité. En adoptant une perspective de « facteur de travail » centrée sur la sécurité, les auteurs affirment :

Pertinence opérationnelle : Une vulnérabilité n'est opérationnellement pertinente que si elle est exploitable dans un budget réaliste de l'adversaire. Rehausser le plancher du coût de calcul peut être aussi efficace que de baisser les taux de succès.
Limites des métriques statiques : Les scores ASR standards sous des budgets de requêtes fixes surestiment systématiquement la robustesse en ignorant la variation d'efficacité des différentes classes d'attaques et les effets non linéaires de l'échelle des modèles et de l'alignement.
Comparaison unifiée : Le cadre proposé permet des comparaisons équitables entre diverses stratégies d'attaque (boîte blanche vs boîte noire) et configurations de modèles en les normalisant par rapport à un axe de calcul partagé.
Évaluation nuancée de la sécurité : L'ajustement de la sécurité n'est pas une amélioration monolithique ; il crée des paysages de protection inégaux où certaines catégories deviennent nettement plus difficiles à briser tandis que d'autres restent vulnérables ou deviennent plus efficaces à attaquer.

Les auteurs concluent qu'une évaluation de l'adversité sensible au coût est nécessaire pour jauger avec précision le risque réel du déploiement des LLM, car les modèles paraissant robustes sous les métriques de nombre de requêtes peuvent échouer de manière catastrophique lorsqu'ils sont évalués sous la pression du calcul.