Standard RAG retrieves flat chunks of text by similarity. Graph RAG first builds a knowledge graph from your documents — entities as nodes, relationships as edges — and retrieves by walking those connections. Instead of "find text that looks like the question," it can answer "what connects these two things," which flat retrieval struggles with.

Why it matters

Some questions are about relationships, not passages. "Which policies were authored by the Finance team, and which of those mention receipts?" requires linking author to document to content — a chain no single chunk contains. Flat RAG retrieves chunks that mention "Finance" or "receipts" separately and hopes the model stitches them. Graph RAG encodes the links explicitly.

It shines on connected corpora: org structures, product dependencies, legal and compliance webs, research citations. For Northwind, a graph linking authors, document IDs, and topics lets you answer "show every Finance-authored policy that mentions a monetary limit" in one traversal.

The tradeoff to state plainly

Graph RAG costs more to build. You need an extraction step that turns unstructured text into entities and relationships, and that step is imperfect and worth evaluating. Reach for it when your questions are genuinely relational and flat RAG keeps failing on multi-hop reasoning — not by default.

How you build it

Extract entities and relationships from each document, store them in a graph database, and at query time traverse the graph to gather connected context before generating. A graph database connected over MCP lets Claude Code build, inspect, and query the graph directly in the session. A skill encodes your extraction schema — which entities you care about, which relationships, how you normalise them — so the graph is built the same way across every document and every project.