Context rot des LLM : RAG vs contexte long en 2026

Ce qu'est le context rot dans les LLM

Le context rot est la baisse, mesurée, de la précision d'un grand modèle de langage à mesure que son entrée s'allonge, bien avant que la fenêtre de contexte ne soit pleine. Il découle d'une attention répartie sur davantage de tokens, de distracteurs qui ressemblent à la réponse et d'un entraînement qui récompense rarement le raisonnement sur des longueurs extrêmes. Le remède consiste à envoyer moins : récupérer et reclasser, effacer les sorties d'outils périmées, compacter ou redémarrer les longues sessions, et mesurer votre propre budget sûr au lieu de vous fier à la fiche technique.

Chroma Research a mis des chiffres dessus sur 18 modèles en juillet 2025, et le terme s'est assez répandu pour que la documentation d'Anthropic elle-même le définisse désormais : « À mesure que le nombre de tokens augmente, la précision et le rappel se dégradent, un phénomène connu sous le nom de context rot. » Une fenêtre annoncée plus grande relève le plafond de ce que vous pouvez envoyer. Elle ne promet pas la même précision en haut de cette plage qu'en bas.

La version pratique, pour quiconque doit décider quoi construire : la fenêtre de contexte documentée, c'est ce que vous avez le droit d'envoyer. Votre fenêtre utilisable, c'est là où le modèle atteint encore votre seuil de qualité. Ce sont deux nombres différents, et le second n'est en général qu'une fraction du premier.

C'est cet écart qui explique pourquoi l'argument qui circulait sur les canaux d'ingénierie fin 2024 et début 2025 (« le RAG est obsolète, collez tout dedans ») a mal vieilli. Les fenêtres sont bel et bien arrivées. Anthropic fait de 1M de tokens la valeur par défaut sur Claude Opus 5.5, Sonnet 5.5 et le nouveau Haiku 5.5. Les modèles GPT-6 d'OpenAI embarquent une fenêtre de 1,05M, dont 922K peuvent servir à l'entrée. Gemini 3.1 Pro et Gemini 3.8 Flash de Google acceptent environ 1M de tokens en entrée. Llama 4 Scout de Meta en documente 10M. Ce qui n'est pas arrivé, c'est un modèle qui exploite toutes les parties de sa fenêtre avec la même efficacité.

La question intéressante a donc cessé d'être « lequel gagne » pour devenir « quel schéma convient à cette forme de données, à ce budget de latence, à cette exigence de fraîcheur et à cette facture ». C'est ce à quoi répond la suite de cet article, en commençant par ce que la recherche a mesuré et par la façon d'y remédier.

---

Ce qu'a montré la recherche de Chroma sur le context rot

Le gros titre (« le context rot existe ») ne rend pas justice au travail. Dans Context Rot: How Increasing Input Tokens Impacts LLM Performance, un rapport technique publié le 14 juillet 2025, et l'étude que la plupart des gens désignent par « l'article sur le context rot », Kelly Hong, Anton Troynikov et Jeff Huber ont mené des expériences contrôlées sur 18 modèles : Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5 et Haiku 3.5 ; o3, GPT-4.1 avec ses versions mini et nano, GPT-4o, GPT-4 Turbo et GPT-3.5 Turbo ; Gemini 2.5 Pro, 2.5 Flash et 2.0 Flash ; et trois tailles de Qwen3. Tous les modèles n'ont pas pris part à toutes les expériences, en raison des limites de fenêtre et de budget de réflexion. Leur kit de réplication sur GitHub vous permet de tout relancer.

Quatre résultats comptent pour l'architecture.

Les performances se dégradent de façon inégale quand l'entrée grandit. Si vous êtes venu chercher la courbe du context rot, c'est sa forme qui compte : il n'existe pas de courbe unique. Chroma le résume ainsi : les modèles « n'utilisent pas leur contexte de manière uniforme ; au contraire, leurs performances deviennent de moins en moins fiables à mesure que la longueur de l'entrée augmente ». La vitesse et l'endroit de la dégradation dépendent du modèle et de la tâche, ce qui explique pourquoi un contrôle ponctuel à une taille de contexte ne vous apprend presque rien du comportement à une autre. L'équipe d'ingénierie d'Anthropic décrit le même schéma comme « un gradient de performance plutôt qu'une falaise abrupte ».

L'ampleur de la chute est importante. Sur LongMemEval, un benchmark de questions-réponses conversationnelles, l'équipe n'a retenu, après filtrage, que 306 prompts et a comparé deux versions de chacun. La version ciblée ne contient que le matériel pertinent et fait environ 300 tokens en moyenne. La version complète enfouit la même réponse dans la conversation environnante et fait environ 113K tokens en moyenne. Les performances se sont dégradées de façon constante sur les versions complètes. Les modèles Claude ont présenté l'écart le plus large, et Chroma l'attribue en grande partie à l'abstention : Claude Opus 4 et Sonnet 4 refusaient souvent de répondre plutôt que de deviner. Même question, même modèle, même réponse présente dans l'entrée. Le principal changement, c'était la quantité de texte non pertinent qui l'accompagnait.

La similarité façonne le déclin. Quand l'aiguille est sémantiquement moins proche de la question (Chroma l'a mesuré par similarité d'embeddings), la précision chute plus vite à mesure que l'entrée grandit. Les distracteurs qui ressemblent à la réponse font aussi des dégâts : un seul suffit déjà à faire baisser les performances par rapport à la référence sans distracteur, et quatre aggravent l'effet. La position, en revanche, a peu compté dans cette tâche. Chroma n'a observé aucune variation notable sur 11 positions de l'aiguille, alors même que Liu et al. (2024), « Lost in the Middle », dans TACL avait mis en évidence une courbe en U sur les questions-réponses multi-documents, où le milieu d'un contexte long est systématiquement sous-pondéré.

