Quand choisir GraphRAG plutôt que le RAG vectoriel

GraphRAG est une architecture de retrieval spécifique à certains workloads

GraphRAG modifie le choix d’architecture RAG pour les questions qui dépendent des relations à travers l’ensemble du corpus. Le RAG conventionnel découpe les documents en chunks, les convertit en embeddings, récupère un petit ensemble de chunks similaires à la requête, puis fournit ces passages au modèle. Pour « Quelle était notre politique de remboursement au T3 ? », ce workflow peut récupérer directement le passage pertinent. Pour « Quels sont les thèmes récurrents sur deux années de réclamations clients ? », la réponse peut être répartie sur de nombreux passages qui, pris individuellement, ne semblent que faiblement liés à la question.

Cette différence rend GraphRAG utile pour une catégorie plus restreinte de problèmes de retrieval. GraphRAG, introduit dans des travaux évoqués par Microsoft Research, remplace ou complète le retrieval de texte isolé par un graphe des entités du corpus et de leurs relations. Les équipes d’ingénierie doivent donc identifier quelles requêtes nécessitent une structure en graphe et lesquelles peuvent rester sur la voie de retrieval plus simple et moins coûteuse. Les travaux initiaux de Microsoft ainsi que quatre études de benchmark indépendantes montrent que cette décision dépend du workload, plutôt que d’établir un avantage général du graphe.

La différence architecturale réside dans la capacité à relier des preuves entre plusieurs passages

La distinction entre workloads commence par ce que la similarité vectorielle peut récupérer. Lorsque deux passages contiennent des faits liés par une entité commune, le fait d’encoder chaque chunk indépendamment n’expose pas cette connexion comme un chemin de retrieval explicite. La recherche par similarité ne couvre également qu’une petite fraction d’un corpus, ce qui crée un problème structurel pour les questions portant sur des thèmes ou des schémas répartis dans toute la collection. Les frontières entre chunks aggravent le problème, car les relations et la hiérarchie nécessaires à un raisonnement complexe peuvent disparaître lorsque les documents sont divisés.

Ce problème de retrieval est à l’origine de l’approche de Microsoft Research. Microsoft Research affirme que le RAG de base « peine à relier les points ». Les mêmes travaux indiquent qu’il fonctionne mal lorsqu’on lui demande de « comprendre de manière holistique des concepts sémantiques résumés sur de vastes collections de données ». Le premier problème consiste à relier des preuves distribuées ; le second exige de sélectionner et d’organiser suffisamment de preuves pour représenter l’ensemble d’un corpus.

GraphRAG traite ces deux problèmes en déplaçant une part importante du traitement sémantique en amont de la requête. Lors de l’indexation, un LLM traite d’abord chaque chunk et en extrait les entités, les relations et les assertions. Ces éléments deviennent un graphe de connaissances pondéré, après quoi l’algorithme de Leiden effectue une détection de communautés, regroupant les éléments connectés du graphe en une hiérarchie de sujets. GraphRAG produit ensuite à l’avance un résumé en langage naturel pour chaque communauté, de sorte que l’index contient des relations explicites et des synthèses de plus haut niveau pour le retrieval ultérieur.

Ces communautés indexées modifient la manière dont une requête rassemble les preuves. Les communautés pertinentes produisent des réponses partielles lors de l’étape « map » ; ces réponses partielles sont classées et fusionnées lors de l’étape « reduce » ; et le modèle génère sa réponse à partir du contexte structuré qui en résulte. Pour une analyse des réclamations à l’échelle du corpus, ce processus fournit au modèle des preuves issues de plusieurs parties pertinentes de la collection ainsi qu’une méthode systématique pour les combiner. La requête peut ainsi couvrir l’ensemble du corpus sans dépendre entièrement des chunks individuels les plus proches.

D’autres systèmes fondés sur des graphes utilisent différemment les relations explicites. HippoRAG combine un graphe avec Personalized PageRank, un mécanisme de parcours de graphe qui classe les nœuds pertinents en se déplaçant à travers les parties connectées du graphe, afin de récupérer des passages. Son processus de retrieval diffère des résumés de communautés pré-calculés de Microsoft GraphRAG, mais les deux rendent les relations du corpus disponibles au moment de choisir le contexte. La distinction architecturale tient à la capacité du retrieval à suivre ces relations lorsqu’un seul passage ne suffit pas.

