Context rot : RAG vs contexte long en 2026

Ce qu'est le context rot dans les LLM

Le context rot est la tendance, mesurée, d'un grand modèle de langage à exploiter l'information de moins en moins bien à mesure que l'entrée s'allonge, bien avant que la fenêtre de contexte ne soit pleine. Chroma Research a mis des chiffres dessus sur 18 modèles de pointe en juillet 2025, et les travaux de suivi menés jusqu'en 2026 ont affiné le constat plutôt que de l'adoucir. Un modèle annoncé à 1M de tokens ne raisonne pas sur 1M de tokens avec la qualité dont il fait preuve à 30K.

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 livre 1M de tokens sur Claude Opus 5 et Claude Sonnet 5. La famille GPT-5.6 d'OpenAI en embarque environ 1.05M. Gemini 3.1 Pro de Google en porte 1M. Llama 4 Scout de Meta en documente 10M. Ce qui n'est pas arrivé, c'est un modèle qui exploite bien la totalité.

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.

---

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

Le titre (« le context rot existe ») ne rend pas justice au travail. Dans Context Rot: How Increasing Input Tokens Impacts LLM Performance, publié le 14 juillet 2025, Kelly Hong, Anton Troynikov et Jeff Huber ont mené des expériences contrôlées sur 18 modèles, dont la famille Claude 4 plus Claude 3.7 et 3.5, o3, la famille GPT-4.1, GPT-4o, GPT-4 Turbo, Gemini 2.5 Pro et Flash, et trois tailles de Qwen3. 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 non uniforme quand l'entrée grandit. Si vous êtes venu chercher la courbe du context rot, c'est sa forme qui compte : ce n'est pas une pente linéaire douce. La précision tient, puis tombe d'une falaise, et cette falaise se situe à un endroit différent pour chaque modèle. Tracez-la et vous obtenez une descente en dents de scie, pas une rampe, ce qui explique exactement pourquoi un contrôle ponctuel à une taille de contexte ne vous apprend presque rien du comportement à une autre.

L'ampleur de la chute est importante. Sur LongMemEval, un benchmark de questions-réponses conversationnelles, l'équipe a filtré jusqu'à 306 prompts et 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 modèles ont bien traité les prompts ciblés et se sont dégradés systématiquement sur les complets. L'écart varie beaucoup selon le modèle, et Chroma a noté que les modèles Claude en présentaient la version la plus marquée. Même question, même modèle, même réponse présente dans l'entrée. Le seul changement, c'était la quantité de texte non pertinent qui l'accompagnait.

La similarité sémantique pilote la dégradation plus que la longueur. Quand l'« aiguille » est facile à distinguer de la « meule de foin », les modèles la trouvent. Quand les distracteurs ressemblent sémantiquement à la réponse, la précision chute nettement, et l'écart se creuse avec la longueur. Un seul distracteur suffit déjà à faire baisser les performances par rapport à la référence sans distracteur, et quatre aggravent l'effet. Cela rejoint Liu et al. (2024), « Lost in the Middle », dans TACL, qui a mis en évidence une courbe en U où le milieu d'un contexte long est systématiquement sous-pondéré.

Un texte structuré et cohérent dégrade l'attention plus qu'un texte mélangé. C'est le résultat qui devrait changer la façon dont les ingénieurs raisonnent. L'intuition dit qu'un document propre de 100K tokens est plus facile à exploiter qu'un document en désordre. Chroma a constaté l'inverse, systématiquement, sur les 18 modèles : mélanger 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 l'attention s'applique. La partie actionnable n'a besoin d'aucun mécanisme : un PDF net et bien mis en forme n'est pas automatiquement l'option sûre.

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 et tendaient à s'abstenir en cas d'incertitude, tandis que les modèles GPT montraient les plus élevés et tendaient à répondre avec assurance et à côté. Si vous hésitez entre les deux, vous choisissez en partie l'échec que vous préférerez déboguer.

Le benchmark Sequential-NIAH (arXiv 2504.04713) sonde la même faille sous un autre angle, en testant si les modèles savent extraire des aiguilles qui doivent ressortir dans le bon ordre. Sur six LLM et des contextes de 8K à 128K, le meilleur modèle a atteint 63,5 %. La récupération multi-étapes à distance est plus dure que ne le suggèrent les démos à une seule aiguille.

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 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. 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 (juin 2026), Shijie Xia, Yikun Wang, Zhen Huang et Pengfei Liu ont étudié quatre modèles phares sur trois benchmarks et nommé 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 teintée d'incertitude, bien avant d'avoir épuisé la fenêtre. À difficulté de requête contrôlée, ils 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 différents, et ils appellent des correctifs opposés. 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 à voler. Ils ont analysé sept méthodes de gestion du contexte réparties en trois catégories 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 compaction et l'élagage gagnent leur place comme fonctionnalités de précision, pas seulement comme leviers de coût. Les auteurs ont aussi construit une stratégie de filtrage sensible au comportement pour l'échantillonnage parallèle et mesuré un gain de 2,6 à 4,9 % 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.

---

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 au surlignage 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, comme par hasard, correspond à peu près à l'endroit où la facturation change.

---

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. Tirez plus que ce que vous 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 tournez 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.

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. 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.

