Interview Bank

RAG in 14 Days: From Retrieval to Trustworthy Answers

D11 Advanced Indexing: Parent-Child Documents, Summary Indexes, Contextual Retrieval, and the Trade-Offs of Tree Aggregation vs. Graph Retrieval

• Parent-child indexing and contextual retrieval both patch the same problem — chunks losing their context. What actually distinguishes them?父子索引和上下文检索都在补『块被切碎』这个问题，它们的差别到底在哪？

  Common in ChinaCommon overseasIntermediate#indexing#contextual-retrieval#chunking

  How to reason about it · think before answering

  1. The hinge is which half of the pipeline each one fixes. Answering 'one is a chunking trick, the other adds a prompt' just describes implementations; the interviewer wants to know where each acts.
  2. Split the pipeline in two and ask separately: what does the retriever see, and what does the generator see. Parent-child changes the generation side — retrieval still runs on small chunks, but a hit is swapped for its parent. Contextual retrieval changes the retrieval side — the header exists so the chunk can be found at all, and the generator does not need it.
  3. Conclusion: parent-child fixes 'found it but can't read it'; contextual retrieval fixes 'readable but never found'. Neither changes what the other changes, so they compose.
  4. That difference also dictates which metric can see each one. Contextual retrieval moves rank, so recall and nDCG catch it. Parent-child moves 'is the evidence sufficient to answer', which a binary recall metric cannot see. Our 20-question set is already saturated at 100% on single-document questions, so parent-child comes out level with the baseline — that is the ruler failing, not the technique.
  5. That difference yields a free optimization: since the header only serves retrieval, keep it out of the context window. Leaving it in pays rent on every single query. Flipping that one switch in our lab freed 36 tokens inside a 600-token budget with every metric unchanged.
  6. The costs differ too. Parent-child costs index entries and a bigger context unit. Contextual retrieval costs one model call per chunk up front plus a permanently larger index. One is space; the other is time and space.
  7. Expect the follow-up 'why not both'. Look at the failure logs first: are you mostly seeing incomplete evidence, or nothing retrieved at all? Without the matching failure mode, neither is worth its price.

  分析过程 · 先想清楚再作答

  1. 这题的题眼是『补的是哪一半』。答成『一个是切块技巧、一个是加提示词』就是在描述实现，面试官想听的是它们各自作用在检索管道的哪一段。
  2. 拆的办法是把管道分成两段问：检索时看到什么、生成时看到什么。父子索引改的是**生成侧**——检索单位还是小块，只是命中之后把上下文单位换成大块；上下文检索改的是**检索侧**——块头拼进去是为了让这一块能被检索到，模型生成时并不需要它。
  3. 结论：父子索引解决『找到了但看不全』，上下文检索解决『看得全但找不到』。前者不改变谁被检索到，后者不改变模型看到多少。它们正交，可以叠加。
  4. 这个差别还决定了它们各自要用什么指标去量：上下文检索动的是名次，用召回率和 nDCG 量得到；父子索引动的是『材料够不够答』，召回率这种二值指标量不出来。我们那份 20 题评估集单文档档已经 100% 饱和，父子索引在表里跟基线持平——那不是它没用，是尺子量不了它。
  5. 顺着这条差异能推出一个立刻能用的优化：既然块头只服务检索，就不该进上下文。它进了上下文就是在每一次查询里白占预算，而且这笔钱是长期的。我们的实验里把这个开关一改，五列指标一个不变，600 token 的预算里多装进了 36 个 token。
  6. 代价也不同：父子索引的代价是索引条目变多、每次装进上下文的东西变大；上下文检索的代价是一次性要给每块调一次模型，加上索引 token 永久变大。前者是空间，后者是时间加空间。
  7. 可预期的追问是『那我全都上』。答案是先看失败案例：日志里是『材料不完整』多，还是『压根没检索到』多。没有对应的失败模式就不该上，这两个手法都不是免费的。

  Key points

  • Parent-child acts on the generation side: retrieve small, swap in the parent for context. It fixes 'found but unreadable'.
  • Contextual retrieval acts on the retrieval side: the header makes the chunk findable. It fixes 'readable but never found'.
  • They are orthogonal and compose; keep the header in the index only, never in the context window.
  • Parent-child costs more index entries and a larger context unit; contextual retrieval costs one call per chunk plus a permanently larger index.
  • Pick based on the observed failure: incomplete evidence points to the former, zero retrieval to the latter.

  答题要点

  • 父子索引作用在生成侧：检索单位是小块，上下文单位换成父块，解决『找到了但看不全』。
  • 上下文检索作用在检索侧：块头让块能被检索到，解决『看得全但找不到』。
  • 两者正交可叠加；块头只该进索引不该进上下文，否则每次查询都在为它付钱。
  • 父子索引的代价是索引条目与上下文单位变大；上下文检索的代价是一次性建索引调用加永久变大的索引。
  • 选哪个看失败案例：材料不完整选前者，压根没检索到选后者。