Anthropic a enfin résolu le problème de la fenêtre de contexte de 1M

AAI LABS
Computing/SoftwareManagementInternet Technology

Transcript

00:00:00La fenêtre de contexte de 1 million semble être une amélioration majeure, mais en réalité, c'est bien pire que ce que la plupart des gens réalisent.
00:00:05Et c'est exactement pour cela que l'ingénieur travaillant sur Claude Code, Tarik, a écrit cet article.
00:00:09Si vous pensez que Claude Code ne commence à moins bien fonctionner qu'à 1 million de jetons, ou que 1 million, c'est tellement vaste que vous n'avez pas à vous en soucier, vous avez tort.
00:00:17La dégradation commence en réalité bien avant la moitié de la fenêtre.
00:00:21Et la solution vers laquelle la plupart des gens se tournent, à savoir la compaction, aggrave généralement les choses.
00:00:24À la fin de cette vidéo, vous saurez exactement comment empêcher Claude Code de devenir moins performant, de la même manière que le fait l'équipe d'Anthropic.
00:00:31Claude Code semble dégradé, même si les modèles eux-mêmes sont pourtant puissants.
00:00:35Vous avez peut-être remarqué qu'il hallucine davantage, qu'il doit être rappelé à l'ordre encore et encore sur des instructions données précédemment, et qu'il finit par les oublier à long terme.
00:00:44Nous avons remarqué cela aussi lorsque nous exécutions des tâches plus longues, et les performances de Claude semblaient diminuer.
00:00:48Mais il y a une raison précise derrière tout cela.
00:00:50Désormais, les modèles après Opus 4.5 sont tous dotés d'une fenêtre de contexte de 1 million, au lieu des 200 000 précédents.
00:00:56Bien que cette mise à niveau donne l'impression que la plupart des problèmes que nous avions seront résolus avec cette fenêtre de 1 million, cela ne semble bon qu'en théorie.
00:01:03Parce que vous pouvez maintenant faire tenir plus de choses à la fois dans la fenêtre de contexte qu'auparavant, et la baser sur davantage de documents et d'informations afin que Claude ne s'écarte pas de la tâche à accomplir.
00:01:12Une fenêtre de contexte d'un million ouvre également la porte aux tâches de longue durée sans trop s'inquiéter des problèmes de contexte auxquels nous étions confrontés.
00:01:19Mais le fait est que tout cela n'est pas entièrement résolu.
00:01:22La fenêtre de contexte d'un million est en réalité une arme à double tranchant.
00:01:26Bien qu'elle permette à Claude d'aller plus loin et de conserver plus d'informations à la fois, tout cela a un coût.
00:01:30Elle ouvre la porte à la "pourriture contextuelle" (context rot).
00:01:32La pourriture contextuelle signifie que les performances du modèle se dégradent avec davantage d'informations dans sa fenêtre de contexte, car avec une fenêtre saturée, il a trop d'éléments à prendre en compte et ne peut pas rester concentré.
00:01:42Et avec une fenêtre de contexte d'un million, votre contexte devient beaucoup plus encombré, ce qui signifie qu'il y a beaucoup plus d'informations susceptibles d'interférer avec le raisonnement de Claude qu'avec la fenêtre de 200 000.
00:01:53La pourriture contextuelle ne se produit pas seulement dans un contexte extrêmement saturé.
00:01:57Selon le créateur de Claude Code, la pourriture contextuelle commence en fait à se produire autour de 300 000 à 400 000 jetons, ce qui est bien moins qu'un million, soit environ 40 % d'utilisation.
00:02:07Peu importe la taille de la fenêtre de contexte, nous devons donc agir pour prévenir cette pourriture.
00:02:11Savoir cela changera réellement votre façon de travailler avec la fenêtre de contexte d'un million.
00:02:15Maintenant, un petit récapitulatif.
00:02:16La fenêtre de contexte est tout ce que le modèle voit à la fois, ce qui inclut la conversation jusqu'à présent, le fichier Claude.md, l'instruction système, les fichiers lus pendant la session et chaque sortie d'appel d'outil.
00:02:26Chaque invite en ajoute davantage, et une fois que la fenêtre est pleine, vous résumez pour continuer avec une fenêtre plus fraîche, ce qui correspond à la compaction.
00:02:32Si vous ne gérez pas correctement le contexte, votre agent peut échouer de quatre manières.
00:02:37Cela devient encore plus évident et problématique avec les agents de longue durée.
00:02:40La pollution contextuelle est la première, que nous avons déjà abordée et qui explique pourquoi elle se produit.
00:02:45La dérive des objectifs est la deuxième.
00:02:46Cela se produit lorsque votre agent s'éloigne de ce qu'il doit faire parce qu'il a trop de choses à gérer sur le moment, ou pour le dire plus simplement, il a oublié les objectifs qu'il était censé atteindre.
00:02:55Cela peut arriver souvent si vous travaillez avec Claude Code, où vous voulez que votre interface ait un certain aspect et vous l'avez déjà spécifié, mais il ne suit pas ces directives et vous devez lui rappeler l'objectif réel.
00:03:05La corruption de la mémoire est la troisième, et elle se produit lorsque, pendant l'exécution, l'état interne de l'agent ou les faits stockés deviennent incorrects, et qu'il continue d'agir sur la base de cet état défaillant.
00:03:14Il est souvent difficile d'identifier la cause exacte lorsque les agents fonctionnent sur de longues périodes ; il devient flou de savoir où l'erreur a pris naissance.
00:03:21Par exemple, la corruption de la mémoire peut ressembler à un fichier écrit d'une certaine manière par l'agent lui-même, puis modifié par un sous-agent qui n'est pas dans le contexte actuel.
00:03:29L'agent se réfère à sa propre mémoire obsolète et continue de fonctionner comme si le fichier existait toujours sous la forme qu'il avait initialement créée.
00:03:37L'imprécision décisionnelle est la dernière.
00:03:39Elle se produit lorsqu'un agent fait des choix contradictoires dans des situations quasi identiques, comme utiliser un modèle de gestion d'erreur à un endroit et un modèle différent ailleurs.
00:03:48Tous ces problèmes surviennent lorsque le contexte n'est pas géré correctement et ils ont un impact sur les performances à long terme des agents.
00:03:53Ce sont exactement les facteurs que la plupart des environnements d'agents tentent d'optimiser.
00:03:57Une fois que vous avez demandé à Claude de faire quelque chose et qu'il a terminé, il existe en fait cinq options possibles pour la suite concernant votre prochaine instruction.
00:04:06Chacune dépend de ce que sera votre prochaine invite.
00:04:08Si vous utilisez chacune d'entre elles correctement, votre façon de travailler avec Claude peut s'améliorer considérablement.
00:04:12Bien que le choix le plus naturel soit simplement de continuer, les autres options vous aident à gérer votre contexte plus efficacement.
00:04:18Vous devez donc décider avec soin si vous voulez réellement poursuivre dans le même flux ou démarrer une nouvelle session.
00:04:24Une fois que le contexte devient saturé, vous avez deux façons d'alléger le contexte : le premier choix est la compaction, que nous avons déjà expliquée comme étant un résumé du contenu existant.
00:04:32Mais vous devez être clair sur le moment où vous souhaitez réellement résumer, car le résumé est destructeur et de nombreux détails qui peuvent vous sembler importants, mais pas pour Claude, peuvent être supprimés.
00:04:41Par conséquent, un contexte important peut ne plus exister dans la fenêtre de contexte.
00:04:44Il vaut mieux contrôler la compaction vous-même plutôt que de laisser Claude déclencher une auto-compaction, car lorsqu'elle se déclenche au milieu d'une tâche, la compaction devient encore plus désordonnée.
00:04:52Il a tendance à conserver ce qu'il juge important et à supprimer tout ce qu'il ne pense pas nécessaire ; Claude est donc moins fiable pendant la compaction.
00:05:00À ce stade, l'attention de Claude se porte uniquement sur la synthèse et il est dépouillé du contexte de soutien, comme l'instruction système et d'autres éléments qui le rendent normalement plus capable.
00:05:08Il s'appuie alors fortement sur ses propres hypothèses concernant ce qui est important, ce qui conduit souvent à de mauvaises décisions de compaction.
00:05:14Une mauvaise compaction survient généralement lorsque le modèle ne peut pas déterminer clairement la direction de votre travail.
00:05:19Par exemple, si vous êtes dans une longue session de débogage et qu'un avertissement a été rencontré plus tôt après une auto-compaction, si vous lui demandez de corriger cet avertissement spécifique, il ne saura pas de quel avertissement vous parlez.
00:05:29Cela arrive parce que la session était axée sur le débogage dans son ensemble ; seul un résumé général de l'activité de débogage a été conservé, et l'avertissement spécifique a été traité comme du bruit et supprimé.
00:05:39Le biais de récence aggrave les choses.
00:05:41Lorsque la compaction est déclenchée, l'invite donne la priorité à la préservation des détails récents de ce sur quoi on travaillait.
00:05:46Ainsi, des informations anciennes mais toujours importantes peuvent être ignorées ou omises.
00:05:50Si quelque chose a été fait incorrectement auparavant, le modèle peut ne plus en être conscient après la compaction.
00:05:54Il n'a accès qu'au résumé au niveau de la transcription, pas à l'état complet du projet, car l'historique des appels d'outils n'est pas entièrement préservé pendant la compaction.
00:06:01Vous pouvez définir des indicateurs pour contrôler le moment où l'auto-compaction se produit, mais c'est quelque chose que vous devriez gérer plus activement et plus souvent.
00:06:07Déclenchez la compaction autour de la plage de 300 000 à 400 000 mentionnée par le créateur, car c'est généralement là que la pourriture contextuelle commence à apparaître, et fournissez toujours vous-même une instruction de compaction, car Claude répond plus soigneusement lorsque des instructions explicites sont incluses.
00:06:22Dites-lui quelles décisions, contraintes et problèmes découverts doivent être conservés afin qu'il sache ce qu'il doit prioriser.
00:06:27Vous devriez donc appuyer sur "compact" lorsque vous voulez réellement que le contexte du flux de travail précédent soit transféré dans la nouvelle fenêtre, et non lorsque vous voulez un nouveau départ.
00:06:34Mais avant d'aller de l'avant, un mot de notre sponsor.
00:06:37Verdant, une plateforme alimentée par l'IA qui aide les bâtisseurs à transformer leurs idées en produits prêts à être expédiés.
00:06:41Vous êtes en plein milieu de la construction, enfin dans la zone, et vos crédits s'épuisent.
00:06:45Votre IA s'arrête net, l'élan est perdu.
00:06:47Tous les outils de codage par IA vous font cela, mais pas Verdant.
00:06:50Lorsque vos crédits atteignent zéro, basculez simplement vers le mode éco, un mode sans frais qui maintient votre IA en marche sans dépenser un dollar de plus.
00:06:56Aucune interruption, aucun rechargement, aucune perte d'élan.
00:06:59Vous continuez simplement à construire.
00:07:00Et quand vous avez des crédits, vous n'êtes pas coincé à choisir entre Claude, GPT ou Gemini.
00:07:04Le mode multi-plan de Verdant exécute les trois ensemble comme un comité de décision, vous offrant de meilleurs plans sans l'anxiété liée aux modèles.
00:07:10Vous voulez encore plus de flexibilité ?
00:07:11Le "BYOK" (Bring Your Own Key) vous permet de brancher votre propre clé API directement dans Verdant.
00:07:15Utilisez les crédits Claude ou GPT de votre entreprise, sans frais de plateforme.
00:07:18Vous payez simplement pour ce que vous utilisez réellement.
00:07:20Vous obtenez 100 crédits et 7 jours pour tester.
00:07:23Cliquez sur le lien dans le commentaire épinglé et essayez Verdant gratuitement.
00:07:26Le deuxième choix consiste à utiliser la commande "clear" (effacer), qui supprime tout le contexte et démarre une nouvelle session avec un contexte vide.
00:07:32Contrairement à la compaction, rien n'est reporté, et seul ce que vous fournissez à nouveau reste dans la fenêtre de contexte.
00:07:37Tout comme pour la compaction, vous ne devriez pas utiliser "clear" uniquement lorsque vous manquez de contexte.
00:07:41Si vous passez à une tâche non liée, il est simple d'effacer la session et de repartir à neuf, afin que la tâche précédente n'interfère pas avec la nouvelle.
00:07:49Par exemple, si vous demandez à l'agent d'écrire des cas de test pour une application sur laquelle vous travaillez, vous pourriez ne pas vouloir qu'il conserve les détails sur la façon dont ces cas de test ont été générés.
00:07:57Au lieu de poursuivre le débogage dans le même contexte, vous pouvez démarrer une nouvelle session.
00:08:01De cette façon, Claude peut travailler au débogage de votre application plus efficacement sans être influencé par la façon dont il a généré les cas de test précédemment.
00:08:08Il existe une autre approche que vous pouvez utiliser, qui consiste à combiner "clear" et la compaction.
00:08:12Cela vous permet de ne conserver que ce que vous voulez et de tout rejeter d'autre.
00:08:16L'idée est d'utiliser un format JSON structuré qui capture les informations que vous souhaitez préserver.
00:08:21Vous pouvez créer une commande personnalisée afin de pouvoir la réutiliser fréquemment.
00:08:24Dans cette commande, vous pouvez inclure une structure JSON qui contient la tâche complète, l'état actuel, les contraintes, les problèmes découverts et tout autre détail pertinent que vous souhaitez que Claude conserve, puis lui demander de sauvegarder cela dans un fichier.
00:08:35Cette approche vous permet d'obtenir le meilleur des deux méthodes.
00:08:38Une fois que vous exécutez la commande, elle analysera toute la conversation et l'état actuel de l'application, ce qu'une compaction normale ne préserve pas de manière fiable, et sauvegardera tout dans le fichier comme spécifié.
00:08:48Un schéma est beaucoup plus strict qu'une prose ; ainsi, lorsque Claude suit une structure définie, il peut représenter ce qui est important de manière plus cohérente et précise.
00:08:56Une fois que les informations ont été sauvegardées dans le fichier, vous pouvez utiliser en toute sécurité la commande "clear" pour tout supprimer de la fenêtre de contexte.
00:09:02Ensuite, vous pouvez démarrer une nouvelle session et demander à Claude de se référer à ce document pour recueillir le contexte et implémenter la tâche suivante à partir de là.
00:09:14Comme mentionné plus tôt, à mesure que le contexte grandit, l'attention de l'agent peut dériver car il y a simplement plus d'informations en compétition pour attirer l'attention, et cela est encore plus perceptible avec la fenêtre de contexte d'un million.
00:09:23Cette pratique aide à résoudre à la fois le problème de dérive des objectifs et les problèmes d'incohérence décisionnelle dont nous avons discuté plus tôt.
00:09:29Au lieu de pousser continuellement vers l'avant dans une tâche de longue durée, il est utile de faire une pause périodiquement et de demander à l'agent de récapituler ce qu'il a fait jusqu'à présent, ainsi que les contraintes et d'autres facteurs importants.
00:09:39Lorsque vous faites cela, cela renforce les objectifs originaux et ramène des détails clés dans la partie la plus récente de la fenêtre de contexte, plutôt que de les laisser enterrés dans des sections plus anciennes.
00:09:48Cela permet de s'assurer que les informations importantes restent fraîches dans le contexte de travail de l'agent et sont moins susceptibles d'être perdues pendant la compaction ou diluées au fil du temps,
00:09:56afin que l'agent reste plus aligné avec la tâche qu'il est censé effectuer et maintienne une meilleure cohérence dans ses décisions.
00:10:02Aussi, si vous appréciez notre contenu, pensez à appuyer sur le bouton "hype", car cela nous aide à créer plus de contenu comme celui-ci et à atteindre plus de personnes.
00:10:09Les sous-agents peuvent ne pas sembler impressionnants, mais ils constituent en réalité un moyen très important de gérer le contexte.
00:10:14Chaque sous-agent est sa propre instance indépendante, avec une fenêtre de contexte dédiée, un accès complet aux outils et les permissions dont il a besoin pour accomplir sa tâche.
00:10:22Ils exécutent le travail assigné dans ce contexte séparé fourni par l'agent parent, puis retournent uniquement le résultat final au contexte principal.
00:10:30Ainsi, tous les appels d'outils qu'il a effectués, les fichiers qu'il a lus, les recherches Web qu'il a effectuées et le raisonnement intermédiaire restent dans le propre contexte du sous-agent et ne polluent pas la fenêtre de contexte de l'agent principal.
00:10:40C'est un moyen efficace de réduire la pourriture contextuelle. Les tâches de recherche en sont l'exemple le plus clair.
00:10:45L'agent parcourt plusieurs sites Web, pages et sources, et vous ne voulez pas que toutes ces informations brutes soient continuellement ajoutées dans la fenêtre de contexte principale.
00:10:53Dans de tels cas, un sous-agent peut effectuer le travail indépendamment et ne retourner que la synthèse finale.
00:10:58La question clé que vous devriez vous poser avant d'utiliser un sous-agent est de savoir si vous aurez besoin d'accéder aux étapes intermédiaires à nouveau, ou si vous ne vous souciez que du résultat final.
00:11:07Claude Code gère également l'orchestration des sous-agents par lui-même et peut générer des agents pour gérer des tâches automatiquement.
00:11:13Mais parfois, vous devez spécifier explicitement dans votre invite que vous souhaitez que le travail soit délégué à un sous-agent afin qu'il soit traité de manière isolée.
00:11:20Donc, si vous travaillez sur des tâches de recherche, de refactorisation, de synthèse ou de génération de documents, vous devriez envisager de les séparer en utilisant des sous-agents au lieu de votre agent principal.
00:11:30Enfin et surtout, "rembobiner" (rewinding) est très important par rapport au simple fait de corriger, car cela supprime les parties non pertinentes ou incorrectes de la fenêtre de contexte tout en ne conservant que l'état correct.
00:11:40Chaque fois que Claude rencontre une erreur, les gens essaient souvent de le re-solliciter pour essayer une autre approche.
00:11:44Mais une meilleure option est de rembobiner à la place, puis de fournir la direction correcte dans la nouvelle invite.
00:11:49Vous pouvez utiliser la commande "rewind" ou appuyer deux fois sur la touche Échap pour faire cela.
00:11:53Après avoir rembobiné, vous pouvez également résumer à partir de ce point afin que la conversation jusqu'à ce stade soit préservée comme contexte utile tout en supprimant les parties qui ont conduit au problème.
00:12:01Le rembobinage présente de multiples avantages.
00:12:03Premièrement, il nettoie la fenêtre de contexte en supprimant la partie où les choses ont mal tourné, ce qui donne un résumé de compaction plus propre qui préserve uniquement les implémentations correctes.
00:12:12Même si vous épinglez des informations importantes, vous évitez de reporter des sections où l'agent s'est écarté de l'objectif, ce qui aide à réduire à la fois l'incohérence décisionnelle et la dérive des objectifs.
00:12:21Si vous utilisez des sous-agents, le rembobinage garantit qu'ils reçoivent un contexte plus propre et plus précis lorsque les tâches sont transmises, de sorte que les approches incorrectes ne sont pas incluses dans leur état de travail.
00:12:30De même, si vous utilisez une commande de transfert, elle capture l'état correct de l'application au lieu d'un état corrompu ou obsolète.
00:12:37Prenez donc l'habitude de rembobiner au lieu de corriger sans cesse vers l'avant, afin que l'agent travaille systématiquement à partir d'un état propre et précis tout au long de la session.
00:12:45Cela nous amène à la fin de cette vidéo.
00:12:47Si vous souhaitez soutenir la chaîne et nous aider à continuer à faire des vidéos comme celle-ci, vous pouvez le faire en utilisant le bouton "super thanks" ci-dessous.
00:12:54Comme toujours, merci d'avoir regardé et je vous verrai dans la prochaine.

