03-Chunking复盘：切分策略、语义完整性和 overlap 取舍

上一篇讲的是文档进入知识库之前的处理。解析、清洗、结构化和 metadata 解决的是资料以什么质量进入系统。

到了这一步，文档已经被清洗过，也尽量保留了标题、段落、表格、代码块和来源信息。接下来还有一个关键问题：这些内容进入索引时，要以什么粒度存在。

这就是 chunking。

chunking 看起来只是把文档切成小块，实际会影响 RAG 的很多核心环节。它影响 embedding 表达，影响召回粒度，影响 Rerank 判断，影响上下文噪声，也影响模型最终能不能基于证据生成完整答案。

这篇的核心判断可以先放在前面：

chunking 的本质，是在检索粒度和语义完整性之间做工程取舍。

切得太粗，检索回来的内容主题混杂，噪声变多；切得太细，模型拿到的证据缺少上下文，语义容易断裂。一个好的 chunk 策略，需要让系统能精准找到证据，同时让模型拿到的证据仍然足够完整。

chunk 在 RAG 链路里的位置

chunk 是 RAG 索引和检索里的基本知识单元。

一条简化后的离线链路大概是这样：

清洗后的文档
  -> 按结构和语义切分 chunk
  -> 为 chunk 补 metadata
  -> 生成 embedding
  -> 写入向量索引
  -> 在线检索召回 chunk

后面的 embedding、向量索引、相似度搜索、Rerank 和上下文拼接，大多围绕 chunk 展开。系统通常检索到的是一批 chunk，而非整篇文档。

这意味着 chunk 的质量会直接进入后续链路。

一个 chunk 如果包含多个主题，embedding 会把这些主题混在一起表达。用户只问其中一个主题时，向量相似度可能会被其他内容稀释。一个 chunk 如果太短，embedding 虽然更聚焦，但模型看到它时可能缺少定义、条件、例外和上下文。召回正确片段和生成完整答案之间，存在一段需要平衡的空间。

所以，chunking 不是单纯的数据预处理。它是 RAG 检索层的粒度设计。

整篇文档直接入库的局限

整篇文档直接入库，通常会遇到两个问题。

第一个是长度问题。很多文档会超过 embedding 模型的输入限制，也会超过后续上下文窗口的合理承载范围。即使模型可以处理很长文本，把整篇文档压成一个向量，也会让细节语义被稀释。整篇文档的向量更像在表达总体主题，难以稳定匹配到某个具体条款、某个参数或某段代码说明。

第二个是噪声问题。用户问一个很具体的问题时，整篇文档里大部分内容都和答案无关。整篇召回会让模型在大量无关信息中寻找证据，token 成本更高，干扰也更多。

chunking 的价值就在这里。它把长文档拆成更小的知识单元，让检索可以在更细粒度上完成匹配。用户问的是某个参数，系统就尽量召回参数所在的片段；用户问的是某个制度条款，系统就尽量召回对应条款和必要上下文。

粒度变细以后，RAG 才更像在找证据，而不是在找整本资料。

chunk 太大带来的问题

chunk 太大时，最直接的问题是主题混杂。

一个长 chunk 里可能同时包含背景介绍、概念定义、操作步骤、注意事项和例外说明。embedding 会把这些内容压成一个向量，这个向量很难只代表其中某一个主题。用户问一个具体问题时，这个 chunk 可能因为整体主题相关被召回，但里面真正有用的内容只占很小一部分。

这种情况会带来几个后果。

召回粒度会变粗。系统找到的是一大段相关材料，而不是刚好覆盖答案的证据。上下文噪声会变多。模型需要在长 chunk 里自己定位答案，生成时更容易被无关内容干扰。Rerank 也会变难，因为一个 chunk 里部分内容相关、部分内容无关，相关性判断会变得模糊。

还有一个容易被忽略的问题是上下文预算。RAG 最终要把检索结果放进模型上下文。chunk 越大，同样 topK 下占用的 token 越多。系统可能只塞得下几段材料，覆盖面反而下降。

因此，大 chunk 更适合信息本身需要完整上下文的场景，比如概念解释、长段落论证、完整条款说明。对于精确问答、参数查询、FAQ、代码定位，过大的 chunk 往往会增加噪声。

chunk 太小带来的问题

