💻 computer science

When Prompt Under-Specification Improves Code Correctness: An Exploratory Study of Prompt Wording and Structure Effects on LLM-Based Code Generation

Cette étude exploratoire révèle que, si la sous-spécification des consignes dégrade généralement la génération de code sur des benchmarks structurellement minimaux, elle peut paradoxalement améliorer l'exactitude sur des tâches plus riches comme LiveCodeBench en perturbant les indices trompeurs, démontrant ainsi que la robustesse des consignes dépend fortement de la structure de la tâche plutôt que d'être une propriété fixe du modèle.

Auteurs originaux : Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

Publié 2026-04-28

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Amal AKLI, Mike PAPADAKIS, Maxime CORDY, Yves Le TRAON

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

Imaginez que vous embauchiez un assistant brillant mais légèrement trop littéral pour écrire un programme informatique pour vous. Vous lui donnez un ensemble d'instructions (un « prompt »). Pendant longtemps, les experts ont cru que plus vos instructions étaient précises, détaillées et strictes, mieux l'assistant s'en sortirait. Si vous omettiez un détail, l'assistant se perdait et échouait.

Ce document remet en question cette vieille croyance. Les chercheurs ont découvert que parfois, donner à votre assistant moins de détails l'aide en réalité à écrire un meilleur code.

Voici comment ils ont découvert cela, expliqué à travers des analogies simples :

1. Les Deux Types d'« Examens »

Les chercheurs ont testé cette idée sur deux types différents d'« examens » (benchmarks) pour les modèles d'IA :

L'Examen « Flashcards » (HumanEval) : Ce sont comme de courtes cartes mémo d'une seule phrase. Les instructions sont très brèves, sans contexte supplémentaire. C'est comme demander : « Écrivez une fonction pour trier cette liste. »
L'Examen « Manuel Scolaire » (LiveCodeBench) : Ce sont comme des chapitres complets de manuel. Ils incluent une longue histoire, une liste de règles, des exemples d'entrées et de sorties, et des contraintes spécifiques. C'est comme dire : « Voici une histoire sur le tri d'une liste de noms. Voici les règles : les noms ne peuvent pas dépasser 10 lettres, et voici un exemple de l'apparence de l'entrée... »

2. L'Expérience : « Casser » les Instructions

Les chercheurs ont pris ces instructions et les ont intentionnellement « mutées » de trois manières pour voir ce qui se passerait :

Vaguité (LV) : Ils ont remplacé des mots spécifiques par des termes vagues (par exemple, changer « trier » par « organiser »).
Sous-spécification (US) : Ils ont supprimé une règle ou une contrainte spécifique (par exemple, retirer une règle sur la taille maximale des nombres).
Mise en forme désordonnée (SF) : Ils ont ajouté des fautes de frappe ou modifié les espacements.

3. Les Résultats Surprenants

Les résultats ont été très différents selon l'« examen » que l'IA a passé :

Sur l'Examen « Flashcards » : Lorsque les chercheurs ont retiré des détails ou rendu les mots vagues, les performances de l'IA se sont effondrées. Tout comme un élève qui panique lorsqu'un enseignant retire un indice d'un court quiz, l'IA s'est perdue et a écrit du code défectueux.
Sur l'Examen « Manuel Scolaire » : Lorsqu'ils ont fait la même chose, les performances de l'IA sont restées stables ou, surprenamment, se sont améliorées.

L'Illusion du « Zéro Net » :
Au début, les chercheurs pensaient que l'IA sur l'« examen Manuel Scolaire » ne se souciait tout simplement pas des changements. Mais en regardant de plus près, ils ont découvert une lutte d'influence.

Certains changements ont fait échouer l'IA (dégradation).
Mais un nombre presque égal de changements ont permis à l'IA de réussir là où elle avait précédemment échoué (amélioration).
Ces deux forces s'annulaient mutuellement, donnant l'impression que rien ne s'était produit.

4. Pourquoi « Moins » Signifie Parfois « Plus » ?

Le document a trouvé une raison fascinante pour laquelle retirer une règle corrige parfois le code. Il s'agit de mauvaises habitudes et de « signaux ».

Imaginez que l'IA est comme un élève qui a mémorisé des réponses à partir d'un manuel spécifique.

Le Piège : Parfois, un mot spécifique ou un nombre spécifique dans le prompt agit comme un « déclencheur ». Il rappelle à l'IA une solution mémorisée qui semble juste mais est en fait incorrecte pour ce problème spécifique.
- Exemple tiré du document : Un problème mentionnait « Devise ». Ce mot a déclenché chez l'IA la pensée des taux de change financiers, l'amenant à utiliser un algorithme de raisonnement inversé.
La Correction : Lorsque les chercheurs ont retiré le mot « Devise » et l'ont remplacé par un mot vague comme « Ressource », l'IA a cessé de déclencher sa « mémoire financière ». Au lieu de cela, elle a été forcée de réfléchir réellement à la structure du problème à partir de zéro. Cela a conduit à une solution correcte.

