Une fenêtre de contexte plus grande ne résoudra pas vos problèmes avec l’agent : budget d’attention et cacheage

Un fournisseur peut annoncer une fenêtre de contexte de un million de tokens, mais le modèle en utilisera néanmoins bien moins de manière fiable. Le benchmark RULER d’NVIDIA vérifie la longueur à laquelle un modèle continue de performer correctement. Pour deux des dix-sept modèles testés, Yi-34B et GPT-4 (version préliminaire 1106), la longueur fiable s’élevait à environ 32 K tokens pour une capacité annoncée de 200 K tokens, et à 64 K tokens pour une capacité annoncée de 128 K tokens. Les modèles les plus faibles perdaient en performance dès une fraction infime de ce qui était promis. Au-delà de ce point, la taille annoncée n’est qu’une ligne sur une fiche de prix et non une capacité réelle de production.

La version courte

La fenêtre de contexte n’est pas une mémoire uniforme. C’est une ressource disposant d’un budget d’attention qui s’épuise bien avant la limite de tokens. Le matériel situé au début ou à la fin du contexte est utilisé de manière plus efficace que celui se trouvant au milieu, au point qu’un modèle à qui l’on donne un document enfoui au milieu d’une demande peut donner de moins bons résultats qu’un modèle ne recevant rien du tout. Exemple concret : un agent qui reçoit un long journal d’activités d’outil, une pile de fragments récupérés ainsi que ses instructions dans une seule demande aura tendance à privilégier ce qui se trouve aux extrémités et à atténuer discrètement le reste.

Trois outils gèrent ce budget, et chacun entraîne une perte différente :

• Compression de la demande : elle supprime les tokens à faible valeur informationnelle. Elle donne de bons résultats sur les benchmarks de référence, mais des reproductions indépendantes révèlent des problèmes avec du contenu structuré tel que les numéros, les chaînes de caractères exactes et les fragments de code.

Les fenêtres glissantes et la compactation contrôlent la durée de la session. La première élimine les données les plus anciennes tandis que la seconde les remplace par un résumé, et leurs pertes diffèrent.

Le cache des prompts peut réduire les coûts d’entrée d’environ 90 pour cent sans perdre d’informations, à condition que le préfixe soit identique en octets entre les appels.

C’est là le piège : la compression et la compactation endommagent toutes deux le cache, et les économies réalisées grâce au cache dépassent fréquemment celles obtenues par la compression. Utiliser l’outil inadapté au problème entraîne des pannes silencieuses en production difficiles à diagnostiquer par la suite.

Le contexte est un budget, pas de l’espace de stockage

Tout d’abord, deux termes importants. Un token est l’unité de texte sur laquelle travaille le modèle, correspondant à environ quatre caractères ou trois quarts d’un mot en anglais. La fenêtre de contexte représente le nombre maximal de tokens traités lors d’une seule requête ; il s’agit moins de la mémoire disponible et plus de la taille maximale de la matrice d’attention en une seule passe.

Andrej Karpathy a décrit l’ingénierie du contexte comme l’art de remplir la fenêtre avec exactement ce dont a besoin l’étape suivante, le modèle servant de processeur et la fenêtre en étant la mémoire de travail. Cette analogie est utile, mais elle ne couvre qu’une moitié du sujet. L’autre moitié concerne le budget d’attention. Les directives d’Anthropic concernant l’ingénierie du contexte pour les agents considèrent le contexte comme une ressource finie dont les retombées diminuent, chaque token ajouté puisant dans un pool d’attention limité. Il s’agit là de calculs mathématiques et non de poésie : les paires d’attention augmentent de manière quadratique, de sorte que mille tokens impliquent environ un million de relations, tandis que cent mille en impliquent dix milliards.

Ajouter du contexte, ne serait-ce que par précaution, n’est jamais gratuit. Trois exemples supplémentaires de type few-shot, un historique complet des conversations ou vingt définitions d’outils au lieu de cinq proviennent tous du même ensemble que les faits importants. La première question lors d’une revue architecturale ne devrait pas porter sur le nombre de tokens disponibles, mais plutôt sur la partie du budget qui contribue réellement au résultat.

La courbe en forme de U

