Context rot : pourquoi l’IA perd le fil des longues conversations

Le context rot peut rendre un agent moins précis alors même que son entrée tient dans la fenêtre de contexte annoncée. L’étude de Chroma sur 18 modèles de langage a montré que leur fiabilité variait avec la longueur de l’entrée. En pratique, il s’agit de conserver les éléments nécessaires à la prochaine action tout en allégeant l’historique sans rapport avec elle.

Qu’est-ce que le context rot en IA ?

Le context rot désigne une baisse de fiabilité à mesure que la quantité d’informations fournies à un modèle de langage augmente. Cette dégradation du contexte peut se traduire par des faits ignorés, des rapprochements erronés ou des réponses qui ne respectent plus une décision déjà prise. Le modèle peut encore accepter une longue conversation tout en ayant davantage de mal à en exploiter correctement le contenu.

La fenêtre de contexte est l’espace de travail dont dispose le modèle pour traiter une requête. Elle peut contenir des instructions, l’historique de la conversation, des documents et les résultats d’outils. Un token est une unité de contenu traitée par le modèle, souvent un fragment de mot. Notre guide de la fenêtre de contexte détaille ce qui occupe cet espace.

Imaginez une cellule de crise dont le mur affiche le plan en cours à côté d’hypothèses abandonnées, de chronologies dépassées et d’anciens logs. Agrandir le mur permet d’y conserver davantage de documents. Cela n’indique pas à la personne qui prend le relais quelle décision fait encore autorité.

Cette distinction compte lorsqu’on débogue un agent. Si le fait nécessaire a été supprimé avant que le modèle reçoive la requête, examinez la troncature ou la récupération d’informations. Si ce fait était présent, mais que la réponse l’a ignoré ou mal exploité, examinez la façon dont le modèle a traité le contexte fourni. Aucun de ces symptômes ne suffit, à lui seul, à prouver un problème lié à la longueur.

Documentation vérifiée le 24 octobre 2026 : les recommandations de l’éditeur présentées ci-dessous ont été vérifiées dans la documentation en ligne d’Anthropic. Les exemples de workflows sont des propositions de conception, pas des résultats observés en production.

Étude sur le context rot : que montrent les résultats ?

Le rapport de Chroma, publié le 14 juillet 2025, montre que des correspondances sémantiques plus difficiles et des éléments trompeurs d’apparence pertinente rendaient la recherche d’informations moins fiable dans les entrées longues. Ces tâches contrôlées fournissent des éléments utiles, mais ne constituent pas un benchmark de votre agent. Étude originale.

Dans sa version nettoyée du benchmark conversationnel LongMemEval, Chroma a comparé 306 prompts d’environ 113 000 tokens en moyenne à des versions ciblées d’environ 300 tokens en moyenne. Les entrées ciblées ont obtenu de meilleurs scores sur l’ensemble des modèles évalués. Point essentiel : ces entrées courtes provenaient de passages annotés comme pertinents et d’ajustements manuels, pas d’un système de récupération d’informations évalué automatiquement. Méthode et résultats de l’étude.

Ce que l’étude de Chroma ne permet pas de conclure

Le rapport n’établit ni le mécanisme sous-jacent ni un nombre universel de tokens en deçà duquel la fiabilité serait assurée. Dans son expérience sur du texte répété, la sortie s’allonge aussi avec l’entrée, contrairement aux tests de recherche d’informations à réponse courte. Limites de la recherche et description des tâches.

Pour qui développe un agent, la question utile est de savoir si le système peut trouver et préserver les éléments nécessaires. Un graphique comparant des éléments soigneusement sélectionnés à un historique complet ne dit pas si votre index de recherche, vos filtres ou votre outil de résumé sauront sélectionner les bons passages. Cette sélection doit faire l’objet de sa propre évaluation.

Pourquoi un contexte plus long peut-il être plus difficile à exploiter ?

Les informations pertinentes doivent se distinguer de tout ce qui les entoure. Un ancien plan de déploiement peut ressembler davantage au plan actuel qu’un document sans rapport avec lui. Le risque ne consiste pas seulement à manquer une phrase : il peut aussi s’agir d’appliquer la mauvaise phrase à la situation présente.

Dans ses recommandations sur l’ingénierie du contexte, Anthropic cite les contraintes d’architecture et un entraînement portant principalement sur des séquences courtes parmi les facteurs qui compliquent l’exploitation des contextes longs. L’entreprise décrit une perte de précision progressive, plutôt qu’un seuil unique au-delà duquel les capacités disparaîtraient. Ces explications aident à raisonner ; elles ne démontrent pas une causalité entièrement élucidée.

