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 polic y?” 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 hardest, cross-document sets: +31 points on MuSiQue and +28 points on 2Wiki.HippoRAG reports up to a 20% accuracy improvement on multi-hop QA, at 10–20× lower cost and 6–13× faster than iterative retrieval methods.3. The controlled head-to-head - where it gets honestHere is where the story gains nuance. A 2025 study from Michigan State and Meta ran RAG against four GraphRAG families under one unified protocol — identical chunking, embeddings, and generation — and found no single winner. The two approaches are complementary:On single-hop, factual lookup (natural questions), plain RAG edged ahead (F1 64.8 vs. 63.0 for the best graph method).On multi-hop reasoning (MultiHop-RAG), graph-guided retrieval pulled in front (70.3 vs. 67.0 overall accuracy).The lesson: A context graph is not a universal upgrade. It is a specialized one that pays off precisely when questions demand reasoning across pieces.4. When to use graphs: The task-type verdictThe most recent benchmark, GraphRAG-Bench (ICLR 2026), set out to answer “In which scenarios do graph structures provide measurable benefits?” Its accuracy-by-task numbers map the boundary cleanly:Simple fact retrieval: Text chunks 60.9 vs. graph 60.1 — effectively a tie. The graph’s structure is overhead the query doesn’t need.Complex reasoning: Graph 53.4 vs. chunks 42.9 — a +10 point graph win.Contextual summarization: Graph 64.4 vs. chunks 51.3 — a +13 point graph win.The scorecardRead top to bottom, the pattern is unmistakable: The graph’s advantage grows with the reasoning depth of the question, while text chunks hold their ground on isolated facts.The catch: Cost and the LLM-judge problemTwo caveats keep this from being a slam dunk, and ignoring them is how teams end up disappointed.Building the graph is expensive. Having an LLM extract entities and relationships from an entire corpus isn’t cheap. One analysis put index construction at roughly $48 against GPT-4o for a moderate corpus, far above a vanilla vector index. (Microsoft’s own follow-up, LazyGraphRAG, defers extraction to query time and cuts that to around 0.1% of the cost - a tacit admission that the original budget is impractical for many deployments.)Many of the wins are judged by another LLM — and LLM judges are biased. An independent audit found systematic flaws in this evaluation style: position bias (swapping which answer appears first can swing the win-rate by more than 30 points), length bias, and trial bias (identical comparisons disagree across runs). After correction, one popular method’s reported 66.7% win rate fell to about 39% — below the 50% break-even line.The takeaway is not “the research is wrong.” It is that the large gains — the +20% multi-hop accuracy, the +15-to-30-point recall jumps — are robust, while narrow comprehensiveness margins deserve a skeptical second look with reference-based metrics.So when should you reach for a context graph?Strip away the hype and the decision is refreshingly practical.Use a context graph when: Your questions are multi-hop, global, or sensemaking in nature; you need comprehensive, multi-perspective answers; and your corpus is richly interconnected (research libraries, case files, incident histories, knowledge bases).Stick with text chunks when: Your queries are mostly single-fact lookups; your corpus is small or flat; and indexing cost, latency, and operational simplicity outweigh a marginal quality bump.Best of all, go hybrid: The systematic studies converge on the same recommendation: route each query to the right method, or fuse evidence from both. Combining graph and chunk retrieval consistently beats either one alone. You don’t have to choose a religion; you have to build a router.The bottom lineA context graph is not magic, and it is not snake oil. It is a targeted instrument. Hand it a question that requires connecting scattered facts or synthesizing a whole corpus, and it will outperform text chunks decisively. Hand it “what’s the phone number on page 3,” and you’ve paid for indexing you didn’t need.The teams that win with GraphRAG in 2026 won’t be the ones who graph everything. They’ll be the ones who know which questions deserve a graph — and build pipelines smart enough to tell the difference.Dattaraj Rao is an RD architect at Persistent Systems ...read more read less