Le même jeu de directives comportementales a fait grimper le taux de réussite des tâches de gpt-oss-120b de 16.1 points de pourcentage, alors que GLM-5 n'a pas bougé d'un iota. Dans une série d'expériences publiée le 18 août, IBM Research a testé huit modèles et en tire une conclusion centrale : la bonne dose de mémoire dépend de la marge qu'il reste au modèle lui-même.
Les expériences reposent sur le benchmark AppWorld : 585 tâches à plusieurs étapes, dont 168 de difficulté normale et 417 de difficulté élevée, réparties sur 9 applications simulées — calendrier, messagerie, paiements, etc.
La méthode elle-même n'a rien de compliqué : l'agent exécute d'abord les tâches une fois, on extrait des trajectoires réussies et échouées des directives comportementales, regroupées en un ensemble réutilisable ; au moment de l'inférence, ces directives sont réinjectées dans le contexte. Il existe deux façons de les injecter : le jeu complet à chaque étape, ou un noyau fixe et réduit complété par une récupération du sous-ensemble pertinent selon la tâche. Même jeu de directives, deux modes d'alimentation, comparés côte à côte.
Trois paliers de modèles, trois solutions optimales différentes
Sur les huit modèles testés, la répartition est nette.
Le palier à marge confortable — DeepSeek-V3.2 (671B MoE), Claude Opus 4.6 et GPT-5.5 — obtient les meilleurs résultats avec l'injection du jeu complet de directives. Chez DeepSeek-V3.2, le taux de réussite des tâches gagne 9.5 points de pourcentage et celui des scénarios 16.1 points ; chez Claude Opus 4.6, 4.1 et 7.1 ; chez GPT-5.5, 2.9 et 7.2.
Le palier à capacité serrée ne compte que gpt-oss-120b (117B MoE). Injecter le jeu complet le submerge littéralement ; en passant à la récupération sélective, les deux indicateurs gagnent chacun 16.1 points de pourcentage, le plus gros gain parmi les huit modèles.
GLM-5 (745B MoE) est classé dans le palier saturé : déjà proche de son plafond sur cet ensemble de tâches, avec ou sans mémoire les deux indicateurs n'évoluent pas, soit 0.0 point de pourcentage.
Deux indicateurs à lire séparément
Le TGC (taux de réussite des tâches) mesure la part des tâches individuelles que l'agent accomplit intégralement et correctement. Le SGC (taux de réussite des scénarios) est plus strict : un scénario regroupe plusieurs variantes d'une même tâche — données différentes, formulation différente, conditions limites différentes — et n'est validé que si toutes les variantes réussissent.
L'intérêt de séparer les deux indicateurs se lit dans les chiffres : le TGC de DeepSeek-V3.2 ne gagne que 9.5 points, alors que son SGC en gagne 16.1. Le même schéma se retrouve chez Claude Opus 4.6 (4.1 contre 7.1) et GPT-5.5 (2.9 contre 7.2). Le bénéfice de la mémoire se situe davantage dans "réussir le même type de tâche même reformulée" que dans "résoudre davantage de nouveaux problèmes". Pour qui construit des systèmes de production, le premier type de gain est bien plus rare que le second.
Le coût se lit dans les tokens
La colonne des coûts est la partie la plus concrète de l'étude. En injection complète, la consommation de tokens par tâche de DeepSeek-V3.2 passe de 148,000 à 263,000, soit +78%. gpt-oss-120b, également en injection complète, passe de 110,000 à 166,000, soit +51%. En passant à la récupération sélective, la consommation de gpt-oss-120b tombe à seulement 116,000, soit +5% seulement, contre un gain de 16.1 points de pourcentage.
En mettant les deux séries côte à côte pour un calcul de rentabilité approximatif : gpt-oss-120b échange 5% de tokens en plus contre 16.1 points, DeepSeek-V3.2 échange 78% de tokens en plus contre 9.5 points (sur le TGC). Pour chaque 1% de tokens supplémentaires, le premier rapporte environ 3.2 points de pourcentage, le second environ 0.12 seulement, soit un écart de plus de vingt fois. Pour des opérations facturées au token, cet écart suffit à transformer "injecter toute la mémoire dans le modèle fort" en un calcul qui ne tient plus.
L'apprentissage se passe en dehors du modèle
Les auteurs ajoutent une phrase qui trace la limite de cette méthode :
Learning happens around the model, not inside it.
L'apprentissage se produit autour du modèle, pas à l'intérieur de lui.
Les directives modifient l'environnement de contexte de l'agent, tandis que les poids du modèle ne bougent pas. L'avantage, c'est qu'on peut les ajouter ou les retirer à tout moment, les auditer, en changer avec le modèle ; la limite se situe au même endroit — tout gain reste borné par la fenêtre de contexte et le coût d'inférence, et au-delà d'un certain seuil, l'effet s'inverse, comme lorsque le jeu complet de directives a submergé gpt-oss-120b.
Ces travaux viennent d'IBM Research, signés par dix auteurs dont Vatche Isahagian, Evelyn Duesterwald et Vinod Muthusamy, avec le code et la méthode publiés sous le nom ALTK-Evolve.
Pour les équipes qui ajoutent aujourd'hui de la mémoire à leurs agents, l'ordre d'action que suggèrent ces données est plus utile que la conclusion elle-même : mesurer d'abord la marge de base du modèle sur la tâche visée ; en cas de marge serrée, opter pour la récupération sélective ; en cas de marge confortable, l'injection complète mérite d'être envisagée ; et pour un modèle déjà proche de son plafond, économiser ces tokens et investir le budget ailleurs.
Sources : blog technique d'IBM Research et de Hugging Face, CocoLoop ; la composition des 585 tâches d'AppWorld, les variations en points de pourcentage de TGC/SGC pour les huit modèles et les coûts en tokens de chaque configuration ont été vérifiés à partir des données expérimentales publiées.