A Three-Hop Question, Worked Example

Every argument about multi-hop retrieval eventually needs a worked example. So here is one: a single question over a plausible corporate wiki, traced twice, once through top-k retrieval and once as a walk through a knowledge forest (a linked graph of documents an agent moves through). If you want the theory first, start with why multi-hop breaks RAG; this post is the companion trace.

The corpus and the question

Picture the internal wiki of a mid-size company, call it Northwind Robotics: a few hundred documents covering service pages, runbooks, architecture decision records and postmortems. A new engineer asks:

Which team gets paged when the export behind the quarterly revenue dashboard fails?

The answer exists, but it is spread across three documents:

1. The dashboard page says its data comes from the finance-mart export.
2. The finance-mart page says the export runs as a nightly job on atlas-pipelines.
3. The atlas-pipelines runbook says job failures page the Data Platform on-call.

No single document contains both "quarterly revenue dashboard" and "Data Platform". The answer only appears when you chain all three, which makes this a strictly three-hop question.

What top-k retrieval returns

Embed the question, fetch the five most similar chunks. What comes back is exactly what similarity promises: chunks about the dashboard (its widgets, its refresh schedule), the sentence naming finance-mart, and maybe a postmortem that happens to contain "dashboard" and "failed" in the same paragraph.

The one document that names the answer, the atlas-pipelines runbook, scores near the bottom of the entire corpus for this query. It never mentions dashboards or revenue. It shares no vocabulary with the question and very little semantics. It was never going to be retrieved, no matter how good the embedding model is, because relevance to the question is not the same as relevance to the answer.

The reader model now holds half-evidence, and it does what language models do with half-evidence: it guesses a plausible team, or it refuses. Retrieval fired once. The question needed three firings, each conditioned on what the previous one found. Top-k is a single hop by construction.

The same question, walked

Now give the same corpus to MonkeyLLM. Each document becomes a node with a passport (a small curated card: title, summary, tags), and nodes link where the documents reference each other. Navigate, don't retrieve.

1. Enter. Search "quarterly revenue dashboard". The agent lands on the dashboard node.
2. Hop 1. The passport summary mentions a data source. The agent opens the node, finds the link to finance-mart, follows it.
3. Hop 2. The finance-mart passport already says "nightly export on atlas-pipelines". Follow the link, no need to open the full body.
4. Hop 3. Open only the paging section of the runbook: Data Platform on-call.

The answer arrives with the three node ids it stands on, and every hop was token-budgeted: reading a passport is cheap, and opening a full document happens only when the label says it is worth it.

There is one more move worth mentioning. The successful hunt deposits pheromone (a usage trace on the path it took), and a shortcut link can be minted from the dashboard node toward the runbook. The next similar question is one hop.

This is not just a story

The trace above is invented; the measurement is not. On 11 strictly multi-hop questions, each needing at least 3 chained hops, the same 12B local model scored 0/11 as a classic top-k RAG reader and 11/11 as a forest navigator.

Eleven questions is a small set, and we say so. The corpus, the question sets and the harness are committed, and every table regenerates with one command.

Trace one of your own

Take a question your team actually asks and count the hops. If the count is above one, top-k was never going to answer it. Star the repo, deploy a forest in four commands with the quickstart, and run the trace yourself at monkeyllm.com.