- Si la limite de tokens en entrée (fenêtre de contexte) des LLM récents s’est étendue jusqu’à plusieurs millions, une dégradation nette des performances sur de longues entrées réelles existe bel et bien, même lorsque les modèles obtiennent de très bons scores sur des benchmarks de recherche simples comme Needle in a Haystack (NIAH)
- Les chercheurs ont mené divers tests sur 18 modèles, et ont confirmé de manière répétée une baisse de performances et des schémas incohérents, même lorsque seule la longueur d’entrée était contrôlée
- La vitesse de dégradation s’accélère ou devient imprévisible selon la baisse de similarité entre question et réponse, l’ajout de phrases distractrices et les changements de structure du texte d’entrée
- Le simple fait de préserver un contexte structuré (enchaînement logique des paragraphes) peut même avoir un effet négatif sur les performances, montrant que l’organisation et l’agencement de l’entrée influencent fortement les résultats des LLM
- Même pour des tâches très simples comme la copie répétée de texte, les modèles montrent une incapacité à produire des résultats cohérents à mesure que la longueur d’entrée augmente, ce qui souligne l’importance de la conception du contexte (context engineering) dans les usages réels
Contexte et objectif de l’étude
- Avec l’extension récente des fenêtres de contexte des LLM à 1 à 10 millions de tokens, l’idée selon laquelle les performances seraient « garanties » même sur de longues entrées s’est largement diffusée
- Gemini 1.5 Pro, GPT-4.1 et Llama 4 en sont des exemples représentatifs
- Le benchmark de référence Needle in a Haystack (NIAH) se limite à une simple recherche de phrase, et ne reflète donc pas correctement la dégradation des performances dans des tâches plus complexes sur documents longs, comme le résumé ou la question-réponse
- Cette étude vérifie systématiquement l’évolution des performances en ne faisant varier que la longueur d’entrée, à difficulté de tâche constante
Principales expériences et résultats
- 18 LLM récents (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen, etc.) ont été évalués selon 4 protocoles expérimentaux :
- variation de la similarité sémantique entre question et réponse (Needle-Question)
- ajout de phrases distractrices
- changement de sujet/structure du texte support (haystack)
- copie répétée de mots (avec augmentation simultanée de la longueur d’entrée et de sortie)
- Dans toutes les expériences, les performances chutent fortement à mesure que la longueur d’entrée augmente, avec une baisse encore plus marquée lorsque la similarité sémantique est faible ou que les distracteurs sont nombreux
- Plus la similarité entre question et réponse est faible, plus le taux d’erreurs explose sur les longues entrées
- L’ajout d’un seul distracteur suffit à faire baisser immédiatement le taux de bonnes réponses, et avec 4 distracteurs ou plus, les phénomènes de confusion et d’hallucination augmentent fortement selon les modèles
- Exemple : les modèles de la famille Claude ont davantage tendance à répondre « impossible de trouver la bonne réponse » plutôt qu’à donner une mauvaise réponse, tandis que les modèles GPT produisent plus souvent des erreurs affirmées avec assurance
- Un phénomène particulier a aussi été observé : les performances peuvent s’inverser selon la structure du texte support (flux logique / ordre aléatoire)
- Sur le texte original respectant un enchaînement logique, les performances du modèle se dégradent au contraire davantage
- Sur un texte mélangé aléatoirement (Shuffled), les performances de recherche peuvent au contraire être meilleures
- Même dans l’expérience de copie répétée de mots, des schémas imprévisibles augmentent avec la longueur des tokens d’entrée et de sortie : hausse des erreurs, refus de la tâche, génération de mots arbitraires, etc.
- Exemple : au-delà de 2 500 à 5 000 mots, certains modèles montrent une forte augmentation de refus de copie, de génération de texte arbitraire et d’autres résultats anormaux
LongMemEval : évaluation de conversations longues en conditions réelles
- Sur le benchmark LongMemEval, qui inclut de véritables historiques de conversation, les chercheurs ont comparé une entrée focalisée (ne contenant que les parties liées à la bonne réponse) à une entrée complète (incluant aussi du contexte sans lien avec la réponse)
- Pour tous les modèles, l’entrée focalisée obtient un taux de bonnes réponses bien supérieur, tandis que l’entrée complète dégrade fortement les performances, car la recherche du contenu pertinent devient elle-même une tâche supplémentaire
- Les modèles de la famille Claude montrent en particulier une nette tendance à se retrancher derrière une réponse de type « aucune bonne réponse » dans les situations ambiguës
Analyses complémentaires et implications
- Les chercheurs ont analysé en détail, à l’aide de nombreux graphiques, les différences de comportement interne selon les modèles, notamment le taux de confusion par distracteur, la précision de localisation de la réponse et la position de génération de mots arbitraires
- Dans l’expérience de copie répétée de mots, on observe aussi des caractéristiques dépendantes de la position, par exemple une meilleure précision lorsque le mot correct apparaît plus tôt
- Étant donné l’effet majeur de la conception du contexte (agencement de l’information, gestion du flux logique, etc.) sur les performances, l’étude suggère qu’en déploiement réel on ne peut pas attendre des performances cohérentes d’une simple extension du contexte
Conclusion
- La capacité des LLM à traiter de longues entrées ne peut pas être garantie par les seuls scores de benchmark, et une dégradation incohérente des performances apparaît dès que la longueur réelle des entrées augmente
- La simple présence des informations pertinentes ne suffit pas : leur ordre, leur structure, les distracteurs et la similarité jouent tous un rôle déterminant dans les performances
- L’usage des LLM exige donc une gestion et une conception rigoureuses des contextes longs (context engineering)
2 commentaires
La 2.5 est sortie depuis un bon moment déjà, alors pourquoi parler de la 1.5 ?
Avis Hacker News
J’ai moi aussi eu une expérience similaire. En particulier avec Gemini Pro, quand je lui fournissais de longues références textuelles, j’obtenais de bien meilleures réponses en résumant d’abord chaque document puis en posant la question, et, si nécessaire, en fournissant ensuite les documents complets dans un style RAG ou via une simple boucle d’agent, plutôt qu’en mettant plusieurs documents d’un coup dans la fenêtre de contexte. De même, en utilisant Claude Code avec Opus ou Sonnet, j’ai constaté directement que plus il y avait de compaction, plus les résultats se dégradaient. Je ne sais pas avec certitude si c’est parce que la qualité des résumés baisse, ou parce que la proportion de données moins pertinentes augmente dans la fenêtre de contexte, mais quand je vidais le contexte et lui demandais de relire uniquement les fichiers pertinents, les résultats étaient nettement meilleurs, même si cela avait déjà été mentionné dans le résumé précédent
Gemini commence à perdre en cohérence et en capacité de raisonnement bien avant d’atteindre la limite de contexte du chat. Et pourtant, d’après ce rapport, c’est le meilleur modèle sur plusieurs aspects. La conclusion, c’est que le context engineering reste important et que l’approche RAG reste valable
La « compaction », ce n’est pas simplement réduire la transcription à un résumé, au fond ? Dans ce cas, il est normal que les performances baissent puisqu’il y a réellement une perte d’information. Mais ce n’est pas dû au context rot. Le vrai signal de context rot apparaît quand on approche du seuil d’auto-compaction. Est-ce que je comprends bien ?
Un agent de code optimal ferait probablement cela automatiquement. Il rassemblerait le code nécessaire, les réponses MCP, la cartographie du dépôt, etc., les résumerait de temps en temps, puis fusionnerait le tout dans un nouveau message de chat pour ne garder que ce qui est vraiment nécessaire. J’utilise déjà ce style avec un outil appelé aider, et dans les situations nécessitant beaucoup de contexte, cela a bien mieux fonctionné que des workflows agentiques ou automatisés. En revanche, cela demande beaucoup de travail manuel
Tu as essayé NotebookLM ? Cette application découpe et résume les documents en arrière-plan, puis permet de poser des questions sur l’ensemble des documents sous forme de chat grâce au RAG
J’ai constaté qu’à mesure que la conversation s’allonge dans Cursor autour d’une nouvelle fonctionnalité ou d’un changement de code, le résultat se dégrade progressivement. J’ai obtenu les meilleurs résultats en établissant d’abord des instructions et un plan clairs et précis, puis en faisant glisser directement dans le prompt de contexte les fichiers à modifier
Suivre le flux « Explore → plan → code → test → commit » m’a été bien plus utile. Si nécessaire, on peut aussi vider le contexte à chaque étape pour gagner en efficacité
Une fois que j’ai réuni suffisamment d’informations pour une tâche donnée, je sauvegarde le contexte à ce moment-là. Si je vois la qualité baisser, je résume à nouveau le travail effectué jusque-là et je l’ajoute au checkpoint précédent
Ce phénomène est bien connu, mais il est rarement correctement documenté, donc cet article est très bienvenu. Je pense que son impact réel est encore plus important que ce qu’on peut facilement mesurer avec des benchmarks. Les applications LLM réellement utiles restent proches de la limite de ce que le modèle peut faire. Elles prennent tout leur sens lorsqu’il faut suivre un contexte qui impose plusieurs « sauts » logiques dans une vraie question ou une vraie tâche. Et je pense que plus ces sauts logiques sont nombreux, plus le problème de context rot s’aggrave de façon exponentielle, parce qu’à chaque saut, le nombre d’éléments auxquels il faut prêter attention augmente
Il faut absolument un moyen simple de couper le contexte. Si je pouvais gérer moi-même tout l’historique du dialogue avec le modèle, j’aurais probablement bien plus de performance dans une session de code d’environ 200 000 tokens. Mais dans la réalité, même avec une bonne instance, le modèle commence à devenir bizarre vers 20 000 tokens, et la session est complètement dégradée. J’aimerais pouvoir simplement couper cette partie
Avec les LLM locaux, on peut éditer le contexte comme on veut, donc si l’on modifie les réponses du LLM lui-même, le modèle peut ensuite croire qu’il les a réellement données à l’origine. C’est donc avantageux pour l’orienter dans la direction souhaitée. En revanche, les modèles LLM-as-a-service n’offrent pas cette possibilité, car cela faciliterait le contournement de la censure
J’ai fait une expérience consistant à dire : « Hé Claude, je vais maintenant réinitialiser le contexte, alors crée-moi un prompt pour que nous puissions continuer à travailler ensuite », puis à relire et ajuster à l’avance le prompt proposé par Claude avant de le réinjecter
Pouvoir revenir facilement à un checkpoint précédent serait vraiment la meilleure fonctionnalité possible
Dans la plupart des agents CLI, on peut faire ce genre de chose avec la commande
/compressEn utilisant Claude code, j’ai l’impression qu’il finit de plus en plus par ne plus distinguer ses propres erreurs de mes consignes. Quand il commence à se mélanger, la solution, c’est d’ouvrir une nouvelle session. Plus la session s’allonge, plus il tourne dans les mêmes boucles ou insiste sur le fait que les tests sont déjà cassés et les ignore (alors qu’en réalité ils ont cassé dans cette session). C’est peut-être ma faute parce que je m’y prends mal dans mes prompts, mais j’ai l’impression qu’en ce moment Claude a perdu 30 points de QI sans qu’on s’en rende compte
J’ai exactement la même impression. Même avec le plan Max, il y a clairement des moments où les performances sont bonnes et d’autres où elles ne le sont pas
Le fait de se dire « ce doit être mon prompt et mon contexte le problème », c’est un peu comme si nous avions tous internalisé une forme de gaslighting
C’est une variété de problème de recherche d’information, mais je pense que la baisse de performance liée à la longueur du contexte peut fonctionner différemment des simples réponses de recherche. Par exemple, pour des questions comme « comment modifier ce bouton en rouge ? » ou des problèmes comme « à quelle catégorie appartiennent les phrases ci-dessus ? », cela peut se comporter autrement. Il y a un article qui m’avait marqué autrefois : Many-Shot In-Context Learning. Cette étude montre qu’en remplissant le contexte avec des exemples, les performances peuvent fortement s’améliorer. Au final, il faut vraiment tester directement selon chaque problème pour comprendre comment le LLM évolue selon le contenu et la longueur du contexte. Il ne faut pas supposer que des contextes plus longs font toujours baisser les performances
C’est un article très cool et plein d’enseignements. Cela dit, du point de vue de l’éducation aux médias, il peut être utile de garder à l’esprit que Chroma est une entreprise de vector DB
J’ai récemment écrit plusieurs romans longs avec Gemini 2.5 Flash, et je ressens clairement le context rot, mais il apparaît bien plus tard que ce que l’article suggère. Dans mon cas, ce n’est qu’après environ 50 000 à 100 000 tokens qu’il commence à ignorer le contexte initial, comme la langue de sortie. Peut-être qu’avec des tâches complexes comme l’écriture créative, l’effet est plus difficile à mesurer ou moins net. Quoi qu’il en soit, tant qu’on lui réinjecte de temps en temps uniquement le contexte manquant, cela reste utilisable
J’ai eu une expérience similaire. Pendant un projet, je développais une fonction de recherche dans des transcriptions vidéo, et les textes étaient très longs. Je pensais qu’avec des modèles comme GPT 4.1, qui ont une grande fenêtre de contexte, le RAG ne serait pas nécessaire, mais surtout avec les petits modèles, des comportements étranges apparaissaient souvent. Parfois, au lieu de répondre correctement à la question, ils se contentaient de résumer l’ensemble du contenu
Rapport intéressant. Je me demande s’il existe une taille de contexte recommandée selon les modèles. J’aimerais savoir s’il existe un moyen de déterminer jusqu’où il est raisonnable d’aller pour mon cas d’usage