Stop graphing everything: When GraphRAG actually beats vector RAG

If you have built anything with retrieval-augmented generation (RAG) in the last two years, you have lived its central frustration: You chop your documents into chunks, embed them, retrieve the top few that look similar to the question, and hand them to the model. For “What was our Q3 refund policy?” This works beautifully. For “What are the recurring themes across two years of customer complaints?” it falls flat — because no single chunk contains the answer.The fashionable fix is GraphRAG: Instead of feeding the model isolated snippets, you first build a knowledge graph of the entities and relationships in your corpus, then use that structure as context. The pitch is seductive. But seductive pitches deserve scrutiny, so I went through the evidence — the original Microsoft paper plus four independent benchmark studies — to answer a simple question: When you swap text chunks for a context graph, do answers actually get better?The short version: Yes, substantially — but only for the right kind of question, and not for free. Let me show you the receipts.Why text chunks hit a wallStandard vector RAG retrieves the k passages most similar to your query. That design has three structural blind spots:It can’t connect the dots. When an answer requires joining facts that live in different passages through a shared entity, chunks embedded in isolation never reveal the link.It’s blind to global questions. “What are the main themes?” needs the whole corpus, but similarity search only returns the handful of chunks that superficially resemble the question.It severs context at chunk boundaries. The relationships and hierarchy that complex reasoning depends on are exactly what chunking throws away.Microsoft Research framed this crisply when they introduced GraphRAG: Baseline RAG “struggles to connect the dots” and performs poorly when asked to “holistically understand summarized semantic concepts over large data collections.”What a context graph changesGraphRAG attacks the problem before any question is asked. During indexing, a large language model (LLM) reads every chunk and extracts entities, relationships, and claims, assembling them into a weighted knowledge graph. It then runs community detection (the Leiden algorithm) to cluster the graph into a hierarchy of related topics, and pre-writes a natural-language summary for each community.At query time, those summaries do the heavy lifting. Each relevant community drafts a partial answer (the “map” step), the partials are ranked and merged (the “reduce” step), and the model synthesizes a final response grounded in structure rather than in a few cherry-picked snippets. Variants like HippoRAG take a different route, using the graph plus a Personalized PageRank walk to find the right passages — but the core idea is the same: Let relationships, not just cosine similarity, decide what context the model sees.The evidence: Four studies, one pattern1. Global sense making: The headline winMicrosoft pitted GraphRAG head-to-head against naïve RAG on global, “make sense of the whole corpus” questions over million-token datasets, with an LLM acting as judge across three axes: Comprehensiveness, diversity, and empowerment.GraphRAG won 72 to 83% of comprehensiveness comparisons and 62 to 82% of diversity comparisons against vector RAG. Its highest-level summaries used up to 97% fewer tokens than processing the source text directly.That is not a rounding-error improvement. On exactly the kind of question that breaks text-chunk RAG, the graph wins two out of three times or better.2. Multi-hop retrieval: The graph finds what chunks missThe second piece of evidence is about retrieval quality: Does the right supporting passage even make it into the top results? On the standard multi-hop QA benchmarks (MuSiQue, HotpotQA, 2WikiMultiHopQA), graph-guided retrieval lifts Recall@5 dramatically:Average Recall@5 climbs from 73.4% (naïve RAG) to 87.8% (graph-guided), a +19.6 point gain.The biggest jumps come on the harde