What is GraphRAG?
Try it: the Graph RAG playground builds a simple graph from your own document, without a model, and shows which passages it adds to plain RAG. Graphs built by a language model are coming soon.
GraphRAG is a way of doing retrieval-augmented generation that first turns your documents into a knowledge graph, a map of the things mentioned and how they are connected, and then uses that map to answer questions. It was introduced by Microsoft Research in 2024 and is aimed at the questions that ordinary RAG handles badly.
Where plain RAG falls short
Plain RAG retrieves the few passages whose text looks most like the question. That works when the answer sits in one place. It struggles with two kinds of question:
- Questions that connect several places. "What can I get money back for, and under what conditions?" needs facts from the returns section and the assembly section. Each passage on its own matches the question only weakly, so some are left out.
- Questions about the whole document. "What are the main topics of this handbook?" has no passage that answers it. The answer has to be assembled from everything.
What a knowledge graph is
A knowledge graph has two parts. Entities are the things: products, people, places, policies. Relationships are the links between them, each with a label. One link written out is called a triple: Frame, covered by warranty for, 5 years.
Here is a small graph built from the bike shop handbook used across this site. The highlighted links are the ones that answer "what can I get a refund for?".
How GraphRAG builds the graph
- SplitThe documents are cut into passages, as in plain RAG.
- ExtractA language model reads each passage and lists the entities and relationships in it.
- MergeThe same entity found in many passages becomes one node, with all its links.
- GroupClosely linked entities are gathered into communities, like topics.
- SummariseThe model writes a short summary of each community.
All of this happens once, before any question is asked. It is the expensive part, because the model is called for every passage and again for every community.
The example, step by step
From three passages of the handbook, the extraction step would produce triples like these:
| Entity | Relationship | Entity | Found in |
|---|---|---|---|
| Bike | can be returned within | 30 days | Returns |
| Return | gives | Full refund | Returns |
| Frame | covered by warranty for | 5 years | Warranty |
| Components | covered by warranty for | 2 years | Warranty |
| Assembly by a local shop | refunded up to | 40 dollars | Assembly |
Now ask "What can I get money back for?". Plain RAG looks for passages that share words with the question; the handbook says "refund", not "money back", so with word matching it finds nothing, and with meaning matching it most likely returns only the returns passage. GraphRAG finds the entity Refund, follows its links to Return and Assembly, and brings back both passages. The model can then answer: a full refund for a bike returned within 30 days, and up to 40 dollars towards assembly at a local shop.
Two ways of answering
| Local search | Global search | |
|---|---|---|
| Good for | Questions about particular things and how they connect | Questions about the whole collection: themes, summaries, comparisons |
| How | Find the entities in the question, follow their links, collect the connected passages | Read the community summaries, answer from each, then combine the partial answers |
| Cost per question | Similar to plain RAG | Higher: many summaries are read for one question |
What it costs
- Building is slow and uses many model calls. A plain RAG index needs no language model at all. A graph needs at least one call per passage, plus one per community. For a large document set that is the main expense. The token counter gives a feel for what a call costs.
- Quality depends on the extracting model. A weak model misses relationships or invents them, and every later step inherits those mistakes.
- Updates are harder. When a document changes, its entities and the communities they belong to have to be rebuilt.
- More to tune. What counts as an entity, how communities are formed and how long summaries are all affect the answers.
When it is worth it
- Use GraphRAG for large collections where questions cut across documents: research notes, case files, incident reports, long contracts with many cross-references.
- Stay with plain RAG for question-and-answer over manuals, policies and support articles, where each answer lives in one passage. It is cheaper, faster and easier to keep up to date.
- Try the cheaper fixes first. Many "RAG cannot connect things" problems come from passages that are too small or matching that is too literal. Larger passages, hybrid search and retrieving a few more passages often help, and you can measure the effect on the Compare page.
Words you will meet
- Entity or node: one thing in the graph.
- Relationship or edge: a labelled link between two entities.
- Triple: one entity, one relationship, one entity.
- Community: a group of closely linked entities, roughly a topic.
- Multi-hop question: one that needs two or more linked facts to answer.
On TryRAG: the Graph RAG playground finds entities by simple rules and links the ones mentioned in the same sentence, so you can see the idea working on your own text. Coming soon: building the graph with your own model, with named relationships as described above.
More guides
What is RAG? · How to choose a chunk size for RAG · What are embeddings? · What are tokens, and what do they cost? · Hybrid search: words plus meaning · How to test RAG retrieval · Seven common RAG mistakes