GraphRAG: How It Works and When to Use It

Documentation verified on 26 October 2026 against Microsoft's GraphRAG docs, its repository, and the Neo4j and LlamaIndex documentation. The comparison below is an analysis of their documented mechanisms, not a performance test. The product-feedback examples are illustrative.

What Is GraphRAG?

Microsoft GraphRAG prepares an overview of your collection before someone asks for one. It uses a large language model, or LLM, to extract entities and relationships from documents, groups connected entities into communities, and generates summaries of those communities. Its query engine can then use those structures to answer questions. Microsoft's overview describes the method and its main retrieval modes.

An entity is something named in your data, such as a customer, product, person or project. A relationship connects entities: a customer uses a product, a project depends on a service. Together, these form a knowledge graph. A community is a cluster of connected entities; its summary describes what is going on in that part of the collection.

Think of a document collection as a campus. Vector search finds rooms whose contents resemble your question. Graph relationships connect the rooms. Community summaries provide an overview from the upper walkways. When you ask what is happening across the campus, collecting a handful of similar rooms can miss entire wings.

That is the problem behind a familiar failure: your retrieval-augmented generation app, which supplies retrieved evidence to a model before it answers, correctly finds the export policy but gives a shallow answer to “What frustrates customers across all these interviews?” The second question needs coverage across the collection. There may be no passage that directly states the answer.

“Graph RAG” also describes a broader family of retrieval systems that use graphs. This piece focuses on Microsoft's implementation. A graph-backed application from another framework does not automatically build Microsoft's community reports or use its global-search method.

How Does GraphRAG Work?

The important change happens during indexing: GraphRAG creates derived descriptions of your data that later queries can reuse. Microsoft's standard indexing method uses LLMs for extraction and summarization, while graph clustering supplies the community structure.

The process has a practical dependency chain:

1. Split documents into text units. These are chunks of source text. Their links back to documents provide provenance, meaning a way to trace an extracted item to its source.
2. Extract entities and relationships. The LLM reads each text unit and describes the entities and connections it finds.
3. Consolidate the graph. Descriptions for matching entities and relationships are combined and summarized. The documented merge rules use entity title and type, and relationship source and target.
4. Find communities. Hierarchical Leiden, a graph-clustering algorithm, groups connected entities at different levels of detail.
5. Write community reports and embeddings. The LLM summarizes communities. Searchable artifacts also get embeddings, numerical representations used for similarity search.

Those steps follow Microsoft's indexing dataflow. Claim extraction is an optional additional workflow and is off by default. You do not have to extract claims to build the standard graph and reports.

For a product-feedback collection, an interview might mention the Atlas project, export failures and an approval process. Another conversation might connect Atlas to a shared workspace. If extraction captures those links, community reports can bring related concerns together even when the documents use different wording.

The weak point is also visible here. If extraction misses a relationship, merges different entities, or separates aliases that should refer to the same entity, later summaries inherit that distorted structure. A neatly connected graph is still an interpretation of the text.

Microsoft stores the default index outputs as Parquet tables, a column-oriented file format, and writes embeddings to the configured vector store. A separate graph database is not required by that default layout. Indexing overview.

Global, Local, DRIFT and Basic Search

Choose the query mode by the evidence the answer needs. Global search addresses patterns across the collection; local search starts around relevant entities. The other modes provide broader exploration or a vector baseline.

Global Search: Themes Across the Collection

Global search is the central reason to evaluate Microsoft GraphRAG for “What are the main themes across all these documents?” It uses community reports from a chosen level of the hierarchy as the material for an answer.

The method is map-reduce: process batches separately, then combine their results. In the map stage, report batches produce partial answers with rated points. The reduce stage selects useful points and turns them into a final answer. More detailed community reports can increase both answer detail and the resources needed. Global-search documentation.

For a product lead reviewing customer feedback, the intended payoff is broader coverage: onboarding, approvals and collaboration might each contribute to the answer. Simply increasing the number of similar passages retrieved does not ensure those different areas are represented.

The boundary matters: global search synthesizes reports. It is not an exact count of how many customers mentioned each problem. If the decision needs a frequency ranking, use a counting procedure with explicit units and deduplication, then let a model explain the results.

Local Search: An Entity and Its Surroundings

Local search fits a question such as “How is the Atlas project connected to export problems?” It finds semantically related entities, collects connected graph information and associated source passages, and filters that material to fit the answer's context window. Local-search documentation.

