Connect the facts first, then compare the three approaches.
GraphRAG: connect the facts first
Knowledge graph
A set of entities (nodes) joined by labelled relationships (edges), stored as triples: (billing, owned_by, Payments).
GraphRAG
Retrieval that uses a knowledge graph built from the documents. Questions are answered by traversing edges (and, in some designs, by summaries of clusters of related nodes) instead of, or as well as, searching text.
Building the graph is a one-time pass over every passage: a model reads each chunk and extracts triples. Then "Which office does the manager of the team that owns the billing service work in?" is three edge lookups and zero text searches.
The graph built from the wiki: 12 edges from 20 passages, and one edge the extraction missed
Things a graph does well:
Multi-hop questions run as a short walk.
Reverse and aggregate questions such as "Which services does the Payments team own?" follow edges backwards and collect everything, where a text search may return only some of the passages.
Thematic questions ("what are the main topics?") can be answered from cluster summaries built on the graph, which no single search can do. (The example does not implement this; see Hard 3.)
Things it does badly or at a cost:
Construction cost. Every passage is read by a model at index time. This can be prohibitive for large corpora.
Extraction quality. Entities are easy; relationships are hard. In the example, "The Discovery team reports to Tomas Berg" did not match the schema, so the edge is missing and every question that goes through the Discovery manager fails (graph accuracy: 83%, 75%, 67% on two-, three- and four-hop questions), although the text plainly contains the answer.
Freshness. The graph is a copy. When the Payments manager changes, a graph built earlier still says Priya Nair; it needs re-extraction. The agentic system, which searches current text, answers correctly at once.
Entity resolution. "Payments", "the Payments team" and "Payments group" must be recognised as one node, or the walk breaks.
Comparing the three
Share of questions answered exactly right, by kind of question
System
1 hop
2 hops
3 hops
4 hops
List
No answer
All
Searches
Model calls
single pass
100%
0%
0%
0%
50%
100%
42%
1.0
2.0
agentic loop
100%
100%
100%
100%
100%
100%
100%
2.1
3.1
graph
100%
83%
75%
67%
100%
100%
88%
0.0
1.0
Situation
single pass
agentic
graph
one outdated passage contradicts a current one
38%
92%
79%
... with "newest passage wins"
42%
100%
88%
manager changed, graph not rebuilt
n/a
correct
stale answer
per-question cost
lowest
highest (loops)
lowest at question time, high at build time
How to read this:
The three systems fail for different reasons: single pass for lack of connection, the loop for cost and loop risk, the graph for extraction misses and staleness.
All three correctly return nothing for the three no-answer questions. In a real system "nothing found" is a decision the agent must be built to make (module 5's gate).
Accuracy here depends heavily on my choice of corpus. Do not carry any of these percentages elsewhere.
Choosing
If your questions are...
Start with
mostly single-fact lookups
plain hybrid RAG (modules 1 to 3)
sometimes chained ("the X of the Y of Z") over changing documents
agentic RAG with a step limit
about relationships across a large, fairly stable corpus (org charts, dependencies, citations) or about themes
GraphRAG, accepting build cost
both
agentic loop whose tools include a graph query
Rules of thumb: add the loop only for the question types that need it (route simple questions to single pass, module 4); cap steps and cost; log every search the agent makes, because you will need the trace to debug; and measure retrieval per hop (module 7), not just the final answer.
Practical advice
Prove the need first. Collect real multi-hop questions and check how many single pass fails.
Cap the loop: a step limit, a total-cost limit, and a "give up" path that returns a refusal (module 5).
Verify each hop before using it to write the next query.
Keep the trace (query, results, decision) as part of the answer's evidence.
For graphs, test extraction first: sample 50 passages, list the edges a person would expect, and measure what the extractor missed.
Plan updates. Decide how a changed passage updates the index and the graph (module 9).
Decide conflict rules (newest wins, authoritative source wins, or show both).
Interview angle
"A user asks 'Which office does the manager of the team that owns service X work in?' and your RAG fails. Why, and what do you do?" The question's words match only the first fact, so one search cannot retrieve the rest; later facts depend on earlier results. Either let an agent retrieve hop by hop, writing each query from the previous result, or pre-compute a knowledge graph and walk it. Then give the trade-offs: the loop is flexible and uses current text but costs latency and can loop or drift, so you cap steps and verify each hop; the graph is cheap per question and good for aggregates and themes but expensive to build, only as good as its extraction, and stale until rebuilt. Add that you would first measure how many real questions are actually multi-hop.
Check yourself
The graph answers 4-hop questions at 67 percent and the agentic loop at 100 percent. Does that mean agentic RAG is better? (Not by itself. The imitation planner knows only eleven question shapes, so the loop never plans badly here. The graph's misses come from phrasings its build-time schema did not read. A real planner makes mistakes too.)
For the curious Small guard added
The keyword retriever divided by zero on an empty collection; it now returns no results. The stale-graph row in the freshness table is the real lesson: a graph built before a fact changed keeps giving the old answer until it is rebuilt.
What you will use daily at work
Practice
What it looks like
A step limit on the retrieval loop
The agent may search at most a few times, then must answer or say it cannot.
Logging each search and its result
When a multi-hop answer is wrong you find the hop that failed.
Rebuild schedule for graphs and summaries
Whatever you precompute must be refreshed when documents change (module 9).
Draft: confirm which graph or agentic retrieval features your stack provides.