Base vectorielle ou base graphe : laquelle pour votre RAG ?

Que stocke une base vectorielle, et que stocke une base graphe ?

Une base vectorielle stocke des passages de texte transformés en vecteurs numériques ; une base graphe stocke des entités (un client, un contrat, un produit) reliées par des relations nommées (« a signé », « dépend de », « exerce à »). La première répond à « qu'est-ce qui ressemble à ceci ? », la seconde à « qu'est-ce qui est relié à cela, et comment ? ».

La base vectorielle

Un modèle d'embedding (représentation vectorielle du texte) convertit chaque passage de document en une liste de nombres. Deux passages qui parlent de la même chose obtiennent des vecteurs proches, même avec des mots différents. À chaque question, la base renvoie les passages les plus proches en quelques millisecondes. Qdrant, Milvus et pgvector sont les options que je déploie le plus souvent ; la page Qdrant et bases vectorielles les compare en détail.

La base graphe

Une base graphe enregistre des nœuds (les entités) et des arêtes (les relations), avec leurs propriétés : date, montant, statut. On l'interroge en Cypher (dans Neo4j) pour suivre des chemins : d'un client vers ses contrats, puis vers leurs fournisseurs. Le graphe ignore le sens d'une phrase ; il connaît des faits explicites et leurs liens.

Dans un système de recherche augmentée par génération (RAG), les deux bases jouent le même rôle : retrouver ce que le modèle lira avant de répondre. Le guide du RAG expliqué décrit la chaîne complète.

La base vectorielle excelle sur les questions formulées librement

Une base vectorielle répond bien dès que la réponse tient dans un ou quelques passages et que l'utilisateur la formule à sa façon. « Que faire après un accrochage avec une voiture de service ? » retrouve la note intitulée « Sinistre impliquant un véhicule de la flotte », sans mot commun entre les deux.

• Tolérance à la formulation : synonymes, fautes de frappe, vocabulaire métier approximatif.
• Ingestion directe : PDF, pages intranet, tickets, e-mails, sans modélisation préalable.
• Filtres par métadonnées : date, service, droits d'accès, appliqués pendant la recherche.
• Recherche hybride : vecteurs et mots-clés exacts combinés, pour les références et les noms propres.

Ses limites apparaissent quand la réponse est dispersée. « Combien de contrats signés avec des fournisseurs allemands expirent cette année ? » demande de trouver tous les contrats concernés, de les filtrer et de les compter. La recherche renvoie les dix passages les plus proches, le modèle compte ce qu'il voit, et la réponse devient fausse dès qu'un onzième contrat existe.

Quatre familles de questions où le graphe prend l'avantage

Le graphe gagne sur les questions dont la réponse se calcule à partir de relations explicites. J'en distingue quatre familles.

1. Les questions à plusieurs sauts (multi-hop) : « Quels projets dépendent d'un composant fourni par un sous-traitant en difficulté ? »
2. Les agrégations : compter, additionner, classer. « Quel commercial suit le plus de comptes dans la santé ? »
3. Les critères exacts combinés : une spécialité, un acte, une zone et une disponibilité, tous obligatoires. La similarité sémantique rapproche ; elle ne vérifie pas chaque critère.
4. L'explication du chemin : montrer pourquoi deux éléments sont liés, utile en conformité ou en analyse de risques fournisseurs.

Condition d'entrée : des entités et des relations. Si vos données sont déjà structurées (base clients, catalogue, annuaire), le graphe s'en nourrit de façon fiable. Si elles n'existent que dans du texte libre, il faut les extraire avec un modèle de langage, avec un coût et un taux d'erreur à mesurer.

Grille de décision par type de question

Le bon choix se déduit des questions réelles de vos utilisateurs. Voici ce que je recommande pour chaque type.

Une application réelle mélange plusieurs types : c'est la proportion de chacun qui décide de l'architecture.

GraphRAG : combiner graphe et vecteurs, comme sur Medicum

Le GraphRAG (RAG sur graphe de connaissances, ou knowledge graph RAG) associe recherche sémantique et parcours de graphe dans la même étape de recherche. C'est l'architecture que j'ai construite pour Medicum, moteur de recherche de praticiens sur GraphRAG.

Le cas Medicum

Medicum, mon produit MedTech, répond à des demandes du type « un dermatologue qui pratique tel acte, près de chez moi, bien noté, disponible rapidement ». Son graphe relie 450 000 praticiens à leurs spécialités, leurs actes, leurs lieux d'exercice, leurs avis et leurs disponibilités. La recherche sémantique interprète la formulation libre ; le parcours du graphe vérifie que chaque praticien renvoyé satisfait chaque critère.

