GraphRAG Architecture: Knowledge-Graph RAG for Enterprise LLMs

Ask a vector-search RAG system “What are the main themes across these 3,000 incident reports?” and it will confidently summarize the twenty chunks that happened to sit closest to your question. It cannot do better, because the answer is not located in any chunk. It lives in the structure of the whole corpus. That gap is exactly what GraphRAG architecture was designed to close, and it is also why GraphRAG is often oversold as a replacement for ordinary retrieval.

In 2026 the picture is clearer than it was at launch. Microsoft’s reference implementation has stabilized on a 3.x line and, according to its package page, is now in maintenance mode. Cheaper variants such as FastGraphRAG, LazyGraphRAG, LightRAG, and HippoRAG 2 have matured. Independent benchmarks now show where graphs help and where they quietly lose to a good vector index.

This guide dissects the full pipeline, from entity extraction to Leiden communities to map-reduce global search, then compares the major open implementations and gives a decision framework. You will leave knowing what to build, what it costs, how to evaluate it, and when to skip it.

What this covers: the failure modes of flat RAG, the GraphRAG indexing and query pipeline, search modes, a comparison of Microsoft GraphRAG, LightRAG, and HippoRAG, costs, evaluation, and a decision tree for production.

Context and Background

Retrieval-augmented generation grounds a language model in your own documents. The standard recipe is simple: split documents into chunks, embed each chunk, store the vectors, and at query time fetch the nearest chunks to place in the prompt. It is fast, cheap, and strong at what it targets, namely questions whose answer sits inside one or two passages. If you want a deeper treatment of production vector stores, our pgvector vs Qdrant vs LanceDB comparison covers the storage side.

The trouble starts when the question is not about a passage. There are three recurring failure shapes.

Global questions. “What are the top themes?” or “How has our strategy evolved?” are summarization tasks over the whole corpus. Top-k retrieval returns a biased sample, and no amount of tuning k fixes a question whose answer is an aggregate. The original GraphRAG paper frames this precisely as the gap between retrieval-augmented generation and query-focused summarization.

Multi-hop questions. “Which suppliers are affected by the regulation cited in the Q3 compliance report?” requires chaining regulation to supplier to status. Each hop may live in a different document, and the second hop’s search terms are unknown until the first hop resolves. Embedding similarity to the original question will not surface the bridging passage.

Entity disambiguation. Embeddings blur distinctions that matter to a business: which “Acme” acquired which company, who reports to whom, which part number supersedes another. A graph stores typed edges explicitly, so these distinctions survive indexing.

Microsoft Research published the approach in “From Local to Global: A Graph RAG Approach to Query-Focused Summarization” (Edge et al., arXiv 2404.16130, first submitted April 2024 and revised February 2025). Its core idea is a two-stage index: first derive an entity knowledge graph from the source documents, then pregenerate summaries for communities of closely related entities. At query time, partial answers are produced from relevant community summaries and then combined into a final response. You can read the original at the arXiv abstract page.

Since then, the field has split into three families. Microsoft’s pipeline is the summary-centric one. LightRAG (Guo et al., arXiv 2410.05779) trades the community hierarchy for a dual-level retrieval scheme and incremental updates. HippoRAG (Gutiérrez et al., arXiv 2405.14831) borrows from hippocampal memory theory and uses Personalized PageRank for multi-hop retrieval. Understanding which family fits your workload is the central decision, and it is easier to make once you see the mechanics of the reference design.

A final piece of context: graph methods are one tool in a broader retrieval toolbox. Agents that plan and iterate over several retrievers, covered in our agentic RAG architecture guide, often use a graph index as one of several tools rather than the only one.

The GraphRAG Reference Architecture

GraphRAG builds an offline index in six steps: chunk documents into TextUnits, have an LLM extract entities and relationships, merge duplicates, cluster the graph hierarchically with the Leiden algorithm, write an LLM summary report for every community, and embed the results. At query time it routes to basic, local, global, or DRIFT search.

Figure 1: The GraphRAG indexing pipeline. Documents become TextUnits, then a typed knowledge graph, then hierarchical communities with LLM-written reports. Three kinds of text are embedded for later retrieval.

The figure shows the offline half of the system. Raw documents flow left to right through extraction, consolidation, clustering, and summarization, and the outputs land in a set of tables plus a vector store. Two things are worth noticing. First, the LLM touches the data three times (extraction, description merging, report writing), which is why indexing dominates the bill. Second, three different text types get embedded, which is what lets different query modes enter the graph from different doors.

Phase 1: TextUnits and extraction

The documentation describes six phases in the default dataflow: compose TextUnits, process documents, extract the graph, augment the graph with communities, summarize communities, and embed text. The first step chunks documents into TextUnits. The current default is 1,200 tokens per unit, whereas the original paper used 600-token chunks with 100-token overlap on its test corpora. That difference is not cosmetic. Larger chunks mean fewer LLM extraction calls but a higher chance that the model skips entities in a dense passage, which is why the paper also discusses multiple “gleaning” passes that ask the model whether it missed anything.

For each TextUnit, an LLM is prompted to emit entities with a title, a type, and a description, plus relationships with a source, a target, and a description. Optionally it extracts claims, which are factual statements attached to entities, such as “Company X was fined in 2023”. The prompts are domain-tunable, and the project’s prompt tuning guide exists because default entity types (person, organization, place, event) are wrong for most enterprise corpora. An industrial maintenance corpus needs entity types like asset, failure mode, work order, and spare part, or the graph will be technically correct and practically useless.

Phase 2: Merging and summarizing descriptions

The same entity appears in hundreds of TextUnits, each with a slightly different description. GraphRAG merges entities that share a title and type, collecting their descriptions into an array, and then asks the LLM to produce one short summary that captures all the distinct information. Relationships are merged the same way. This is the step that turns noisy mentions into a graph node with a coherent identity.

It is also the weakest link. Exact-match merging means “IBM”, “International Business Machines”, and “Big Blue” can remain three nodes. Production teams add an entity resolution pass, either with alias dictionaries from a master data system or embedding-plus-LLM clustering, before the graph is trusted. Treat this as a design requirement, not an optimization.

Phase 3: Hierarchical Leiden communities

With the graph assembled, GraphRAG applies the hierarchical Leiden algorithm recursively until communities fall under a size threshold. The result is a tree: broad communities at the top, tight clusters at the leaves. In the paper’s experiments, the community levels were labeled C0 through C3, with C0 as the root level and higher numbers as finer partitions.

Why Leiden rather than the older Louvain? Traag, Waltman, and van Eck showed in “From Louvain to Leiden: guaranteeing well-connected communities” (Scientific Reports, 2019) that Louvain can yield arbitrarily badly connected communities. In their experiments, up to 25 percent of communities were badly connected and up to 16 percent were disconnected entirely. Leiden adds a refinement phase that guarantees connected communities and runs faster on large networks. For GraphRAG this matters directly: a disconnected community would force the LLM to write one report about two unrelated topics. The paper is available at Nature Scientific Reports.

An important caveat: Leiden optimizes graph structure, not semantics. A community is a set of densely linked nodes, and density in an extracted graph reflects how often entities co-occur in the text, which is a proxy for relatedness. When extraction is noisy, communities inherit the noise.

Phase 4: Community reports and embeddings

For each community at each level, the LLM writes a report: an executive overview that references the key entities, relationships, and claims. Lower-level reports are summarized upward, so the hierarchy is built bottom-up. These reports are the artifact that makes global questions answerable. A question about dataset-wide themes can be answered by reading a few dozen reports instead of a million tokens of source text.

The paper quantifies this. Root-level community summaries used between 9 and 43 times fewer tokens than approaches that summarize source text directly, and over 97 percent fewer tokens than full source-text summarization on the tested corpora. That is the economic argument for the whole design: you pay once at indexing time to compress the corpus into reusable summaries.

Finally, the pipeline embeds entity descriptions, TextUnit content, and community report text, writing them to a configured vector store. Output tables include documents, entities, relationships, communities, and community reports, stored as Parquet files by default. That tabular output is deliberately portable: you can load the same tables into a graph database, a lakehouse, or a notebook.

What the graph looks like at scale

The paper gives concrete sizes. On its podcast transcript corpus of roughly one million tokens (1,669 chunks), the extracted graph had 8,564 nodes and 20,691 edges. On the news corpus of about 1.7 million tokens (3,197 chunks), it had 15,754 nodes and 19,520 edges. The authors report a 281-minute indexing time for the podcast dataset using GPT-4-turbo. These numbers are from 2024-era models and endpoints, so treat the minutes as a historical anchor rather than a benchmark for today’s hardware or APIs. The shape still holds: nodes scale with the number of distinct entities, edges with co-occurrence, and the LLM bill with the token count of the source.

Query-Time Architecture: Four Ways Into the Graph

The index is only half the system. GraphRAG ships four query modes, each entering the structure through a different door. Choosing the right one per question, rather than defaulting to one, is where much of the quality comes from.

Figure 2: Query routing in a knowledge graph RAG system. A router classifies the question and sends it to basic, local, global, or DRIFT search before a final synthesis step.

The diagram shows a classifier (an LLM prompt, a rules layer, or the user’s own choice) in front of four retrieval strategies that all converge on a synthesis call. In practice, the router is the component teams forget to build, and its absence is the commonest reason a GraphRAG deployment feels worse than the demo.

Basic and local search

Basic search is plain vector similarity over TextUnits, kept in the package precisely because many questions need nothing more. Local search starts from entities. The query is embedded, matched against entity descriptions, and the retrieval context is assembled from the matched entities, their neighbors and relationships, the community reports they belong to, and the original TextUnits that mention them. That fan-out is what makes multi-hop questions workable: the LLM receives the connecting edges explicitly instead of hoping the bridging passage ranked in the top ten.

Local search is the workhorse for questions like “What is the relationship between Vendor A and the 2023 recall?” It costs one retrieval pass and one generation call, so latency and price are close to vector RAG, plus the extra context tokens from the neighborhood.

Global search: map-reduce over community reports

Global search answers dataset-wide questions. The documentation describes a two-stage map-reduce. In the map phase, community reports are segmented into chunks of a fixed size, and each chunk produces an intermediate response containing points rated by importance. In the reduce phase, the highest-rated points are aggregated into the context for the final answer.

Figure 3: GraphRAG global search as a map-reduce. Every report chunk costs one LLM call in the map step, which is why the hierarchy level you choose drives both quality and spend.

The sequence shows why global search is the expensive mode. The number of map calls equals the number of report chunks at the chosen level, so cost scales with the size of the index, not with the question. The documentation is explicit about the knob: lower hierarchy levels have more detailed reports and tend to yield more thorough responses, but they increase the time and LLM resources needed. Higher levels are faster but potentially less thorough. A max_data_tokens parameter bounds the context size.

This is the architecture’s defining trade-off. You can ask “What are the top five themes?” and get a good answer, but each such question may trigger dozens or hundreds of LLM calls. For an interactive product, teams typically cache answers to common global questions, run global search at a coarse level by default, and expose finer levels only to analysts.

DRIFT search: local with a global primer

DRIFT, introduced in a Microsoft Research blog post, combines the two. It begins with a primer step that compares the query to the top K most semantically relevant community reports, producing an initial answer plus follow-up questions, using Hypothetical Document Embeddings to improve recall. It then executes each follow-up with local-search variants in a refinement loop; the post says the termination criterion is currently two iterations. The output is a hierarchy of questions and answers ranked by relevance.

Microsoft’s reported evaluation compared DRIFT to GraphRAG’s own local search on 50 local questions generated from more than 5,000 Associated Press articles: DRIFT won on comprehensiveness 78 percent of the time and on diversity 81 percent of the time. Note the narrow comparison. It beats local search, not a tuned hybrid vector pipeline, and the question set is small. Treat it as directional evidence.

What the original evaluation actually showed

The headline results from the 2024 paper deserve a careful reading because they are quoted loosely. Against a naive vector RAG baseline, the Graph RAG approach won on comprehensiveness with rates of 72 to 83 percent on the podcast corpus and 72 to 80 percent on the news corpus, and on diversity with 75 to 82 percent and 62 to 71 percent respectively. Judging was done by an LLM against criteria the authors defined.

Two caveats matter for engineers. First, the questions were global sensemaking questions, the case GraphRAG is built for. Second, on the control criterion of directness (specificity and clarity), vector RAG gave the most direct answers across all comparisons, and the empowerment criterion showed mixed results. In plain terms: graphs help you say more, not necessarily say it more precisely. If your users want a number from a table, comprehensiveness is not what they are buying.

Indexing modes and their economics

The project’s own warning is blunt: GraphRAG indexing can be an expensive operation, so read the documentation and start small. Two indexing methods exist. Standard indexing uses the LLM for entity extraction, relationship extraction, description summarization, optional claims, and community reports. Fast indexing replaces some of that with classical NLP: entities are noun phrases found with libraries such as NLTK and spaCy, relationships come from co-occurrence within text units, and the description-summarization step is skipped. Community reports are still LLM-generated.

