GraphRAG: Knowledge Graphs Meet Retrieval

Plain RAG misses the answer, because it searches for passages that look like the question. When the answer is a chain of facts spread over separate documents, no single passage looks like the question. GraphRAG, the method this guide explains, searches the links between things instead.

RAG, short for retrieval-augmented generation, means your code looks up related text first and pastes it into the prompt, the text sent to the model. The model, a large language model that reads and writes text, then answers from that text.

Picture a common setup. A procurement team at an auto-parts buyer near Chennai runs a research tool over about 4,200 documents: supplier audits, contracts, shipment notes and local news. The setup is made up, but the problem is real.

One Monday, heavy rain floods an industrial area in Hosur. An analyst asks the tool which brake suppliers on the watchlist depend on anything in Hosur. The tool replies that no brake supplier is based there.

It shows three news passages about the flood and two about brake pads. Each passage looks relevant, and none answers the question. The real answer takes the analyst two hours with a spreadsheet.

A 2025 audit report says Brake maker A buys its disc castings from Foundry F. A separate news item says Foundry F runs its only plant in Hosur. No single document mentions Brake maker A and Hosur together.

So a search that ranks passages by similar words or meaning has nothing to find. And it matters: Brake maker A supplies 30 percent of the brake pads for the team's biggest client, a car-maker. A two-week stop could cost that car-maker around Rs 40 lakh (4 million rupees) a day.

The question is not about similar words. It is about relationships: who buys from whom, and who sits where. The rest of this guide adds a graph to this tool, and shows where the team decides not to.

You need five words: entity, relationship, knowledge graph, hop and community. Each gets a plain meaning and an example from the supplier tool.

Entity. An entity is one named thing in your documents, such as a company, a plant, a town or a part. Example: Brake maker A, Foundry F and Hosur are three entities.

Relationship. A relationship is a typed link between two entities, written as subject, relation, object. Example: Brake maker A, buys castings from, Foundry F. Engineers call this three-part fact a triple.

Knowledge graph. A knowledge graph is a set of entities joined by relationships. Each entity becomes a node, a point, and each relationship an edge, a line between two points. The W3C, which sets web standards, defines a graph in its RDF 1.1 data format as a set of triples.

Hop. A hop is one step along one edge. Brake maker A to Foundry F is one hop. Brake maker A to Hosur, through Foundry F, is two hops.

Community. A community is a group of entities that link to each other far more than to the rest of the graph. Example: the Hosur foundries, the firms they supply and their transport firms may form one community.

GraphRAG is retrieval-augmented generation that searches a knowledge graph built from your documents, instead of only searching text chunks by similarity. It follows relationships between entities, then hands the connected facts and their source passages to the model.

Plain RAG usually means vector search. Each chunk is turned into an embedding, a list of numbers that captures its meaning. Search returns the chunks whose numbers sit closest to the question's numbers.

A 2024 survey of graph retrieval splits the method into three stages: graph-based indexing, graph-guided retrieval and graph-enhanced generation. In plain words, you build the graph, walk it to collect facts, then write the answer from them.

The name GraphRAG also points to one well-known 2024 paper by Edge and colleagues, revised in February 2025. It builds the graph with a model, groups entities into communities and writes a summary of each group in advance. This guide covers the general idea and that paper's community trick.

A picture from Haridwar

In Haridwar, priests called pandas keep handwritten family registers, called bahis, filed by a family's ancestral district and village. Entries record names, births, marriages and deaths, so a family line can be traced across generations.

Tell a panda your village and your father's name. He does not hunt for names that sound like yours. He opens your village's register, finds your father and follows the family links back to earlier generations and out to cousins who moved away.

Here is the small piece of the tool's graph that answers the Hosur question. Pause and predict: starting from the car-maker, how many hops does it take to reach the flood?

You build it by asking a model to read each chunk and list the entities and relationships it mentions. Your code then merges those lists into one graph, and every edge keeps a pointer to the chunk it came from.

A chunk is a small piece of a document, and a token is the unit a model reads, often a word or part of one. The GraphRAG paper used chunks of 600 tokens, with 100 tokens of overlap between neighbouring chunks.

Follow the diagram from the documents to the summaries. A model does the work in only two boxes. Everything else is ordinary code you can test like any data pipeline.

Extracting entities and relationships

