GraphRAG (graph retrieval-augmented generation) is a type of RAG that builds a knowledge graph from your documents. It retrieves answers from that graph instead of only from isolated text chunks.
An LLM reads each chunk, pulls out entities and the relationships between them, and groups related entities into communities. At query time, the system uses those entities, relationships, and community summaries as context for the answer.
A few terms make this easier to follow:
- RAG: a pattern where a system retrieves relevant text and passes it to an LLM as context before the model answers.
- Knowledge graph: a data structure where nodes are things (people, products, APIs, companies) and edges are the relationships between them.
- Entity: a named thing the LLM extracts from text, such as "Stripe" or "OAuth 2.0."
- Relationship: a typed link between two entities, such as "Stripe supports OAuth 2.0."
Microsoft Research introduced the GraphRAG method described here. In Microsoft's GraphRAG paper, the authors report: "For a modest drop in performance compared with other global methods, root-level GraphRAG offers a highly efficient method for the iterative question answering that characterizes sensemaking activity, while retaining advantages in comprehensiveness (72% win rate) and diversity (62% win rate) over vector RAG." Those win rates come from LLM-judged comparisons on corpus-wide questions, not from every kind of query.
Why Vector RAG Struggles With Connected Questions
Vector RAG retrieves the few chunks whose embeddings look most similar to the question. This works well when the answer sits in one or two passages, such as "What is the rate limit on the search endpoint?"
It works poorly when the answer is spread across documents that never mention each other. Imagine a docs site where one page deprecates an endpoint, a second page introduces its replacement, and a third page lists a migration caveat. A question like "What breaks if we migrate now?" needs all three, but similarity search may only return the page that best matches the wording.
Vector RAG also has no direct way to answer corpus-wide questions such as "What are the main themes across these 5,000 support tickets?" No single chunk contains that answer. GraphRAG addresses both problems by storing connections explicitly and summarizing groups of related entities ahead of time.
How GraphRAG Works
GraphRAG runs in two stages. Indexing builds the graph once from your corpus, and querying uses that graph every time someone asks a question.
The indexing stage is where most of the cost and most of the quality risk sit. The querying stage decides how the graph is searched for each question.
Indexing: Turning Text Into a Knowledge Graph
Indexing starts by splitting documents into chunks. An LLM then reads each chunk and extracts entities, relationships, and short descriptions of each. The system merges duplicate entities across chunks into a single graph.
In Microsoft's design, an LLM processes every chunk during extraction. As a result, indexing cost grows with the number of input tokens, and any noise in the text gets processed and paid for too.
Community Detection and Community Summaries
After extraction, the pipeline described in Microsoft's paper uses hierarchical Leiden clustering, a community detection algorithm, to group densely connected entities into nested communities. A community might be "payment APIs" at one level and "refund handling" at a lower level.
An LLM then writes a summary, called a community report, for each community. These reports let GraphRAG answer corpus-wide questions without reading every source chunk at query time.
Querying: Local, Global, and DRIFT Search
GraphRAG offers several query modes, and each one retrieves context differently:
| Query Mode | Best For | How It Retrieves Context |
|---|---|---|
| Local search | Questions about specific entities | Matches entities to the question, then pulls their neighbors, relationships, and source text |
| Global search | Corpus-wide questions about themes | Runs a map-reduce pass over community reports and combines partial answers |
| DRIFT search | Specific questions that benefit from broader context | Starts from community reports, then runs local follow-up searches |
DRIFT stands for Dynamic Reasoning and Inference with Flexible Traversal. In Microsoft's DRIFT search evaluation, the team reports: "On comprehensiveness, DRIFT search outperformed Local Search 78% of the time." That result comes from 50 LLM-judged local questions over a news dataset.
GraphRAG vs RAG: Key Differences
GraphRAG and vector RAG differ in what they index, what they cost, and which questions they answer well. The table compares both on the same criteria.
| Criteria | Vector RAG | GraphRAG |
|---|---|---|
| Retrieval unit | Text chunks ranked by embedding similarity | Entities, relationships, community reports, and linked source text |
| Index build | Embed chunks once | LLM extraction per chunk, clustering, and LLM summaries per community |
| Best question types | Single-fact and detail lookups | Multi-hop and corpus-wide questions |
| Cost profile | Low indexing cost | High upfront indexing cost |
| Adding new documents | Embed the new chunks | Extract the new chunks; affected community reports can go out of date |
| Traceability | Shows retrieved chunks | Shows entities and relationships plus source text |
Neither approach wins across the board. An independent RAG vs GraphRAG benchmark found: "In QA, RAG performs better on single-hop and detail-oriented factual queries, whereas GraphRAG is more effective on multi-hop, reasoning-intensive questions."
The same study also measured build cost. On the MultiHop-RAG dataset, building the vector RAG index took 135 seconds, while building the community-based GraphRAG index took 5,560 seconds.
How Much GraphRAG Costs
GraphRAG cost is front-loaded at indexing. You pay for an LLM extraction call on every chunk and for an LLM summary of every community before anyone asks a question.
The main cost drivers are:
- Corpus size: more input tokens mean more extraction calls.
- Chunk size: smaller chunks give finer-grained extraction but more calls.
- Extraction model: larger models cost more per token but can build better graphs.
- Community levels: each level of the hierarchy adds summaries to generate.
- Update frequency: changed documents need new extraction calls and can leave community reports out of date.
Because of this, test on a small sample and tune extraction prompts before indexing a full corpus. A full re-index of a large corpus repeats every extraction and summary call.
LazyGraphRAG: A Lower-Cost Variant
LazyGraphRAG is a Microsoft Research variant that defers LLM use until query time. At index time it uses lightweight NLP noun-phrase extraction to find concepts and how often they appear together. It skips upfront community summaries.
Microsoft reports a large drop in indexing cost from this design. In its write-up on LazyGraphRAG indexing cost, Microsoft states: "LazyGraphRAG data indexing costs are identical to vector RAG and 0.1% of the costs of full GraphRAG."
These are Microsoft's own results on one news dataset. Microsoft also notes that full GraphRAG indexes still have value beyond question answering, such as reading the community reports directly.
When to Use GraphRAG and When Not To
Use GraphRAG when your users ask questions that span many documents or depend on relationships between entities. Stay with vector RAG when most questions are single-fact lookups or when your budget cannot absorb a large indexing bill.
| Situation | Recommended Approach | Why |
|---|---|---|
| "What are the main themes across this corpus?" | GraphRAG global search | Community reports summarize the whole dataset ahead of time |
| Multi-hop questions across linked documents | GraphRAG local or DRIFT search | Explicit relationships connect facts that similarity search can miss |
| Single-fact lookups ("What is the limit on X?") | Vector RAG | The answer sits in one passage, and vector RAG performed better on single-hop questions |
| Small corpus or tight indexing budget | Vector RAG or LazyGraphRAG | Full graph extraction may cost more than it returns |
| Sources that change daily or weekly | Vector RAG, or GraphRAG with incremental updates | Full re-indexing on every change is expensive |
| Mixed question types | Hybrid: route by question type | Each approach covers the other's weak spots |
Why Source Data Quality Decides Graph Quality
A GraphRAG index is only as good as the entities and relationships the LLM extracts. The LLM extracts from whatever text you give it. If chunks contain navigation menus, cookie banners, or repeated footers, those fragments can become entities and edges in the graph.
Graph construction quality changes results. In the same independent benchmark, switching extraction models moved overall MultiHop-RAG scores from 65.77 with no graph to 71.17 with GPT-4o-mini and 75.08 with GPT-4o.
That study tested the extraction model, not input cleanliness. By the same logic, noisier input likely gives the extractor more chances to create wrong or useless nodes. The same principle drives web scraping for RAG pipelines, where boilerplate in the index degrades the answers.
Clean Input Reduces Extraction Noise and Cost
Feed the indexer clean Markdown instead of raw HTML. Markdown keeps headings, lists, and tables that help the LLM understand structure, while dropping markup and page chrome that add tokens without adding meaning.
For web sources, the practical workflow is to crawl entire documentation sites into Markdown pages and keep each page's source URL as metadata for citations. Only then chunk and index.
Choosing the right AI-ready input formats matters here because every token you send is a token the extraction step bills. Preparing LLM-ready web data before indexing can reduce both cost and the cleanup work on the finished graph.
Keeping the Graph Fresh as Sources Change
Web sources change, move, and disappear, and a stale graph keeps answering from old facts. Community reports summarize groups of entities, so new or deleted documents can leave those reports out of date. Rebuilding the whole index to fix that repeats every extraction and summary call.
A practical pattern is to update only what changed:
- Detect changes: monitor source pages for changes on a schedule instead of re-crawling everything.
- Compare versions: use structured change-tracking diffs to see which pages were added, edited, or removed.
- Re-extract changed pages: run entity extraction only on new or edited content.
- Remove deleted content: drop entities and relationships whose only source was a deleted page.
- Refresh affected summaries: regenerate community reports only for communities that changed.
This pattern keeps the graph current without paying for a full re-index each time a source updates.
Common GraphRAG Use Cases
GraphRAG fits workloads defined by the type of question, not by industry. Common examples include:
- Summarizing themes across large collections of reports, transcripts, or support tickets.
- Investigating connections between people, companies, and events spread across many documents.
- Answering questions over technical documentation with heavy cross-references between pages.
- Building competitive or market intelligence from many web sources about the same companies.
Frequently Asked Questions
What is GraphRAG and how does it work?
GraphRAG is a RAG approach that uses an LLM to extract entities and relationships into a knowledge graph. It groups them into summarized communities and retrieves from that structure at query time.
How is GraphRAG different from RAG?
Standard RAG retrieves similar text chunks, while GraphRAG retrieves entities, relationships, and community summaries. That helps with multi-hop and corpus-wide questions but costs more to build.
How much does GraphRAG cost?
Most GraphRAG cost comes from indexing, because every chunk needs an LLM extraction call and every community needs an LLM summary. The total depends on corpus size, chunk size, model choice, and how often you re-index.
What are common uses for GraphRAG?
GraphRAG is used for corpus-wide summaries, investigations across many documents, cross-referenced technical documentation, and multi-source market research.
Does GraphRAG reduce hallucinations?
That claim is not proven. An independent benchmark found GraphRAG's global search handled questions with no valid answer poorly, which suggests a higher hallucination risk on those queries.
What is the difference between local and global search in GraphRAG?
Local search starts from specific entities and their neighbors, while global search combines community reports to answer questions about the whole dataset.
What is LazyGraphRAG?
LazyGraphRAG is a Microsoft Research variant that skips upfront LLM summaries and defers LLM work to query time. Microsoft reports that this lowers indexing cost to the level of vector RAG.
How do you keep a GraphRAG index up to date?
Detect which source pages changed, re-extract only those pages, remove entities from deleted sources, and regenerate summaries only for the communities affected.