LLMs en prod : pourquoi un prompt de 8 mots a battu tous les autres

J’avais un besoin simple : obtenir le meilleur score possible sur une tâche d’évaluation linguistique. Un jeu de données annoté par des humains, 700 textes, et de quoi tester plusieurs prompts dans les mêmes conditions.

J’ai fait ce qu’on fait tous. J’ai commencé par un prompt élaboré, structuré, conforme aux bonnes pratiques. Puis j’ai testé des variantes. Et le résultat m’a surpris : un prompt de huit mots a battu un prompt conçu par 21 chercheurs.

J’ai d’abord pensé à une anomalie. Puis j’ai cherché dans la littérature, et j’ai découvert que ce résultat avait un nom : l’instruction dilution. Un phénomène documenté, qui touche tous les modèles de langage. L’idée est simple et un peu contre-intuitive : quand on ajoute des informations à un prompt, même correctes, même pertinentes, les performances peuvent se dégrader. Non pas parce que les informations sont fausses, mais parce qu’elles diluent le signal utile dans du bruit.

Ce qui suit, c’est ce que la recherche récente nous apprend sur ce phénomène, illustré par mon expérience sur ces 700 textes.

L’expérience : 700 textes, 4 prompts

Le contexte : évaluation automatique du niveau de langue d’apprenants en anglais, selon le référentiel CECRL (les six niveaux A1 à C2). Le modèle testé : GPT-4.1. Le corpus : 700 expressions écrites, chacune évaluée par trois examinateurs humains certifiés.

On a construit quatre prompts. Du plus élaboré au plus minimaliste.

Les résultats

P3 gagne, et d’assez loin. Il bat le prompt académique de 8 points, le prompt few-shot de 15 points, et sa propre version enrichie de 12 points.

Ce dernier écart est celui qui m’a le plus intrigué. Entre P3 et P4, on a seulement ajouté deux informations que GPT-4.1 possède déjà : le fait que l’apprenant étudie l’anglais, et la liste des niveaux CECRL. En les répétant, on ne l’a pas aidé. On l’a gêné.

Pourquoi ajouter de l’information dégrade les résultats

Cet écart de 12 points entre P3 et P4 s’explique par ce que la littérature appelle l’information dilution : quand on reformule ce que le modèle sait déjà, on dilue le signal utile dans du bruit.

Le mécanisme n’est pas mystérieux. L’attention des transformers alloue une capacité finie à chaque passe. Quand une partie de cette capacité est consommée par des informations redondantes, même correctes, il en reste moins pour la tâche elle-même. L’attention ne disparaît pas : elle se disperse sur des tokens non informatifs. Jiang et al. (2024) parlent de “reduced perceptual ability due to the limited context window” : la fenêtre de contexte est une ressource finie, et chaque token consommé par du bruit est un token en moins pour le signal.

GPT-4.1 connaît le CECRL. Il a été entraîné sur des données massives d’évaluation linguistique. Quand on lui demande en une phrase d’évaluer selon le CECRL, il active exactement ce qu’il faut. Quand on lui fournit des exemples et des instructions détaillées, aussi bien formulés soient-ils, on lui propose une reformulation de ce qu’il sait déjà. Et cette reformulation crée une friction. C’est pour ça que P1, le prompt le plus élaboré, termine dernier.

La question qui se pose alors : à quel point ce phénomène est-il systématique ? Et que se passe-t-il quand on pousse les modèles au-delà de quelques instructions ?

Trois profils de dégradation

Le benchmark IFScale (Jaroslawicz et al., 2025) a testé 20 modèles sur des tâches comportant de 10 à 500 instructions simultanées. Les résultats révèlent trois profils de dégradation distincts.

Les modèles de raisonnement comme o3 ou gemini-2.5-pro suivent un profil à seuil : les performances restent quasi parfaites jusqu’à 150 ou 250 instructions, puis chutent brutalement. Gemini-2.5-pro passe de 98,4 % à 100 instructions à 68,9 % à 500. Le modèle encaisse, encaisse, puis cède d’un coup.

Les grands modèles généralistes comme gpt-4.1 ou claude-3.7-sonnet se dégradent de façon régulière et prévisible. GPT-4.1 passe de 95,4 % à 48,9 %, claude-3.7-sonnet de 94,8 % à 52,7 %. Chaque instruction ajoutée coûte un peu de performance. C’est le profil le plus actionnable, parce qu’on peut estimer la perte avant de la subir.

Les petits modèles comme claude-3.5-haiku ou llama-4-scout s’effondrent rapidement puis se stabilisent sur un plateau bas, entre 7 et 15 %. Au-delà d’une centaine d’instructions, ajouter ou retirer quoi que ce soit ne change presque plus rien : le modèle a déjà décroché.