According to the documentation, graph extraction accounts for roughly 75 percent of indexing cost, so the fast method is substantially cheaper. The trade is quality of the graph: the docs state that the extracted graph is less directly useful outside GraphRAG and tends to be noisier. They position fast indexing as well suited to summary-focused queries and standard indexing as preferable when graph exploration and fidelity matter.

LazyGraphRAG pushes the idea further. Microsoft’s research blog describes it as deferring all LLM use to query time: indexing uses NLP noun phrase extraction to build a concept co-occurrence graph, with data indexing costs the post says are identical to vector RAG and 0.1 percent of the cost of full GraphRAG. For global queries it reports comparable answer quality to GraphRAG Global Search at more than 700 times lower query cost, and at a higher budget it reports strong results at 4 percent of global search’s query cost. The cost-quality dial is a single “relevance test budget”. These are vendor-published results from the project team; verify them on your own corpus before you commit.

Comparing GraphRAG, LightRAG, and HippoRAG

Three open designs dominate practice. They share the premise that a graph should mediate retrieval, but they make different bets about what to precompute.

Microsoft GraphRAG: precompute summaries

GraphRAG bets that most hard questions are summarization questions and pre-pays to build community reports. Strengths: the best story for global, thematic questions; a mature CLI, configuration, prompt tuning, and Parquet outputs; four query modes; an MIT license. Weaknesses: indexing cost, re-indexing pain when documents change, and a pipeline tuned for batch rather than streaming data.

On maintenance status, the PyPI page for the graphrag package lists version 3.2.0 released September 23, 2026, requires Python 3.11 through 3.13, and states that the project is largely in maintenance mode, accepting bug fixes and security updates but no new features. Whether the repository’s state has since changed is worth checking before you commit. The practical reading: use it for what it does well and expect new ideas to come from the research community and from forks rather than from this codebase.

LightRAG: dual-level retrieval and incremental updates

LightRAG’s abstract describes a dual-level retrieval system that captures both low-level (specific entity details) and high-level (conceptual) knowledge, graph structures combined with vector representations, and incremental updates so new data can be integrated without a full rebuild. It skips the community-report hierarchy; keywords from the query are matched against entities and relationships, then the neighborhood is expanded.

The incremental update property is the practical differentiator for enterprises whose documents change daily. The license is worth reading closely: the project’s repository is released under Creative Commons BY-NC-SA 4.0 according to the paper’s abstract page, and a non-commercial share-alike license could constrain commercial use. Check the current repository license directly, because licensing can change between versions and I could not confirm it for a specific release.

HippoRAG and HippoRAG 2: memory-inspired multi-hop

HippoRAG’s abstract describes orchestrating LLMs, knowledge graphs, and the Personalized PageRank algorithm to mimic the roles of the neocortex and hippocampus. At indexing, an LLM performs open information extraction to build a schemaless graph. At query time, entities in the question seed a Personalized PageRank walk, which spreads relevance along graph paths and ranks passages by it. The authors report up to 20 percent improvement over state-of-the-art methods on multi-hop question answering, and results comparable to iterative retrieval while being 10 to 30 times cheaper and 6 to 13 times faster.

HippoRAG 2, titled “From RAG to Memory: Non-Parametric Continual Learning for Large Language Models” (Gutiérrez et al., arXiv 2502.14802), addresses a known weakness: structure-heavy methods often lose to plain RAG on simple factual tasks. It keeps Personalized PageRank, adds deeper passage integration and better LLM use during retrieval, and reports a 7 percent improvement on associative memory tasks over a state-of-the-art embedding model while retaining factual performance.

Side-by-side decision matrix

Dimension	Microsoft GraphRAG	LightRAG	HippoRAG 2	Plain hybrid RAG
Core bet	Precomputed community reports	Dual-level entity and relation retrieval	Personalized PageRank over a graph	Chunks plus embeddings plus BM25
Best question type	Global, thematic	Mixed local and conceptual	Multi-hop, associative	Single-fact lookup
Index cost	High (standard), lower (fast)	Moderate to high	Moderate	Low
Incremental updates	Painful, re-index likely	Designed for it	Supported by design (verify per release)	Trivial
Query latency	Slow for global (map-reduce)	Low to moderate	Low	Lowest
Maturity signal	Maintenance mode, 3.2.0	Active research repo	Active research repo	Everywhere
License	MIT	CC BY-NC-SA 4.0 per paper page (verify)	Check repository	N/A

