Microsoft GraphRAG: Community Summaries over a Graph

Microsoft GraphRAG is the Edge et al. (2024; arXiv:2404.16130) open-source pipeline in microsoft/graphrag: it extracts an entity-relationship graph from text, clusters entities into Leiden communities, writes LLM community summaries, and answers with Local, Global, DRIFT, or Basic search. The GraphRAG docs on microsoft.github.io/graphrag describe that process and the query engine. The broader architecture family without this package’s query modes and cost variants lives on GraphRAG. Microsoft GraphRAG sits among the named patterns in what each architecture added.

How does Microsoft GraphRAG index a corpus?

Microsoft GraphRAG builds its index before any user query by turning raw documents into a hierarchical community-summary graph. The GraphRAG docs describe the GraphRAG process as slicing text into TextUnits, extracting entities, relationships, and claims with an LLM, clustering with Leiden hierarchical community detection, and writing community reports bottom-up so thematic questions can use precomputed structure instead of thousands of raw chunks (microsoft.github.io/graphrag Index overview; Edge et al., 2024 section 2).

Edge et al. (2024 section 3.6) report the resulting graphs for their evaluation corpora: Podcast transcripts produced 8,564 nodes and 20,691 edges; News articles produced 15,754 nodes and 19,520 edges. That extraction-and-summary pass is where most indexing LLM spend happens, which is why later sections treat LazyGraphRAG as a deliberately cheaper indexing alternative rather than a free upgrade.

Once the community hierarchy exists, the next question is which query mode reads which layer of that index.

How do local, global, and DRIFT search work in Microsoft GraphRAG?

Microsoft GraphRAG’s query engine assembles LLM context from the finished index in four documented modes (Query Engine overview, microsoft.github.io/graphrag). Local search combines knowledge-graph neighbourhoods with raw text chunks for entity-specific questions. Global search runs map-reduce over community reports for corpus-wide themes such as “What are the main themes?” and is resource-heavy because many reports enter the map step unless pruned. DRIFT search expands local search with community context: a community-summary primer emits an initial answer plus follow-ups, local follow-up drills gather detail, and a ranked combine merges the results. Basic search is top-k vector RAG when the graph is overkill.

Pick the mode by question shape. Entity lookup fits local search. Whole-corpus theme questions fit global search. Questions that need both breadth and entity detail fit DRIFT. The Query Engine overview positions Basic search as the fallback when graph structure does not earn its indexing cost. The same docs are the source for mode names; secondary tutorials that rename the modes without citing the package should not override them.

Global search’s cost problem is what dynamic community selection was built to fix.

What is dynamic community selection in GraphRAG global search?

Dynamic community selection is Microsoft Research’s optimization for global search: an LLM rates whether each community report is relevant to the question, walking from the root of the hierarchy and pruning irrelevant branches before the expensive map-reduce (Microsoft Research blog, “GraphRAG: Improving global search via dynamic community selection”).

On an AP News evaluation with 50 global questions, that blog reports similar quality to static global search at community level 1 with no statistically significant gap on comprehensiveness, diversity, or empowerment, while cutting average token cost by 77%. Static map-reduce processed about 1,500 level-1 reports; dynamic selection kept about 470 on average. Allowing descent to level 3 on the 29 questions that pulled more reports than the static baseline, dynamic search won 58.8% on comprehensiveness and 60.0% on empowerment versus static level 1, at +34% relative token cost (blog Table 1). Their experiment used GPT-4o-mini for relevance rating and GPT-4o for map-reduce generation.

Those figures are AP News results under that rating setup, not a universal SLA for every corpus. The next published evaluation to read is Edge et al.’s original global GraphRAG versus naive vector RAG comparison.

How well did Microsoft GraphRAG score in the Edge et al. evaluation?

Edge et al. (2024 section 3.6) evaluate global GraphRAG as query-focused summarisation over two corpora in the roughly one-million-token range: Behind the Tech podcast transcripts and a decade of news articles. They generate 125 sensemaking questions per dataset (K = M = N = 5) and repeat each comparison five times for LLM-as-judge win rates on comprehensiveness, diversity, empowerment, and directness.

Global GraphRAG conditions outperformed naive vector RAG on comprehensiveness and diversity. Comprehensiveness win rates for global approaches versus naive RAG were 72 to 83% on Podcast transcripts and 72 to 80% on News articles; diversity win rates were 75 to 82% and 62 to 71% respectively (Edge et al., 2024). Table 2 in the paper shows root-level community summaries (C0) using about 2.6% and 2.3% of the maximum context tokens versus source-text map-reduce on Podcast and News, which is more than 97% fewer tokens at the root; low-level summaries (C3) still used 26 to 33% fewer tokens than source-text map-reduce. The paper’s limitations section notes the evaluation is sensemaking questions on two corpora, not a universal accuracy claim for every RAG workload.

Indexing and query cost are the other half of the decision, especially when community summaries are written with LLMs at index time.