chunk 太小看起来更精准，实际也有明显风险。

语义通常不是按固定长度自然结束的。一个定义可能在上一段，适用条件在下一段，例外说明又在后面。如果 chunk 太小，系统可能只召回答案中的一个片段，模型拿不到完整背景。

这种碎片化会影响生成。模型看到一小段文本时，可能不知道它属于哪个章节、针对哪个对象、是否还有前置条件。为了回答用户问题，模型可能开始补全缺失上下文，幻觉风险也随之上升。

chunk 太小还会导致召回结果变得分散。原本一段完整证据被拆成多个片段，topK 里可能只出现其中一两个。Rerank 排序时，这些碎片单独看相关性有限，完整答案所需的多个片段也未必能一起进入上下文。

所以，小 chunk 的优势是聚焦，代价是上下文不完整。它适合边界清晰、语义短小的内容，比如 FAQ 问答对、独立条款、参数说明。对于依赖长上下文的技术文档和制度文档，过小的 chunk 会让证据失去完整性。

粒度	优势	主要风险	更适合
大 chunk	上下文完整	主题混杂、噪声多、占用窗口	概念解释、长段论证、完整条款
小 chunk	检索更聚焦	语义断裂、证据碎片化	FAQ、参数说明、独立条款
父子 chunk	兼顾召回和上下文	链路更复杂	长文档、制度文档、技术文档

overlap 的作用和副作用

overlap 用来缓解边界断裂。

当一段信息横跨两个 chunk 时，适当 overlap 可以让边界附近的上下文同时出现在相邻 chunk 中。这样即使用户问题命中了边界位置，检索结果也更可能带上必要的前后文。

但 overlap 也有成本。overlap 越大，索引体积越大，embedding 成本越高，重复召回越明显。在线检索时，topK 可能被几个高度相似的 chunk 占满，其他有价值的证据被挤掉。重复内容进入上下文后，还会浪费窗口，甚至让模型觉得某段内容更重要。

因此，overlap 更适合看成对切分边界的补偿。它可以减少边界损失，但不能替代合理的语义切分。

在制度文档、技术说明、教程类文档中，overlap 常常有价值，因为条件、步骤和解释容易跨段。但在 FAQ、表格、代码函数这类边界本来就比较清晰的内容里，overlap 需要更克制。

常见 chunking 策略

固定长度切分实现最简单，也最容易跑通 demo。它按照字符数或 token 数切分文本，再加上一定 overlap。这个方案的优势是稳定、成本低、易实现，适合结构不强的普通文本。它的短板也很明显：切分器不了解语义边界，可能把段落、表格或代码块切开。

按标题层级切分更适合 Markdown、产品手册、技术文档和制度文档。标题本身提供了主题边界，章节路径也能作为 metadata 保留下来。用户问某个功能、某条制度或某段说明时，标题结构能帮助系统定位上下文。

语义边界切分会尽量在段落、句子或主题变化处断开。它更贴近内容本身，也更能保留语义完整性。相应地，它的实现复杂度更高，稳定性和成本也需要额外关注。对于长段说明、论文、技术文章，这类策略通常比固定长度更自然。

父子 chunk 是一种很实用的折中。子 chunk 用来做精细召回，父 chunk 用来提供更完整上下文。在线检索时，系统可以先命中较小的子 chunk，再把它所在的父 chunk 或相邻上下文带给模型。这样既保留了细粒度检索能力，也能缓解证据碎片化。

Late Chunking 的思路更偏向长上下文表示。它希望先在更长上下文中获得语义表示，再处理局部片段，从而缓解传统先切分再 embedding 带来的上下文丢失。正式应用时不一定一开始就需要这种方案，但它说明了一个方向：chunking 和 embedding 的顺序也会影响语义保留。

这些策略没有统一标准答案。更合理的做法是根据文档结构、问题类型、评测结果持续调整。

策略	适合场景	主要风险
固定长度切分	普通文本、快速 demo、结构不强的资料	容易切断段落、表格或代码块
标题层级切分	Markdown、产品手册、制度文档	依赖原文标题质量
语义边界切分	技术文章、论文、长段说明	实现复杂度和成本更高
父子 chunk	既要精细召回，又要完整上下文	检索和上下文扩展链路更复杂
Late Chunking	希望保留更长上下文语义	不一定适合一开始就引入

不同文档类型的切分思路

chunking 策略要服从文档类型。

普通文章和说明文档通常可以按标题、段落和语义边界切分。制度文档要保留条款编号、适用范围、例外说明和生效条件。表格要尽量整块保留，至少要让表头、单位和行列关系进入同一个语义单元。代码文档适合按函数、类、模块切分，函数签名、注释和函数体要保持在合理范围内。FAQ 更适合按问答对切分，问题和答案需要放在同一个 chunk 中。

统一固定长度切分虽然简单，但很难覆盖所有内容形态。文档类型越复杂，越需要把结构信息带入切分策略。

文档类型	切分重点
普通文章 / 说明文档	标题、段落、语义边界
制度文档	条款编号、适用范围、例外说明、生效条件
表格	表头、单位、行列关系尽量放在同一语义单元
代码文档	函数、类、模块、函数签名和注释
FAQ	问题和答案放在同一个 chunk 中

这一点和上一篇的文档结构化直接相关。结构化做得越好，chunking 越容易贴近真实语义边界。表格结构、标题层级、代码块边界、图片说明，这些信息在切分时都应该被利用。

chunk 和 metadata 的关系

chunk 是文本片段，metadata 让它带上身份。

一个 chunk 至少应该知道自己来自哪份文档、哪个章节、哪个页面或段落位置。对于生产系统，还要继承文档级 metadata，比如产品线、部门、文档类型、语言、发布时间、更新时间、权限范围和索引版本。

chunk 级 metadata 也很重要。chunk 序号可以帮助恢复原文顺序，父 chunk ID 可以支持上下文扩展，切分策略可以帮助排查效果变化，页码和章节路径可以支持引用，embedding 模型版本和索引版本可以帮助后续重建。

metadata 会直接影响在线检索。系统可以先按权限、产品线、文档类型、时间范围过滤，再做向量检索或关键词检索。这样既能减少噪声，也能降低权限风险。

没有 metadata 的 chunk 也可以被召回，但系统很难判断它是否属于当前用户、当前产品、当前版本。chunking 和 metadata 应该一起设计，而不是切完文本后随手补几个字段。

chunking 需要评估和迭代

chunk 策略不能只靠经验拍定。

同一份文档，不同 chunk 大小、overlap、标题策略和父子 chunk 方案，会带来不同召回效果。评估时可以构造一批真实问题和标准证据，观察正确 chunk 是否进入 topK，是否被 Rerank 排到前面，最终答案是否能基于证据生成。

检索层可以看 Hit@K、Recall@K、MRR。生成层可以看 Faithfulness、Answer Relevancy、Context Precision、Context Recall。更重要的是看失败样本：哪些问题没有召回正确 chunk，哪些问题召回了但上下文不完整，哪些问题因为重复 chunk 挤占了窗口。

chunking 的优化通常来自这些失败样本。发现证据经常被切断，就要调整语义边界或增加父子 chunk。发现 topK 里重复内容太多，就要控制 overlap 或做去重。发现表格问答效果差，就要重新处理表格结构。发现代码问答缺少上下文，就要按函数、类或文件结构重新切分。

好的 chunking 策略是迭代出来的。它要结合文档类型、业务问题、检索指标和生成效果一起看。

失败现象	优先排查方向
正确证据经常被切断	调整语义边界，或引入父子 chunk
topK 里重复内容太多	控制 overlap，增加去重
表格问答效果差	重新保留表头、单位和行列关系
代码问答缺上下文	按函数、类、文件结构重新切分

小结

chunking 是 RAG 从文档到索引之间的关键设计。

chunk 太大，检索粒度变粗，噪声和上下文占用都会上升。chunk 太小，语义容易断裂，模型拿到的证据会变成碎片。overlap 可以缓解边界损失，也会带来索引膨胀和重复召回。固定长度、标题层级、语义边界、父子 chunk、Late Chunking 都是在不同场景下处理粒度和语义完整性的方案。

这篇的核心可以收成一句话：

chunking 决定文本以什么粒度进入索引，也决定模型最终能拿到怎样的证据。

下一篇继续往下走。chunk 确定之后，这些文本会被转成向量，进入向量索引。接下来要看的是 embedding、相似度计算和向量数据库如何影响检索质量。