💻 computer science

Instruction fragility under hidden operational requirements

Cet article démontre que les instructions en langage naturel sont fragiles face aux exigences opérationnelles cachées, révélant que si le prompting générique échoue à satisfaire les contraintes omises, la performance s'améliore considérablement lorsque ces contraintes sont explicitement sollicitées et exécutées.

Auteurs originaux : Chanho Park, Jinbae Gong, Minsu Kim, Gyeongho Gong, Woochan Lee, Yeachan Kwak, Seongim Choi

Publié 2026-07-07

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chanho Park, Jinbae Gong, Minsu Kim, Gyeongho Gong, Woochan Lee, Yeachan Kwak, Seongim Choi

Article original sous licence CC BY 4.0 (https://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

Le problème central : Le « Génie » qui se trompe

Imaginez que vous avez un Génie magique (l'IA) qui exauce vos vœux. Vous dites : « Rends-moi riche. »

Le Génie pourrait interpréter cela de mille façons :

Il pourrait vous donner un emploi légitime.
Il pourrait imprimer de la fausse monnaie.
Il pourrait pirater une banque.
Il pourrait changer la définition de la « richesse » pour que vous soyez riche en « bonheur » mais pauvre en argent liquide.

Le papier soutient que lorsque vous donnez une instruction courte à une IA, vous lui donnez essentiellement une liste de souhaits avec des éléments manquants. Vous pensez peut-être vouloir une « richesse légitime », mais vous n'avez pas précisé « pas d'activités illégales » ou « pas d'erreurs bancaires ». Parce que vous ne l'avez pas dit, l'IA est libre de choisir n'importe quelle version de la « richesse » qui correspond aux mots que vous avez utilisés.

Les auteurs appellent cela la « Fragilité de l'instruction ». L'instruction est fragile car elle se brise facilement lorsque l'IA devine la mauvaise version de vos règles cachées.

L'expérience : Le jeu de la « Règle Secrète »

Pour tester cela, les chercheurs ont créé un jeu avec 100 tâches différentes (comme écrire un e-mail, résumer un rapport ou planifier un voyage).

Le Prompt Visible : C'est ce que l'utilisateur voit et tape (ex : « Résume cet article »).
Les Exigences Cachées : Ce sont des règles secrètes connues uniquement des chercheurs (les évaluateurs), et non de l'IA. Exemples : « Doit faire moins de 50 mots », « Doit inclure un avertissement de risque », « Doit être au format JSON » ou « Ne doit pas utiliser le mot 'certainement' ».

L'IA devait suivre le prompt visible et deviner parfaitement les règles cachées. Si elle manquait ne serait-ce qu'une seule règle cachée, la tâche était un échec total.

Les Résultats : Deviner vs Demander

Les chercheurs ont testé l'IA sous différentes conditions pour voir comment elle gérait ces règles manquantes.

1. La « Tentative Unique » (2,7 % de réussite)

Analogie : Vous dites à un chef : « Fais-moi un sandwich », et vous partez. Vous ne dites pas « sans oignons », « avec du pain au levain » ou « coupé en deux ».
Résultat : L'IA a réussi seulement 2,7 % du temps. Elle a presque toujours manqué les règles cachées.

2. Le « Modèle Générique » (7,3 % de réussite)

Analogie : Vous donnez au chef un « Bon de commande de sandwich » standard qui possède des cases pour le « Pain » et la « Viande », mais vous n'avez toujours pas rempli la case spécifique « Sans Oignons ».
Résultat : Un peu mieux, mais toujours largement erroné. Les formulaires génériques ne règlent pas le problème des détails spécifiques manquants.

3. La « Fausse Conversation » (1,7 % de réussite)

Analogie : Vous demandez au chef : « Avez-vous des règles spéciales ? » et le chef répond : « Non, faites juste un sandwich. »
Résultat : Cela n'a servi à rien. Parler sans obtenir les bonnes informations est inutile.

4. La « Clarification Véritable » (8,0 % de réussite)

Analogie : Vous forcez le chef à poser des questions spécifiques à partir d'un menu (ex : « Voulez-vous le format JSON ? »). Le chef pose la question, et vous répondez « Oui ».
Résultat : Toujours très bas. L'IA était mauvaise pour déterminer quelles questions poser. Elle posait les mauvaises questions ou manquait les plus critiques.

5. L'« Oracle » (La feuille de triche) (64,7 % de réussite)

Analogie : Vous donnez au chef une feuille de triche qui liste chaque règle cachée avant qu'il ne commence à cuisiner.
Résultat : Le succès grimpe à 64,7 %. Cela prouve que si l'IA connaît les règles, elle peut beaucoup mieux les suivre.

La grande conclusion :
Le problème n'est pas que l'IA est stupide ; le problème est qu'elle ne peut pas lire dans vos pensées. Quand vous cachez les règles, l'IA échoue. Quand vous dites explicitement les règles à l'IA, elle réussit. Cependant, même avec la feuille de triche, elle a encore échoué environ 35 % du temps, ce qui signifie que même lorsqu'elle connaît les règles, elle oublie parfois de les suivre parfaitement.

Pourquoi cela importe (La théorie des « Ensembles »)

Le papier utilise un concept mathématique sophistiqué pour expliquer cela simplement :

Considérez votre instruction comme un filet.
Le filet capture de nombreux résultats possibles (exécutions).
Vous voulez seulement que l'IA capture les « bons » résultats (ceux que vous voulez réellement).
Si votre filet est trop large (parce que vous n'avez pas précifié les règles), il capture aussi des résultats « mauvais » (comme des transferts illégaux ou des formats erronés).
La sécurité consiste à rétrécir le filet jusqu'à ce qu'il ne capture que les bonnes choses. Vous ne pouvez pas faire cela à moins de dire explicitement à l'IA ce qu'elle doit exclure.

Résumé des « Modes d'Échec »

Le papier détaille pourquoi l'IA a échoué :

Information Manquante : L'IA ne connaissait pas les règles (le problème majeur).
Mauvaises Questions : L'IA a posé les mauvaises questions pour trouver les règles.
Erreurs d'Exécution : Même quand l'IA connaissait les règles, elle oubliait parfois de les rédiger correctement.

L'essentiel à retenir

Si vous voulez qu'une IA accomplisse une tâche de manière sûre et correcte, vous ne pouvez pas simplement lui donner une commande vague et espérer qu'elle « comprenne ». Vous devez énoncer explicitement les contraintes cachées (comme le nombre de mots, les formats et les limites de sécurité). Les prompts génériques et les conversations génériques ne suffisent pas ; vous devez spécifiquement solliciter et confirmer les règles manquantes.

Résumé Technique : Fragilité des Instructions sous l'Effet de Contraintes Opérationnelles Cachées

Définition du Problème
L'article traite du problème de la fragilité des instructions découlant de contraintes opérationnelles cachées. Dans les interactions en langage naturel avec les grands modèles de langage (LLM), les utilisateurs omettent souvent des contraintes qui sont connues d'eux ou des évaluateurs mais absentes du prompt (par exemple, des formats de sortie spécifiques, des limites de mots, des étiquettes de risque ou des limitations de sources). Les auteurs formalisent cela non pas comme un résultat unique voulu, mais comme une sémantique à valeurs d'ensemble : une instruction dénote un ensemble d'exécutions réalisables. La sécurité face à une telle sous-spécification exige que chaque exécution réalisable au sein de cet ensemble appartienne également à l'ensemble des exécutions acceptables par l'utilisateur. Si l'instruction permet ne serait-ce qu'une seule exécution inacceptable (par exemple, une méthode frauduleuse pour « me rendre riche »), l'instruction n'est pas robuste. Le problème central est que les instructions finies ne peuvent identifier de manière unique une exécution voulue sans transmettre toutes les contraintes latentes.

Méthodologie
L'étude combine un cadre théorique formel avec un benchmark empirique contrôlé.

Cadre Formel :
- Les auteurs définissent une instruction $s$ ayant une dénotation $J_sK_B \subseteq H$ (un ensemble d'histoires réalisables) sous une théorie de fond $B$ .
- La sécurité est définie par le critère de sécurité adversaire : $J_sK_B \subseteq A_{\tau, \eta}$ , où $A_{\tau, \eta}$ est l'ensemble des histoires acceptables (satisfaisant des seuils d'utilité et des budgets d'effets secondaires).
- Les analyses théoriques dérivent des bornes inférieures d'information (nécessitant $\Omega(\log N)$ symboles pour distinguer $N$ intentions), des contraintes de cardinalité (les instructions finies ne peuvent dénoter des sous-ensembles arbitraires d'espaces d'exécution infinis) et une dureté computationnelle (la synthèse sûre se ramène au problème NP-complet de la Couverture d'Ensemble).
Construction du Benchmark :
- Un benchmark de 100 tâches a été créé, couvrant 20 domaines thématiques (ex: mémos de politique, réponse aux incidents, notes financières).
- Chaque tâche consiste en un prompt utilisateur visible et un ensemble de contraintes cachées (2 à la tâche) connues de l'évaluateur mais omises dans le prompt.
- Les contraintes sont catégorisées en trois types :
  - Implicites conventionnelles : Hypothèses, incertitude, compromis, niveaux de risque.
  - Opérationnelles : Limites de mots, limites de sources.
  - Formatage privé : JSON valide, nombre exact de puces.
- Un « passage strict » est défini par la satisfaction de chaque contrainte cachée d'une tâche.
Protocoles Expérimentaux :
L'étude a évalué trois modèles (GPT-5.4, Claude Opus 4.7, Gemini 3.1 Pro) à travers neuf conditions :
- Faible Information : Prompting en un coup (one-shot), templates génériques, et clarification de contrôle négatif (questions forcées avec des réponses « aucune contrainte cachée »).
- Élicitation : Clarification forcée (réponses sincères à des questions basées sur des menus) et vérification (listes de contrôle visibles ou internes).
- Conditions d'Oracle : Oracle budgétisé (révélation de jusqu'à 4 contraintes cachées) et Oracle complet (révélation de toutes les contraintes cachées).

Résultats Clés
Les résultats empiriques, basés sur 2 700 observations tâche–modèle–condition, révèlent un contraste frappant entre l'interaction générique et la révélation des véritables contraintes :

Échec de l'Interaction Générique : Le prompting one-shot n'a obtenu un taux de passage strict que de 2,7 % (8/300 essais). Les templates génériques (7,3 %) et la clarification de contrôle négatif (1,7 %) n'ont apporté qu'une amélioration négligeable. Cela indique que l'interaction sans information pertinente à la tâche ne permet pas de récupérer les contraintes omises.
Valeur de l'Élicitation Correcte : La révélation des bonnes contraintes cachées a produit un saut qualitatif de performance. La condition Oracle Complet a atteint un taux de passage strict de 64,7 %. L'Oracle Budgétisé (révélation partielle) a atteint 54,0 %.
Échec de l'Élicitation : Même lorsque les modèles étaient forcés de poser des questions (Clarification Forcée), ils n'ont atteint qu'un taux de réussite de 8,0 %. L'écart entre la Clarification Forcée et l'Oracle Budgétisé (46,0 points de pourcentage) démontre que les modèles échouent fréquemment à identifier quelles contraintes latentes sont pertinentes, posant les mauvaises questions ou en manquant des critiques (par exemple, les limites de sources n'ont été rappelées que 1,0 % du temps).
Échec d'Exécution : Même sous conditions d'Oracle Complet, où toutes les exigences étaient connues, le taux de réussite n'a pas atteint 100 % (64,7 %). Cela indique un second mode de défaillance : la conformité aux contraintes connues, où les modèles échouent à exécuter la spécification complète même lorsqu'elle est explicitement fournie.
Échec Composé : Les taux de passage strict se sont effondrés de manière multiplicative à mesure que le nombre de contraintes cachées augmentait. Pour les protocoles à faible information, les taux de réussite sont tombés proche de zéro pour les tâches comportant 3 à 5 contraintes.
Spécificité des Exigences : Les exigences de formatage privé (JSON, nombre de puces) étaient presque impossibles à récupérer sans divulgation (0 % en one-shot), tandis que les exigences conventionnelles (incertitude, éviter les absolus) étaient partiellement inférées mais restaient peu fiables.

Signification et Revendications
L'article prétend identifier un mode de défaillance contrôlé pour la conformité opérationnelle stricte dans les systèmes d'IA. Ses principales contributions sont :

Formalisation de la Fragilité des Instructions : Il fournit un cadre de dénotation à valeurs d'ensemble montrant que la robustesse nécessite l'exclusion de toutes les exécutions inacceptables, et non seulement l'inclusion d'une bonne exécution.
Diagnostic de l'Échec de Communication : Les résultats démontrent que le goulot d'étranglement dans le suivi des instructions n'est pas simplement le manque de tours de dialogue, mais la qualité de l'information élicitée. La clarification générique est insuffisante ; une élicitation ciblée des exigences est nécessaire.
Recadrage des Templates et de la Vérification : L'étude suggère que les templates de prompt et les listes de contrôle de vérification génériques n'apportent que des gains marginaux. Ils ne peuvent se substituer à la communication explicite des contraintes privées spécifiques à la tâche.
Implications pour la Sécurité : Les conclusions soutiennent le principe de conception selon lequel les assistants IA robustes nécessitent une élicitation de l'état des exigences, une intégration fidèle de ces contraintes et une vérification par rapport à cet état, plutôt que de compter sur des prompts plus longs ou une interaction générique.

Les auteurs maintiennent une portée modeste, notant que le benchmark est synthétique et uniquement textuel, se concentrant sur des contraintes vérifiables en surface. Ils ne prétendent pas mesurer le comportement d'un agent sur le long terme ou la qualité subjective, mais cherchent à isoler le mode de défaillance spécifique des exigences opérationnelles omises. Les résultats suggèrent que les modèles frontières actuels, bien que capables, ne sont pas clairvoyants et ne peuvent pas récupérer de manière fiable les contraintes omises sans communication explicite.