Le graphe extrait du texte

L'autre famille construit le graphe à partir de documents non structurés. Le projet GraphRAG de Microsoft fait extraire par un modèle de langage les entités et les relations de chaque passage, regroupe le graphe en communautés (algorithme de Leiden) et rédige un résumé par communauté, ce qui permet de répondre à des questions de synthèse sur tout le corpus. Microsoft prévient que l'indexation peut coûter cher, et le dépôt indique que le projet est désormais largement en mode maintenance. LlamaIndex propose de son côté un index de graphe de propriétés (PropertyGraphIndex), qui extrait un graphe des documents et l'interroge par vecteurs ou par requêtes Cypher.

Mon avis de praticien : l'extraction automatique produit des graphes bruités (entités en double, relations mal nommées). Elle se justifie quand les questions de synthèse ou de relations dominent.

Ce que coûte un graphe, de la modélisation à la mise à jour

Une base vectorielle coûte peu à mettre en place ; un graphe demande un travail de conception et d'entretien des données sur toute la durée de vie du système. Les logiciels existent en version gratuite des deux côtés ; le budget part dans le travail autour.

Exemple illustratif : 20 000 documents découpés en 15 passages en moyenne représentent 300 000 appels au modèle pour construire le graphe (20 000 × 15), puis de nouveaux appels à chaque mise à jour. Multipliez par le coût unitaire du modèle choisi, et comparez avec le budget d'un RAG classique détaillé sur la page prix d'un assistant documentaire RAG.

Une option réduit la complexité : Neo4j gère des index vectoriels depuis sa version 5.13, en édition Community comme Enterprise, selon sa documentation officielle. Un seul moteur porte alors graphe et vecteurs. PostgreSQL avec pgvector et Apache AGE garde tout dans la base que votre équipe connaît déjà.

Sur 2,7 millions de délibérations, des vecteurs bien réglés ont suffi

Un RAG vectoriel bien réglé couvre la plupart des besoins documentaires, et deux systèmes que j'ai livrés l'illustrent. Chez Delibia, govtech au service des collectivités, l'assistant porte sur 2,7 millions de délibérations. Mesuré sur un jeu de questions réelles d'agents municipaux, le retrieval (recherche des passages pertinents) Top@10 est passé de 53 % à 93 %, les réponses jugées satisfaisantes de 26 % à 98 % et la latence de 15 s à 4,3 s. Le travail a porté sur l'indexation, la recherche, les consignes et le routage des questions, puis sur un modèle d'embedding entraîné sur leur corpus, 4 fois plus léger que bge-m3 pour 95 % de top-100. Aucun graphe.

Chez Virteem, aucun document ne devait passer par une API de modèle externe. Le socle repose sur vLLM pour servir un modèle ouvert et sur Milvus comme base vectorielle, avec zéro API externe (voir la réalisation Virteem, RAG auto-hébergé avec vLLM et Milvus).

La leçon : mesurez d'abord ce qu'un RAG vectoriel donne sur vos questions. Si les échecs restants sont relationnels, le graphe a sa place. S'ils viennent de passages mal découpés ou d'un modèle d'embedding inadapté au français, le graphe n'y changera rien.

Classez 50 questions réelles avant de choisir

La décision se prend sur un échantillon de questions réelles, en une demi-journée. Voici la méthode que j'applique en cadrage.

1. Collectez 50 questions que vos utilisateurs posent, avec l'endroit où se trouve la réponse.
2. Étiquetez chacune selon la grille plus haut.
3. Vérifiez vos données : les entités et relations utiles existent-elles déjà dans une base (CRM, ERP, catalogue), ou seulement dans des textes ?
4. Appliquez mon repère : moins d'une question relationnelle sur cinq, partez sur une base vectorielle avec recherche hybride et métadonnées. Plus d'une sur trois, avec des entités déjà structurées, prévoyez un graphe dès la conception. Entre les deux, démarrez en vectoriel et traitez les questions relationnelles par une requête sur vos bases existantes.
5. Mesurez la première version sur ces 50 questions avant d'ajouter une brique.

Pour un assistant documentaire classique, la méthode aboutit souvent à une base vectorielle bien réglée, avec le déroulé d'un assistant IA documentaire sur mesure. Si l'on vous propose de réentraîner un modèle, le comparatif RAG ou fine-tuning complète la décision. Et si vous hésitez entre un freelance IA et une agence IA pour ce cadrage, la grille sert de test : demandez à chacun comment il classerait vos 50 questions.