This is useful when the answer depends on relationships scattered across documents. The graph provides entry points and connections; the original passages provide supporting detail. Local search still uses similarity matching and a bounded context, so it cannot promise every relevant relationship will appear.

DRIFT Search: Explore From Broad Context

DRIFT starts with relevant community information and develops follow-up questions that use local search. It fits exploratory questions where the first broad answer reveals more specific lines of investigation. DRIFT documentation.

For example, “Why is collaboration difficult for these customers?” may lead to separate investigations of approvals, shared ownership and export handoffs. Evaluate whether those extra searches uncover useful evidence before making DRIFT the default for routine questions.

Basic Search: Keep the Baseline

Basic search retrieves similar text chunks using vector search. Microsoft includes it to make comparisons across query types easier. It is a useful control for a narrow question such as “What does the export policy say?” Query-engine documentation.

GraphRAG vs RAG: Compare the Question and the Index

Keep the simplest retrieval approach that covers the question reliably. The comparison below separates question fit, indexing work and maintenance. These are architectural judgments, not measured cost or speed rankings.

Hybrid search addresses a different failure from global synthesis. Microsoft's hybrid-search documentation describes combining full-text and vector results. If your app misses an exact product code, start with hybrid search. A global community summary is an indirect fix for a lexical retrieval problem.

Agentic RAG changes the search workflow. A model may choose retrieval, judge relevance, rewrite the question and search again, as demonstrated in LangGraph's agentic retrieval tutorial. Use agentic RAG when the app needs to decide what evidence to gather next.

These approaches can combine. An agent can call a graph retriever, and a graph-backed retriever can begin with hybrid search. The decision is which additional mechanism solves an observed failure. Adding all of them at once makes that harder to establish.

Why GraphRAG Indexing Does More Work

Standard GraphRAG adds generative processing to the embedding work of a plain vector index. There is no defensible universal multiplier to apply to your document count: the work depends on the text, extraction configuration, graph and reports you generate.

A useful planning model is:

Indexing work = chunk processing + extraction passes + description summaries + community reports + embeddings.

This is an accounting model for your pilot, not a vendor price formula. Track the work by stage so you can see what grows when you add data.

Chunks determine repeated extraction work. More chunks mean more text units to analyze. Chunk size and overlap change how much repeated context the extractor sees. Microsoft's configuration also exposes max_gleanings, which controls additional extraction cycles. Do not assume every chunk always costs exactly one LLM call. Configuration reference.

Graph size determines downstream material. A collection with many distinct entities and relationships can produce more descriptions to consolidate than a similarly sized collection about a narrow topic. Repeated mentions create descriptions to merge; diverse connections shape the communities that need reports. This follows from the extraction and summarization stages, rather than from document count alone.

Reports add another generation workload. Community contents must be summarized, and the hierarchy creates different levels of overview. Embeddings remain part of the index too. The standard method's task list is the right starting point for identifying these drivers.

Cache reuse can avoid repeated model work. Microsoft caches LLM invocation results for subsequent indexing runs. Measure a fresh build and an update separately; a cached rerun does not tell you what a new collection will require. Cache configuration.

Query work is a separate budget. Global map-reduce and DRIFT exploration can involve multiple model operations after indexing is complete. A successful indexing pilot does not establish acceptable answer latency.

Fresh Documents Can Still Produce Stale Themes

A document arriving in storage does not make the reports used by global search current. Your freshness target must cover the derived index that the query actually reads.

Microsoft provides graphrag update; the current CLI describes writing the new index to update_output by default. Its configuration also provides separate update storage to preserve existing outputs. So incremental updating exists, but an update command alone is not a complete synchronization policy. CLI reference, update storage.

Consider a support conversation that corrects an earlier claim about Atlas. The new document may be present while a deployed community report still describes the old situation. That is a maintenance failure even if a direct lookup can find the correction.

Test additions, corrections and deletions against the exact version and configuration you deploy. Check source chunks, extracted relationships and both local and global answers. The cited CLI documentation does not establish that every mutation automatically propagates with the semantics your application needs.

For operators, the practical requirement is a visible index version and a known source cutoff. Publish a consistent set of artifacts, then point queries at that version. If the business needs immediate answers from rapidly changing records, keep a direct retrieval route available while you evaluate the report-refresh process.

Two Other Graph-RAG Routes

Neo4j and LlamaIndex offer graph retrieval building blocks with different choices about extraction, storage and querying. Evaluate the mechanism their documentation describes instead of treating “GraphRAG” as one interchangeable product.