Key Takeaway

Pour éviter la dégradation des performances sur une fenêtre de 1 million de jetons, il faut gérer activement le contexte en rembobinant après les erreurs, en utilisant des sous-agents pour les tâches isolées et en privilégiant une compaction manuelle basée sur des structures JSON rigides.

Highlights

La dégradation des performances du modèle, appelée « pourriture contextuelle », commence dès 300 000 à 400 000 jetons, soit environ 40 % de la fenêtre de 1 million de jetons.

La compaction automatique réduit la fiabilité car Claude supprime des détails cruciaux lors de la synthèse, perdant ainsi le contexte de soutien nécessaire à la prise de décision.

L'utilisation de sous-agents isolés permet de traiter des tâches complexes, comme la recherche Web ou la génération de documents, sans polluer la fenêtre de contexte principale avec des données brutes.

Le rembobinage (rewind) après une erreur est supérieur à la simple correction car il élimine les segments de contexte invalides avant qu'ils ne soient intégrés par la compaction.

La création d'un état persistant via un format JSON structuré permet de réinitialiser le contexte sans perdre les contraintes ou les objectifs du projet.

Timeline

La réalité de la fenêtre de 1 million de jetons

  • La dégradation des performances survient bien avant la saturation totale de la fenêtre.
  • Le concept de « pourriture contextuelle » désigne l'incapacité du modèle à rester focalisé lorsque trop d'informations interfèrent avec son raisonnement.
  • Les problèmes commencent généralement autour de 300 000 à 400 000 jetons.

