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 (microsoft.github.io/graphrag, captured 2026-07-28). The broader architecture family without this package’s query modes and cost variants lives on GraphRAG. This page covers the Microsoft index, the four query modes, dynamic community selection, LazyGraphRAG’s published cost ratios, and the Edge et al. evaluation bands.

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 (GraphRAG docs “The GraphRAG Process,” captured 2026-07-28; Edge et al., 2024 §2).

1. Slice into TextUnits. The corpus becomes analyzable chunks that also serve as fine-grained citations in answers.
2. Extract entities, relationships, and claims. An LLM reads each TextUnit and emits graph elements. DataCamp’s GraphRAG tutorial (captured 2026-07-28) notes that this extraction pass is where most indexing LLM calls happen.
3. Cluster with Leiden. Hierarchical community detection groups densely connected entities (docs cite the Leiden technique; Traag et al.).
4. Summarise communities bottom-up. An LLM writes a natural-language community report for each community so thematic questions can use precomputed structure instead of thousands of raw chunks.

Edge et al. (2024 §3.6) report the resulting graphs for their evaluation corpora: Podcast transcripts — 8564 nodes / 20691 edges; News articles — 15754 nodes / 19520 edges.

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, captured 2026-07-28; DataCamp tutorial).

• Local search — combine knowledge-graph neighbourhoods with raw text chunks for entity-specific questions (for example, properties of a named herb in the docs’ example).
• Global search — map-reduce over community reports for corpus-wide themes (“What are the main themes?”). Resource-heavy because many reports enter the map step unless pruned.
• DRIFT search — DataCamp describes three phases: a community-summary primer that emits an initial answer plus follow-ups; local follow-up drills; then a ranked combine. Docs position DRIFT as local search expanded with community context.
• Basic search — top-k vector RAG when the graph is overkill.

Pick the mode by question shape: entity lookup → local; whole-corpus theme → global; both breadth and entity detail → DRIFT.

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, “Improving global search via dynamic community selection”).

On an AP News evaluation with 50 global questions, the blog reports:

• Similar quality at much lower cost when capped at level 1. Versus static global search at community level 1, dynamic search showed no statistically significant quality gap on comprehensiveness, diversity, or empowerment, while cutting average token cost by 77%. Static map-reduce processed about 1500 level-1 reports; dynamic selection kept about 470 on average.
• Deeper search can buy detail for more spend. 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).
• Cheaper model for rating. Their experiment used GPT-4o-mini for relevance rating and GPT-4o for map-reduce generation.

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

Edge et al. (2024 §3.6) evaluate global GraphRAG as query-focused summarisation over two corpora in the ~1 million-token range (Podcast and News), using head-to-head LLM win rates on 125 questions per comparison (each repeated five times and averaged).

• Versus naïve vector RAG. Global GraphRAG conditions achieved comprehensiveness win rates of 72–83% on Podcast transcripts and 72–80% on News articles; diversity win rates were 75–82% and 62–71% respectively (paper Figure 4 discussion).
• Versus map-reducing source text. Table 3: root-level community summaries (C0) required over 97% fewer context tokens than summarising source texts; low-level (C3) summaries used 26–33% fewer tokens while staying competitive on quality.

The paper’s Discussion (§5) limits the claim: only a class of sensemaking questions on two corpora — not a universal production SLA. Re-measure on your labelled global set.

What does Microsoft GraphRAG cost, and what is LazyGraphRAG?

Full Microsoft GraphRAG spends most tokens at index time; LazyGraphRAG is the Research blog’s deferred-LLM alternative that keeps graph structure without pre-writing community summaries.

• Full GraphRAG indexing. Every TextUnit needs an extraction LLM call, and every community needs a summary (DataCamp GraphRAG FAQ, captured 2026-07-28). Global queries then scale with how many community reports enter map-reduce.
• LazyGraphRAG indexing. Microsoft Research’s LazyGraphRAG blog states indexing costs identical to vector RAG and 0.1% of full GraphRAG, because NLP noun-phrase / co-occurrence extraction replaces LLM entity summarisation and community-summary generation at index time.
• LazyGraphRAG query claims (same blog). A configuration matched to vector-RAG query cost is reported to match GraphRAG global answer quality at more than 700× lower query cost; at 4% of GraphRAG global search (C2) query cost, LazyGraphRAG significantly outperforms the blog’s competing conditions on both local and global queries in their win-rate charts. An editor’s note dated 2025-06-06 points to Microsoft Discovery / Azure Local integrations — confirm current packaging before shipping.

No single dollar total transfers across corpora — measure token spend on yours.

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

Microsoft GraphRAG earns its index when private documents need connect-the-dots reasoning or corpus-wide themes. It is usually the wrong default for short factual lookups.

• Use it for the two baseline-RAG failure classes the docs name. Shared-attribute multi-document questions, and holistic themes over large private collections (GraphRAG docs “GraphRAG vs Baseline RAG”).
• Prefer vector RAG for simple facts and small corpora. DataCamp’s guidance: start with standard RAG and move to GraphRAG when those limits appear.
• Match index depth to query lifetime. Edge et al. (§5) note the graph-index investment depends on compute budget and expected lifetime queries; LazyGraphRAG’s blog positions itself for one-off, exploratory, and streaming cases that cannot afford LLM summarisation up front.

Family-level when-to-use without package modes is on GraphRAG; the structured-vs-similarity decision frame is on RAG vs knowledge graph.

How is Microsoft GraphRAG different from LightRAG or RAPTOR?

Microsoft GraphRAG is one concrete stack inside a larger graph-retrieval family.

• Microsoft GraphRAG — LLM entity extraction, Leiden communities, community-summary global search, plus DRIFT / dynamic selection / LazyGraphRAG variants in the MS ecosystem.
• Family GraphRAG — the mechanism page for entity-graph retrieval without this package’s query catalogue — GraphRAG.
• LightRAG — a cheaper dual-level graph-retrieval profile — LightRAG.
• RAPTOR — hierarchical clustering over embedding vectors of text chunks (Edge et al. related work), not Leiden communities over extracted entities — RAPTOR.

How do you implement Microsoft GraphRAG?

Implementing Microsoft GraphRAG is a handoff checklist: install microsoft/graphrag, initialise config, run the indexer, then query with an explicit method.

1. Start from the official repo and docs. github.com/microsoft/graphrag and microsoft.github.io/graphrag get_started (captured 2026-07-28).
2. Init and index. Docs advise graphrag init –root [path] –force between minor version bumps so config matches the release.
3. Query by mode. Choose local, global, drift, or basic vector search per question type.
4. Tune prompts. The docs strongly recommend the Prompt Tuning guide rather than shipping defaults on a new domain.

DataCamp’s CLI/Python walkthrough is a workable tutorial, but runnable pipeline assembly for this site belongs on building the pipeline.