# GraphRAG Explained: When Knowledge Graphs Beat Vector Search

> What GraphRAG is, how graph-based retrieval differs from vector RAG, the query shapes where it wins, and the honest costs before you build one.

GraphRAG augments retrieval with a knowledge graph: entities and relationships extracted from your corpus, traversed at query time. Vector RAG answers 'find passages like this'; GraphRAG answers 'connect these things' — multi-hop questions, whole-corpus summaries, relationship queries. The cost is real: graph extraction is expensive and quality-critical.

Vector [RAG](/glossary/rag) has a structural blind spot: it retrieves passages that *resemble the question*. Ask something whose answer is **assembled from connections** — across documents, through relationships, over the whole corpus — and no chunk resembles the question, so retrieval returns fragments and the model improvises. **GraphRAG** is the fix for exactly that class of question: retrieval over a knowledge graph instead of a similarity index.

## The mechanism

GraphRAG moves the hard work to **index time**. An LLM pass over the corpus extracts *entities* (people, systems, companies, concepts) and *relationships* (X supplies Y, A depends on B), building a knowledge graph; most implementations — Microsoft's reference one popularized the pattern — also cluster the graph into communities and write **community summaries** at several levels, giving the corpus a hierarchical map.

Query time then has two new moves unavailable to vector search:

- **Local traversal** — resolve the question's entities, walk their neighborhoods (1–3 hops), and assemble the connected evidence: the multi-hop answer path.
- **Global summarization** — answer corpus-level questions ("dominant failure modes across all incident reports?") from community summaries rather than top-k chunks, which is the only honest way to "retrieve" something whose answer is *everywhere*.

## Where it wins — and loses

**Wins:** multi-hop questions (the chain `A→B→C` exists in three documents, none containing the question's vocabulary); global/thematic questions; relationship-first domains — org knowledge, codebases and their dependency structure, investigations, compliance webs. In these, vector RAG's failure isn't marginal, it's categorical.

**Loses:** cost and fragility. Index construction is LLM extraction over everything — a real bill, repeated as documents change. Extraction quality becomes load-bearing: a missed relationship is a silently unanswerable question; a hallucinated one is worse. And you've added an index type to operate. For needle-in-haystack lookups — most queries in most products — plain [vector retrieval with reranking](/guides/concepts/hybrid-search-reranking) stays simpler and equally good.

> [!TIP]
> Route, don't bet. The mature pattern is hybrid: classify incoming queries by shape (lookup vs connection vs global) and send each to the cheap index that answers it. GraphRAG as *a* retriever, not *the* pipeline.

## Building one without regret

1. **Audit your failed queries first.** GraphRAG is justified by a corpus of questions vector RAG demonstrably fumbles — multi-hop and global ones. No such corpus, no project.
2. **Scope the ontology.** Extract the few entity/relationship types your questions actually traverse; "extract everything" balloons cost and noise.
3. **Start with the reference shape** — extraction → graph → communities → summaries — on a corpus slice; measure answer quality against your failure set before indexing everything. The [graphrag-scaffolder](/skills/data/graphrag-scaffolder) skill stands up exactly this experiment.
4. **Plan the update path.** Incremental re-extraction on changed documents is the difference between a system and a demo.
5. **Keep the vector index.** You'll still want it for the lookup-shaped majority; the win is the router.

GraphRAG is the most substantive extension of the RAG pattern since [reranking](/glossary/reranking) — and the most oversold. The test is your queries: if their answers live in connections, the graph pays; if they live in passages, you already have the right architecture — see [How RAG Actually Works](/guides/concepts/how-rag-works) and, for the other 2026 evolution of the pattern, [Agentic RAG](/guides/concepts/agentic-rag).

---

_Source: https://agentscamp.com/guides/concepts/graph-rag — Guide on AgentsCamp._