布吉岛 Agent

Appearance

10.3.1 Chunk 策略不合理会带来哪些典型问题？ ​

先给结论：Chunk 策略不合理，最直接的后果不是“看起来不优雅”，而是整条 RAG 链路都会受影响。它既会影响关键证据能不能被召回，也会影响召回后的证据是否足够完整、是否容易被模型正确使用。

很多人第一次接触 RAG 时，会把切块理解成一个很技术性的预处理步骤，好像只是：

  • 把文档切小一点

但真实系统里，Chunk 实际上决定了：

  • 什么信息能作为独立检索单元出现
  • 哪些上下文关系会被保留下来
  • 哪些证据会在召回时被切散、切断或混杂

所以切块一旦不合理，后面很多问题都会跟着发生。

第一类典型问题：证据被切碎，单块表达不完整 ​

这是最常见的一类问题。

常见表现：

  • 召回结果看起来相关，但总是只有半句话
  • 规则、例外条件和适用范围被切开
  • 表格说明、标题和正文分离后失去意义

这类问题的本质是：

  • 一个完整语义单元被拆散了

结果就是，模型虽然拿到了一部分材料，但缺少关键上下文。

第二类典型问题：块太大，局部相关性被稀释 ​

另一种常见错误正好相反：

  • 切得太大

常见表现：

  • 大块里既有相关内容，也有很多无关内容
  • 检索命中后，噪声一起进入上下文
  • 长文档中的关键局部很难稳定排到前面

这类问题说明：

  • 检索单元过粗，导致相关性判断不够精细

第三类典型问题：结构信息丢失，文档语义被改坏 ​

有些文档不是普通段落文本，比如：

  • 标题分级明确的长文档
  • FAQ
  • 表格
  • 列表规则
  • 代码文档

如果一律按固定长度切块，常见后果是：

  • 标题和内容脱钩
  • 表头和单元格分开
  • 问题和答案分离
  • 函数说明和参数定义被切散

这时问题不只是“块大小不合适”，而是：

  • 文档结构语义没有被保留

第四类典型问题：相邻块信息重复过多 ​

很多人为了避免切断语义，会增加 overlap。这个方向本身没问题，但如果重叠过大，也会出现新的问题：

  • 候选结果高度重复
  • 上下文里塞进很多相似内容
  • 真正有价值的新信息反而进不来

这类问题说明：

  • 切块的连续性补救过头了

第五类典型问题：检索和生成都被迫使用同一套块 ​

这是更隐蔽、但很常见的问题。

很多系统一开始会默认：

  • 检索怎么切
  • 生成就怎么喂

但现实中，小块通常更适合召回，较完整的块更适合生成。如果你把两者完全绑定，就容易出现：

  • 检索阶段看起来还行
  • 生成阶段却总是证据不完整

或者反过来：

  • 生成块足够大
  • 但检索召回变钝

什么时候应该优先怀疑切块策略 ​

当你发现下面这些现象时，很值得优先回头看 Chunk：

  • 正确文档能召回，但回答总是缺限制条件
  • 长文档问题表现明显差于短文档
  • FAQ、规则类文档、表格类文档效果特别不稳
  • 相同知识点换一种问法，召回结果就变得非常碎
  • 候选集中重复内容过多

这些信号都很像：

  • 切块没有和文档类型、任务目标对齐

一个很实用的判断框架 ​

你可以先用下面这个角度粗看：

  • 如果问题是“证据总是不完整”，优先怀疑块太碎
  • 如果问题是“召回很粗，噪声很多”，优先怀疑块太大
  • 如果问题集中出现在表格、FAQ、规则条款，优先怀疑结构切块不足
  • 如果问题是“上下文重复太多”，优先怀疑 overlap 和去重设计

一个最小失败信号示意 ​

python
chunk_symptoms = {
    "fragmented_evidence": "chunk_too_small_or_bad_structure_split",
    "noisy_context": "chunk_too_large",
    "duplicated_results": "overlap_too_large",
    "faq_mismatch": "document_structure_not_preserved"
}

重点不是这个映射写死，而是让你建立：

  • 失败现象和切块问题之间的对应感

一句话总结 ​

Chunk 策略不合理最典型的后果，是让证据要么被切碎、要么被稀释、要么失去结构关系。切块不是简单预处理，而是会直接决定整条 RAG 链路质量的基础设计。