GraphRAG and knowledge graphs

Read these first

• Retrieval strategies for RAG

What you will know

• Extract entities and relations into a graph from a corpus

  Define entity resolution and relation provenance, because duplicate names and unsupported edges can poison every downstream path.

• Answer a multi-hop question that flat retrieval cannot

  Use a held-out question whose evidence spans documents, then expose the intermediate nodes and citations rather than accepting a plausible final sentence.

• Measure the ingestion cost of a graph against flat chunking

  Include extraction calls, retries, storage, indexing, and refresh work; update-heavy corpora can erase the apparent retrieval benefit.

• Decide against it for a corpus that doesn't need it

  Sparse or mostly independent facts gain little from graph traversal while inheriting schema, extraction, and consistency failure modes.

• Justify it with an eval rather than an intuition

  Compare against flat retrieval on multi-hop accuracy, citation support, latency, and total cost using a representative held-out set.

Chapters

1. 1

   A multi-hop question has no chunk that resembles it, at any k

   Asking for the refund window for EU customers is answered by flat top-k; asking which product lines depend on suppliers hit by the Shenzhen factory fire is not, and the reason is structural rather than a matter of difficulty. The chunks naming the factory's tenants never mention your product lines, so no k retrieves them. What is missing is a second retrieval conditioned on the first, which query decomposition also supplies — so the graph earns its place only under stated conditions: the number of hops is not known in advance, the intermediate entities cannot be named from the question, or the same traversal is amortised across many queries.

   Read chapter
2. 2

   Seed nodes, a hop budget and community summaries make a graph answerable

   Before the failure modes, the machine itself. Extraction asks a model, document by document, to emit entities and relations conforming to a declared schema — which node types exist, which relations are permitted between them — and everything downstream inherits whatever that schema could not express. Over the assembled graph runs a community-detection and summarization pass: cluster densely connected nodes, write an LLM summary per cluster, and you can answer broad questions no single traversal reaches, at a cost of one call per community and a re-run whenever edges move. At query time the question binds to seed nodes, expands under a hop budget, and hands the generator the intermediate nodes along with the document behind each edge, which is what a citation over a traversal actually is.

   Read chapter
3. 3

   Four Acme nodes give every traversal a quarter of the edges

   Extracting entities and relations from 200,000 support tickets yields Acme Corp, Acme Corporation, ACME and Acme Inc. as four separate nodes, so a traversal starting from any one of them sees roughly a quarter of the relationships. Nothing in the trace marks the other three-quarters as missing, which is why the partial answer reads as complete. Covers entity resolution as a first-class ingestion step rather than a cleanup pass.

   Read chapter
4. 4

   An edge with no source document is indistinguishable from an invention

   Six months into production an answer cites that Acme Corp supplies Northwind, and no document in the corpus says so; the edge came from a badly OCR'd PDF where two table columns ran together. The system cannot tell an edge somebody asserted from one extraction fabricated, and that is the defect the incident exposed. Here you attach provenance to the edge itself and weigh an LLM re-read pass against what it can actually verify.

   Read chapter
5. 5

   Independent opinions have no hop to traverse

   Four million product reviews, each a complete independent opinion, answering questions of the form what people say about battery life on a given model: there is nothing to traverse, and flat retrieval already handles aggregate questions over independent facts well. Rebuilding as GraphRAG here buys no accuracy and inherits the entity-resolution, provenance and schema failures of the previous chapters. This chapter states the corpus properties that make traversal worth the machinery.

   Read chapter
6. 6

   Extraction is a run rate, not an invoice, once the corpus churns

   Costing a graph over 500,000 documents, the per-document extraction calls dominate, and estimates routinely omit retries on malformed output, the community summarization pass over the assembled graph, and re-extraction on every source change. At 3% daily churn the corpus turns over in about five weeks, so a one-off projection is really a monthly bill. Re-extraction is not local either: a revision can contradict edges elsewhere and stale the summaries built on them. Nor does everything scale with document count — entity resolution grows with pairwise node comparisons and summarization grows with graph size — which is what makes a flat 60x projection from a snapshot wrong twice over.

   Read chapter
7. 7

   Show the traversal, then run flat retrieval at the same budget

   A reviewer unconvinced that the graph answered something flat retrieval could not is asking the right question. Settle it by exposing the traversal, intermediate nodes and the document asserting each edge, then running flat retrieval at the same context budget. Score held-out questions from the real query log on whether cited evidence supports the answer, and when the result is 76% against 72% at nine times the cost, ask where those four points concentrated.

   Read chapter