Use the matrix as a starting filter, not a verdict. The point of the last column is that every graph method should be justified against it.

What independent benchmarks say

GraphRAG-Bench (Xiang et al., arXiv 2506.05690, last updated February 2026) was built because, in the authors’ words, GraphRAG frequently underperforms vanilla RAG on many real-world tasks. It grades tasks from fact retrieval through complex reasoning, contextual summarization, and creative generation, and evaluates 11 GraphRAG frameworks end to end including MS-GraphRAG, HippoRAG, HippoRAG2, LightRAG, RAPTOR, and Fast-GraphRAG.

The pattern is the one a first-principles analysis predicts. On simple fact retrieval, traditional RAG matches or beats graph methods; one reported figure is vanilla RAG’s evidence recall of 87.83 percent on such tasks. On complex reasoning, graph methods lead, with HippoRAG reaching evidence recall of 87.9 to 90.9 percent on multi-hop questions, and on a medical dataset HippoRAG2 scored 61.98 percent accuracy on complex reasoning against vanilla RAG’s 58.64 percent. Note the size of that margin: about three points. It is real and also modest.

The same study shows the cost side. MS-GraphRAG global search prompts reach up to about 4 x 10^4 tokens, LightRAG around 10^4, and HippoRAG2 about 10^3. Graph construction overhead varied widely across methods, from tens of seconds for a lightweight method to more than 700 seconds for LightRAG in their setup. A separate unified study, “RAG vs. GraphRAG: A Systematic Evaluation and Key Insights” (Han et al., arXiv 2502.11371), reaches the same conclusion from another angle: RAG and GraphRAG have distinct strengths, and selecting or combining them improves results consistently. The reliable takeaway is routing, not replacement.

Building It: A Practical Walk-through

Theory aside, here is how a team should stage a GraphRAG project so that the expensive part is earned, not assumed.

Step 1: Prove you have a graph-shaped problem

Before indexing anything, collect 30 to 50 real user questions and tag each as single-fact, multi-hop, or global. If more than about 80 percent are single-fact, stop and invest in hybrid retrieval and reranking instead. Our RAG evaluation metrics guide explains how to score faithfulness and context quality so this comparison is quantitative rather than anecdotal.

Step 2: Index a slice, not the corpus

The project’s own advice is to start small. Take roughly 1 to 5 percent of the corpus, chosen to include documents that your hard questions depend on, and run both indexing modes. The commands below are the documented entry points; the query command follows the documented CLI pattern but confirm the exact flags against the version you install.

# Initialize a workspace (re-run init with --force between minor versions
# when the configuration format changes, per the docs)
graphrag init --root ./kg_pilot

# Standard: LLM does extraction, description merging, community reports
graphrag index --root ./kg_pilot --method standard

# Fast: NLP noun phrases and co-occurrence, LLM only for community reports
graphrag index --root ./kg_pilot --method fast

# Query modes (verify flags for your installed version)
graphrag query --root ./kg_pilot --method local  --query "How is Vendor A tied to the 2023 recall?"
graphrag query --root ./kg_pilot --method global --query "What are the main supply risks?"

Run the same question set against both indexes and against your vector baseline. Track answer quality, tokens per query, and p95 latency together. A graph that wins by three points but triples cost per query may still be right for an analyst tool and wrong for a customer chatbot.

Step 3: Tune the extraction schema

This is where enterprise projects are won. Replace default entity types with ones from your domain, add few-shot examples of correct extractions, and review a sample of 100 extracted triples by hand. Count three error classes: missed entities, wrong types, and hallucinated relationships. If hallucinated relationships exceed a few percent, tighten the prompt or move to a stronger extraction model before you spend on community reports, because every downstream layer amplifies upstream errors.

Where you already hold structured knowledge, such as an ontology, a product master, or a bill of materials, seed the graph from it rather than asking an LLM to rediscover it. Hybrid construction, where deterministic sources supply the backbone and the LLM extracts from unstructured text onto that backbone, tends to produce cleaner graphs and cheaper indexing. In industrial settings this is a natural fit; see how engineering data models feed language models in our piece on AI-native PLM and LLM engineering data.

Step 4: Add routing and fall-back

