GraphRAG,
explained.

Rung 8 retrieves the passages most similar to the question and generates from them, which is exactly right when the answer is somewhere in the corpus. This rung names the class of question where that framing fails completely: "what are the main themes across all of this". No individual passage contains the answer. Retrieving the ten most similar ones returns ten arbitrary examples, and the model dutifully summarises those ten as though they were the corpus. The failure is quiet — a fluent answer about a sample, presented as an answer about the whole.

The change is to precompute structure rather than to retrieve harder. Use a language model to extract entities and relationships from every chunk into a graph, run community detection to find clusters of densely-related entities, and have the model write a summary of each community ahead of time, at several levels of granularity. The corpus acquires a hierarchy it did not come with.

A global question is then answered by map-reduce over those summaries instead of by retrieval: answer the question partially against each community summary, then combine those partial answers. Stated in rung 8's units, the difference is coverage — top-k touches k passages, this touches the whole corpus by way of a structure built in advance. The cost moves from query time to indexing time, which is the trade, and it is a good one whenever a corpus is queried more often than it changes.

Standard RAG works by similarity: embed the query, retrieve the top-k most similar chunks, and let the model answer from them. For a local question — one whose answer sits in a specific place — this is perfect. The relevant passage is similar to the query, so it gets retrieved, and the model reads it off.

But a global question is different in kind. "What are the recurring themes?" "How do these findings relate across the whole report?" "Summarize the main tensions in this corpus." The answer to these isn't in any passage — it's an emergent property of many passages. Retrieve the top-k most similar chunks and you get a handful that happen to match the query's words, covering a small slice of what you'd need to synthesize. No amount of better embedding fixes this: the information is distributed, and top-k retrieval is inherently local.

GraphRAG's indexing does more than embed chunks. An LLM reads every chunk and extracts entities and the relationships between them — people, organizations, concepts, and how they connect. Stitched together across the corpus, these become a knowledge graph: nodes are entities, edges are relationships, and an entity mentioned in many places becomes a well-connected hub.

This graph captures something the flat pile of chunks never did: structure. Two facts stated in different documents about the same entity are now linked through that entity's node. The corpus stops being a bag of passages and becomes a network you can traverse, cluster, and reason over globally — which is exactly what the local, similarity-only view was missing.

A knowledge graph over a large corpus is itself too big to read. So GraphRAG runs community detection (the Leiden algorithm) to partition the graph into communities — clusters of densely interconnected entities that tend to correspond to coherent topics or themes. This is done hierarchically, giving communities at multiple levels of granularity. An LLM then writes a summary of each community ahead of time.

The community summaries are the key artifact. Instead of a million raw chunks, you now have a manageable set of topic-level digests that collectively cover the entire corpus. A global question can be answered by consulting these, not by hoping the right handful of chunks were similar enough to retrieve.

To answer a global query, GraphRAG uses map-reduce over the community summaries. Map: generate a partial answer from each relevant community summary in parallel. Reduce: combine those partial answers into a single, comprehensive response. Because the summaries span the whole corpus, the final answer draws on all of it — not the fraction that a top-k retriever would surface.

If a global answer is spread over R relevant passages and you retrieve only k < R, plain RAG covers just min(k,R)/R of it — for R=10, k=3, that's 30%. GraphRAG's map-reduce over community summaries covers the whole corpus by construction. The paper found this yields substantially more comprehensive and diverse answers to global sense-making questions, judged head-to-head against vector RAG. The runnable version below makes the coverage gap concrete.

GraphRAG (Edge, Trinh, Cheng and colleagues at Microsoft, 2024) spends language-model calls at indexing time so that a question about a whole corpus can be answered from prepared summaries at query time. In the paper's experiments the extraction, summarisation and answering steps below are prompted calls to GPT-4 Turbo; chunking, community detection and packing are not.

1. Chunk the text. Split the source documents into chunks; the experiments used 600-token chunks with 100-token overlaps. Chunk size is a recall dial: on a HotPotQA sample, 600-token chunks yielded almost twice as many entity references as 2,400-token chunks, at the price of four times as many extraction calls.
2. Extract elements. For each chunk, a few-shot prompt asks for entities (name, type, description), relationships between them (source, target, description) and, optionally, claims about them. The examples in the prompt can be tailored to the corpus's domain.
3. Glean what was missed. After each extraction the model is asked whether any entities were missed, with a logit bias forcing a yes-or-no answer; on a yes, a follow-up prompt says many entities were missed and asks for them. This repeats up to a set number of gleanings, so larger chunks can be used without losing as much recall.
4. Summarise elements. An entity extracted from many chunks has many descriptions, so a model call merges each entity's and each relationship's descriptions into one. Repeated relationship instances become the edge's weight.
5. Detect communities. Run Leiden community detection on the weighted graph recursively, splitting each community again until the leaf communities cannot be partitioned further. The paper evaluates four levels, C0 at the root down to C3.
6. Write community summaries from the bottom up. For a leaf community, rank its edges by the combined degree of their two endpoints and add each edge's source, target, linked claims and description to the context until the token limit is reached; the model writes a report-style summary from that. For a higher community, use its element descriptions if they fit, and otherwise substitute its sub-communities' shorter summaries until they do.
7. Map over the summaries. At query time pick a level, shuffle its community summaries and pack them into chunks of a fixed token size, so relevant material is spread across chunks instead of concentrated in one. Each chunk yields an intermediate answer and a helpfulness score from 0 to 100, and answers scoring 0 are dropped.
8. Reduce to one answer. Sort the surviving answers by score, add them to a fresh context window until it is full, and generate the global answer from that context.

