Salut tout le monde, ici Alex d’agntai.net. Nous sommes en mars 2026, et je me débats avec quelque chose qui est probablement dans l’esprit de beaucoup d’entre vous : comment construire des agents qui ne ressemblent pas simplement à des appels API rehaussés, mais qui montrent vraiment un certain niveau de comportement intelligent et persistant ? Plus précisément, je pense beaucoup aux architectures de mémoire pour les agents IA. C’est une chose d’amener un modèle GPT à répondre à une question ; c’en est une autre d’avoir un agent qui se souvienne d’un projet de plusieurs jours, qui adapte sa stratégie en fonction des échecs passés, et qui apprenne véritablement des interactions.
Depuis un moment, beaucoup d’entre nous s’appuient fortement sur des bases de données vectorielles comme notre mémoire externe principale pour les agents. Et ne vous méprenez pas, elles sont formidables 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 essayant d’être un assistant de recherche personnel, l’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 caractéristiques clés 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 eu une révélation 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, il acquiesçait, puis deux jours plus tard, il me balançait un autre article dense d’arXiv dans les bras. Les vecteurs de représentation pour « je n’aime pas les articles académiques » étaient là, mais l’agent n’apprenait pas vraiment de mon retour d’une manière qui modifiait réellement sa stratégie de recherche à long terme. C’était comme parler à quelqu’un avec une excellente mémoire à court terme, mais sans 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 avec d’autres formes de mémoire qui répondent à différents types d’informations et à différents horizons temporels. Pensez à la manière 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 des choses). Un seul vecteur d’encodage d’un extrait de conversation ne sépare pas ces éléments de manière claire.
Le problème de s’appuyer uniquement sur la recherche vectorielle pour tout, c’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 – tous sont mélangés dans des représentations. 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 n’est qu’une collection de mots-clés, et où 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 revient à segmenter et structurer différents types d’informations, puis à faire en sorte que le moteur de raisonnement central de l’agent décide intelligemment quel stockage 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, il s’agit généralement d’une simple liste des tours récents d’une conversation, des paramètres de tâche actuels et des observations transitoires. C’est volatil, et cela est fréquemment effacé ou résumé. 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 quelques derniers articles qu’il a examinés, et peut-être un indicateur indiquant qu’il est encore en recherche. Cela est généralement géré en passant l’historique récent de la conversation directement 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à que les bases de données vectorielles brillent vraiment, mais avec une twist. 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 » peut être une interaction utilisateur, une action de l’agent, une décision prise, ou une observation clé. Chaque événement a un horodatage, une brève description, et peut-être quelques entités associées ou une indication de sentiment.
Pourquoi résumer/taguer ? Parce qu’un transcript de conversation brut peut être trop bruyant. « L’utilisateur a dit ‘c’est intéressant’ puis ‘pouvez-vous m’en montrer plus’ puis ‘qu’en est-il de X ?’ » peut être résumé en « L’utilisateur a exprimé son intérêt, a demandé plus d’informations, puis a posé des questions sur X. » Cela rend les représentations plus concentrées sur le *sens* de l’interaction plutôt que sur la formulation 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):
# Concatenate relevant fields for 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 extrait 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 : D'accord, comment puis-je aider ? Utilisateur : Pouvez-vous trouver les tendances du marché récentes pour l'IA dans le secteur de la santé ? Je suis particulièrement intéressé par les tours de financement."
# Appel LLM pour traiter cet extrait
summary, tags, entities = llm_summarize_event(conversation_chunk)
# summary : "L'utilisateur a demandé les tendances du marché récentes pour l'IA dans le secteur de la santé, en se concentrant sur les tours de financement, à rendre d'ici vendredi."
# tags : ["demande_de_recherche", "sensible_au_délai", "IA_santé", "tours_de_financement"]
# entities : {"topic": "IA dans le secteur de 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, intégrer event.to_embedding_text() et stocker 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 de temps, en plus de la similarité sémantique.
3. Mémoire sémantique : Le graphe de connaissances des faits et des 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 évolutives. Les bases de données vectorielles sont suffisantes pour des faits généraux, mais ne sont pas idéales pour représenter les 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 de simplement intégrer tout, j’utilise des LLM pour extraire des triplets (sujet-prédicat-objet) à partir 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 n’aime pas les articles académiques », c’est une relation directe. S’il apprend ensuite « les articles sur l’IA dans le secteur de la santé sont souvent académiques », il peut en déduire « Alex n’aime probablement pas les articles sur l’IA dans le secteur de la santé. » Ce genre d’inférence est difficile simplement avec la similarité vectorielle.
# Pseudo-code Python pour extraire et stocker des triples
def extract_and_store_triples(agent_id, text_input):
# Appel LLM pour extraire des triples.
# Prompt : "Extraire des triples 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 graphique (par exemple, en utilisant un dictionnaire Python simple pour la démonstration)
# Dans un système réel, ce serait un appel client Neo4j ou similaire
graph_db_add_triple(agent_id, s, p, o)
# Exemple de '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]: # Prévenir 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 graphique non seulement par des mots-clés, mais aussi par des relations. « Quelles sont les préférences d’Alex ? » ou « Quelles tâches sont liées au Projet A ? » C’est une façon beaucoup plus puissante de récupérer des connaissances structurées.
4. Mémoire Procédurale : La Bibliothèque de Compétences
Cela ne correspond 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 pourrait être une liste de fonctions Python, de spécifications d’API ou même de 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 descriptives 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 relatives à la requête.
Utile pour des connaissances générales, des actualités et des événements récents.
Args:
query (str): La requête de recherche.
Returns:
str: Un résumé des résultats de recherche.
"""
# ... mise en œuvre 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 aperçus.
Utile pour résumer, extraire des points clés ou pour l'analyse de sentiments 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.
"""
# ... mise en œuvre de l'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 (graphique de connaissances)
# Pour simplifier, renvoie 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 invité à sélectionner et à appeler ces fonctions en fonction de son raisonnement.
Mise en Œuvre : La Couche d’Orchestration
La véritable magie se produit dans la façon dont le moteur de raisonnement central de l’agent (le LLM lui-même, typiquement) interagit avec ces différents magasins de mémoire. Ce n’est pas simplement un système de récupération passif ; l’agent doit décider activement :
- Quelles informations 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 vraiment dynamique. Je structure typiquement cela avec un prompt qui guide le LLM à réfléchir à voix haute, à planifier, puis à exécuter des opérations de mémoire. C’est une chaîne de processus de pensée qui intègre l’interaction de mémoire.
Mon approche actuelle :
- Percevoir : L’agent reçoit une entrée (requête utilisateur, événement système).
- Réfléchir & 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.
- « Ai-je besoin de rappeler des interactions passées (épisodiques) ? Quelles sont les préférences connues de l’utilisateur (sémantiques) ? Ai-je des outils pour atteindre cela (procédurale) ? »
- 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 & Apprendre : Après une action, le LLM réfléchit au résultat et met à jour ses différents magasins de mémoire.
- Une nouvelle interaction est résumée et ajoutée à la mémoire épisodique.
- Nouveaux faits ou préférences sont extraits et ajoutés au graphique de connaissances sémantiques.
- Si une stratégie échoue, il pourrait générer une entrée « leçon apprise » dans la mémoire sémantique.
Ce processus itératif permet à l’agent de développer une compréhension plus riche et plus nuancée de son environnement, de son utilisateur et de lui-même au fil du temps. Il va au-delà de la simple récupération de faits pour réellement former des croyances persistantes et adapter son comportement.
Conseils Pratiques pour l’Architecture de Votre Agent
Si vous construisez des agents AI en ce moment et atteignez des limites de RAG simple, voici ce que je recommande d’essayer :
- Ne traitez pas toute la mémoire de la même manière. Catégorisez le type d’informations que vous devez stocker : contexte à court terme, historique des événements, faits/ préférences structurés, et capacités.
- Augmentez votre base de données vectorielle. Elle est excellente pour la mémoire épisodique, surtout lorsque vous résumez et étiquetez les entrées. Mais ne la faites pas le seul magasin de mémoire.
- Expérimentez avec des graphiques de connaissances pour la mémoire sémantique. Même un simple magasin de triples peut faire une énorme différence dans la façon dont votre agent stocke et récupère des relations structurées et des croyances fondamentales. Cela permet un véritable raisonnement, pas seulement une recherche de similarité.
- Concevez pour une gestion active de la mémoire. Le moteur de raisonnement central de l’agent (votre prompt 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 un seul prompt.
- Maintenez 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 se limite pas à des modèles plus grands ; il s’agit de conceptions plus intelligentes. En offrant à nos agents un système de mémoire plus semblable à celui des humains, nous pouvons nous rapprocher d’agents qui non seulement se souviennent mais apprennent et s’adaptent réellement. C’est un chemin difficile mais incroyablement gratifiant, et je suis impatient de voir où nous allons tous l’emmener ensuite.
🕒 Published: