Salut tout le monde, Alex ici de agntai.net. C’est mars 2026, et je me bats avec quelque chose qui, je pense, touche beaucoup d’entre vous qui travaillez avec des agents d’IA : la complexité de faire en sorte que ces choses fonctionnent réellement de manière fiable dans le monde réel. Nous avons dépassé la phase de la « démo cool » pour de nombreux systèmes d’agent. Maintenant, il s’agit de stabilité, de prévisibilité et de débogage lorsque les choses partent inévitablement en vrille.
Plus précisément, je veux parler de la mémoire des agents. Pas seulement du store vectoriel pour RAG, que tout le monde et leur chien mettent en œuvre, mais des systèmes de mémoire plus nuancés et multicouches qui permettent à un agent d’apprendre, de s’adapter et de maintenir le contexte sur de longues périodes et à travers différentes tâches. C’est ce qui sépare une simple interface API glorifiée de quelque chose qui ressemble véritablement à un assistant intelligent.
Quand j’ai commencé à construire mon agent « chef de projet », il y a un peu plus d’un an, mon système de mémoire était… primitif. Une simple liste des interactions passées, peut-être un rapide résumé ajouté à l’invite pour le tour suivant. Cela fonctionnait pour des conversations courtes, mais dès qu’il s’agissait de quelque chose de complexe, nécessitant de rappeler une décision prise trois jours auparavant ou une préférence exprimée dans un contexte totalement différent, tout s’effondrait. On avait l’impression de parler à quelqu’un ayant une perte de mémoire à court terme sévère.
Au-delà du Store Vectoriel : Le Besoin d’une Mémoire Multicouche
L’approche standard en ce moment, et un bon point de départ, est une base de données vectorielle pour récupérer des morceaux d’information pertinents. Vous déversez les conversations passées de votre agent, des documents, des observations – peu importe – dans des embeddings, puis utilisez la similarité sémantique pour extraire ce qui pourrait être utile pour la tâche actuelle. C’est efficace pour obtenir du contexte, mais ce n’est pas réellement de la « mémoire » au sens humain. C’est plutôt comme un moteur de recherche très efficace pour des expériences passées.
Pensez à la manière dont nous nous souvenons des choses. Nous avons la mémoire à court terme (notre contexte de travail), la mémoire à long terme (faits, compétences, événements passés) et la mémoire épisodique (expériences spécifiques liées à un temps et un lieu). Nous avons aussi la capacité de généraliser à partir d’expériences, de former des habitudes et de mettre à jour nos croyances. Un simple store vectoriel a du mal avec tout cela.
Mon agent « chef de projet », appelons-la ‘Orion’, devait faire plus que rappeler des messages passés. Elle devait :
- Se souvenir de mes préférences spécifiques quant à la manière dont les tâches sont décomposées.
- Suivre les objectifs globaux du projet, même en discutant d’un détail minute.
- Apprendre de ses échecs passés – par exemple, si une certaine décomposition de tâche entraînait systématiquement des retards, elle devrait proposer des alternatives la prochaine fois.
- Comprendre les relations entre différents morceaux d’informations.
Cela m’a conduit sur un chemin de création d’une architecture de mémoire plus sophistiquée. Voici ce que j’ai trouvé être une approche pratique, bien que toujours en évolution.
Couche 1 : Le Contexte Éphémère (Mémoire de Travail)
C’est votre contexte d’invite immédiat. Pour chaque tour, il contient l’entrée actuelle de l’utilisateur, les derniers échanges de conversation et tout fait ou directive immédiate. Cela est généralement directement transmis au LLM. C’est rapide, temporaire et crucial pour maintenir le flux.
Pour Orion, cela serait la tâche actuelle que je lui confie, toute question de suivi immédiate, et les 3 à 5 derniers échanges que nous avons eus. Je limite généralement cela à un nombre de tokens pour éviter le bourrage de prompt.
Couche 2 : L’Archive Sémantique (Mémoire Déclarative à Long Terme)
C’est ici que votre store vectoriel entre en jeu. C’est votre dépôt de toutes les interactions passées, observations, pensées générées, et de tout document externe auquel l’agent a accès. Lorsque le contexte éphémère n’est pas suffisant, Orion interroge cette archive pour récupérer des informations pertinentes.
La clé ici n’est pas simplement de tout déverser. Il s’agit de la manière dont vous segmentez et intégrez. Au lieu d’intégrer simplement des tours de conversation bruts, je fais souvent en sorte qu’Orion résume ou extraye des faits/ décisions clés des interactions, puis les intègre. Cela réduit le bruit et améliore la pertinence de la récupération.
def store_fact(agent_id, fact_text, fact_embedding, timestamp):
# C'est un exemple simplifié. En réalité, vous utiliseriez un client de base de données vectorielle.
db.insert_embedding(
collection_name=f"{agent_id}_facts",
text=fact_text,
embedding=fact_embedding,
metadata={"timestamp": timestamp}
)
def retrieve_relevant_facts(agent_id, query_embedding, k=5):
# Encore une fois, simplifié. Utilise la fonction de recherche de votre base de données vectorielle.
results = db.query_embeddings(
collection_name=f"{agent_id}_facts",
query_embedding=query_embedding,
top_k=k
)
return [r.text for r in results]
# Exemple d'utilisation :
# user_query = "Qu'avons-nous décidé concernant le budget marketing la semaine dernière ?"
# query_embedding = get_embedding(user_query)
# relevant_facts = retrieve_relevant_facts("Orion", query_embedding)
# print(relevant_facts)
J’ai également trouvé utile qu’Orion « réfléchisse » activement sur ses actions passées ou sur un ensemble de faits récupérés. Cela implique de demander au LLM un ensemble de mémoires récupérées et de lui demander de synthétiser de nouvelles idées de haut niveau ou de généraliser des motifs. Ces idées synthétisées sont ensuite également stockées dans l’archive sémantique, créant une boucle de rétroaction pour l’apprentissage.
Couche 3 : Le Graphe de Connaissances (Mémoire Relationnelle)
C’est ici que les choses deviennent vraiment intéressantes, et où Orion a commencé à sembler véritablement plus capable. Un graphe de connaissances vous permet de stocker des relations entre des entités, pas seulement des faits isolés. Au lieu de simplement savoir que « La Tâche A dépend de la Tâche B », un graphe peut montrer que « La Tâche A fait partie du Projet X », « Le Projet X est dirigé par Alex », et « La Tâche B a échoué la dernière fois à cause de la Ressource Y. »
J’utilise une simple base de données de graphe de propriétés (comme Neo4j ou même une configuration SQLAlchemy personnalisée pour de plus petits projets) pour stocker les entités et leurs relations. Orion, après avoir traité une interaction ou récupéré des faits, se voit demander d’extraire des entités et des relations. Celles-ci sont ensuite ajoutées au graphe.
Par exemple, si je dis à Orion : « La nouvelle fonctionnalité ‘Mode Sombre’ doit être mise en œuvre d’ici la fin du mois prochain, et cela dépend de l’actualisation de l’interface utilisateur étant achevée en premier », Orion devrait :
- Identifier les entités : « Mode Sombre » (Fonctionnalité), « Actualisation de l’UI » (Tâche), « Fin du mois prochain » (Délai).
- Identifier les relations : « Mode Sombre » a_délai « Fin du mois prochain », « Mode Sombre » dépend_de « Actualisation de l’UI ».
Plus tard, lorsque je demande des nouvelles concernant « Mode Sombre », Orion peut interroger le graphe pour non seulement obtenir le délai mais aussi voir immédiatement sa dépendance. Cela permet de prendre des décisions plus éclairées et de faire des suggestions proactives.
# Fonction d'update simplifiée pour le graphe de connaissances
from py2neo import Graph, Node, Relationship
graph = Graph("bolt://localhost:7687", auth=("neo4j", "password"))
def update_knowledge_graph(agent_id, entities_relationships_json):
tx = graph.begin()
for item in entities_relationships_json:
if item["type"] == "entity":
node = Node(item["label"], name=item["name"])
tx.merge(node, item["label"], "name")
elif item["type"] == "relationship":
source = Node(item["source_label"], name=item["source_name"])
target = Node(item["target_label"], name=item["target_name"])
rel = Relationship(source, item["relationship_type"], target)
tx.merge(rel, item["relationship_type"])
tx.commit()
# Exemple de sortie LLM à analyser pour la mise à jour du graphe :
# {
# "entities": [
# {"type": "entity", "label": "Feature", "name": "Mode Sombre"},
# {"type": "entity", "label": "Task", "name": "Actualisation de l'UI"}
# ],
# "relationships": [
# {"type": "relationship", "source_label": "Feature", "source_name": "Mode Sombre",
# "relationship_type": "DEPENDS_ON", "target_label": "Task", "target_name": "Actualisation de l'UI"}
# ]
# }
# update_knowledge_graph("Orion", parsed_llm_output)
La beauté de cela est que la récupération du graphe n’est pas seulement sémantique ; elle est structurelle. Vous pouvez demander « toutes les tâches dépendant de l’Actualisation de l’UI » ou « tous les projets dirigés par Alex. » Cela apporte une toute nouvelle dimension aux capacités de raisonnement d’un agent.
Couche 4 : Le Système de Croyances (Mémoire Adaptative)
C’est la couche la plus difficile, et celle avec laquelle j’expérimente encore activement. Il s’agit de permettre à l’agent de mettre à jour ses modèles internes, croyances ou préférences basés sur l’expérience. Ce n’est pas juste rappeler un fait ; il s’agit de changer son comportement ou son processus de prise de décision.
Pour Orion, cela signifie des choses comme :
- Si je rejette systématiquement une certaine stratégie de décomposition de tâche, Orion devrait apprendre à ne pas la proposer à nouveau, ou du moins à la proposer avec des mises en garde.
- Si un membre spécifique de l’équipe manque systématiquement des délais, Orion devrait en tenir compte pour planifier ou attribuer des tâches à l’avenir.
- Si je préfère toujours des explications détaillées à des résumés de haut niveau, Orion devrait adapter son style de communication.
Mon approche actuelle ici implique une combinaison de deux choses :
- Stockage explicite des préférences : J’ai une table dédiée (ou une section dans le graphe de connaissances) pour stocker les préférences explicites ou les “règles” que Orion a apprises. Celles-ci sont souvent générées par Orion elle-même par réflexion (par exemple, “L’utilisateur préfère des décompositions de tâches détaillées”) ou lui sont dites explicitement. Ces préférences sont ensuite injectées dans le prompt lorsque c’est pertinent.
- Apprentissage par renforcement léger : C’est encore à ses débuts, mais pour certains points de décision (par exemple, choisir une stratégie de décomposition des tâches), j’explore l’utilisation d’un simple mécanisme de retour d’information. Si j’accepte une suggestion, elle reçoit un signal positif. Si je la rejette, un signal négatif. Ce signal ne met pas directement à jour un NN, mais peut influencer un “score de confiance” associé à une stratégie particulière, que Orion considère ensuite lorsqu’elle fait des suggestions futures. C’est moins une question d’optimisation d’une politique et plus de pondérer ses “heuristiques internes.”
Cette couche est moins axée sur la récupération et plus sur l’adaptation proactive. C’est la différence entre un agent qui connaît un fait et un agent qui internalise une leçon.
Mise en œuvre de l’ensemble : Un orchestrateur de mémoire
Avoir ces couches est une chose ; les faire fonctionner ensemble en est une autre. J’ai constaté que vous avez besoin d’un composant “Orchestrateur de Mémoire” qui décide quel système de mémoire interroger et quand. Il s’agit souvent d’un autre appel LLM, agissant comme un routeur.
Lorsque Orion reçoit une nouvelle entrée :
- L’orchestrateur vérifie d’abord le Contexte Éphémère. La réponse est-elle immédiatement disponible ?
- Si ce n’est pas le cas, il génère une requête et interroge l’Archive Sémantique (magasin de vecteurs) pour des interactions passées ou des faits pertinents.
- Concurremment, ou si la récupération sémantique n’est pas suffisante, il peut générer une requête graphique pour le Graphe de Connaissances afin d’extraire des informations relationnelles (dépendances, propriété, etc.).
- Enfin, avant de générer une réponse, il consulte le Système de Croyance pour voir s’il y a des préférences ou des règles apprises qui devraient influencer la sortie.
Toutes ces informations récupérées sont ensuite compilées et transmises au LLM principal pour générer la réponse ou l’action finale. C’est une série de récupérations et de filtrages en cascade qui rassemblent un contexte complet.
Défis et orientations futures
Construire ce système de mémoire multicouche n’a pas été sans ses maux de tête :
- Coût et latence : Chaque étape de récupération supplémentaire augmente les coûts de l’API et la latence. Vous avez besoin d’un routage et d’un cache intelligents.
- Consistance : Maintenir des faits cohérents à travers le magasin de vecteurs, le graphe de connaissances et le système de croyance est difficile. Parfois, Orion apprend quelque chose dans une couche qui est en conflit avec une autre.
- Débogage : Lorsque Orion prend une mauvaise décision, retracer quel composant de mémoire a fourni des informations trompeuses ou n’a pas réussi à récupérer quelque chose de crucial est un cauchemar.
- Évolution du schéma : Le schéma du graphe de connaissances n’est pas statique. À mesure qu’Orion apprend de nouveaux types d’entités ou de relations, je dois mettre à jour la structure du graphe et son prompt pour l’extraction.
En regardant vers l’avenir, je suis vraiment intéressé par l’exploration de moyens plus solides pour que l’agent s’auto-organise sa mémoire. Orion peut-elle automatiquement identifier les lacunes de son graphe de connaissances ? Peut-elle résumer et condenser proactivement des mémoires sans demande explicite ? Comment pouvons-nous mieux intégrer le “système de croyance” avec la boucle de raisonnement centrale sans simplement ajouter davantage dans le prompt ?
Conseils pratiques pour vos agents
Si vous construisez un agent d’IA et atteignez les limites d’une récupération de vecteurs simple, voici ce que je vous suggérerais de considérer :
- Commencez simple, puis développez : Ne tentez pas de construire toutes les couches en même temps. Faites d’abord fonctionner votre contexte éphémère et un magasin de vecteurs de base.
- Pensez au “Quoi” et au “Comment” :
- Quel type d’informations doit être mémorisé ? (Faits, relations, préférences, actions passées, plans ?)
- Comment ces informations doivent-elles être récupérées et utilisées ? (Recherche sémantique, parcours de graphes, recherche directe, application de règles ?)
- Adoptez la réflexion : Demandez régulièrement à votre agent de réfléchir sur ses actions passées, de synthétiser des idées et de mettre à jour ses magasins de mémoire. C’est crucial pour l’apprentissage.
- Pensez à un Graphe de Connaissances pour les données relationnelles : Si votre agent doit comprendre les dépendances, les hiérarchies ou des relations complexes, une base de données graphique est incroyablement puissante.
- Expérimentez avec des composants adaptatifs : Pour les préférences ou les comportements appris, explorez des magasins de préférences simples ou des heuristiques pondérées avant de vous lancer dans un apprentissage par renforcement à grande échelle.
- Construisez un orchestrateur de mémoire : Ne vous contentez pas de déverser toute la mémoire dans le prompt. Concevez un composant qui interroge intelligemment différentes couches de mémoire en fonction du contexte actuel et de la tâche.
- Itérez et déboguez : Les systèmes de mémoire sont complexes. Attendez-vous à passer beaucoup de temps à tester, déboguer et affiner la manière dont votre agent stocke et récupère des informations.
Le chemin vers des agents véritablement intelligents est long, mais construire des systèmes de mémoire sophistiqués et multicouches est une étape critique. Cela nous éloigne des chatbots réactifs pour nous diriger vers des agents qui peuvent réellement apprendre, s’adapter et fonctionner avec une compréhension plus profonde de leur monde. J’aimerais entendre vos expériences et vos approches sur la mémoire des agents – laissez un commentaire ci-dessous !
🕒 Published: