Chapitre 9 — Gérer le budget d'attention

Neuvième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où une fenêtre de contexte d'un million de tokens se révèle être une valeur plafond plutôt qu'un point de fonctionnement, et où une part remarquable des « le modèle est devenu moins bon » se révèle être « le modèle a été enseveli ».

Pourquoi ce chapitre existe

Une fenêtre de contexte ressemble à de l'espace libre. Elle ne l'est pas. Chaque token qu'un agent lit coûte de la latence, de l'argent, et — moins évidemment mais plus importantement — de la qualité. L'illusion qu'une fenêtre d'un million de tokens signifie « tout faire entrer » est l'une des lectures les plus coûteuses de la pratique actuelle, et elle compte pour une large part des échecs de production diagnostiqués comme des régressions de modèle. Le modèle n'a pas empiré. Il a été enseveli. Ce chapitre traite le contexte comme un budget fini plutôt que comme une ressource libre : ce qui mange le budget, quelles alternatives existent quand le budget est le mauvais outil, et comment se poser dans la zone productive où l'agent a exactement ce qu'il lui faut et rien de plus.

9.1 Context rot et la falaise non linéaire

La relation entre longueur de contexte et qualité n'est pas linéaire. Doubler le prompt ne divise pas la qualité par deux ; passé un point, cela la divise par plus de deux. Le nom technique qui s'est imposé — context rot — est informel mais juste. L'étude classique de Stanford par Liu et collègues a montré que des modèles à qui l'on demande de trouver une information dans une liste de documents performent dramatiquement moins bien quand le document pertinent se trouve au milieu que quand il est à l'une des extrémités. La courbe en U a été reproduite à travers les familles de modèles et les longueurs de contexte. Le milieu d'un long prompt est, en un sens significatif, attentionnellement moins coûteux que les bords, même si l'architecture traite chaque position identiquement.

Les benchmarks « needle in a haystack » devenus standards en 2023 et 2024 ont d'abord paru réfuter cette image — récupération quasi parfaite à 100K, 200K, voire un million de tokens. Les travaux de suivi plus soigneux ont montré que les benchmarks étaient trop faciles. Une aiguille bien visible dans une botte de foin homogène est un problème différent de trouver un fait pertinent enfoui parmi vingt distracteurs thématiquement reliés. MCP-Universe et BIG-Bench-Long, sortis fin 2025, ont intégré cette structure adversariale, et les chiffres font réfléchir : à 100K tokens, les modèles de pointe perdent dix à vingt points par rapport à la même tâche à 8K, et à 500K l'écart peut atteindre quarante.

Il existe une seconde forme de rot, spécifique aux agents MCP. À mesure que les outils s'accumulent dans le prompt système, la précision du modèle pour sélectionner le bon outil se dégrade. MCP-Universe a montré la précision de sélection d'outil tomber d'environ quatre-vingt-dix pour cent avec cinq outils à sous soixante avec quarante. Les praticiens appellent désormais cela tool-loadout rot, et c'est la cause la plus commune de « l'agent est devenu plus bête après l'ajout de capacités ». Le mécanisme est le même dans les deux cas : l'attention est finie, et à mesure que le prompt grandit, la part que reçoit chaque token rétrécit.

9.2 Trois réponses à la même question : MCP, RAG, affinage

Quand un modèle manque de la connaissance dont il a besoin, il y a trois réponses architecturales, et confondre l'une pour l'autre est la cause d'une part remarquable d'effort mal alloué. MCP convient quand la connaissance est opérationnelle — inventaire courant, agenda du jour, statut d'un build. Cela a une source faisant autorité, change continûment, et aucun contexte préchargé ne peut le tenir à jour. Le gain n'est pas que la fraîcheur mais aussi la responsabilité : quand le modèle dit « le build est vert », l'utilisateur peut demander « d'après quoi » et la réponse est « d'après le serveur de build, interrogé à cet instant ».

Le RAG convient quand la connaissance est documentaire — un corpus trop grand pour la fenêtre mais assez stable pour qu'un index de récupération soit faisable. Documents internes, articles de support, contrats, grandes bases de code. Le Volume III de cette série portait entièrement sur l'ingénierie du RAG et reste la référence canonique. L'affinage convient quand l'écart est comportemental — format constant, voix particulière, refus fiable d'une classe de requêtes. La mauvaise allocation qui revient dans l'industrie consiste à utiliser l'affinage pour injecter de la connaissance factuelle qui change, ce qui produit un modèle brièvement impressionnant puis progressivement faux à mesure que le monde dérive de son instantané gelé.

Les trois ne sont pas exclusifs. Un agent mature les combine typiquement : affinage pour le comportement, RAG pour la connaissance documentaire, MCP pour la connaissance opérationnelle. Le cadrage qui aide est le bon substrat pour la bonne exigence de fraîcheur. Le comportement est stable à l'échelle des générations de modèles ; cuisez-le dans les poids. La connaissance documentaire change à l'échelle des jours ; indexez-la. La connaissance opérationnelle change à l'échelle des secondes ; allez la chercher par outils. Les architectures qui marient mal substrat et fraîcheur — poids gelés pour des faits qui changent vite, index de récupération pour de l'état vivant — paient en justesse, en latence, ou les deux.

9.3 La zone Boucle d'or : assez de contexte, pas trop

La question quotidienne est de savoir combien de contexte passer à chaque appel. La zone du milieu est plus étroite que la plupart des équipes ne le supposent au départ. Le levier le plus conséquent est le prompt système. Un bon est court, spécifique, stable. Un mauvais est le prompt défensif qui grandit par accrétion, avec une clause ajoutée chaque fois que le modèle se conduit mal, jusqu'à devenir un document de règles de mille mots que le modèle ne peut plus suivre de manière fiable. Les équipes qui auditent trimestriellement avec la suppression explicite pour objectif finissent avec des prompts plus courts qu'un an plus tôt et un meilleur comportement.

Le second levier est le roster d'outils. Le correctif au tool-loadout rot est la divulgation progressive : enregistrer un petit nombre d'outils de haut niveau et laisser le modèle entrer dans le détail via un outil de découverte. Quarante outils étroits deviennent quatre outils larges avec dispatch interne, et la précision de sélection retrouve l'essentiel de ce qui était perdu. Le troisième levier est l'historique conversationnel — compactez dès le premier tour, pas à quatre-vingt-dix pour cent de la capacité. Le quatrième est les résultats d'outil : renvoyez les champs dont le modèle a besoin, pas la ligne entière. La discipline est l'inclusion délibérée : pour chaque élément, l'équipe devrait pouvoir répondre « que se passerait-il s'il n'était pas là ». Si la réponse est « l'agent se comporterait pareil », il devrait être retiré.

Ce que prépare le Chapitre 9

Ce chapitre a cadré le contexte comme un budget fini à l'intérieur d'un seul appel d'inférence. Ce qu'il n'a pas couvert, c'est la question du temps. Un agent qui tourne trente secondes a un problème de budget qui tient dans une seule fenêtre. Un agent qui tourne trente minutes, trois heures, trois jours a un problème de mémoire qu'aucune fenêtre de taille pratique ne peut tenir. Les stratégies pour cette échelle de travail sont différentes en nature, pas seulement en degré.

Prochaine étape — Chapitre 10 : Mémoire de tâche à long horizon. Les mécanismes à court terme par fenêtres glissantes et scratchpads ReAct, les mécanismes à long terme par vecteurs épisodiques et stores sémantiques, et les techniques de compaction qui permettent à un agent d'opérer sur des heures et des jours.