Liu et ses collègues (Stanford et Berkeley, 2023) ont mesuré la précision dans le domaine de la réponse à des questions sur plusieurs documents et ont observé une forme en U. Les réponses étaient les plus fiables lorsque le passage pertinent se trouvait en premier ou en dernier, et les moins fiables lorsqu’il était placé au milieu. L’expression « Perdu au milieu » s’est rapidement imposée, bien avant toute explication officielle.

Ce qui est vraiment préoccupant, c’est un effet secondaire. Lorsque la demande contenait vingt ou trente documents, une réponse correcte placée au milieu du contexte obtenait un score inférieur à celui obtenu avec une approche sans accès aux documents, où le modèle ne voyait aucun document du tout. Fournir les preuves appropriées à la mauvaise place peut rendre le système dans une situation pire que s’il n’en recevait aucune.

Pourquoi cela se produit : encore indéterminé

Des années plus tard, il n’existe pas de consensus sur la cause. Plusieurs explications coexistent :

• un artefact des données d’entraînement, car les auteurs ont tendance à placer les points clés en début et en fin de texte,
• le comportement de l’encodage positionnel et du masquage causal,
• la géométrie du décodeur qui existe dès l’initialisation, avant même le début de l’entraînement,
• une adaptation qui apparaît pendant le préentraînement lorsque le modèle équilibre des exigences mémoire contradictoires.

Chaque cause exige un remède différent : d’autres données d’entraînement, une autre masque d’attention, une calibration de l’attention, ou simplement un prompt réorganisé. Les fusionner en une seule explication claire serait trompeur.

Qu’est-ce qui est résolu et qu’est-ce qui ne l’est pas

Se demander si le problème est déjà résolu le présente de manière erronée. La récupération simple de faits est en grande partie résolue : les modèles de pointe actuels peuvent trouver une information explicitement mentionnée, même au milieu d’une très grande quantité de données, où qu’elle se trouve. Le raisonnement à plusieurs étapes n’est pas encore résolu. La synthèse de plusieurs documents ou l’édition de code dans un grand répertoire constituent des tâches différentes de la simple localisation d’un fait, et les évaluations publiées sur le codage à long contexte montrent que les taux de réussite chutent fortement à mesure que la longueur des entrées augmente, pour le même modèle et le même type de tâche.

Il existe également des preuves contre l’idée que cette courbe soit universelle. L’étude Context Rot de Chroma a testé dix-huit modèles avancés et a constaté qu’un ensemble de données mélangées et logiquement incohérent surpassait un ensemble cohérent dans tous ces modèles, de plus ses expériences n’ont pas montré d’avantage positionnel constant. La conclusion raisonnable est qu’il existe plus d’un mécanisme de dégradation, et Lost in the Middle n’en est qu’un.

Une phrase qui a fait passer un score de 27 % à 98 %

Anthropic a rapporté un cas significatif concernant Claude 2.1 dans un test de type « aiguille dans une botte de foin ». Le taux de précision était de 27 % jusqu’à ce qu’une seule ligne soit ajoutée en début de réponse du modèle, lui indiquant de sélectionner la phrase la plus pertinente dans le contexte. Par la suite, ce taux est passé à 98 %. Aucune capacité supplémentaire n’a été ajoutée ; une simple instruction a simplement changé de position. Il s’agissait d’une seule évaluation, avec une seule version du modèle et un seul type de tâche, il convient donc de le considérer comme une illustration et non comme une règle valable pour tous les prompts.

Le mécanisme : les puits d’attention

Les premiers tokens d’une séquence absorbent une part disproportionnée de l’attention, que le contenu soit pertinent ou non. La cause en est une simple question de mathématiques : la fonction softmax fait en sorte que les poids d’attention s’additionnent à un, ce qui oblige le modèle à diriger toute son attention vers quelque part, même lorsque rien dans le contexte ne le justifie. S’abstenir n’est pas une option, et les premières positions deviennent ainsi des décharges. On les appelle des puits d’attention.

