文档切片决定RAG上限

摘要：

文档切片不是简单地按 500 或 1000 个 token 截断，而是在定义“什么才是一份能够独立回答问题的证据”。规则与例外、表头与数据、代词与主体一旦分家，后续检索再强也只能找到残缺片段；切得太大又会让关键信号被噪声稀释。本文比较固定、结构化、上下文化与 Late Chunking，分析三类证据断裂，并给出一套从真实问题和失败样本反推切片策略的评测方法。最终验收不看平均切片长度，而看真实问题能否召回完整、可引用的证据。

“每 500 个 token 切一块，重叠 50 个。”

这是很多 RAG 项目的第一版切片策略。它简单、稳定、容易批量处理，所以很适合作为基线。问题在于，文档不是均匀的字符流：一条规则可能有条件和例外，一张表的含义依赖表头，一个句子里的“它”依赖几段之前的主体。

当裁刀只认识长度，不认识证据，切片就在检索之前决定了系统的上限。

切片其实在定义证据

切片的本质不是压缩上下文，而是定义检索器能找到的最小证据单位。

块太大时，一个向量要同时表达多个主题。用户问其中一个细节，相关信号可能被整章内容稀释；块太小时，关键词虽然集中，条件、主体、时间和例外却可能留在相邻块里。检索器找到了“相似句”，模型拿到的仍不是“可回答证据”。

所以，好的切片不追求一个全局最佳长度，而要让高频问题所需的证据尽量完整，同时让每个块保持足够明确的主题。

三类断裂怎样发生

三种常见断裂，比长度更值得先看

第一种是规则与例外断裂。

制度写着：“普通退款应在七日内申请。若商品已激活、已下载或属于定制内容，则不适用。”如果切片把第二句放到下一个块，检索“退款期限”只会命中“七日”，回答看似准确，实际漏掉决定业务结果的例外。

第二种是表头与数据断裂。

一行“专业版｜299｜20｜支持”离开“套餐｜月费｜成员数｜API”这组表头后，任何数字都失去含义。把表格转成纯行文本再按长度切，会让检索器找到数值，却无法确认单位和字段。

第三种是代词与主体断裂。

Late Chunking 论文使用了一个直观例子：前文介绍柏林，后文写“它拥有超过 385 万人口”“这座城市是欧盟人口最多的城市之一”。如果后两句被单独编码，传统短块嵌入看不到“它”指柏林；检索“柏林人口”时，语义联系会变弱。

这三类问题共同说明：块里有相关词，不等于块能独立承担答案。

固定切片：应该保留，但只当基线

固定长度或递归切片的优势很真实：规则简单、速度快、结果可复现，便于建立第一条管线。文本结构平坦、段落短、问题主要依赖局部事实时，它可能已经足够。

但它应该回答的是“最简单方案能做到什么”，不是“以后都按这个数字切”。如果团队没有一组真实问题，也没有检查被命中的块是否包含完整证据，讨论 500 还是 800 token 只是参数偏好。

结构化切片：先尊重文档自己的边界

标题、章节、列表、代码块、表格和图注本身就在表达结构。结构化切片先按这些边界分组，再在超长段落中做二次切分。标题路径可以作为元数据附在每个块上；跨页表格需要保留表头；规则段落要把条件与例外绑定。

RAGFlow 的 DeepDoc 把 OCR、版面分析、表格结构和文本位置放在切片之前，本质上是在解决一个前置问题：如果文档结构没恢复，后面就没有可靠边界可切。

Contextual Retrieval：给小块补一段“身份说明”

Anthropic 提出的 Contextual Retrieval，会为每个块生成一段简短上下文，再把这段说明与原块一起用于向量和关键词索引。它公开的例子中，孤立的“本季度收入增长 3%”会被补上公司、财期和文档主题。

这不是把整篇文档塞回块里，而是补足检索时最需要的身份信息。代价是预处理增加模型调用，生成的上下文也可能写错，因此应保存原块，并抽样检查补充文字是否忠实。

Late Chunking：先让全文互相看见，再为小块做向量

Late Chunking 采取另一条路径。传统方式是先切块，再让嵌入模型分别编码；Late Chunking 则先让长上下文嵌入模型编码整篇文档的 token 表示，使每个词在编码时看到全文，然后按块范围做池化，得到块向量。

在柏林示例里，包含“它”和“这座城市”的句子，因为编码阶段已经看见前文，生成的向量与“柏林”更接近。论文报告，“它拥有超过 385 万人口”与“柏林”的相似度从传统方式的 0.7084 提升到 0.8249；“这座城市……”从 0.7535 提升到 0.8498。

这些数字用于说明机制，不是所有数据集的保证。效果依赖长上下文嵌入模型、文档长度和问题类型。

四种策略各自保留什么

Late Chunking 的核心证据，是在多个检索任务中比较传统分块嵌入与“先全局编码、后分块池化”。论文发现，较小块、上下文依赖明显的文档更容易受益；它也明确展示了边界：当任务是从大量无关文本中寻找一个明确“针”，大块传统编码可能更好，因为全文上下文反而引入干扰。

这和制度文档案例一致。若答案依赖前文主体、标题或例外，小块需要恢复上下文；若答案是一个独立编号或错误码，精确、短小的块可能更有效。切片策略必须服从问题类型，不能倒过来。

用真实问题反推切片

设计切片时，可以从“可回答证据”反推，而不是从 token 数正推。

先选一组真实问题，为每个问题标出最小完整证据：答案需要哪条规则、哪些条件、哪个表头、哪段定义。再检查当前切片是否把这些内容放在同一块，或者能否通过标题路径、窗口扩展、父子块和上下文补充在检索时恢复。

接着至少比较四项：正确证据是否进入 Top-K；无关内容占了多少；模型回答是否被证据支持；切片与索引成本是否可接受。一次只改变一种策略——长度、重叠、结构边界或上下文化——用同一组问题回归。

选择也可以很务实：平坦短文本先用固定/递归切片；章节结构强的手册优先结构化；需要小块精确召回但上下文依赖强时，考虑 Contextual Retrieval 或父子检索；有合适长上下文嵌入模型且大量代词、跨段关系时，再测试 Late Chunking。

什么时候固定切分已经够用

Late Chunking 不是默认升级。文档超过嵌入模型上下文窗口、预处理成本敏感、内容主要由独立短事实组成时，收益可能不抵成本。上下文化描述也可能引入新错误，不应替代原文。

如果真正问题是 OCR 错、表格结构丢失或旧版本未清理，换任何切片算法都救不回来。切片优化必须建立在正确解析和版本治理之上。

切片的验收标准

切片不是把文档切小，而是定义什么算一份完整证据；先让问题决定证据边界，再让 token 数服务于它。