Extraction means sending each chunk to the model with an instruction. The instruction asks for every entity with a name, type and short description, and every relationship between them. The output comes back as structured data your code can store.

Models miss things on the first pass. The paper adds extra rounds it calls gleanings: it asks the model whether any entities were missed and, if so, asks it to extract again, up to a set maximum. Its first version used one gleaning round on a podcast dataset and none on a news dataset.

Merging entities that are the same thing

Entity resolution means deciding that two names point to the same real thing. A contract says Foundry F Pvt Ltd, and a news item says Foundry F. If they stay as two nodes, the chain from Brake maker A to Hosur breaks.

The team merges in two passes. Plain code first matches exact registration numbers, such as a firm's GST (goods and services tax) registration number. Then a model compares the leftover close names and their descriptions, and a person reviews any merge the model is unsure about.

Finding communities

Community detection is a graph algorithm that groups nodes which link to each other far more than to outsiders. The GraphRAG paper uses the Leiden algorithm in levels: it finds big groups, then smaller groups inside each one.

Leiden, published in Scientific Reports in 2019, improved on the older Louvain method. Its authors showed Louvain can return badly connected communities, and in the worst case disconnected ones. Leiden guarantees every community it returns is connected, meaning you can walk between any two members without leaving the group.

GraphRAG answers in one of two ways. Local search starts at the entities named in the question and walks a few hops. Global search reads community summaries to answer questions about the whole collection.

Be precise about who describes which. The GraphRAG paper builds and tests only the global path. Walking out from named entities is a common pattern in the 2024 survey, such as taking a question's entities and their two-hop neighbours. HippoRAG, covered below, also starts from the question's entities.

The Hosur question is local. It names an entity and asks what connects to it. Here is how the tool handles it now.

1. 1

   Spot the entities in the question

   A small model call pulls out the entity names, here Hosur, plus the target type, here brake suppliers.

2. 2

   Match them to nodes

   Code looks up Hosur in the graph, using the same merge rules as indexing, and finds the Hosur industrial area node.

3. 3

   Walk the edges

   Code walks backwards from Hosur up to 2 hops, collecting the paths it finds. It finds Foundry F at hop 1 and Brake maker A at hop 2.

4. 4

   Keep only what was asked

   Code keeps paths that end at a brake supplier. Brake maker A stays, and firms of other kinds that also use Hosur plants drop out.

5. 5

   Fetch the source chunks

   Each edge on a kept path points to its chunk. The audit report line and the news line both go into the prompt.

6. 6

   Write the answer with its path

   The model answers that Brake maker A is exposed through Foundry F, and shows both documents so the analyst can check them.

There are other ways to walk a graph. HippoRAG, a 2024 method, ranks nodes with Personalized PageRank: the chance that a random walk, which keeps jumping back to your starting nodes, lands on each node.

On multi-hop question benchmarks, its authors report that one round of HippoRAG matched or beat IRCoT, a method that searches several times in a row. They also report it was 10 to 30 times cheaper and 6 to 13 times faster.

Community summaries are short reports a model writes in advance, one for each group of closely linked entities. They let GraphRAG answer big-picture questions that no handful of passages could cover.

For its quarterly review, the team asks a second kind of question. It wants to know which risks keep showing up across its casting suppliers this year.

Vector search returns the top five passages, and five passages cannot show a pattern spread across 4,200 documents. Local search does not help either, because the question names no single entity to start from. The GraphRAG paper calls these global questions.

The paper turns community summaries into one answer in three steps. It calls the middle two steps map and reduce, after the pattern of answering in pieces and then combining the pieces.

• Prepare: shuffle the community summaries and pack them into batches of a set token size.
• Map: for each batch, the model writes a partial answer and scores how helpful it is, from 0 to 100. Partial answers scored 0 are dropped.
• Reduce: sort the rest by score, add them to one prompt until it is full, and ask the model to combine them into one final answer.

Here is the full question path in the supplier tool. Start at the question and look at the first box: a router decides which kind of question it is before any search runs.

Vector RAG finds passages whose meaning is close to the question, while GraphRAG finds facts connected to the question's entities. One ranks by similarity, the other follows relationships.

Neither one wins everywhere. Many questions in the tool are plain lookups, like the payment terms in one contract. For those, vector search, or a hybrid of keyword and vector search, is cheaper and answers just as well.