Neo4j for GraphRAG

Neo4j GraphRAG for Python includes VectorCypherRetriever: it first finds similar nodes, then executes a retrieval query to collect additional context. Cypher is Neo4j's graph query language. The package also offers hybrid retrieval using vector and full-text indexes, and Text2Cypher for translating a question into a database query. Neo4j's retriever guide.

This route fits a builder who wants explicit control over which relationships to follow after finding a relevant node. For example, retrieve a project and then fetch its linked dependencies through a defined graph query.

Neo4j's graph-construction tooling also supports LLM entity and relationship extraction, writing the graph and resolving duplicate entities. Its docs describe extraction-error handling that can ignore failing chunks unless configured otherwise. Check ingestion completeness as well as whether the query runs. Knowledge Graph Builder guide.

The boundary: vector search followed by a graph query does not, by itself, produce Microsoft's hierarchy of community reports. If broad thematic summaries are your requirement, specify how that layer will be built.

LlamaIndex Property Graphs

LlamaIndex's PropertyGraphIndex orchestrates graph construction and retrieval. A property graph holds labeled entities, their attributes and their relationships. Its extractors run on chunks; SchemaLLMPathExtractor can restrict extraction to allowed entity and relationship patterns. VectorContextRetriever finds embedded graph nodes and retrieves connected paths, with source text available through the retrieval options. Property graph guide.

This route fits a builder who wants configurable extractors and retrievers inside an application framework. The documented insertion, upsert and deletion operations offer components for maintaining the graph; the application still needs a policy for source changes and derived facts.

The boundary: available operations depend on the graph store. The default SimplePropertyGraphStore is not a graph database and does not support Cypher. Choose storage and retrieval together. A property-graph index also should not be assumed to include Microsoft's global summarization workflow.

GraphRAG Tutorial: Evaluate the Failure You Have

Start with a bounded collection and questions whose answers you can review. Microsoft's repository warns that indexing can be expensive, and its getting-started guide recommends learning on a small dataset before committing to a large job.

Once the workspace and credentials are configured, these commands use the current documented CLI syntax:

graphrag index --method standard
graphrag query "What are the main themes across these documents?" --method basic
graphrag query "What are the main themes across these documents?" --method global

The query is a positional argument in the current CLI reference.

Judge the output on coverage and support together. An answer that lists more themes but invents connections has not solved the problem. Ask a reviewer to trace each important theme to evidence, note which expected themes are missing, and check whether distinct groups were collapsed into a convenient generalization.

For builders, adopt the graph only if it fixes the failing question class while preserving acceptable lookup behavior. For operators, require a refresh procedure that survives corrections and removals. For buyers commissioning a system, ask for those same demonstrations on representative documents before accepting a graph visualization as proof of better answers.

If the evidence is already present but the model repeatedly uses the wrong format or behavior, revisit RAG vs fine tuning. A more elaborate index addresses evidence access; it is not automatically the right intervention for every generation failure.

What Is Overhyped?

The strongest claim you can make is narrower than “graphs make RAG better”: a particular graph and query method can improve a particular kind of evidence gathering.

Connections do not certify truth. Extracted relationships and community reports can be wrong. Treat them as searchable interpretations and preserve the source trail. A graph path can make retrieval easier to inspect without proving that its underlying assertion is correct.

More connected answers are not necessarily more complete. A broad-looking summary may still omit an isolated concern. Include minority themes and awkward exceptions in the review set, especially if they could change a product decision.

A community summary is not a frequency table. Repeated mentions, entity connectivity and a model's assessment of importance are different from counting unique customers. Define the unit of analysis before claiming a theme is the most common.

The repository is not a managed Microsoft service. Microsoft's repository guidance describes the code as a demonstration of the methodology rather than an officially supported Microsoft offering. Deployment, monitoring and data-refresh responsibilities still need an owner.

Questions About GraphRAG

What to Do Next Week

Take the thematic question your app currently answers poorly and identify the evidence a good answer would need across the collection. Build a small GraphRAG evaluation around that failure, keeping your existing retriever as the control.

Act now if collection-wide synthesis is a recurring product requirement and someone can own the derived index. Wait if the corpus changes faster than you can validate the reports, or if no one can judge whether a thematic answer is complete. Keep the current design if your workload is predominantly reliable factual lookup. The useful outcome is a justified retrieval decision, whether or not the graph stays.

For practical guides to building AI systems, join the newsletter.