Un remplissage cohérent a fait plus de dégâts qu'un remplissage mélangé. C'est le résultat qui devrait changer la façon dont les ingénieurs raisonnent. L'intuition dit qu'une meule de foin cohérente devrait être plus facile à fouiller qu'une meule en désordre. Chroma a constaté l'inverse, systématiquement, sur les 18 modèles : mélanger les phrases de la meule de foin et détruire son enchaînement logique améliorait les performances. Le pourquoi reste ouvert, et Chroma va seulement jusqu'à dire que la structure d'une entrée pourrait influencer la façon dont le mécanisme d'attention s'applique. La partie actionnable n'a besoin d'aucun mécanisme : un remplissage cohérent et dans le sujet n'est pas automatiquement inoffensif.

Un dernier détail à emporter en production : les modes d'échec dépendent du modèle. Sous distracteurs, les modèles Claude ont montré les taux d'hallucination les plus bas, Claude Sonnet 4 et Opus 4 se montrant particulièrement prudents et enclins à s'abstenir en cas d'incertitude, tandis que les modèles GPT montraient les plus élevés et tendaient à donner avec assurance de mauvaises réponses. Si vous hésitez entre les deux, vous choisissez en partie l'échec que vous préférerez déboguer.

Chroma n'est pas la seule équipe à mesurer ce phénomène. Si vous cherchez un benchmark de context rot qui ressemble à votre charge de travail, voici les principaux :

C'est la dernière ligne qu'il faut retenir : même quand un modèle récupère parfaitement chaque passage pertinent, une entrée plus longue lui coûte encore de la précision.

Pour une entrée en matière plus douce, Hamel Husain a reçu Kelly Hong pour dérouler la recherche et a publié un compte rendu annoté de cette présentation. Ses conclusions rejoignent celles du rapport : les performances ne sont pas uniformes selon la longueur de contexte, la façon de présenter l'information compte, et l'ingénierie de contexte délibérée est le levier.

---

Pourquoi le contexte long échoue : le mécanisme

Le mécanisme compte parce qu'il prédit quelles charges de travail cassent.

L'attention des transformers applique un softmax sur des paires de tokens. Quand la longueur de séquence augmente, l'attention se répartit sur davantage de positions. Même avec des encodages de position relatifs comme RoPE ou ALiBi, le dénominateur du softmax grossit et le poids disponible pour un token donné diminue. À 1M de tokens, le bon token est en concurrence avec 999 999 autres pour un budget fini. Les ingénieurs d'Anthropic appellent cela un « budget d'attention » : « Chaque nouveau token introduit entame ce budget d'une certaine quantité. »

Les encodages de position étirent la portée sans supprimer le problème. RoPE se dégrade quand on extrapole très au-delà de la longueur d'entraînement : un modèle entraîné sur des séquences de 32K et déployé à 1M fait donc de l'extrapolation que les mathématiques sous-jacentes ne soutiennent pas complètement. Meta, par exemple, a pré-entraîné et post-entraîné Llama 4 Scout à 256K tout en documentant une fenêtre de 10M, si bien que tout ce qui dépasse 256K repose sur la généralisation en longueur. YaRN, l'interpolation de position et la mise à l'échelle NTK-aware aident tous, et aucun ne produit un modèle qui exploite 1M de tokens aussi bien qu'il exploite 32K.

Il y a aussi un problème de données d'entraînement. Même lorsqu'un modèle s'entraîne sur des séquences longues, les exemples exigeant un véritable raisonnement sur 800K tokens sont rares. Les modèles apprennent à utiliser les parties du contexte que leurs données d'entraînement leur ont appris à utiliser.

Le context rot est donc une propriété de l'architecture et de la distribution d'entraînement, plutôt qu'un bug que la prochaine version corrigera. Les futurs modèles repousseront la frontière, et la forme de la dégradation, elle, persistera.

---

Terminaison prématurée : ce que la recherche de 2026 a ajouté

Le résultat nouveau le plus utile depuis la première publication de cet article vient des travaux sur les agents à long horizon plutôt que du terrain des benchmarks.

Dans Diagnosing and Mitigating Context Rot in Long-horizon Search, mis en ligne en juin 2026 puis largement révisé en août, Shijie Xia, Yikun Wang, Zhen Huang et Pengfei Liu ont étudié quatre modèles phares à poids ouverts (GLM-4.7, GLM-5.0, Qwen3.5-397B-A17B et MiniMax-M2.5) sur trois benchmarks de recherche approfondie : BrowseComp, xbench-DeepSearch et BrowseComp-Plus, qui effectue ses recherches dans un corpus local fixe. Les modèles fermés ont été écartés parce que leurs traces de raisonnement sont chiffrées. La version révisée nomme un mode d'échec que la littérature antérieure avait laissé de côté : la terminaison prématurée. Sous un contexte volumineux, les modèles abandonnent, ou renvoient une réponse fausse qu'ils signalent comme incertaine, bien avant d'avoir épuisé la fenêtre. À difficulté de requête contrôlée, les auteurs ont constaté que le taux de terminaison prématurée augmente avec la longueur du contexte.

Cela recadre le problème. Le context rot recouvre deux échecs distincts, qui appellent des correctifs différents. Si le modèle ne trouve plus l'aiguille, améliorez la précision. Si le modèle cesse de chercher, il lui faut de la place et une raison de continuer à explorer. Pour un agent qui fait de la recherche multi-étapes, les confondre coûte des semaines.