Use GraphRAG when your questions depend on how things connect, or on patterns across a whole collection. Stay with plain RAG when most answers sit inside a single passage.

These signs point toward GraphRAG:

• Questions often chain two or more facts, like a supplier's supplier, or a director who sits on two boards.
• Your documents name the same entities again and again: companies, people, parts, places.
• Users ask about themes or trends across everything, not about one document.
• Users must see why an answer is true, and a path of named links is easier to check than a pile of passages.

These signs say plain RAG is enough:

• Most questions are lookups, like a clause in one contract.
• Documents are long prose with few named entities, such as policy essays.
• Content changes every hour and you cannot afford to re-extract that often.
• Nobody on the team can review merges and test extraction quality.

The supplier tool ends up with both. Vector search answers lookups, the graph answers dependency questions, and summaries answer quarterly reviews. The Hosur question now takes about 8 seconds instead of two hours (made up).

You walk it with a breadth-first search, which visits every node one hop away, then every node two hops away, and so on. The walk is plain code, not a model call. The file below runs as it is; we ran it on Python 3.13.

Each triple carries the id of the chunk it came from. The walk goes backwards along edges, from an object to the subjects that point at it, because the question asks who depends on Hosur.

from collections import defaultdict

# Each fact: (subject, relation, object, id of the chunk it came from)
triples = [
    ("Car-maker", "buys brake pads from", "Brake maker A", "contract-17"),
    ("Car-maker", "buys brake pads from", "Brake maker B", "contract-22"),
    ("Brake maker A", "buys castings from", "Foundry F", "audit-2025-031"),
    ("Brake maker B", "buys castings from", "Foundry G", "audit-2025-044"),
    ("Foundry F", "has its plant in", "Hosur", "news-0912"),
    ("Foundry G", "has its plant in", "Coimbatore", "news-0870"),
]

def build_incoming(triples):
    incoming = defaultdict(list)
    for subj, relation, obj, chunk_id in triples:
        incoming[obj].append((subj, relation, chunk_id))
    return incoming

def who_depends_on(incoming, start, max_hops=2, max_paths=200):
    seen, frontier, paths = {start}, [start], []
    for hop in range(1, max_hops + 1):
        next_frontier = []
        for node in frontier:
            for subj, relation, chunk_id in incoming[node]:
                if subj not in seen and len(paths) < max_paths:
                    seen.add(subj)
                    next_frontier.append(subj)
                    paths.append((hop, subj, relation, node, chunk_id))
        frontier = next_frontier
    return paths

for hop, subj, relation, obj, chunk_id in who_depends_on(build_incoming(triples), "Hosur"):
    print(hop, subj, "|", relation, "|", obj, "|", chunk_id)

Run it and you should see exactly these two lines. Each line gives the hop, the fact and the chunk to cite.

1 Foundry F | has its plant in | Hosur | news-0912
2 Brake maker A | buys castings from | Foundry F | audit-2025-031

Three parts of the code matter. The incoming index lets the walk go from Hosur back to the firms that depend on it. The seen set stops the walk from looping when two firms buy from each other.

The max_hops and max_paths limits keep one walk's output small. In our test, a port linked to 500 firms, each with 20 customers, gave 10,500 paths uncapped (500 at hop 1, 10,000 at hop 2) and 200 capped. The cap does not stop the scan, though: a port with a million edges still had all of them checked once.

One limit is easy to miss. The seen set records each firm once, by the first path that reaches it. If a firm depends on Hosur through two different foundries, only the first route is listed.

It runs map and reduce over the summaries: one model call per batch writes a scored partial answer, and one final call combines the best of them. The code below shows that control flow.

The ask_model function here is a stand-in, so the file runs without a model. A real system replaces it with a call to your model provider. The stand-in scores a batch by how many summaries mention castings.

def ask_model(instruction, question, texts):
    # Stand-in for a real model call, so this file runs on its own.
    if instruction.startswith("Combine"):
        return "FINAL: " + " / ".join(texts)
    hits = [t for t in texts if "casting" in t.lower()]
    return f"{min(100, 40 * len(hits))}|" + "; ".join(hits)

def parse_score(reply):
    score, _, text = reply.partition("|")
    return int(score), text

