**GraphRAG** does extra work before any query arrives. It reads the corpus, extracts entities and the relationships between them into a knowledge graph, and builds summaries of clusters of related content. Plain vector RAG skips all that and just retrieves the top-k most similar chunks at query time.
That upfront work pays off for three kinds of question. Global, aggregative ones like "what are the main themes across this whole corpus" need a view of everything at once. Multi-hop ones chain relationships across several documents to reach an answer. And corpora where the meaning lives in the connections between entities reward an explicit graph.
For everything else, GraphRAG is overkill. A single fact sitting in one document, or a small FAQ where each answer is one short article, is already handled fine by top-k vector retrieval. Adding a graph just adds cost.
And it never wins on speed — building and traversing a graph is usually slower, not faster, than a vector lookup.
The right answers are global/aggregative questions, multi-hop relationship questions, and entity-rich corpora. The wrong ones are single-fact lookups, small FAQs, and — the trap — "it's faster."
**GraphRAG** moves work to an offline indexing phase. It extracts entities and relationships into a knowledge graph, then runs community detection and summarizes each community. At query time it can traverse the graph or roll up community summaries instead of relying purely on chunk similarity.
That is exactly what unlocks the three winning cases. A global question like "main themes across the corpus" cannot be answered by top-k chunks, because no single chunk holds the global view — the community summaries do. A multi-hop question needs to connect entity A to entity C through B, which graph traversal does and similarity search does not. And a corpus whose meaning is relational (org charts, citation networks, dependency graphs) is literally encoded by the graph.
The distractors are the everyday cases vector RAG already nails. A self-contained fact in one document, or a short FAQ article, retrieves cleanly with top-k. Adding a graph buys nothing there but indexing cost and complexity.
The latency option is plainly false. Graph construction is expensive offline, and traversal plus summarization is usually slower at query time, not faster.
Quick reference
TL;DR
GraphRAG earns its cost on global questions, multi-hop chains, and entity-rich corpora — the queries plain top-k vector search cannot stitch together. It is overkill for single-fact lookups and never chosen for speed.
Imagine a huge pile of news clippings. If someone asks 'what does this one article say,' you just find that clipping and read it — that is normal search. But if someone asks 'across all these clippings, what are the big recurring storylines, and how are these two people connected through a chain of events,' flipping through clippings one at a time will not work. So beforehand you build a giant relationship map — who knows whom, what links to what — and a set of summaries grouping related clippings. That map is GraphRAG. It costs effort to build, but it answers the big-picture and connect the dots questions a plain search never could. For a simple 'what is the refund policy' question, the map is wasted work.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A corpus of independent, self-contained documents answered by single-document lookups There is no cross-document structure to exploit, so the graph adds extraction cost for no recall gain over top-k.
Latency-sensitive query paths with tight response budgets Traversal and multi-summary aggregation add query-time work; a vector lookup with reranking is faster.
Rapidly changing corpora that need near real-time freshness Re-extracting entities and recomputing community summaries is expensive, so the graph lags the source data.
Small corpora where a long-context model can read most of it directly If everything fits the window, building a graph is wasted engineering versus just feeding the documents.
Quick scan · 2–4 min
Everything important, quickly.
5 min: what GraphRAG builds offline, why global/multi-hop/relational queries need it, why single-fact and FAQ lookups do not, and why latency is the wrong reason to choose it.
Real-world examples
Real products, models, and research that use this idea.
1Microsoft's GraphRAG extracts an entity-relationship graph, runs Leiden community detection, and summarizes communities to answer global sensemaking questions over a corpus.
2Analysts querying 'what are the recurring risk themes across these thousands of incident reports' use community summaries, which top-k chunk retrieval cannot assemble.
3Multi-hop questions over a citation or org-structure graph rely on traversal to connect entities that share no single chunk.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does GraphRAG actually answer a global question that no single chunk contains?
Sign in or go Pro to see the approach for this follow-up.
QWhat makes multi-hop questions hard for plain dense retrieval?
Sign in or go Pro to see the approach for this follow-up.
QHow would you keep a GraphRAG index fresh on a corpus that changes daily?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Picking GraphRAG to cut latency — graph construction and traversal usually make it slower and more expensive to build, not faster; it is chosen for the questions it can answer, never for speed.