Hierarchical and Parent-Child Retrieval

The request asks what to press under ZX-68 maintenance mode. Flat retrieval finds the mode heading and nearby device material, but the selected blocks leave out the required action. The same document also describes production mode, where a similar-looking instruction would apply under different conditions. A plausible fragment is not enough: the evidence packet must preserve both what to do and when that instruction applies.

Decomposition and Multi-Hop Retrieval established a chain between documents using exact entity identities. Here the missing link is structural rather than relational: a short action and the heading that governs it belong to the same document. Can we search within that structure, or expand a retrieved child to its parent, without exceeding the same evidence allowance?

Build parents from the retained representation

The teaching parser already identifies exact raw blocks and heading sections. We extend that representation with whole-document units and explicit containment links: each block points to its smallest containing section and to its document. A link is valid only when child and parent share source, document, version, representation and content digest, and the child’s complete raw span falls inside the parent’s span. The hierarchy is therefore reconstructed from retained source boundaries, not guessed from similar wording.

Containment is a checkable relationship between source spans. A heading from a different document cannot be substituted as the parent merely because the text looks right; a section from a later revision cannot inherit an earlier child’s reference. Each parent has its own retrieval-unit identity and exact source span. Expanding a child means selecting another identified source unit, not silently pasting untracked context onto a hit.

When a child triggers expansion, we retain both references: the parent selected for the evidence packet and the child whose retrieval caused that choice. This distinction matters when explaining the result. The lexical score belongs to the matched child; the parent did not independently earn that score. Its additional context may complete an evidence bundle, but that is evaluated from source spans rather than inferred from the child’s rank.

Our hierarchy links existing, exact source spans; it does not generate new text. The inspected RAPTOR manuscript instead builds a tree by embedding, clustering and summarising text recursively. Such generated parents require separate checks for what their summaries preserve and how they map to originals. We execute neither RAPTOR nor a summary model, and the results of our containment experiment do not measure the performance of that approach.

Compare where the search begins

To isolate where a search begins and how much context selection can restore, we execute six deterministic alternatives over the new constructed information needs:

Method	Candidate procedure
Flat blocks	One lexical search over parsed blocks
Flat windows	One lexical search over twelve-word windows with stride eight
Flat sections	One lexical search over heading sections
Document first	Retrieve two documents, then up to four blocks inside them
Section first	Retrieve two sections, then up to four blocks inside them
Parent expansion	Retrieve blocks, then replace each with its containing section, preserving first encounter order

In the two-stage methods, the first search chooses a restricted parent set; the second search ranks children only inside that eligible subset, with lexical statistics recomputed for it. We never compare a raw parent BM25 score directly with a child score drawn from another index. Finding a high-ranking parent only determines where the next search may look. It cannot guarantee that the child containing the required action will rank high enough to be selected.

Every method may select at most four units and 900 characters of evidence text, including separators. Document-first and section-first retrieval use two logical calls: up to two parent rows, followed by up to four child rows. Flat search and parent expansion use one ranked search of up to six rows; expansion then performs a local structural lookup rather than another search. These limits make the output allowance explicit, but they do not equalise index construction, scoring work or current-view checks, which are outside the logical call count.

Finding the right parent can still fail

Dense Hierarchical Retrieval uses learned encoders to retrieve documents and then score passages with evidence from both levels, including title-tree context. It illustrates a general failure boundary: if the document stage excludes the correct parent, no subsequent passage scorer restricted to that parent set can recover its children. Our lexical document-first and section-first examples expose that gating risk; they do not reproduce the paper’s learned representations or score combination.

A hierarchy does not require every search to start at the root. RAPTOR, for example, distinguishes tree traversal through selected parents from collapsed-tree retrieval across nodes at several levels. Its nodes include generated summaries, which cannot be cited as literal source spans without separate resolution. Our alternatives are different again: parent-first restriction narrows the child universe, while child-first expansion retrieves a small unit and then restores its containing section. These candidate procedures should not be treated as equivalent simply because each uses a tree.

For the ZX-68 maintenance request, document-first retrieval includes the correct mode document, and section-first retrieval includes the relevant mode sections. Yet both fail the complete heading-and-action bundle. Their child-stage rankings keep matching headings and other mode material while omitting the maintenance action. The required source is inside the searched hierarchy; it does not survive the second selection stage.

The query repeats words from the heading, not from the action: “Press the silver pad once, then inspect the readiness lamp.” A lexical child search can therefore reward the heading while overlooking the instruction that answers the request. Locating the correct container reduces the search space; it does not make every essential child equally discoverable. Parent relevance and child sufficiency are separate judgements.

Parent expansion starts with that heading hit but selects its complete maintenance section, with the child-to-parent link retained. The section contains both required anchors and fits within the declared allowance. For this request, the expanded evidence packet contains 320 characters, compared with 145 for flat blocks, and covers the bundle that flat selection misses. The observed improvement is therefore accompanied by a measurable cost in returned text; it is not a free ranking gain.

Preserve a long-parent counterexample

Expansion has an opposite failure mode when the parent is too large. In the deliberately long archive document, the selector end-marker follows extensive unrelated text. Both the containing section and its long paragraph exceed the 900-character cap. The selector skips those whole units rather than clipping them and presenting a partial prefix as if it were equivalent evidence.

For the selector request, flat windows recover the complete required anchor. Flat blocks, flat sections, parent expansion and both parent-first procedures fail to cover it within the same protocol. Here a small window isolates the useful tail while its parent is infeasible. The maintenance example favoured restored context; this one favours a narrower unit. Together they rule out the simple conclusion that larger retrieval units are always better.

The actual dense encoder in this batch receives only the block representations; two long block inputs exceed its wordpiece limit. The hierarchy comparisons reported here, however, use lexical scoring and a selected-text character cap. Their oversized-parent failures are not measured dense-encoder truncation failures. Nor have we tested whether a longer encoder window would change these structural outcomes.

Read the controlled-cap comparison

The final constructed collection has twenty requests and sixteen targets with non-empty source-evidence bundles. Three of those targets lack required current evidence; a separate conflict case contains positive statements but no accepted relation path. We retain those distinctions when reading the table. Its outcome is complete structural bundle coverage under the declared selection policy, not proof of answerability, relationship validity or generated-answer correctness.

Method	Complete bundles	Mean characters	Mean logical calls
Flat blocks	4/16	141.85	1
Flat windows	7/16	244.15	1
Flat sections	11/16	365.55	1
Document first	4/16	135.40	2
Section first	4/16	129.10	2
Parent expansion	11/16	358.05	1

Mean characters and logical calls are calculated across all twenty final requests, including requests without accepted evidence. The development bundle counts, in the table’s method order, are 4/11, 7/11, 9/11, 4/11, 4/11 and 9/11. As Understanding Queries and Routing explains, development and final worlds are mirrored constructions prepared by the same author. Similar patterns between them are useful mechanism checks, not independent replication or estimates for an unseen task population.

The shared 900-character ceiling prevents one method from returning an unlimited parent while another is constrained. It does not make the methods equal in the amount of evidence they actually select. Flat sections and parent expansion return more characters on average than flat blocks or the parent-first methods, and their unit boundaries and lexical statistics also differ. Their 11/16 coverage result is therefore an outcome of the complete procedure under this cap, not an isolated estimate of the benefit of hierarchy traversal alone.

This is a new, constructed comparison with a common character cap. It does not rerun Part II’s original block/window/section experiment under equal characters or equal model-token budgets; that historical comparison remains not measured. A codepoint allowance is also not a substitute for the actual token budget of a downstream language model.

Containment carries permission and version constraints

Containment does not bypass eligibility. If a document is excluded by the trusted current view, none of its descendants enters parsing or retrieval for that view. Even when a child is eligible to return, selecting it is not independent authorisation to expose a larger parent. Parent expansion must satisfy the same source/version gate and final current-view projection as any other evidence packet.

The revised-project control changes the current relationship and the relevant child references together. Earlier children remain identifiable as historical source units, but they cannot be resolved as current evidence by attaching them to the revised parent. Tests require exact span containment within the same source version and representation; textual resemblance across revisions is not treated as a valid continuity link.

A bundle can be covered by several short units even when no single unit contains every required anchor. A larger parent may also include both an accepted assertion and a contradiction. Neither proximity nor completeness of the raw spans decides which statement governs. This creates an intentional distinction for the next chapter: the conflicted request can pass a structural-coverage check here while failing the stronger requirement for a verified, consistent relation chain.

We can now navigate evidence in two distinct ways: through containment within a document and through source-backed relationships connecting entities across documents. Both need exact identity and current eligibility, but only the latter claims that one entity stands in a declared relation to another. Graph and Structured Retrieval represents those claims as typed edges and asks what evidence a traversable path must carry before it can be trusted.

References and further reading

Background and extensions for this chapter:

• Liu et al. (2021). Dense Hierarchical Retrieval for Open-domain Question Answering. Findings of EMNLP. Provides a document-first, passage-second retrieval hierarchy.
• Sarthi et al. (2024). RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval. arXiv preprint, v1. Offers a contrasting hierarchy of generated summaries rather than exact containment spans.
• Luan et al. (2021). Sparse, Dense, and Attentional Representations for Text Retrieval. TACL. Explains why preserving more document text need not preserve a precise searchable representation.

Related chapters

• Representation Is Part of Context. Examines which obligations survive a change in evidence representation.