Leur second résultat est celui dont il faut s'inspirer. Ils ont testé sept méthodes de gestion du contexte réparties en trois familles (compaction, élagage et isolation via des sous-agents) et conclu que ces méthodes fonctionnent surtout comme des stratégies de mise à l'échelle au moment du test : en réduisant le taux de terminaison prématurée, elles procurent au modèle davantage d'exploration. La famille la plus utile dépend du modèle. Sur le plus solide des deux modèles agentiques comparés, Qwen3.5-397B-A17B, isoler le travail dans des sous-agents a donné le meilleur score. Sur le plus faible, GLM-4.7, les sous-agents figuraient parmi les pires options, et ne conserver que les derniers résultats d'outils, accompagnés d'un résumé, offrait le meilleur équilibre entre précision et coût. Les auteurs ont aussi construit une stratégie de filtrage sensible au comportement pour l'échantillonnage parallèle, qui a relevé la précision moyenne de 2,6 à 4,9 points de pourcentage sur trois méthodes d'agrégation.

Si vous faites tourner des agents sur de longues sessions, suivez la fréquence à laquelle les vôtres s'arrêtent trop tôt. C'est une métrique bon marché, et presque personne ne l'instrumente.

Trois autres prépublications de 2026, mises en ligne entre juillet et début octobre, vont dans le même sens. Context as an Environment conserve les sorties d'outils sous forme de variables dans une session Python persistante et ne laisse entrer dans le contexte de l'agent que ce que celui-ci affiche ; avec le même modèle Qwen3.8-Max sous-jacent, cette approche a obtenu 86,7 % sur le benchmark LOCA à 256K tokens, contre 65,3 % pour un agent qui résume son historique. Stateless Language Agents reconstruit le contexte à chaque appel à partir de l'état que conserve le harnais, au lieu de faire suivre la conversation d'un appel à l'autre, et, sur l'optimisation de kernels, a atteint la performance finale de la meilleure référence avec plus de 84 % de tokens en moins. Enfin, CompactionRL traite la compaction comme une compétence à entraîner plutôt que comme une fonctionnalité à greffer après coup : son modèle GLM-4.5-Air a obtenu 6,6 points de plus sur SWE-bench Verified que le même modèle de base auquel la compaction est ajoutée au moment de l'inférence. Ce sont des prépublications, mais elles s'accordent sur la direction : garder l'ensemble de travail réduit, et apprendre au modèle à le maintenir ainsi.

---

Comment corriger le context rot dans les agents et les outils de chat

Tous les correctifs qui fonctionnent font la même chose : ils placent moins de tokens, et de meilleurs, devant le modèle. L'équipe d'ingénierie d'Anthropic le dit en une ligne dans Effective context engineering for AI agents : « Le contexte doit donc être traité comme une ressource finie aux rendements marginaux décroissants. » Ce qui change, c'est l'endroit où vous appliquez la règle.

Si vous construisez des applications LLM ou des agents :

