Résumé Technique : IH-BENCHMARK

Énoncé du Problème

Alors que les modèles de langage de grande taille (LLM) évoluent vers des agents capables d'orchestrer des outils et de gérer des conversations multi-tours, la fiabilité de la robustesse de la hiérarchie des instructions est devenue centrale pour la sécurité et l'utilité. Le problème fondamental abordé est la capacité du modèle à prioriser correctement les instructions en fonction de leur source : les messages système doivent prévaloir sur les entrées utilisateur, qui doivent elles-mêmes prévaloir sur l'historique de discussion et les sorties d'outils.

Lorsque les modèles ne respectent pas cet ordre, des entrées utilisateur adverses peuvent outrepasser les contraintes système, et des sorties d'outils malveillantes peuvent détourner le comportement du modèle en pleine tâche. Bien que des travaux antérieurs aient formalisé cette hiérarchie, les évaluations existantes souffrent de deux limitations principales :

1. Focus sur un seul bord : De nombreux benchmarks se concentrent uniquement sur les conflits système-utilisateur ($S \succ U$), négligeant les conflits provenant des sorties d'outils.
2. Jeux de données adaptés : D'autres adaptent des jeux de données publics plutôt que de construire des scénarios de conflit de hiérarchie dédiés, ce qui limite la couverture des contextes agentiques et des contraintes spécifiques telles que les listes d'autorisation/interdiction d'outils ou les restrictions de paramètres.

Par conséquent, il manque des benchmarks qui testent conjointement les conflits à travers les niveaux de la hiérarchie dans un contexte agentique.

Méthodologie : IH-BENCHMARK

Les auteurs introduisent IH-BENCHMARK (IH-B), un benchmark conçu sur mesure pour évaluer la robustesse de la hiérarchie des instructions à travers deux pistes distinctes :

1. Système $\succ$ Utilisateur ($S \succ U$) : Évalue si un modèle préserve une contrainte système de priorité supérieure lorsqu'un utilisateur émet une requête conflictuelle.
2. Utilisateur $\succ$ Outil ($U \succ T$) : Évalue si un modèle préserve la tâche de l'utilisateur lorsqu'une instruction conflictuelle apparaît dans une sortie d'outil de priorité inférieure.

Construction et Portée

• Familles de Contraintes : Le benchmark est construit à partir d'une taxonomie rédigée par des humains comprenant 44 familles de contraintes réparties en cinq domaines : générique, santé, finance, vente au détail et codage.
  • $S \succ U$ Track : 19 familles couvrant les contraintes de sortie (lexicales, format), les contraintes de sujet (sujets interdits, détournement de concurrent) et les contraintes d'outils (interdictions globales, restrictions de paramètres).
  • $U \succ T$ Track : 25 familles couvrant la manipulation du format de réponse, la manipulation de contenu (altération factuelle), la manipulation d'outils (blocage/redirection d'appels) et les actions agentiques à haute sévérité (exécution de commandes, exfiltration de données, achats non autorisés).
• Génération de Scénarios : IH-B génère procéduralement 2 336 scénarios exécutables (734 dans $S \succ U$, 1 602 dans $U \succ T$). Les scénarios sont générés en liant les paramètres de contrainte et en faisant varier :
  • La Strictité de la Contrainte ($L$) : Allant de simples énoncés ($L_1$) à des clauses renforcées et des directives de refus ($L_3$).
  • La Formulation de l'Invite ($P$) : Requêtes utilisateur explicites ($P_1$) vs implicites ($P_2$).
  • La Variante de Livraison ($D$) : Pour $U \succ T$, variation de la manière dont les instructions conflictuelles sont intégrées dans les sorties d'outils (texte brut, rupture de contexte, acknowledgement, basculement).
• Simulateurs d'Agents : Pour les scénarios agentiques $U \succ T$, le benchmark utilise trois simulateurs Python à état (codage, vente au détail, support de santé) pour modéliser les effets secondaires persistants et les interactions d'outils multi-étapes.
• Protocole d'Évaluation : Un protocole binaire uniforme de type succès/échec est utilisé.
  • DSL de Prédicat : Un langage de domaine spécifique léger évalue la correspondance de chaînes, les vérifications structurelles et l'inspection des appels d'outils.
  • LLM-as-a-Judge : Utilisé sélectivement pour les catégories où la vérification mécanique est difficile (ex: dénigrement de marque, engagement sur un sujet), utilisant une rubrique à 4 niveaux mappée sur des décisions binaires.
  • Scénarios sans Conflit : Inclus pour mesurer le sur-refus et s'assurer que les modèles ne échouent pas à des requêtes ordinaires à cause de la sensibilité aux contraintes.

Contributions Clés

