Salut à tous, ici Alex d’agntai.net. Nous sommes en mars 2026, et je me débats avec quelque chose que je pense que beaucoup d’entre vous qui travaillent avec des agents IA ressentent probablement aussi : la complexité écrasante de faire en sorte que ces choses fonctionnent de manière fiable dans le monde réel. Nous avons dépassé la phase de “démo cool” pour de nombreux systèmes d’agents. Maintenant, il s’agit de stabilité, de prévisibilité et de débogage lorsque les choses vont inévitablement de travers.
Plus précisément, je veux parler de la mémoire des agents. Pas seulement du magasin vectoriel pour RAG, que tout le monde et son chien implémentent, mais des systèmes de mémoire plus nuancés et multi-tiers qui permettent à un agent d’apprendre, de s’adapter et de maintenir le contexte sur des périodes prolongées et à travers différentes tâches. C’est ce qui sépare un simple enveloppe API d’un véritable assistant intelligent.
Lorsque j’ai commencé à construire mon agent de “gestion de projet”, il y a un peu plus d’un an, mon système de mémoire était… primitif. Une simple liste d’interactions passées, peut-être un rapide résumé ajouté à l’invite pour le prochain tour. Cela fonctionnait pour des conversations courtes, mais pour tout ce qui était complexe, tout ce qui nécessitait que l’agent se souvienne d’une décision prise trois jours auparavant ou d’une préférence exprimée dans un contexte totalement différent, cela s’effondrait. C’était comme parler à quelqu’un qui avait de graves pertes de mémoire à court terme.
Au-delà du magasin vectoriel : le besoin d’une mémoire multi-niveaux
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éposez les conversations passées de votre agent, documents, observations – peu importe – dans des vecteurs, 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 vraiment de la “mémoire” au sens humain. C’est plus comme un moteur de recherche très efficace pour les expériences passées.
Pensez à comment 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 au temps et au 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 magasin vectoriel peine avec tout cela.
Mon agent “gestionnaire de projet”, appelons-la ‘Orion’, devait faire plus que simplement se souvenir des messages passés. Elle devait :
- Se souvenir de mes préférences spécifiques sur la manière dont les tâches sont décomposées.
- Garder une trace des objectifs globaux du projet, même en discutant d’un détail minutieux.
- Apprendre des échecs passés – par exemple, si un certain découpage de tâche entraînait systématiquement des retards, elle devrait proposer des alternatives la prochaine fois.
- Comprendre les relations entre différentes informations.
Cela m’a conduit à essayer de construire une architecture de mémoire plus sophistiquée. Voici ce que j’ai trouvé être une approche pratique, bien qu’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 conserve l’entrée utilisateur actuelle, les derniers échanges de conversation et toute information ou directive immédiate. Cela est généralement transmis directement au LLM. C’est rapide, temporaire et crucial pour maintenir le flux.
Pour Orion, cela serait la tâche actuelle que je lui donne, 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 prompts.
Couche 2 : L’archive sémantique (mémoire déclarative à long terme)
C’est là que votre magasin vectoriel entre en jeu. C’est votre dépôt de toutes les interactions passées, observations, pensées générées, et 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 juste de tout déverser. Il s’agit de la manière dont vous segmentez et incorporez. Au lieu d’incorporer simplement des échanges bruts de conversation, j’ai souvent obligé Orion à résumer ou à extraire des faits/décisions clés des interactions et ensuite à les incorporer. 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):
# Ceci est un exemple simplifié. En réalité, vous utiliseriez un client de DB vectoriels.
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 DB vectoriel.
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 = "Que avons-nous décidé au sujet du 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 de faire réfléchir activement Orion sur ses actions passées ou un ensemble de faits récupérés. Cela implique de proposer au LLM un ensemble de souvenirs récupérés et de lui demander de synthétiser de nouvelles informations de niveau supérieur ou de généraliser des motifs. Ces insights synthétisés sont ensuite également archivés dans l’archive sémantique, créant une boucle de rétroaction pour l’apprentissage.
Couche 3 : Le graphique des connaissances (mémoire relationnelle)
C’est ici que les choses deviennent vraiment intéressantes, et où Orion a commencé à se sentir véritablement plus capable. Un graphique des connaissances vous permet de stocker des relations entre des entités, pas seulement des faits isolés. Au lieu de savoir simplement “La tâche A dépend de la tâche B”, un graphique peut montrer que “La tâche A fait partie du projet X”, “Le projet X est géré 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 graphes de propriétés (comme Neo4j ou même un setup SQLAlchemy personnalisé pour des projets plus petits) pour stocker des entités et leurs relations. Orion, après avoir traité une interaction ou récupéré des faits, est invitée à extraire des entités et des relations. Celles-ci sont ensuite ajoutées au graphique.
Par exemple, si je dis à Orion : “La nouvelle fonctionnalité ‘Mode Sombre’ doit être mise en œuvre d’ici la fin du mois prochain, et elle dépend d’abord de l’actualisation de l’interface utilisateur”, Orion devrait :
- Identifier les entités : “Mode Sombre” (Fonctionnalité), “Actualisation de l’UI” (Tâche), “Fin du mois prochain” (Date limite).
- Identifier les relations : “Mode Sombre” a_date_limite “Fin du mois prochain”, “Mode Sombre” dépend_de “Actualisation de l’UI”.
Plus tard, lorsque je demande à propos de “Mode Sombre”, Orion peut interroger le graphique pour non seulement obtenir la date limite mais aussi voir immédiatement sa dépendance. Cela permet une prise de décision plus éclairée et des suggestions proactives.
# Fonction simplifiée de mise à jour du graphique des 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 graphique :
# {
# "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)
Ce qui est remarquable, c’est que la récupération à partir du graphique n’est pas juste sémantique ; c’est aussi structurel. Vous pouvez demander “toutes les tâches dépendantes de l’actualisation de l’UI” ou “tous les projets gérés par Alex.” Cela ajoute une toute nouvelle dimension aux capacités de raisonnement d’un agent.
Couche 4 : Le système de croyance (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 un rappel de faits ; il s’agit d’altérer 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écoupage de tâche, Orion devrait apprendre à ne plus la proposer, ou au moins à la suggérer avec des réserves.
- Si un membre spécifique de l’équipe manque systématiquement les délais, Orion devrait en tenir compte dans les futures planifications ou attributions de tâches.
- Si je préfère toujours des explications détaillées aux résumés généraux, 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 “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 explicitement communiquées. Ces préférences sont ensuite injectées dans l’invite lorsqu’elles sont pertinentes.
- Apprentissage par renforcement léger : C’est en développement, mais pour certains points de décision (par exemple, choisir une stratégie de décomposition de tâches), j’explore l’utilisation d’un simple mécanisme de rétroaction. 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 réseau de neurones, mais il pourrait influencer un “score de confiance” associé à une stratégie particulière, que Orion prend ensuite en compte lors de futures suggestions. Il s’agit moins d’optimiser une politique que de pondérer ses “heuristiques” internes.
Cette couche est moins axée sur la récupération et davantage sur l’adaptation proactive. C’est la différence entre un agent connaissant un fait et un agent internalisant une leçon.
Mettre le tout ensemble : Un orchestrateur de mémoire
Avoir ces couches est une chose ; les faire fonctionner ensemble en est une autre. J’ai constaté qu’il vous faut un composant “Orchestrateur de Mémoire” qui décide quel système de mémoire interroger et quand. Cela est souvent un autre appel à un 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 vectoriel) pour retrouver des interactions passées ou des faits pertinents.
- En parallèle, ou si la récupération sémantique n’est pas suffisante, il peut générer une requête 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 existe 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 finale ou l’action. C’est une série de récupérations et de filtrages en cascade qui rassemble un contexte approfondi.
Défis et orientations futures
Construire ce système de mémoire multi-couches 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 et la latence de l’API. Vous avez besoin d’un routage et d’un cache intelligents.
- Consistance : Maintenir la cohérence des faits à travers le magasin vectoriel, le graphe de connaissances et le système de croyance est difficile. Parfois, Orion apprend quelque chose dans une couche qui entre en conflit avec une autre.
- Débogage : Lorsque Orion prend une mauvaise décision, retracer quel composant de mémoire a fourni de fausses informations ou n’a pas réussi à récupérer quelque chose de crucial est un véritable 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 invite pour l’extraction.
En regardant vers l’avenir, je suis très intéressé à explorer des moyens plus solides pour l’agent d’auto-organiser sa mémoire. Orion peut-elle identifier automatiquement des lacunes dans son graphe de connaissances ? Peut-elle résumer et condenser proactivement des souvenirs sans invite explicite ? Comment pouvons-nous mieux intégrer le “système de croyance” avec la boucle de raisonnement de base sans simplement ajouter plus d’éléments à l’invite ?
Conseils pratiques pour vos agents
Si vous construisez un agent AI et atteignez les limites d’une récupération vectorielle 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 une seule fois. Faites d’abord fonctionner votre contexte éphémère et un magasin vectoriel de base.
- Pensez à “Quoi” et “Comment” :
- Quel type d’informations doit être mémorisé ? (Faits, relations, préférences, actions passées, plans ?)
- Comment ces informations devraient-elles être récupérées et utilisées ? (Recherche sémantique, traversée de graphe, recherche directe, application de règles ?)
- Acceptez la réflexion : Invitez régulièrement votre agent à réfléchir sur ses actions passées, synthétiser des idées et mettre à jour ses mémoires. Cela est crucial pour l’apprentissage.
- Considérez un graphe de connaissances pour les données relationnelles : Si votre agent doit comprendre des dépendances, des 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 à part entière.
- Construisez un orchestrateur de mémoire : Ne déversez pas simplement toute la mémoire dans l’invite. 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 comment 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 multi-couches est une étape cruciale. Cela nous propulse au-delà des chatbots réactifs vers des agents qui peuvent vraiment 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: