GraphRAG precomputes answers before questions

GraphRAG is usually described as retrieval with a graph. That description hides the bill. In Microsoft's original design, a model extracts entities and relationships, groups them into hierarchical communities, then writes reports about those communities before anybody asks a question. Global search later maps the question across those reports and reduces the partial answers.

The short answer: full GraphRAG is a materialized-report system, not merely a smarter retriever. If the corpus changes often, default to deferred summarization. Choose eager community reports only when people will read or reuse the reports themselves, or repeated global questions genuinely repay the refresh cost. The architecture decision is not graph versus vector. It is when to pay for summarization, and who owns the stale answer already sitting on disk.

The index already contains an editorial judgement

The April 2024 GraphRAG paper was built for global questions over a corpus: not “which paragraph mentions this name?” but “what are the main themes here?” Its pipeline extracts a graph, finds communities at several levels, and generates a summary for each community. At query time, global search shuffles and batches those stored reports, asks a model for scored partial responses, then reduces the useful parts into one answer.

That sequence matters. A vector index stores representations of source chunks. Full GraphRAG stores model-written interpretations of groups of sources. The report is already a judgement about which entities belong together, what matters inside the cluster and how to compress it. By the time the first user arrives, the system has prepaid for a shelf of possible answers.

The paper reported better comprehensiveness and diversity than a vector-RAG baseline on global sensemaking questions over two corpora around the million-token scale. It also reported a less convenient result: vector RAG won on directness, and the evaluation used model-generated questions and an LLM judge rather than a human gold standard. That is useful evidence for a mechanism, not permission to call GraphRAG universally better.

A changing corpus turns retrieval into a freshness contract

Now put daily incident reports, policy revisions or customer notes into that pipeline. A new document can change entity relationships, community membership and therefore what a previously generated community report should say. The old report does not become obviously broken. It becomes quietly incomplete.

Microsoft's own July 2024 incremental-indexing design note makes the dependency visible. Cached chunks and entity extraction could be reused, but graph construction and communities might need recomputation, which in turn could trigger re-summarisation. The proposed optimisation was not “summaries never go stale.” It was to re-summarise only communities whose membership changed, with a worst case that could degrade toward normal indexing cost.

So the operating burden is not automatically a full rebuild after every edit. It is more precise and more demanding: define the invalidation unit. Which source change marks which community report stale? How soon must it be refreshed? Can queries read the previous report while refresh is running? Which corpus version and prompt produced the report now being cited?

Consider a daily incident corpus as an explicit illustration, not a reported deployment. An eager index produces a “recurring causes” report on Monday. Tuesday's incidents create a new relationship that moves two entities into another community. If the Monday report is still eligible for Tuesday's answer, freshness is now part of the product SLA. You did not only buy retrieval. You bought a derived data product with lineage, invalidation and serving rules.

Even a small archive needs that separation. If I materialise a topic summary over a set of reports, I need the source date, summary version and refresh receipt. An immutable source does not make its derived summary current. Smaller corpus, same derived-data obligation.

This is the same unglamorous work behind semantic infrastructure for data agents: model-written context is useful only while the organisation can say what it means, what it covers and whether it is still true.

LazyGraphRAG moves the bill to the question

Microsoft's November 2024 LazyGraphRAG comparison keeps graph structure but removes LLM summarisation from indexing. It extracts noun phrases and co-occurrences, then waits. When a question arrives, it expands the query, traverses relevant communities, tests source text for relevance and extracts query-specific claims before reducing the answer.

Microsoft reported indexing at 0.1% of full GraphRAG's cost and comparable global-answer quality at more than 700 times lower query cost. Those ratios are striking and should remain attributed. The test used 5,590 licensed AP articles, 100 synthetic questions split between local and global, and pairwise LLM judging. I found no independent reproduction in the cited material. Treat the numbers as a vendor benchmark that earns a trial, not a procurement constant.

The more durable result is architectural: lazy work is naturally attached to a question and a corpus version. It avoids maintaining a library of answers nobody may ask for. That makes it the cleaner default for streaming data, exploratory analysis and low-repeat workloads — exactly the use cases Microsoft names.

The exception gives away the buying rule

Microsoft also says full GraphRAG summaries have value beyond question answering because people can read and share them as reports. That is the exception I would use to approve eager summarisation. If a community report is a deliverable — opened by an analyst, reviewed on a cadence, fed into another governed workflow — precomputation has a consumer before the query does.

Before choosing eager GraphRAG, put five fields in the design review: report consumer, expected reuse, invalidation unit, freshness target, and evaluation set. “The graph might answer better” fills none of them. A stable corpus with repeated global questions may pass. A fast-moving corpus with one-off investigation usually will not. Benchmark both paths on your questions, with human review, and include refresh cost rather than comparing query invoices alone.

That test also stops a familiar category error. The graph can be valuable without every graph-derived summary deserving permanent storage. Structure and timing are separate choices.

Default to building the graph early and the answer late; precompute community reports only when the reports themselves have a named reader, a refresh owner and a reason to exist before the question.