Prenons un agent de support dont l’historique contient un diagnostic initial, un contournement qui a échoué, puis un correctif confirmé. Si un appel d’outil ultérieur renvoie une ancienne version du guide de dépannage, la réponse suivante doit tenir compte à la fois de la chronologie et de l’autorité des sources. Le texte supplémentaire a compliqué la décision, même si la question de l’utilisateur reste la même.

Rendez cet arbitrage explicite : identifiez l’état actuel, indiquez que le premier diagnostic a été écarté et conservez la source qui étaye le correctif retenu. L’objectif est de disposer d’éléments suffisants dont le statut est clair, pas de fabriquer le prompt le plus court possible.

Que vérifier d’abord lorsqu’on développe ou exploite un agent ?

Comparez la même décision avec des contextes différents avant d’incriminer le modèle. Côté développement, cela suppose d’enregistrer la requête réellement assemblée par l’application. La conversation visible peut ne pas montrer les instructions système, les résultats de recherche ou les réponses d’outils que le modèle a reçus.

Côté exploitation, identifiez une exigence précise qui a été ignorée ou une action incorrecte. « La conversation semble moins bonne » est difficile à analyser ; « l’agent a recommandé le contournement déjà écarté dans le dossier d’incident » donne un cas concret à rejouer.

Appliquez cette séquence de diagnostic à un exemple enregistré :

1. 1

   Figer les paramètres de la décision

   Gardez la même question, la même configuration du modèle et le même résultat attendu. Enregistrez l’entrée d’origine et les éléments qui font autorité. Rejouez le cas sans exécuter d’actions externes, afin que la comparaison ne puisse pas modifier la situation étudiée.

2. 2

   Vérifier que les éléments nécessaires sont arrivés

   Recherchez le passage nécessaire dans la requête réelle. S’il manque, corrigez d’abord la récupération d’informations, la troncature ou le chargement de l’état. Si une source obsolète a été fournie à sa place, corrigez la sélection et l’actualité des sources.

3. 3

   Préparer une comparaison avec un contexte ciblé

   Conservez les mêmes instructions et tous les éléments nécessaires pour répondre, en retirant l’historique sans rapport avec la tâche et les résultats d’outils obsolètes. N’incluez pas la réponse attendue et ne simplifiez pas la tâche. Comparez l’exactitude, l’utilisation des sources et le respect des contraintes sur des réexécutions représentatives.

4. 4

   Choisir la correction en fonction de l’échec

   Si l’entrée ciblée améliore le résultat, examinez la sélection et l’organisation du contexte. Si les deux versions échouent, examinez la tâche, les instructions, la qualité des éléments fournis et les capacités du modèle. Si l’échec apparaît après la création d’un résumé, vérifiez ce que celui-ci a perdu.

Cette comparaison sert au diagnostic ; elle ne prouve pas que la longueur seule a causé l’erreur, puisque retirer du contenu en modifie aussi la composition. Pour tester plus rigoureusement l’effet de la longueur, contrôlez les éléments pertinents et leur emplacement tout en ajoutant du contenu sans rapport avec la tâche. Ne tirez pas de conclusion générale d’une réexécution qui réussit par chance.

Les équipes doivent intervenir dès lors que l’allongement de l’historique s’accompagne régulièrement d’erreurs évitables. Un workflow court et bien délimité qui satisfait ses contrôles d’exactitude peut conserver sa conception simple. Ajoutez de l’orchestration lorsque l’échec constaté lui donne une fonction précise.

Comment limiter le context rot dans un agent ?

Choisissez l’intervention en fonction du contenu qui pose problème. La compaction gère l’historique accumulé ; la récupération d’informations sélectionne les éléments utiles ; les sous-agents circonscrivent l’exploration ; l’ordre de présentation clarifie la tâche ; des réponses d’outils concises réduisent le contenu superflu. Ces leviers sont complémentaires et chacun peut échouer à sa manière.

Compacter l’historique sans perdre l’état de travail

La compaction remplace les anciens échanges par une trace plus courte permettant de poursuivre le travail. La documentation en ligne d’Anthropic sur la compaction explique pourquoi il importe de garder un contexte actif réduit : « la qualité des réponses se dégrade à mesure que la conversation s’allonge ». Son API prend en charge la compaction à la demande de l’application ainsi que son déclenchement à partir d’un seuil de tokens configuré.

Concevez la transmission autour de ce qu’exige la prochaine action. Dans l’exemple de l’incident, conservez l’objectif actuel, la cause confirmée, le contournement écarté et la raison de son rejet, les incertitudes restantes, l’emplacement des sources et la prochaine action. Préservez les identifiants ou formulations exacts lorsque l’exactitude en dépend.

Une transmission insuffisante indique : « Nous avons étudié le problème et progressé. » Une transmission utile précise : « Le contournement a été écarté parce qu’il compromet le comportement requis ; le correctif retenu est consigné dans le document d’incident ; sa vérification reste à faire. » La seconde permet de poursuivre sans raconter à nouveau toute l’enquête.

La limite : un résumé peut supprimer un détail qui deviendra important par la suite. Gardez le dossier d’origine accessible et vérifiez que l’agent qui reprend le travail peut encore répondre aux questions qui nécessitent ce détail. Sauvegarder un état durable et choisir ce qu’il faut recharger sont deux tâches distinctes, abordées dans notre guide de la mémoire des agents.

Récupérer les informations au moment où la tâche l’exige

Conservez des références vers les sources volumineuses et chargez les passages pertinents à la demande. Anthropic parle de contexte « juste à temps » : l’agent peut garder des chemins de fichiers, des requêtes ou des liens, puis récupérer le contenu selon ses besoins. Recommandations sur la récupération du contexte.

Pour un agent chargé des incidents, commencez par le dossier de l’incident en cours et la documentation applicable au service. Récupérez un ancien incident lorsque le diagnostic le justifie. Accompagnez chaque passage de sa source, de sa version ou de sa date lorsqu’elles sont disponibles, ainsi que d’assez de texte environnant pour interpréter une exception.

La limite : la récupération peut omettre la clause décisive ou renvoyer une correspondance plausible, mais dépassée. Vérifiez la présence des éléments nécessaires avant de mesurer la qualité de la réponse. Donnez à l’agent un moyen d’élargir sa recherche ou de lire la source complète lorsqu’un extrait ne permet pas de conclure.

Un ensemble de résultats plus restreint n’est utile que s’il préserve ce dont la décision a besoin. « Rechercher plutôt que tout charger » est une règle de sélection, pas une consigne pour masquer le contexte gênant.

Confier aux sous-agents des tâches délimitées dans des contextes épurés

Réservez un contexte distinct aux explorations dont l’agent principal n’a pas besoin de connaître les résultats bruts. La documentation d’Anthropic sur les sous-agents de Claude Code décrit des agents qui travaillent dans leur propre fenêtre de contexte et renvoient leurs résultats à la conversation principale.

Un sous-agent chargé d’examiner un log peut recevoir la question précise, les informations pertinentes sur le service et une référence vers ce log. Demandez-lui de renvoyer sa conclusion, l’emplacement des éléments qui l’étayent, les incertitudes et toute dépendance non résolue. L’agent principal peut exploiter ce résultat sans conserver toutes les étapes de la recherche.

La limite : l’isolation retire aussi des connaissances partagées. Fournissez au sous-agent les contraintes dont il a besoin et exigez des éléments à l’appui de sa conclusion. Vérifiez ce que votre framework d’orchestration lui transmet réellement : copier tout l’historique de l’agent principal annulerait la séparation recherchée. Recoller ensuite toutes les conversations des sous-agents dans celle de l’agent principal y recrée l’encombrement.

Utilisez cette approche pour des investigations qui peuvent être séparées. Une décision dont les composantes sont étroitement liées et qui dépend d’un dossier partagé peut être plus facile à traiter dans le contexte principal, avec une récupération ciblée des informations.

Choisir l’ordre des documents et de la demande actuelle

La tâche en cours doit se distinguer facilement des documents qui l’étayent. Les recommandations d’Anthropic pour les prompts à contexte long préconisent de placer les longs documents vers le début du prompt, de distinguer leurs sources et de placer la question après eux. Elles recommandent aussi de repérer les citations pertinentes avant de répondre à des questions sur les documents.

Dans votre application, gardez les instructions qui font autorité dans le canal prévu à cet effet. Au sein de l’entrée de la tâche, identifiez séparément le dossier d’incident actuel et les notes historiques, puis formulez clairement la question et la sortie attendue. Déplacer un texte récupéré ne doit pas lui conférer le statut d’instruction faisant autorité.

La limite : réorganiser le contenu ne rétablit pas les éléments qui n’ont jamais été chargés, et aucun ordre ne garantit un résultat pour tous les modèles et toutes les tâches. Comparez les dispositions sur vos propres exemples. Évitez de répéter un règlement entier à chaque échange lorsqu’un énoncé concis et à jour de la tâche suffit.

Fournir des résultats d’outils ciblés, avec accès à la version complète

