GraphRAG: Entities, Relationships & Global Reasoning

Introduction

Last lesson, knowledge graphs let us answer relationship and multi-hop questions vector search couldn't. But there's an even harder class of question that neither plain vector RAG nor simple graph traversal handles well — the global, whole-corpus question:

"What are the main themes across all these documents?" · "What are the most frequently discussed risks in this report collection?" · "Summarize the key findings of this 1,000-document dataset."

These are query-focused summarization (or sensemaking) questions, and they have a brutal property: the answer isn't in any chunk. No passage is "the main themes" — the themes are an emergent property of the entire corpus. Retrieve-top-k fundamentally can't see them; it grabs 5 trees and misses the forest.

GraphRAG (Microsoft Research, "From Local to Global", 2024) is built for exactly this. In this lesson:

The class of global question vector RAG can't answer
The GraphRAG indexing pipeline: graph → communities (Leiden) → summaries
Global vs local search — and the map-reduce trick
The notorious cost cliff — and how LazyGraphRAG fixed it

An infographic titled 'GraphRAG — From Local Facts to Global Themes'. A red strip states the question vector RAG can't answer: what are the main themes across ALL these documents? Top-k retrieval returns a few similar chunks, but no chunk IS 'the themes' — you can't see the forest by grabbing 5 trees. GRAPHRAG INDEXING precomputes a hierarchical understanding of the whole corpus as a flow: Chunk (text units), then Extract graph (entities plus relationships, via an LLM), then Leiden communities (cluster the graph into a hierarchy of topics), then Community summaries (an LLM summarizes each community, bottom-up). Two query-mode cards. Global search: whole-corpus / sensemaking questions, map-reduce over the community summaries — each summary gives a partial answer (map), combined into one global answer (reduce); summaries are precomputed so there's no giant context call. Local search: entity-specific lookups, fan out from an entity's neighborhood — its relationships, nearby entities, and source chunks; here GraphRAG and vector RAG overlap, and DRIFT search blends both. A caveat: the cost cliff — full GraphRAG indexing is brutal (LLM extraction per chunk plus a summary per community); one famous dataset cost about 33,000 dollars; LazyGraphRAG and LightRAG cut indexing about 1000 times (around 0.1 percent); it's overkill for lookups, so use it for global sensemaking and route by query type. Banner: cluster the graph into communities, summarize each, then map-reduce over the summaries — that's how GraphRAG answers global questions retrieval alone can't.

The Question Retrieval Can't Answer

Be precise about why vector RAG fails here, because it's a structural limit, not a tuning problem. Vector search answers "find the chunks most similar to my query." For a global question like "what are the main themes?":

There is no single chunk that is semantically similar to "the main themes," because the themes don't appear written down anywhere — they're a synthesis across thousands of chunks.
Even if you retrieved the top-100 chunks, you'd get 100 arbitrary passages, not a representative survey of the corpus — and you can't fit (or sensibly summarize) the whole dataset into one context window.

This is the gap between local retrieval (find the relevant bit) and global sensemaking (understand the whole). GraphRAG's core idea is to precompute a structured, hierarchical understanding of the entire corpus at indexing time — so that at query time, answering a global question becomes reading a handful of summaries instead of trying to read everything.

The GraphRAG Indexing Pipeline

GraphRAG inserts three new stages into the normal index → retrieve → generate pipeline. The first you already know from L103; the other two are what make global reasoning possible:

# GraphRAG INDEXING (offline, expensive): build a hierarchical understanding of the corpus.
# 1) Extract an entity-relationship graph from chunks (L103) — an LLM call per chunk.
# 2) Detect COMMUNITIES with the Leiden algorithm, recursively → a hierarchy of topic clusters.
import networkx as nx
from graspologic.partition import hierarchical_leiden

communities = hierarchical_leiden(entity_graph, max_cluster_size=10)
#   level 0 = a few big, generic communities ; deeper levels = smaller, specific ones

# 3) SUMMARIZE each community with an LLM, bottom-up — these summaries are the key artifact.
def summarize_community(entities, relationships):
    return llm(f"Summarize this community of related entities into a report:\n"
               f"Entities: {entities}\nRelationships: {relationships}")

community_summaries = {c.id: summarize_community(c.entities, c.relationships)
                       for c in communities}      # ← precomputed, reused at query time

1. Extract the entity graph (L103) — an LLM pulls entities, relationships, and claims from each chunk into a knowledge graph.

