Ordinary RAG retrieves chunks that look like the query. That works when the answer sits in one passage. It fails when the answer has to be assembled from several, connected by relationships nobody wrote down in a single place.
"Which services did the engineer who owns the checkout queue also touch during last month's incidents?" has no chunk that resembles it. The answer is three hops through the relationships between people, services, and incidents.
Graph instead of pile
GraphRAG builds a graph first, extracting entities and the relationships between them, then retrieves by traversal:
(Engineer:Rae) -[OWNS]-> (Service:checkout-queue)
(Engineer:Rae) -[COMMITTED_TO]-> (Service:billing)
(Incident:4821) -[AFFECTED]-> (Service:billing)Retrieval becomes: find the node, walk the edges, return the subgraph. The model receives a small set of connected facts rather than ten chunks that each mention one of them.
What it buys and what it costs
Buys: multi-hop questions, aggregation across many documents ("what themes recur across every postmortem this quarter"), and provenance, since every returned fact has an explicit path you can show.
Costs: a build step that extracts entities and relationships, usually with an LLM, which is slow, expensive, and lossy. Your graph is only as good as that extraction, and schema drift over time is real. This is materially more machinery than a vector database.
When to reach for it
Reach for it when the questions are genuinely relational and your corpus has real structure to exploit: incidents, ownership, org charts, dependency trees, case histories. If your corpus is prose and your questions are answerable from a single passage, GraphRAG adds a large build pipeline for no gain.
Related terms
Retrieval-augmented generation (RAG)
RAG is the workhorse pattern of context engineering: retrieve the material relevant to a request, put it in the context, and let the model generate an answer grounded in it rather than guessing from memory.
Read definition →ConceptEmbeddings
An embedding turns a piece of text into a list of numbers that captures its meaning, so that similar ideas land near each other. Embeddings are what let you search by meaning instead of by exact keyword.
Read definition →ConceptChunking
Chunking is splitting a long document into smaller pieces before you embed and retrieve them. The size and overlap of the chunks decide what can be found as a unit, so it quietly makes or breaks a retrieval system.
Read definition →ConceptVector database
A vector database stores embeddings and finds the nearest ones to a query vector quickly. It is an index for meaning, and for small corpora you very often do not need one.
Read definition →