6.4.1 为什么大文档场景下，分层检索通常比直接 top-k chunk 更稳？

先给结论：因为大文档里的答案往往不是单个 chunk 就能完整表达的。直接做 top-k chunk 检索，常常会只抓到局部片段，却丢掉真正有用的文档上下文。分层检索更稳，是因为它更像“先找相关范围，再在范围内找细节”。

这也是长文档场景里很常见的一个误区：

• 以为只要 chunk 切得够细，再多拿几个 top-k 就能解决问题

现实里通常没有这么简单。

大文档场景里，top-k chunk 为什么容易出问题

最常见的问题是：

1. 相关信息被分散

一篇长文档里，真正回答用户问题的内容可能分散在：

• 标题层
• 小节层
• 具体段落层

如果系统只平面地拿 top-k chunk，经常会出现：

• 抓到一个局部句子
• 但缺了这个句子所在章节的整体语境

2. 局部相关和整体相关不总一致

某个 chunk 可能在字面上和问题很像，但它所在文档并不是用户真正想看的那一部分。

反过来，某篇文档整体非常相关，但因为具体 chunk 写法不够接近，系统又可能没有把它顶上来。

3. 长文档容易让 chunk 之间相互竞争

一篇长文档往往会被切成很多块。

如果系统只按 chunk 排名，就可能出现：

• 同一篇文档内部很多块互相抢位
• 其他真正相关文档的机会被压掉

这会让候选集既不完整，也不均衡。

为什么分层检索更稳

因为它通常不是一步到位地找最终 chunk，而是：

1. 先判断哪些文档、章节或上层节点更相关
2. 再在这些范围里找更细粒度的内容

也就是说，它在长文档里做的是：

• 先缩搜索空间
• 再做细粒度定位

这样通常会有几个好处：

• 先保住文档级上下文
• 减少无关 chunk 混进来
• 让细节检索发生在更靠谱的范围内

一个更直观的对比

你可以先这样理解：

• top-k chunk：先在所有碎片里抢前几名
• 分层检索：先找对容器，再在容器里找碎片

对于长文档来说，后者通常更符合人类真实查资料的过程。

一个最小示意

candidate_docs = doc_level_retrieve(user_query, top_k=5)
candidate_chunks = []

for doc in candidate_docs:
    candidate_chunks.extend(chunk_level_retrieve(user_query, doc_id=doc["doc_id"], top_k=5))

这段代码想说明的是：

• 大文档场景下，先找相关文档，再找文档内 chunk，往往比一次性全局抢 chunk 更稳

什么场景尤其不适合只做平面 top-k chunk

下面这些场景，尤其容易让简单平面检索出问题：

1. 一篇文档很长，章节结构明显
2. 一个答案依赖多个相邻段落
3. 问题需要先理解章节主题，再看细节
4. 文档内部很多 chunk 语义相似，容易彼此抢位

这些场景里，分层检索通常会比简单 top-k 更自然。

一个常见误区

很多人看到召回不够，就会先做这件事：

• 把 top_k 继续调大

这有时能补一点，但不总是根治。

因为问题可能不是：

• 相关 chunk 不够多

而是：

• 检索顺序本来就错了

也就是系统应该先找对文档或章节，再去找片段。

一句话总结

大文档场景下，分层检索通常比直接 top-k chunk 更稳，因为长文档的答案往往分布在多个层级。先找相关文档或章节，再找局部 chunk，通常比在全局碎片里直接抢前几名更不容易丢掉真正上下文。