The case for GraphRAG

There is a class of question that makes a convincing retrieval demo fall apart. What keeps delaying our deals? Which customer problems are becoming a pattern? Where are we making promises the product cannot keep? The answer is spread across calls, tickets, emails and product discussions. No single document was written to answer it.

The case for GraphRAG is that a broad view of the evidence can be built once and used again. Connect the things the documents describe, organise the related material, and answer questions through that structure. For a team repeatedly investigating patterns across the same business, that is a useful piece of infrastructure to build.

Microsoft’s GraphRAG paper, From Local to Global, gives that argument a concrete method and an evaluation. The useful question for a builder is where that extra structure earns its keep.

A good match can still be a poor answer

In a basic retrieval-augmented generation system, or RAG, the question is used to find relevant text, which is passed to the model to produce an answer. Vector retrieval ranks passages by semantic similarity. This works naturally for a question pointing towards particular evidence. It is a weaker fit when the question asks for a view across the collection. Microsoft describes this distinction in its global search documentation.

Imagine a sales leader asking why expansion deals keep slipping. This is a hypothetical example. Three recent calls mention price. The agent retrieves those calls and writes an explanation about budget pressure, complete with citations.

Elsewhere, implementation notes describe an unfinished integration. Support tickets show the same dependency across several accounts. A product discussion says the promised release has moved. Those passages might look quite different from the sales leader’s question. Together, they suggest another explanation worth investigating.

The price answer can be faithful to every passage it cites and still miss the larger pattern. A citation tells you where a sentence came from. It does not establish that the evidence represents the whole business.

Returning more passages might help. But the design problem remains: how does the system decide that it has covered enough of the subject to answer a broad question?

Build the connections before you need the answer

GraphRAG adds a preparation step. A language model extracts entities and relationships from the text. The resulting graph is grouped into communities of connected entities, with summaries at different levels of detail. Those summaries become reusable context. The indexing documentation describes these stages.

In our expansion example, the things we would want represented are accounts, implementations, integrations and commitments. An account connects to an implementation; that implementation depends on an integration; several other accounts depend on it too. These connections would give the system a way to organise evidence around the shared problem, even when the sources use different language.

For a broad question, GraphRAG’s global search processes batches of community reports into intermediate responses, then filters and combines their useful points into a final answer. The question is answered across an organised representation of the collection. See the global search workflow.

The part I find compelling is the separation of work. Organising the evidence is work the system can reuse. Answering a question is work it does against that preparation. The next question can start from the same structure instead of asking the model to assemble the wider picture again from whatever a search happens to return.

The graph’s role in this method is to organise what gets summarised together. Simply putting documents in a graph database would not give us this workflow. The useful work is extracting the relationships, grouping the evidence and preparing the summaries that a broad question can draw on.

The specific bet on a graph is that relationships are a useful way to decide what belongs together. In company work, a shared product dependency may matter more than which document a fact appears in. That is what I would test against simpler ways of preparing summaries: does organising around the connected things preserve the patterns the team needs to see?

The argument is coverage first, compression second

Two comparisons matter: GraphRAG against vector retrieval, and GraphRAG against summarising all the source text. The first asks whether organising a wider view helps. The second asks what the graph adds once both systems consider the collection.

The chart uses root-level GraphRAG (C0), the same configuration as the token comparison below. Its comprehensiveness score was about 72% against vector retrieval on both datasets. Against full-text summarisation, its advantage was not statistically significant. See Table 6.

For a question about recurring customer problems, that is the trade I would investigate: does the answer cover more of what the team needs to see? Brevity matters less if a concise answer leaves out the dependency affecting half the accounts under review.

The preparation changes how much text each question needs. C0 used over 97% fewer context tokens than summarising all source text directly.

The case becomes more interesting when the same collection supports repeated questions. Preparation has a cost, so I would evaluate it over the life of the workload: building the index, keeping it current, and answering the questions people actually ask. A one-off summary and a weekly review process deserve different calculations.

The study used podcast and news corpora, not company workflows. Its claim-based follow-up found no significant comprehensiveness or diversity differences between GraphRAG and full-text summarisation. Vector retrieval was more direct; reduced hallucination was not established. See results and limitations.

My reading is that the study makes a strong case for broader coverage, and a practical case for achieving it through reusable summaries. It gives us a reason to test GraphRAG on company evidence. It does not settle that test in advance.

Use GraphRAG where the question crosses the documents

I would start with a question the team keeps answering by opening several systems and reconstructing the same relationships. Recurring implementation blockers. Themes across lost deals. Shared dependencies behind customer requests. Work where the difficulty lies in assembling the picture is a good place to test whether a graph improves it.

Take past examples and ask the people who know the work to assess the answers. Which important themes did each approach miss? Are the connections supported by the sources? Can the reader get back to the evidence? Does the improvement justify the time and cost of maintaining the index? Compare ordinary retrieval, whole-collection summarisation and GraphRAG on those same questions.

For a lookup such as finding a particular clause in a known contract, I would start with the simpler retrieval path. For an exact count of overdue invoices, I would query the underlying records. The architecture should follow the question.

A company agent still needs current state and permissions before it acts; that is where a world model for the company extends the work. The retrieval decision stands on its own: when a team repeatedly needs a broad view of connected evidence, build a representation it can reuse. Judge GraphRAG by how much better that makes the work.