Mémoire à long terme consultable pour les agents d’ingénierie de données

Les agents sans état résolvent bien les problèmes. Ils sont mauvais pour se souvenir qu’ils les ont résolus.

Le problème de l’amnésie

Imaginez un agent qui passe presque une heure à gérer une erreur NoClassDefFoundError dans un notebook Databricks fraîchement généré. Il analyse la trace d’erreur, découvre la bibliothèque manquante dans le cluster de travail, applique une correction et confirme que l’exécution s’est déroulée sans problème. C’est une débogage autonome efficace.

Une semaine plus tard, un autre pipeline rencontre la même erreur, et l’agent n’a aucune idée d’avoir déjà été confronté à celle-ci. Toute la session de débogage se reproduit donc, avec un coût élevé en ressources, et il y a de fortes chances cette fois de trouver une solution différente.

Ce n’est pas une défaillance du modèle. C’est ainsi que les agents se comportent par défaut, et ils oublient de trois manières :

1. Lorsqu’une session se termine, tout ce qui a été appris disparaît.
2. Les sessions longues sont finalement résumées ou compressées, ce qui conserve l’intrigue générale mais élimine souvent les détails d’implémentation importants.
3. Dans les systèmes multi-agents, les agents travailleurs partent généralement d’un contexte vierge, n’héritent de rien des agents précédents et ne conservent rien une fois leur tâche terminée.

Une équipe gérant un système multi-agents qui génère des pipelines Databricks lakehouse payait cette « taxe de l’amnésie » dans les trois cas. Leur solution a été l’ajout d’une couche de mémoire à long terme consultable.

Que signifie la « mémoire consultable »

Deux choses différentes sont désignées sous le nom de mémoire dans les systèmes d’agents, il est donc nécessaire de préciser ces termes.

La fenêtre de contexte fonctionne comme la mémoire de travail de l’agent. Tout ce qui s’y trouve est immédiatement accessible au modèle, mais uniquement pendant la durée de la session. Une fois les informations supprimées, pour l’agent, elles ont disparu.

La mémoire à long terme est un stockage persistant qui survit aux sessions, aux tâches et aux agents. Cependant, il ne suffit pas de simplement stocker des informations. Ces dernières ne deviennent une mémoire utile que lorsqu’elles sont capturées automatiquement, peuvent être recherchées efficacement et rappelées dans la fenêtre de contexte lorsque c’est nécessaire. C’est cette dernière étape qui compte vraiment. Une leçon parfaite qui n’est jamais récupérée vaut autant rien, et une leçon récupérée est inutile si elle n’atteint pas l’agent qui prend la décision.

La science cognitive propose une taxinomie qui s’adapte bien aux systèmes d’agents :

• Mémoire épisodique : elle conserve des enregistrements d’expériences passées spécifiques, tels que des transcriptions de sessions archivées, des échecs antérieurs avec leurs solutions, ou des décisions prises lors de versions précédentes.
• Mémoire sémantique : elle contient des faits structurés tels que « l’entité X appartient au produit de données Y » ou « ce système source s’authentifie de cette manière », de préférence avec des intervalles de validité, car les faits changent.
• Mémoire procédurale : il s’agit des savoir-faire, des fichiers d’instructions, des compétences ainsi que des conventions chargées à chaque session.

Deux niveaux de mémoire

Une décision a considérablement simplifié les choses : diviser la mémoire en deux niveaux.

Niveau 1, mémoire curatée. Un petit ensemble de règles, maintenu manuellement, chargé à chaque session. Il s’agit de normes architecturales, de exigences de sécurité, de conventions de nommage et de contraintes de gouvernance. L’espace de stockage est précieux, donc ce niveau est réservé à ce qui doit toujours être disponible.

Niveau 2 : mémoire recherchable. Un vaste archivage d’expériences capturées automatiquement et consultées uniquement lorsque c’est pertinent : correctifs validés, découvertes liées au dépannage, leçons tirées des déploiements et signatures de pannes récurrentes. Par défaut, il reste hors de portée de la requête.

