En bref : l’ingénierie de contexte est la pratique consistant à décider ce qui entre dans la fenêtre de contexte d’un modèle, dans quel ordre et à quel coût, plutôt que de décider seulement comment formuler la demande. Elle est devenue la compétence déterminante parce que les données d’évaluation se sont retournées nettement contre l’hypothèse selon laquelle une grande fenêtre de contexte serait une fenêtre utilisable. L’évaluation NoLiMa, publiée à ICML 2025, a testé treize modèles annonçant tous au moins 128 000 jetons et a constaté que onze d’entre eux tombaient sous cinquante pour cent de leur propre référence en contexte court dès 32 000 jetons, GPT-4o passant de 99,3 pour cent à 69,7 pour cent. Des chercheurs d’IBM ont mesuré une dégradation de l’appel de fonctions de 7 à 85 pour cent à mesure que les catalogues d’outils s’étoffent, de 7 à 91 pour cent à mesure que les sorties d’outils s’allongent, et de 13 à 40 pour cent à mesure que les conversations s’étirent. Les travaux fondateurs publiés dans TACL sur les contextes longs ont montré que les modèles récupèrent bien au début et à la fin d’une entrée, et mal au milieu. Ensemble, ils disent la même chose : l’attention est une ressource rare que l’on alloue, pas un contenant gratuit que l’on remplit. Ce guide fournit le tableau de dégradation mesurée, un ratio dérivé entre taille annoncée et point de dégradation, un budget de contexte en cinq parties et un audit pratique. Une dirigeante alloue délibérément un capital rare ; une étudiante remesure quand le modèle suivant arrive.
Pendant environ trois ans, l’histoire que nous nous racontions sur le travail avec les modèles de langage était une histoire de formulation. Si la sortie était mauvaise, le prompt était mauvais. Ajoutez un rôle. Ajoutez des exemples. Demandez-lui de réfléchir étape par étape. Dites : vous êtes experte. Tout un genre de conseils s’est développé autour de l’idée que la capacité était dans le modèle et que le prompt était la clé qui la débloquait.
Cette histoire n’était pas exactement fausse, mais elle est devenue une petite partie d’un problème bien plus vaste, et ce déplacement a une cause précise. Les modèles ont obtenu de longues fenêtres de contexte. Puis on les a remplies. Puis les résultats se sont dégradés d’une manière qu’aucune reformulation ne corrigeait, et le domaine a dû développer un vocabulaire pour ce qui se passait réellement.
Ce vocabulaire, c’est l’ingénierie de contexte, et ce qui compte n’est pas que ce soit un terme à la mode. C’est que la défaillance qu’elle traite est mesurée, publiée et importante.
La définition, énoncée précisément
L’ingénierie de prompt demande : comment formuler l’instruction pour que le modèle fasse la bonne chose ?
L’ingénierie de contexte pose une question différente et strictement plus large : quel est le plus petit ensemble d’informations à fort signal dont le modèle a besoin dans sa fenêtre pour bien faire cela, et comment y placer exactement cela et rien d’autre ?
La distinction se voit le plus facilement dans ce que chacune contrôle. L’ingénierie de prompt contrôle un composant de la fenêtre : l’instruction. L’ingénierie de contexte contrôle toute la fenêtre, qui dans tout système réel contient au moins cinq occupants concurrents : les instructions système, les définitions d’outils et de fonctions, les documents ou connaissances récupérés, l’historique de conversation et la sortie accumulée des appels d’outils et actions précédents.
Ce recadrage compte parce que l’instruction est généralement la plus petite de ces cinq, d’un ordre de grandeur, et la seule que la plupart des gens touchent. Si votre système échoue et que vous modifiez encore la formulation du prompt, vous optimisez une erreur d’arrondi.
L’ingénierie de contexte ne remplace pas l’ingénierie de prompt au sens de la rendre obsolète. Elle l’englobe. La formulation est un levier au sein d’un problème d’allocation plus vaste, de la même façon que la tarification est un levier au sein de la conduite d’une entreprise. Quiconque a examiné pourquoi l’ingénierie de prompt ne suffit pas reconnaîtra la forme : la compétence qui semblait être tout le métier se révèle une couche d’un empilement.
Pourquoi la fenêtre n’est pas ce qui est écrit sur l’étiquette
Voici les données qui ont imposé ce déplacement, et elles méritent une lecture attentive, car les chiffres sont plus sévères que ne le suggère le discours général.
Le premier résultat est fondateur. La recherche publiée dans les Transactions of the Association for Computational Linguistics sur la manière dont les modèles de langage utilisent les contextes longs a trouvé une courbe de performance en U cohérente sur la question-réponse multidocument et la récupération clé-valeur. La performance était maximale lorsque l’information pertinente apparaissait au début ou à la fin de l’entrée, et se dégradait nettement lorsque le modèle devait la trouver au milieu. La position dans la fenêtre n’est pas neutre. L’endroit où vous placez quelque chose change la capacité du modèle à s’en servir.
Le deuxième résultat devrait changer vos réglages par défaut. L’évaluation NoLiMa, publiée à ICML 2025, a été conçue pour combler une faille du test classique de l’aiguille dans une botte de foin. Dans ce test, le fait caché partage généralement un vocabulaire évident avec la question, si bien qu’un modèle peut réussir par simple correspondance littérale sans raisonner véritablement sur le contexte. NoLiMa a supprimé cette béquille en construisant questions et faits cibles avec un recouvrement lexical minimal, forçant le modèle à inférer l’association.
Les résultats sur treize modèles annonçant tous au moins 128 000 jetons : la performance était solide sous 1 000 jetons, et onze des treize tombaient sous cinquante pour cent de leur propre référence en contexte court dès 32 000 jetons. GPT-4o, parmi les plus performants, est passé de 99,3 pour cent de précision de référence à 69,7 pour cent en longueur étendue.
Le troisième résultat déplace cela de la récupération vers les flux agentiques qui composent aujourd’hui l’essentiel de l’usage professionnel. Des chercheurs d’IBM ont introduit LongFuncEval pour mesurer la qualité de l’appel de fonctions des modèles à long contexte quand le contexte grandit, et ont rapporté trois courbes de dégradation distinctes : une baisse de performance de 7 à 85 pour cent à mesure que le catalogue d’outils s’étoffe, une dégradation de 7 à 91 pour cent de la récupération de réponse à mesure que les réponses d’outils s’allongent, et une dégradation de 13 à 40 pour cent à mesure que les conversations multitours s’étirent.
Tableau 1 : dégradation mesurée en contexte long (sources vérifiées)
| Étude | Ce qui a été mesuré | Dégradation mesurée |
|---|---|---|
| Lost in the Middle, Transactions of the ACL | Position de l’information pertinente dans le contexte | Courbe en U : maximale au début et à la fin de l’entrée, nettement dégradée au milieu |
| NoLiMa, ICML 2025 | Récupération associative sans recouvrement lexical, 13 modèles annonçant 128K ou plus | 11 modèles sur 13 sous 50 pour cent de leur référence en contexte court à 32 000 jetons ; GPT-4o de 99,3 à 69,7 pour cent |
| LongFuncEval, IBM Research | Appel de fonctions à mesure que le contexte grandit | Baisse de 7 à 85 pour cent avec l’étoffement du catalogue d’outils ; baisse de 7 à 91 pour cent de la récupération de réponse avec l’allongement des sorties d’outils ; baisse de 13 à 40 pour cent avec l’allongement des conversations |
Trois groupes de recherche indépendants, trois familles de tâches différentes, une conclusion cohérente. La capacité à accepter des jetons et la capacité à les utiliser sont des propriétés distinctes, et l’écart entre les deux est l’endroit où vit l’essentiel des défaillances réelles.
Ce que valent réellement les chiffres annoncés
Le chiffre marketing et le chiffre de travail ne sont pas le même, et il est utile de rendre le rapport explicite. Le calcul ci-dessous est un ratio dérivé par CEOtudent, non une mesure : il prend le point où NoLiMa a observé la plupart des modèles passer sous la moitié de leur référence et l’exprime comme une fraction de la fenêtre annoncée par chaque modèle.
Tableau 2 : fenêtre annoncée face au point de division par deux observé (cadre éditorial CEOtudent, dérivé de NoLiMa)
| Fenêtre de contexte annoncée | Point de division par deux observé chez la plupart des modèles testés | Rapport entre ce point et la fenêtre annoncée |
|---|---|---|
| 128 000 jetons | 32 000 jetons | 25,0 pour cent |
| 200 000 jetons | 32 000 jetons | 16,0 pour cent |
| 1 000 000 jetons | 32 000 jetons | 3,2 pour cent |
Lisez la méthode avant les chiffres. Les 32 000 jetons correspondent au point où onze des treize modèles de NoLiMa étaient tombés sous la moitié de leur propre référence en contexte court, sur une tâche de récupération associative conçue pour être difficile. Ce n’est pas une falaise universelle, cela ne se transpose pas à tout type de tâche, et un modèle qui échoue à ce test à 32 000 jetons peut encore accomplir un travail utile de correspondance littérale bien au-delà. Ce que le ratio établit, c’est la direction et l’ordre de grandeur de la décote à appliquer quand un fournisseur annonce une taille de fenêtre. Traiter une fenêtre annoncée d’un million de jetons comme un million de jetons utilisables n’est pas une petite erreur : c’est une erreur d’un ordre de grandeur sur la classe de tâches la plus difficile.
L’implication comportementale est simple et un peu contre-intuitive : ajouter du contexte à un système en difficulté est généralement le mauvais geste. Au-delà d’un seuil qui arrive bien plus tôt que l’étiquette ne le suggère, les jetons supplémentaires diluent au lieu d’informer.
Le budget de contexte en cinq parties
Si l’attention est rare, alors tout ce qui se trouve dans la fenêtre la dépense. Voici le cadre que nous utilisons pour auditer cette dépense. Chaque ligne nomme un occupant de la fenêtre, la défaillance documentée précise qu’il entraîne, et le geste d’ingénierie qui y répond.
Tableau 3 : le budget de contexte (cadre éditorial CEOtudent)
| Occupant de la fenêtre | Part typique du problème | Défaillance documentée qu’il entraîne | Le geste |
|---|---|---|---|
| Instructions système | Petites en jetons, grandes en effet | Règles contradictoires ou périmées qui écrasent silencieusement votre demande | Rester bref, retirer les règles obsolètes, énoncer explicitement la priorité |
| Définitions d’outils et de fonctions | Grandit silencieusement à chaque capacité ajoutée | LongFuncEval : 7 à 85 pour cent de dégradation quand le catalogue s’étoffe | N’exposer que les outils pertinents pour cette tâche, pas tout le catalogue |
| Documents récupérés | Généralement le plus gros occupant | Lost in the Middle : le matériau enterré au milieu du contexte est mal récupéré | Récupérer moins, classer plus durement, placer le décisif au début ou à la fin |
| Historique de conversation | Grandit de façon monotone jusqu’à intervention | LongFuncEval : 13 à 40 pour cent de dégradation à mesure que les tours s’accumulent | Résumer et redémarrer délibérément plutôt que laisser les fils courir indéfiniment |
| Sortie d’outils accumulée | L’invisible ; celui qui grandit le plus vite dans les flux agentiques | LongFuncEval : 7 à 91 pour cent de dégradation quand les réponses d’outils s’allongent | Tronquer et résumer les retours d’outils avant qu’ils ne rentrent dans la fenêtre |
La cinquième ligne est l’endroit où la plupart des gens perdent sans le savoir. Dans un flux agentique, chaque appel d’outil renvoie quelque chose, et ce quelque chose reste dans la fenêtre à chaque tour suivant. Une poignée de réponses verbeuses peut consommer plus de budget que toute la description de la tâche, et rien dans l’interface ne vous dit que c’est arrivé. Si vous déléguez du travail en plusieurs étapes à des systèmes d’IA, c’est la chose la plus utile à instrumenter, et cela rejoint directement les concepts de notre guide sur ce qu’il faut comprendre avant de déléguer du travail à des agents d’IA.
Un audit pratique à mener cette semaine
Vous n’avez pas besoin d’infrastructure pour commencer. Vous avez besoin de l’habitude de demander ce qui est dans la fenêtre et si cela mérite sa place.
Question un : qu’y a-t-il réellement dedans ? La plupart des gens ne savent pas y répondre pour leurs propres flux. Listez les cinq occupants pour une tâche que vous exécutez régulièrement et estimez la part de chacun. Que l’estimation soit grossière n’a pas d’importance ; découvrir que les documents récupérés ou l’historique d’outils dominent constitue généralement toute la découverte.
Question deux : que retirerais-je si la fenêtre faisait un dixième de sa taille ? C’est la fonction contraignante. Elle identifie de façon fiable le matériau présent par habitude plutôt que par nécessité. Dans la plupart des configurations en service, une large part de ce qui occupe la fenêtre s’y trouve parce que personne ne l’a retiré, non parce que quelqu’un a décidé qu’elle devait y être.
Question trois : où se trouve l’information décisive ? Compte tenu de la courbe en U documentée dans les travaux TACL, le matériau enterré au milieu d’une longue entrée est le moins susceptible d’être utilisé. Déplacez ce dont dépend la réponse vers le début ou la fin, et vérifiez si la sortie change. C’est souvent le cas, et c’est une réplication bon marché et autonome d’un effet publié.
Question quatre : cette défaillance est-elle un problème de formulation ou de contexte ? Le diagnostic est simple. Si le modèle produit une réponse assurée mais fausse sur les faits que vous avez fournis, c’est un problème de contexte : le matériau était présent mais non utilisé, ou absent alors que vous le croyiez là. Si le modèle produit les bons faits sous la mauvaise forme, c’est un problème de formulation. Les deux se ressemblent de l’extérieur et appellent des correctifs entièrement différents, et se tourner vers le prompt quand la faute est dans le contexte est l’heure perdue la plus courante de ce métier.
Question cinq : quand ai-je remesuré pour la dernière fois ? Chaque chiffre de cet article est attaché à une génération de modèles précise. Les résultats NoLiMa décrivent les modèles testés en 2025. Les courbes LongFuncEval décrivent les systèmes disponibles à la rédaction de l’article. Chaque nouvelle génération déplace ces frontières, généralement dans le bon sens, et aucune n’a encore comblé l’écart entre capacité annoncée et capacité utilisable. Prendre l’habitude de vérifier est plus durable que mémoriser un seuil quelconque, ce qui est exactement l’argument que nous défendons à propos de la compétence à juger les sorties d’IA.
Pourquoi c’est une véritable compétence et non un changement de nom
Une objection raisonnable existe : l’ingénierie de contexte serait l’ingénierie de prompt sous un nom plus impressionnant, inventé parce que l’ancien commençait à sonner peu sérieux.
L’objection échoue à un test précis. Les deux disciplines se distinguent par ce qu’elles peuvent et ne peuvent pas corriger, et la frontière est nette. Aucune reformulation d’une instruction ne répare un fait récupéré mais placé au beau milieu d’une entrée de 60 000 jetons. Aucun jeu de rôle ni cadrage étape par étape ne récupère un appel de fonction ayant échoué parce que quarante définitions d’outils étaient chargées alors que quatre étaient pertinentes. Ce sont des défaillances structurelles dans la composition de la fenêtre, et elles ne se traitent qu’en changeant cette composition.
C’est la marque d’une discipline réelle plutôt que d’un changement de nom : elle a ses propres modes de défaillance, ses propres diagnostics et ses propres correctifs, dont aucun n’est atteignable depuis la pratique dont elle est issue.
La littérature académique a déjà tranché de la même façon. Une synthèse sur l’ingénierie de contexte pour les grands modèles de langage, publiée en juillet 2025 après l’analyse systématique de plus de 1 400 articles de recherche, la traite explicitement comme une discipline formelle allant au-delà de la conception de prompts, et la décompose en trois composants fondamentaux : récupération et génération de contexte, traitement du contexte et gestion du contexte. Ces trois correspondent presque exactement au budget pratique ci-dessus, signe rassurant que le cadre décrit quelque chose de réel plutôt qu’inventé pour un titre.
Il vaut aussi la peine d’être honnête sur les personnes concernées. Si votre usage de l’IA se résume à des demandes conversationnelles ponctuelles, la formulation constitue vraiment l’essentiel de votre levier et l’ingénierie de contexte reste largement théorique. Dès que vous construisez quelque chose de persistant, c’est-à-dire un flux qui récupère des documents, appelle des outils ou s’étend sur de nombreux tours, la balance bascule fortement, et elle bascule sans s’annoncer. Comprendre comment fonctionnent réellement les modèles de langage rend la raison évidente : la fenêtre est le monde entier du modèle pendant la durée d’une requête, et tout ce qui s’y trouve rivalise pour la même attention finie.
La dirigeante et l’étudiante
Le cadrage de dirigeante rend cela immédiatement intuitif. Le contexte est un budget. Il a un plafond dur, la valeur marginale de ce que vous y mettez décline bien plus vite que le plafond ne le suggère, et tout ajout évince autre chose. Personne ne dirigerait une entreprise en dépensant chaque unité de capital disponible simplement parce qu’elle est disponible. C’est pourtant exactement ce à quoi ressemble le fait de remplir une fenêtre de contexte.
Le cadrage d’étudiante fournit la discipline dont ce budget a besoin. Chaque seuil cité ici est un instantané d’un système mouvant. La bonne réponse à un chiffre publié n’est pas de le mémoriser mais d’apprendre le test qui l’a produit, afin qu’à l’arrivée de la génération suivante vous puissiez découvrir où se situe la nouvelle frontière au lieu de deviner. NoLiMa existe parce que quelqu’un a remarqué que le test standard comportait une faille et en a construit un plus dur. Cet instinct, vérifier si la mesure mesure vraiment ce qu’elle prétend, est la partie transférable.
Les personnes qui réussiront le mieux avec ces systèmes dans les années à venir ne seront pas celles qui ont les prompts les mieux formulés. Ce seront celles qui savent, à tout moment, ce qui est dans la fenêtre et pourquoi.
Questions fréquentes
Quelle est la différence entre ingénierie de contexte et ingénierie de prompt en une phrase ?
L’ingénierie de prompt optimise l’instruction ; l’ingénierie de contexte optimise tout ce qui se trouve dans la fenêtre du modèle, dont l’instruction est généralement la plus petite part.
Une fenêtre de contexte plus grande résout-elle le problème ?
Pas de façon fiable. L’évaluation NoLiMa a testé treize modèles annonçant tous au moins 128 000 jetons et en a trouvé onze sous la moitié de leur référence en contexte court à 32 000 jetons. La capacité à accepter des jetons n’est pas la même propriété que la capacité à les utiliser.
L’ingénierie de prompt est-elle morte ?
Non. C’est un composant plutôt que la discipline entière. La formulation compte encore pour les tâches conversationnelles à un tour, et elle reste le bon premier diagnostic quand le modèle produit des faits corrects dans le mauvais format.
Quelle est l’amélioration la plus rapide possible ?
Réduisez ce qui est dans la fenêtre et déplacez le matériau décisif vers le début ou la fin. L’effet de position en U documenté dans les travaux TACL se réplique en quelques minutes sur vos propres tâches, et le résultat surprend généralement.
Pourquoi les flux agentiques se dégradent-ils plus vite que le dialogue ?
Parce qu’ils accumulent deux occupants que le dialogue n’a pas : les définitions d’outils et les sorties d’outils. Les mesures LongFuncEval d’IBM situent la dégradation à 7 à 85 pour cent avec l’étoffement du catalogue et 7 à 91 pour cent avec l’allongement des réponses d’outils, en plus des 13 à 40 pour cent dus à la seule longueur de conversation.
Ai-je besoin d’outils spécifiques pour pratiquer cela ?
Non. Les cinq questions d’audit de cet article n’exigent rien d’autre que de l’attention à ce que vous envoyez. L’outillage aide à grande échelle, mais le plus grand gain unitaire, retirer le matériau présent dans la fenêtre par habitude plutôt que par nécessité, est immédiatement accessible à tout le monde.
Sources
- Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni et Liang, Lost in the Middle: How Language Models Use Long Contexts, Transactions of the Association for Computational Linguistics
- Modarressi, Deilamsalehy, Dernoncourt, Bui, Rossi, Yoon et Schütze, NoLiMa: Long-Context Evaluation Beyond Literal Matching, International Conference on Machine Learning, 2025
- Kate, Pedapati, Basu, Rizk, Chenthamarakshan, Chaudhury, Agarwal et Abdelaziz, LongFuncEval: Measuring the Effectiveness of Long Context Models for Function Calling, IBM Research, 2025
- Mei, Yao, Ge, Wang, Bi, Cai et collègues, A Survey of Context Engineering for Large Language Models, juillet 2025
Ce contenu a été compilé avec le soutien de l’IA à la suite d’une recherche approfondie, puis rédigé et préparé pour publication par l’équipe éditoriale de CEOtudent.
This post is also available in:
