← Retrieval From First Principles

Decomposition and Multi-Hop Retrieval

Retrieve a supported chain across documents while preserving bridge identity, source evidence and stopping conditions.

“Which contact serves project PR-84?” A search can find a passage naming the project without finding the contact it asks for. The project record identifies the organisation that operates PR-84; a separate registry record identifies that organisation’s contact. To satisfy the request, retrieval must connect those two statements through the same identified organisation, not merely return documents about the right topic.

The name Rowan makes the danger concrete. Two organisations in the fictional registry share that display name. A project passage and a contact passage can both mention Rowan yet refer to different entities. Matching the words would produce a convincing-looking but unsupported chain; matching the exact organisation identity is the necessary join.

Query Rewriting and Expansion changed the expression used to search while retaining the original information need. Multi-hop retrieval keeps the need intact but makes a later search depend on evidence from an earlier one. Each transition must have a stated reason: what was learned, which source supports it and why that information permits the next search.

Decompose the obligation, not the answer

The contact request supplies a small relation pattern:

project --operated_by--> organisation --contact--> contact entity

The pattern is an interpretation of this particular request, stored alongside the original words rather than substituted for them. No model has generated a decomposition or proposed an answer. Another relationship question would require another supported pattern; two arrows in this example do not amount to a general-purpose multi-hop planner.

The implementation begins by searching for the interpreted project’s exact canonical identifier. It may follow an operated_by bridge only when a current, source-backed relation is supported by a unit actually returned in that first search. It then searches the exact canonical identifier of that organisation and requires a supported contact relation in the second result set. A plausible name or relation elsewhere in the catalogue is not sufficient to advance this particular search.

The diagram shows why the two searches cannot simply run in parallel: the second identifier is produced by the first hop, and each transition needs its own supported clause.

    %%{init: {"flowchart": {"wrappingWidth": 380}}}%%
flowchart TD
    Q["Request preserved: which contact serves project PR-84?"] --> H1["Hop 1 · search the project's canonical identifier; require a supported operated_by clause, whose object becomes the bridge identifier"]
    H1 -->|"clause absent"| X["No complete path: partial evidence only"]
    H1 -->|"clause present"| H2["Hop 2 · search that bridge identifier; require a supported contact clause in the returned rows"]
    H2 -->|"clause absent"| X
    H2 -->|"clause present"| P["Packet: two supporting clauses, 106 characters"]
    P --> V["Projection rechecks each reference and relation"]

The join key is the bridge identifier, not a display name and not a similarity score. Both refusal paths lead to the same outcome: partial evidence is not a supported chain, and the packet is not exposed as one.

The two refusal paths are the tested ones: seven constructed challenges with no accepted complete path, in which the implementation returned none.

The trace records each derived subquery alongside the original request, returned references and ranks, source anchor supporting the transition, exact bridge identifier and budget remaining. These fields explain not only which evidence was selected but why the second query was issued. It is derived from a checked fixture relation, never treated as an instruction supplied by retrieved prose.

The HotpotQA paper illustrates why multi-document retrieval requires more than several relevant-looking documents: it supplies annotations for the facts that support multi-hop questions. We do not run HotpotQA or inherit its performance claims. Our small authored relation cases instead test a specific property that SciFact’s document-level judgements cannot establish: whether the retrieved sources support the required connection.

Require evidence for the join

Other multi-hop systems obtain the next query in different ways. Multi-hop Dense Retrieval encodes the question with previously retrieved passages to produce a new dense query. IRCoT uses generated intermediate reasoning to guide subsequent retrieval. One changes a learned representation; the other introduces a generated search cue. Neither approach, by itself, guarantees that an intermediate entity or relation is supported. Our system takes a narrower route: it checks literal relations in a supplied catalogue, with no learned reformulator or reasoning model executing.

For the main example, the fictional records contain literal clauses:

REL project:final:main | operated_by | org:final:north
REL org:final:north | contact | contact:final:desk

Each clause is backed by a source, document, version, representation, content digest, exact span and quoted text. The declared relation must reproduce the supported clause: changing its subject or object, or losing its support digest, invalidates the bridge. The join key is org:final:north, not the shared display name Rowan and not a similarity score. Source identity and relation identity are both needed to make the chain inspectable.

Each fictional world contains nine author-declared relation records, including invalid controls. The source clauses already contain canonical entity identifiers; the retriever is not extracting those identifiers from unfamiliar prose. Chapter 20’s graph and this two-hop implementation use the same catalogue. Their agreement can check implementation consistency, but cannot count as independent discovery or independent experimental confirmation.

Four operations are easy to conflate: following a declared relation, retrieving the unit that supports it, checking that support against the current view, and discovering a previously unknown relation in unstructured text. This experiment implements and tests the first three, not the fourth. Relationship extraction and independent graph construction are not measured. A source-backed clause also remains a fictional assertion; its provenance does not certify real-world organisational authority or truth.

