GraphRAG: Retrieval Over a Knowledge Graph
Building the graph, querying it, and the corpora where it beats vector retrieval — with the indexing cost stated.
GraphRAG retrieves over a knowledge graph of entities and relationships — often with community summaries — instead of only similar text chunks. That is how it follows shared attributes across documents and answers corpus-wide questions baseline vector RAG misses. The name is overloaded: architecture family and Microsoft Research’s Edge et al. (2024) pipeline in microsoft/graphrag. This page covers how the graph is built, how local and global search use it, what indexing costs, and when vector RAG is still enough — among the patterns on RAG architectures.
How does GraphRAG build the knowledge graph?
GraphRAG builds the knowledge graph at index time by extracting entities and relationships from text, clustering related entities into communities, and (in the Microsoft-style pipeline) writing a summary for each community before any user query arrives.
The reference steps — documented on Microsoft’s GraphRAG site (as of the July 2026 capture of microsoft.github.io/graphrag) and matching Edge et al., arXiv:2404.16130 — are:
- Split into text units. The corpus is sliced into analyzable chunks (Microsoft calls them TextUnits) that later become fine-grained citations in answers.
- Extract entities and relationships. An LLM reads each unit and emits entities, relationships between them, and often claims — short factual statements tied to the graph. DataCamp’s GraphRAG tutorial (2025–2026) is blunt that this extraction pass is where most indexing LLM calls happen: every chunk needs a model call.
- Assemble the graph. Entities become nodes; relationships become edges. This is the retrieval substrate described more generally on knowledge graphs for retrieval.
- Detect communities. Hierarchical clustering groups tightly related entities. The Microsoft pipeline uses the Leiden algorithm (Traag et al.; cited from the GraphRAG docs).
- Summarise communities bottom-up. An LLM writes a natural-language summary for each community, with higher-level summaries incorporating lower ones — the precomputation that makes global questions feasible without stuffing thousands of chunks into one prompt.
- Embed for hybrid entry. Entity descriptions, relationships, and community summaries are typically embedded so vector search can find a starting node. GraphRAG usually uses embeddings; it does not replace them. Vectors locate an entry point; the graph supplies neighbourhood and community context.
Other stacks share the extract→graph→retrieve shape without Leiden community summaries — Neo4j GenAI guides and LangChain/LlamaIndex property-graph retrievers are in that broader family. Chunk-similarity graphs that only link passages by embedding distance (no entity extraction) are a different mechanism and are out of scope here. Package-level detail for Microsoft’s indexer belongs on Microsoft GraphRAG.
How does GraphRAG answer a query?
GraphRAG answers a query by assembling LLM context from graph structure — an entity neighbourhood for local questions, or precomputed community summaries for global ones — rather than from top-k similar chunks alone.
Microsoft’s documented query modes (Query overview on microsoft.github.io/graphrag, July 2026 capture) and the same split in DataCamp’s tutorial are:
- Local search — identify entities in the question, retrieve them (often via vector similarity on descriptions), then fan out to neighbouring entities, relationships, associated text units, and nearby community context. Use this for entity-specific questions (“What did Acme announce about Q3?”).
- Global search — run a map-reduce over community summaries: each relevant summary produces a partial answer, then those partials are reduced into one corpus-level response. Use this for thematic questions (“What are the main themes in this dataset?”) that Edge et al. (2024) frame as query-focused summarisation rather than ordinary retrieval.
- DRIFT search — Microsoft’s hybrid that starts from community-level context and follows up with local traversal (named here only; mechanism depth is on Microsoft GraphRAG).
- Basic / vector search — standard top-k chunk retrieval when the question does not need the graph.
Local search stays in a neighbourhood and is usually cheaper at query time; global search touches many community summaries and scales with how many communities you ask the model to read.
How expensive is GraphRAG?
GraphRAG is expensive primarily at index time because every text unit needs an LLM extraction call and every community needs an LLM-written summary — before a single user query runs.
The structural cost, stated without inventing a dollar total:
- Indexing dominates. DataCamp’s GraphRAG FAQ (captured July 2026): every text chunk requires an LLM call for entity extraction, and community summaries need generation too. Brian Curry’s GraphRAG guide (Medium, 11 Feb 2026) and Stackviv’s overview (updated 27 Jul 2026) both note that Microsoft’s pipeline warns indexing can be costly and recommend starting on a small corpus.
- Query cost depends on mode. Local search is comparatively cheap (a neighbourhood). Global search processes community summaries, so token spend scales with community count and corpus size (DataCamp FAQ).
- Published quality claim stays qualitative here. Edge et al. (2024, arXiv:2404.16130) report that for global sensemaking questions over datasets in the ~1 million token range, GraphRAG showed substantial improvements over a conventional RAG baseline on comprehensiveness and diversity of answers. They do not publish a single percentage lift that this page can safely crown as “the” GraphRAG number — so none is invented.
Measure token spend on your own corpus
Exact dollars depend on model prices, chunk size, entity density, and how often you re-index. Put a real number on a pilot slice before committing the whole corpus. If the indexing bill is the blocker, look at cheaper graph-retrieval variants such as LightRAG rather than assuming full community-summary GraphRAG is free.
When should you use GraphRAG?
GraphRAG earns its indexing cost when questions need relationships or corpus-wide synthesis that top-k chunk retrieval cannot assemble — and it does not earn that cost on simple single-passage lookups.
- Use it for connect-the-dots and multi-hop questions — answers that require traversing shared attributes across documents. Microsoft’s GraphRAG docs call out baseline RAG’s failure to “connect the dots” as a primary motivation.
- Use it for global / thematic questions — “What are the main themes?” over a private corpus. Edge et al. (2024) designed GraphRAG for that query-focused summarisation class on corpora around the 1 million token scale.
- Use it in entity-rich domains — organisations, supply chains, scientific literature, legal networks — where named entities and typed relationships are the natural unit of retrieval (Stackviv, Jul 2026; Brian Curry, Feb 2026).
- Skip it for single-passage facts and entity-poor text — phone-number lookups, small FAQs, and uniform docs without stable entities. DataCamp’s rule: start with standard RAG and move to GraphRAG when you hit those limits. Brian Curry and Stackviv state the same: vector RAG stays faster and cheaper when one chunk holds the answer.
Choosing between a pure knowledge graph, vector RAG, and a hybrid is a separate decision — covered on RAG vs knowledge graphs. Prove the lift on your own multi-hop and global questions; do not crown GraphRAG from a vendor demo.
What failure does GraphRAG prevent?
GraphRAG exists mainly to prevent two failures of single-shot vector retrieval: missing the second document in a multi-hop chain, and answering a corpus-wide question from a handful of similar chunks that never represented the whole dataset.
Microsoft’s docs describe the first as baseline RAG struggling to connect disparate pieces through shared attributes; Edge et al. (2024) describe the second as global sensemaking that ordinary RAG treats like ordinary retrieval. The symptom side — hop-miss versus composition miss on labelled evidence — is diagnosed on multi-hop RAG failures. Architectures that fix multi-hop without a graph (iterative retrieve-and-reason, query decomposition) live on multi-hop RAG. GraphRAG changes the index so relationships and community structure are first-class; it does not fix incomplete entity extraction or a missing source document.
How do you implement GraphRAG?
You implement GraphRAG by choosing a graph-construction path — Microsoft’s open-source library for community-summary global search, or a graph database plus vector entry points for neighbourhood retrieval — then measuring the same multi-hop and global questions against plain vector RAG.
As of July 2026, the widely cited reference implementation is Microsoft’s GraphRAG library (github.com/microsoft/graphrag, docs at microsoft.github.io/graphrag). Neo4j’s GenAI GraphRAG guides and LangChain/LlamaIndex property-graph retrievers cover the broader extract-and-traverse family without requiring Leiden community summaries. If you also keep a dedicated vector layer for chunk entry points, common stores include Weaviate, Pinecone, Qdrant and Milvus — the graph still owns relationships. Runnable, pinned builds belong on building the pipeline; Microsoft package depth on Microsoft GraphRAG; lower-cost dual-level graph retrieval on LightRAG.
What is GraphRAG?
GraphRAG is retrieval-augmented generation over a knowledge graph of entities and relationships — often with community summaries — instead of ranking similar text chunks alone. The name also refers specifically to Microsoft Research’s Edge et al. (2024) pipeline in the microsoft/graphrag library, which adds Leiden community detection and community summaries for local and global search.
How does local search differ from global search in GraphRAG?
Local search finds entities in the question and fans out to their graph neighbourhood, related text, and nearby community context — best for entity-specific questions. Global search runs a map-reduce over precomputed community summaries to answer corpus-wide or thematic questions. Local is usually cheaper at query time; global scales with how many community summaries the model must read.
How expensive is GraphRAG compared with vector RAG?
GraphRAG costs more mainly at indexing: each text unit needs an LLM call for entity extraction, and community summaries need further LLM calls before any query runs. At query time, local search stays relatively cheap while global search scales with community count. Exact dollars depend on your models and corpus — measure a pilot slice rather than trusting a blog total.
When is vector RAG enough instead of GraphRAG?
Vector RAG is enough when answers live in a single passage, the corpus is small or entity-poor, and you are not asking thematic corpus-wide questions. DataCamp and other practitioner guides recommend starting with standard RAG and adopting GraphRAG only after those limits show up on your own eval set.
Does GraphRAG use vector embeddings?
Yes in typical stacks. Embeddings usually locate starting entities or community summaries; the graph then supplies neighbourhood traversal and community context. GraphRAG extends retrieval with structure — it does not replace the vector index for entry-point search.