La compaction du contexte efface un tiers des règles anti-triche dans ProgramBench

Les tâches agentiques longues ne tiennent de plus en plus souvent pas dans la fenêtre de contexte, et le harnais de l'agent doit libérer de la place : compresser l'historique, jeter le superflu, poursuivre le travail à partir d'un court résumé. Cette technique, appelée compaction, existe dans pratiquement tous les agents de code. Elle a pourtant été très peu évaluée de façon systématique sur des modèles frontier et des tâches réalistes : les travaux antérieurs faisaient tourner de petits modèles ouverts sur des trajectoires jouets ou synthétiques. Le groupe de Jeanne Salle, avec quatre coauteurs, comble cette lacune et obtient un résultat à double fond. Les benchmarks remarquent à peine la compaction, mais le travail réel, lui, la remarque.

Le protocole expérimental

Les auteurs ont figé le harnais agentique OpenCode et y ont implémenté cinq stratégies de compaction. Ils ont ensuite fait passer trois modèles frontier sur trois benchmarks de longue durée. Deux des trois modèles disposent d'un contexte de 1 million de tokens ; le troisième, GPT-5.3-Codex, a la plus petite fenêtre de l'échantillon. Le seuil de déclenchement de la compression a varié d'un essai à l'autre.

• Harnais : OpenCode, identique pour tous les essais.
• Stratégies : cinq variantes de compaction ; la référence est l'auto-résumé, où le modèle reformule lui-même son historique.
• Modèles : deux modèles avec une fenêtre de 1M et GPT-5.3-Codex.
• Benchmarks : PaperBench, ProgramBench, PostTrainBench.
• Jeu de données complémentaire : des sessions utilisateur réelles, SWE-chat.

Où la compaction est sûre, et où elle ne l'est pas

Pour les modèles à fenêtre de 1M, le seuil de compression n'a pas d'effet notable sur le résultat. Pour GPT-5.3-Codex, le tableau est différent : sur PaperBench, la qualité baisse avec les seuils bas ; sur PostTrainBench, l'effet est plus faible et moins net. La logique est simple : plus la fenêtre est petite, plus il faut compresser souvent et de façon agressive, et plus les pertes s'accumulent.

Les méthodes sophistiquées n'ont pas tenu leurs promesses. Aucune n'a fait mieux que l'auto-résumé classique. Les approches qui écartent davantage de contenu ont coûté jusqu'à 20 points à certains modèles, et rien à d'autres. Autrement dit, la sensibilité à la compaction agressive dépend du modèle, et on ne peut pas la deviner à l'avance.

La découverte la plus gênante concerne les contraintes. Sur ProgramBench, dès le premier résumé, l'agent perd en moyenne environ un tiers des règles anti-triche de la tâche, et la part des règles perdues augmente de façon monotone à chaque compaction suivante. Un agent qui a oublié qu'il ne devait pas tricher ni contourner la vérification continue formellement son travail, mais selon d'autres règles. Et il ne le signale pas.

Sur les sessions réelles de SWE-chat, l'écart est encore plus marqué. Les instructions sur la manière de travailler et sur ce qu'il ne faut pas faire sont écartées environ 6 fois plus souvent que les spécifications de ce qu'il faut construire. Le modèle retient bien l'objectif, mais mal la manière de travailler : style, interdictions, accords passés avec l'utilisateur.

Pourquoi les benchmarks induisent en erreur

Les auteurs qualifient les benchmarks actuels de « favorables à la compaction ». Leur objectif est fixe et écrit dans l'énoncé, et la progression de l'agent se trouve sur le disque : code, fichiers, logs. Presque tout ce que la compression a retiré du contexte peut donc être retrouvé en relisant le dépôt.

Seul ce qui n'est consigné nulle part ailleurs est irrécupérable : les contraintes, les précisions données à l'oral dans le dialogue, les raisons des décisions passées. Dans une session réelle, ces éléments sont nombreux ; dans un benchmark, il n'y en a presque pas. D'où la conclusion : de bons chiffres sur les tests ne garantissent pas que l'agent ne perdra pas des exigences dans un projet réel.

Pour ceux qui construisent des agents, les enseignements sont pratiques. Il ne faut pas compliquer la compaction : l'auto-résumé par défaut reste une base solide, et économiser des tokens par un rejet agressif de contenu peut coûter jusqu'à 20 points de qualité. Les règles et les interdictions doivent être conservées hors de l'historique de dialogue : dans le prompt système, dans un fichier d'instructions du dépôt ou dans un bloc épinglé que la compression ne touche pas.

Après chaque compaction, il est judicieux de comparer automatiquement le résumé à la liste des contraintes. Enfin, dans le choix du modèle, la fenêtre de contexte ne compte pas en soi : plus elle est petite, plus la compaction se déclenche souvent et plus le risque de perte silencieuse des exigences est élevé. Il convient aussi d'évaluer les agents sur des scénarios où une partie des conditions n'existe que dans le dialogue ; sinon, le benchmark mesurera la mémoire de l'objectif, et non la discipline de travail.