def answer_global(question, summary_batches, keep=8):
    partials = []
    for batch in summary_batches:              # map: one call per batch
        reply = ask_model("Score 0 to 100, then answer from these summaries.",
                          question, batch)
        score, text = parse_score(reply)
        if score > 0:                          # drop batches with nothing to say
            partials.append((score, text))
    partials.sort(key=lambda p: p[0], reverse=True)
    best = [text for score, text in partials[:keep]]
    print("batches:", len(summary_batches), "kept:", len(best))
    return ask_model("Combine these partial answers into one.",
                     question, best)           # reduce: one final call

batches = [
    ["Community 3: Hosur foundries, flood risk to casting supply",
     "Community 8: Chennai port transport firms, shipping delays"],
    ["Community 5: Coimbatore foundries, power cuts slow casting output"],
    ["Community 9: tyre suppliers, rubber prices"],
]
print(answer_global("What risks keep showing up across our casting suppliers?", batches))

Run it and you should see these two lines:

batches: 3 kept: 2
FINAL: Community 3: Hosur foundries, flood risk to casting supply / Community 5: Coimbatore foundries, power cuts slow casting output

The score check matters most. Most communities have nothing to say about casting risks, and dropping their empty answers keeps the final prompt short. The paper also shuffles summaries before batching, which this sketch leaves out.

It showed better coverage on whole-collection questions, judged on two datasets of about 1 million and 1.7 million tokens: podcast transcripts and news articles. It did not test the local, entity-walking questions this guide began with.

A model compared pairs of answers on comprehensiveness and diversity, meaning how much the answer covers and how many different angles it gives. Its February 2025 revision reports that its global approaches beat plain vector RAG in 72 to 83 percent of comprehensiveness comparisons on podcasts. That label also covers a graph-free version that summarises the source text directly. On news, the range was 72 to 80 percent.

Diversity win rates were 75 to 82 percent on podcasts and 62 to 71 percent on news. Plain vector RAG still gave the most direct answers in every comparison, which the authors expected, since directness trades off against coverage.

The top-level summaries were also cheap at question time. The paper reports they needed over 97 percent fewer tokens per question than summarising the source text directly. Even so, these graph summaries alone still beat plain RAG in 72 percent of comprehensiveness and 62 percent of diversity comparisons.

GraphRAG costs far more to build than a vector index, because a model must read every chunk, once more per gleaning round, and write every community summary. Keeping it fresh costs more too, since new facts can reshape communities.

The team does the maths before building anything. Its 4,200 documents make about 38,000 chunks. Extraction with one gleaning round averages Rs 1.50 a chunk, so about Rs 57,000, and summaries add about Rs 8,000 (all made up).

Time adds up as well. In the paper's revised version, indexing the podcast dataset, about 1 million tokens in 600-token chunks, took 281 minutes using a hosted model. Larger chunks mean fewer model calls, but on one sample dataset the paper's model found almost twice as many entity references with 600-token chunks as with 2,400-token ones.

Freshness is the harder problem. About 60 new documents reach the tool each day, mostly news. Some add new links, and some make old links false, like a firm moving its plant from Hosur to Ranipet.

• Every night, extract triples from new chunks only and merge them into the graph.
• Store a date on each edge, and let a newer document mark an older edge as replaced instead of deleting it.
• Re-run community detection once a week, not every night, because it looks at the whole graph.
• Re-write summaries only for communities whose members or edges changed since the last run.
• When a document is withdrawn, remove every edge that points to its chunks.

Quality needs checks too, because extraction fails quietly. A missed edge raises no error; the graph just never shows that link. So the team keeps 50 known supply chains, written by analysts, and checks weekly how many the walk still finds.

Explain it as vector RAG plus a graph built at indexing time, and justify the graph with a question that plain RAG cannot answer.

1. 1

   Start with plain RAG

   Draw chunking, embeddings, vector search and the answer step. Say it works when one passage holds the answer.

2. 2

   Show a multi-hop failure

   Give a question whose answer is a path across two documents, like a supplier's foundry in a flooded town.

3. 3

   Add the indexing pipeline

   Extraction with fixed entity and relation types, entity merging, a graph store, community detection and summaries.

4. 4

   Split the question paths

   A router sends named-entity questions to a graph walk, big-picture questions to summaries, and lookups to vector search.

5. 5

   Put the limits in code

   Cap hops and paths, store a source chunk and date on every edge, and test against known chains.

6. 6

   Talk about cost and freshness

   Estimate model calls per chunk, then explain nightly updates, weekly community runs and selective re-summarising.