Reconstruct the offline build steps of a GraphRAG index

Order steps·Medium·4.0 · 0·~1 min·Asked atFigure Ai Qualcomm

Attempt it

1Split the corpus into chunks
2Extract entities and relationships from each chunk with an LLM
3Assemble the entities and relationships into a knowledge graph
4Generate a summary for each detected community
5Detect communities (densely connected clusters) in the graph

GraphRAG is a retrieval pattern where, instead of dropping chunks into a flat vector index, you first build a **knowledge graph** of the entities and relationships in your corpus. The offline build pipeline has a strict order because each step eats the output of the one before it. The correct sequence is: split the corpus into chunks, extract entities and relationships from each chunk with an LLM, assemble those into a knowledge graph, detect communities (densely connected clusters) in the graph, then summarize each community. The ordering logic is purely about dependencies. You cannot extract entities from text you have not chunked yet. You cannot build a graph before you have nodes and edges to put in it. You cannot find communities in a graph that does not exist. And you cannot summarize a community before community detection has told you which nodes belong to which cluster. The community summaries are the payoff. They let GraphRAG answer broad, aggregative questions — "what are the main themes across these documents?" — that flat top-k retrieval struggles with, because a global question has no single chunk that answers it. They are produced last because they depend on every earlier artifact.

The GraphRAG offline index builds in five dependency-ordered stages. The order falls out entirely from what each stage consumes. Chunk first. Split the corpus into passages small enough for reliable LLM extraction. Then run entity and relationship extraction: for each chunk, prompt an LLM to pull out the entities mentioned and the relationships between them, typically as typed triples. This is the most expensive stage because it is one or more LLM calls per chunk across the whole corpus. Next, **assemble the knowledge graph**. The extracted entities become nodes and the relationships become edges; duplicate mentions of the same entity across chunks are resolved and merged so one real-world entity is one node. Only now does a graph exist. With the graph in hand, run **community detection**. A clustering algorithm like Leiden partitions the graph into densely connected groups, often hierarchically so you get communities at several levels of granularity. Finally, **summarize each community**: an LLM writes a natural-language report describing what that cluster of entities and relations is about. Those community summaries are the artifact that makes GraphRAG distinctive. At query time, a global question ("what are the dominant themes?") is answered by map-reducing over community summaries rather than retrieving individual chunks. A local question can still traverse the graph from specific entities. The build order is non-negotiable because summarization depends on detection, detection depends on the assembled graph, and the graph depends on extraction over chunks.

TL;DR

GraphRAG's offline pipeline runs chunk → extract entities and relations → assemble the graph → detect communities → summarize each community, because every step consumes the artifact the previous one produced.

Memory aid

Easy to grasp

Imagine turning a stack of biographies into a giant friendship map of a town. First you tear the books into readable pages (chunks). On each page you note who is mentioned and how they relate — Alice is Bob's sister, Bob works at the bakery. Then you pin all those notes on a wall and draw lines between the people, building one big web. Once the web exists, you can see clusters: the bakery crowd, the school crowd, the football crowd. Finally you write a short blurb describing each cluster. Now if someone asks a sweeping question like 'what are the main social circles in town?', you read the blurbs instead of every page. That blurb-writing has to come last, because you cannot describe a cluster before you have found it.

Key concepts

Retrieval-Augmented Generation LLM System Design

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Ordering questions look like trivia, but a good interviewer uses them to test whether you actually understand a system's data flow. GraphRAG is a perfect target: it has five offline build stages, the order is completely rigid, and the only way to get it right is to reason about what artifact each stage produces and consumes. Memorizing the sequence is fragile; understanding the dependencies means you can reconstruct it under pressure.

GraphRAG exists to solve a problem ordinary RAG handles poorly. Flat top-k retrieval is great at "find me the passage that answers this" but weak at "summarize the main themes across the whole corpus," because a global question has no single chunk that contains the answer. GraphRAG builds a structured knowledge graph and precomputes summaries of its communities so those whole-corpus questions become tractable.

There is a second reason the order matters in an interview. Several of the wrong sequences are not merely suboptimal, they are physically impossible — you cannot summarize a cluster you have not found, and you cannot cluster a graph that has not been built. An interviewer watching you place the steps learns immediately whether you picture GraphRAG as a real data pipeline or as a vague bag of buzzwords. Naming the artifact each stage produces is the tell that you understand it.

This deep dive walks the pipeline stage by stage, explains why each step must wait for the previous one, looks closely at the two LLM-heavy stages that dominate cost and quality, and ends on the economics that decide when GraphRAG is the right tool at all.

The dependency chain that fixes the order

The five stages are: chunk the corpus, extract entities and relationships, assemble the knowledge graph, detect communities, summarize each community. There is exactly one valid order, and it is not a matter of preference — it is a topological sort over a dependency graph where each step needs the previous step's output to exist.

Walk the chain backwards and the rigidity is obvious. You cannot summarize a community until detection has told you which nodes form that community. You cannot run community detection until a graph exists to cluster. You cannot assemble a graph until you have extracted nodes and edges. You cannot extract entities reliably until the text is chunked into passages an LLM can process well.

Each arrow is a hard data dependency, so there is no flexibility. This is why the common wrong answers — putting summarization before detection, or detection before assembly — are not just suboptimal, they are impossible: the input the misplaced step needs has not been produced yet.

The useful interview move is to say this out loud. Rather than reciting five steps, name the artifact each one produces (chunks, triples, a graph, communities, reports) and the order falls out for free.

Stage one and two: chunking and LLM extraction

Stage three: assembling and resolving the graph

Stage four and five: detection and summarization

Why the build is a batch job, not a stream

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Microsoft's GraphRAG implementation runs exactly this pipeline: chunk, LLM entity/relation extraction with gleaning, graph assembly, Leiden community detection, then community report generation
LlamaIndex's PropertyGraphIndex builds the graph from extracted triples before any community-level summarization is available

What an interviewer would ask next. Try answering before peeking at the approach.

QHow does GraphRAG answer a global question differently from a local one at query time?

A global question ('main themes across the corpus') map-reduces over community summaries: each relevant community contributes a partial answer, then those are reduced into a final response. A local question starts from specific entities and traverses the graph's neighborhood. The community hierarchy lets you pick the right zoom level — leaf communities for narrow, root communities for whole-corpus.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Putting community detection or summarization before the graph is assembled — you cannot cluster nodes and edges that do not exist yet, and you cannot summarize a community you have not found.

60 second bullets to scan on the way to the call.

The five stages of the GraphRAG offline build in order
Why chunking has to precede entity extraction

Primary sources. Browse if you want the original framing.