Ne faites pas confiance aux grandes fenêtres de contexte

• La fenêtre de contexte d’un LLM peut se diviser entre une zone intelligente où le modèle reste précis, et une zone émoussée où son attention baisse et où il commence à oublier les consignes précédentes
• Le point de bascule se situe autour de 100k tokens, et une grande taille de fenêtre de contexte mise en avant ne signifie pas pour autant la même capacité de travail réelle
• Les agents de code peuvent consommer des tokens très vite, jusqu’à atteindre 100k tokens rien qu’avec des lectures de fichiers, de longues sessions de débogage et l’exécution de gros tests
• Le rapport RULER et le rapport de Chroma sur le context rot montrent que le contexte effectif ne représente qu’une partie du chiffre annoncé, et que les performances se dégradent progressivement à mesure que la fenêtre se remplit
• Plutôt que de s’appuyer sur des résumés automatiques pour les longues sessions, il vaut mieux laisser l’information hors session via des spécifications et petits livrables rédigés à la main, afin de rester dans la zone intelligente

---

Les limites réelles de la fenêtre de contexte

• La fenêtre de contexte d’un LLM peut se diviser entre une zone intelligente où le modèle reste précis et une zone émoussée où son attention baisse
  • Dans la zone émoussée, le modèle commence à oublier ce qui lui a été transmis quelques minutes plus tôt
  • Le point de bascule se situe autour de 100k tokens
  • Même si la taille de fenêtre de contexte annoncée augmente, ce point de bascule ne disparaît pas
• Les agents de code consomment rapidement des tokens dans les usages modernes
  • Quelques lectures de fichiers, une longue session de débogage et une large exécution de tests suffisent pour atteindre 100k tokens
  • Les fournisseurs mettent en avant des fenêtres de contexte de 200k, 1M ou 2M, mais ces chiffres ne représentent pas l’ensemble de travail réellement exploitable
• Les grandes fenêtres de contexte relèvent surtout de chiffres marketing
  • L’architecture derrière fonctionne, mais elle masque un problème que le mécanisme d’attention de base ne résout pas réellement
  • Les chiffres affichés sur les produits augmentent à chaque release, mais la partie réellement utilisable ne suit pas au même rythme
• RULER et le rapport de Chroma sur le context rot montrent que le contexte effectif ne représente qu’une partie du chiffre annoncé
  • Les performances se dégradent progressivement à mesure que la fenêtre de contexte se remplit

Une manière de travailler qui garde les sessions courtes

• Les agents récents commencent à intégrer des fonctions de compression automatique pour gérer les longues sessions
  • Claude Code effectue un auto-compact quand la session devient trop longue, en résumant l’historique puis en repartant sur une nouvelle base
  • Cette approche aide, mais elle intervient après avoir déjà passé du temps dans la zone émoussée
  • Le résumé lui-même est produit par un modèle dont les performances ont déjà baissé
• Une meilleure façon de transmettre le travail consiste à ouvrir une nouvelle session et à fournir une spécification rédigée à la main
  • Une spécification écrite directement par une personne constitue un support de transmission avec un signal plus fort qu’un résumé automatique
  • Parce qu’un humain peut décider lui-même de ce qui sera important ensuite
  • Cette méthode correspond à l’approche breadcrumb, qui consiste à laisser des livrables propres que la session suivante, ou la personne suivante, pourra reprendre facilement
• obra/superpowers et mattpocock/skills structurent les workflows d’agents autour de petits livrables nommés
  • PRD, plans, skills et transmissions à des sous-agents font partie de ces livrables
  • Chaque livrable déplace l’information hors de la session active pour que la session suivante puisse la relire
  • Cette approche aide les sessions de travail à rester dans la zone intelligente
• La fenêtre de contexte doit être traitée comme un budget
  • Il faut partir du principe que seule une partie des premiers blocs est réellement utile
  • Les informations transférées depuis la session active vers des written artifacts réduisent la quantité d’éléments que l’attention du modèle doit gérer

[baam12]

Même 100k, passe encore ; on voit déjà qu’ils peinent dès qu’on arrive à 40–50k tokens.

[GN⁺]

Commentaires sur Hacker News

• Apprendre les bases de l’IA est assez amusant, mais je ne suis pas d’accord avec la direction que prend tout ça
  Il est difficile d’exprimer à quel point les commentaires dans ce genre de fil me mettent mal à l’aise. Les témoignages bien intentionnés du type « chez moi, avec XYZ, ça s’est passé comme ça » ressemblent à des conseils sur Facebook dans des discussions sur les animaux de compagnie ou la cuisine
  Les groupes Facebook sur l’impression 3D sont encore pires, et si vous imprimez tout en voulant comprendre ce qui se passe réellement, vous voyez probablement ce que je veux dire
  Dans le monde des LLM, surtout celui des LLM dans le cloud, l’exigence partagée de rigueur semble s’être complètement effondrée, au point de se réduire à une simple imitation quasi magique. Plus personne n’est vraiment plus juste ou plus faux qu’un autre
  C’est un peu l’ambiance de « vous avez essayé de nettoyer le contexte avec du liquide vaisselle Dawn, de le laisser sécher, puis d’appliquer une couche de bâton de colle ? »
  Je n’ai pas envie d’être trop dur avec les gens qui essaient d’aider. Mais ça donne une impression tellement différente des fils sur d’autres sujets. D’habitude, les autres débattent ou affinent la suggestion de quelqu’un, ou bien quelqu’un explique un truc comme sa façon de sélectionner l’historique bash, et ça vous change la vie ; alors que ces fils finissent par tourner en « c’est quand même étrange que ça marche quand on le menace, non ? »

  • Le caractère arbitraire et non déterministe des workflows LLM est vraiment dérangeant. Venant du monde de l’embarqué et des systèmes, j’ai toujours privilégié le déterminisme et la reproductibilité
    Pourtant, les agents sont formidables, et devenir « architecte de chaînes de raisonnement » est amusant. Je ne reviendrai pas en arrière. Même si le développement de l’IA s’arrêtait aujourd’hui, ma carrière ne redeviendrait sans doute jamais comme avant
  • Dans l’industrie tech, on voyait déjà ça en permanence bien avant l’arrivée des LLM
    J’ai vécu bien trop de réunions où l’on décidait non pas selon des critères objectifs et mesurables, mais parce qu’« une entreprise un peu plus connue fait comme ça ». Même des preuves montrant que cette entreprise n’applique pas réellement cette méthode de façon générale avaient étonnamment peu de poids
  • Les conseils en informatique ont toujours eu un peu cette dimension. Plus les systèmes et les résultats sont complexes, plus il devient difficile de définir clairement ce qui est « meilleur » ou « pire »
    Si l’on ajoute à cela le fait que les LLM sont fortement non déterministes, alors les conseils sur les LLM finissent pratiquement par ressembler à des conseils de jardinage
    Même les « benchmarks » s’apparentent le plus souvent à une tentative de cristalliser, avec un succès relatif, l’intuition de quelqu’un
  • Je compatis beaucoup avec cette frustration et je suis globalement d’accord. Chaque fois que j’essaie de formaliser un workflow fondé sur les LLM, je finis à nouveau déçu en constatant que personne ne semble vraiment savoir pourquoi certaines choses marchent et d’autres non
    Du coup, j’en reviens à /plan en lui disant d’écrire dans un document Markdown, pour plus tard, avant d’itérer sur l’implémentation, en espérant que d’ici le mois prochain on aura quelque chose d’un peu plus rigoureux et mieux fondé rationnellement
    Je n’utilise jamais de bâton de colle, parce que je n’en ai pas besoin. En revanche, Dawn semble assez efficace pour que les plateaux Bambu retrouvent une bonne adhérence. Je ne l’ai pas acheté exprès, je l’avais déjà pour faire la vaisselle. Comme l’IPA ne marchait pas, j’ai essayé Dawn, et ça a permis à plusieurs reprises à mes impressions de bien réadhérer. Je n’en suis pas encore à N=30
  • Il est possible que cette idée même de « rigueur partagée » dans nos têtes soit une illusion, et que les LLM avec leur problème de contexte ne fassent que le révéler
    Dans le secteur tech que je fréquente depuis des décennies, je n’ai pas vu beaucoup de rigueur. Les outils s’accumulent, les paradigmes naissent, meurent puis reviennent, et pour chaque règle de mesure il existe une règle concurrente avec une autre unité. Une fois passées la physique de la puissance et du signal, et la structure des coûts dominants des wafers de silicium, nous ne sommes presque tous, comparés à quelques disciplines bien plus anciennes, que des bricoleurs plus ou moins habiles
    Les limites de contexte, on les a gérées assez facilement jusqu’ici. Il suffit d’écrire une spécification et de limiter le périmètre. Pour qu’un LLM produise de bons résultats, il faut une spécification claire et un guidage fort
    Mais là encore, ce n’est peut-être qu’une intuition pratique de bricolage propre à l’état actuel des choses. Peut-être que dans 90 jours, même cette contrainte aura disparu, et qu’un simple prompt suffira à générer un système d’exploitation de classe mondiale, un langage de programmation, ainsi que la base formelle mathématique pour les deux

• Ils évitent le problème de taille du contexte en imposant une simple contrainte à la boucle d’agent. Dans le fil de conversation principal avec l’utilisateur, tous les appels d’outils sont bloqués. Les tâches qui nécessitent des appels d’outils n’ont lieu qu’à l’intérieur d’appels récursifs de l’agent, et seul le résultat est renvoyé à l’appelant
  Même sur une base de code de plus d’un million de LOC, ils ont pu maintenir toute la journée la même conversation de haut niveau sans atteindre une limite de tokens significative. Pas besoin non plus d’astuces de compression ou de résumé. On peut brûler 50 millions de tokens dans des appels récursifs sans même faire bouger le fil de conversation racine au-delà de 100 000 tokens
  Il faut certes refaire un travail de « bootstrap » chaque fois que l’agent redescend à Narnia, mais c’est bien plus efficace que de traîner en permanence un énorme contexte plat qui essaie de tout contenir
  La récursion est très efficace pour contrôler l’usage des tokens, mais elle a aussi ses limites. Ils n’ont jamais vu de gain au-delà d’une profondeur de récursion de 1. Ils ont vu l’agent essayer plusieurs fois, mais les performances n’étaient pas au rendez-vous. La récursion symbolique externe ne semble pas faire partie de ce sur quoi les modèles de pointe ont été entraînés. Ils excellent à simuler la récursion à l’intérieur du contexte, mais si l’objectif est de réduire l’usage des tokens, ce n’est pas du tout la bonne direction

  • Si vous utilisez Claude Code, il suffit de lui dire de faire tout le travail à l’intérieur d’un workflow. Il existe un outil pour ça, une fonctionnalité arrivée avec Opus 4.8, et cela semble aussi mieux gérer les tâches longues
    À ce stade, la conversation principale ne sert plus qu’à orchestrer la tâche
  • Intuitivement, ça se tient. Je me demande quel harness permet de définir ce genre de contrainte, et comment on le configure
  • Claude Code semble faire ça automatiquement dans certains cas. Il doit y avoir une heuristique du genre « ça va consommer beaucoup de contexte », qui lui fait décider de basculer vers un sous-agent
    Je le vois souvent dans les flux de résolution de problèmes ou d’analyse de données : il délègue la collecte et l’agrégation des données à un sous-agent, puis ne récupère qu’un résumé des résultats
    De manière similaire, l’agent principal peut aussi conserver le contexte dans un document de conception ou un fichier Markdown qu’il met à jour au fil de l’avancement. Cela permet ensuite d’effacer, redémarrer ou transmettre à tout moment
  • J’utilise une autre approche et j’essaie encore d’évaluer à quel point elle fonctionne bien. Au lieu de passer en récursion, quand le contexte devient trop gros ou qu’on se retrouve bloqué, l’agent redémarre le fil après une étape de résumé / rapport / réflexion, ce qui lui permet d’écrire les découvertes essentielles dans une mémoire persistante et de réécrire le prompt
    En quelque sorte, c’est proche d’une récursion avec optimisation d’appel terminal
    D’une certaine manière, c’est une généralisation d’une approche guidée par spécification : en plus de la spécification formelle, un buffer hérité reste en mémoire
  • Ce qui est intéressant, c’est que réduire le contexte et l’usage des tokens profite à l’utilisateur, mais va à l’encontre de l’intérêt financier des fournisseurs d’IA
    Même sans être expert, cette « astuce simple » donne l’impression de pouvoir corriger les problèmes de contexte et de permettre un contrôle bien plus fin de l’usage des tokens. Merci d’avoir partagé ce conseil dans un commentaire HN. La manière dont les gens informés utilisent les agents IA pourrait bien changer à l’avenir. C’est difficile à suivre

• Depuis qu’Anthropic propose une fenêtre de contexte d’un million de tokens dans ses abonnements, je n’ai pas eu ce genre d’expérience avec Opus. Je dépasse régulièrement 500 000 tokens, et il m’arrive d’approcher les 800 000 sans voir ce problème
  Je l’ai un peu observé au-delà de 900 000 tokens, donc proche de la vraie limite, mais pas de manière aussi sévère que ce qu’a vu l’auteur
  De toute façon, pour une tâche unique ou un groupe de tâches suffisamment liées pour partager le même contexte, il est rare de remplir la fenêtre de contexte à ce point ; en général, on est plutôt entre 200 000 et 600 000
  Cela ne veut pas dire que personne ne vit ce genre de situation, mais le fait que, pour certaines personnes, ce soit assez fréquent pour avoir son propre nom me paraît étrange

  • Je vois souvent ce genre de propos, mais j’ai vu à plusieurs reprises les modèles Opus faire des erreurs basiques de rappel avec moins de 100 000 tokens, donc ça me paraît absurde
    Personnellement, j’estime que la zone où Opus est intelligent se situe en dessous de 60 000 tokens. Opus 4.7 et 4.8 sont pires à cause d’un tokenizer plus granulaire
  • Opus 4.6 donnait l’impression d’être sous substance au-delà de 200 000, j’ai sauté la 4.7, la 4.8 tenait correctement jusqu’à environ 350 000, et Fable, dans des tests limités, était excellent même au-delà de 400 000
    La qualité semble suivre une tendance à la hausse
  • Tout le monde n’utilise pas le même modèle ni le même harness, et tout le monde n’utilise pas non plus les modèles de la même façon
    Chaque modèle et chaque version de modèle utilise une architecture d’attention différente, ce qui influe sur les performances en long contexte. La quantité et le type d’entraînement au long contexte diffèrent aussi très probablement
    Chaque agent a aussi sa propre manière de construire le contexte et sa propre implémentation de compression du contexte
    À moins de parler du même modèle, du même agent/harness et de tâches très proches, il n’y a aucune raison de s’attendre à une expérience identique du comportement des modèles face à la taille du contexte
  • Je dépasse souvent les 300 000 et j’ai déjà travaillé à 800 000, mais c’est clairement un problème observable
    Selon la nature du problème, une grande fenêtre de contexte peut fonctionner, mais j’ai l’impression qu’il est plus efficace de pencher vers des contextes plus petits, sous les 300 000
  • D’accord. La famille Claude s’améliore progressivement sur ce point à chaque release
    Opus 4.5 commençait à rater des appels d’outils en approchant de sa limite de 200 000, Opus 4.6 montait jusqu’à environ 300 000 avant de devenir confus, Opus 4.7 pouvait aller jusqu’à environ 400 000 mais entrait ensuite dans une zone stupide. Avec Opus 4.8, j’ai eu des sessions qui dépassaient confortablement les 500 000
    Je n’ai utilisé Fable que pendant un temps limité, mais j’ai eu quelques sessions qui sont montées sans difficulté jusqu’à 800 000–900 000

• Les versions récentes d’Opus tiennent le coup au-delà de 100 000, mais en général j’essaie de rester sous les 200 000
  C’est pour ça que je pense que les soi-disant systèmes de mémoire sont le plus souvent une erreur qui rend le modèle plus bête. Le modèle n’a pas de mémoire, seulement du contexte, et plus on pousse dans ce contexte des faits sans rapport, moins il reste de place pour le problème à résoudre. Moins il y a d’interférences, meilleur est le résultat
  La bonne manière de faire « se souvenir » quelque chose à un agent, c’est de lui faire documenter le travail comme le ferait un développeur humain qui veut construire un projet agréable à reprendre par d’autres développeurs. Une bonne documentation de développement avec une page d’index et un bon plan avec checklist, enregistrés sous forme de fichiers Markdown concis et commités dans le dépôt, constituent la mémoire idéale pour le modèle, ainsi que la documentation idéale pour comprendre ce qu’il a bien pu faire. C’est aussi utile quand un humain ou un autre modèle fait une revue de code, et ça n’a aucun inconvénient

  • Au moins dans mon cas, Opus continue d’écrire des choses dans la mémoire, mais il oublie constamment d’aller consulter cette mémoire avant de refaire la même erreur
    Du coup, « souviens-toi de vérifier la mémoire ! » se retrouve à nouveau enregistré dans la mémoire. Clairement, ce n’est pas un système qui fonctionne bien
  • Les systèmes de « mémoire » sont une manière pour les développeurs d’avoir l’impression qu’ils apportent leur contribution à l’IA