Ces relations exigent un travail supplémentaire avant de pouvoir améliorer le retrieval. GraphRAG déplace le traitement sémantique plus tôt dans le pipeline via l’extraction d’entités et de relations, la construction du graphe, le clustering et la synthèse. Tout gain en retrieval ou en raisonnement s’accompagne donc d’un travail d’indexation supplémentaire et d’une complexité opérationnelle accrue. La question posée par les benchmarks est de savoir si cet investissement apporte un gain de qualité suffisant pour les requêtes qu’un système reçoit réellement.

Dans les benchmarks, l’avantage du graphe augmente avec la profondeur du raisonnement

Les expériences de Microsoft sur les requêtes globales montrent un workload où cet investissement peut porter ses fruits. Microsoft a comparé GraphRAG directement à un RAG naïf sur des questions nécessitant une compréhension globale de jeux de données d’un million de tokens, et un LLM a évalué les réponses selon leur exhaustivité, leur diversité et leur capacité à éclairer l’utilisateur. Microsoft développe GraphRAG et les outils associés ; l’entreprise a donc un intérêt commercial dans l’adoption de cette approche, et ses résultats doivent être lus en gardant cet intérêt à l’esprit. Les chiffres de comparaison figurent dans le tableau de bord ci-dessous aux côtés de résultats de benchmarks indépendants.

L’expérience sur les requêtes globales est importante parce qu’elle teste le problème créé par les limites du retrieval vectoriel. Une demande portant sur des thèmes à l’échelle du corpus ne peut pas supposer de manière fiable que quelques chunks individuellement similaires représentent l’ensemble de la collection. Microsoft a également constaté que les résumés de plus haut niveau de GraphRAG consommaient jusqu’à 97 % de tokens en moins que le traitement direct du texte source. Le pré-calcul de la structure peut donc réduire le volume de matériau source entrant dans ce type de requête, même si la construction de cette structure a un coût d’indexation.

Les benchmarks multi-hop testent le même problème de retrieval à un niveau plus fin. MuSiQue, HotpotQA et 2WikiMultiHopQA exigent des réponses qui dépendent de plusieurs étapes de raisonnement ; trouver un passage pertinent ne fournit donc pas nécessairement suffisamment de preuves. Leurs résultats Recall@5 mesurent si les éléments de support apparaissent parmi les cinq résultats récupérés, rendant visible la qualité du retrieval avant même le début de la génération. La génération ne peut pas raisonner sur des preuves que le retrieval ne fournit jamais.

HippoRAG propose un test connexe avec une conception différente du retrieval par graphe. Il fait état d’une amélioration de précision pouvant atteindre 20 % sur la QA multi-hop, tout en coûtant 10 à 20× moins cher et en s’exécutant 6 à 13× plus vite que les méthodes de retrieval itératif. Ces chiffres d’efficacité comparent HippoRAG au retrieval itératif plutôt qu’au retrieval vectoriel ordinaire ; ils répondent donc à une question d’architecture différente de celle d’une comparaison directe graphe contre vecteur. Ils montrent que l’exploitation des relations du graphe peut éviter d’envoyer à plusieurs reprises un modèle dans une séquence coûteuse d’étapes de retrieval.

Une étude contrôlée de 2025 menée par Michigan State et Meta réduit une autre source de variation. Elle a comparé le RAG conventionnel à quatre familles de GraphRAG en utilisant un chunking, des embeddings et une génération identiques, et aucune méthode n’a gagné de manière universelle ; le retrieval par graphe et le retrieval conventionnel se sont révélés complémentaires. Le fait de maintenir constants ces composants environnants rend plus visible le type de tâche comme facteur de différenciation des résultats. Les résultats single-hop et multi-hop de l’étude figurent dans le tableau de bord.

GraphRAG-Bench, associé à l’ICLR 2026, pose directement la question du type de tâche : « Dans quels scénarios les structures en graphe apportent-elles des bénéfices mesurables ? » Ses résultats au niveau des tâches distinguent les faits simples du raisonnement complexe et de la synthèse contextuelle. Cette distinction est importante, car elle teste si la structure en graphe modifie les performances à mesure que les preuves deviennent plus distribuées et interconnectées. Le tableau de bord conserve ces mesures séparées, car les études utilisent des métriques et des protocoles de comparaison différents.

L’affirmation la plus forte en faveur de GraphRAG dépend de la méthode d’évaluation

