Accueil › Glossaire › Episodic Memory

Episodic Memory (Mémoire Épisodique)

L’episodic memory (mémoire épisodique) est un type de mémoire à long terme qui permet à un agent IA de stocker, indexer et rappeler des expériences passées spécifiques, avec leur contexte temporel, situationnel et causal, pour guider ses décisions futures.

Qu’est-ce que l’episodic memory en IA ?

En psychologie cognitive, la mémoire épisodique désigne la capacité de se souvenir d’événements vécus personnellement : un voyage à Paris, une conversation avec un ami, un échec professionnel. Le psychologue Endel Tulving a formalisé cette distinction en 1972, en la séparant de la mémoire sémantique (les faits généraux sur le monde).

Transposée à l’intelligence artificielle, l’episodic memory donne à un agent la capacité de se souvenir non pas de faits abstraits, mais d’expériences concrètes : quand un événement s’est produit, dans quel contexte, avec quels participants, et surtout quel résultat il a produit. C’est la différence entre savoir que « les actions tech sont volatiles » (sémantique) et se rappeler que « le 15 janvier, j’ai recommandé un portefeuille tech à l’utilisateur A, et il a sous-performé de 12% en trois mois » (épisodique).

Cette distinction est fondamentale pour les agents IA actuels. Un LLM seul est stateless : chaque requête repart de zéro, sans aucune continuité. La mémoire épisodique transforme un chatbot réactif en système capable d’apprendre de son propre historique opérationnel.

Episodic memory dans la taxonomie CoALA

Le cadre de référence pour comprendre la mémoire des agents IA est le papier Cognitive Architectures for Language Agents (CoALA), publié par Sumers, Yao, Narasimhan et Griffiths. Inspiré de l’architecture cognitive SOAR des années 1980, CoALA organise la mémoire d’un agent en modules distincts :

Dans CoALA, l’agent exécute une boucle décisionnelle continue : il récupère des informations en mémoire à long terme (retrieval), raisonne en working memory via le LLM (reasoning), puis écrit de nouvelles connaissances en mémoire à long terme (learning). L’episodic memory sert spécifiquement lors du retrieval : quand l’agent rencontre une situation inédite, il recherche dans ses épisodes passés les expériences similaires pour adapter sa stratégie.

Comment fonctionne l’episodic memory pour un agent IA

Structure d’un épisode

Un épisode stocké en mémoire épisodique n’est pas un simple log brut de conversation. Il contient des métadonnées structurées qui permettent une récupération contextuelle :

C’est cette richesse contextuelle qui distingue l’episodic memory d’un simple historique de conversation. L’agent ne se contente pas de savoir ce qui a été dit : il sait quand, pourquoi, avec qui, et ce qui en a résulté.

Le cycle de vie d’un épisode

Le cycle complet de gestion d’un épisode en mémoire suit quatre étapes, quel que soit le framework utilisé :

1. Encodage (write time) : L’agent identifie qu’une interaction mérite d’être mémorisée. Le contenu est transformé en embedding vectoriel via un modèle d’embedding, puis stocké avec ses métadonnées dans une base vectorielle. C’est à cette étape que le gros du traitement a lieu : extraction de faits, résolution d’entités, génération d’embeddings. Les systèmes bien conçus optimisent pour des écritures lentes et des lectures rapides.

2. Stockage : L’épisode est persisté dans un store externe. Les implémentations courantes utilisent des vector databases (Pinecone, Weaviate, Chroma) pour la recherche sémantique, des event logs (Redis Streams) pour la vérité terrain chronologique, et parfois des knowledge graphs (Neo4j) pour les relations entre épisodes.

3. Récupération (retrieval) : Quand l’agent traite une nouvelle requête, il encode la requête en vecteur et cherche les épisodes sémantiquement similaires. Les meilleurs systèmes combinent recherche vectorielle (similarité cosinus) et filtrage par métadonnées (timestamp, user_id, type de tâche). Certains ajoutent une étape de synthèse via LLM pour raisonner sur les épisodes récupérés.

4. Consolidation et oubli : Au fil du temps, les épisodes redondants ou obsolètes doivent être compressés ou supprimés. C’est l’équivalent de la consolidation mnésique chez l’humain. Certains épisodes sont abstraits en connaissances sémantiques générales (un pattern récurrent devient une règle), d’autres sont simplement oubliés via un mécanisme de decay temporel.

Mémoire explicite vs implicite

Deux stratégies existent pour décider quand écrire en mémoire épisodique :