• Presque tous les commentaires ici s’appuient sur une expérience personnelle. À l’inverse, le billet original renvoie à deux études comparant les performances de tests standardisés sur plusieurs modèles
  Je ne peux pas dire à quel point ces tests sont bons, mais ils ne peuvent pas être pires que des preuves anecdotiques sur quelque chose d’aussi flou et subjectif que les performances des LLM

  • Pour ajouter encore une anecdote, dans tous les tests que j’ai faits, la famille Llama suivait très mal les consignes. Je ne connais pas bien les autres modèles de RULER
    Dans les résultats de Chroma, on voit Sonnet 4, et dans mon expérience aussi, Sonnet 4 était catastrophique. Le même prompt qui fonctionnait parfaitement avec Sonnet 4.5 échouait lamentablement avec Sonnet 4
    J’aimerais voir de nouveaux tests incluant à la fois les modèles SOTA et les modèles à poids ouverts. Les meilleurs modèles semblent toujours mieux suivre les instructions et moins sortir du sujet, et j’aimerais avoir des données pour étayer ça
  • Ces études datent de 2024 et 2025. Elles ne s’appliquent pas aux modèles Claude actuels

• J’obtiens de très bons résultats en agissant comme le chef de produit de l’IA et en exigeant fermement qu’elle rédige un court PRD pour chaque fonctionnalité à développer
  Ça permet de garder une trace de ce qui a été construit au fil du temps, et de moins dériver pour chaque fonctionnalité. J’ai une conversation séparée par fonctionnalité
  Pour moi, c’est un bon compromis : ça évite les digressions tout en permettant de se référer aux décisions passées quand c’est nécessaire. Ce qui me plaît moins dans l’approche de Pocock, c’est qu’elle écrit moins de PRD et cherche d’abord à s’aligner via une discussion approfondie, ce qui gaspille trop de la meilleure partie de la fenêtre initiale d’allers-retours

  • Je me demande si c’est fait de manière ad hoc, ou avec une approche plus structurée comme openspec
    Moi aussi je planifie d’abord, mais ça reste comme une liste de tâches dans la session et c’est difficile à retrouver ensuite

• Le fait de se demander ce qu’il se passe à l’intérieur de l’agent ne fera probablement plus longtemps partie du développement logiciel
  Personnellement, je considère déjà les LLM et les agents comme des boîtes noires. Je donne chaque demande de fonctionnalité à plusieurs LLM et je compare les résultats. Je n’utilise pas manuellement de « session ». Je regarde seulement le résultat. Si ça ne me plaît pas, je fais git reset --hard, je modifie le prompt, puis je relance la demande de fonctionnalité
  Je conserve des logs pour garder en permanence une idée de l’agent le plus performant, et je calcule le score ELO de l’agent qui répond le mieux à mes besoins. Ce score est ce qui m’importe ; la manière dont l’agent y parvient m’importe assez peu

  • Vu le coût réel de l’inférence, c’est une approche vraiment absurdement gaspilleuse, et ce n’est pas quelque chose dont il faut se vanter
  • Je me demande sur quel type de projet ou de travail de code tu fais ça
    J’imagine que ça peut convenir à certains types de travail front-end qui n’exigent pas beaucoup de sécurité ni d’autres vérifications
    Mais ça ne semble pas adapté à des secteurs réglementés ou à des tâches demandant une extrême prudence
  • Quel modèle est en tête actuellement ?

• Oui, la gestion du contexte est essentielle
  Je construis mon propre framework et je passe beaucoup de temps à déboguer ce problème, mais plus que la taille absolue du contexte, le vrai souci est la probabilité qu’il y ait dans la fenêtre des déchets ou de mauvaises orientations qui finissent par recouvrir ce que l’utilisateur juge important
  Ça se manifeste quand le LLM continue à refaire ce qui a échoué dans l’approche juste précédente. Si quelque chose apparaît souvent dans la fenêtre de contexte, ça prend du poids, même si c’est faux
  Il y a aussi beaucoup d’astuces, comme ne pas donner une tonne d’outils au LLM, mais lui donner un outil pour rechercher les outils à utiliser
  Mais la solution plus importante est dans le processus. Il faut utiliser quelque chose comme superpowers pour forcer le LLM à avancer étape par étape, et contrôler le contexte transmis à la suite

• J’ai créé une toute petite extension personnelle pour Pi afin d’ajouter la commande /last. Elle efface toute la session et ne garde que le dernier message de sortie de l’agent
  Ça permet une « compression » manuelle. En gros, je dis à l’agent « résume le plan discuté avec les références des fichiers à modifier », puis j’appelle /last, et ensuite je lui demande d’implémenter
  [1] https://pi.dev/

• Je n’aime pas qu’on mette tout ça dans le même sac en parlant des « modèles ». Les architectures d’attention diffèrent selon les modèles, et ça peut donc produire de très grandes différences de comportement en long contexte
  Oui, le long contexte est un problème et la qualité se dégrade sur la plupart des modèles, mais je ne généraliserais pas directement le comportement d’anciens modèles aux nouveaux