2. Detect communities with the Leiden algorithm. This is the key new idea. Leiden (an improvement on Louvain) is a community-detection algorithm: it partitions the graph into communities — clusters of densely interconnected entities that represent topics. Crucially, GraphRAG runs it hierarchically/recursively: big communities at level 0 (generic), sub-communities within them at deeper levels (specific). You get the corpus's topic structure at multiple granularities.

3. Summarize every community with an LLM, bottom-up. For each community, an LLM writes a natural-language summary report — first the small leaf communities, then summaries-of-summaries up the hierarchy. These community summaries are the magic artifact: a precomputed, multi-level "what this part of the corpus is about."

The output is a set of Entities, Relationships, and Communities (with summaries) — a queryable, hierarchical map of the whole dataset.

Two Ways to Search: Global & Local

With that index built, GraphRAG answers questions in two modes — and knowing which is which is the practical core of the lesson:

# GLOBAL search — "What are the main themes across the corpus?"  (map-reduce over summaries)
def global_search(question, community_summaries):
    partials = [llm(f"Using ONLY this community report, answer: {question}\n\n{s}")
                for s in community_summaries.values()]          # MAP: one partial per community
    return llm(f"Combine these partial answers into one: {partials}\n\nQ: {question}")  # REDUCE
#   No raw documents re-read at query time — just the small, precomputed summaries.

# LOCAL search — "Tell me about CTO Bob."  (fan out from the entity's neighborhood)
def local_search(entity, question):
    ctx = graph.neighbors(entity) + graph.relationships(entity) + source_chunks(entity)
    return llm(f"Answer using this entity's context:\n{ctx}\n\nQ: {question}")

🌍 Global search — for whole-corpus, sensemaking questions. It runs a map-reduce over the community summaries: each summary independently produces a partial answer (the map step), and those partials are combined into one final answer (the reduce step). The elegance: because the summaries are precomputed, query time just fetches small summaries — there's no attempt to cram the whole corpus into one giant context call. This is how "what are the main themes?" gets answered — by synthesizing the pre-written topic summaries.

📍 Local search — for entity-specific lookups ("tell me about CTO Bob"). It fans out from a specific entity's neighborhood: its relationships, neighboring entities, and the source chunks that mention it. This is closer to L103 traversal blended with vector retrieval.

The division mirrors the lesson title — from local to global. Global search is where GraphRAG uniquely shines (sensemaking); local search is where it overlaps with vector RAG (lookups). A newer mode, DRIFT search, dynamically blends the two. Explore both in the widget below.

Toggle Global vs Local. Global ('what are the themes?') map-reduces over the community summaries to synthesize the whole corpus; Local ('tell me about X') fans out from one entity. See what vector RAG structurally can't do.

Does It Work? The Evidence

For the global questions it targets, GraphRAG delivers — and the improvement is exactly along the axes you'd expect from "understanding the whole corpus":

On global sensemaking questions over ~1-million-token datasets, Microsoft's GraphRAG produced answers that were substantially more comprehensive and more diverse than a conventional vector-RAG baseline (commonly cited as roughly +26% comprehensiveness and +57% diversity, with better faithfulness too — explicit relationships preserve context).
It's also strong on hard multi-hop questions (one enterprise benchmark reported GraphRAG far ahead of vector RAG on multi-hop accuracy).

But note the crucial caveat baked into those same studies: vector/semantic search still wins on specific lookup queries. GraphRAG's advantage is specific to global, synthesis-heavy questions — it is not a blanket upgrade. Which makes the next question — what does it cost? — decisive.

The Cost Cliff — and LazyGraphRAG

Here's the catch that has sunk many GraphRAG projects, and the honest reason it's not a default: full GraphRAG indexing is breathtakingly expensive. Look at what it does at index time — an LLM extraction call per chunk, plus an LLM summary per community at every level of the hierarchy. On a large corpus that's millions of tokens of LLM work:

Full Microsoft GraphRAG on ~1M tokens runs roughly $20–40** with a frontier model; for a large dataset, indexing famously cost about **$ 33,000 in early 2024 — the "GraphRAG cost cliff."
It also adds heavy operational complexity (graph DB + community detection + extraction + summarization pipeline) and inherits L103's entity-drift problem ("Sagar S" / "Sagar Shankaran" / "S Shankaran" becoming three nodes).