La nuance est importante. Les modèles de raisonnement résistent remarquablement bien jusqu’à un point critique. Les généralistes se dégradent graduellement mais de façon gérable. Les petits modèles ne sont tout simplement pas conçus pour les prompts denses. Connaître le profil de dégradation du modèle qu’on utilise, c’est savoir combien d’instructions on peut se permettre.

Omission vs modification : comment les modèles échouent

IFScale révèle aussi quelque chose de plus subtil : les modèles n’échouent pas de la même façon selon la densité d’instructions.

À faible densité, quand un modèle se trompe, il se trompe de peu. Il approxime, il interprète mal une contrainte. C’est ce que les chercheurs appellent une erreur de modification : le modèle a essayé, et il s’est trompé.

À haute densité, le mode d’échec change radicalement. Le modèle ne se trompe plus, il oublie. Les instructions ne sont pas mal interprétées, elles sont purement et simplement ignorées. C’est une erreur d’omission. Et les chiffres sont frappants : à 500 instructions, llama-4-scout présente un ratio omission/modification de 34,88x. Pour chaque erreur d’approximation, 35 instructions sont simplement oubliées. Le modèle ne fait pas de son mieux avec un résultat imparfait. Il abandonne.

Ce basculement a une conséquence directe sur la façon dont on conçoit les prompts. À densité modérée, reformuler ou clarifier une instruction peut aider. À haute densité, ça ne sert à rien, parce que le problème n’est pas que le modèle comprend mal. C’est qu’il ne lit même plus.

Il y a aussi un effet de compétition cognitive qui mérite d’être mentionné. L’attention dépensée sur le suivi des instructions dégrade la qualité de la tâche principale elle-même. IFScale montre que o3, à 500 instructions, produit environ 1 500 tokens de sortie où chaque troisième mot doit être un mot-clé imposé. Le modèle consacre tellement de capacité au respect des contraintes formelles qu’il n’en reste plus assez pour la tâche.

Le lien avec mon expérience est direct. P1 et P2 ajoutent des instructions qui entrent en compétition avec la tâche principale d’évaluation. Même si ces instructions sont correctes, elles consomment de l’attention. P3 laisse toute l’attention au modèle pour ce qui compte vraiment.

Le biais positionnel : Lost in the Middle et au-delà

L’instruction dilution est amplifiée par un autre problème bien documenté : le biais positionnel.

Liu et al. (Stanford, 2023) ont montré que les LLMs présentent un biais d’attention en forme de U. Ils traitent mieux ce qui est au début et à la fin du prompt, et dégradent significativement les informations placées au milieu. C’est le phénomène Lost in the Middle, et il touche même les modèles explicitement entraînés pour les longs contextes.

IFScale apporte une nuance inattendue sur la tendance du modèle à favoriser les premières instructions, ce qu’on appelle le biais de primauté. Ce biais suit une courbe non linéaire. À faible densité, en dessous de 100 instructions, il est faible : le modèle traite les instructions de façon relativement uniforme. À densité modérée, entre 150 et 200 instructions, il atteint un pic. Le modèle devient sélectif et favorise les premières instructions aux dépens des suivantes. Au-delà de 300 instructions, le biais converge vers un niveau bas, non pas parce que le modèle est redevenu équitable, mais parce qu’il passe en mode « échec uniforme » : il ignore les instructions de façon homogène, quelle que soit leur position.

En pratique, sur des prompts de longueur modérée (le cas le plus courant en production), la position compte énormément. Ce qui est au début cadre la tâche. Ce qui est à la fin agit comme dernière instruction avant la génération. Ce qui est au milieu est le plus vulnérable à l’oubli. Et c’est une raison de plus de garder les prompts courts : plus le prompt est long, plus le « milieu » est grand, et plus le biais en U est prononcé.

Ce n’est pas toujours le plus court qui gagne

Le message de cet article n’est pas « faites des prompts courts ». C’est qu’au-delà d’un certain seuil, l’ajout d’information devient contre-productif, et ce seuil est plus bas qu’on ne le pense.

Ce seuil dépend de plusieurs choses. D’abord du modèle : les modèles de raisonnement comme o3 ou gemini-2.5-pro résistent beaucoup mieux à la densité d’instructions que les modèles plus petits. Un prompt qui fonctionne sur gpt-4.1 peut s’effondrer sur claude-3.5-haiku.

