7.3.3 文档级合并、Chunk 级合并、相邻块扩展分别适合什么情况？

先给结论：这三种做法解决的不是同一个问题。文档级合并更适合恢复整体语境，chunk 级合并更适合控制精度和预算，相邻块扩展更适合补齐局部上下文。关键不是三选一，而是根据问题类型和文档结构决定哪一层该先发生。

很多系统在这一步容易走向两个极端：

• 要么什么都不合并，只把零散块直接丢给模型
• 要么一命中就整篇文档全带上，导致上下文被迅速撑爆

更稳的做法通常是：

• 先理解当前问题需要的是“局部证据”还是“连续语境”，再决定怎么组织候选

一、文档级合并适合什么情况

文档级合并，指的是：

• 当多个命中块来自同一文档时，不只保留零散片段，而是按文档或章节把它们重新组织起来

它更适合这些场景。

1. 文档内部结构很强

比如：

• 产品手册
• 流程说明
• 政策文件
• 章节清晰的规范文档

这类文档里，单个块有时并不足以表达完整意思，读者需要：

• 标题
• 小节关系
• 前置条件
• 后续限制

这时只看孤立块，模型很容易理解失真。文档级合并能帮助系统恢复“这段话在文档里原本属于什么位置”。

2. 问题本身需要跨段综合

例如：

• 某个流程有哪些前置条件、步骤和异常分支
• 某个规则的定义、例外和限制分别是什么

这类问题通常不是一个小块能回答完的，文档级组织会更稳。

它的风险

文档级合并的最大风险是：

• 一不小心把太多无关内容带进来

所以它不适合：

• 文档特别长
• 命中点很局部
• 问题只需要一个精确答案

二、Chunk 级合并适合什么情况

Chunk 级合并，指的是：

• 仍然以块为基本单位，但把属于同一小范围、同一小节、同一证据点的多个块组合处理

它更适合大多数常规 RAG 场景，因为它兼顾了：

• 足够细粒度的控制
• 较好的上下文恢复
• 不至于像整篇文档那样迅速膨胀

典型适用场景

• FAQ 知识库
• 帮助中心文章
• 技术说明文档
• 中等长度的操作指南

在这些场景里，你通常希望：

• 保留命中块的局部精度
• 但不要因为切块边界太硬，把一条完整信息拆得太碎

它的优势

• 控制成本更容易
• 去重和筛选更灵活
• 更适合和 Rerank 联动

很多系统最终的默认策略，其实就是：

• 先检索和重排 chunk
• 再在最终阶段按块级规则做有限合并

三、相邻块扩展适合什么情况

相邻块扩展，指的是：

• 某个块命中之后，再把它前后的一个或几个相邻块一起补进来

它最适合解决的问题是：

• 命中的块是对的，但单独看上下文不完整

典型适用场景

• 一个定义的解释在下一段
• 一个步骤的注意事项在前一段
• 表格说明和表格正文被拆开了
• 代码解释和示例分布在前后块

这类问题里，命中的核心块往往是对的，但如果只给这一块，模型会缺半句背景。

它的优势

• 成本比整篇回填低很多
• 比粗暴扩大 Top K 更聚焦
• 适合处理切块带来的局部割裂

它的风险

• 如果扩展窗口过大，容易把噪声一起带进来
• 如果文档结构本来就松散，相邻不一定代表相关

所以相邻块扩展不是默认越多越好，而是要结合文档结构和块边界设计。

怎么选：一个更实用的判断顺序

如果你在三者之间做选择，可以先按这个顺序判断。

1. 问题需要的是局部证据，还是连续语境

如果更像局部精确问答，优先考虑：

• chunk 级组织
• 必要时少量相邻扩展

如果更像跨段综合问题，优先考虑：

• 文档级或章节级组织

2. 文档本身是不是结构强、连续性强

如果文档层次清晰、章节意义强，文档级或章节级合并更有价值。

如果内容本来就是碎片知识点，文档级合并就容易过重。

3. 当前主要问题是“太碎”还是“太散”

• 太碎：优先相邻块扩展或小范围合并
• 太散：优先精选和压缩，不要贸然整篇带回

一个最小示意

candidates = rerank(query, retrieve(query, top_k=20))

if question_needs_cross_section_context(query):
    final_context = merge_by_document_section(candidates)
elif chunk_is_right_but_context_is_incomplete(candidates):
    final_context = expand_neighbor_chunks(candidates, window=1)
else:
    final_context = merge_small_chunk_groups(candidates)

这段代码想表达的是：

• 最终组织方式应该由问题和文档结构共同决定
• 不同策略不是替代关系，而是适用条件不同

一个常见误区

很多人会把“相邻块扩展”理解成“简化版文档级合并”，或者把“文档级合并”理解成“多带一点上下文”。

这两种理解都不够准确。

更稳的区分是：

• 文档级合并是在恢复整体结构
• chunk 级合并是在保持精度前提下恢复局部完整性
• 相邻块扩展是在补切块边界造成的上下文缺口

一句话总结

文档级合并适合需要整体语境和跨段综合的问题，chunk 级合并适合大多数常规问答场景，相邻块扩展适合补齐命中块周围缺失的局部上下文。真正该选哪种，不取决于你更喜欢哪种实现，而取决于问题类型、文档结构和当前系统暴露出的失败模式。