The field's answer, also from Microsoft, is LazyGraphRAG (late 2024): it defers the expensive LLM work to query time, so indexing costs about the same as plain vector RAG — roughly 0.1% of full GraphRAG — while matching or beating its quality on global questions. Lighter variants (LightRAG, Fast GraphRAG) cut indexing 50–6,000× as well. That " $33,000 → ~$ 33" collapse is what made GraphRAG practical for 2026.

So the verdict: GraphRAG is the right tool for global sensemaking over relationship-rich corpora — business intelligence, legal/research/regulatory collections, healthcare pathways, fraud and supply-chain analysis — not for simple lookups, where it's expensive overkill. And the production pattern is the one from L101: run both vector and graph RAG, routed by query type — lookups to vector, global/multi-hop to GraphRAG — and prefer a Lazy/Light variant to dodge the cost cliff.

🧪 Try It Yourself

Drive the GraphRAG widget, then reason about it:

Click 🌍 Global. How does GraphRAG produce "the three themes" — what does it actually read, and why is that impossible for top-k vector retrieval?
Click a 📍 Local entity. Could vector RAG answer this one reasonably well? What does that tell you about where GraphRAG is and isn't worth it?
Put these GraphRAG indexing steps in order, and say which one enables global questions: community summarization, entity-relationship extraction, Leiden community detection, chunking.
A startup wants GraphRAG for a customer-support bot that answers "how do I reset my password?"-style questions over 500 help articles. Good fit? What would you recommend instead?
Your CFO balks at a $30k GraphRAG indexing bill for a one-million-token corpus. What's the 2026 answer?

→ (1) It map-reduces over the precomputed community summaries — reading a few topic-level summaries that span the whole corpus, then combining them. Vector RAG can only fetch similar chunks, and no chunk is "the themes," so it structurally can't. (2) Yes — a local lookup is answerable by vector RAG too; that's the tell that GraphRAG's unique value is global sensemaking, not lookups (so don't pay for it on lookup-only workloads). (3) chunk → extract entities/relationships → Leiden community detection → community summarization; the community summaries are what enable global questions. (4) Poor fit — those are local lookups; plain vector RAG (hybrid + rerank) is cheaper and as good. GraphRAG is overkill here. (5) Use LazyGraphRAG / LightRAG — indexing cost drops to ~0.1% (roughly $30k →$ 30) at comparable global-question quality.

Mental-Model Corrections

"Retrieve enough chunks and you can answer any question." Not global ones — "the main themes" exist in no chunk; they're a synthesis of the whole corpus. GraphRAG precomputes that via community summaries.
"GraphRAG is just knowledge-graph retrieval (L103)." It adds two things on top: hierarchical community detection (Leiden) and community summarization — that's what unlocks global reasoning.
"Global and local search are the same." Global = map-reduce over community summaries (whole-corpus); local = fan out from an entity (lookup). GraphRAG uniquely wins at global.
"GraphRAG beats vector RAG everywhere." Only on global / multi-hop sensemaking. Vector RAG wins on lookups — and is far cheaper.
"GraphRAG is too expensive to use." Full GraphRAG is (the ~$33k cliff), but LazyGraphRAG/LightRAG cut indexing to ~0.1% — that excuse is gone in 2026.
"Use GraphRAG or vector RAG." Production uses both, routed by query type (L101) — lookups to vector, global to graph.

Key Takeaways

GraphRAG answers global sensemaking questions ("what are the themes/risks across the whole corpus?") that vector RAG structurally can't — the answer is a synthesis of the entire dataset, present in no single chunk.
Indexing adds three stages: extract an entity graph (L103) → detect communities with the hierarchical Leiden algorithm → write an LLM summary for each community (bottom-up). The community summaries are the key precomputed artifact.
Two query modes: Global = map-reduce over community summaries (whole-corpus synthesis, no giant context call); Local = fan out from an entity neighborhood (lookup). DRIFT blends them.
Evidence: substantially more comprehensive & diverse answers than vector RAG on global questions — but vector RAG still wins on lookups.
The cost cliff: full GraphRAG indexing is brutal (~$33k famously); LazyGraphRAG/LightRAG cut it ~1000× (≈0.1%). Use GraphRAG for global sensemaking over relational corpora, prefer a Lazy/Light variant, and route by query type (vector for lookups, graph for global).
Next: RAG over tables, PDFs & images — multimodal retrieval, when the answer lives in a chart or a scanned page, not in text.