GraphRAG vs. plain RAG vs. hybrid — measured on real corpora

The GraphRAG-versus-RAG debate has been running hot since Microsoft’s paper landed. Most of the writing on it is bimodal: GraphRAG is the future and plain RAG is dead, or GraphRAG is overengineered and plain RAG plus a good reranker is all you need. The truth, as usual, is more boring and more conditional.

We ran the three patterns — plain RAG, GraphRAG, and a hybrid configuration we will describe — against three corpora chosen to span the conditions where the patterns are claimed to matter. We measured answer quality (against a held-out eval set), latency, and indexing cost. This piece is the result.

The three patterns

Plain RAG. Standard chunk-and-embed pipeline. Chunks are stored in a vector store. Retrieval is top-k cosine similarity. The retrieved chunks are passed to the generation step. We ran this with a high-quality reranker (Cohere’s rerank-3) on top because that is what a competent team would do in production.

GraphRAG. The pattern from the Microsoft paper, simplified. An index-time pass extracts entities and relationships from the corpus and stores them as a graph. A second pass clusters the graph and generates summaries per community. At query time, the query is routed to the relevant communities, the summaries inform the answer, and (optionally) chunks from the original corpus are still retrieved as ground-truth.

Hybrid. Plain RAG plus graph-derived “context cards” at query time. We use the graph for entity disambiguation and for fetching a small set of related entities, but we keep retrieval primarily on the vector side. The graph is a thin layer, not the backbone.

The three corpora

We picked corpora to span the conditions where the patterns are claimed to differ:

• Engineering docs. A 50k-page corpus of internal engineering documentation from a partner team. Lots of named systems, lots of cross-references, moderate density of factual claims.
• Customer support transcripts. A 200k-conversation corpus of customer support chats. Lots of named products, lots of issues, semi-structured at best.
• Policy and regulation. A 30k-document corpus of regulatory text. Cross-references between rules are dense; the language is precise; the failure mode is “missed the exception.”

Each corpus has a held-out eval set of 200 questions with hand-graded ground-truth answers. The graders did not know which retrieval pattern produced which answer.

Results: answer quality

Quality is the median grader score (1–5 scale) on the held-out eval set. The graders were instructed to score for completeness and accuracy, not for prose style.

The pattern is not “GraphRAG wins” or “plain RAG wins.” It is “the right pattern depends on the corpus.”

For engineering docs, hybrid wins. The graph helps disambiguate named systems (which the plain-RAG pipeline confuses); the vector retrieval handles the rest. GraphRAG alone is worse than plain RAG because the community summaries lose the specificity engineers need.

For customer support, GraphRAG underperforms substantially. The corpus has so much noise (greetings, off-topic, repetitions) that the graph-extraction step pulls a lot of low-value entities, and the community summaries become low-quality. Plain RAG and hybrid are tied; the graph layer is not earning its keep.

For policy and regulation, GraphRAG wins decisively. The cross-references between rules are the work; the graph models them natively; the plain-RAG pipeline misses too many “see also” connections to give correct answers. Hybrid edges out pure GraphRAG by adding the precision of vector retrieval back in.

Results: latency

Latency is p95 over 1,000 queries, end-to-end (retrieval + generation).

GraphRAG is slow. The query-time routing to relevant communities adds a step, the community summaries are larger context windows than chunk lists, and the generation step takes longer with bigger context. If your application is latency-sensitive, the trade-off is real.

Hybrid pays a small latency tax on top of plain RAG because of the graph-side lookup. It is much less than the GraphRAG tax.

Results: indexing cost

Cost is per million tokens indexed, on our indexing pipeline at provider list rates.

GraphRAG indexing is expensive. The entity-extraction step calls the LLM on every chunk. The community-summary step calls it again on every cluster. For a 50M-token corpus, that is a $700 indexing bill at current rates, against $20 for plain RAG. If your corpus changes daily, this is a real cost. If it changes quarterly, less so.

Hybrid is in between. The graph layer is thinner so the entity-extraction work is smaller.

What we would tell a team picking today

The decision tree is more conditional than either camp would have you believe. Three questions to ask:

1. Does the corpus carry rich cross-references between entities? If yes, the graph layer is earning its keep. Policy, regulation, dense engineering docs, scientific literature — all candidates. If no — if the corpus is noisy, semi-structured, or conversational — the graph layer is overhead.
2. Is your latency budget tight? GraphRAG’s latency tax is real. Hybrid is much friendlier. Plain RAG is the fastest path.
3. How often does the corpus change? A daily-changing corpus makes GraphRAG indexing expensive. A quarterly-changing corpus makes the indexing cost a rounding error against the query cost.

If you have a small, stable, cross-referenced corpus with a relaxed latency budget, GraphRAG or hybrid is probably right. If you have a large, noisy, conversational corpus, plain RAG plus a reranker is probably right. The most common case in production — engineering docs, internal knowledge base, product documentation — is the hybrid case.

What we missed

Three things we are deliberately not claiming.

The first is multilingual corpora. We did not test on a non-English corpus. The entity-extraction quality varies meaningfully across languages and the GraphRAG numbers above would not hold on a French or Mandarin corpus without a separate methodology pass.

The second is question type. We tested broad question types but did not segment results by question complexity. GraphRAG is claimed to win specifically on multi-hop questions. Our data is consistent with that claim but does not isolate it cleanly.

The third is the production pattern of incremental updates. We indexed each corpus once. Real production GraphRAG systems incrementally update the graph as the corpus grows. The cost and quality math under incremental update is a different piece.

We will revisit the methodology in a future issue. For now: the GraphRAG-versus-RAG question does not have a universal answer, the conditions that matter are corpus shape, latency budget, and update frequency, and the most production-friendly pattern in the middle of those conditions is the hybrid one.

— The Editorial Team