Sanjana Pedada dote les agents LLM d’une mémoire sélective

Une nouvelle architecture Sanjana Pedada, Aditya Dhavala et Neelraj Patil présentent une mémoire persistante sélective pour les systèmes d’agents LLM. Leur travail sera présenté à la conférence EMNLP en septembre 2026. Ces agents produisent du code grâce à plusieurs échanges avec des outils. Chaque nouvelle session recommence pourtant sans les choix de configuration précédents. Elle perd aussi les contraintes métier, les schémas de données et les habitudes d’utilisation des outils. Les auteurs proposent de conserver ces éléments réutilisables, sans enregistrer les traces de raisonnement propres à chaque session. La méthode vise ainsi à maintenir un contexte utile, plutôt qu’un historique conversationnel complet.

Quatre catégories conservées L’architecture retient les spécifications de tâche, les schémas de données, les configurations d’outils et les contraintes de sortie. Elle écarte les traces de raisonnement spécifiques à une session. Cette sélection répond au problème posé par la conservation intégrale des conversations. Selon les auteurs, le contexte non pertinent dégrade la qualité des générations. La mémoire peut aussi être partagée entre plusieurs utilisateurs. Des espaces de travail encapsulent les informations retenues et peuvent être transférés avec un contrôle d’accès fondé sur les rôles. Les utilisateurs réemploient ainsi un contexte accumulé sans répéter les mêmes spécifications à chaque nouvelle interaction.

Les agents réutilisent quatre contextes

Une plateforme collaborative Les chercheurs ont déployé cette architecture dans une plateforme collaborative. Les agents y produisent, modifient et maintiennent des artefacts suivis par Git. Ces artefacts comprennent des tableaux de bord interactifs, des rapports structurés et des documents fondés sur des données. La plateforme accède à plusieurs sources hétérogènes. Elle prend en charge les téléversements CSV, les bases SQL, les API REST et les serveurs MCP. Le versionnage avec Git isole les brouillons pendant les modifications. Les utilisateurs peuvent donc explorer une version, puis restaurer un état antérieur sans relancer le modèle. Cette isolation limite le risque associé aux changements expérimentaux.

Des gains mesurés Dans trois scénarios de déploiement en entreprise, la mémoire sélective atteint 96 % de réussite des tâches. Le taux atteint 79 % sans mémoire et 71 % avec un historique complet. La conservation intégrale dégrade donc la réalisation des tâches dans cette comparaison. Les auteurs l’associent à un biais introduit par des traces de raisonnement devenues obsolètes. La génération guidée par des résumés réduit aussi le coût en jetons par invocation d’un facteur 97 par rapport à l’injection des données brutes. Ces résultats portent sur l’architecture déployée et sur les trois scénarios d’entreprise évalués par l’équipe de recherche.

Le rafraîchissement évite une nouvelle invocation

Des mises à jour sans jeton Un mécanisme complémentaire sépare les programmes générés des données utilisées à l’exécution. Il permet de réutiliser un artefact lorsque les données récurrentes sont actualisées. Le modèle n’a alors pas besoin d’être invoqué de nouveau. Les auteurs rapportent une réduction de 14 fois du temps par tâche pour ce rafraîchissement sans jeton. Une réplication sur quatre jeux de données publics confirme également ce mécanisme. Les douze essais réalisés aboutissent à un rafraîchissement réussi. Cette approche concerne les mises à jour de données, tandis que la mémoire sélective concerne le contexte réutilisable entre sessions. Les deux mécanismes sont présentés comme complémentaires.

Une collaboration contrôlée Le partage repose sur des espaces de travail et un contrôle d’accès par rôles. Cette organisation permet à plusieurs utilisateurs de récupérer les spécifications, schémas, configurations et contraintes déjà enregistrés. Les artefacts restent versionnés par Git, avec une isolation des brouillons et une restauration possible des états précédents. Les résultats rapportés couvrent trois scénarios d’entreprise et quatre jeux de données publics. L’article complet est disponible sur la page de recherche, tandis que la publication peut être consultée sur arXiv. Les prochaines étapes décrites par les auteurs reposent sur cette architecture déployée et ses mécanismes de réutilisation.