Une équipe du MIT (Xiao et ses collègues) a transformé cette particularité en outil. Ils ont découvert qu’une fenêtre glissante simple se résout précisément au moment où le premier token est éliminé du cache. En fixant uniquement les premiers tokens comme points d’ancrage, on maintient une génération stable même avec des flux de millions de tokens, ce qui permet d’obtenir une vitesse jusqu’à 22,2 fois supérieure à celle du rec calcul de chaque fenêtre. Les synthèses courantes omettent souvent une contrainte : cela ne consomme aucun token de mémoire réelle. La production reste fluide tandis que les anciens tokens disparaissent, et tout fait qui sort de la fenêtre est perdu définitivement. La stabilité et la mémoire sont deux choses distinctes.

Le conseil pratique consiste donc à placer l’instruction clé là où l’attention est la plus forte, généralement à la fin, et à effectuer des tests sur sa propre configuration. Ce n’est pas universel : certaines recherches montrent que des points d’ancrage apparaissant au milieu de la séquence sont mieux supprimés que protégés, et le comportement varie selon le modèle.

Compression, fenêtre et compactage

Pensez à une valise qui ne peut pas contenir tout ce que vous avez. Vous pouvez jeter les objets moins importants, ne packer que les plus récents ou écrire une note indiquant ce qui est resté à la maison. Chaque choix entraîne la perte de quelque chose de différent.

Compression rapide

La famille LLMLingua évalue le degré de surprenante de chaque token à l’aide d’un petit modèle auxiliaire et élimine ceux qui contiennent peu d’informations. Les résultats sont impressionnants : jusqu’à 20 fois de compression avec LLMLingua, et pour LongLLMLingua, conçu pour comprendre les requêtes, une amélioration allant jusqu’à 21,4 % sur NaturalQuestions en utilisant seulement un quart des tokens. Il s’agit de deux variantes et non d’un seul résultat.

Les reproductions indépendantes compliquent la situation. Une étude menée contre le répertoire de référence a montré que l’instruction non compressée surpassait clairement celle qui l’était, ce qui est le contraire de ce rapporté dans la publication. Une autre étude sur la compression dans ce domaine a indiqué que la précision du comptage des fragments diminuait fortement, car la compression détruit les numéros et les chaînes de caractères exactes. Il ne s’agit pas pour autant que la compression échoue ; sa fiabilité est contestée et dépend du type de données. Le texte narratif la supporte bien, tandis que les passages numérotés, les identifiants, le code et les chiffres ne le supportent pas.

Trois façons de gérer une session

• Fenêtre glissante. Méthode classique premier entré, premier sorti : on conserve les derniers k messages ou N tokens et on élimine le reste. Cela ne coûte rien en termes de calcul, mais les informations sont perdues de manière drastique ; ainsi, une décision prise dès le premier tour disparaît déjà au cinquième tour, et le modèle peut proposer quelque chose qui la contredit.

Compaction. Remplacer la conversation plus ancienne par un résumé. Le risque est d’obtenir un résumé si sommaire qu’il omet des détails dont l’importance apparaîtra plus tard. Les seuils varient considérablement d’un outil à l’autre, mais une recommandation courante est de déclencher la compression lorsque la capacité atteint 70 à 75 % et non 95 %, car un modèle sans marge de manœuvre produit un résumé de moindre qualité.

Mémoire externe. Dans le style MemGPT, les données se trouvent en dehors de la fenêtre de travail et le modèle les récupère via une appel de fonction lorsque c’est nécessaire. Rien n’est perdu définitivement, mais chaque récupération entraîne un retard et une appel de modèle supplémentaire ; de plus, le modèle doit savoir à l’avance qu’un fait donné vaut la peine d’être récupéré, ce qui est lui-même une source possible d’erreurs. Utilisez-la pour des faits qui doivent être accessibles sur demande, comme les préférences de l’utilisateur ou des décisions antérieures, et non pour tout.

Le piège : la compression annule la réduction de prix du cache

Avec le caching rapide, le fournisseur se souvient de la version inchangée de votre requête et facture les lectures ultérieures à un faible pourcentage du tarif habituel. Le cache KV contient l’état calculé des tokens précédents, permettant ainsi au modèle de ne pas refaire ce travail.