• Envoyez moins, et choisissez bien ce que vous envoyez. Récupérez, reclassez et écartez ce dont la tâche n'a pas besoin. Le guide de Google sur le contexte long dit la même chose : « En général, si vous n'avez pas besoin de transmettre des tokens au modèle, mieux vaut éviter de les transmettre. »
• Placez les longs documents en premier et la question en dernier. Pour des entrées de 20K tokens ou plus, le guide de prompting d'Anthropic recommande de mettre les documents en haut et la requête à la fin, en notant que les requêtes placées à la fin « peuvent améliorer la qualité des réponses jusqu'à 30 % lors des tests ». Il suggère aussi de demander au modèle de citer les passages pertinents avant de répondre. Google donne le même conseil de placement pour Gemini.
• Effacez les résultats d'outils périmés. Les vieux résultats de recherche et les dumps de fichiers sont les tokens dont la suppression coûte le moins. Anthropic qualifie l'effacement des résultats d'outils de « l'une des formes de compaction les plus sûres et les plus légères » et le propose sous le nom d'édition de contexte (context editing), qui, par défaut, commence à effacer à partir de 100 000 tokens d'entrée et conserve les trois utilisations d'outils les plus récentes.
• Compactez avant que la fenêtre ne se remplisse, et testez le résumé. L'API d'Anthropic propose une compaction à seuil (déclenchement par défaut : 150 000 tokens d'entrée) et, depuis septembre 2026, une compaction à la demande. L'API Responses d'OpenAI compacte côté serveur quand vous définissez un compact_threshold sous context_management, et expose aussi un endpoint de compaction autonome. Un résumé fait perdre de l'information, alors vérifiez ce qu'il laisse tomber. Anthropic conseille de commencer par maximiser le rappel, puis de couper le superflu.
• Gardez les règles et l'état hors du résumé. The Compaction Cliff in Long-Running AI Agent Memory, un article de CIKM 2026 mis en ligne sur arXiv en août, a constaté que le prompt de compaction de Claude Code sur Sonnet 4.6 conservait, après une passe, 53 % des règles de sécurité présentes dans des configurations d'agents en production, et 10 % après cinq. Le correctif proposé par les auteurs épingle mot pour mot les règles de sécurité et les procédures et compresse le reste selon son type ; il a maintenu un rappel de 96 % sur cinq passes. Épinglez donc les règles là où l'agent les relit, et consignez l'avancement dans des notes, un outil de mémoire ou git plutôt que dans l'historique du chat.
• Déléguez l'exploration à des sous-agents. Un sous-agent consomme son propre contexte pour la recherche et renvoie, selon les mots d'Anthropic, « un résumé condensé et distillé de son travail (souvent 1 000 à 2 000 tokens) ». Testez-le toutefois sur votre modèle : dans l'article sur la terminaison prématurée, les sous-agents ont obtenu le meilleur score sur le plus solide des deux modèles comparés et figuraient parmi les pires options sur le plus faible. Nous expliquons comment sous-agents, skills et hooks s'articulent dans notre guide de l'agentic engineering.
• Mesurez par taille de contexte. Faites tourner votre propre évaluation à plusieurs longueurs d'entrée et journalisez les arrêts précoces. Sans cela, chacun des correctifs ci-dessus reste une supposition.

Anthropic a publié des chiffres pour cette combinaison. Dans une évaluation interne de recherche agentique, son outil de mémoire associé à l'édition de contexte a amélioré les performances de 39 % par rapport à la référence, et l'édition de contexte seule de 29 %. Dans un test de recherche web sur 100 tours, l'édition de contexte a réduit la consommation de tokens de 84 %. Ce sont les chiffres d'un fournisseur sur son propre produit : lisez-les comme une direction plutôt que comme une promesse.

Si vous utilisez des assistants de chat ou des agents de code :

• Un chat par tâche. Le guide des bonnes pratiques de Claude Code l'affirme : « Une session propre avec un meilleur prompt surpasse presque toujours une longue session chargée de corrections accumulées. » Le guide Codex d'OpenAI va dans le même sens : « Gardez un chat par unité de travail cohérente. »
• Repartez de zéro après deux corrections ratées. C'est la règle empirique de Claude Code lui-même : lancez /clear et rédigez un meilleur prompt initial qui intègre ce que vous avez appris.
• Compactez à vos conditions. Claude Code, Codex et Cursor résument tous automatiquement à l'approche de la limite. Compacter plus tôt avec une consigne de focalisation (par exemple, /compact Focus on the API changes) vous donne voix au chapitre sur ce qui survit. Claude Code prévient que « les instructions détaillées données au début de la conversation peuvent être perdues » : les règles persistantes ont donc leur place dans un fichier que l'agent relit, comme CLAUDE.md, pas dans le chat.
• Surveillez la jauge. /context dans Claude Code montre ce qui remplit la fenêtre, et /status dans Codex indique quelle part vous en avez utilisée. Cursor place à côté du champ de saisie un anneau de contexte qui ouvre une ventilation détaillée quand vous cliquez dessus.

Les commandes et les valeurs par défaut changent d'une version à l'autre : considérez ce tableau comme exact en octobre 2026 et vérifiez la documentation de votre outil après une mise à jour.

---

Là où le RAG l'emporte encore

Tout cela posé, la génération augmentée par récupération garde toute sa place. Voici les cas où elle continue de gagner.

Corpus multi-documents à grande échelle. Si votre base de connaissances compte 50 000 documents pour un total de 500M de tokens, elle n'entre dans aucune fenêtre. La récupération est la seule architecture viable.

Fraîcheur et récence. Les bases vectorielles se mettent à jour de façon incrémentale. Un prompt à contexte long doit être reconstruit dès que le contenu change. Pour tout ce qui bouge toutes les heures (actualités, catalogues, tickets de support, code), la récupération absorbe le changement à bas coût.

Coût. Le coût d'entrée croît avec le nombre de tokens d'entrée, et au-delà de certains seuils il croît plus vite que linéairement. Si 95 % de vos requêtes trouvent leur réponse dans 5K tokens pertinents, la récupération revient bien moins cher, d'un large facteur, sans perte de précision.

Citation et provenance. La récupération vous rend une liste structurée de sources que vous pouvez afficher, lier et classer, alors qu'ancrer une réponse en contexte long dans des sources précises demande de la tuyauterie supplémentaire. C'est la raison pour laquelle un outil de lecture qui conserve le passage et sa source vaut mieux qu'un outil qui conserve un résumé : quand vous posez des questions sur tout ce que vous avez enregistré dans Glasp, chaque réponse peut renvoyer à la source dont elle est issue.

Contrôle d'accès et multi-tenant. Si votre corpus a une visibilité par utilisateur, par tenant ou par rôle, vous ne pouvez pas tout déverser. La récupération filtre selon la politique avant que le modèle ne voie quoi que ce soit. C'est non négociable en B2B.

Raisonnement multi-corpus. Quand la réponse s'étale sur un fil Slack, une page Notion, un ticket Linear et une PR GitHub, la récupération fait le pont.

Cochez l'une de ces cases et le RAG n'est pas optionnel. La question devient comment rendre la récupération bonne, pas s'il faut en faire.

---

Là où le contexte long l'emporte

Le contexte long a des charges de travail où il est tout simplement la bonne réponse.

Raisonnement approfondi sur un seul document. Lire un contrat de 100 pages et répondre en croisant les clauses. Analyser un article scientifique. Décortiquer une conférence de résultats. Quand la réponse relie deux paragraphes distants de 80 pages, le découpage en chunks coupe souvent le lien.

Compréhension de code au sein d'un dépôt. Beaucoup de tâches de code exigent d'avoir en même temps les imports, les types, les définitions et les sites d'appel. Découper par fichier perd les relations entre fichiers.

Continuité conversationnelle. Les longues sessions d'agent bénéficient d'un véritable historique. La récupération sur l'historique de conversation est fragile, parce qu'il vous faut d'ordinaire les 50 derniers tours, pas les 50 sémantiquement les plus proches.

Raisonnement exploratoire quand vous ne connaissez pas encore la requête. Si vous ne pouvez pas écrire la requête à l'avance, la récupération est difficile à viser. Le contexte long laisse le modèle explorer.

Renvois internes au sein d'une unité cohérente. Un chapitre de manuel, un article, un mémoire juridique. Les découper puis les réassembler tend à perdre l'argumentation.

Heuristique grossière : si vos données forment un seul document logique et qu'elles tiennent dans votre budget sûr mesuré, le contexte long est l'architecture la plus propre.

---

Le schéma hybride que la plupart des équipes adoptent

Le choix par défaut en 2026 pour les systèmes sérieux n'est ni le RAG pur ni le contexte long pur. Récupérez un ensemble de tokens substantiel mais borné, puis raisonnez dessus.

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Chaque étage couvre le mode d'échec de l'autre. La récupération ramène un corpus trop gros pour n'importe quelle fenêtre à quelque chose de gérable. Raisonner sur l'ensemble récupéré restaure le raisonnement inter-chunks que le RAG classique top-5 jette à la poubelle.

La décision porteuse, c'est la taille de l'ensemble récupéré. Trop peu de tokens et vous avez simplement reconstruit du RAG top-5. Trop, et vous voilà dans la zone de context rot, à payer plus cher pour une réponse moins bonne. Une règle empirique praticable, que la section suivante transforme en mesure : prévoyez un budget sûr autour de 20 à 40 % de la fenêtre documentée, puis vérifiez-le sur vos propres données. Pour un modèle à fenêtre de 200K, cela fait 40K à 80K. Pour un modèle à fenêtre de 1M, cela fait 200K à 400K, ce qui, justement, correspond à peu près à l'endroit où la facturation change chez OpenAI et sur Gemini 3.1 Pro.

---

Régler l'hybride : chiffres et heuristiques

Ce ne sont pas des vérités universelles. Ce sont des points de départ qui tiennent en production.

Taille de chunk. 500 à 1 500 tokens pour de la prose. 200 à 500 pour du code, par fonction ou par bloc logique. 1 500 à 3 000 pour du texte juridique ou académique où le contexte interne au chunk porte du sens. Chevauchement de 10 à 20 %.

Récupération top-k. Ramenez plus de candidats que vous n'en enverrez. Récupérez les 50 à 200 meilleurs, puis reclassez. Un cross-encoder coûte plus cher par paire qu'un modèle d'embedding et se montre nettement meilleur sur la pertinence fine.

Ratio reclassement/contexte. Gardez les 20 à 100 meilleurs chunks après reclassement. Le nombre exact découle de la taille des chunks et de votre budget sûr.

Récupération hybride. Combinez dense et creux (BM25, SPLADE) avec une fusion par rang réciproque. Le dense seul rate les correspondances exactes comme les références produit, les codes d'erreur et les noms propres. Le creux seul rate les paraphrases.

Deux de ces molettes méritent mieux qu'une puce, parce que c'est là que les équipes perdent de la précision sans s'en apercevoir.

La première est votre budget de contexte sûr, et la seule façon honnête de le fixer est de le mesurer. Construisez un petit jeu d'évaluation de questions qui exigent de raisonner sur plusieurs chunks, puis notez la précision à 16K, 32K, 64K, 128K et 256K de contexte bourré. Prenez la plus grande taille qui passe encore votre seuil et restez 20 % en dessous pour garder de la marge. Ce nombre mesuré devrait atterrir près de la règle des 20 à 40 % ci-dessus, et quand ce n'est pas le cas, faites confiance à votre évaluation plutôt qu'à l'heuristique. Si vous n'avez pas encore de harnais d'évaluation, notre guide du stack d'évaluation LLM passe l'outillage en revue.

La seconde, c'est ce qui se passe quand vous changez de modèle, et cela a piégé des équipes en 2026. Le tokenizer d'Anthropic a changé avec Claude Opus 4.7, et le même texte se traduit désormais par 1,0 à 1,35 fois autant de tokens selon le contenu, ce qu'Anthropic résume par environ 30 % de plus. Haiku 5.5, sorti le 7 octobre, utilise lui aussi le nouveau tokenizer : un pipeline qui monte en version depuis Haiku 4.5 compte donc environ 30 % de tokens en plus pour le même texte. Vos documents n'ont pas grossi. Votre budget a rétréci. Si vous avez figé un plafond de tokens il y a un an et remplacé le modèle en dessous, ce plafond veut dire autre chose aujourd'hui, et rien dans vos logs ne vous l'annoncera.

Court-circuitez complètement la récupération quand la requête le dit. « Résume le document que je viens de téléverser » est une tâche mono-document. Détectez ces cas avec un petit classifieur, sautez la récupération, gagnez de la latence et évitez de faire remonter du bruit sans rapport.

Couches de résumé et d'élagage. Pour les historiques très longs, compressez le matériel ancien avant l'assemblage. Les résumés coûtent aussi des tokens, alors mesurez s'ils aident réellement.

---

Les anti-patterns que les ingénieurs continuent de livrer

Quelques pièges reviennent assez souvent pour mériter un nom.

« Tout balancer dans le contexte ». Tentant après chaque sortie qui double la fenêtre. La dégradation est silencieuse, donc vous passez les contrôles ponctuels et vous échouez en production exactement sur les requêtes qui demandaient un raisonnement inter-contexte. Lancez une évaluation à votre taille cible avant de livrer.

« Toujours utiliser du RAG ». La récupération réflexe rate les cas mono-document. Indexer un PDF de 50 pages et en tirer les 5 meilleurs chunks vaut en général mieux que rien, et perd face à l'envoi pur et simple du PDF.

« Ignorer le nombre de tokens assemblés ». Les équipes règlent le top-k sur « ce qui rentre », puis découvrent trois mois plus tard que leur prompt moyen fait 350K tokens, que la précision a discrètement glissé et que la facture a doublé à un seuil que personne n'avait lu. Suivez la taille du contexte assemblé comme une métrique de premier ordre et posez une alerte dessus.

« Laisser la compaction automatique s'en charger ». La compaction automatique maintient une session en vie. Elle ne la maintient pas précise. Les résumés laissent tomber des instructions, et l'article « Compaction Cliff » a vu la rétention des règles chuter passe après passe. Décidez de ce qui doit survivre, et stockez-le hors de la conversation.

« Sauter les évaluations parce que le modèle est bon maintenant ». Les montées de version changent l'architecture optimale, et parfois changent votre comptabilité de tokens à votre insu. Réévaluez quand les modèles changent.

« Supposer qu'un échec silencieux est un échec sans danger ». Sous distracteurs, certains modèles hallucinent et d'autres s'abstiennent, et sur les tâches à long horizon certains s'arrêtent simplement plus tôt. Sachez ce que fait le vôtre, et instrumentez-le.

---

Ce qui a changé en 2026 : modèles, prix et compaction

L'essentiel de ce qui suit a changé entre septembre et début octobre 2026, quand Anthropic, OpenAI et Google ont tous livré de nouveaux modèles, et tout ne va pas dans le même sens.

La gamme de modèles s'est renouvelée. Anthropic a sorti Claude Fable 5.1 le 1er septembre, Opus 5.5 le 22 septembre, Sonnet 5.5 le 28 septembre et Haiku 5.5 le 7 octobre, tous avec des fenêtres de 1M de tokens. OpenAI a livré GPT-6 Astra le 3 septembre, GPT-6 Sol et Luna le 22 septembre, et GPT-6.1 Sol le 29 septembre, chacun avec une fenêtre de 1,05M et jusqu'à 922K tokens en entrée. Google a fait passer Gemini 3.8 Flash en disponibilité générale le 2 septembre, tandis que Gemini 3.1 Pro reste un modèle en préversion.

Les meilleurs scores de récupération ont bondi, et l'écart entre modèles est énorme. Sur OpenAI MRCR v2, son propre test à 8 aiguilles, OpenAI annonce 96,3 % pour GPT-6 Astra entre 512K et 1M de tokens, contre 73,8 % pour GPT-5.6 Sol. La fiche de modèle de Google évalue Gemini 3.1 Pro sur le MRCR v2 (8 aiguilles) propre à Google, un jeu de données différent malgré le nom commun : 84,9 % en moyenne jusqu'à 128K et 26,3 % à 1M. L'écart entre fournisseurs est donc un signal, pas une comparaison directe. Les deux séries de chiffres sont produites par les fournisseurs eux-mêmes (OpenAI retient le meilleur score, quel que soit le niveau d'effort de raisonnement), et MRCR mesure la capacité à trouver et à reproduire le bon passage, pas à raisonner sur un document. Le context rot n'a pas disparu. Il est devenu quelque chose qu'il faut mesurer modèle par modèle.

