GraphRAG vs RAG vectoriel : quand le graphe de connaissances change la donne

Le RAG vectoriel a un angle mort : il récupère des passages isolés, sans comprendre comment ils se relient entre eux. Tant que vos questions portent sur des faits localisés (« que dit la clause X ? »), ça suffit largement. Mais dès qu'une question exige de connecter des informations dispersées (« qui a travaillé sur les projets impliquant à la fois l'équipe A et le fournisseur B ? »), la similarité vectorielle patine. C'est là que le GraphRAG entre en jeu.

Voici la différence concrète entre les deux approches, et comment décider laquelle votre cas appelle.

Comment fonctionne le RAG vectoriel (et ce qu'il rate)

Le RAG vectoriel découpe vos documents en passages, les transforme en vecteurs, et récupère les plus proches d'une requête. C'est rapide, robuste, et parfait pour les questions dont la réponse tient dans un ou quelques passages.

Sa limite : il traite chaque passage comme une île. Il ne sait pas que le passage A et le passage D parlent de la même personne, que cette entité apparaît dans dix documents, ou que deux faits se complètent. Il récupère par ressemblance, pas par relation.

Prenons un exemple. Vous avez indexé 800 comptes rendus de réunion. Question : « Quels fournisseurs ont été mentionnés dans des réunions où le sujet de la conformité RGPD a aussi été abordé ? » Le RAG vectoriel va chercher les passages les plus proches de cette phrase. Il remontera peut-être quelques chunks qui parlent à la fois de fournisseurs et de RGPD dans le même paragraphe — mais il ratera systématiquement les cas où le fournisseur est cité dans la réunion du 3 mars et la discussion RGPD dans le compte rendu de la réunion du 12 mai, alors que c'est la même série de réunions. La connexion existe dans vos données ; le vecteur ne la voit pas, parce qu'elle n'est inscrite dans aucun passage unique.

Le RAG vectoriel répond bien aux questions « locales » (la réponse est dans le texte). Il échoue sur les questions « globales » qui exigent de relier des bouts d'information éparpillés.

Comment fonctionne le GraphRAG

Le GraphRAG (popularisé notamment par les travaux de Microsoft, dont l'implémentation open source du même nom) ajoute une couche de structure. Au lieu de ne stocker que des vecteurs, il construit un graphe de connaissances en quatre étapes :

1. Extraction d'entités et de relations — un LLM parcourt le corpus chunk par chunk et en extrait les entités (personnes, projets, produits, organisations) et les liens qui les unissent, sous une forme structurée (souvent des triplets sujet — relation — objet).
2. Construction du graphe — ces entités deviennent des nœuds, les relations des arêtes. Les entités identiques mentionnées dans plusieurs documents sont fusionnées (résolution d'entités). L'information éparpillée se relie en un seul réseau.
3. Détection de communautés — un algorithme de clustering de graphe (typiquement Leiden) regroupe les nœuds densément connectés en communautés thématiques, à plusieurs niveaux hiérarchiques. Chaque communauté est ensuite résumée par le LLM.
4. Récupération sur le graphe — pour répondre, on ne parcourt plus des passages isolés mais des sous-graphes et des résumés de communautés. Microsoft distingue deux modes : la global search (interroge les résumés de communautés pour les questions de vue d'ensemble) et la local search (part d'une entité et explore son voisinage pour les questions ciblées sur une entité).

Un mini-exemple concret

Imaginons trois chunks issus de vos comptes rendus :

Chunk 1 : « Marie Lefort (DSI) a validé le contrat avec Acme Cloud
            pour l'hébergement souverain. »
Chunk 2 : « Acme Cloud opère ses datacenters à Roubaix et Strasbourg. »
Chunk 3 : « Lors du comité du 12 mai, Marie Lefort a alerté sur les
            obligations RGPD liées au transfert de données. »

L'étape d'extraction produit des triplets de ce type :

(Marie Lefort) --[a_validé]--> (Contrat Acme Cloud)
(Marie Lefort) --[occupe_le_rôle]--> (DSI)
(Contrat Acme Cloud) --[concerne]--> (Acme Cloud)
(Acme Cloud) --[héberge_à]--> (Roubaix)
(Acme Cloud) --[héberge_à]--> (Strasbourg)
(Marie Lefort) --[a_soulevé]--> (Obligation RGPD)

Le sous-graphe obtenu relie désormais Acme Cloud, RGPD et Marie Lefort alors qu'aucun chunk unique ne contient les trois ensemble. À la question « Le fournisseur d'hébergement validé par la DSI pose-t-il des enjeux RGPD ? », une local search partant du nœud Acme Cloud traverse l'arête vers Marie Lefort, puis vers Obligation RGPD, et reconstruit une réponse que le vectoriel n'aurait jamais assemblée. C'est exactement la requête relationnelle où le vectoriel échoue : la réponse n'est dans aucun passage, elle est dans la structure.

Résultat : le GraphRAG excelle là où le vectoriel cale — les questions de synthèse globale, de connexion d'entités, de « vue d'ensemble » sur un corpus.

Le tableau des forces et faiblesses

Critère	RAG vectoriel	GraphRAG
Questions factuelles locales	Excellent	Surdimensionné
Questions de connexion / synthèse globale	Faible	Excellent
Coût d'ingestion	Faible	Élevé (extraction LLM du graphe)
Latence de requête	Faible	Variable, souvent plus élevée
Maintenance / mise à jour	Simple	Complexe (le graphe doit évoluer)
Maturité / outillage	Très mûr	En progression

Le GraphRAG n'est pas « un meilleur RAG ». C'est un outil pour un autre type de questions, au prix d'un coût d'ingestion et d'une complexité nettement supérieurs.

Le vrai coût : l'ingestion

C'est le point que la plupart des équipes sous-estiment. Le RAG vectoriel, à l'ingestion, c'est un appel d'embedding par chunk — quelques centièmes de centime, et c'est terminé. Le GraphRAG, lui, fait passer chaque chunk par un LLM génératif pour en extraire entités et relations, puis un ou plusieurs appels supplémentaires pour résumer chaque communauté.

Posons des ordres de grandeur prudents pour fixer les idées. Un corpus de 10 000 chunks d'environ 600 tokens chacun :

• Vectoriel : 10 000 appels d'embedding. Avec text-embedding-3-small, le coût total se chiffre en dizaines de centimes.
• GraphRAG : 10 000 appels d'extraction sur un modèle génératif, chacun consommant l'entrée (le chunk + un prompt d'extraction parfois long) et produisant une sortie structurée. Selon le modèle, comptez de l'ordre de quelques dizaines à quelques centaines d'euros pour ce seul corpus, avant même la phase de résumé de communautés et les éventuelles passes de raffinement. Microsoft documente d'ailleurs des stratégies de réduction (extraction en plusieurs « gleanings », modèles moins chers pour certaines étapes) précisément parce que la facture grimpe vite.

L'écart de coût d'ingestion entre vectoriel et GraphRAG peut atteindre deux à trois ordres de grandeur. Sur un corpus vivant qu'il faut ré-ingérer régulièrement, ce n'est pas une dépense ponctuelle : c'est une ligne de coût récurrente.

Ajoutez à cela le temps : extraire un graphe sur un gros corpus se compte en heures, voire en jours, là où la vectorisation est massivement parallélisable et quasi instantanée à l'échelle.

Quand le graphe change la donne

Le GraphRAG apporte une vraie valeur quand :

• vos questions sont relationnelles : « comment X est-il lié à Y à travers le corpus ? » ;
• vous avez besoin d'une vue d'ensemble : « quels sont les grands thèmes / risques récurrents dans ces 500 rapports ? » ;
• votre domaine est riche en entités interconnectées : dossiers clients, réseaux d'acteurs, dépendances techniques, généalogies de décisions.

À l'inverse, si vos utilisateurs posent surtout des questions factuelles ponctuelles, le coût du graphe ne se justifie pas.

L'approche pragmatique : commencer vectoriel, ajouter le graphe si besoin

La plupart des projets devraient commencer en RAG vectoriel (hybride + reranking), qui couvre la majorité des besoins à faible coût. On n'introduit le GraphRAG que lorsque la mesure révèle une classe de questions — relationnelles, globales — que le vectoriel échoue systématiquement à traiter.

Une voie intermédiaire séduisante consiste à combiner les deux : le vectoriel pour les questions locales, un graphe pour enrichir le contexte sur les entités clés. On capte les relations sans payer le coût d'un graphe exhaustif sur tout le corpus.

Question ─► classifieur
              ├─ locale / factuelle ──► RAG vectoriel (hybride + rerank)
              └─ relationnelle / globale ──► GraphRAG (sous-graphes, communautés)

Comment fonctionne le classifieur de questions

Le maillon central de cette architecture hybride, c'est le routeur placé en amont. Plusieurs implémentations sont possibles, du plus simple au plus robuste :

• Heuristiques — détecter des marqueurs lexicaux (« compare », « relie », « quels sont tous les… », « vue d'ensemble », « combien de… au total ») qui trahissent une intention globale ou relationnelle. Rapide et gratuit, mais fragile.
• Classifieur LLM léger — un petit modèle (ou un appel court sur un modèle économique) reçoit la question et renvoie un label locale / relationnelle avec une confiance. C'est l'approche la plus courante en 2026 : un prompt de quelques lignes, une sortie contrainte, une latence de l'ordre de la centaine de millisecondes.
• Routage agentique — un agent décide lui-même s'il interroge l'index vectoriel, le graphe, ou les deux, et peut enchaîner les appels. Plus puissant, plus coûteux, plus difficile à rendre déterministe.

En pratique, on commence par un classifieur LLM léger avec un fallback : en cas de doute, on lance les deux récupérations en parallèle et on laisse le LLM de génération arbitrer sur le contexte le plus pertinent. Le coût marginal d'une double récupération reste modeste comparé à l'erreur d'avoir routé une question relationnelle vers le seul vectoriel.

Les pièges du GraphRAG

• Sous-estimer le coût d'ingestion — extraire entités et relations sur un gros corpus coûte cher en appels LLM, comme détaillé plus haut. Mesurez sur un échantillon représentatif avant d'industrialiser.
• Le graphe qui vieillit — un corpus vivant impose de mettre à jour le graphe. Et ce n'est pas un simple « ajout » : intégrer de nouveaux documents peut créer de nouvelles entités, fusionner des nœuds existants, redessiner des communautés entières — donc relancer la détection de communautés et le résumé. Sans stratégie d'incrémental, vous re-payez l'ingestion complète à chaque rafraîchissement.
• La qualité d'extraction — un graphe mal extrait propage des relations fausses, et une relation fausse est pire qu'une absence de relation : elle fonde des réponses confiantes mais erronées. Les écueils typiques : la même entité dédoublée sous deux orthographes (« Acme Cloud » vs « ACME »), des relations hallucinées par le LLM, des types de relations incohérents d'un chunk à l'autre. La qualité du modèle d'extraction et la résolution d'entités sont déterminantes ; prévoyez une passe d'évaluation du graphe lui-même, pas seulement des réponses finales.
• L'over-engineering — déployer un graphe pour des questions que le vectoriel traitait déjà très bien. C'est le piège le plus fréquent, et le plus coûteux : on s'enthousiasme pour la technologie avant d'avoir prouvé que la classe de questions relationnelles existe vraiment dans l'usage réel.

Conclusion

RAG vectoriel et GraphRAG ne s'opposent pas : ils répondent à des familles de questions différentes. Le vectoriel reste le choix par défaut, robuste et économique, pour les questions locales. Le GraphRAG devient pertinent quand la valeur réside dans les relations et la vue d'ensemble — au prix d'un coût et d'une complexité bien réels. La bonne décision ne se prend pas par effet de mode, mais en regardant ce que vos utilisateurs demandent vraiment, en mesurant où le vectoriel échoue, et en n'ajoutant le graphe que là où il rembourse réellement son coût.

Pour aller plus loin

• Architecture RAG de production : du chunking au reranking, le guide complet
• Agentic RAG : quand l'agent décide quoi récupérer (et quand s'arrêter)