The split of work is the design. Steps 1 to 6 run once per corpus and touch every chunk, so their cost scales with the corpus; steps 7 and 8 run per question and touch only summaries, so their cost scales with the number of communities at the chosen level. Choosing a higher level makes a query cheaper and coarser, and choosing a lower one makes it more detailed and more expensive.

• deg(u) + deg(v) — an edge's prominence. Edges between well-connected entities are summarised first, so the most central facts survive the token limit.
• hb — the helpfulness score the model attaches to its own partial answer; a zero means the batch had nothing relevant, and the answer is discarded.
• Aij, ki, m — the edge weight between entities i and j, the weighted degree of i, and the total edge weight of the graph.
• γ — the resolution: higher values favour more, smaller communities.
• δ(ci, cj) — 1 when i and j sit in the same community, otherwise 0.

GraphRAG has no trained objective; these rules, plus the modularity that Leiden (Traag, Waltman and van Eck) maximises in its standard form, decide which text a model ever sees. Read together, the map and reduce lines show the design: shuffling spreads relevant summaries across batches so that no single batch has to hold them all, and the score lets the reduce step discard empty batches before the final window fills. At the extremes, choosing C0 means a handful of very broad summaries — the cheapest query — while choosing the leaf level approaches summarising the source text itself; a question that matches nothing returns all-zero scores and leaves the reduce step nothing to combine.

There was no benchmark of whole-corpus questions, so the authors built one. Two corpora: transcripts of a technology podcast, about 1 million tokens, and a collection of news articles, about 1.7 million. For each, an LLM proposed five users, five tasks per user and five questions per user-task pair that need the whole corpus to answer: 125 questions per dataset. Six conditions answered them — GraphRAG at levels C0 to C3, TS (the same map-reduce run directly over shuffled source text) and SS (naive RAG: retrieve similar chunks into the window) — all with an 8,000-token context, which had beaten larger windows on comprehensiveness in a pilot. An LLM judge compared answers head to head on comprehensiveness, diversity and empowerment, with directness as a control that naive RAG should win.

The cheapest level held up: root-level C0 summaries still beat naive RAG, with comprehensiveness win rates of about 72% and diversity win rates of 62% to 77% across the two corpora, while reading a few percent of TS's tokens. The negative results are stated in the paper. Naive RAG won directness, as designed. Empowerment results were mixed. Root-level summaries only tied map-reduce over the raw text, with win rates between 47% and 56%, so the cheap level is a trade, not a free win. And both the questions and the judge were language models working on two corpora of one to two million tokens, so the authors caution that other question types, data types and dataset sizes still need study. Later work moved the cost around rather than removing it: Microsoft's LazyGraphRAG, described in late 2024, defers most model calls from indexing to query time.

The indexing cost is the honest headline: extracting entities and relations and summarising communities means many language-model calls over every chunk of the corpus, so building the index is expensive in a way rung 8's is not, and it must be redone as the corpus changes. For a large or fast-moving collection that is the deciding factor.

Quality depends on extraction quality, and errors there are structural rather than local: a missed relation is an edge that never exists, a conflated entity merges two things permanently, and the community summaries inherit both. The summaries are themselves model-generated, so a global answer is built from paraphrases of paraphrases — which is defensible and is a longer chain of trust than quoting a source.

How it held up: the diagnosis is the durable part, and it clarified the whole field's vocabulary — "local" questions answered by finding a passage versus "global" questions requiring corpus-level synthesis are different problems needing different machinery, and conflating them is why so many retrieval deployments disappoint on exactly the questions executives ask. The graph is one implementation; hierarchical summarisation without a graph, and agentic approaches that plan a multi-step search, are others. Read this rung as the end of the ladder's argument: rungs 1 to 3 made meaning comparable, 4 and 5 made it searchable, 6 and 7 made it trainable, 8 made it generative, and 9 points out that some questions were never retrieval problems.

GraphRAG buys global reach at a real cost, so it complements rather than replaces vector RAG:

The practical pattern is a hybrid: route local, fact-lookup queries to cheap vector RAG, and global, sense-making queries to GraphRAG's community summaries. The graph earns its expensive index precisely on the questions plain retrieval can't touch.

GraphRAG named and attacked a real limitation that practitioners kept hitting: retrieval-augmented systems that were great at fact lookup and useless at "help me understand this whole body of text." By reintroducing structure — a knowledge graph and its communities — it gave RAG a way to reason over a corpus as a whole, and its open-source release made the approach widely reproducible.

The deeper point is about representation. Flat vector retrieval treats a corpus as an unordered set of passages, which is why it can only ever answer locally. Imposing a graph — entities, relationships, communities — restores the connective tissue between passages, and connective tissue is exactly what global questions are about. It's a reminder that how you structure knowledge determines which questions you can answer, and that similarity search, powerful as it is, is only one such structure.

Work each one out before you open it — a number, a prediction or a reason, not a definition. Producing the answer is what makes it stick. Your progress is kept on this device.

The longest ladder here, and the most linear: nine papers that carry one idea — text as geometry — from a 2013 word embedding to a graph-structured retrieval system.

1. 1Word2Vec2013
2. 2GloVe2014
3. 3Sentence-BERT2019
4. 4Product Quantization2011
5. 5HNSW2016
6. 6Dense Passage Retrieval2020
7. 7ColBERT2020
8. 8Retrieval-Augmented Generation2020
9. 9GraphRAG2024

All 110 papers, in 19 ladders →