advanced25 min studyLesson 672 in Engineering

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

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.

P(Q)={parent⁡(c):c∈R(Q)}P(Q)=\{\operatorname{parent}(c):c\in R(Q)\}
R(Q) is a set of authorized retrieved child records for query Q, and parent identity includes its immutable source version. This set removes duplicate parent identities; it does not itself authorize all parent content or define which parent wins a context budget.↔ Scroll wide equations horizontally.

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.

Cparents=∑p∈Pchosenτ(render⁡(p)),Cparents≤BevidenceC_{\rm parents}=\sum_{p\in P_{\rm chosen}}\tau(\operatorname{render}(p)),\qquad C_{\rm parents}\leq B_{\rm evidence}
τ counts tokens using the actual generation tokenizer on each declared rendered evidence block, including its header under an additive-block accounting convention. B_evidence is the available input budget after other reserves. Final concatenated rendering must also be tokenized because boundary effects can change counts.↔ Scroll wide equations horizontally.

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.

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.

  1. Deduplicating parent/version identities yields three candidates A,B,C rather than six separate parent fetches or copies.

  2. All three cost 620+520+420=1,560 tokens, exceeding the evidence budget by 360.

  3. 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 result

The six child matches become two packed parents under this policy. Retrieval success and final evidence coverage are therefore separate measurements.

Explore the model

Interactive lab

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.

Repeated hits and distinct identities have different costsA 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. Current readings: Hits / requests: 0 / 16; Hit rate: 0%; Address-stream period: 16 addresses. All parameters are adjustable with the labeled controls below.Fully associative LRU cache after 16 deterministic requests: 0 hits and 16 misses.Most recent 16 requestsaddress = i × 3 mod 160M3M6M9M12M15M2M5M8M11M14M1M4M7M10M13MCurrent cache order · oldest → newest471013Latest address 13 · miss: inserted as newestToy address stream · period 16 · starts empty
Cached addressMiss / evictionMost recent request
Hits / requests
0 / 16
Hit rate
0%
Address-stream period
16 addresses
t = 0 s

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.

Check your understanding

What additional check is required before expanding an authorized child hit into a larger parent?

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.

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.