Hierarchical retrieval: expand a precise hit without losing its lineage
Separate child retrieval, parent expansion, recursive summaries, authorization boundaries, and context budgets.
On this page
The question for today
What you’ll understand
- Deduplicate child hits by the intended parent/version identity.
- Budget expanded parent evidence rather than only indexed child size.
- Distinguish source expansion from generated hierarchical summaries.
A small passage can match a question precisely while omitting the section needed to interpret it. Parent-child retrieval addresses this by retrieving a focused unit and expanding to a related larger unit. Hierarchical summaries address a different problem by representing broader content at several abstraction levels. Both approaches need explicit lineage, permission checks, and budgets; a successful small hit does not make every related paragraph safe or useful to include.
A retrieved child and a served parent are different units
Index a child passage with a stable pointer to its parent document region and immutable source version. Retrieval ranks children, but the expansion policy decides whether to include a paragraph, section, neighboring window, or another bounded unit. Several child hits can point to the same parent. Deduplicate using the actual parent/version identity before fetching or packing it repeatedly. Retain the child match and score as selection evidence rather than pretending the parent received the same similarity score through an independent retrieval.
Expansion can reveal text beyond the matched child, so authorization must cover every served parent span under the current policy. A child-level permission is not a blanket grant for the whole document. If a parent crosses permission boundaries, fetch a permitted bounded region or reject that expansion. Parent identifiers must not be silently reassigned after an edit. Resolve them against the same corpus snapshot as the child index or explicitly detect a version mismatch and refresh rather than combining old matches with unrelated new text.
Recursive summaries are derived evidence, not original quotations
RAPTOR recursively clusters and summarizes text to build retrieval representations at multiple abstraction levels. That is different from simply returning the original parent section for a child match. A generated summary may combine distant passages or omit qualifications, so preserve its contributing source identities and generation configuration. If it is used to select evidence, follow its lineage back to original source spans for claim validation. A fluent hierarchy node is not automatically a faithful quotation or an authoritative replacement for its inputs.
A hierarchy can be a tree or a more general dependency structure depending on grouping and reuse. Updates to a leaf can invalidate summaries above it, embeddings of those summaries, and cached retrieval results. Mixed-access inputs need a derived-content permission policy that prevents a summary from leaking a restricted contributor. The simplest conservative design restricts use to principals authorized for all contributing material, though a carefully reviewed redacted derivation can define another policy. Treat that policy as an implemented data rule rather than a prompt instruction.
Evaluate expansion separately from retrieval and generation
Compare child-only, bounded-parent, and hierarchical-summary variants on the same authorized corpus snapshot. Measure whether the required source facts are present after expansion and after budget trimming. Broad parents may improve interpretation while crowding out a second necessary source. Fusion-in-Decoder encodes retrieved passages separately before decoder fusion; its architecture is not the same as placing all parent text in one decoder-only prompt. Apply the appropriate architecture's input and compute budgets instead of assuming every retrieval-enhanced generator shares one packing rule.
The cache lab isolates repeated identity reuse. Reset, set C=3 and s=4, predict zero hits among the first sixteen requests, then Play or Step. Separately Reset, set C=4 and s=4, predict twelve initial hits, then Play or Step. This modulo-sixteen stream cycles through four addresses; three slots cannot retain the whole cycle. It contains no parent-child map, hierarchy, or document permissions. Use it to motivate measuring the number of distinct fetched identities, then validate the real expansion and source lineage independently.
Work it through
Deduplicate children before expanding parents
Six child hits map to parents [A,A,B,A,C,B]. Rendered authorized parents cost 620,520,420 generation tokens respectively, including headers. The evidence budget is 1,200 and the stated priority order is A, then B, then C.
Deduplicating parent/version identities yields three candidates A,B,C rather than six separate parent fetches or copies.
All three cost 620+520+420=1,560 tokens, exceeding the evidence budget by 360.
Under the stated priority policy, A and B cost 1,140 and leave sixty tokens. C does not fit. The pipeline must preserve the missing-evidence signal instead of silently claiming all three parents were supplied.
The six child matches become two packed parents under this policy. Retrieval success and final evidence coverage are therefore separate measurements.
The living notebook
Explore the model
Interactive lab · cache
Repeated hits and distinct identities have different costs
Reset, set C=3 and s=4, predict zero initial hits in 16 requests, then Play or Step. Separately Reset, set C=4 and s=4, predict 12 initial hits, then Play or Step. The four-address LRU cycle has no hierarchy, source text, permissions, or generation budget.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forCount distinct expanded identities instead of treating every small hit as an independent large fetch.
Pause & reason
Check your understanding
Your turn
Try it yourself
Four child hits map to parents [D,D,E,F]. Their authorized rendered costs are 300,250,200 tokens. With budget 600 and priority D,E,F, which parents fit? Does this prove every required claim is supported?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Deduplicate first, then apply the stated priority and token budget.
Compare with the solution
Distinct candidates are D,E,F. D and E total 550 tokens and leave fifty; F does not fit. This is only the result of the declared packing rule. Whether the needed facts are present, mutually consistent, and faithfully used still requires evidence and answer evaluation.
Keep the idea
Take it with you
- Child ranking and parent expansion are separate decisions.
- Generated hierarchy nodes need original-source lineage and derived-content access policy.
- Measure evidence coverage after expansion and final budget trimming.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.