GraphRAG: When Knowledge Graphs Meet Retrieval
Standard retrieval augmented generation finds passages that look similar to a question and hands them to a language model. It works well for direct questions whose answer sits in one paragraph. It struggles when the answer requires connecting facts that live in different places. GraphRAG fixes that by retrieving from a knowledge graph instead of, or alongside, a pile of text chunks. The model gets facts and their connections, not just passages that happen to share words with the question.
Where plain RAG runs out
Ask a plain RAG system "which of your restaurants is open late and allows children?" The retriever looks for chunks similar to that sentence. It finds a chunk about late opening hours and a chunk about the child policy, possibly for different restaurants, possibly incomplete. The model is left to stitch them together and often guesses.
The question is really two hops: find restaurants, check two properties on each. Text similarity has no concept of hops. A graph does, because hops are exactly what its edges are.
What GraphRAG does differently
In GraphRAG the business's knowledge lives as entities and relationships: Hotel has outlet Restaurant, Restaurant closes at 23:00, Restaurant allows children yes. When a question arrives, the system identifies the entities it mentions, walks the graph from those entities along the relevant relationships, and collects the facts it finds. That subgraph, the handful of nodes and edges that matter, is what gets handed to the model.
The model now sees: Restaurant A, closes 23:00, children allowed. Restaurant B, closes 21:00, children allowed. Restaurant C, closes 23:30, children not allowed. The answer is a simple read, with no guessing.
The two flavours
Local GraphRAG starts from specific entities in the question and explores their neighbourhood. It is precise and cheap, ideal for "tell me about this thing" questions.
Global GraphRAG works on summaries of whole regions of the graph, built in advance by clustering related entities. It answers broad questions like "what are the main themes in these reviews" that no single node could answer. Many systems combine the two: local for specifics, global for overview.
Why the model behaves better
Three things improve when the model receives a graph rather than loose text.
Precision rises. Facts arrive as explicit statements with named relationships, so the model is not inferring from prose.
Multi hop questions become tractable. The walk through the graph does the connecting; the model only has to read the result.
Answers become explainable. Because every fact came from a specific node and edge, the system can show its sources. "Restaurant A allows children" traces back to one record, not to a paragraph somewhere.
What it demands from you
GraphRAG only works when the graph exists. That means someone has to express the business's knowledge as entities and relationships, keep it current, and give each entity a stable identity. This is more effort than dumping documents into a vector store. It is also why the results are so much better, and why businesses that invest in a clean graph of their own facts are easier for any AI to reason about, whether that AI is theirs or someone else's.
The takeaway
Plain RAG retrieves text that resembles the question. GraphRAG retrieves facts and the connections between them. For anything that requires joining two or more pieces of information, the graph is what makes the answer reliable rather than lucky.