Mémoire explicite (hot path) : L’agent décide lui-même, en temps réel, que l’information courante mérite d’être mémorisée. Il appelle un outil de mémoire (via function calling) pour écrire l’épisode. C’est l’approche de Letta, où l’agent gère activement ses propres blocs de mémoire. L’avantage : l’agent priorise ce qui est pertinent. L’inconvénient : chaque décision de mémorisation consomme des tokens et ajoute de la latence.

Mémoire implicite (background) : La mémorisation est déclenchée programmatiquement à des moments définis, par exemple après chaque session ou à intervalles réguliers. Un processus externe analyse la conversation et extrait les faits saillants. C’est l’approche de Mem0, qui exécute une pipeline d’extraction sur chaque paire de messages. L’avantage : prévisibilité et pas d’impact sur le budget d’inférence. L’inconvénient : moins de contrôle fin sur ce qui est mémorisé.

Episodic memory vs semantic memory : quelle différence concrète ?

La confusion entre episodic et semantic memory est fréquente. Voici comment les distinguer en pratique :

Le point crucial : les deux se complètent. En production, un agent performant utilise l’episodic memory pour le raisonnement basé sur l’expérience (case-based reasoning) et la semantic memory pour les connaissances factuelles du domaine. La combinaison des deux, souvent via une architecture hybride avec vector search et knowledge graph, produit les meilleurs résultats.

Episodic memory vs RAG : ne pas confondre

L’episodic memory est souvent confondue avec le RAG (Retrieval-Augmented Generation). Les deux utilisent des vector databases et de la recherche sémantique, mais leurs objectifs divergent :

Le RAG récupère des documents externes existants pour enrichir une réponse. C’est une opération ponctuelle et statique : vous cherchez dans un corpus figé (documentation, base de connaissances) pour compléter le contexte du LLM.

L’episodic memory est dynamique et personnelle. Elle stocke les expériences propres de l’agent, évolue avec chaque interaction, et maintient un état qui persiste entre les sessions. Un système RAG ne sait pas que vous avez posé la même question il y a deux semaines et obtenu une réponse insatisfaisante. Un agent avec episodic memory, si.

En pratique, les deux coexistent : le RAG fournit la base de connaissances externes, l’episodic memory fournit l’historique expérientiel de l’agent. Mem0 illustre bien cette distinction : son pipeline d’extraction identifie les faits saillants de chaque interaction (episodic) et les compare aux mémoires existantes pour décider d’ajouter, mettre à jour ou supprimer (gestion d’état).

Implémentation technique : les frameworks en production

Mem0 : la mémoire comme service

Mem0 est le framework de mémoire agent le plus adopté, avec plus de 41 000 étoiles GitHub et 14 millions de téléchargements. Son approche : intégrer la mémoire en quelques lignes de code, indépendamment du framework d’orchestration utilisé (LangChain, CrewAI, AutoGen).

Le mécanisme est astucieux : quand vous ajoutez une interaction via add(), Mem0 exécute une pipeline d’extraction qui identifie les faits saillants et les compare aux mémoires existantes. Quatre opérations sont possibles : ADD (nouveau fait), UPDATE (mise à jour), DELETE (obsolète), NOOP (rien à faire). Si un utilisateur dit qu’il a déménagé de Mumbai à Bangalore, Mem0 supprime l’ancien fait et ajoute le nouveau. La plupart des systèmes RAG ne gèrent pas ce cas.

La variante Mem0g utilise des graphes orientés étiquetés (entités comme nœuds, relations comme arêtes) et excelle sur le raisonnement temporel. Sur le benchmark LOCOMO, Mem0 atteint un score LLM-as-a-Judge d’environ 67%, avec une latence p95 de seulement 0,2 seconde et une consommation d’environ 1 764 tokens par conversation contre 26 031 pour le contexte complet.

Letta (MemGPT) : la mémoire comme état de l’agent

Letta, issu du projet de recherche MemGPT à UC Berkeley, adopte une philosophie radicalement différente : traiter le contexte du LLM comme de la mémoire virtuelle, à la manière d’un système d’exploitation. L’agent ne se contente pas d’utiliser Letta pour sa mémoire : il tourne à l’intérieur de Letta.

Trois niveaux de mémoire inspirés de l’architecture informatique classique :

Core Memory (RAM) : petit bloc toujours présent dans la fenêtre de contexte. L’agent le lit et le modifie directement. Contient les informations prioritaires persistantes (persona, préférences utilisateur, objectifs).

Recall Memory (cache disque) : historique conversationnel indexé, stocké hors contexte. L’agent le fouille via des appels d’outils quand il a besoin d’un épisode passé.

Archival Memory (stockage froid) : mémoire à long terme pour les connaissances volumineuses. Requêtes via search, résultats injectés dans le contexte à la demande.

La différence fondamentale avec Mem0 : chez Letta, l’agent décide lui-même ce qu’il mémorise. Quand il juge une information importante, il appelle ses outils de mémoire pendant sa boucle de raisonnement pour écrire dans le niveau approprié. C’est la mémoire explicite en action.

Zep et LangMem : approches complémentaires

Zep se distingue par son knowledge graph temporel : il structure les interactions en séquences significatives et suit comment les faits évoluent dans le temps. C’est particulièrement adapté quand la dimension temporelle est critique (suivi de projets, relations client évolutives).

LangMem s’intègre nativement dans LangGraph comme couche de mémoire à long terme. Il supporte les types épisodique, sémantique et procédural, et gère l’extraction de faits ainsi que la mémoire comportementale (comment l’agent doit agir, pas seulement ce qu’il sait). Ses benchmarks sont honnêtes mais modestes : environ 58% sur LOCOMO, avec une latence p95 de près de 60 secondes, ce qui le rend impraticable pour les agents conversationnels temps réel mais adapté aux agents batch ou offline.

Tableau comparatif des frameworks mémoire

Exemple de code : episodic memory avec Python

Voici un exemple simplifié d’un store épisodique utilisant une vector database pour la recherche sémantique. Ce pattern est à la base de la plupart des implémentations en production :

import json
from datetime import datetime
from dataclasses import dataclass, asdict

@dataclass
class Episode:
    """Structure d'un épisode en mémoire."""
    timestamp: str
    user_id: str
    context: str       # situation, tâche en cours
    actions: str       # ce que l'agent a fait
    outcome: str       # résultat de l'interaction
    embedding: list    # vecteur pour la recherche sémantique

class EpisodicMemory:
    def __init__(self, embedding_model, vector_store):
        self.embedding_model = embedding_model
        self.vector_store = vector_store

    def encode(self, user_id: str, context: str,
               actions: str, outcome: str) -> Episode:
        """Encode et stocke un nouvel épisode."""
        # Créer le texte à vectoriser
        text = f"Contexte: {context} | Actions: {actions} | Résultat: {outcome}"
        embedding = self.embedding_model.encode(text)

        episode = Episode(
            timestamp=datetime.utcnow().isoformat(),
            user_id=user_id,
            context=context,
            actions=actions,
            outcome=outcome,
            embedding=embedding
        )

        # Stocker dans la vector database
        self.vector_store.upsert(
            id=f"ep_{user_id}_{episode.timestamp}",
            vector=embedding,
            metadata=asdict(episode)
        )
        return episode

    def recall(self, query: str, user_id: str,
               top_k: int = 5) -> list[dict]:
        """Récupère les épisodes les plus pertinents."""
        query_vector = self.embedding_model.encode(query)

        results = self.vector_store.query(
            vector=query_vector,
            filter={"user_id": user_id},
            top_k=top_k
        )
        return [r.metadata for r in results]

    def consolidate(self, user_id: str, llm) -> str:
        """Consolide les épisodes récurrents en règles sémantiques."""
        all_episodes = self.vector_store.list(
            filter={"user_id": user_id}
        )
        prompt = f"""Analyse ces {len(all_episodes)} épisodes.
Identifie les patterns récurrents et formule des règles générales.
Épisodes : {json.dumps([e.metadata for e in all_episodes])}"""

        return llm.generate(prompt)

Ce code illustre les trois opérations fondamentales : l’encodage d’un épisode (avec embedding pour la recherche sémantique), la récupération par similarité vectorielle filtrée par utilisateur, et la consolidation via LLM pour extraire des patterns récurrents en connaissances sémantiques.

Cas d’usage concrets

Support client personnalisé

Un agent de support avec episodic memory se souvient que l’utilisateur 42 a déjà signalé un bug de synchronisation il y a deux semaines, que le problème avait été résolu par un reset de cache, et que le client avait exprimé de la frustration face au temps de résolution. Lors du prochain contact, l’agent adapte son approche : il propose directement le reset de cache si le symptôme est similaire, et adopte un ton plus empathique.

Assistant de développement

Un agent de code mémorise que le développeur a rencontré une erreur de dépendance circulaire dans le module auth la semaine dernière, et que la solution impliquait un refactoring vers l’injection de dépendances. Quand un problème structurellement similaire apparaît dans un autre module, l’agent propose la même approche sans que le développeur ait besoin de réexpliquer le contexte.

Conseiller financier IA

L’agent se souvient que sa recommandation d’un portefeuille orienté tech il y a trois mois a sous-performé pour le client A, et que le client B a ignoré son conseil de diversification. Ces épisodes spécifiques enrichissent ses recommandations futures de manière que des connaissances financières générales seules ne pourraient pas.

Agent multi-sessions à horizon long

Un agent de planification qui gère un projet logiciel sur plusieurs mois utilise l’episodic memory pour se rappeler les décisions architecturales passées, les compromis acceptés, les préférences des parties prenantes, et les problèmes rencontrés lors des sprints précédents. Comme le souligne un papier de recherche de 2025, un agent assistant au développement d’un projet massif comme le noyau Linux devrait intégrer et raisonner en continu sur des décennies de contributions, d’issues et de décisions passées.

État de la recherche (2026)

L’episodic memory pour les agents IA est un domaine en pleine ébullition. Plusieurs axes de recherche se distinguent :

MemRL (janvier 2026) : cette approche utilise le reinforcement learning pour permettre à l’agent d’apprendre à partir de sa mémoire épisodique en temps réel. L’agent s’auto-améliore en rejouant ses expériences passées, un mécanisme inspiré du replay épisodique en neurosciences.

BEAM (ICLR 2026) : un framework d’évaluation et un système de mémoire qui combine trois composantes complémentaires : un index épisodique sur l’intégralité de la conversation (pour la récupération), une working memory (les derniers tours de conversation), et un scratchpad où le modèle raisonne après chaque tour pour extraire les faits saillants. Cette architecture à trois voies obtient des résultats significativement supérieurs aux approches mono-mémoire.

Workshop MemAgents (ICLR 2026) : un workshop dédié à la mémoire des systèmes agentiques, confirmant l’importance du sujet dans la communauté de recherche. Son postulat : le facteur limitant des agents n’est plus la capacité brute du modèle, mais la mémoire, c’est-à-dire comment les agents encodent, retiennent, récupèrent et consolident l’information.

Papier de position « Episodic Memory is the Missing Piece » : les auteurs argumentent que la mémoire épisodique est la pièce manquante pour les agents LLM à horizon long. Les systèmes actuels (RAG, knowledge graphs) ne couvrent pas toutes les caractéristiques nécessaires, notamment le binding contextuel (lier un souvenir à son contexte temporel, spatial et causal) et la récupération basée sur des indices contextuels.

Limites et défis

Vie privée et surveillance : un agent qui mémorise chaque interaction crée un risque de surveillance. Les systèmes en production doivent intégrer des mécanismes de consentement, de suppression à la demande, et de séparation multi-tenant (les souvenirs du client A ne fuient pas vers le client B). Les frameworks comme Mem0 gèrent cette séparation via des hiérarchies user_id / session_id / agent_id.

Qualité de la récupération : la recherche par similarité vectorielle ne suffit pas toujours. Un terme différent pour le même concept (terminologie mismatch) peut faire rater un épisode pertinent. Les systèmes avancés combinent plusieurs stratégies de retrieval : vectoriel, par mots-clés, par graphe de relations, et par filtrage temporel.

Scalabilité : un agent qui tourne depuis des mois accumule des millions d’épisodes. Sans stratégie de consolidation et de decay, la qualité de récupération se dégrade et les coûts de stockage explosent.

Cohérence : quand un fait épisodique contredit une connaissance sémantique, lequel prime ? Les architectures actuelles n’ont pas de mécanisme standard pour résoudre ces conflits. C’est un problème ouvert.

Benchmarking : évaluer la qualité d’une mémoire épisodique est notoirement difficile. Le benchmark LOCOMO (10 conversations de ~600 tours chacune) est le plus utilisé, mais il a ses limites : il ne teste pas vraiment l’accumulation séquentielle d’expériences sur de longues durées. Les résultats sont souvent contestés entre frameworks concurrents.

Verdict

L’episodic memory est la brique qui transforme un LLM stateless en agent capable d’apprendre de l’expérience. Sans elle, même le modèle le plus puissant oublie tout entre deux sessions. La taxonomie CoALA (episodic / semantic / procedural) reste le cadre de référence, mais les implémentations en production divergent considérablement.

Pour la majorité des cas d’usage, Mem0 est le choix le plus pragmatique : framework-agnostic, rapide à intégrer, latence faible, et la variante graph gère bien le raisonnement temporel. Si vous êtes prêt à adopter un runtime complet et voulez que l’agent gère sa propre mémoire, Letta offre une architecture plus puissante mais plus engageante. Évitez de construire votre propre système de mémoire épisodique from scratch, sauf si vous avez des contraintes très spécifiques que les frameworks existants ne couvrent pas.

Le sujet est loin d’être résolu. L’oubli intelligent, le binding contextuel riche, et la consolidation épisodique → sémantique restent des problèmes ouverts. Mais c’est précisément là que se joue la prochaine étape des agents IA : le passage du chatbot réactif au système qui accumule et exploite l’expérience sur le long terme.