Les falaises tarifaires diffèrent désormais d'un fournisseur à l'autre. OpenAI retarife toujours la requête entière au-delà de 272K tokens d'entrée, et sur les modèles GPT-6 cela signifie « 2x les tarifs d'entrée et de cache, et 1,5x la sortie ». GPT-6.1 Sol passe de $2 et $10 par million de tokens d'entrée et de sortie à $4 et $15, et GPT-6 Astra de $10 et $50 à $20 et $75. Les $4 et $20 de GPT-5.6 Sol sont un tarif promotionnel valable au moins jusqu'au 21 novembre 2026, et au-delà du même seuil, ce tarif passe à $8 et $30. Google facture les prompts Gemini 3.1 Pro de plus de 200K à $4 et $18 au lieu de $2 et $12, mais Gemini 3.8 Flash n'a pas de palier de ce genre. Anthropic facture la fenêtre complète de 1M aux tarifs standard sur Claude 4.6 et les versions ultérieures (« Une requête de 900k tokens est facturée au même tarif par token qu'une requête de 9k tokens », selon sa page de tarifs), à une exception près : sur Haiku 5.5, les prompts de plus de 100 000 tokens coûtent cinq fois plus cher, $0.50 et $2.50 au lieu de $0.10 et $0.50.

La compaction est devenue un produit. Les réglages sont traités dans les correctifs ci-dessus. Ce qui a changé, c'est que les fournisseurs exécutent désormais la compaction à votre place. La documentation d'Anthropic recommande sa nouvelle compaction à la demande « partout où elle est disponible ». L'API Responses d'OpenAI renvoie le contexte compacté sous la forme d'un élément opaque qui n'est pas censé être lisible par un humain, et son API Agents, en bêta publique depuis le 10 septembre, indique : « OpenAI gère l'orchestration des sessions, la compaction du contexte et la reprise. » Notez toutefois la valeur par défaut : un fournisseur doté d'une fenêtre d'un million de tokens déclenche sa compaction à seuil à 150K.

Le cache est devenu moins cher. Il ne corrige toujours pas le context rot. Les lectures en cache coûtent un dixième du prix d'entrée de base sur la plupart des modèles d'Anthropic, un vingtième sur Opus 5.5 et Sonnet 5.5, et un quarantième sur Fable 5.1. OpenAI facture un dixième sur la plupart des modèles et un vingtième sur GPT-6.1 Sol, et depuis GPT-5.6, il facture les écritures en cache à 1,25 fois le tarif d'entrée. Le cache rend les requêtes répétées sur du contenu stable bien moins chères. Il ne change rien à ce que le modèle fait d'une entrée longue, et chez OpenAI, les tokens en cache doublent de prix au-delà de 272K, exactement comme l'entrée hors cache.

Ce qui n'a pas changé, c'est le résultat de fond. De meilleurs modèles déplacent la courbe, une fenêtre plus grande ne corrige rien à elle seule, et il vous faut toujours de la récupération pour les charges fraîches, multi-tenant et multi-sources.

C'est la même discipline que celle qu'on retrouve dans l'ingénierie de contexte en général : ce que vous laissez hors du prompt compte autant que ce que vous y mettez. C'est aussi pourquoi la couche de récupération mérite la même vigilance que n'importe quel autre chemin d'entrée, puisque l'injection de prompt indirecte arrive par les documents récupérés plutôt que par vos utilisateurs.

---

Un cadre de décision applicable dès aujourd'hui

Déroulez ceci de haut en bas pour toute nouvelle fonctionnalité LLM.

Étape 1 : quelle est la taille de votre corpus ?

