Salut tout le monde, Alex ici d’agntai.net. Nous sommes en mars 2026, et je me bats avec quelque chose qui est probablement dans l’esprit de beaucoup d’entre vous : comment construisons-nous réellement des agents qui ne ressemblent pas juste à des appels d’API glorifiés, mais qui exhibent véritablement un certain niveau de comportement intelligent et persistant ? Plus précisément, j’ai beaucoup réfléchi aux architectures de mémoire pour les agents IA. C’est une chose de faire en sorte qu’un modèle GPT réponde à une question ; c’est quelque chose de totalement différent d’avoir un agent qui se souvient d’un projet sur plusieurs jours, adapte sa stratégie en fonction des échecs passés et apprenne véritablement des interactions.
Depuis un certain temps, beaucoup d’entre nous s’appuient largement sur les bases de données vectorielles comme notre mémoire externe principale pour les agents. Et ne vous méprenez pas, elles sont fantastiques pour la génération augmentée par récupération (RAG) et pour donner à nos agents accès à d’énormes quantités d’informations factuelles ou contextuelles. Mais après avoir construit quelques prototypes pour des clients – l’un d’eux étant censé être un assistant de recherche personnel, un autre un bot de support client dynamique – j’ai commencé à remarquer leurs limitations. Elles sont excellentes pour « de quoi avons-nous parlé mardi dernier ? » ou « quelles sont les principales caractéristiques du produit X ? », mais elles ont du mal avec « souviens-toi de cette préférence subtile que j’ai exprimée il y a trois semaines et intègre-la dans ta recommandation actuelle. »
J’ai compris cela en essayant de faire comprendre à mon agent assistant de recherche que je *déteste vraiment* les articles trop académiques, sauf si c’est absolument nécessaire. Je lui disais cela, il acquiesçait, puis deux jours plus tard, il me donnait un autre article arXiv dense sur les genoux. Les embeddings vectoriels pour « détester les articles académiques » étaient là, mais l’agent n’apprenait pas vraiment de mes retours d’une manière qui modifiait véritablement sa stratégie de recherche à long terme. C’était comme parler à quelqu’un qui a une excellente mémoire à court terme mais pas de mémoire à long terme pour les préférences personnelles ou le contexte évolutif.
Au-delà de la recherche vectorielle : le besoin d’une mémoire multimodale
Ma conclusion ? Nous devons aller au-delà d’une dépendance unique aux bases de données vectorielles pour la mémoire des agents. Il ne s’agit pas de les remplacer, mais de les compléter par d’autres formes de mémoire qui s’adaptent à différents types d’informations et à différents horizons temporels. Pensez à la façon dont les humains se souviennent des choses. Nous avons une mémoire de travail à court terme, une mémoire épisodique (événements), une mémoire sémantique (faits) et une mémoire procédurale (comment faire les choses). Un seul embedding vectoriel d’un segment de conversation ne sépare pas proprement tout cela.
Le problème de se fier uniquement à la recherche vectorielle pour tout est qu’elle traite tous les souvenirs comme également importants et également structurés. Une préférence subtile, une croyance fondamentale, un objectif à long terme ou une observation transitoire – tout est amalgamé dans des embeddings. Lorsque l’agent interroge sa mémoire, il récupère ce qui est sémantiquement similaire, mais pas nécessairement ce qui est *le plus pertinent* d’une manière profondément contextuelle ou temporellement consciente. C’est comme avoir une bibliothèque où chaque livre est juste une collection de mots-clés, et vous ne pouvez trouver des choses qu’en faisant correspondre ces mots-clés, pas en comprenant le genre du livre, l’intention de l’auteur ou sa place dans une série.
Alors, à quoi ressemble une architecture de mémoire « multimodale » pour un agent IA ? Pour moi, cela se résume à séparer et structurer différents types d’informations, puis à faire en sorte que le moteur de raisonnement central de l’agent décide intelligemment quel magasin de mémoire consulter et comment le mettre à jour.
1. Mémoire à court terme / mémoire de travail : le bloc-notes
C’est le contexte immédiat de votre agent. C’est ce à quoi l’agent pense activement en ce moment. Pour moi, cela se traduit généralement par une simple liste des tournures récentes d’une conversation, des paramètres de tâche actuels et des observations transitoires. C’est volatile, cela est effacé ou résumé fréquemment. Pensez-y comme à la RAM de l’agent.
Exemple : Si mon agent assistant de recherche est actuellement chargé de « trouver des articles sur les améliorations de l’architecture des transformateurs de 2024 », sa mémoire de travail contient cette requête spécifique, les derniers articles qu’il a examinés et peut-être un drapeau indiquant qu’il est toujours en train de chercher. Cela est généralement géré en passant directement l’historique des conversations récentes au LLM ou en le gardant dans un simple tampon en mémoire.
2. Mémoire épisodique : le journal des événements
C’est là où les bases de données vectorielles brillent vraiment, mais avec une nuance. Au lieu de simplement intégrer des morceaux de conversation bruts, je trouve plus utile de *résumer* et de *taguer* les événements avant de les intégrer. Un « événement » pourrait être une interaction utilisateur, une action d’agent, une décision prise, ou une observation clé. Chaque événement reçoit un horodatage, une brève description, et peut-être quelques entités ou sentiments associés.
Pourquoi résumer/taguer ? Parce qu’une transcription de conversation brute peut être trop bruyante. « L’utilisateur a dit ‘c’est intéressant’ puis ‘pouvez-vous me montrer plus’ puis ‘et X ?’ » peut être résumé par « L’utilisateur a exprimé de l’intérêt, a demandé plus d’informations, puis a posé une question sur X. » Cela rend les embeddings plus centrés sur le *sens* de l’interaction plutôt que sur la phraséologie spécifique. Cela permet également un filtrage plus facile par tags par la suite.
# Pseudo-code Python pour une entrée de mémoire épisodique
class EpisodicMemoryEntry:
def __init__(self, timestamp, description, tags=None, associated_entities=None, raw_context=None):
self.timestamp = timestamp
self.description = description # Événement résumé par le LLM
self.tags = tags if tags is not None else []
self.associated_entities = associated_entities if associated_entities is not None else {}
self.raw_context = raw_context # Interaction originale pour un rappel détaillé si nécessaire
def to_embedding_text(self):
# Concaténer les champs pertinents pour l'embedding
return f"Événement à {self.timestamp} : {self.description}. Tags : {', '.join(self.tags)}. Entités : {self.associated_entities}"
# Exemple d'utilisation :
# Supposons que 'llm_summarize_event' soit une fonction qui appelle un LLM
# pour condenser un morceau de conversation en une description et extraire des tags/entités.
conversation_chunk = "Utilisateur : J'ai vraiment besoin de finir ce rapport d'ici vendredi. Agent : Très bien, comment puis-je vous aider ? Utilisateur : Pouvez-vous trouver les tendances du marché récentes pour l'IA dans la santé ? Je suis particulièrement intéressé par les tours de financement."
# Appel au LLM pour traiter ce morceau
summary, tags, entities = llm_summarize_event(conversation_chunk)
# summary : "L'utilisateur a demandé des tendances récentes du marché pour l'IA dans la santé, se concentrant sur les tours de financement, à rendre d'ici vendredi."
# tags : ["demande_de_recherche", "conscient_du_délai", "santé_IA", "tours_de_financement"]
# entities : {"topic" : "IA dans la santé", "deadline" : "vendredi", "focus" : "tours de financement"}
event = EpisodicMemoryEntry(
timestamp=datetime.now(),
description=summary,
tags=tags,
associated_entities=entities,
raw_context=conversation_chunk
)
# Ensuite, embarquez event.to_embedding_text() et stockez-le dans la base de données vectorielle
Lorsque l’agent a besoin de rappeler des événements passés, il interroge cette mémoire épisodique, mais maintenant il peut également filtrer par tags, entités ou plages temporelles, en plus de la similarité sémantique.
3. Mémoire sémantique : le graphe de connaissances des faits et croyances
C’est peut-être le domaine le moins développé dans de nombreuses architectures d’agents, mais c’est là où l’agent peut stocker des faits structurés, des relations et ses propres croyances ou préférences en évolution. Les bases de données vectorielles sont correctes pour des faits généraux, mais elles ne sont pas très efficaces pour représenter des relations (par exemple, « Alex préfère X à Y », « Le projet Z est une sous-tâche du projet A »).
C’est ici que j’ai commencé à expérimenter avec des graphes de connaissances. Au lieu d’intégrer tout, j’utilise des LLM pour extraire des triplets (sujet-prédicat-objet) des interactions et les stocker dans une base de données graphique (comme Neo4j ou même une simple base de données relationnelle si le graphe n’est pas trop complexe).
Pourquoi un graphe de connaissances ? Parce qu’il modélise explicitement les relations. Si mon agent apprend « Alex déteste les articles académiques », c’est une relation directe. S’il apprend ensuite « Les articles sur l’IA dans la santé sont souvent académiques », il peut déduire « Alex déteste probablement les articles sur l’IA dans la santé. » Ce genre de déduction est difficile avec juste la similarité vectorielle.
# Pseudo-code Python pour extraire et stocker des triplets
def extract_and_store_triples(agent_id, text_input):
# Appel LLM pour extraire les triplets.
# Indication : "Extraire des triplets factuels (sujet, prédicat, objet) du texte suivant.
# Exemple : 'Alex préfère le café' -> (Alex, préfère, café)."
# text_input = "L'utilisateur Alex a mentionné qu'il préfère des résumés concis et n'aime pas les articles trop académiques."
triples_str = call_llm_for_triple_extraction(text_input)
# Exemple de sortie : "[(Alex, préfère, résumés concis), (Alex, n'aime pas, articles académiques)]"
extracted_triples = parse_triples_string(triples_str) # Convertir la chaîne en liste de tuples
for s, p, o in extracted_triples:
# Stocker dans une base de données graph (par exemple, en utilisant un simple dict Python pour la démonstration)
# Dans un système réel, cela serait un appel client Neo4j ou similaire
graph_db_add_triple(agent_id, s, p, o)
# Exemple 'graph_db_add_triple' (simplifié)
knowledge_graph = {} # {sujet: {prédicat: [objets]}}
def graph_db_add_triple(agent_id, s, p, o):
if agent_id not in knowledge_graph:
knowledge_graph[agent_id] = {}
if s not in knowledge_graph[agent_id]:
knowledge_graph[agent_id][s] = {}
if p not in knowledge_graph[agent_id][s]:
knowledge_graph[agent_id][s][p] = []
if o not in knowledge_graph[agent_id][s][p]: # Empêcher les doublons
knowledge_graph[agent_id][s][p].append(o)
# Pour interroger :
# Qu'est-ce qu'Alex n'aime pas ? -> knowledge_graph[agent_id]["Alex"]["n'aime pas"]
L’agent peut interroger ce graph non seulement par des mots-clés, mais par des relations. « Quelles sont les préférences d’Alex ? » ou « Quelles tâches sont liées au Projet A ? » C’est une manière beaucoup plus puissante de récupérer des connaissances structurées.
4. Mémoire procédurale : La bibliothèque de compétences
Cela ne représente pas la mémoire au sens traditionnel, mais plutôt une collection d’outils, de fonctions et de flux de travail que l’agent sait exécuter. Lorsqu’un LLM décide qu’il doit effectuer une action, il consulte cette « bibliothèque de compétences ». Cela peut être une liste de fonctions Python, des spécifications API, ou même des flux de travail multi-étapes prédéfinis.
Mon expérience : J’ai trouvé utile de rendre ces compétences découvrables par le LLM en utilisant des docstrings descriptifs et des signatures de fonction claires. Le LLM peut alors choisir le bon outil en fonction de l’objectif actuel.
class AgentSkills:
def search_web(self, query: str) -> str:
"""
Recherche sur le web des informations liées à la requête.
Utile pour les connaissances générales, les nouvelles et les événements actuels.
Args:
query (str): La requête de recherche.
Returns:
str: Un résumé des résultats de recherche.
"""
# ... implémentation réelle de la recherche sur le web ...
return f"Résultats de recherche web pour '{query}': ..."
def analyze_document(self, document_id: str, analysis_type: str) -> str:
"""
Analyse un document spécifié pour divers insights.
Utile pour résumer, extraire des points clés, ou analyse de sentiment d'un document.
Args:
document_id (str): L'ID du document à analyser.
analysis_type (str): Le type d'analyse à effectuer (par exemple, 'résumé', 'mots-clés', 'sentiment').
Returns:
str: Le résultat de l'analyse.
"""
# ... implémentation d'analyse de document ...
return f"Analyse du document {document_id} pour {analysis_type}: ..."
def get_user_preferences(self, user_id: str, preference_type: str = None) -> dict:
"""
Récupère les préférences stockées pour un utilisateur spécifique.
Utile pour personnaliser les réponses et les actions.
Args:
user_id (str): L'ID de l'utilisateur.
preference_type (str, optionnel): Type spécifique de préférence à récupérer (par exemple, 'n'aime pas', 'sujets').
Returns:
dict: Un dictionnaire des préférences de l'utilisateur.
"""
# Cela interrogerait la mémoire sémantique (graph de connaissances)
# Pour simplifier, renvoyant des données fictives ici
if user_id == "Alex" and preference_type == "n'aime pas":
return {"n'aime pas": ["articles académiques", "explications verbeuses"]}
return {"préférences": "..."}
# Le LLM serait amené à sélectionner et appeler ces fonctions en fonction de son raisonnement.
Tout rassembler : La couche d’orchestration
La véritable magie réside dans la manière dont le moteur de raisonnement central de l’agent (le LLM lui-même, généralement) interagit avec ces différentes mémoires. Ce n’est pas juste un système de récupération passif ; l’agent doit décider activement :
- Quelle information ai-je besoin en ce moment ?
- Quel magasin de mémoire est le plus susceptible de contenir cette information ?
- Comment devrais-je mettre à jour ma mémoire en fonction de cette nouvelle interaction/observation ?
Ce processus de prise de décision est là où l’agent devient véritablement dynamique. Je structure généralement cela avec une indication qui guide le LLM à réfléchir à voix haute, planifier, puis exécuter des opérations mémoire. C’est une chaîne de processus de pensée qui incorpore l’interaction mémoire.
Mon approche actuelle :
- Percevoir : L’agent reçoit une entrée (requête utilisateur, événement système).
- Réfléchir et planifier : Le LLM analyse l’entrée, considère les objectifs actuels et formule un plan. Ce plan implique souvent d’interroger la mémoire.
- « Dois-je me souvenir des interactions passées (épisodiques) ? Quelles sont les préférences connues de l’utilisateur (sémantiques) ? Ai-je des outils pour réaliser cela (procédural) ? »
- Il pourrait interroger la mémoire épisodique pour des situations passées similaires ou la mémoire sémantique pour des faits pertinents.
- Agir : En fonction du plan et des souvenirs récupérés, le LLM décide d’une action (par exemple, générer une réponse, appeler un outil, mettre à jour la mémoire).
- Mémoriser et apprendre : Après une action, le LLM réfléchit sur le résultat et met à jour ses différentes mémoires.
- Une nouvelle interaction est résumée et ajoutée à la mémoire épisodique.
- De nouveaux faits ou préférences sont extraits et ajoutés au graph de connaissances sémantiques.
- Si une stratégie a échoué, elle pourrait générer une entrée « leçon apprise » dans la mémoire sémantique.
Ce processus itératif permet à l’agent de construire une compréhension plus riche et plus nuancée de son environnement, de son utilisateur et de lui-même au fil du temps. Cela va au-delà de la simple récupération de faits pour réellement former des croyances persistantes et adapter son comportement.
Conclusions pratiques pour votre architecture d’agent
Si vous construisez des agents IA en ce moment et que vous atteignez les limites d’une simple RAG, voici ce que je recommande d’essayer :
- Ne considérez pas toute la mémoire comme égale. Catégorisez le type d’information que vous devez stocker : contexte à court terme, historique des événements, faits préférentiels structurés et capacités.
- Augmentez votre base de données vectorielle. C’est formidable pour la mémoire épisodique, surtout lorsque vous résumez et taguez les entrées. Mais ne la faites pas le seul magasin de mémoire.
- Expérimentez avec des graphes de connaissances pour la mémoire sémantique. Même un simple magasin de triplets peut faire une énorme différence dans la manière dont votre agent stocke et récupère des relations structurées et des croyances fondamentales. Cela permet de véritable inférence, pas seulement de recherche de similarité.
- Concevez pour une gestion active de la mémoire. Le moteur de raisonnement central de l’agent (votre indication LLM) devrait explicitement inclure des étapes pour interroger, mettre à jour et réfléchir sur ses différents magasins de mémoire. Ne vous contentez pas de déverser tout le contexte dans une seule indication.
- Gardez la mémoire procédurale (utilisation des outils) organisée. Des descriptions claires et des exemples pour vos outils aident le LLM à utiliser efficacement ses capacités.
Construire de véritables agents intelligents ne concerne pas seulement des modèles plus grands ; il s’agit de conceptions plus intelligentes. En offrant à nos agents un système de mémoire plus humain, nous pouvons nous rapprocher d’agents qui non seulement se rappellent mais qui apprennent et s’adaptent réellement. C’est un chemin difficile mais incroyablement gratifiant, et je suis impatient de voir où nous allons tous le prendre ensuite.
🕒 Published: