Accueil › Glossaire › Semantic Memory

Semantic Memory (Mémoire Sémantique)

La semantic memory (mémoire sémantique) est un type de mémoire à long terme qui stocke les faits, concepts, relations entre entités et connaissances générales dont dispose un agent IA, indépendamment de toute expérience spécifique ou contexte temporel.

Qu’est-ce que la semantic memory en IA ?

Le concept de mémoire sémantique vient de la psychologie cognitive. En 1972, Endel Tulving l’a définie comme un « thésaurus mental » : l’ensemble des connaissances organisées qu’un individu possède sur les mots, les symboles, leurs significations, les relations entre eux, et les règles pour les manipuler. C’est ce qui vous permet de savoir que Paris est la capitale de la France, que les baleines bleues sont des mammifères, ou que la gravité attire les objets vers le sol, sans avoir besoin de vous rappeler quand ni comment vous avez appris ces faits.

La différence fondamentale avec l’episodic memory tient à l’ancrage contextuel : la mémoire épisodique est toujours liée à un moment, un lieu, une situation (« je me souviens avoir visité Paris en juillet 2019 »), tandis que la mémoire sémantique est décontextualisée (« Paris est en France »). Les deux forment ensemble la mémoire déclarative (ou explicite), par opposition à la mémoire procédurale (implicite, le savoir-faire).

Transposée aux agents IA, la semantic memory représente la base de connaissances factuelle de l’agent : les profils clients, les spécifications produits, les règles métier, les relations entre entités, le vocabulaire du domaine. C’est la couche qui permet à l’agent de répondre à « Quels sont les effets secondaires de ce médicament ? » ou « Quel client a un contrat actif avec le fournisseur X ? » sans avoir besoin de fouiller dans des historiques de conversation.

Place dans la taxonomie CoALA

Le framework CoALA (Cognitive Architectures for Language Agents), proposé par Sumers, Yao, Narasimhan et Griffiths, organise la mémoire d’un agent IA en quatre modules, inspirés de l’architecture cognitive SOAR :

Dans la boucle décisionnelle CoALA, l’agent utilise la semantic memory principalement lors du retrieval : il interroge sa base de connaissances pour récupérer les faits pertinents à la tâche en cours, puis intègre ces faits dans sa working memory pour raisonner. L’agent peut aussi écrire en semantic memory (learning) quand il acquiert de nouvelles connaissances factuelles.

Point important : les poids du LLM lui-même constituent une forme de mémoire sémantique implicite (les faits encodés durant l’entraînement). Mais cette mémoire est figée après le training, non modifiable à l’exécution, et sujette aux hallucinations. La semantic memory externe (knowledge graphs, bases vectorielles) complète et corrige cette mémoire implicite avec des données actualisées et vérifiables.

Semantic memory vs episodic memory : la distinction en pratique

La confusion entre ces deux types de mémoire est la plus fréquente. Voici comment les distinguer clairement dans le contexte d’un agent IA :

En production, les deux types de mémoire se complètent systématiquement. La semantic memory fournit le socle de connaissances stable (ce que l’agent sait), l’episodic memory enrichit ce socle avec l’expérience accumulée (ce que l’agent a vécu). Un agent juridique performant combine sa connaissance du droit (sémantique) avec le souvenir des dossiers traités (épisodique) pour formuler des avis contextualisés.

Comment stocker la semantic memory : les architectures

Knowledge graphs : le stockage structuré

Les knowledge graphs sont le support naturel de la semantic memory. Ils encodent les entités (nœuds) et leurs relations (arêtes) dans un réseau sémantique interrogeable. Le fait « Elon Musk a fondé SpaceX » devient deux nœuds (Personne: Elon Musk, Entreprise: SpaceX) reliés par une arête « a_fondé ».

