Guide GraphRAG : quand les graphes de connaissances battent le vector RAG (et quand ce n'est pas le cas)

Guide GraphRAG : quand les graphes de connaissances battent le vector RAG (et quand ce n'est pas le cas)

GraphRAG n'est pas mort, mais il n'est pas non plus le choix par défaut. microsoft/graphrag a publié la v3.1.1 le 2026-07-18, fort de 35 088 étoiles GitHub, et trois benchmarks de 2026 rapportent désormais, ouvertement, qu'il perd fréquemment face à la recherche vectorielle classique. Ce guide GraphRAG répond donc à la seule question qui reste : un graphe de connaissances vaut-il sa facture d'indexation ?

Faut-il utiliser GraphRAG ? La réponse courte

Utilisez GraphRAG quand vos questions traversent plusieurs entités ou couvrent l'ensemble du corpus, du type « quels sont les fournisseurs auxquels notre plus gros client vend aussi ses produits ? ». Pour les recherches de faits mono-saut, les documents qui changent vite et les budgets de latence serrés, restez au RAG classique ou hybride. Le graphe rentabilise son coût sur les questions multi-sauts et vous fait perdre de l'argent partout ailleurs.

GraphRAG n'est ni mort ni devenu le standard. Il vaut sa facture d'indexation quand vos questions sont multi-sauts ou couvrent tout le corpus, et il perd de l'argent dans le cas contraire.

La version courte :

• GraphRAG gagne sur les questions multi-sauts et à l'échelle du corpus ; le RAG classique gagne sur les recherches mono-saut.
• Les benchmarks de 2026 sont mitigés : les graphes aident l'agrégation mais peuvent dégrader les résumés fins.
• Le coût tombe au moment de l'indexation, dans les appels LLM d'extraction, pas au moment des requêtes.
• Avant de construire quoi que ce soit, lancez Basic Search comme témoin sur votre propre corpus.

Si vous avez déjà un pipeline de RAG vectoriel qui tourne, la seule décision est de savoir si un graphe par-dessus vaut son entretien. Le tableau ci-dessous résume tout le débat en six lignes, et là où il dit de rester au classique, c'est la réponse honnête, plus souvent que les éditeurs ne l'admettent. La recherche hybride BM25 plus vecteurs couvre la plupart de ces cas sans aucun graphe.

Ce qu'est vraiment GraphRAG : des fragments aux communautés

GraphRAG est une génération augmentée par recherche appliquée à un graphe de connaissances plutôt qu'à des fragments déconnectés. À l'indexation, un LLM extrait les entités et les relations de vos documents, l'algorithme Leiden regroupe ces entités en communautés, et chaque communauté reçoit un résumé. Au moment de la requête, le graphe et ces résumés répondent à des questions auxquelles une fenêtre top_k sur des fragments ne peut structurellement pas répondre.

Le pipeline, de bout en bout :

Documents
  |
  v
Chunks --> LLM entity + relationship extraction
  |
  v
Knowledge graph (entities = nodes, relations = edges)
  |
  v
Leiden community detection --> community summaries
  |
  v
Vector index over entity + community descriptions

Deux phases font le travail. La phase d'indexation est la plus coûteuse : chaque fragment exige un appel LLM pour extraire entités et relations, et les résumés de communautés ajoutent encore des appels par-dessus. La phase de requête est celle où le retour sur investissement apparaît. Comme le graphe stocke les relations explicitement, une question du type « quels sont les fournisseurs auxquels notre plus gros client vend aussi ? » devient un parcours de graphe, au lieu de reposer sur la chance que les deux bons fragments atterrissent dans la même fenêtre top_k.

Les résumés comptent, car ce sont eux que Global Search lit réellement : les questions couvrant tout le corpus reçoivent une réponse à partir de textes de communautés écrits à l'avance, pas de fragments bruts. Et chaque arête est un jugement du LLM, stocké sous forme de triplet que vous pourriez requêter en Cypher sur une vraie base de données graphe. Cette conception explique aussi pourquoi l'indexation domine le coût, ce que les chiffres ci-dessous concrétisent.

La formulation qui mérite sa place : le RAG classique récupère des passages, GraphRAG récupère de la structure. Votre choix de modèle d'embedding compte toujours pour la couche vectorielle, et votre base de données vectorielle stocke toujours les descriptions, mais le graphe est la nouvelle pièce porteuse de l'édifice. La documentation officielle, Index Overview, décrit chaque étape en détail.

Quelles sont les quatre méthodes de requête de GraphRAG ?

Le moteur de requête de GraphRAG embarque quatre méthodes : Local Search, Global Search, DRIFT Search et Basic Search. Local Search raisonne à partir d'entités précises, Global Search agrège les résumés de communautés sur l'ensemble du corpus, DRIFT Search combine les deux de façon récursive, et Basic Search est une simple base vectorielle. Une cinquième fonctionnalité, la génération de questions, se greffe au-dessus du moteur plutôt qu'à côté.

Nous avons vérifié la documentation en ligne sur microsoft.github.io/graphrag/query/overview/ le 2026-07-30, et le compte est bien de quatre. La plupart des guides bien classés n'en citent que deux ou trois. La même vérification a trouvé le mot « lazy » zéro fois sur les pages Index et Query Overview, ce qui compte pour la section coût ci-dessous.

La ligne qui mérite votre attention est la dernière. Basic Search est la base vectorielle classique intégrée, et elle existe pour que vous puissiez comparer le graphe à la recherche simple en A/B sur votre propre corpus, et découvrir si le graphe vaut sa facture. Ce n'est pas un détail ; c'est toute la procédure de décision de ce guide, ramassée dans une seule fonctionnalité. Lancez Basic Search en premier. Si Local, Global ou DRIFT Search ne le battent pas sur les questions qu'on vous pose réellement, le graphe est un coût, pas une amélioration.

Qu'ont vraiment trouvé les benchmarks de 2026 ?

Trois benchmarks de 2026 concluent que GraphRAG aide sur les tâches d'agrégation multi-sauts et multi-faits, mais reste fréquemment en dessous du RAG classique ailleurs. L'un d'eux a construit un benchmark précisément pour repérer là où les graphes perdent. Tous les trois s'accordent : le gain dépend du type de question, pas de la taille du corpus. Les preuves disent que GraphRAG est situationnel, pas un choix par défaut.

Un quatrième travail, GraphRAG-Bench (dépôt), évalue neuf méthodes GraphRAG sur 16 disciplines et 20 manuels, et aboutit à la même conclusion sous un angle plus large.

Les trois benchmarks convergent sur un point : le graphe rentabilise son coût sur l'agrégation multi-sauts et le perd sur le rappel fin.

Notre lecture : le cycle de hype a fait les dégâts, et ces benchmarks sont la correction. Aucun ne dit que les graphes sont inutiles. Ce qu'ils disent, avec constance, c'est que l'étape d'agrégation qui rend GraphRAG bon sur les thèmes couvrant tout le corpus est la même étape qui brouille les détails fins. WildGraphBench en est l'exemple le plus net : les graphes ont aidé l'agrégation multi-faits à partir d'un nombre modéré de sources, et ils ont dégradé la précision des résumés dans la même évaluation. Ce n'est pas une contradiction ; c'est un seul mécanisme qui se manifeste deux fois.

La conséquence pratique, c'est que vous ne pouvez pas trancher avec la seule littérature. Les benchmarks vous disent quels types de questions tester, pas si votre corpus en fait partie. C'est exactement le rôle du témoin Basic Search de la section méthodes ci-dessus.

Combien coûte GraphRAG ? (Et la mise en garde LazyGraphRAG que tout le monde répète mal)

Le coût de GraphRAG est une facture d'indexation, pas de requête, et c'est précisément pour cela qu'il surprend. Les appels LLM qui extraient entités et relations de chaque fragment, plus la passe de résumé des communautés, sont ce qui le rend cher. Vous payez d'avance, avant la moindre requête. Le temps de requête est moins cher mais pas gratuit : Global Search se déploie sur les résumés de communautés avec un appel LLM par communauté, raison pour laquelle le tableau des méthodes ci-dessus le classe élevé.

Les seuls chiffres publics et solides viennent de Microsoft Research. Le 2024-11-25, l'équipe rapportait que le coût d'indexation de LazyGraphRAG était identique à celui du RAG vectoriel et représentait 0,1 % du coût de GraphRAG complet, et qu'avec 4 % du coût de requête de Global Search, il surpassait les méthodes concurrentes testées, sur les requêtes locales comme globales (Microsoft Research). Ce sont les chiffres de Microsoft, tirés du blog de Microsoft, et nous les rapportons comme tels ; nous n'avons pas nous-mêmes exécuté d'indexation tarifée.

Voici la correction que la plupart des articles manquent. LazyGraphRAG n'est pas une option installable avec pip. Selon la note éditoriale de Microsoft du 2025-06-06, il a été intégré à Microsoft Discovery et Azure Local, pas au package open source. Nous avons vérifié les pages officielles Index Overview et Query Overview le 2026-07-30 : le mot « lazy » y apparaît zéro fois. Donc si un guide présente LazyGraphRAG comme une variante que vous pouvez lancer cet après-midi, il répète une affirmation qui a cessé d'être vraie dans le monde open source.

Ce que vous pouvez faire aujourd'hui : exécuter le modèle d'extraction en local. Pointer l'étape d'indexation vers un modèle local via Ollama supprime les frais d'API au token de la phase la plus coûteuse, et associer cela à un stock vectoriel auto-hébergé maintient le reste de la facture près de zéro.

Quelle bibliothèque GraphRAG est vraiment maintenue ?

Deux des six bibliothèques GraphRAG les plus citées n'ont pas reçu de push depuis six et neuf mois. Nous avons tiré ces chiffres de l'API GitHub le 2026-07-30, et le recensement ci-dessous est la vérification que les comparatifs plus anciens sautent, avec la commande pour la relancer avant de vous engager sur l'une d'elles. LightRAG et microsoft/graphrag sont celles qui vivent ; nano-graphrag et fast-graphrag dérivent vers l'abandonware.

for r in HKUDS/LightRAG microsoft/graphrag getzep/graphiti neo4j/neo4j-graphrag-python gusye1234/nano-graphrag circlemind-ai/fast-graphrag; do gh api "repos/$r" --jq '.full_name,.stargazers_count,.pushed_at,.open_issues_count'; done

Notre lecture : les étoiles sont une mesure de vanité ; la date de push est le chiffre qui compte. LightRAG et microsoft/graphrag sont toutes deux activement maintenues, Graphiti suivant de près sur l'angle du graphe temporel. nano-graphrag et fast-graphrag sont les deux que les anciens articles recommandent encore sur leur seule réputation, et aucune des deux n'a rien publié depuis un semestre.

Comment choisir : prenez microsoft/graphrag si vous voulez l'implémentation de référence avec les quatre méthodes de requête officielles, LightRAG si vous voulez le projet le plus actif et une empreinte plus légère, et une bibliothèque maintenue par l'éditeur comme neo4j-graphrag-python si vous utilisez déjà la base de données de cet éditeur. Évitez tout ce dont le dernier push précède votre projet d'un semestre.

Graphiti mérite une note cadrée : sa conception de graphe temporel est pensée pour la recherche sur des données sensibles au temps, et elle recoupe la mémoire des agents, que nous couvrons à part dans notre guide sur Graphiti et la mémoire des agents IA. Pour le champ plus large, voyez le paysage des outils RAG.

Ce qui casse après le jour 200 : dérive du graphe et ré-extraction

La dérive du graphe est la taxe que vous payez après la mise en production, et c'est la première objection des praticiens, pour de bonnes raisons. Tous les tutoriels traitent le graphe comme une chose qu'on construit une fois. Les vraies équipes se retrouvent bloquées au jour 200.

Trois choses se dégradent. D'abord, la réindexation lors des mises à jour documentaires. Quand 40 documents changent, vous ne pouvez pas simplement recalculer leurs embeddings ; vous devez relancer l'extraction LLM sur les fragments modifiés, réconcilier les nouvelles entités avec l'ancien graphe, puis recalculer les communautés concernées et leurs résumés. Un guide sur Medium qualifie la mise à jour incrémentale de facile. Les praticiens de r/Rag ne sont pas d'accord. L'auteur d'un thread du 2026-04-25 faisant tourner BM25 plus BGE-M3 sur environ 600 documents le disait sans détour : « L'extraction d'entités et de relations par LLM est bruitée, et la réindexation lors des mises à jour de documents a l'air pénible. »

Ensuite, la dérive de la résolution d'entités. « Acme Corp », « Acme » et « ACME Corporation » arrivent dans des documents différents, à des mois d'intervalle, et se divisent en trois nœuds qui devraient n'en faire qu'un. Rien ne les fusionne automatiquement.

Enfin, les relations qui étaient vraies au moment de l'extraction et qui cessent silencieusement de l'être. Personne ne reçoit d'alerte quand une arête reports_to devient obsolète.

def on_documents_changed(changed_docs):
    stale = find_affected_nodes(changed_docs)
    re_extract(changed_docs)
    reconcile_entities(stale)
    recompute_communities(affected_only=True)
    re_summarize(affected_communities)

Un dépôt de code est le pire des cas, et le plus intéressant. L'autocomplétion propose désormais « graphrag for codebase », « graphrag claude code » et « graphrag mcp server », et un dépôt de code est un graphe qui change toutes les heures : chaque commit réécrit les arêtes d'appels, déplace des symboles et supprime des fonctions. C'est de la dérive de graphe à un rythme qu'aucune réindexation nocturne ne peut suivre complètement. C'est aussi pourquoi les outils sérieux de graphe de code s'appuient sur des parseurs déterministes comme tree-sitter et LSP pour les arêtes, et réservent le LLM au texte qui les entoure : docstrings, messages de commit, threads de revue. Si vous mettez un dépôt en graphe, passez la couche qui bouge lentement au LLM et celle qui bouge vite au parseur.

Que disent vraiment les développeurs de GraphRAG ?

Les développeurs en activité sont divisés, et Google semble le savoir : un thread Reddit se classe deuxième sur « graphrag vs rag », ce qui est le moteur de recherche vous disant que ce sujet réclame des avis de pairs, pas du discours d'éditeur.

Le scepticisme est réel. Sur le thread r/Rag de 2024 « Would you always recommend (knowledge) graph RAG over normal RAG? » (10 points, 86 % de votes positifs), u/EncartaIt écrivait : « Tous les tutoriels que j'ai trouvés sont trop simplistes et ne défendent pas vraiment le motif du knowledge graph. » u/Prestigious_Run_4049 était plus direct : « Je pense que graph rag, c'est juste de la hype. Les gens adorent en parler et ça sonne bien, mais personne ne l'utilise vraiment sur des cas réels. » Tout le monde n'est pas d'accord. u/pytheryx, argumentant depuis la production, notait que la recherche par graphe gagne sur les questions de type liste exigeant le contexte de plus de fragments que top_k n'en retourne ; son corpus de livres blancs a besoin d'environ 50 fragments pour une réponse complète.

Le thread de 2026 est plus mesuré. u/Popular_Sand2773 : « La plupart des setups graph rag trichent tout simplement à grande échelle. Vous lancez une recherche vectorielle ou par métadonnées standard pour trouver des nœuds de départ, puis vous vous promenez dans le graphe. » u/ggone20, qui fait tourner un système d'environ 300 millions d'artefacts : « À grande échelle, vous ne pouvez littéralement pas vous en passer pour répondre à de vraies questions. »

Notre lecture rejoint l'argument le plus tranchant des deux threads : le point de bascule est la complexité de vos questions, pas la taille de votre corpus. C'est aussi ce que les benchmarks ci-dessus ont trouvé, raison pour laquelle nous donnons raison aux praticiens qui cantonnent l'outil au travail multi-sauts plutôt qu'à ceux qui le déclarent mort.

Comment Techsy aborde la question

Voici l'ordre que nous suivons sur les projets clients, et il est volontairement ennuyeux.

D'abord, prouver le plafond de la recherche hybride. La plupart des demandes « il nous faut un graphe » que nous entendons sont en réalité un problème de découpage en fragments ou de reclassement déguisé. Un pipeline BM25 plus vecteurs avec un bon reranker répond à plus de besoins que les équipes ne l'imaginent.

Ensuite, lancer Basic Search comme témoin sur votre propre corpus avant de construire quoi que ce soit. C'est exactement le rôle de la quatrième méthode de requête : une base vectorielle simple contre laquelle comparer le graphe en A/B, sur vos données, avec vos questions.

Enfin, ne construire le graphe que lorsqu'une classe de questions mesurée échoue à ce témoin. Si les requêtes multi-sauts ou couvrant tout le corpus échouent, vous avez un vrai cas. Sinon, vous venez de vous épargner une facture d'indexation et un problème de dérive.

Vous voulez un second regard sur votre pile de recherche ? Demandez une consultation gratuite.

Questions fréquemment posées

Comment fonctionne GraphRAG ?

GraphRAG indexe vos documents dans un graphe de connaissances. Un LLM extrait les entités et les relations de chaque fragment, l'algorithme Leiden regroupe ces entités en communautés, et chaque communauté reçoit un résumé. Au moment de la requête, le moteur interroge le graphe et ces résumés, si bien qu'il peut relier des faits situés dans des fragments différents.

En quoi GraphRAG diffère-t-il du RAG ?

Le RAG standard récupère les k fragments les plus similaires et les fournit au modèle. GraphRAG récupère de la structure : les entités, les relations entre elles, et des résumés de communautés écrits à l'avance. Ce surplus de structure est ce qui lui permet de répondre aux questions multi-sauts et couvrant tout le corpus, et c'est aussi ce qui rend l'indexation plus lente et plus chère.

Quand faut-il utiliser GraphRAG ?

Utilisez-le quand vos questions traversent plusieurs entités ou couvrent tout le corpus, comme les questions de chevauchement de fournisseurs ou l'analyse de thèmes récurrents sur des milliers de documents. Passez votre chemin pour les recherches de faits mono-saut, les corpus qui changent vite et les budgets de latence ou de coût serrés. Si un pipeline hybride simple répond déjà à une classe de questions, le graphe ajoute du coût sans ajouter de valeur.

GraphRAG est-il mort ?

Non, mais il n'est pas non plus le choix par défaut. Les benchmarks de 2026 montrent qu'il fait fréquemment moins bien que le RAG classique sur les tâches courantes, ce qui a tué la hype, tout en continuant de gagner sur les questions multi-sauts et d'agrégation. La formulation honnête est situationnelle : GraphRAG rentabilise son coût pour les bons types de questions et perd de l'argent pour le reste.

Quelles sont les méthodes de requête de GraphRAG ?

Le moteur de requête officiel en embarque quatre : Local Search pour les questions centrées sur une entité, Global Search pour l'agrégation à l'échelle du corpus, DRIFT Search pour une combinaison récursive des deux, et Basic Search pour la simple recherche vectorielle. Une cinquième fonctionnalité, la génération de questions, se greffe au-dessus. Basic Search est la plus importante : c'est le témoin contre lequel vous comparez le graphe en A/B.

Combien coûte l'indexation GraphRAG ?

Le coût tombe au moment de l'indexation, dans les appels LLM qui extraient entités et relations de chaque fragment, plus le résumé des communautés. Microsoft Research a rapporté un coût d'indexation de LazyGraphRAG égal à 0,1 % de celui de GraphRAG complet et identique au RAG vectoriel, mais cette variante a été livrée dans des produits Microsoft, pas dans la bibliothèque open source. Nous n'avons pas exécuté nous-mêmes d'indexation tarifée.

Peut-on faire tourner GraphRAG en local avec Ollama ?

Oui. La bibliothèque microsoft/graphrag vous permet de pointer l'indexation et les requêtes vers un modèle local servi par Ollama, ce qui supprime les frais d'API au token de l'étape d'extraction. Vous échangez de la vitesse et de la qualité contre du coût : les modèles locaux sont moins bons en extraction d'entités, alors attendez-vous à des graphes plus bruités et à des indexations plus longues sur du matériel modeste.

LightRAG ou Microsoft GraphRAG : lequel est le meilleur ?

Ils n'optimisent pas la même chose. LightRAG (38 353 étoiles, dernier push le 2026-07-30) est le plus actif et plus léger à faire tourner ; microsoft/graphrag (35 088 étoiles, v3.1.1) est l'implémentation de référence avec les quatre méthodes de requête officielles. Choisissez LightRAG pour un graphe de production efficace, celui de Microsoft pour un comportement fidèle à la spécification et le témoin Basic Search.

Qui a créé GraphRAG, et quand ?

Microsoft Research a créé GraphRAG. L'équipe a publié l'article en 2024 et maintient le dépôt open source microsoft/graphrag sous licence MIT, avec la documentation sur microsoft.github.io/graphrag. La bibliothèque de référence a atteint la v3.1.1 le 2026-07-18, et un écosystème actif d'implémentations tierces, dont LightRAG et Graphiti, s'est développé autour.

Le verdict : quand un graphe rentabilise son coût

Les preuves pointent dans une seule direction, alors voici la position.

• GraphRAG n'est pas mort. Il est situationnel, et les benchmarks de 2026 le disent tout haut.
• Il rentabilise sa facture d'indexation sur les questions d'entités multi-sauts et sur l'agrégation à l'échelle du corpus. Il perd de l'argent sur les recherches mono-saut.
• Le coût est une facture d'indexation, et la variante bon marché que tout le monde cite, LazyGraphRAG, n'a jamais atteint la bibliothèque open source.
• Le graphe se dégrade après la mise en production : la résolution d'entités dérive et les relations deviennent obsolètes, alors prévoyez un budget de réindexation.
• Lancez Basic Search comme témoin sur votre propre corpus avant de construire quoi que ce soit.

Une phrase : un graphe de connaissances rentabilise son coût quand vos questions sont multi-sauts ou couvrent tout le corpus, et pas avant. Si vous voulez un second avis sur votre pile de recherche, demandez une consultation gratuite.