Microsoft GraphRAG: Indexing, Community Summaries, Global Search, and Token Costs
Microsoft GraphRAG is an open-source, MIT-licensed indexing and query framework that builds a knowledge graph from a document corpus and layers structured retrieval on top of it, rather than relying solely on nearest-neighbor lookups over embedding vectors. The project originated at Microsoft Research and is maintained as a standalone Python pipeline on GitHub (microsoft/graphrag); it is not a hosted product with its own pricing page, so cost is entirely a function of the LLM and embedding calls the pipeline and its query modes make against whichever model provider is configured, whether Azure OpenAI, OpenAI, or another compatible endpoint. The design responds to a known failure mode of standard retrieval-augmented generation: vector similarity search returns chunks that are locally relevant to a query but cannot answer questions that require synthesizing information scattered across an entire corpus, since no single chunk holds the answer to something like "what are the recurring themes across these 500 documents." GraphRAG addresses this by extracting entities and relationships from source text during indexing, clustering them into a hierarchy of communities, and generating LLM-written summaries of each community that can be searched independently of the raw text. That extra indexing work is also where most of the framework's cost and operational complexity originates, which is why token cost has become as central to evaluating GraphRAG as retrieval quality itself.
········
THE INDEXING PIPELINE: FROM TEXT CHUNKS TO A HIERARCHICAL COMMUNITY GRAPH.
How raw documents become a queryable graph, and which stages actually call the LLM.
Indexing runs as a fixed sequence of stages. Documents are first split into TextUnits, chunks of a configurable size with a documented default of 1,200 tokens; larger chunks index faster but yield less precise entity and relationship extraction. Each TextUnit is then passed to an LLM prompt that returns the entities (title, type, description) and relationships (source, target, description) it contains. Because the same entity or relationship typically appears across multiple TextUnits, subgraphs are merged by matching identical entity titles/types or identical relationship source-target pairs, accumulating their descriptions into arrays rather than discarding duplicates. A separate LLM summarization pass then condenses each entity's and relationship's accumulated description array into one consolidated description, so the graph stores a single coherent statement about each node and edge instead of a growing list of fragments.
Community structure is built on top of the resulting entity graph using the Hierarchical Leiden algorithm, a graph-clustering method applied recursively until clusters fall under a configured size threshold. This produces multiple hierarchy levels: a small number of broad communities at the top of the hierarchy and progressively more numerous, narrower communities below. For every community at every level, an LLM generates a community report — an executive summary plus references to the community's key entities, relationships, and claims — and these reports are themselves summarized for compact reuse. A final embedding pass vectorizes entity descriptions, TextUnit text, and community reports, producing the vector index that local and DRIFT search draw on. Community reports are what make Global Search possible: they let the system reason over corpus-wide themes without re-reading every source chunk at query time.
........
Pipeline stage | What happens | LLM involvement | Output artifact |
Text chunking | Documents split into TextUnits (default 1,200 tokens) | None | TextUnit list |
Entity & relationship extraction | LLM scans each TextUnit for entities and relationships | One call per TextUnit | Raw entity/relationship graph |
Graph summarization | Multiple descriptions per entity/relationship condensed into one | One call per entity/relationship with multiple descriptions | Deduplicated graph |
Community detection | Hierarchical Leiden clustering on the entity graph | None (graph algorithm) | Multi-level community hierarchy |
Community reporting | LLM writes a report for every community at every level | One call per community per level | Community reports |
Embedding | Entities, TextUnits, and community reports vectorized | Embedding model calls | Vector index |
........
········
QUERY MODES: LOCAL, GLOBAL, DRIFT, AND BASIC SEARCH.
Four retrieval strategies built on the same graph, trading cost against the breadth of question each can answer.
Local Search combines the AI-extracted graph with raw text chunks around specific entities, and is suited to entity-centric questions such as what a given entity did or how two entities relate. It performs a targeted graph traversal plus vector lookup, so its cost profile is close to standard vector RAG with graph-traversal overhead on top. Global Search answers corpus-wide questions by running a map-reduce over community reports: the model reads batches of reports at a chosen hierarchy level (the map step), then reduces the partial answers into one final response. Because it processes every community report in scope, Microsoft's own documentation describes it as resource-intensive, and cost scales directly with how many communities exist at the selected level.
Microsoft Research's dynamic community selection addresses that scaling problem directly. Instead of processing every report at a fixed level, the system starts at the root of the community hierarchy and uses a cheaper model to rate each report's relevance to the query, pruning irrelevant branches — and their sub-communities — before they reach the expensive map-reduce step. Microsoft Research reports this cut token costs by 77% compared to static level-1 search, reducing the average number of community reports processed from roughly 1,500 to about 470, with no statistically significant difference in response quality across comprehensiveness, diversity, and empowerment metrics in their evaluation. DRIFT Search takes a different route to a similar goal: a "primer" phase compares the query against the top-k most relevant community reports to produce an initial answer plus follow-up questions, then a "follow-up" phase runs local search on each generated question to fill in specifics, and the results are assembled into a ranked hierarchy of questions and answers. It sits between local and global search in both context breadth and cost, since it never processes the full community-report set the way a plain Global Search does. Basic Search is GraphRAG's own baseline implementation of vector-similarity RAG over the same embedded text chunks, included mainly so a team can compare the graph-based modes against plain retrieval on its own data before committing to the extra indexing spend.
········
INDEXING AND QUERY COSTS: WHERE THE TOKENS GO AND HOW TO CUT THEM.
Concrete cost drivers, documented reduction techniques, and what each lever actually trades away.
Indexing cost is dominated by two LLM passes that scale with corpus size — one extraction call per TextUnit and one summarization call per entity or relationship with multiple accumulated descriptions — plus one community-report call per community at every hierarchy level. A large corpus can produce thousands of communities across levels, each requiring its own LLM call, which is why running the full pipeline with a capable model over a large document set has historically been expensive. Reported cost trajectories vary sharply with model pricing and pipeline configuration: one practitioner account (published independently, not an official Microsoft benchmark) describes indexing a 5-gigabyte legal-case dataset for roughly $33,000 in early 2024, then reindexing comparable data for about $33 by mid-2025 after model price drops and pipeline optimizations — a reported 1,000x difference over about eighteen months. That figure should be read as a single documented case rather than a general multiplier, since it depends heavily on model choice, corpus composition, and which specific optimizations were applied.
Microsoft Research's own mitigations are better documented as vendor-reported figures. LazyGraphRAG removes the LLM-based extraction and summarization passes from indexing entirely, using noun-phrase extraction instead of LLM-based entity recognition and deferring essentially all LLM use to query time. Microsoft Research states LazyGraphRAG's indexing cost is "identical to vector RAG" and about 0.1% of full GraphRAG's indexing cost — roughly a 1,000x reduction, by their own account. At query time, LazyGraphRAG combines best-first search (prioritizing chunks similar to the query) with breadth-first search (covering the dataset broadly) through iterative deepening, controlled by a relevance-test budget parameter that trades cost against answer quality: at low budget it is priced like basic vector search while, per Microsoft Research's evaluation, outperforming competing methods on local queries; at a budget around 4% of Global Search's cost it reportedly matches or exceeds Global Search quality on both local and global queries; and Microsoft Research separately reports comparable answer quality to Global Search on global queries at more than 700x lower query cost. These are the vendor's own published claims and have not been independently verified in this article. Dynamic community selection, described above, is the complementary lever for teams that want to keep the standard indexing pipeline but reduce Global Search's per-query cost.
........
Cost lever | Stage affected | Reported effect | Source |
Cheaper model for extraction/reporting calls | Indexing | Lower cost per call, some quality trade-off | Practitioner reports |
LazyGraphRAG (noun-phrase extraction, no indexing-time LLM calls) | Indexing | ~0.1% of full GraphRAG indexing cost | Microsoft Research (vendor claim) |
LazyGraphRAG relevance-test budget | Query (global) | Reported >700x lower cost than Global Search at comparable quality | Microsoft Research (vendor claim) |
Dynamic community selection | Query (global) | 77% token reduction vs. static level-1 search | Microsoft Research (vendor claim) |
DRIFT search instead of exhaustive Global Search | Query | Lower cost than full map-reduce; not independently quantified in public docs | Microsoft documentation |
Chunk size / community size-threshold tuning | Indexing | Fewer or larger units reduce call count, at some cost to extraction precision | Microsoft documentation |
........
········
DEPLOYMENT, LICENSING, AND WHEN THE GRAPH PAYS FOR ITSELF.
How teams actually run GraphRAG, and the trade-off that decides whether it belongs in a given pipeline.
GraphRAG is distributed as an MIT-licensed Python package on GitHub; there is no separate GraphRAG subscription or license fee, and all cost is LLM and embedding API usage plus whatever compute runs the indexing pipeline. Teams typically self-host the pipeline and point it at Azure OpenAI, OpenAI, or another compatible endpoint. Microsoft also publishes a reference accelerator for one-click deployment on Azure, and the resulting vector index component can be backed by Azure AI Search instead of a local index. None of this bundles a managed query service: the query modes are library functions a team wires into its own application, not an API endpoint Microsoft operates on their behalf.
The trade-off that decides fit is straightforward once the mechanics are clear. GraphRAG's extraction, clustering, and community-reporting stages exist specifically to answer questions that require synthesizing information across many documents at once — thematic summaries, corpus-wide change detection, multi-hop relationships between entities that never appear in the same chunk. Standard vector RAG, including GraphRAG's own Basic Search mode, has no mechanism for that: it can only return chunks similar to the query, so it degrades on aggregate or corpus-wide questions regardless of embedding model quality. That capability is bought with an indexing pass that scales with corpus size and community count, and, in its original full-pipeline form, with per-query costs for Global Search that can exceed a vector RAG query by a wide margin. If the workload is dominated by narrow, entity- or fact-level lookups against a corpus that changes frequently, standard vector RAG or GraphRAG's Basic Search mode is the better starting point and the graph can be skipped entirely. If a meaningful share of queries are genuinely corpus-wide or require connecting entities across documents, GraphRAG is worth adopting, but the decision rule is to start with LazyGraphRAG or dynamic community selection rather than the original full-indexing pipeline, and to reach for the full pipeline only if those cheaper modes fail on the actual query mix in production.
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