L’avantage majeur des knowledge graphs sur les vector databases pour la mémoire sémantique : le raisonnement multi-hop. Quand l’agent doit répondre à « Quels produits a évalués ce client parmi ceux liés à ses achats précédents ? », un knowledge graph traverse les relations pour trouver la réponse. Une simple recherche vectorielle par similarité risque de manquer la connexion.

Les technologies courantes : Neo4j (le plus mature, requêtes en Cypher), Amazon Neptune (cloud-native AWS), Kuzu (embedded, utilisé par défaut dans Cognee), FalkorDB et Memgraph (alternatives performantes). L’approche Graph-RAG combine un knowledge graph (pour identifier le contexte structuré) avec une recherche vectorielle (pour retrouver les détails textuels), offrant le meilleur des deux mondes.

Vector databases : la recherche par similarité

Les vector databases (Pinecone, Weaviate, Chroma, Qdrant, pgvector) stockent les connaissances sous forme d’embeddings vectoriels et permettent une recherche par similarité sémantique. Vous n’avez pas besoin de formuler une requête exacte : « achats du client Acme » retrouvera des résultats sur « commandes de la société Acme Corp ».

Les vector databases sont souvent la première brique de semantic memory déployée en production, parce qu’elles sont simples à mettre en place et suffisantes pour de nombreux cas d’usage. Leur limite : elles ne modélisent pas les relations entre entités. Si vous avez besoin de traverser des connexions (« le manager de l’équipe qui a traité le ticket X »), vous avez besoin d’un knowledge graph.

Bases relationnelles : la vérité terrain

Pour les faits structurés et critiques (données financières, profils client, inventaires), les bases relationnelles classiques (PostgreSQL, MySQL) restent pertinentes. Elles offrent des garanties ACID, des requêtes exactes, et une auditabilité totale. Mem0 utilise Postgres pour stocker ses mémoires à long terme structurées, tandis que les embeddings passent par une couche vectorielle séparée.

L’architecture hybride : le standard en production

En pratique, les systèmes de semantic memory en production combinent plusieurs couches de stockage :

Le package neo4j-agent-memory, publié par Neo4j Labs, illustre cette convergence : il combine vector search et graph traversal dans une seule base, avec trois types de mémoire (short-term, long-term, reasoning). L’extraction d’entités est multi-étapes (spaCy, GLiNER, LLM), et la résolution d’entités gère la déduplication par matching exact, fuzzy et sémantique.

Les frameworks de semantic memory en production

Cognee : le moteur de connaissance open source

Cognee est un moteur de mémoire open source qui construit automatiquement un knowledge graph à partir de données non structurées. Vous injectez des documents, et Cognee extrait les entités, les relations et les embeddings sémantiques. Le résultat est interrogeable par recherche vectorielle et par traversée de graphe simultanément.

L’architecture de Cognee est notable par sa flexibilité de stockage. Par défaut, tout tourne en local avec SQLite (relationnel), LanceDB (vecteurs) et Kuzu (graphe), sans infrastructure à configurer. En production, vous pouvez basculer sur Neo4j, Qdrant, pgvector ou Amazon Neptune selon vos besoins. Cognee est utilisé par plus de 70 entreprises et traite plus d’un million de pipelines par mois. Le projet a levé 7,5 millions de dollars en seed, avec le soutien d’investisseurs liés à Google DeepMind et OpenAI.

Cognee expose ses fonctionnalités via le Model Context Protocol (MCP), ce qui permet à des agents Claude, GPT ou Llama d’interagir avec le même knowledge graph via un protocole standardisé.

import cognee
import asyncio

async def main():
    # Injecter des données
    await cognee.add("Le client Acme Corp a un contrat Premium "
                     "valide jusqu'en mars 2027, "
                     "d'une valeur de 1,8M euros.")

    # Construire le knowledge graph
    await cognee.cognify()

    # Interroger la mémoire sémantique
    results = await cognee.search("Quel contrat a Acme Corp ?")
    for result in results:
        print(result)

asyncio.run(main())

Mem0 : extraction automatique de faits

Mem0 excelle dans l’extraction automatique de faits à partir de conversations. Quand vous lui soumettez un échange, son pipeline d’extraction identifie les informations factuelles et les stocke comme mémoires sémantiques. Si l’utilisateur dit « J’ai déménagé de Lyon à Bordeaux », Mem0 supprime l’ancien fait (ville: Lyon) et ajoute le nouveau (ville: Bordeaux). Cette gestion des mises à jour (ADD, UPDATE, DELETE, NOOP) distingue Mem0 d’un simple RAG statique.

La variante Mem0g enrichit cette approche avec des graphes orientés étiquetés : les entités deviennent des nœuds et les relations des arêtes. Cette couche graph est particulièrement utile pour les requêtes temporelles et relationnelles que la recherche vectorielle seule ne peut pas résoudre.

Zep et Neo4j Agent Memory

Zep construit un knowledge graph temporel à partir des conversations : il extrait les entités, les intentions et les faits, puis suit leur évolution dans le temps. L’avantage par rapport à un graph statique est la dimension temporelle native : Zep sait quand un fait a commencé à être vrai et quand il a cessé de l’être.

Le package neo4j-agent-memory de Neo4j Labs adopte un modèle de données POLE+O (Person, Object, Location, Event, Organization) configurable, avec extraction d’entités multi-étapes et résolution par déduplication. Il s’intègre nativement avec LangChain, Pydantic AI, LlamaIndex, CrewAI et OpenAI Agents SDK.

Comparatif des approches

Semantic memory vs RAG : clarifier la confusion

Le RAG (Retrieval-Augmented Generation) et la semantic memory partagent des technologies (vector databases, embeddings), mais leur rôle diffère :

Le RAG est une technique ponctuelle : récupérer des documents externes pertinents pour enrichir le contexte d’une requête spécifique. Le corpus est généralement statique (documentation, base de connaissances pré-indexée). Le RAG ne « se souvient » de rien entre deux requêtes.

La semantic memory est un état persistant : elle stocke les connaissances que l’agent a accumulées, les met à jour quand de nouveaux faits arrivent, supprime les informations obsolètes, et maintient une cohérence globale. C’est la différence entre consulter une encyclopédie (RAG) et construire progressivement son propre savoir (semantic memory).

En pratique, la semantic memory utilise souvent des mécanismes de RAG pour la récupération, mais elle ajoute les dimensions cruciales que le RAG seul n’offre pas : la mise à jour dynamique, la résolution de conflits entre faits, la consolidation depuis les épisodes, et la persistance inter-sessions.

Semantic memory vs poids du LLM

Un LLM comme GPT-5.4 ou Claude Opus 4.6 contient déjà une immense quantité de connaissances factuelles encodées dans ses poids. C’est une forme de mémoire sémantique implicite. Pourquoi alors ajouter une couche externe ?

Actualité : les poids du modèle sont figés après l’entraînement. Ils ne connaissent pas les événements survenus après leur date de cutoff. La semantic memory externe contient les données les plus récentes.

Spécificité domaine : le LLM connaît des faits généraux, mais pas vos données internes : profils clients, contrats en cours, règles métier spécifiques. La semantic memory externe stocke ces connaissances propriétaires.

Vérifiabilité : quand le LLM génère un fait depuis ses poids, il n’y a aucune garantie de fiabilité (risque d’hallucination). Quand l’agent récupère un fait depuis sa semantic memory externe, la source est traçable et auditable.

Modifiabilité : vous ne pouvez pas corriger un fait dans les poids du LLM sans ré-entraînement. La semantic memory externe est modifiable en temps réel.

Implémentation technique : construire une semantic memory

Architecture type

Voici l’architecture standard d’une semantic memory en production, indépendamment du framework utilisé :

Données entrantes (documents, conversations, APIs)
        │
        ▼
┌─────────────────────────────┐
│   Pipeline d'extraction     │
│  (NER, relation extraction, │
│   entity resolution, LLM)   │
└─────────────────────────────┘
        │
        ▼
┌─────────────────────────────────────────────┐
│              Stockage hybride                │
│                                             │
│  ┌──────────┐  ┌───────────┐  ┌──────────┐ │
│  │ Knowledge │  │  Vector   │  │   Base   │ │
│  │   Graph   │  │   Store   │  │ relation.│ │
│  │ (Neo4j)   │  │ (Qdrant)  │  │ (Postgres)│ │
│  └──────────┘  └───────────┘  └──────────┘ │
└─────────────────────────────────────────────┘
        │
        ▼
┌─────────────────────────────┐
│    Retrieval multi-stratégie │
│  (graph traversal + vector  │
│   search + keyword + filtre) │
└─────────────────────────────┘
        │
        ▼
    Contexte injecté dans le LLM

Exemple : semantic memory avec knowledge graph

Voici un exemple simplifié d’une semantic memory basée sur un knowledge graph. Le pattern illustre l’extraction d’entités, le stockage relationnel, et la requête structurée :

from dataclasses import dataclass

@dataclass
class Entity:
    id: str
    type: str        # "Person", "Company", "Product", etc.
    name: str
    properties: dict # attributs libres

@dataclass
class Relation:
    source_id: str
    target_id: str
    type: str        # "employe_de", "client_de", "fournit", etc.
    properties: dict

class SemanticMemory:
    def __init__(self, graph_db, vector_store, llm):
        self.graph = graph_db
        self.vectors = vector_store
        self.llm = llm

    def ingest(self, text: str):
        """Extrait entités et relations, puis stocke."""
        # 1. Extraction via LLM
        extraction = self.llm.extract_entities_and_relations(text)

        for entity in extraction.entities:
            # Résolution : l'entité existe-t-elle déjà ?
            existing = self.graph.find_similar(entity.name, entity.type)
            if existing:
                self.graph.merge(existing.id, entity)
            else:
                self.graph.create(entity)
                # Embedding pour la recherche sémantique
                embedding = self.vectors.embed(
                    f"{entity.type}: {entity.name} - "
                    f"{entity.properties}"
                )
                self.vectors.upsert(entity.id, embedding)

        for relation in extraction.relations:
            self.graph.create_relation(relation)

    def query_structured(self, cypher: str) -> list:
        """Requête structurée sur le knowledge graph."""
        return self.graph.execute(cypher)

    def query_semantic(self, question: str, top_k: int = 5) -> list:
        """Recherche par similarité vectorielle."""
        q_embedding = self.vectors.embed(question)
        return self.vectors.search(q_embedding, top_k=top_k)

    def query_hybrid(self, question: str) -> str:
        """Combine graph + vector pour une réponse complète."""
        # Identifier les entités mentionnées
        entities = self.llm.extract_entities(question)

        # Graph traversal pour le contexte relationnel
        graph_context = []
        for e in entities:
            neighbors = self.graph.get_neighbors(e.name, depth=2)
            graph_context.extend(neighbors)

        # Vector search pour les détails textuels
        vector_results = self.query_semantic(question)

        # Synthèse par le LLM
        return self.llm.synthesize(question, graph_context, vector_results)

La méthode query_hybrid illustre le pattern Graph-RAG : le knowledge graph identifie le contexte structurel (entités voisines à 2 niveaux de profondeur), la recherche vectorielle retrouve les détails textuels, et le LLM synthétise l’ensemble.

Cas d’usage concrets

Support client B2B

L’agent stocke en semantic memory les profils clients (secteur, contrat, stack technique, contacts clés), les produits et leurs dépendances, les règles de SLA par tier. Quand un ticket arrive, l’agent récupère instantanément le contexte du client sans que l’utilisateur ait besoin de se réidentifier ou de répéter son historique. La traversée du knowledge graph permet de connecter un problème technique à un changement récent chez un fournisseur en amont.

Assistant juridique

La semantic memory stocke le droit applicable (articles, jurisprudences, commentaires doctrinaux) et les relations entre textes (un décret qui applique une loi, un arrêt qui interprète un article). L’agent peut répondre à « Quelles exceptions au droit de rétractation s’appliquent aux contrats numériques ? » en traversant le graphe de relations juridiques, pas seulement en cherchant des mots-clés similaires.

Analyse financière

L’agent maintient un knowledge graph des entreprises, leurs filiales, dirigeants, secteurs d’activité, et métriques financières. Quand l’utilisateur demande « Quelles entreprises du portefeuille ont un lien avec le secteur des semi-conducteurs via leurs fournisseurs ? », la réponse exige une traversée relationnelle que la recherche vectorielle seule ne peut pas fournir.

Mémoire partagée multi-agent

Dans les systèmes multi-agents, la semantic memory sert de base de connaissances partagée. Chaque agent spécialisé (recherche, rédaction, validation) lit et écrit dans le même knowledge graph. L’agent de recherche enrichit la base avec de nouveaux faits, l’agent de rédaction les consomme pour produire du contenu, l’agent de validation vérifie la cohérence. Cognee gère cette isolation par tenant avec des sessions séparées au sein du même graphe.

Défis et limites

Extraction de qualité : la fiabilité de la semantic memory dépend entièrement de la qualité de l’extraction d’entités et de relations. Les LLM sont bons pour cette tâche, mais pas parfaits. Des erreurs d’extraction (entité mal identifiée, relation inventée) polluent le knowledge graph et dégradent les réponses en aval. Les pipelines multi-étapes (NER statistique + LLM) réduisent ce risque.

Scalabilité du knowledge graph : les traversées profondes dans un graph dense deviennent coûteuses. Les requêtes à 4 ou 5 niveaux de profondeur sur un graph de millions de nœuds peuvent prendre des secondes. Les architectures hybrides (graph pour la structure + vecteurs pour la similarité) atténuent ce problème.

Résolution d’entités : « Acme Corp », « Acme Corporation », « ACME » : est-ce la même entité ? La déduplication est un problème classique, amplifié par le volume et la variété des sources. Les systèmes avancés combinent matching exact, fuzzy (distance de Levenshtein), et sémantique (similarité d’embeddings).

Cohérence temporelle : quand un fait change (le CEO d’une entreprise est remplacé), il faut mettre à jour le knowledge graph et gérer la validité temporelle. Le pattern « ancien fait invalidé, nouveau fait activé » est simple en théorie mais complexe à orchestrer en production, surtout avec plusieurs sources de vérité.

Oubli intelligent : comme pour l’episodic memory, déterminer quelles connaissances sémantiques sont devenues obsolètes et peuvent être supprimées reste un problème ouvert. Les approches courantes incluent le TTL (time-to-live) et le scoring par fréquence d’accès.

Verdict

La semantic memory est la colonne vertébrale de tout agent IA qui doit raisonner sur des connaissances factuelles. Sans elle, l’agent est limité aux faits figés dans les poids du LLM et aux documents récupérés ponctuellement par RAG, sans cohérence, sans mise à jour, et sans modélisation des relations.

Pour la majorité des projets, commencez par Cognee si vous voulez un knowledge graph automatiquement construit à partir de vos données, avec une architecture flexible et un bon support MCP. Utilisez Mem0 si votre priorité est l’extraction automatique de faits depuis les conversations avec gestion des mises à jour. Optez pour neo4j-agent-memory si vous êtes déjà dans l’écosystème Neo4j et voulez un contrôle fin sur le modèle de données.

Le knowledge graph est le différenciateur : les agents qui ne stockent leur mémoire sémantique que dans des vector databases finissent par atteindre un plafond quand les requêtes exigent du raisonnement relationnel. Investissez dans un graph tôt : le coût de migration après coup est bien plus élevé que celui de l’intégration initiale.