1. Benchmark Procédural : La proposition d'IH-B, couvrant les pistes $S \succ U$ et $U \succ T$ avec 2 336 scénarios dérivés de 44 familles de contraintes.
2. Cadre d'Évaluation Unifié : Un système combinant des scénarios contrôlés au niveau de l'invite avec des simulateurs d'agents à état, permettant l'évaluation dans des contextes statiques, médiés par des outils et agentiques.
3. Analyse Empirique Complète : Évaluation de 37 variantes de modèles (22 sources fermées, 15 poids ouverts) révélant que la robustesse de la hiérarchie des instructions n'est pas une capacité unique mais un ensemble de comportements variant selon les surfaces de conflit et les types de contraintes.

Résultats

L'évaluation de 37 modèles révèle une variance significative de performance, avec des taux de conformité globaux allant de 98,2 % à 20,5 %.

• Dissociation des Pistes : Une haute performance sur la piste $S \succ U$ n'est pas un indicateur fiable de la robustesse $U \succ T$. Par exemple, Grok 4.20 (R) a atteint 96,9 % de conformité sur $S \succ U$ mais seulement 65,6 % sur $U \succ T$. Cela suggère que résister aux dépassements directs de l'utilisateur ne garantit pas la résistance à l'injection via les sorties d'outils.
• Disparités entre Modèles : Les modèles à source fermée ont généralement surpassé les modèles à poids ouverts. La conformité moyenne pour les modèles fermés était de 88,6 % ($S \succ U$) et 75,1 % ($U \succ T$), contre 80,5 % et 59,1 % pour les modèles à poids ouverts.
• Effets de la Strictité de la Contrainte :
  • Dans $S \succ U$, des contraintes plus strictes ($L_2, L_3$) ont systématiquement amélioré la conformité, particulièrement pour les modèles plus faibles (ex: Qwen 3 235B-A22B est passé de 23,5 % à 88,2 % dans les contextes spécifiques au domaine).
  • Dans $U \succ T$, l'effet du durcissement était moins uniforme. Alors que certains modèles (ex: Grok 4.20 (R)) ont montré des gains massifs (18,8 % à 89,6 %), d'autres (ex: Qwen 3 235B-A22B) sont restés proches de 10 % à travers tous les niveaux de strictité, indiquant une incapacité fondamentale à maintenir les limites plutôt qu'une simple sensibilité aux instructions.
• Analyse des Familles de Contraintes :
  • $S \succ U$ : La famille la plus difficile était forbid-tools-all (52,4 %), où les modèles peinent à refuser tous les appels d'outils malgré les demandes de l'utilisateur. Les contraintes de sujet étaient les plus faciles (ex: forbid-disparagement à 98,6 %).
  • $U \succ T$ : Les familles les plus difficiles impliquaient des actions à faible enjeu et non suspectes comme content-lie (50,1 %) et format-disclaimer (50,4 %). À l'inverse, les actions à haute sévérité comme les achats non autorisés ou la fermeture massive de tickets ont été mieux résistées (ex: purchase à 88,1 %), probablement grâce à l'entraînement existant sur l'alignement de sécurité.
• Subtilité des Échecs : Les échecs les plus révélateurs étaient souvent subtils (ex: clauses de non-responsabilité injectées, petites distorsions factuelles) plutôt que des actions ouvertement dangereuses. Les modèles étaient plus fiables pour résister aux actions de masse non autorisées qu'à la détection de dérives factuelles subtiles.

Signification et Limites

L'article soutient que la robustesse de la hiérarchie des instructions n'est pas une capacité uniforme unique, mais une collection de comportements qui doivent être évalués à travers plusieurs surfaces de conflit, types de contraintes et présentations d'attaques. La publication d'IH-B, incluant le corpus, les simulateurs et l'outil d'évaluation, vise à soutenir une évaluation et un déploiement responsables en aidant les développeurs à identifier les faiblesses spécifiques au modèle ou au scénario avant le déploiement.

Limites :

• Le benchmark se concentre sur des scénarios à tâche unique bornée et ne couvre pas les réglages multi-tours plus longs où le contexte s'accumule au fil du temps.
• La couverture des domaines est sélectionnée et asymétrique selon l'adéquation naturelle de chaque domaine à la piste (ex: la finance n'est présente que dans $S \succ U$, le codage uniquement dans $U \succ T$).
• Bien que 35 des 44 familles de contraintes aient été rédigées par des humains, le reste a été suggéré par un LLM et révisé manuellement, ce qui signifie que la couverture est large mais non exhaustive.

Les auteurs reconnaissent que la divulgation de faiblesses spécifiques de modèles comporte des risques d'aider les adversaires, mais postulent que le bénéfice d'une évaluation de sécurité systématique et reproductible l'emporte sur ces risques.