Renvoyez le résultat nécessaire à la prochaine décision, avec un moyen de retrouver le document complet. Les recommandations d’Anthropic sur la conception des outils préconisent des réponses utiles et des mécanismes comme le filtrage, la pagination et la troncature. Sa documentation sur la modification du contexte décrit, séparément, la suppression des anciens résultats d’outils dans l’historique de conversation.

Lorsqu’un contrôle échoue, renvoyez l’échec, l’extrait d’erreur pertinent et l’emplacement du rapport enregistré. Pour une recherche, renvoyez les passages pertinents et leurs sources. Pour une opération réussie, renvoyez le statut et les identifiants nécessaires à la suite. Évitez d’intégrer tout le rapport simplement parce que l’outil l’a produit.

La limite : une troncature aveugle peut supprimer l’erreur décisive ou une réserve importante. Signalez les omissions et permettez à l’agent d’en demander davantage. Conservez la sortie complète hors du contexte actif lorsqu’elle devra pouvoir être examinée.

Ces choix relèvent de la couche d’assemblage des requêtes. Notre guide de l’ingénierie du contexte explique plus largement comment s’articulent instructions, mémoire, outils et informations récupérées.

Qu’exagère-t-on à propos du context rot ?

Aucun nombre universel de messages ni aucun pourcentage de remplissage de la fenêtre n’indique à tous les agents quand repartir de zéro. Un seuil qui évite une requête trop volumineuse est un réglage de capacité. Le point à partir duquel un workflow donné devient peu fiable doit se mesurer sur ses tâches réelles.

De même, toute mauvaise réponse dans une longue conversation ne démontre pas un cas de context rot. Des éléments manquants, des instructions contradictoires, un outil défaillant ou une tâche hors des capacités du système peuvent produire des symptômes similaires. Un rapport d’incident utile identifie la décision qui a échoué et consigne ce que le modèle a reçu.

La compaction entraîne des pertes, et une mémoire externe ne garantit pas la pertinence. Traitez-les comme des composants dont les sorties doivent être contrôlées. Conserver plus efficacement une conclusion erronée peut rendre un workflow systématiquement incorrect.

Enfin, la mise en cache répond à un autre besoin. Un cache KV réutilise les calculs d’attention ; il ne détermine pas quel document compte et ne supprime pas l’historique périmé. Une requête qui bénéficie pleinement du cache peut toujours contenir des informations inadaptées à la prochaine décision.

Une courte liste d’actions pour cette semaine

Appliquez ces actions à un agent qui échoue de façon récurrente :

• Enregistrez l’entrée réelle au moment de la décision qui a échoué et identifiez les éléments dont elle avait besoin.
• Rejouez la tâche avec des éléments ciblés, sans changer les exigences ; comparez l’exactitude sur des cas représentatifs.
• Remplacez la réponse d’outil la plus encombrée de contenu inutile par un extrait pertinent et une référence vers le document complet.
• Définissez une transmission de compaction qui préserve les décisions, les approches écartées, les contraintes, les sources et le travail inachevé.
• Isolez une investigation séparable dans le contexte épuré d’un sous-agent, si l’exploration est à l’origine de l’encombrement.
• Ne déployez la modification que si le workflow repris conserve les faits nécessaires et améliore le cas d’échec ciblé ; gardez la possibilité de rétablir le comportement précédent.

Commencez par un échec que vous savez reproduire. Vous disposerez ainsi d’un critère d’acceptation clair pour la modification, au lieu de faire de « moins de contexte » votre mesure de réussite.

Questions fréquentes sur le context rot

Le context rot est-il toujours d’actualité ?

La documentation actuelle d’Anthropic sur la compaction décrit toujours explicitement une dégradation de la qualité des réponses à mesure que les conversations s’allongent. Cela justifie de continuer à gérer le contexte, sans pour autant établir les performances de chaque modèle actuel. Évaluez le modèle et le workflow que vous déployez.

Comment éviter le context rot ?

Conservez les instructions actuelles et les éléments nécessaires, retirez le contenu obsolète ou redondant, compactez l’historique avec soin et récupérez les détails selon les besoins. Isolez les tâches annexes qui encombrent le contexte lorsque c’est utile. Vérifiez que chaque modification préserve les faits requis pour la prochaine action.

Quelles sont les causes du context rot ?

La longueur du contexte, la pertinence du contenu environnant et la présentation des informations peuvent influer sur la fiabilité. L’étude originale n’établit pas de mécanisme sous-jacent unique. Pour un agent, examinez les éléments fournis et l’état de travail avant de choisir une correction.

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur la conception et l’exploitation de workflows d’IA.