Aller au contenu principal

GraphRAG : de la recherche locale à la synthèse globale centrée sur les requêtes

· 7 minutes de lecture
Mike Thrift
Mike Thrift
Marketing Manager

L'article sur GraphRAG de Microsoft, publié en avril 2024, est rapidement devenu la référence pour quiconque se demande si les graphes de connaissances peuvent sauver le RAG (Génération Augmentée par Récupération) de son mode d'échec le plus évident : les questions nécessitant la synthèse d'un corpus entier plutôt que la récupération d'un passage spécifique. Je le lis maintenant car le journal précédent sur FinAuditing a exposé la difficulté des LLM face aux structures XBRL multi-documents — et l'approche par résumé de communauté de GraphRAG est la réponse existante la plus proéminente à ce type précis de problème de raisonnement global.

L'article

2026-06-04-graphrag-local-to-global-query-focused-summarization

« From Local to Global: A Graph RAG Approach to Query-Focused Summarization », par Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness et Jonathan Larson (Microsoft, arXiv:2404.16130), propose un pipeline piloté par LLM en deux étapes pour répondre à ce que les auteurs appellent des « questions de compréhension globale » — des requêtes telles que « Quels sont les thèmes principaux de cet ensemble de données ? » auxquelles le RAG vectoriel standard ne peut répondre car aucun passage unique ne contient la réponse.

L'approche se déroule en deux phases. Lors de l'indexation, un LLM extrait les entités, les relations et les affirmations de chaque fragment de texte, les assemble dans un graphe d'entités pondéré, puis exécute la détection de communautés de Leiden pour partitionner le graphe en une hiérarchie de clusters liés, générant un résumé en langage naturel pour chaque communauté à chaque niveau. Au moment de la requête, chaque résumé de communauté génère indépendamment une réponse partielle (l'étape map), ces réponses partielles sont classées par score d'utilité et assemblées jusqu'à la limite de la fenêtre de contexte (l'étape reduce), et le résultat est une réponse finale synthétisée.

Idées clés

  • La détection de communautés hiérarchique de Leiden structure le corpus en quatre niveaux de granularité (C0–C3), permettant aux utilisateurs de troquer la profondeur de réponse contre le coût en jetons — les résumés au niveau racine ont nécessité 97 % de jetons en moins que le traitement direct du texte source.
  • Sur deux corpus de test — des transcriptions de podcasts (~1M de jetons, 8 564 entités, 20 691 arêtes de relation) et des articles de presse (~1,7M de jetons, 15 754 entités, 19 520 arêtes) — GraphRAG a atteint des taux de victoire de 72 à 83 % en exhaustivité et de 62 à 82 % en diversité contre le RAG vectoriel dans des comparaisons par paires jugées par LLM.
  • La conception map-reduce évite les appels LLM à long contexte au moment de la requête : les résumés de communauté sont précalculés, la récupération devient donc l'obtention d'un résumé plutôt que le retraitement des documents bruts.
  • L'article compare six conditions : quatre niveaux hiérarchiques GraphRAG, la synthèse de texte (TS) et la recherche sémantique (SS). Les conditions Global GraphRAG surpassent systématiquement la recherche sémantique sur les questions de compréhension globale ; la recherche sémantique est plus performante pour les requêtes de recherche spécifique.
  • Les expériences d'extraction d'affirmations ont montré que les conditions globales extrayaient en moyenne 31 à 34 affirmations par réponse, contre 25 à 26 pour le RAG vectoriel, suggérant une couverture thématique plus large indépendante des préférences de notation du juge LLM.
  • Le pipeline ne nécessite aucun schéma ou ontologie spécifique au domaine — l'extraction d'entités, l'étiquetage des relations et la synthèse de communauté proviennent uniquement de l'inférence par prompt.

Ce qui tient la route — et ce qui ne tient pas

L'intuition architecturale centrale est correcte : le RAG par similarité cosinus ne peut pas répondre aux questions au niveau du corpus car il n'existe aucun fragment unique qui représente l'ensemble. Les résumés de communauté précalculés de GraphRAG sont un contournement fondé sur des principes, et la hiérarchie basée sur Leiden est un choix de conception concret qui permet de naviguer des résumés globaux grossiers aux résumés de clusters détaillés selon la tolérance aux coûts.

Cependant, l'évaluation présente de sérieux problèmes. Une étude indépendante récente (arXiv:2506.06331) a audité la méthodologie du LLM en tant que juge utilisée par GraphRAG et ses successeurs et a trouvé trois biais systématiques : le biais de position (les taux de victoire varient de plus de 30 % simplement en changeant l'ordre des réponses dans le prompt), le biais de longueur (une différence de 25 jetons dans une réponse de 200 jetons crée un écart de 50 points dans le taux de victoire), et le biais de répétition (des évaluations identiques produisent des résultats contradictoires d'une exécution à l'autre). Après correction, les avantages de performance revendiqués s'effondrent — le taux de victoire de 66,7 % de LightRAG par rapport au RAG naïf tombe à 39,06 %. Les chiffres d'exhaustivité de 72 à 83 % de GraphRAG souffrent presque certainement de la même méthodologie.