Build the router from the earlier figure. A simple and effective version asks a small model to classify each question as fact, relational, or thematic, and sends it to basic, local, or global search accordingly. Log the decisions. After a few weeks of traffic you will know which modes are actually used and can retire the ones that are not.

A rough cost model

The exact bill depends on your model, pricing, and corpus, so use a formula rather than a number. Standard indexing makes roughly one extraction call per TextUnit (more if you glean), a summarization call per entity and relationship with multiple descriptions, and one report call per community. As a back-of-the-envelope illustration, a 10-million-token corpus at 1,200 tokens per TextUnit produces about 8,300 TextUnits. Even if each extraction call costs a few thousand input and output tokens, you are processing tens of millions of tokens before the summarization and report layers add more. That arithmetic is illustrative, not a measurement, but it explains why the documentation says graph extraction is around 75 percent of the indexing cost and why prices from model providers should be plugged in before any pilot.

Query-time cost is the part people forget. Local search is roughly one extra-large prompt. Global search is a fan-out: with N report chunks at the selected level, you pay N map calls plus one reduce. If a corpus yields 500 report chunks at the chosen level, one global question is on the order of 500 LLM calls. That is the number LazyGraphRAG’s “more than 700 times lower query cost” claim is attacking, and it is why caching and level selection are production necessities.

Keeping the graph fresh

Documents change, and a static graph silently ages. There are three strategies. Rebuild nightly or weekly when the corpus is small and the budget allows. Use an incrementally updatable design such as LightRAG, which its authors designed to integrate new data without a full rebuild. Or partition the corpus by time or tenant so a change only invalidates one shard. The Microsoft documentation notes migration notebooks exist for major version bumps to avoid re-indexing, a hint at how much re-indexing hurts. Whichever you choose, store the source TextUnit IDs on every node and edge so stale evidence can be found and removed.

Evaluating the result

Standard RAG metrics apply, with additions. Measure faithfulness (is every claim supported by retrieved evidence), answer relevance, and context recall as in any pipeline. Then add graph-specific checks: entity extraction precision and recall on a hand-labeled sample, community coherence (do reviewers agree a report describes one topic), and citation traceability (can every sentence be traced from a report back to TextUnits).

For global questions, the paper’s approach is useful: pairwise LLM judging on comprehensiveness, diversity, and empowerment, with directness as a control. Run the pairwise comparison in both orders to cancel position bias, and spot-check judge decisions with humans, since an LLM judge can reward verbosity. If you serve answers through a gateway or cache layer, our notes on semantic caching architecture cover how to cache global answers safely.

Choosing: When GraphRAG Wins and When Plain RAG Wins

The decision is not “graph or vector”. It is a sequence of questions about your workload, update rate, and budget.

Figure 4: A decision flow for GraphRAG architecture choice. Most workloads exit at the first question, which routes them to hybrid vector RAG with a reranker.

The figure encodes the evidence from the benchmarks above. If questions are mostly single-fact lookups, hybrid vector RAG wins on cost and often on accuracy. If they are multi-hop or dataset-wide, graphs earn their keep, and the remaining branches depend on update frequency and indexing budget. The leaf names are starting points; a lightweight design such as LazyGraphRAG-style deferral or HippoRAG 2 can also be the right answer at high budgets.

A useful rule of thumb from first principles, labeled as opinion: graph retrieval pays off when the answer requires combining information that no single chunk contains. If one chunk suffices, the graph adds latency and a new failure surface. If five chunks must be joined along relationships, or a hundred must be aggregated, the graph pays for itself.

Trade-offs, Gotchas, and What Goes Wrong

Extraction errors compound. An LLM that invents a relationship creates an edge that local search will present as fact, and a community report that summarizes it will repeat it with authority. Unlike a missing chunk, a wrong edge fails silently. Sample and audit extractions continuously, not just at launch.

Entity resolution is not solved by the pipeline. Exact-title merging leaves aliases split and sometimes merges distinct entities with the same name. Both degrade communities. Budget real engineering time for resolution against a master list.

Global search cost scales with the index. A question that cost cents on a pilot slice can cost dollars on the full corpus, and a chatty user can exhaust a budget. Add per-user quotas, cache, and default to coarse hierarchy levels.

Staleness and re-indexing. Because communities and reports depend on global structure, a small change can alter many summaries. Teams that ignore this ship answers that cite superseded policies. Version your index and expose its build date in the UI.