Bien que la capacité de 1 million de jetons soit présentée comme une amélioration, elle s'avère être une arme à double tranchant. L'encombrement du contexte sature l'attention du modèle et entraîne des erreurs de raisonnement. Les utilisateurs doivent agir activement pour prévenir cette dégradation, plutôt que de compter sur la capacité théorique maximale.

Erreurs courantes des agents de longue durée

  • L'absence de gestion du contexte mène à quatre échecs : pollution contextuelle, dérive des objectifs, corruption de la mémoire et imprécision décisionnelle.
  • La corruption de la mémoire survient quand l'agent se réfère à des états obsolètes créés par des sous-processus disparus.
  • La dérive des objectifs se manifeste lorsque l'agent oublie les directives initiales à cause de la surcharge d'informations.

La gestion inefficace du contexte, notamment lors de sessions prolongées, entraîne une perte de cohérence. L'agent peut oublier des contraintes précédemment fixées ou agir sur la base de fichiers dont l'état a été modifié sans qu'il en soit informé. Ces erreurs s'accumulent, rendant difficile l'identification de la source exacte du problème.

Stratégies de gestion du contexte : Compaction et Effacement

  • La compaction automatique est destructrice car elle privilégie les informations récentes et supprime des détails contextuels jugés superflus par le modèle.
  • Le contrôle manuel de la compaction permet de spécifier les contraintes et décisions à conserver.
  • L'utilisation d'un schéma JSON structuré combiné à une commande 'clear' permet de réinitialiser la session tout en préservant l'état critique du projet.

La compaction déclenchée par l'agent lui-même est souvent imprécise. Il est préférable d'initier la compaction manuellement en fournissant une instruction explicite sur ce qui doit être priorisé. Pour une gestion optimale, le stockage d'un état sous format JSON permet une transition propre vers une nouvelle session, garantissant ainsi que l'agent travaille à partir d'informations vérifiées et structurées.

Optimisation via sous-agents et rembobinage

  • Les sous-agents traitent des tâches isolées et ne renvoient que la synthèse finale, préservant la clarté du contexte principal.
  • Le rembobinage (double touche Échap) élimine les séquences d'erreurs avant qu'elles ne soient consolidées dans la mémoire ou lors d'une compaction.
  • Récapituler périodiquement les objectifs renforce l'alignement de l'agent dans les tâches de longue durée.

L'utilisation de sous-agents permet d'isoler les recherches ou refactorisations intensives pour éviter la pollution contextuelle. Le rembobinage est une pratique proactive essentielle pour corriger les erreurs de parcours. En supprimant les portions incorrectes de l'historique, l'agent évite de s'appuyer sur des données fausses, améliorant ainsi la précision décisionnelle sur le long terme.

Community Posts

View all posts