Le coût d'indexation est également un véritable obstacle. Une analyse de praticien cite des coûts de construction d'index atteignant 47,9 $ avec GPT-4o pour des corpus de taille modérée. La variante LazyGraphRAG de Microsoft elle-même, publiée ultérieurement, réduit ce coût à 0,1 % de celui du GraphRAG complet en reportant l'extraction du graphe au moment de la requête — ce qui est une reconnaissance implicite que le budget d'indexation original est impraticable pour de nombreux déploiements réels.

Les deux corpus d'évaluation sont également restreints : deux ensembles de données en anglais totalisant 1 à 1,7M de jetons chacun. Les auteurs reconnaissent que la généralisation à d'autres domaines et échelles est inconnue. Pour les données structurées ou semi-structurées — rapports financiers, exports de grands livres — les prompts d'extraction d'entités optimisés pour les textes narratifs pourraient manquer les relations tabulaires et hiérarchiques qui importent le plus en pratique.

Pourquoi c'est important pour l'IA financière

Un grand livre Beancount est exactement le type de corpus où les requêtes de compréhension globale surviennent naturellement : « Quelles sont mes plus grandes catégories de dépenses au cours des trois dernières années ? » ou « Quels comptes fournisseurs ont augmenté de plus de 20 % d'une année sur l'autre ? ». Le RAG standard ne peut pas répondre à cela car aucune écriture unique ne contient la réponse — l'agent doit synthétiser des milliers de transactions.

L'approche par résumé de communauté de GraphRAG s'y prête bien : si les nœuds du graphe de connaissances sont des comptes, des bénéficiaires et des catégories de transactions, et que les arêtes sont des cooccurrences ou des relations compte-parent, alors les résumés de communauté deviennent des vues agrégées précalculées sur le grand livre. La hiérarchie reflète également la manière dont l'arborescence des comptes de Beancount structure déjà les données — les Actifs, les Dépenses et les Revenus se décomposent de manière récursive, ce qui correspond naturellement au partitionnement hiérarchique de type Leiden.

Cela dit, les conclusions sur le biais d'évaluation sont un avertissement : les taux de victoire impressionnants de l'article pourraient ne pas tenir lors de tests contrôlés rigoureux, et le coût d'indexation en fait un pari technique plus lourd qu'il n'y paraît. Pour Beancount spécifiquement, l'agrégation structurée — requêtes de type SQL ou pandas sur le grand livre exporté — pourrait surpasser la synthèse de communauté pilotée par LLM pour les analyses déterministes. La valeur de GraphRAG serait maximale pour les questions à forte teneur narrative, comme le raisonnement sur les mémos de transaction et les noms de fournisseurs à grande échelle, là où il existe une véritable ambiguïté que les requêtes structurées ne peuvent résoudre.

Que lire ensuite

  • LazyGraphRAG (blog Microsoft Research, 2024) — La variante de Microsoft à coût réduit qui reporte l'extraction du graphe ; directement pertinent pour savoir si l'approche de GraphRAG est déployable à l'échelle d'un grand livre réel sans coûts d'indexation prohibitifs.
  • « How Significant Are the Real Performance Gains? An Unbiased Evaluation Framework for GraphRAG » (arXiv:2506.06331) — L'audit systématique des biais ; lecture essentielle avant d'accepter tout chiffre de taux de victoire provenant d'évaluations de méthodes de synthèse par LLM en tant que juge.
  • « Towards Verifiably Safe Tool Use for LLM Agents » (arXiv:2601.08012, ICSE 2026) — Le prochain élément de la liste de lecture ; passe de la synthèse à la sécurité de l'écriture, qui est le problème non résolu le plus pressant pour les agents Beancount.