When is a graph RAG index not worth its build and refresh cost?

## Where the money goes Graph RAG's cost is dominated by index-time LLM work, and it comes in four distinct buckets. **Extraction** runs at least one model call per chunk to pull entities and relations, sometimes several passes for higher recall. This scales linearly with corpus size and is the single largest line item on a large corpus. **Entity resolution** adds blocking, similarity scoring and adjudication of the ambiguous band, where the adjudicator is often another model call or a human. **Community detection and summarisation** clusters the entity graph and then writes a summary per community — and, because the clustering is hierarchical, per community *at each level* you intend to serve. This multiplies with how many levels you keep. **Refresh** is the recurring bill and the one most often left out of the business case. Appending new documents is cheap; keeping the structure correct is not. Against this, query-time cost for local traversal is comparable to ordinary RAG, while global map-reduce answering is substantially more expensive per query. So the shape is: high fixed cost, moderate marginal cost, and an unusually expensive premium query class. ## The refresh problem A new batch of documents introduces new entity mentions, some of which are new surface forms of existing entities and some genuinely new. Extraction on the new chunks is straightforward. What is not straightforward is that new nodes and edges change the community structure — a cluster may now split, or two may merge — and every summary built from an affected community is now describing a corpus that no longer exists. The options are all compromises. Full rebuild gives correctness at full cost and is only viable on slow-moving corpora. Incremental attachment extracts from new documents, resolves against existing nodes, and appends edges without reclustering — cheap, but community summaries drift stale and global answers silently reflect an older corpus. Periodic reclustering of affected regions splits the difference and is what most production systems settle on, with a scheduled full rebuild as a backstop. The decision rule follows from the query mix: if global queries matter, staleness is a correctness issue and refresh cadence must be tight. If almost all queries are local traversals, stale summaries barely matter and incremental attachment is fine. ## Signals the graph is not worth it **The query log is mostly single-hop.** Instrument first. If eighty percent of questions are answerable from one passage, the graph is being paid for by queries that never touch it, and better chunking, metadata filters or a reranker will move the aggregate number more per unit of spend. **The corpus churns faster than it rebuilds.** An incident-response knowledge base ingesting continuously cannot support a rebuild cadence that keeps summaries meaningful. Structure that is always stale is worse than no structure, because it is trusted. **Entity density is low.** Extraction over narrative prose with few named entities and few explicit relations produces a sparse, noisy graph. The graph's value comes from real relational structure in the source material; if the documents do not contain it, extraction will hallucinate a thin version of it. **The corpus is small enough for long context.** If everything fits comfortably in a modern context window, multi-hop and even aggregate questions can often be answered by giving the model the whole corpus. That baseline should be beaten, not assumed away. **A cheaper technique reaches parity.** Query-side decomposition handles a good share of multi-hop questions without index-time cost. Structured metadata and filters answer many aggregate questions exactly, and better than any summary. If a cheap option gets within a few points on your eval set, the graph's remaining gain has to justify its whole build and refresh bill. ## How to decide, concretely Do not decide architecturally. Run the experiment. First, label a sample of the real query log by class: single-fact, multi-hop, corpus-aggregate. That distribution is the size of the prize and takes an afternoon. Second, build the graph over a representative slice of the corpus, not all of it. Measure build cost per document and extrapolate; teams are routinely surprised by a factor of several. Third, evaluate against the vector baseline on the same slice, and report **cost per correctly answered query** broken down by query class rather than a single quality score. A graph that wins overall by three points while costing six times as much has told you to adopt it selectively, not globally. Fourth, price refresh explicitly at your real ingest rate, including whatever reclustering cadence the global query class demands. The common right answer is partial adoption. Graph the entity-dense, high-value subdomain — the contract corpus, the safety-signal corpus — and route only queries about it to the graph, leaving everything else on the vector index. That captures most of the benefit at a fraction of the build and refresh bill, and it keeps the failure blast radius small if resolution quality turns out to be worse than the pilot suggested.