« Faire confiance à la fenêtre documentée ». La limite documentée, c'est ce que vous avez le droit d'envoyer. La limite utilisable, c'est là où la qualité tient. Ce sont deux nombres différents, et un seul figure sur la fiche technique.

« 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 : fenêtres, prix et compaction

Deux choses ont bougé depuis la première version de cet article, et les deux vont dans le même sens.

Le contexte long porte désormais une falaise tarifaire publiée, chez deux fournisseurs. OpenAI facture la famille GPT-5.6 sur deux compteurs. Sous le seuil, GPT-5.6 Sol revient à $4 par million de tokens d'entrée et $20 par million en sortie. Au-dessus, le même modèle revient à $8 et $30. Terra passe de $2/$12 à $4/$18, et Luna de $0.20/$1.20 à $0.40/$1.80. Le seuil se situe à 272K tokens d'entrée, et le franchir retarife la requête entière, pas seulement le débordement. Un prompt de 272 001 tokens facture chacun de ces tokens au tarif supérieur. Rapporté à une fenêtre annoncée de 1.05M de tokens, cela représente à peu près un quart de celle-ci au prix affiché.

Google fait la même chose à un seuil plus bas. Gemini 3.1 Pro revient à $2 par million en entrée et $12 par million en sortie pour les prompts jusqu'à 200K tokens, puis $4 et $18 au-dessus. Même structure de 2x en entrée et 1,5x en sortie, 72K tokens plus tôt. Si vous avez dimensionné votre pipeline sur la falaise d'OpenAI puis changé de fournisseur, vous pouvez franchir celle de Google sans modifier une seule ligne de code.

Deux fournisseurs indépendants qui facturent le contexte long comme un premium, c'est une preuve plus forte que l'un ou l'autre pris isolément. Cela transforme un argument de qualité en argument de budget : rester sous votre budget de contexte sûr était déjà le geste qui préserve la précision, et c'est désormais aussi la différence entre une facture et deux.

Les fournisseurs livrent la gestion du contexte comme une fonctionnalité produit. La compaction d'Anthropic résume côté serveur le contexte antérieur à mesure qu'une conversation grandit. Elle est optionnelle plutôt qu'activée par défaut, mais une fois que vous l'activez, son seuil de déclenchement vaut par défaut 150K tokens sur des modèles dont la fenêtre fait 1M. Relisez : le fournisseur qui dispose d'une fenêtre d'un million de tokens fixe sa propre valeur par défaut à 15 % de celle-ci. Anthropic livre aussi l'édition de contexte, qui efface les anciens résultats d'outils ou blocs de réflexion au lieu de les résumer. Deux mécanismes différents, le même aveu de fond.

Le cache de prompt est le vrai levier de coût, et il est bien réel : les lectures d'entrée en cache coûtent environ un dixième du prix d'entrée normal sur les deux grandes API. Le cache rend les requêtes répétées sur du contenu stable bien moins chères. Il ne corrige pas le context rot, et chez OpenAI il ne vous exempte pas non plus du palier contexte long.

Ce qui n'a pas changé, c'est le résultat de fond. Aucune de ces sorties n'a apporté la preuve qu'une fenêtre plus grande corrige le context rot. Des fenêtres plus larges relèvent le plafond, la forme de la dégradation persiste, 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 uniquement 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 possible : 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 chez Google, ou sous votre budget sûr mesuré ailleurs : c'est bon.
• Juste au bord de l'un des 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.

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 le constat que les LLM exploitent le contexte long moins bien que ne le suggère le marketing. À mesure que vous injectez plus de tokens, la précision en récupération et en raisonnement se dégrade de façon non linéaire, en tombant de falaises plutôt qu'en descendant une rampe. La chute s'accélère quand le texte distracteur ressemble à la réponse, et Chroma a constaté que même une entrée cohérente et bien structurée nuisait plus à l'attention qu'une entrée mélangée, sur les 18 modèles testés. Remplir une fenêtre de 1M de tokens ne vous achète pas une réponse de qualité 1M de tokens.

Le RAG est-il dépassé en 2026 ?

Non, et les preuves pointent dans l'autre sens. 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 leur ont depuis donné raison dans leurs propres produits : la compaction optionnelle d'Anthropic résume par défaut à 150K sur un modèle à 1M de tokens, OpenAI retarife les requêtes au-delà de 272K tokens d'entrée, et Google 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 chez OpenAI vous voudrez rester sous 272K pour des raisons de facturation, et sous 200K chez Google. 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 d'entrée en cache coûtent environ un dixième du prix d'entrée normal, 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, le cache ne vous exempte pas non plus du palier tarifaire contexte long.

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 répondent avec une assurance non méritée avant d'avoir épuisé la fenêtre, à un taux qui grimpe avec la longueur du contexte. La gestion du contexte 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. 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. 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 tarifent et conçoivent désormais comme s'ils étaient d'accord avec vous. Des falaises à 272K et 200K, et un seuil de compaction par défaut à 150K, sont autant d'aveux que la fenêtre utilisable ne représente qu'une fraction de celle qui est annoncée. C'est utile, parce que cela signifie que l'architecture disciplinée est aussi la moins chère, et ces deux-là pointent rarement dans la même direction.

Si vous voulez une carte plus large de quel modèle affecter à quelle tâche, nous en tenons une 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.