Autrement dit, les détails supplémentaires dans le prompt ont parfois accidentellement donné à l'IA un « indice » qui l'a menée sur la mauvaise voie. Retirer cet indice a forcé l'IA à faire le travail correctement.

5. La Conclusion Principale

Le document conclut que la robustesse ne dépend pas de la taille de l'IA (qu'il s'agisse d'un petit ou d'un géant modèle) ; elle dépend de la manière dont les instructions sont construites.

Si vous donnez à une IA un prompt court, d'une seule phrase, il est très fragile. Si vous modifiez la formulation, elle échoue.
Si vous donnez à une IA un prompt riche et multicouche (avec des exemples, des contraintes et des formats), elle est beaucoup plus robuste. Elle dispose de « signaux de secours » sur lesquels s'appuyer si une partie de l'instruction est confuse.
Crucialement : Parfois, être trop spécifique est un piège. Des mots ou des nombres spécifiques peuvent accidentellement « amorcer » l'IA pour qu'elle utilise un raccourci mémorisé mais incorrect. Retirer ces signaux spécifiques peut parfois forcer l'IA à résoudre le problème correctement.

En bref : Ne supposez pas qu'un prompt parfait et détaillé est toujours le meilleur. Parfois, un prompt légèrement plus vague force l'IA à réfléchir par elle-même, évitant ainsi les pièges de ses propres habitudes mémorisées.

1. Énoncé du problème

Bien que les modèles de langage de grande taille (LLM) soient de plus en plus utilisés pour la génération de code, la justesse de leur sortie est hautement sensible à la formulation des invites. Les recherches antérieures ont établi que la sous-spécification (absence ou affaiblissement des exigences) et les perturbations mineures des invites dégradent généralement les performances. Cependant, ces conclusions sont largement dérivées de benchmarks à spécification minimale (par exemple, HumanEval, MBPP) qui présentent de courtes descriptions à une seule ligne de documentation, avec une redondance structurelle limitée.

Les auteurs émettent l'hypothèse que ces benchmarks exagèrent la fragilité des LLM. Dans des scénarios réels, les tâches incluent souvent des spécifications riches et multi-couches (descriptions, contraintes, formats d'E/S, exemples). L'article examine si les effets négatifs de la sous-spécification persistent dans des environnements structurellement riches et si, contre-intuitivement, la suppression d'éléments spécifiques de l'invite pourrait en réalité améliorer la justesse du code en perturbant les indices de récupération trompeurs.

2. Méthodologie

Benchmarks

L'étude oppose deux benchmarks aux propriétés structurelles distinctes :

HumanEval (HE) : 164 problèmes Python simples avec de courtes lignes de documentation. Manque de contraintes séparées, d'E/S structurées ou d'exemples. Représente la « spécification minimale ».
LiveCodeBench (LCB) : 1 055 problèmes de programmation compétitive (LeetCode, Codeforces, AtCoder) comportant des descriptions en prose complète, des contraintes explicites, plusieurs paires d'exemples d'E/S et des spécifications de format. Représente la « spécification riche ».

Modèles

L'étude évalue 10 LLM répartis en trois catégories :

Open-Source de petite taille (6–7B) : CodeLlama-7B, DeepSeek-Coder-6.7B, Qwen2.5-Coder-7B.
Open-Source de grande taille (15–34B) : StarCoder2-15B, Codestral-22B, CodeLlama-34B, DeepSeek-Coder-33B, Qwen2.5-Coder-32B.
Propriétaires/Raisonnement : GPT-5-mini, Claude Sonnet 4.

Mutations des invites

Les auteurs ont généré systématiquement 3 651 invites mutées en utilisant trois types de transformations :