Make the second search earn its cost

The budget is explicit. Each hop may request at most three lexical rows, for no more than two logical searches and six returned rows across the request. Final selection remains limited to four units and 900 characters. Rows retrieved during the first hop count against search work even if they are irrelevant or never enter the final packet; a second hop is not free merely because its evidence is eventually selected.

In the successful main case, the two searches return six rows and the final packet contains two supporting clauses: 106 characters including the separator. The revised case selects 107 characters. These are measurements of retained source text under this fixture’s packet rule, not a generated answer, a model-token count or a claim about end-to-end latency.

If both canonical entity identifiers were already known, the corresponding searches could be independent. Here the second identifier must be obtained from a validated first-hop relation. Running both searches in parallel would assume the bridge in advance or guess it. The implementation therefore follows the dependency sequentially; it provides neither unbounded exploration nor an adaptive agent that backtracks through alternative paths.

Distinguish finding a hop from completing a chain

The final challenge declares three positive relation requests: two for the main assignment and one for its revised version. The two-hop method returns an accepted complete path for all three. Under the same final selection cap, each of the three fixed text routes misses those complete target bundles. This shows the value of the added relation-checking capability in the constructed cases; it does not show that arbitrary multi-hop questions have been solved.

Seven further cases have no accepted complete path: missing first hop, missing second hop, wrong bridge, shared name, restricted hop, contradictory assignment and misleading mention. The implementation returns no complete path in all seven. These deliberately designed cases test whether it refuses unsupported joins; their same-author labels and narrow construction do not yield an independently sampled false-path rate.

The retained intermediate results are more informative than the total:

Constructed case Required first anchor observed Required second anchor observed Complete path returned
Main chain Yes Yes Yes
Second hop removed Yes No No
First hop removed No Yes No
Second hop restricted Yes No No
Assignment contradicted Yes No No

In this table, “observed” means that the required anchor appears in an offline returned-search trace, not necessarily that it reaches the final public packet. When the first hop is removed, the first search happens to encounter the second relation’s source. That incidental discovery cannot serve as a project-to-organisation bridge. Finding both relation types somewhere in retrieved material is weaker than proving their required order and shared identity.

The contradictory-assignment case stops after one search because a current opposing assignment prevents the first bridge from being treated as settled. This check may inspect eligible catalogue relations whose supporting units were not among the returned search rows. It is deliberately stronger than evidence found by those searches alone and must be counted as a catalogue-level assumption. Skipping the second call is justified under that declared rule, not proof of general natural-language contradiction detection.

Version and permission are part of the bridge

The revised view assigns the project to the southern organisation. The original northern assignment remains addressable in historical records but is not an eligible current bridge. A valid contemporary chain must use the revised project relation and the southern organisation’s contact. Similar wording in an older version cannot substitute for a current, version-qualified edge.

If the contact source is restricted or removed, the second hop cannot establish a complete public chain. Before exposure, the public projection rechecks the current eligibility of every selected source reference and supporting relation. It excludes protected intermediates and returns no accepted path. An authorised offline audit may identify the failed hop, but the public response does not inherit a right to disclose that explanation.

This is a trusted-metadata teaching boundary, not an access-control service. The implementation does not authenticate a requester, discover live production permissions or test prompt-injection resistance. Retrieved relation clauses are treated as data: they cannot alter the source allowance, authorise a bridge on their own or increase the search budget.

Keep structural coverage separate from an answer

Evidence coverage and a supported join are different outcomes. A packet might contain both requested positive statements while another eligible source contradicts the assignment connecting them. One correctly retrieved relation may also be useful partial evidence without completing the path. The trace therefore distinguishes anchor coverage, complete-bundle coverage and accepted paths rather than treating any retrieved pair as a valid answer.

Across all sixteen target needs, the specialised contact pattern covers only 3/16 complete bundles: it is not designed for reset, evacuation or checksum questions. Chapter 16’s router exists precisely because this capability should not be applied everywhere. Within its intended positive relation cases, recovery is 3/3; among the seven no-path challenges, unsupported complete paths are 0/7. Chapter 20 reports matching counts using the same nine authored relation records and evidence, not an independent confirmation. None of these denominators measures the correctness of a generated answer.

No answer-generating consumer runs in this experiment, so evidence assembly, use and helpfulness remain not measured. The retriever also greedily follows its first eligible supported edge and does not backtrack if that branch reaches a dead end. A collection with several genuine candidate bridges could therefore expose another failure even when some complete path exists.

The need for a second piece of evidence does not always imply a second document or an asserted relation. A short procedure may simply need the heading that limits its scope, or the parent section that supplies its conditions. Hierarchical and Parent-Child Retrieval addresses those containment relationships next, keeping them distinct from the explicit entity joins tested here.

References and further reading

Background and extensions for this chapter: