Mémoire vectorielle vs mémoire graphe — comment choisir (2026)
Comparaison pratique des deux architectures mémoire AI dominantes : quand utiliser les embeddings vectoriels, quand dégainer un graphe de connaissances et quand combiner les deux.
Two memory models, one decision
Tout système mémoire AI se ramène à l'une ou aux deux primitives suivantes : la mémoire vectorielle (embarquer le contenu, récupérer par similarité sémantique) et la mémoire graphe (entités connectées par des arêtes typées, récupérées par traversée). Choisir entre les deux est l'une des décisions à plus fort levier dans l'architecture d'Agent.
La mémoire vectorielle gagne sur la vitesse, la simplicité et le flou. Toutes les grandes bibliothèques la supportent (Qdrant, Pinecone, pgvector), elle gère le texte libre nativement, et une récupération sous 100 ms sur des millions de mémoires est routinière. Elle peine sur le raisonnement multi-sauts (« ami d'un ami qui travaille sur X ») et les requêtes temporelles (« à quoi s'intéressait l'utilisateur le trimestre dernier ? »).
La mémoire graphe gagne sur la structure, les relations et l'historique. Des questions comme « qui a collaboré avec qui sur quel projet » sont des traversées de graphe directes. Les graphes temporels style Graphiti ajoutent un historique explicite. Le coût : complexité opérationnelle plus élevée (une graph DB à opérer), qualité d'extraction plus difficile (le LLM doit produire des arêtes bien typées) et requêtes cold-path plus lentes sur les traversées profondes.
La plupart des systèmes de production en 2026 sont hybrides : un vector store pour tout, un graph store pour les 10-20 % de requêtes où les relations comptent. Cette page explique quand choisir quoi — et quand construire les deux.
Decision framework
Ce flowchart est la version courte de la décision. Chaque recommandation de bibliothèque concrète ci-dessus a sa propre page sur TokRepo avec code et compromis de coût — cliquez quand vous avez besoin du détail.
# 1. What kind of questions will your agent answer?
#
# (a) "Find me memories similar to X" → VECTOR
# (b) "Who is connected to whom via what relationship?" → GRAPH
# (c) "What was true about X at time T?" → GRAPH (temporal)
# (d) "Has this topic come up before?" → VECTOR
# (e) Mix of (a)+(b)+(c) → HYBRID
#
# 2. What does your data look like?
#
# Free-form chat, long-form content, docs → VECTOR first
# Structured entity-relationship patterns → GRAPH first
# Conversational with named entities → HYBRID
#
# 3. What is your operational budget?
#
# 1 dev, small app → VECTOR only (simpler ops)
# Team, production workload → HYBRID (graph for the 10% that needs it)
#
# 4. Concrete stack recommendations:
#
# MVP chatbot → mem0 (vector) + Qdrant
# Session chat → Zep (vector + built-in entity graph)
# Long-running → Letta (paged) OR Graphiti (temporal graph)
# Research agent → Graphiti + vector DB side-by-side
#
# 5. Don't optimize prematurely.
# Ship vector memory first. Add graph when you can point at a
# specific query your vector memory fails on. Hybrid is a
# complexity tax — pay it only when it buys accuracy or correctness.Fonctionnalités clés
Vector : similarité sémantique
Récupère par distance dans l'espace d'embedding. Excellent pour « trouve du contenu comme X » même quand le wording diffère. Échoue quand la question porte sur des relations, pas sur la similarité.
Graph : relations typées
Récupère en traversant des arêtes (friend_of, worked_on, lives_in). Excellent pour les questions multi-sauts et les requêtes structurelles. Exige que l'extracteur produise des arêtes propres et typées.
Vector : ops plus simples
Les vector DBs sont un service unique. Les options managées (Pinecone, Qdrant Cloud) se provisionnent en minutes. Le debugging est direct — inspectez embeddings et scores.
Graph : raisonnement temporel
Les arêtes bitemporelles style Graphiti permettent de demander « qu'était-ce vrai et quand ? » — impossible en pur modèle vectoriel. Essentiel dans les domaines régulés (santé, finance, conformité).
Hybride : le défaut en production
La plupart des systèmes réels stockent la mémoire deux fois : une fois dans un index vectoriel pour le rappel sémantique rapide, une fois dans un graphe pour les requêtes structurelles. Les requêtes sont routées par intent.
Asymétrie de coût
La récupération vectorielle coûte des fractions de cent sur des millions de mémoires. La construction graphe coûte plus (extraction LLM par épisode), mais les requêtes graphe peuvent être moins chères qu'un rerank multi-vecteurs sur des charges fortes en relations.
Comparaison
| Semantic recall | Multi-hop relations | Temporal queries | Operational cost | |
|---|---|---|---|---|
| Vector memory | Excellent | Poor | Poor (workarounds exist) | Low |
| Graph memory | Medium (depends on embedding-on-nodes) | Excellent | Excellent (with temporal edges) | Medium-High |
| Hybrid (vector + graph)celui-ci | Excellent | Excellent | Excellent | Medium-High |
Cas d'usage
01. Chatbot consumer (choisir vector)
mem0 ou Zep vous donne 90 % de l'intelligence perçue à coût opérationnel minimal. N'ajoutez pas de graphe avant qu'un utilisateur ne se plaigne d'une question précisément shape-relation.
02. Santé / conformité (choisir graph ou hybride)
Les régulateurs demandent « quel médicament prenait le patient en janvier ? ». Les arêtes graphe bitemporelles (Graphiti) sont la façon standard de répondre. Ajoutez une couche vectorielle pour la récupération de notes en texte libre.
03. Code intelligence ingénierie (hybride)
Vector sur les chunks de code pour « trouve du code similaire » ; graphe sur symboles/imports pour « qu'est-ce qui casse si je renomme ça ? ». Aucun seul n'est suffisant pour des dev tools en production.
Tarification et licence
Stacks vector-only : Qdrant/Chroma self-hosted est gratuit ; les vector DBs managées démarrent autour de 70 $/mois en production. Les coûts d'embeddings LLM scalent avec le volume d'écriture mémoire — typiquement des fractions de cent par mémoire.
Stacks graph : le tier gratuit Neo4j AuraDB couvre les prototypes ; la production démarre autour de 65 $/mois. Les coûts d'extraction LLM sont plus élevés car chaque épisode déclenche une passe d'extraction d'entités/arêtes.
Stacks hybrides : payez les deux lignes infra. Le bénéfice se mesure en précision d'Agent sur le sous-ensemble de requêtes qui bénéficient d'une traversée de graphe. Mesurez avant de vous engager.
Assets associés sur TokRepo
Vector — High-Performance Observability Data Pipeline
Vector collects, transforms, and routes logs, metrics, and traces from any source to any destination. Written in Rust, it handles 100x more throughput than Logstash/Fluentd on the same hardware with a unified config language.
CozoDB — Hybrid Relational-Graph-Vector Database with Datalog
A transactional database that unifies relational, graph, and vector search queries in a single Datalog-based query language.
OpenPencil — AI-Native Vector Design + MCP
Open-source AI-native vector design tool with design-as-code `.op`, concurrent agent teams, and built-in MCP; verified 2777★, pushed 2026-05-14.
Mapbox GL JS — Interactive Vector Tile Maps in the Browser
A JavaScript library for rendering interactive, GPU-accelerated maps using vector tiles and WebGL.
Questions fréquentes
Ai-je vraiment besoin d'une base de graphe pour la mémoire AI ?+
En général non. La mémoire vectorielle couvre la plupart des cas chatbot et personnalisation. Ajoutez un graphe quand vous pouvez pointer du doigt des questions précises sur lesquelles votre Agent échoue parce qu'il ne peut pas traverser de relations — pas parce que les graph databases sont intellectuellement intéressantes.
Puis-je utiliser une graph DB comme unique store mémoire ?+
Oui, mais vous voudrez des fonctionnalités de recherche vectorielle dessus. Neo4j a des index vectoriels natifs ; FalkorDB est bâti sur Redis avec support vectoriel. Pure-graph-sans-vector marche pour des domaines structurés mais souffre sur le rappel de chat en texte libre.
Comment les hybrides vector + graph routent-ils les requêtes ?+
Pattern courant : classifiez l'intent de la requête avec un petit appel LLM, puis routez vers vector pour les questions « trouve du contenu » et vers graph pour les questions « trouve des relations ». Fusionnez les résultats dans un reranker. Zep le fait en interne ; Graphiti + vector DB côte-à-côte permet de le faire explicitement.
Et GraphRAG — c'est vector ou graph ?+
Microsoft GraphRAG c'est les deux. Il construit un graphe à partir de documents (entités + arêtes + détection de communautés), puis interroge des résumés hiérarchiques à plusieurs niveaux. C'est plus une architecture de récupération qu'un système mémoire — idéal pour de grandes bases de connaissances statiques, pas pour la mémoire conversationnelle.
Lequel est le plus « future-proof » ?+
Aucun — ils sont complémentaires, pas concurrents. La tendance recherche est vers une mémoire structurée apprise qui combine les deux (pensez « neural graph stores »). Pour 2026, construisez en hybride si vous avez besoin de la puissance ; construisez en vector-only sinon. Dans tous les cas, gardez votre couche mémoire suffisamment abstraite pour échanger les implémentations.