Une étude d’IBM Research sur ALTK-Evolve montre qu’ajouter de la mémoire à un agent ne suffit pas : le volume et le mode d’injection des consignes doivent être adaptés à chaque modèle.
Donner une mémoire à un agent IA paraît intuitivement souhaitable : il apprend de ses erreurs, conserve les stratégies efficaces et les réutilise lors des tâches suivantes. Pourtant, davantage de contexte ne produit pas systématiquement de meilleurs résultats. Dans certains cas, un ensemble de règles trop volumineux dégrade même le compromis entre performance et coût.
Une publication d’IBM Research, consacrée à ALTK-Evolve, documente ce point sur huit modèles évalués dans l’environnement AppWorld. Son enseignement pratique est simple : la mémoire agentique n’est pas une option binaire. C’est un dosage à calibrer selon le modèle, ses marges de progression et la façon dont les consignes sont injectées dans le contexte.
Ne pars pas du principe qu’un agent doit recevoir toute sa mémoire à chaque étape. Teste au minimum trois variantes : sans mémoire, avec l’ensemble complet de règles, puis avec un socle stable complété par des règles récupérées selon la tâche.
ALTK-Evolve transforme les trajectoires en consignes réutilisables
Dans cette étude, le mot « mémoire » ne désigne pas un historique brut de conversations ou d’actions. Le système construit plutôt un jeu de guidelines : des consignes comportementales issues des trajectoires passées de l’agent. Elles peuvent formaliser une stratégie qui a fonctionné, une erreur à éviter ou un cas limite rencontré lors de l’exécution d’une tâche.
Le processus décrit par les chercheurs suit quatre étapes :
- l’agent traite des tâches et génère des trajectoires ;
- ALTK-Evolve extrait des enseignements à partir des réussites comme des échecs ;
- ces enseignements sont consolidés dans un ensemble de règles réutilisables ;
- à l’inférence, l’agent reçoit soit toutes les règles, soit une sélection adaptée à la tâche.
Il n’y a pas de mise à jour des poids du modèle, ni d’annotation humaine dans cette boucle telle qu’elle est présentée. L’apprentissage se situe donc autour du modèle, dans son contexte d’exécution. C’est un choix intéressant pour les équipes produit : la méthode peut en théorie être appliquée sans lancer de fine-tuning et sans verrouiller le mécanisme dans un seul modèle.
Trois profils observés selon la capacité du modèle
Les auteurs ne proposent pas une règle universelle du type « injecte 20 consignes ». Ils observent au contraire trois comportements récurrents. Le nombre de paramètres n’explique pas seul ces écarts : la marge sur le benchmark, l’architecture, la taille de fenêtre de contexte, la qualité des règles et la distribution des tâches peuvent jouer. La publication précise que la séparation de ces facteurs reste un travail en cours.
Les modèles solides avec de la marge bénéficient du corpus complet
Pour les modèles capables d’absorber beaucoup d’instructions supplémentaires, l’ensemble complet de guidelines obtient les meilleurs résultats. DeepSeek-V3.2, présenté comme un modèle MoE de 671 milliards de paramètres, gagne 9,5 points de Task Goal Completion (TGC) avec cette configuration. Claude Opus 4.6 et GPT-5.5 progressent également avec le corpus complet, malgré des scores de départ déjà élevés.
L’interprétation opérationnelle est qu’un modèle suffisamment robuste peut exploiter des règles rares et des exceptions, sans être trop perturbé par la densité de contexte.
Les modèles moins performants préfèrent une mémoire sélectionnée
À l’inverse, un modèle moins à l’aise sur les tâches étudiées peut être noyé dans un trop grand volume de règles. Pour gpt-oss-120b, IBM Research rapporte le meilleur résultat avec une récupération curatée : un noyau fixe de règles à forte confiance, complété par quelques consignes pertinentes pour la tâche en cours.
Le gain communiqué est de 16,1 points de TGC, de 39,9 % à 56,0 %, et autant sur l’indicateur SGC, qui passe de 21,4 % à 37,5 %. La source indique aussi que l’injection de l’ensemble complet était moins performante pour ce modèle tout en consommant environ 50 % de tokens supplémentaires.
Certains modèles ne montrent aucun gain mesurable
GLM-5 est classé dans le profil « saturated » dans les essais rapportés : son score reste inchangé avec la mémoire complète. Les auteurs sont prudents sur la cause. Le modèle était peut-être déjà proche de son plafond sur ces tâches ; les règles n’ont peut-être pas ciblé ses erreurs restantes ; ou il ne les a peut-être pas appliquées efficacement. Il s’agit d’une observation expérimentale, pas d’une explication démontrée.
Les résultats AppWorld mesurent surtout la fiabilité sur des tâches multi-étapes
L’évaluation porte sur AppWorld, avec 585 tâches multi-étapes réparties entre 168 tâches test_normal et 417 tâches test_challenge, dans neuf applications simulées, notamment de calendrier, messagerie et paiement. Les guidelines sont extraites uniquement à partir du jeu d’entraînement ; la publication indique qu’aucune donnée du jeu de test n’est utilisée pour les constituer.
Deux métriques sont utilisées :
- TGC : la tâche est-elle entièrement accomplie ?
- SGC : toutes les variantes d’un scénario sont-elles réussies ? C’est une mesure plus stricte.
Le SGC progresse souvent davantage que le TGC. Pour DeepSeek-V3.2, par exemple, le TGC progresse de 9,5 points, tandis que le SGC gagne 16,1 points, de 64,3 % à 80,4 %. Chez GPT-5.5, le gain communiqué est de 2,9 points en TGC mais de 7,2 points en SGC. Cela suggère que les consignes extraites aident particulièrement à traiter les variantes et les cas où une seule erreur invalide le scénario.
Attention toutefois à la portée de ces chiffres : ils concernent AppWorld, les configurations testées et les modèles cités. La source ne permet pas d’affirmer qu’un gain identique se reproduira sur ton agent, tes outils, tes données ou tes parcours clients.
La récupération ciblée peut réduire les coûts de contexte
Le coût est un point central dès lors que l’agent fonctionne en boucle ReAct : les règles injectées dans le prompt doivent être renvoyées à de multiples étapes. Un corpus complet alourdit donc l’entrée à chaque tour.
La publication avance que la récupération curatée pour gpt-oss-120b apporte un gain de performance avec seulement 5 % de tokens supplémentaires par rapport à la baseline. Elle souligne aussi que le prompt caching peut rendre l’injection d’un corpus complet plus abordable en production. Mais les détails chiffrés complets du tableau de coûts ne figurent pas dans le contenu fourni : il serait imprudent d’extrapoler un coût précis à un autre fournisseur ou à une autre architecture d’agent.
Pour une équipe qui pilote une application réelle, la conséquence est claire : il faut suivre ensemble le taux de réussite, la latence et les tokens par tâche. Optimiser uniquement le score fonctionnel peut conduire à une solution trop chère dès qu’elle passe à l’échelle.
Comment tester la bonne dose sur ton agent
Tu peux reprendre la logique de l’étude sans reproduire exactement son infrastructure. Commence par enregistrer les trajectoires de ton agent : appels d’outils, étapes réussies, échecs, corrections humaines et erreurs répétées. Transforme-les en règles courtes, vérifiables et actionnables plutôt qu’en résumés vagues.
- Constitue un jeu d’évaluation séparé des données qui servent à produire les règles.
- Mesure une baseline sans mémoire.
- Teste le jeu complet de guidelines à chaque étape.
- Teste un noyau de règles générales et une récupération ciblée par tâche.
- Compare le succès complet, les erreurs par scénario, les tokens, le temps de réponse et les appels d’outils.
Le bon résultat n’est pas forcément la configuration qui contient le plus de mémoire. C’est celle qui réduit de façon reproductible les échecs que ton agent commet encore, avec un coût acceptable. Si aucune variante ne progresse, ne force pas l’ajout de contexte : examine plutôt la qualité des règles, le routage des outils et la nature des échecs observés.