What does Microsoft GraphRAG cost, and what is LazyGraphRAG?

Full Microsoft GraphRAG pays LLM calls twice: once to extract and summarize the graph at index time, and again at query time when map-reduce reads community reports. Global query cost scales with how many community reports enter the map step, which is why dynamic selection’s 77% average token cut matters on large level-1 hierarchies.

LazyGraphRAG is Microsoft Research’s follow-on that defers LLM use until query time. The LazyGraphRAG blog (Microsoft Research) states that indexing costs are identical to vector RAG and 0.1% of full GraphRAG because it builds an NLP co-occurrence concept graph without LLM community summaries at index time. For comparable query cost to vector RAG, the same blog reports LazyGraphRAG outperforming competing local methods in their head-to-head charts, and comparable global answer quality to GraphRAG global search at more than 700× lower query cost. At 4% of GraphRAG global query cost (C2 level), LazyGraphRAG significantly outperformed competing methods on both local and global query types in that evaluation (5,590 AP news articles; 50 local and 50 global synthetic queries). Those ratios are Microsoft Research’s published comparisons on that setup; measure your own corpus before treating them as a budget line.

The cost structure decides when full GraphRAG, dynamic global search, or LazyGraphRAG is the right spend.

When should you use Microsoft GraphRAG, and when should you avoid it?

Microsoft GraphRAG earns its indexing cost when questions need connect-the-dots reasoning or corpus-wide themes over private text that vector RAG under-answers. Edge et al. motivate global sensemaking questions that no small set of similar chunks can cover. The GraphRAG docs contrast that global mode with baseline vector retrieval for entity-local questions.

Avoid full GraphRAG indexing for simple fact lookups, tiny corpora, or workloads where Basic or ordinary vector RAG already recovers the answer. Prefer LazyGraphRAG when you need graph-shaped retrieval without paying LLM community summarization up front, especially for exploratory or streaming corpora (LazyGraphRAG blog). Prefer dynamic community selection when you already run full GraphRAG global search and token cost at level 1 is the bottleneck. Family mechanism without this package’s modes lives on the GraphRAG family page; deciding whether a knowledge graph belongs in the stack at all is a separate product decision on RAG versus knowledge graphs.

Related hierarchical and cheaper-graph designs answer different failure modes and should not be collapsed into one name.

How is Microsoft GraphRAG different from LightRAG or RAPTOR?

Microsoft GraphRAG is the Edge et al. package: LLM entity extraction, Leiden communities, community-summary global search, plus Local, DRIFT, and Basic modes in microsoft/graphrag. The family GraphRAG page covers the mechanism without that package’s query-mode and cost-variant depth. LightRAG is a cheaper dual-level graph variant with its own indexing and retrieval recipe, covered on LightRAG. RAPTOR builds hierarchical embedding clusters over summaries rather than Leiden entity communities, and that design is covered on RAPTOR.

Do not treat “GraphRAG” in a vendor blog as automatically meaning microsoft/graphrag. Confirm whether the author means the Microsoft package, a generic entity-graph RAG pattern, or another named system such as LightRAG or LazyGraphRAG before copying indexing budgets.

With the borders fixed, the remaining question is what you wire when you implement the Microsoft package.

How do you implement Microsoft GraphRAG?

Implementing Microsoft GraphRAG is a handoff checklist: install microsoft/graphrag, initialize a project, run the indexer over TextUnits, then query with –method local, global, or drift (GitHub microsoft/graphrag; GraphRAG docs get-started and Query Engine overview, as of September 2026 captures). Prompt tuning for your domain is recommended in the docs because extraction quality drives community quality.

Entity and chunk vectors used by local and Basic search can live in any store that returns ranked neighbours. Vector stores with native hybrid search, including Weaviate, Qdrant, Pinecone, and Azure AI Search, can hold those embeddings beside keyword fields. Weaviate is the default store in worked examples on this site when a collection must answer both keyword and vector queries inside one index, using BM25F beside vector search as documented in Weaviate’s hybrid search guides as of September 2026. That does not invent a Microsoft GraphRAG benchmark on Weaviate; it only places where vector-backed local search often sits.

Runnable end-to-end pipeline assembly, including evaluation harnesses and pinned clients, belongs on building the pipeline. Check the package changelog before upgrading: microsoft/graphrag still moves between minor versions.

Microsoft GraphRAG indexes private text into Leiden communities and community summaries, then answers with Local, Global, DRIFT, or Basic search as documented in microsoft/graphrag. Edge et al. (2024) publish comprehensiveness win rates of 72 to 83% versus naive vector RAG on their Podcast sensemaking set, and Microsoft Research reports a 77% average token cut for dynamic community selection at level 1 on AP News. Use full GraphRAG when global themes justify LLM indexing; use LazyGraphRAG when you need graph retrieval without that index bill; measure win rates and tokens on your own corpus before treating any published ratio as a production SLA.