Le type de tâche modifie également la manière d’interpréter les principaux taux de victoire mis en avant par Microsoft, car de nombreuses comparaisons de GraphRAG utilisent un autre LLM pour évaluer les réponses générées. Un audit indépendant des LLM utilisés comme juges a mis en évidence un biais systématique de position : inverser l’ordre d’apparition des réponses peut modifier le taux de victoire de plus de 30 points. L’audit a également identifié un biais de longueur et un biais d’essai, où des comparaisons identiques répétées peuvent produire des jugements contradictoires. Ces effets rendent difficiles à considérer comme stables de faibles écarts dans la préférence subjective pour une réponse.

L’ampleur de ce problème d’évaluation apparaît dans un exemple audité. Une méthode populaire annonçait initialement un taux de victoire de 66,7 %, mais la correction l’a ramené à environ 39 %, en dessous du seuil d’équilibre de 50 %. Un résultat fondé sur un juge peut donc passer d’une supériorité apparemment convaincante à une situation où il perd plus de comparaisons qu’il n’en gagne. Les écarts d’exhaustivité méritent donc des vérifications fondées sur des références lorsque des décisions d’architecture en dépendent.

Les mesures directes de retrieval et de précision sur les tâches dépendent moins de cet ordre subjectif. HippoRAG rapporte ce qui est présenté comme « +20 % de précision multi-hop », tandis que les résultats des benchmarks multi-hop sont décrits comme des « bonds de recall de 15 à 30 points », ces benchmarks mesurant soit la capacité du retrieval à trouver des preuves pertinentes, soit l’exactitude de la réponse finale. Ces mesures étayent plus solidement le choix du workload qu’une faible marge de préférence, car elles dépendent moins du classement par un LLM juge de deux réponses générées. L’argument en faveur des graphes est le plus solide lorsque des mesures spécifiques à la tâche confirment le même type de workload que celui identifié par les expériences sur les requêtes globales.

Cette réserve sur l’évaluation restreint donc la portée de l’affirmation architecturale. Elle réduit la confiance que l’on peut accorder au fait de traiter chaque taux de victoire rapporté comme une preuve équivalente, en particulier pour des qualités subjectives telles que l’exhaustivité. La précision multi-hop, Recall@5, la recherche factuelle contrôlée et les résultats spécifiques aux tâches de GraphRAG-Bench offrent une base plus solide pour décider quand la structure en graphe aide réellement. Dès lors que l’affirmation de qualité devient spécifique au workload, le coût supplémentaire doit être évalué sur la même base.

La qualité du graphe a un coût d’indexation

Ce coût commence avec le prétraitement nécessaire à la création des relations du graphe. Un LLM doit extraire les entités et les relations à travers le corpus, et une analyse estime à environ 48 $ le coût de construction de l’index pour un corpus de taille modérée en prenant GPT-4o comme référence tarifaire. L’indexation vectorielle conventionnelle évite ce pipeline d’extraction sémantique. Lorsque les benchmarks sur des faits simples montrent peu d’avantage pour le graphe, appliquer ce coût à chaque corpus se justifie faiblement en termes de qualité pour des workloads dominés par ce type de questions.

Le LazyGraphRAG de Microsoft modifie cette économie en reportant l’extraction au moment de la requête. Microsoft affirme que son coût représente environ 0,1 % de celui de l’approche initiale ; comme Microsoft développe ces approches GraphRAG et bénéficie commercialement de leur adoption, cette affirmation sur les coûts porte le même intérêt fournisseur que ses autres affirmations sur GraphRAG. Ce report modifie le moment où le travail est effectué ; les équipes doivent donc toujours prendre en compte le chemin de requête qui en résulte, en plus des exigences de qualité. Un coût de prétraitement plus faible modifie l’arbitrage sans le supprimer.

Cet arbitrage est le plus clair pour « quel est le numéro de téléphone à la page 3 ». La preuve demandée est directement localisée et ne nécessite ni parcours de relations, ni synthèse de communautés, ni raisonnement à l’échelle du corpus. L’extraction du graphe ajoute du traitement sans apporter une capacité requise par cette requête, tandis que l’étude contrôlée et les résultats de GraphRAG-Bench ne montrent aucun avantage en recherche factuelle susceptible de compenser ce travail supplémentaire. À volume de requêtes ou taille de corpus suffisants, le coût d’indexation, la latence et la complexité opérationnelle peuvent l’emporter sur un gain de qualité marginal.