Règle générale :

Un fait qui doit être respecté à chaque fois doit figurer dans le niveau curé. Un fait utile en cas de situation similaire doit être conservé dans le niveau recherchable.

Cette séparation permet de conserver les connaissances sans submerger la fenêtre de contexte.

Le système multi-agents qui en avait besoin

Le système en question gère l’ensemble du cycle de vie de l’ingénierie des données, transformant une exigence métier en pipeline et tableau de bord prêts à être mis en production. Un orchestrateur coordonne des travailleurs spécialisés, chacun ayant une seule tâche et uniquement les outils nécessaires :

• Spécification fonctionnelle : lecture de la demande, rédaction d’une spécification et obtention de l’approbation du demandeur humain.
• Conception technique : transformation de la spécification approuvée en un plan détaillé des contrats de données et des mappages source-cible.
• Ingestion, transformation et intégration : création du code correspondant au pipeline réel. Cela inclut des notebooks Bronze qui extraitent les données depuis Kafka, SAP, REST ou des fichiers, des notebooks Silver qui reformattent les données, ainsi que des modèles dimensionnels Gold, tous organisés selon un schéma en médailles.
• Validation : seul agent autorisé à accéder à un cluster en production. Il exécute chaque notebook généré sur des tables temporaires et vérifie les résultats.
• Repository : gestion des branches, des commits et des demandes de fusion.
• Surveillance : suivi du processus CI/CD une fois qu’une modification a été intégrée.

Tableau de bord : crée des tableaux de bord analytiques à partir des résultats.

Suivi des coûts : indique le coût total de tout cela.

L’architecture est délibérément isolante. Les travailleurs s’exécutent en parallèle avec une propriété de fichiers indépendante, ne peuvent pas communiquer entre eux et commencent chaque tâche dans un contexte complètement vierge. L’orchestrateur rédige une instruction de tâche autonome, le travailleur effectue une tâche définie, renvoie un résultat puis disparaît.

L’isolation rend le système sûr et parallélisable. Elle aggrave également l’amnésie par rapport à une configuration à un seul agent, car chaque travailleur « naît » à chaque fois comme s’il était nouveau. Chaque rôle accumule son propre type d’expérience qu’il estime utile de conserver, mais aucune d’elles ne survit à la fin d’une tâche à moins que quelque chose en dehors de leur contexte ne la préserve.

Conception de la mémoire pour de nombreux agents

Quatre mécanismes permettent de résoudre ce problème.

1. Capture automatique

Les hooks en temps de exécution de l’agent s’activent à deux moments : lorsque une session se termine et juste avant que le contexte ne soit compressé. Chacun d’eux lit la transcription et extrait des leçons réutilisables pour les stocker dans une mémoire. Personne n’a besoin de se souvenir d’écrire de la documentation ou de mettre à jour une base de connaissances.

Les opérations sur la mémoire sont également non bloquantes. Si l’infrastructure de mémoire tombe en panne, les hooks ne font rien. La couche de mémoire est là pour aider ; elle ne doit jamais devenir quelque chose sans quoi le travail réel ne peut pas progresser.

2. Accès ciblé

L’orchestrateur possède l’ensemble complet des outils de mémoire. Les travailleurs n’ont que trois capacités : lire leur propre journal, écrire leur propre journal et rechercher dans le stockage. Ce sont les outils qui imposent ces règles, et non les instructions, ce qui permet de maintenir des responsabilités claires et d’empêcher les travailleurs de modifier la mémoire en dehors de leurs compétences.

3. Journaux spécifiques aux rôles

Chaque travailleur dispose d’un espace de noms mémoire privé. Les pannes en temps de exécution ainsi que les correctifs validés s’accumulent dans le journal de l’agent de validation, tandis que le moniteur CI/CD collecte les signatures des pannes et les solutions qui ont fonctionné. Les autres agents conservent des registres tout aussi restreints.

Ces journaux ne constituent pas des canaux de communication. Les travailleurs ne transmettent pas de messages via la mémoire, et la coordination reste entre les mains de l’orchestrateur, qui assure la cohérence et la pertinence de chaque journal.

4. Rappel au niveau du contexte

Ce fut la décision la plus importante. Les travailleurs commencent avec un contexte vide, de sorte qu’une mémoire récupérée ne sert à rien tant qu’elle n’a pas été injectée dans ce contexte. La règle à suivre est :

Une mémoire qui a été récupérée mais qui n’a pas été placée dans le contexte n’existe pas pour le travailleur.

Lorsque des leçons pertinentes sont trouvées, l’orchestrateur les écrit directement dans le contexte de la tâche avant d’envoyer le travail. La simple récupération ne suffit pas ; pour être appliquée, une leçon doit être visible.

Construction sur MemPalace

Cette couche est construite sur MemPalace, un framework de mémoire open source axé sur l’utilisation locale. Le stockage, les embeddings ainsi que l’index de recherche fonctionnent tous localement, de sorte que aucune donnée ne quitte l’environnement, ce qui est crucial lorsque des agents traitent des données d’entreprise et des systèmes de production.

MemPalace conserve les mémoires sous forme de fragments de texte enrichis de métadonnées telles que l’agent créateur, une catégorie et une date et heure, organisés dans des espaces de noms distincts. Cela permet aux journaux spécifiques à chaque rôle de fonctionner efficacement : chaque agent écrit dans son propre espace et développe ainsi des compétences au fil du temps.

La capture s’effectue via les points d’ancrage du cycle de vie mentionnés ci-dessus. À la fin de la session, ou avant la compression, la transcription est nettoyée, transformée en leçons réutilisables, intégrée à un modèle ONNX local et indexée pour être récupérée ultérieurement. Tout cela se déroule en arrière-plan, de sorte que les agents n’attendent jamais les opérations de mémoire.

La récupération est hybride, combinant la similarité vectorielle avec la correspondance par mots-clés. Cela est utile en ingénierie de données, où certains signaux sont sémantiques tandis que d’autres sont des chaînes de caractères exactes. Un nom d’erreur tel que NoClassDefFoundError ou une version exacte du runtime Databricks doit correspondre littéralement, mais le même problème formulé différemment doit tout de même être retrouvé.

Les agents accèdent à la mémoire via MCP. L’orchestrateur voit l’ensemble de l’ensemble d’outils, tandis que les travailleurs ne voient que diary_read, diary_write et search, avec des limites imposées par les outils plutôt que par des instructions.

MemPalace a été choisi car il privilégie les solutions locales, est gratuit et facile à intégrer, mais son architecture n’en dépend pas. Mem0, Zep ou Letta pourraient remplir la même fonction. Ce qui compte, ce n’est pas le framework, mais le cycle de feedback : enregistrer l’expérience, la conserver, et la mettre à disposition lorsque le même problème réapparaît.

Qu’est-ce qui a changé en pratique

Le premier avantage visible a été la triage des pannes. La règle fondamentale pour l’agent de validation est simple : en cas de panne, effectuer une recherche avant de déboguer.

mempalace_search(query="NoClassDefFoundError DBR 14.3")

Lorsqu’une solution est retrouvée, l’agent bénéficie d’une leçon tirée d’une résolution antérieure réussie :

Le carnet Bronze destiné aux commandes est tombé en panne sur DBR 14.3 en raison d’une erreur NoClassDefFoundError liée au désérialiseur Avro. Ce qui a permis de le résoudre : déclarer explicitement la bibliothèque de sérialisation dans la configuration du cluster de tâches.

La différence est considérable. Au lieu de devoir découvrir une solution à partir de zéro, l’agent part des éléments prouvant qu’une méthode a fonctionné. Et la valeur ajoutée ne réside pas seulement dans la vitesse : c’est aussi la cohérence. Sans mémoire, deux agents confrontés au même problème pourraient chacun choisir une solution différente, mais apparemment valide. Avec mémoire, le système choisit celle dont on sait qu’elle fonctionne et continue de l’utiliser.

D’autres domaines ont montré des améliorations similaires. Le moniteur CI/CD intègre désormais dans ses rapports diagnostiques les occurrences historiques d’une signature d’échec, les hooks de démarrage de session restituent le contexte récent pertinent, et les agents spécialisés acquièrent de l’expertise au fil du temps au lieu de devoir la reconstruire constamment.

Aucun reconditionnement n’est nécessaire. Le cycle d’apprentissage se déroule en dehors du modèle : expérience, leçon, stockage, récupération, application.

Leçons tirées de la production

Faites attention aux remplacements historiques. La première tentative a importé de grandes quantités d’anciens enregistrements. Les résultats étaient décevants, car les données plus anciennes éclipsaient souvent les leçons plus récentes et plus utiles, rendant la récupération des informations perturbée. L’équipe a abandonné cette importation massive et a recommencé à partir du jour où la capture en temps réel est devenue opérationnelle. La récente date et la qualité l’emportent sur le volume.

Écrivez les souvenirs en langage simple. Le cadre propose des formats d’entrée compacts, que l’équipe a adoptés. La récupération est optimale lorsque la leçon enregistrée contient exactement les mêmes mots que ceux utilisés lors d’une recherche ultérieure : noms de produits, noms d’entités, messages d’erreur et classes d’exception. La capacité de retrouvabilité est plus importante que la petite taille dans un stockage de souvenirs.

Soyez prudents quant à ce que vous notez. Tout ce que l’on voit ne mérite pas d’être conservé à long terme. Il vaut la peine de conserver les correctifs confirmés, les résultats validés et les leçons réutilisables. Il convient d’omettre les journaux de routine, les observations temporaires, les mises à jour de statut répétitives et les informations sensibles. Un mauvais stockage de souvenirs s’accumule rapidement et peut causer plus de dommages que son absence totale.

Points clés

Chaque fois que les agents effectuent des tâches répétitives, ils créent de l’expérience qui mérite d’être conservée. Ce que la mise en œuvre suggère :

• Diviser la mémoire en règles soigneusement sélectionnées et en une expérience répertoriable.
• Capter automatiquement les leçons, en particulier avant la compression du contexte.
• Accorder aux utilisateurs des permissions restreintes, basées sur leur rôle.
• Récupérer des informations avant de raisonner, lorsque un problème similaire a déjà pu être résolu.
• Intégrer directement les souvenirs rappelés dans la demande.
• Considérer les souvenirs comme des preuves, et non comme des vérités indiscutables.
• Préférer la qualité des souvenirs à leur quantité.

La leçon la plus importante est d’ordre architectural. Beaucoup d’efforts sont consacrés à rendre les agents plus intelligents, mais en pratique, la valeur à long terme provient du fait que les systèmes sachent se souvenir.

Lectures complémentaires

• Des modèles aux agents : réorganiser les trois lignes de défense — Comment la gouvernance MLOps s’applique aux systèmes d’agents : ce que chacune des trois lignes doit ajouter, où se situent les lacunes, et ce que signalent les régulateurs de l’UE, de la FDA et du secteur financier.
• Construire une mémoire d’agent qui dure pendant la conversation sans accumuler — Une conception en trois niveaux pour la mémoire des agents : permettre à l’état de session de disparaître, conserver des notes à long terme de taille réduite et modifiables, et récupérer des données en temps réel fraîches. Plus une analyse des échecs de transfert entre plusieurs agents.

Explication des agents : outils, prompts système et le cycle pensée-action — Un guide pour débutants sur le fonctionnement des agents d’IA : pourquoi les modèles de conversation oublient, comment décrire des outils à un LLM, les prompts système, ReAct, les agents de code et les observations.