Access control is harder in a graph. Vector RAG can filter chunks by permission metadata. In a graph, a community report summarizes content from many documents, so a report may leak facts the asking user cannot see. Build separate indexes per permission boundary, or generate reports only from content a role may access. This is the least discussed and most dangerous enterprise gotcha.

Noisy graphs from the fast method. The docs warn that the graph produced by fast indexing is noisier and less useful outside GraphRAG. If you plan to reuse the graph for analytics or exploration, pay for standard extraction.

Benchmarks can mislead. LLM-judged win rates reward long, comprehensive answers. Several studies caution that graph methods help on some tasks and hurt on others. Your own question set beats any published leaderboard, and a pilot that is not scored against a strong vector baseline proves nothing.

Tooling churn. The flagship implementation’s maintenance-mode status, a fast-moving research landscape, and differing licenses mean you should isolate the graph layer behind an interface. If the retriever is swappable, a change of library is a sprint, not a rewrite.

Practical Recommendations

Start by measuring. Label real questions, run a strong hybrid baseline with a reranker, and only add a graph if the multi-hop or global share justifies it. Most teams discover that a third of their questions need the graph and two thirds do not, which is the signal to route rather than replace.

Pilot on a slice with both indexing modes, and put cost per query beside quality in every comparison. Treat the extraction schema as the product: spend your time on entity types, aliases, and seeding from structured sources. Plan updates from day one, choosing between scheduled rebuilds, an incremental design, or sharding. Enforce permissions at the index boundary, not at the prompt.

Finally, keep the architecture modular. Put basic, local, and global retrieval behind one interface so you can swap Microsoft’s pipeline for a lighter or newer design as the field moves.

A short checklist before you ship:

Question set labeled by type, with a vector-plus-reranker baseline scored on it.
Extraction schema tuned, with hand-audited samples and measured error rates.
Entity resolution against a master list or alias table.
Router with logging, plus a fall-back to basic search.
Per-query token and latency budgets, with caching for global answers.
Index versioning, build date visible, and a refresh plan.
Permission-scoped indexes or reports.
Faithfulness and citation-traceability checks in CI.

Frequently Asked Questions

What is GraphRAG and how is it different from regular RAG?

GraphRAG is a retrieval-augmented generation approach that has an LLM extract entities and relationships from documents into a knowledge graph, clusters the graph into communities, and pregenerates summaries of each community. Regular RAG retrieves similar text chunks by vector similarity. GraphRAG can answer dataset-wide and multi-hop questions that chunk retrieval cannot, at the price of heavier indexing and more complex operations.

Is GraphRAG better than vector RAG?

Not universally. Benchmarks such as GraphRAG-Bench report that on simple fact retrieval, vanilla RAG matches or beats graph methods, while graphs win on complex reasoning and summarization tasks. The original paper also found vector RAG produced the most direct answers. The practical answer is to route questions by type and compare against a strong hybrid baseline on your own data.

How expensive is GraphRAG indexing?

It is the dominant cost. Microsoft warns that indexing can be expensive and recommends starting small, and its documentation says graph extraction is roughly 75 percent of indexing cost. Fast indexing replaces some LLM calls with NLP, and LazyGraphRAG reports indexing costs equal to vector RAG. Your bill depends on corpus size, model pricing, and chunking, so run a pilot slice first.

What is the difference between local and global search in GraphRAG?

Local search starts from entities matched to the question and gathers their neighbors, relationships, community reports, and source text, making it suited to specific, relationship-oriented questions. Global search runs a map-reduce over community reports to answer dataset-wide questions such as “what are the main themes”. Global search is more thorough on broad questions but uses many more LLM calls.

Should I use Microsoft GraphRAG, LightRAG, or HippoRAG?

Choose by workload. Microsoft GraphRAG is strongest for thematic, corpus-wide questions with a mature toolchain, though its package page states it is in maintenance mode. LightRAG emphasizes incremental updates and dual-level retrieval, and its license deserves review. HippoRAG 2 targets multi-hop retrieval cheaply with Personalized PageRank. Prototype two on a corpus slice and score them on your questions.

Why does GraphRAG use the Leiden algorithm?

Leiden finds hierarchical communities and, unlike Louvain, guarantees the communities it returns are connected. Louvain can produce badly connected or disconnected communities, which would force an LLM to write one report about unrelated topics. Leiden is also faster on large networks. That connectivity guarantee gives each community report a coherent subject, which is why GraphRAG uses it for hierarchical summaries.