• Moins de 100K tokens au total : sautez la récupération, utilisez le contexte long.
• 100K à 1M de tokens : cela dépend de la fraîcheur, passez à l'étape 2.
• Plus de 1M de tokens : la récupération est obligatoire.

Étape 2 : quelle fraîcheur les données doivent-elles avoir ?

• Horaire ou plus rapide : récupération. Reconstruire de longs prompts coûte trop cher.
• Quotidienne à hebdomadaire : les deux schémas fonctionnent.
• Statique : le contexte long avec cache de prompt est bon marché et propre.

Étape 3 : quelle est la forme des requêtes ?

• Raisonnement approfondi mono-document : penchez vers le contexte long.
• Synthèse multi-documents : penchez vers l'hybride.
• Consultation ou recherche de fait : penchez vers le RAG classique.
• Exploratoire : contexte long si l'ensemble de documents est borné, sinon hybride.

Étape 4 : avez-vous besoin de citations ou de contrôle d'accès ?

• Oui à l'un des deux : la récupération est obligatoire. Rajouter après coup des citations et un filtrage par utilisateur sur une conception reposant uniquement sur le contexte long est pénible.

Étape 5 : quel est votre budget de latence ?

• Sous 1 seconde : RAG classique.
• 1 à 5 secondes : l'hybride est faisable.
• Plus de 5 secondes : n'importe quel schéma fonctionne.

Étape 6 : quel est votre plancher de précision sur les requêtes longues ?

• Haute précision sur du raisonnement multi-étapes au-delà de 50K tokens : hybride avec un reranker.
• Au mieux : le RAG classique suffit en général.

Étape 7 : où atterrit votre prompt assemblé par rapport à la falaise tarifaire ?

• Sous 272K chez OpenAI, sous 200K sur Gemini 3.1 Pro, sous 100K sur Claude Haiku 5.5, ou sous votre budget sûr mesuré ailleurs : c'est bon.
• Juste au bord de l'un de ces seuils : ajoutez un reranker et réduisez l'ensemble récupéré. Vous obtiendrez en général une meilleure réponse et une facture plus légère en même temps.

Étape 8 : cela tournera-t-il en session longue ou en agent ?

