Budgétiser une fenêtre de contexte pour une tâche longue

Ce que c'est

La fenêtre de contexte, c'est tout ce que le modèle voit lors d'un appel : l'invite système, les définitions d'outils, la conversation menée jusque-là (résultats d'outils compris) et les tokens qu'il génère. La documentation de l'éditeur sur les fenêtres de contexte décrit comment ces éléments comptent dans la limite et présente le compactage côté serveur comme la stratégie à adopter pour les conversations qui s'en approchent. Deux propriétés font de cette fenêtre un budget plutôt qu'un simple contenant. L'article cité sur les contextes longs rapporte que la performance est souvent la meilleure lorsque l'information pertinente se trouve au début ou à la fin de l'entrée, et qu'elle se dégrade lorsqu'elle se trouve au milieu. Le billet d'ingénierie d'Anthropic cité désigne ce même effet par le terme context rot : plus le nombre de tokens dans la fenêtre augmente, plus la capacité du modèle à y retrouver une information diminue.

Pourquoi c'est important

Une tâche longue (une refactorisation touchant plusieurs fichiers, un rapport de recherche, une migration) produit beaucoup plus de texte qu'il n'en faut à un instant donné. Sans budget, la fenêtre se remplit d'anciens résultats d'outils, l'instruction donnée au départ se retrouve au milieu, et la réponse est tronquée par la limite de sortie. Chacun de ces cas constitue un échec silencieux : rien ne produit d'erreur, le résultat est simplement moins bon.

Comment l'appliquer

• Diviser le budget en quatre parties et attribuer une taille à chacune : le fixe (invite système, définitions d'outils), le matériel de la tâche (le cahier des charges, les fichiers concernés), l'ensemble de travail (résultats d'outils récents, sur quelques étapes au maximum) et la réserve (la réponse la plus longue que la tâche puisse exiger, plus une marge pour un tour d'outil supplémentaire).
• Placer le cahier des charges et les critères d'acceptation au début ; reformuler le sous-objectif en cours à la fin de chaque tour, afin que les deux extrémités portent l'essentiel.
• Conserver le plan, l'avancement et les décisions dans un fichier bloc-notes que l'agent réécrit, et le recharger après chaque compactage ; les résumés de compactage sont à perte d'information et ne doivent pas être la seule copie.
• Fixer un point de compactage bien en deçà de la limite et compacter par intention (ce qui a été décidé, ce qui reste à faire) plutôt que par chronologie.
• Suivre l'utilisation à partir du décompte de tokens fourni par le prestataire à chaque appel, et s'arrêter pour transmettre la tâche ou la scinder lorsque l'ensemble de travail ne tient plus après compactage.
• Préférer plusieurs tâches ciblées avec des contextes neufs à un seul contexte qui porte tout.

Pièges

Remplir la fenêtre simplement parce qu'elle est grande. Faire disparaître les critères d'acceptation lors d'un compactage. Fixer la limite de sortie par habitude et tronquer la réponse finale. Faire confiance à un résumé de compactage qui a laissé de côté une inconnue, laquelle apparaît alors comme tranchée.