Cette recherche simple montre pourquoi le coût modifie la décision d’architecture elle-même. Si le retrieval par graphe était systématiquement supérieur pour chaque requête, son coût supplémentaire pourrait être évalué face à une amélioration universelle de la qualité. Or l’amélioration mesurée dépend de la tâche ; la dépense doit donc dépendre du chemin dont la tâche a besoin. La sélection au moment de la requête découle de cette asymétrie.

Orientez les requêtes selon les preuves qu’elles exigent

Un routeur de retrieval peut préserver les points forts des deux approches en choisissant une méthode de retrieval pour chaque requête. Les questions multi-hop, globales et de sensemaking sont les candidates les plus évidentes au retrieval par graphe, en particulier lorsque l’utilisateur a besoin de réponses exhaustives représentant plusieurs perspectives. Les corpus fortement interconnectés, comme les bibliothèques de recherche, les dossiers de cas, les historiques d’incidents et les bases de connaissances, créent des relations que le retrieval par graphe peut exploiter. Ces workloads correspondent aux tâches pour lesquelles les benchmarks montrent les gains les plus importants.

La recherche d’un fait unique oriente vers les chunks conventionnels, car la preuve peut souvent être récupérée directement. Les corpus petits ou peu structurés offrent également moins de relations utiles à encoder, tandis que les équipes soumises à de fortes contraintes de coût, de latence ou de simplicité opérationnelle ont des raisons supplémentaires de conserver la voie vectorielle. Le retrieval conventionnel par chunks de texte reste une architecture pratique pour le workload qu’il traite bien. La capacité graphe peut ensuite être invoquée lorsque la requête exige des connexions au-delà d’un passage directement pertinent.

Un système hybride peut faire ce choix requête par requête ou fusionner les preuves issues des deux méthodes de retrieval. Dans l’ensemble des études systématiques, la combinaison du retrieval par graphe et du retrieval par chunks surpasse systématiquement chacune des approches prise isolément. La fusion peut préserver les passages directement pertinents tout en ajoutant des preuves sélectionnées par le graphe lorsque les relations comptent, tandis que le routage peut éviter d’activer la voie graphe supplémentaire lorsqu’une recherche directe suffit. La recherche étaye ce principe architectural sans pour autant établir un classificateur universel ni un seuil universel pour mettre en œuvre le routeur.

En l’absence de seuil universel, chaque équipe reste confrontée à un problème d’ingénierie spécifique à son workload : déterminer, à partir de sa propre distribution de requêtes, quelles demandes nécessitent un raisonnement entre passages ou une synthèse globale. Une base de connaissances de support dominée par des questions isolées sur des politiques et des coordonnées n’a pas la même économie qu’une archive d’incidents utilisée pour retracer des causes récurrentes à travers les systèmes et le temps. La composition des requêtes détermine la fréquence à laquelle la structure de graphe supplémentaire peut justifier son coût. L’architecture doit suivre cette composition.

En conclusion

GraphRAG n’est pas un remplacement du RAG vectoriel. C’est une architecture de retrieval supplémentaire pour les workloads où les réponses dépendent des relations entre documents, entités ou à l’échelle du corpus dans son ensemble. Les éléments issus des benchmarks pointent dans la même direction : la valeur de la structure en graphe tend à augmenter à mesure que les preuves sont plus distribuées et que le raisonnement devient plus complexe.

Pour les décideurs, cela rend la composition des requêtes plus importante que les gains mis en avant par les benchmarks. Une organisation dominée par la recherche factuelle peut tirer peu de bénéfices du coût de construction du graphe, de sa maintenance et de la complexité opérationnelle supplémentaire. Une organisation qui pose régulièrement des questions multi-hop, d’investigation ou à l’échelle du corpus a un argument plus solide en faveur de cet investissement.

L’architecture pratique est donc souvent hybride. Conservez le retrieval conventionnel pour les questions qu’il traite efficacement, et orientez les questions riches en relations ou globales vers le retrieval par graphe lorsque le gain de qualité attendu justifie le coût. Évaluez les deux approches sur des requêtes métier représentatives en utilisant la précision du retrieval, la qualité des réponses, la latence et le coût total, plutôt que de vous appuyer sur un seul benchmark.

En définitive, la décision consiste moins à choisir entre GraphRAG et le RAG vectoriel qu’à déterminer où chacun a sa place. La structure en graphe justifie sa place lorsque les relations font partie des informations que l’entreprise doit récupérer.