Le prix de cette réduction est la rigidité : le préfixe doit être identique à chaque octet entre les différentes appels. Cela exclut l’utilisation d’une date et heure variables en tête de requête, d’un ID de session aléatoire avant les instructions ou de clés réorganisées dans un dictionnaire JSON. Tout élément variable doit être placé dans la partie volatile. Les équipes utilisant des agents de production avancés considèrent le taux de hits du cache comme leur métrique système la plus importante, avec une différence de coût d’environ dix fois entre les hits et les misses.

Ici, le piège se referme. La compression réécrit la requête à chaque appel, car les tokens supprimés dépendent de la question posée, ce qui fait que chaque demande entraîne une absence dans le cache. Une économie d’environ soixante pour cent sur les tokens se heurte à la perte d’un rabais de quatre-vingt-dix pour cent, et l’entreprise perd cette bataille plus souvent que les équipes ne le pensent.

Une anecdote circule dans les supports de marketing selon laquelle une facture mensuelle serait passée d’environ 42 000 dollars à 2 100 dollars après l’implémentation de la compression, sans que l’entreprise concernée, la date ni la méthode utilisée ne soient indiquées. Il est impossible de savoir si cette comparaison tenait compte de la perte dans le cache, qui est précisément la variable déterminant si un tel résultat peut se reproduire.

Un plan pour lundi

Cette liste ne remplace pas les tests sur vos propres données. Elle permet d’éviter l’erreur la plus courante, à savoir recourir à la compression ou à des délais plus longs avant d’examiner des options moins coûteuses et plus sûres.

1. Classifiez la tâche. S’agit-il d’un simple retrait d’informations ou d’un raisonnement en plusieurs étapes sur un contexte long ? Cela détermine l’importance réelle de la dégradation liée à la position des éléments.
2. Vérifiez où se trouve l’instruction clé. Si elle est enfouie au milieu du prompt, déplacez-la à la fin et mesurez les résultats. Il s’agit d’un changement de une seule phrase, ce qui constitue le seul levier disponible ici.
3. Vérifiez la stabilité des préfixes. Lorsque le prompt du système diffère ne serait-ce que d’un octet entre deux appels, le mémorisation ne sert à rien ; il faut donc d’abord corriger ce problème. Il est mentionné bien moins souvent dans les évaluations que le choix du modèle, même s’il peut avoir un impact plus important sur les résultats.

Déterminez d’abord le problème avant de choisir un outil. Un coût élevé signifie qu’il faut vérifier le cache avant la compression. Une qualité qui se dégrade au cours d’une session prolongée indique une compactation à un seuil de 70 à 75 pour cent. L’oubli de faits spécifiques suggère l’utilisation d’une fenêtre glissante ou de mémoire externe, selon que ces faits doivent être restitués sur demande.

Si vous continuez à utiliser la compression, testez-la sur vos propres données, en particulier sur des données contenant des nombres exacts, des identifiants et du code, où les résultats publiés échouent le plus souvent à être reproduits.

À retenir

Une fenêtre plus grande ne résout pas le problème d’un agent, car elle augmente simplement la capacité d’une ressource dont le véritable problème n’était jamais la capacité elle-même.

• La fenêtre représente un budget d’attention et non de stockage ; chaque token ajouté par précaution vient du pool destiné aux éléments importants.

Le débat sur les modèles « Lost in the Middle » est mal formulé : la récupération de faits est principalement gérée par des modèles avancés, tandis que le raisonnement en plusieurs étapes sur de longs contextes reste nettement moins performant.

La position géographique est l’élément le moins coûteux à prendre en compte, il faut donc la vérifier avant d’investir dans des solutions plus chères.

La compression présente des faiblesses avérées dans les tests indépendants, en particulier pour du contenu qui doit être conservé mot pour mot.

Du point de vue économique, le stockage en cache et la compression s’annulent mutuellement, il convient donc de calculer d’abord les économies réalisées par chacun.

Le véritable changement dans le travail quotidien réside dans l’ordre des questions lors d’une revue de conception. Demandez d’abord quel est le contexte et où se situe chaque élément, puis seulement ensuite quelle en est la taille. Inversez cet ordre et vous risquez de disposer d’une marge trop grande qui fait simplement que les faits importants ont plus d’espace pour disparaître. Une règle pratique à retenir : examinez d’abord la position, puis la stabilité du préfixe, ensuite le volume, et n’abordez la compression qu’en dernier.