200 000 jetons, c'est largement suffisant ! Le blog @AmpCode propose une perspective contre-intuitive mais pertinente sur la « limite » de la fenêtre de contexte de 200 000 jetons du modèle Claude Opus 4.5. L’équipe estime que, pour un codage et une exécution des tâches de haute qualité, 200 000 jetons sont non seulement suffisants, mais souvent supérieurs à des contextes excessivement longs. La théorie de l'« ivresse » : plus de contexte n'est pas toujours préférable. L'auteur propose une analogie frappante : « Si vous donnez trop de jetons à un agent, il se comportera comme s'il était ivre. » • Problème de rapport signal/bruit : un historique de dialogue excessivement long peut contenir beaucoup d’informations non pertinentes pour la tâche actuelle, ce qui distrait l’attention du modèle et le rend sujet aux erreurs, voire aux hallucinations. • Dégradation des performances : Pour garantir des performances optimales de l’agent, il est essentiel de « fournir uniquement le contexte nécessaire à l’exécution de la tâche en cours, et rien de plus ». Les auteurs de la philosophie de flux de travail « à threads courts » s'opposent à l'accumulation de tout le travail dans une conversation excessivement longue comportant des millions de jetons, et préconisent plutôt l'utilisation de groupes interconnectés de threads courts : • Décomposition des tâches : Une fonctionnalité de développement complexe doit être décomposée en plusieurs petites tâches distinctes. • Les threads sont des tâches : chaque thread correspond à une petite tâche. Par exemple, un thread est responsable de l’implémentation de base, un autre de la refactorisation et un autre encore de la revue de code ou de l’écriture des scripts de test. • Transmission du contexte : transmission du contexte nécessaire entre les threads via des références ou des outils, au lieu d'accumuler constamment un historique. Considérations relatives aux coûts et à l'efficacité : Efficacité économique : Les conversations longues impliquent non seulement l'envoi d'un grand nombre de jetons à chaque requête, mais augmentent également le risque de manquer la fenêtre de cache, ce qui accroît encore les coûts. • Contrôlabilité : Les flux courts sont plus faciles à gérer et à suivre, et chaque interaction a un objectif clair. Cette méthode de travail s’inspire du principe classique d’ingénierie qui consiste à « décomposer les grandes tâches en tâches plus petites ». Cet article plaide essentiellement pour un changement de paradigme dans l'interaction avec l'IA, passant d'une approche uniforme à une gestion plus fine. L'auteur soutient qu'au lieu de tenter de contenir le chaos avec une fenêtre de contexte infiniment longue, il est préférable de décomposer les problèmes complexes en de multiples unités de contexte concises et efficaces de l'ordre de 200 000, grâce à de bonnes pratiques d'ingénierie. Autrement dit, la limite de 200 000 est une « fonctionnalité » qui oblige les utilisateurs à bien décomposer leurs tâches, plutôt qu'un défaut. Adresse du blog
