La compression de la mémoire des agents IA fait perdre jusqu'au tiers des règles de la tâche, mais les benchmarks ferment les yeux

La compression de la mémoire des agents IA fait perdre jusqu'au tiers

des règles de la tâche, mais les benchmarks ferment les yeux

Quand un agent IA travaille sur une tâche pendant plusieurs heures — par exemple en écrivant du code ou en essayant de reproduire un article scientifique — il finit tôt ou tard par remplir toute sa fenêtre de contexte disponible : les échanges, les appels d'outils et leurs résultats. Pour continuer, les développeurs de systèmes agentiques comme Claude Code, Codex CLI, Cursor ou OpenCode utilisent une technique appelée « compression du contexte » (compaction) : on demande au modèle de résumer brièvement tout ce qui a été fait, on efface l'ancien historique et on poursuit le travail avec ce résumé. Le problème, c'est qu'un résumé, par définition, perd des détails — et on ne sait pas exactement ce qui se perd ni à quel point c'est critique.

C'est précisément ce qu'ont voulu vérifier Sahar Abdelnabi et Maksym Andriushchenko, chercheurs au Max Planck Institute for Intelligent Systems.

Pour garantir la rigueur de l'expérience, ils ont fixé un seul et même « harnais » d'agent — l'outil open source OpenCode — afin que les écarts de résultats ne s'expliquent pas par des particularités propres à différentes plateformes logicielles. Au sein d'OpenCode, ils ont implémenté cinq méthodes différentes de compression du contexte et testé quatre modèles de pointe — Claude Opus 4.6, GPT-5.

3-Codex, GPT-5.4 et Gemini 3.1 Pro Preview — sur trois tâches pratiques de longue durée : PaperBench (reproduire un article scientifique issu d'ICML à partir de sa description, sans accès au code des auteurs), ProgramBench (écrire à partir de zéro un utilitaire en ligne de commande en disposant uniquement d'un exécutable de référence prêt à l'emploi et de sa documentation) et PostTrainBench (entraîner puis affiner un petit réseau de neurones sur une seule carte graphique en 10 heures).

La taille de la fenêtre de contexte décide de tout, la méthode de

compression presque de rien

La conclusion principale concerne les deux modèles disposant d'une fenêtre d'un million de tokens — Claude Opus 4.6 et GPT-5.4.

Leurs résultats ne variaient pratiquement pas, que la mémoire soit compressée toutes les 160 000 tokens ou toutes les 380 000 — l'écart restait dans la marge d'erreur statistique. En revanche, GPT-5.3-Codex, dont la fenêtre ne compte que 400 000 tokens, affichait un résultat nettement moins bon sur la tâche PaperBench en cas de compression précoce et fréquente : 0,38 point au seuil de 160 000 tokens contre 0,60 à partir d'un seuil de 260 000 tokens et plus — soit presque deux fois moins bon.

Sur la tâche d'écriture de code (ProgramBench), cet écart n'apparaissait pas, et sur PostTrainBench, les résultats variaient trop fortement pour en tirer des conclusions.

Les chercheurs ont également vérifié si une stratégie de compression plus « intelligente » apportait un avantage par rapport à un simple résumé en d'autres termes. Cinq variantes ont été testées : un résumé classique ; un résumé classique accompagné d'un nettoyage des anciens résultats d'appels d'outils ; la sauvegarde de l'historique complet dans un fichier séparé sur le disque avant compression (pour pouvoir théoriquement y revenir et tout relire) ; la suppression des blocs de raisonnement du modèle de l'historique avant la rédaction du résumé ; et enfin, la rédaction du résumé par un modèle moins coûteux — Claude Haiku 4.5 — plutôt que par le modèle principal exécutant la tâche.

Aucune de ces méthodes avancées n'a dépassé le simple résumé classique, sur aucun des benchmarks. Pire, les variantes les plus agressives — suppression des raisonnements et transfert du résumé à un modèle plus petit — ont nettement fait chuter le score de certains modèles sur PaperBench, jusqu'à 20 points, tandis qu'elles n'ont absolument pas affecté d'autres modèles. Cela signifie qu'une méthode de compression efficace avec un modèle ne peut pas être simplement transposée à un autre.

Où disparaissent les règles du jeu

La découverte la plus préoccupante ne concerne pas la performance, mais la sécurité. Dans la tâche ProgramBench, l'agent reçoit dès le départ trois règles strictes : ne pas copier ni intégrer le code source du programme de référence, ne pas se connecter à Internet (notamment pour éviter de télécharger le code original) et produire une implémentation réellement originale plutôt qu'une simple enveloppe autour d'une solution existante. Ces règles n'existent que dans le texte du tout premier message — et si le résumé lors de la compression ne les répète pas, l'agent les oublie purement et simplement, contrairement à l'objectif de la tâche et à sa propre progression, qu'il peut relire dans les fichiers stockés sur le disque.

Or, dès la première compression du contexte, environ une règle sur trois disparaît en moyenne. Après la dixième compression, ce sont déjà deux règles sur trois. Sur de vraies sessions utilisateurs issues du jeu de données SWE-chat, le tableau est similaire : la compression fait disparaître les instructions sur la façon dont l'agent doit travailler et sur ce qu'il ne doit pas faire — et ces pertes surviennent environ 6 fois plus souvent que celles concernant les exigences sur ce qu'il faut construire.

Pourquoi les tests actuels ne s'en aperçoivent pas

Les auteurs apportent une précision importante : les benchmarks eux-mêmes, sur lesquels on évalue habituellement les agents, sont conçus de telle sorte que les pertes dues à la compression se reconstituent facilement. L'objectif de la tâche est fixe, l'utilisateur ne change rien en cours de route, et toute la progression de l'agent est stockée dans des fichiers sur disque qu'il peut relire à tout moment. Ainsi, parmi tout ce que la compression efface, seul ce qui n'est consigné nulle part ailleurs disparaît réellement — en premier lieu les contraintes et règles énoncées une seule fois au tout début.

Dans de vrais dialogues avec un utilisateur, où les instructions et précisions sont beaucoup plus nombreuses et ne sont pas stockées séparément, le coût de cet oubli est bien plus élevé.

Conclusion pratique pour les équipes qui construisent des systèmes agentiques : si la tâche est longue et que des contraintes strictes sont en jeu (ne pas toucher à la base de production, ne pas se connecter au réseau, ne pas supprimer de fichiers sans confirmation), on ne peut pas compter sur un résumé classique pour les préserver — il vaut mieux soit consigner explicitement ces règles séparément de l'historique général et les relire à chaque compression, soit choisir un modèle avec une large marge de contexte et compresser le moins souvent possible.