• Oui : décidez dès le départ ce qui est effacé (anciens résultats d'outils), ce qui est compacté, ce qui vit hors de la conversation (règles, avancement) et quand l'agent repart de zéro. Journalisez les arrêts précoces.
• Non : les requêtes ponctuelles n'ont besoin que des étapes 1 à 7.

La plupart des systèmes en production atterrissent sur l'hybride, parce que les charges réelles portent au moins une contrainte qui casse le contexte long pur (multi-tenant, fraîcheur, coût, citation) et au moins une qui casse le RAG top-k pur (raisonnement mono-document, requêtes inter-contexte, exploration).

Il existe une version humaine de cette même compétence. Décider de ce qui mérite de passer devant un processus de raisonnement, c'est ce que les lecteurs attentifs ont toujours fait à la main, et le surlignage est cette décision rendue explicite. Le surligneur web de Glasp conserve les passages que vous avez jugés dignes d'être gardés plutôt que la page entière, ce qui revient à faire de la récupération avec un reranker humain. Si vous voulez pointer votre propre outillage sur cet ensemble, le connecteur MCP de Glasp expose vos surlignages directement à un LLM. Nous avons détaillé ce montage dans transformer vos notes en serveur MCP.

---

Questions fréquentes

Qu'est-ce que le context rot dans les LLM ?

Le context rot est la baisse, mesurée, de la qualité avec laquelle un LLM exploite son entrée à mesure que celle-ci grandit, bien avant que la fenêtre de contexte ne soit pleine. La précision en récupération et en raisonnement décline de façon inégale, dans des proportions qui varient selon les modèles, et plus vite quand le texte distracteur ressemble à la réponse. Chroma a constaté qu'une meule de foin cohérente faisait plus de dégâts qu'une meule mélangée sur les 18 modèles testés, et la documentation d'Anthropic définit désormais le terme directement : « À mesure que le nombre de tokens augmente, la précision et le rappel se dégradent, un phénomène connu sous le nom de context rot. » Remplir une fenêtre de 1M de tokens ne vous achète pas une réponse de qualité 1M de tokens.

Comment corriger le context rot ?

Envoyez moins de tokens, et de meilleurs. Pour les applications et les agents, cela veut dire récupérer et reclasser au lieu de bourrer le contexte, placer les longs documents avant la question, effacer les résultats d'outils périmés, compacter avant que la fenêtre ne se remplisse, garder les règles et l'avancement hors de la conversation, et confier l'exploration à des sous-agents. Pour les outils de chat et de code, cela veut dire un chat par tâche, repartir de zéro après deux corrections ratées, compacter tôt avec une consigne de focalisation, et conserver les règles persistantes dans un fichier que l'agent relit, comme CLAUDE.md.

Les modèles récents comme Claude Opus 5.5 ou GPT-6 corrigent-ils le context rot ?

Aucun modèle n'est immunisé, mais l'écart entre modèles est large. OpenAI annonce 96,3 % pour GPT-6 Astra sur son MRCR à 8 aiguilles entre 512K et 1M de tokens, tandis que la fiche de modèle de Google montre Gemini 3.1 Pro à 26,3 % à 1M sur la version du test propre à Google. Les jeux de données diffèrent, mais l'écart est trop grand pour être ignoré. La documentation d'Anthropic décrit le context rot comme une propriété générale des entrées qui s'allongent, et celle de Claude Code précise, à propos de la fenêtre de contexte, que les performances « se dégradent à mesure qu'elle se remplit ». Mesurez le modèle que vous utilisez réellement, sur des entrées qui ressemblent aux vôtres.

Le RAG est-il toujours pertinent en 2026 ?

Oui. La récupération reste obligatoire pour les corpus qui dépassent n'importe quelle fenêtre, pour les données qui changent toutes les heures, pour le contrôle d'accès par tenant et pour la citation. Ce qui est dépassé, c'est le RAG classique top-5 comme unique schéma. Le choix par défaut aujourd'hui est hybride : récupérer un ensemble borné, puis raisonner sur sa totalité. Des fenêtres de contexte plus grandes ont changé la quantité que vous récupérez, pas le fait de récupérer.

Le contexte long remplace-t-il le RAG ?

Pas dans le cas général. Le rapport Context Rot de Chroma a montré des performances qui se dégradent bien avant que la fenêtre ne se remplisse, et les fournisseurs conçoivent leurs produits comme s'ils étaient d'accord : la compaction à seuil d'Anthropic se déclenche par défaut à 150K sur des modèles à 1M de tokens, OpenAI retarife les requêtes au-delà de 272K tokens d'entrée, et Google facture plus cher les prompts Gemini 3.1 Pro au-delà de 200K. Le contexte long remplace bel et bien le RAG pour un document unique et borné qui tient dans votre budget sûr mesuré.

Quelle taille doit faire mon ensemble récupéré avant que le context rot ne s'installe ?

Testez votre modèle précis, mais un point de départ raisonnable est de 20 à 40 % de la fenêtre documentée. Cela fait 40K à 80K pour un modèle à 200K et 200K à 400K pour un modèle à 1M, sachant que, pour des raisons de facturation, vous voudrez rester sous 272K chez OpenAI, sous 200K sur Gemini 3.1 Pro et sous 100K sur Claude Haiku 5.5. Construisez une petite évaluation de questions multi-sauts, mesurez la précision à différentes tailles de contexte et retenez la plus grande taille qui passe encore votre seuil.

Le cache de prompt corrige-t-il le context rot ?

Non. Le cache corrige le coût, pas la précision. Les lectures en cache coûtent désormais entre un dixième et un quarantième du prix d'entrée normal selon le modèle, donc les requêtes en contexte long sur du contenu stable deviennent bien moins chères et l'avantage de coût du RAG se resserre. Le modèle lit toujours le même contexte long et se dégrade de la même façon : vous payez moins pour la même réponse, tout aussi faible. Chez OpenAI, les tokens en cache doublent eux aussi de prix au-delà de 272K.

Faut-il utiliser un reranker avant d'envoyer en contexte long ?

Pour la plupart des systèmes hybrides en production, oui. Un cross-encoder qui note vos 50 à 200 meilleurs chunks récupérés améliore nettement ce qui parvient à l'étage de raisonnement. Sauter le reclassement revient en général à bourrer plus de tokens pour compenser une précision plus faible, ce qui vous pousse à la fois vers la zone de context rot et vers la falaise tarifaire. C'est l'un des changements au plus fort impact que vous puissiez apporter à un pipeline hybride.

Mon agent s'arrête tôt sur les tâches longues. Est-ce du context rot ?

Probablement, et cela porte désormais un nom. L'article de 2026 Diagnosing and Mitigating Context Rot in Long-horizon Search l'appelle la terminaison prématurée : sous un contexte lourd, les modèles abandonnent ou renvoient une réponse fausse qu'ils signalent comme incertaine avant d'avoir épuisé la fenêtre, à un taux qui grimpe avec la longueur du contexte. La gestion du contexte (compaction, élagage ou sous-agents) aide principalement en réduisant ce taux, pour que l'agent continue d'explorer. Instrumentez les arrêts précoces comme une métrique à part entière.

---

Pour conclure

Chaque sortie dotée d'une fenêtre plus grande porte la même promesse implicite : arrêtez de concevoir, déversez tout. Chroma a mis des chiffres précis sur les raisons pour lesquelles cette promesse n'a pas tenu, les travaux de 2026 ont ajouté un second mode d'échec que personne ne surveillait, et les mathématiques sous-jacentes (dilution du softmax, extrapolation de position, distribution d'entraînement) disent qu'elle ne tiendra pas davantage à 100M de tokens.

Reste la réponse ennuyeuse et productive. Construisez la récupération. Réglez-la. Ajoutez un reranker. Effacez ce dont le modèle n'a plus besoin, et gardez hors de la conversation ce qu'il ne doit jamais perdre. Choisissez un budget de contexte sûr en le mesurant plutôt qu'en faisant confiance à une fiche technique, et remesurez quand le modèle ou son tokenizer change, ce qui, entre septembre et début octobre 2026, s'est produit chez Anthropic, OpenAI et Google à la fois. Envoyez le plus petit ensemble de tokens pertinents qui contienne la réponse. Laissez le modèle raisonner dessus. Citez les sources.

La nouveauté de 2026, c'est que les fournisseurs conçoivent désormais comme s'ils étaient d'accord avec vous. Le seuil d'OpenAI à 272K, celui de Google à 200K sur Gemini 3.1 Pro, celui de Haiku 5.5 à 100K, et une compaction déclenchée par défaut à 150K sur les modèles Claude à un million de tokens sont autant d'aveux que la fenêtre utilisable ne représente qu'une fraction de celle qui est annoncée. La tarification uniforme d'Anthropic sur ses plus grands modèles supprime la falaise tarifaire, mais pas le coût en précision, et moins de tokens coûtent toujours moins cher à tarif uniforme. L'architecture disciplinée est donc aussi la moins chère, et ces deux-là pointent rarement dans la même direction.

Si vous voulez une cartographie plus large indiquant quel modèle affecter à quelle tâche, nous en tenons une à jour dans la matrice tâches et modèles d'IA. Les décisions d'architecture survivent aux sorties de modèles. Réussissez-les et la prochaine montée de version sera une amélioration gratuite plutôt qu'une réécriture forcée.