Ensuite de la tâche. Mon P3 gagne parce que GPT-4.1 connaît déjà le CECRL. Il a été entraîné sur des volumes massifs de données d’évaluation linguistique. Sur un domaine inconnu du modèle, un framework métier propriétaire, un jargon spécialisé non publié, un prompt détaillé reste nécessaire. C’est justement parce que le modèle ne sait pas qu’il faut lui dire.

Et enfin de la nature de l’information ajoutée. Toute la différence est entre information redondante et information nouvelle. Reformuler ce que le modèle sait (les descripteurs CECRL, la liste des niveaux) crée du bruit. Fournir ce que le modèle ne sait pas (un barème propriétaire, des critères métier spécifiques) crée du signal.

En pratique, ça demande de connaître les frontières du modèle, ce qui fait partie de son entraînement et ce qui n’en fait pas partie. Cette frontière est rarement documentée. Elle se découvre en testant.

Prompt compression : compresser plutôt que supprimer

Dans beaucoup de cas d’usage en production (RAG, analyse de documents, contextes longs), on ne peut pas simplement raccourcir le prompt. Le contexte est long parce que le problème l’exige.

La recherche sur la prompt compression offre une alternative intéressante : plutôt que de supprimer de l’information, on la compresse. On élimine le bruit tout en préservant le signal.

La première famille d’approches, dite text-to-text, transforme le texte en un texte plus court, par élagage des tokens non informatifs ou par résumé. LLMLingua-2 de Microsoft atteint des taux de compression de 3 à 6x avec des performances comparables au texte non compressé. Sur NaturalQuestions, le F1 reste à 71,90 avec 3,9x de compression. Sur GSM8K, l’exact match atteint 79,08 à 5x. On divise la taille du contexte par 4 ou 5, et la performance reste quasi identique.

La seconde famille, text-to-vector, encode le texte en représentations vectorielles compactes, ce que la littérature appelle des gist tokens. La technique du gisting atteint jusqu’à 26x de compression avec une perte minimale. L’idée : au lieu de faire lire 10 000 tokens au modèle, on les encode en quelques centaines de vecteurs qui capturent l’essentiel de l’information.

LLM-DCP (Jiang et al., 2024) va plus loin en modélisant la compression comme un processus de décision de Markov. Chaque token est évalué séquentiellement, garder ou supprimer, en fonction de sa contribution à la tâche. Le résultat : 12,9x de compression.

Quand le contexte est long, la question n’est pas « comment raccourcir ? » mais « comment compresser sans perdre le signal ? ». C’est un problème d’ingénierie, pas de rédaction.

Implications pratiques

De tout ça, je retiens quelques principes que j’applique maintenant au quotidien.

Le premier, c’est l’atomicité. Une instruction par prompt, formulée en une phrase si possible. Quand une tâche est complexe, je la découpe en étapes plutôt que d’allonger le prompt.

Le second, c’est la position. L’instruction principale va au début, les contraintes critiques à la fin, le contexte et les exemples au milieu, en sachant qu’ils seront moins bien retenus.

Le troisième, c’est le test sur volume. Un prompt qui fonctionne sur 10 exemples peut s’effondrer sur 700. Les résultats d’IFScale montrent que les profils de dégradation sont prévisibles : il vaut la peine de tester à différentes densités pour trouver le seuil de son modèle.

Et enfin, quand un prompt contient plusieurs contraintes, un rappel en fin de prompt (« assure-toi de respecter toutes les contraintes ci-dessus ») peut réduire le taux d’omission. C’est un palliatif, pas une solution, mais il fonctionne sur les profils de dégradation linéaire.

Conclusion

L’instruction dilution n’est pas une intuition. C’est un phénomène mesurable, reproductible, et la recherche commence à bien le comprendre. Au-delà d’un certain seuil, ajouter de l’information à un prompt dégrade les performances du modèle. Ce seuil dépend du modèle, de la tâche, et de la nature de l’information ajoutée.

Les guides de prompting donnent des techniques. La recherche explique pourquoi certaines marchent et d’autres non. Non pas parce que les guides sont faux, mais parce qu’ils sont écrits pour un contexte, la conversation, qui ne se transfère pas directement à un autre, la production à l’échelle.

Pour écrire des prompts qui fonctionnent à l’échelle, il faut comprendre ce qui se passe dans l’attention du modèle. Savoir ce qu’il sait déjà, ce qu’il ne sait pas, et où se situe le point de basculement. Et ça, ça ne s’apprend que par l’expérimentation. En se trompant sur 700 exemples et en comprenant pourquoi.

Si vous voulez systématiser cette expérimentation, des outils comme promptfoo ou le Playground d’OpenAI permettent de comparer des variantes de prompts sur un jeu de données, de mesurer les régressions entre versions, et de trouver ce fameux seuil de basculement pour chaque modèle.