Vaguité lexicale (LV) : Remplacement de termes ou d'identifiants précis par des synonymes plus larges (par exemple, « trier » $\to$ « organiser », délimiteur $\to$ remplissage).
Sous-spécification (US) : Suppression d'une seule contrainte explicite (par exemple, bornes de valeurs, règles de tri, descriptions de cas limites) tout en maintenant la validité grammaticale de l'invite.
Syntaxe et mise en forme (SF) : Introduction de bruit de surface (fautes de frappe, erreurs d'indentation, problèmes de délimiteurs) sans altérer la sémantique.

Métriques d'évaluation

Pass@1 : La métrique principale pour la justesse.
Analyse des transitions : Suivi des transitions Pass $\to$ Échec (dégradation) et Échec $\to$ Pass (amélioration) pour distinguer la dégradation uniforme des forces opposées.
Analyse de l'attention : Examen des schémas d'attention du modèle pour comprendre quelles régions de l'invite guident les décisions.
Analyse des causes racines : Inspection manuelle des cas où les mutations ont amélioré la justesse pour identifier les mécanismes linguistiques.

3. Contributions et résultats clés

Résultat 1 : La robustesse est structurelle, non architecturale

HumanEval : Tous les types de mutations ont provoqué des baisses de performances significatives (par exemple, les mutations US ont causé une baisse moyenne de -11,8 %).
LiveCodeBench : Les mêmes mutations ont entraîné un impact net quasi nul (par exemple, les mutations US n'ont causé qu'une baisse de -0,9 %).
Conclusion : La robustesse n'est pas une propriété intrinsèque de la taille ou de l'architecture du modèle. Elle est régie par la structure de l'invite. Les spécifications riches fournissent une redondance (contraintes, exemples, E/S) qui agit comme des signaux de repli lorsque des parties de l'invite sont dégradées. Les cartes d'attention confirment que les modèles sur LCB s'appuient fortement sur ces composants auxiliaires, tandis que les modèles sur HE s'appuient presque exclusivement sur la description.

Résultat 2 : La sous-spécification peut améliorer la justesse

Contrairement à l'hypothèse selon laquelle « plus de spécification est toujours mieux », l'étude a révélé que la sous-spécification améliore souvent la justesse du code sur LCB.

Sur LCB, le ratio de transitions Échec $\to$ Pass par rapport aux transitions Pass $\to$ Échec était presque de 1:1 (0,99) pour les mutations LV, ce qui signifie que les améliorations annulaient les dégradations.
Sur HumanEval, les dégradations dominaient largement (Ratio 0,40).
Améliorations constantes : L'étude a identifié 47 tâches LCB spécifiques où la suppression de contraintes ou de vague a systématiquement amélioré les taux de réussite sur plusieurs modèles.

Résultat 3 : Mécanismes d'amélioration (Perturbation des indices de récupération)

L'analyse manuelle a révélé que les invites originales contiennent souvent des « indices de récupération » qui ancrent les modèles sur des solutions mémorisées mais incorrectes. La sous-spécification perturbe ces indices, forçant le modèle à raisonner à partir de la structure du problème.

Vaguité lexicale (LV) :
- Renommage de variables : Briser les associations surajustées (par exemple, renommer s en seq empêche la récupération d'un algorithme spécifique erroné).
- Généralisation terminologique : Remplacer des noms spécifiques au domaine (par exemple, « devise ») par des termes génériques (par exemple, « ressource ») empêche le modèle d'appliquer des heuristiques spécifiques au domaine (comme des balayages financiers inversés) et encourage un raisonnement algorithmique général (comme la programmation dynamique vers l'avant).
Sous-spécification (US) :
- Suppression de contraintes : Des contraintes spécifiques (par exemple, $C_i \le 10^9$ ) préparent souvent les modèles à utiliser des raccourcis optimisés (par exemple, formules de diamètre de graphe étoile) qui échouent sur des cas généraux. Supprimer la contrainte force le modèle à utiliser un algorithme général et correct (par exemple, deux-BFS).
- Amorçage des E/S : Les contraintes déclenchent parfois des modèles d'analyse d'entrée incorrects (par exemple, input().split() style LeetCode vs formats stdin de programmation compétitive). Les supprimer force une analyse correcte.

4. Importance et implications

Réévaluation des benchmarks : Les benchmarks minimaux comme HumanEval peuvent surestimer la fragilité des LLM car ils manquent de la redondance présente dans les tâches réelles. Ils ne parviennent pas à capturer l'« effet d'annulation » où la richesse structurelle atténue les erreurs d'invite.
Ingénierie des invites : L'étude remet en question le dogme selon lequel les invites doivent être maximales en précision. Dans certains cas, la sur-spécification (incluant spécifiquement des contraintes trompeuses ou des identifiants spécifiques au domaine) induit silencieusement les modèles en erreur. Les praticiens doivent être conscients que la suppression de certains indices peut parfois produire de meilleurs résultats.
Développement de modèles : La sensibilité aux indices de récupération indique un fossé de généralisation que l'échelle du modèle seule ne résout pas. Même les modèles de raisonnement les plus avancés (GPT-5, Claude) tombent victimes de ces indices, suggérant la nécessité de stratégies d'entraînement privilégiant le raisonnement structurel plutôt que la correspondance de motifs.
Recherche future : L'article appelle à des benchmarks reflétant la richesse structurelle du développement réel et encourage l'investigation des déclencheurs linguistiques spécifiques qui causent les échecs basés sur la récupération.

Résumé

Cette étude exploratoire démontre que l'impact de la sous-spécification des invites n'est pas uniforme. Si elle dégrade les performances sur les benchmarks minimaux, les spécifications riches dans les tâches réelles fournissent une redondance qui neutralise ces effets. De manière surprenante, la sous-spécification peut améliorer la justesse du code en perturbant les indices de récupération trompeurs qui amènent les modèles à s'appuyer sur des motifs mémorisés et incorrects. Les auteurs concluent que la robustesse est une fonction de la structure de l'invite, et que « moins c'est plus » dans des contextes spécifiques où la précision déclenche un surajustement.