RAG 文档切割策略详解：原理、适用场景与选型实践

RAG 中的文档切割（Chunking，也称切分、分块），是把原始文档转换成便于检索和引用的信息单元。常见方法包括固定长度、句子或段落、递归、文档结构、语义边界，以及 LLM 辅助切分。实际系统通常组合使用多种方法。

选型的核心，是让每个块既容易匹配问题，又包含理解答案所需的主体、条件与来源。块太碎容易丢掉限制条件；块太大会混入多个主题、占用上下文预算。检索用的小块与最终交给模型的大段上下文，也不必完全相同。

一、先分清四个设计维度

这些维度可以组合。例如，先按标题识别章节，再递归切成子块；用子块检索，命中后读取父章节。这里同时使用了结构切分、递归切分和父子检索，并不矛盾。

二、六类常见切分策略

1. 固定长度切分：按字符、词或 token

按设定长度依次切割，例如每块最多 512 tokens。字符切分实现简单；按 token 计数更便于控制模型输入长度，但必须使用实际模型对应的 tokenizer。中文汉字数、英文单词数和 token 数不能直接互换。

• 快速建立基线、大批量格式简单的文本，以及需要明确长度上限的场景。
• 运行成本低、实现可控，块数量与存储开销容易估算。
• 可能切断一句话、一个表格或一条带例外条件的规则；长度相同不代表信息完整。

示例：若把“企业版支持离线运行，但首次激活需要联网”切成两块，检索只返回前半句就可能误答。固定长度更适合作为长度约束，配合自然边界一起使用。

参考：Microsoft Learn 文档分块概述

2. 按句子、段落或业务记录切分

利用句号、段落分隔或完整业务记录建立边界，再把相邻小单元合并到目标大小。FAQ 可把一个问题及其答案视作一条记录；对话可按完整问答轮次或一个话题组织。

• FAQ、短知识条目、说明文、客服对话和结构较清楚的自然语言材料。
• 通常比直接按长度截断更容易保留一个完整表达。
• 单句可能依赖前文的“该产品”“上述条件”；一个段落也可能过长或包含多个主题。

实现时要处理中文标点、英文缩写、小数、编号和 OCR 伪换行。遇到短句应适当合并；遇到超长段落再细分。问答记录不宜把问题和答案分开索引后丢失关联。

3. 递归切分：从较大边界逐步细分

按优先级尝试分隔符：先段落，再换行、句末标点、空格，仍超长时才使用更细的边界。它在保留自然结构和控制块长度之间做折中，适合作为通用文本的起点。

以 LangChain 的 RecursiveCharacterTextSplitter 为例，默认分隔符主要是空行、换行、空格和字符级回退；默认长度计算并不等于 token 计数。处理中文时，应配置“。！？；”等边界，并核对最终长度。

• 普通文章、知识库正文、技术文档的章节内部。
• 无需模型参与切分，成本低，规则容易复现和调试。
• 它识别的是分隔符，不会真正理解主题，也不会自动理解 PDF 版面、代码语法或表格结构。

参考：LangChain 递归切分与中文分隔符

4. 按文档结构与版面切分

先识别标题、章节、列表、代码块、表格和图注，再把相应元素组织成片段。Markdown 可利用标题层级，HTML 可利用正文 DOM 结构，JSON 可按对象或记录，代码可按函数、类或语法树节点处理。

例如，一个片段正文虽然只有“默认保留 30 天”，也应携带“产品手册 > 企业版 > 审计日志”的标题路径。标题可以作为元数据；若希望它影响向量匹配，需要明确将其放进用于 embedding 的文本，而非只存在数据库字段中。

• 产品手册、规章制度、API 文档、论文、复杂 PDF 和代码仓库。
• 便于保留业务层级、出处和语义完整性。
• 依赖解析质量。扫描 PDF、双栏阅读顺序、重复页眉和跨页表格识别错误，会直接传递到分块结果。

按 PDF 页码切分可作为保留出处的粗粒度基线，但页面是排版边界，不一定是语义边界。跨页段落可以合并，同时记录页码范围。过长章节仍需递归细分，过短同类元素可在不破坏结构的情况下合并。

参考：LangChain 结构化切分

5. 语义切分：在主题变化处建立边界

常见实现先按句子拆开，给句子或局部句子窗口计算 embedding，再比较相邻窗口的相似度。当语义距离明显增大时建立边界，之后用最小、最大长度约束修整结果。也有基于聚类的变体，需核对是否保留原文顺序。

• 标题不明显、段落组织较弱、主题变化较多的长文或转录文本。
• 可以在没有显式标题的情况下识别内容转换，不必强求各块等长。
• 增加 embedding 计算，效果依赖模型、语言和阈值；同一主题中的转折、否定或例外条件也可能被错误切开。

语义相似并不等于逻辑上不可分。实施时应限制极长块和极碎块，并检查规则与例外、问题与答案是否仍在一起。它是否优于递归切分，需要业务测试集验证，不能仅凭名称判断。

参考：LlamaIndex SemanticSplitterNodeParser

6. LLM 辅助切分：让模型判断段落归属

让 LLM 判断哪些句子属于同一主题，或为连续句子选择段落边界。为控制内容改写风险，可以先给句子编号，要求模型只返回编号区间，再由程序从原文提取对应片段。

• 结构混乱、需要理解业务语义、且能够承担离线处理成本的重要文档。
• 有机会识别普通分隔符难以表达的主题、论证或业务单元。
• 成本与耗时较高，输出可能不稳定；模型可能漏句、重排内容或给出非法边界。

工程上应验证编号合法、原文覆盖完整、顺序正确、没有意外重复或遗漏，并设置长度约束和失败回退。若让模型直接重写片段，就要额外检查是否改变了事实、否定和适用条件。“Agentic Chunking”也常用于描述相关方案，但具体实现并不统一。

参考：Chroma 对 LLM 切分及其他策略的研究

三、常与切分搭配的策略

1. 重叠窗口：缓解边界丢失

相邻块共享少量尾部与头部文本。例如块长 C = 500 tokens、重叠 O = 100 tokens，滑动步长为 C − O = 400 tokens。它是一项边界参数，可以配合固定长度或递归切分。

重叠能帮助保留跨边界内容，但会增加重复索引，也可能让检索结果被相似片段占满。忽略首尾效应，固定窗口处理的总 token 量约放大为 1 / (1 − r)，其中 r = O / C；20% 重叠约为 1.25 倍，50% 约为 2 倍。这是索引文本量估算，不等于端到端费用同比变化。

完整 FAQ 或独立记录通常不必机械重叠。递归实现中的 overlap 也可能只是目标值，实际重叠量应抽查；它不能保证任意跨度的答案都完整落在某一块中。

2. 父子分块与层级检索：小块匹配，大块阅读

保存较大的父章节，同时将它细分成较小的子块。先检索子块，命中后沿 parent_id 取回父章节或相关父段落。更深的层级还可以在多个子节点命中后，按规则合并到共同父节点。

它适合“答案句很短，但解释依赖整段条件”的问题。代价是父子映射、更新和存储更复杂，取回父块也可能带来无关内容。应对父块去重，并设置阅读预算，不能一命中就无限扩展到整篇文档。

参考：LlamaIndex 层级节点与自动合并检索

3. 句子窗口检索：命中句子后补邻近句

按单句建立检索单元，同时保存前后相邻句子的关联。检索命中后，用邻近句窗口替换或扩展该句，再交给生成模型。

它与预先重叠切块不同：前者是在召回后扩展阅读内容，后者是在入库时复制边界文本。父子检索依靠文档层级，句子窗口依靠原文位置；两者都需要处理窗口重叠、重复内容和跨章节边界。

参考：LlamaIndex 句子窗口检索

4. 命题级切分：抽取可独立理解的事实

把复杂表达改写为自包含的原子事实，通常需要 LLM。例如“星河设备于2024年发布A系列，它支持蓝牙连接”，可拆成关于发布时间与连接能力的两条事实，并补全代词所指的对象。这里的示例为虚构。

命题粒度适合细节事实检索，但这已经包含信息提取和改写。最容易遗漏的是否定、范围、时态、例外和概率表述。建议把命题作为检索入口，保留原文位置，回答时回查原段落；不应把未经核验的生成命题直接作为唯一证据。

参考论文：Dense X Retrieval

5. 上下文补充：让片段说清“谁、何时、什么场景”

在片段前添加文档标题、章节路径，或依据全文生成的简短说明，然后再建立向量或关键词索引。比如给“续费后继续生效”补上具体产品、订阅项目和版本上下文。

这主要改变检索表示，并不一定改变切分边界。确定性的标题路径可以先做；生成式说明需检查是否忠于原文，并与原始证据分开存储。补充文字也要计入长度预算，不能让重复的通用摘要淹没片段主题。

参考：Anthropic Contextual Retrieval

6. Late Chunking：先编码，再按块聚合向量

传统方式通常先切文本，再分别编码每块。Late Chunking 先让长上下文 embedding 模型处理整篇或一个较大的文本范围，得到带上下文的 token 表示，再按块边界分别池化，生成块向量。

它有助于片段向量保留跨块信息，但需要支持相应 token 表示与池化流程的模型或服务；仅返回单个文档向量的普通 API，不能把该向量再“切成”多个块向量。超长文档仍受模型范围与算力限制，文档变更也可能影响更大范围的向量。它不是检索重排，也不等同于 ColBERT 式 Late Interaction。

参考论文：Late Chunking

四、特殊文档如何处理

对于表格，拆分前应明确用户是在查一条记录，还是要对大量行做汇总。总计、排序和跨行运算不应依赖随机召回几个表格片段，可先定位表格，再由结构化查询或代码执行。Docling 的混合分块体现了“先利用结构，再受 token 预算约束”的思路，也提供了重复表头的表格处理方式。

参考：Docling 混合分块与表格表头处理

五、chunk size 和 overlap 怎样选

不存在适用于所有语料和模型的最佳长度。长度首先受 embedding 输入上限约束，之后还受重排模型长度限制、最终生成上下文预算和证据密度影响。标题前缀、生成说明和其他实际送入模型的内容，都必须计入相应阶段的输入长度。

• 单一事实定位可试较小块；流程解释、条件判断和多步推理通常需要更完整上下文，可通过父块或窗口补全，而非一律增大索引块。
• 短 FAQ 可直接整体索引；长手册先按章节；多主题长文不宜整篇压成一个检索向量。
• 可将 256、512、1024 tokens 与 0%、10%、20% overlap 作为一组初始候选；这只是实验设计示例，不是通用推荐值。对适用的方案再逐步细调。
• 同时观察召回候选数量、重排输入和最终证据 token 数。增加 Top-K、块长度和父块扩展叠加后，很容易超出预算。

例如，最终给证据分配 4,000 tokens 时，较大的片段会占用更多名额；较小的片段可以覆盖更多位置，但可能缺少上下文。应比较在同一证据预算内，各方案能提供多少完整、独立且相关的信息。

六、一个具体例子：如何避免只召回“支持离线”

假设产品说明原文为：“企业版支持在内网部署。首次激活需要访问授权服务。完成离线授权后，基础检索可在断网状态下运行，但云端问答功能仍需联网。”用户问：“断网后所有功能都能用吗？”

• 若只召回“基础检索可在断网状态下运行”，可能遗漏云端问答的限制。
• 把这组说明作为“企业版 > 部署与联网要求”的完整小节，保留适用版本和限制条件。
• 让“断网运行”相关子块负责匹配，命中后取回该小节，使授权条件和功能例外一起进入上下文。
• 预期答案应区分基础检索与云端问答，并提到离线授权条件；不能仅检查是否出现“离线”关键词。

该例是工程说明，不对应具体产品。它说明切分质量应看答案所需证据是否完整，而不只是看每块是否读起来通顺。

七、落地流程与元数据

一条可作为起点的流程是：文档解析与去噪 → 识别标题和内容类型 → 按结构生成初步片段 → 超长片段递归细分 → 短片段按语义边界合并 → 配置必要重叠 → 补充标题路径 → 校验长度与原文覆盖 → 建立索引。检索后再按需要重排、扩展父块或邻近句，并按来源去重。

字符偏移或 token 偏移需要明确以哪一份规范化文本为基准。文档重新解析后不能继续假定旧偏移有效；内容修改或删除时，应同步处理相关父块、子块、索引及缓存。

八、如何证明某种切分更好

先准备真实问题及其对应的原始证据位置，而不是把某一种切分生成的 chunk_id 固定成唯一标准答案。切分一变，chunk_id 和相关块数量都会变化，直接比较块级召回率可能失真。

• 检查正文有无漏失、乱码、意外重复，标题与内容是否错配，表头与单位是否完整，是否存在超长块。
• 观察 Hit@K、Recall@K、MRR 或 nDCG，并注明相关性标注和粒度定义；多证据问题还要检查所有必要条件是否被覆盖。
• 按原文跨度或 token 统计覆盖与无关内容，并将重叠文本去重。避免把同一句重复召回三次当成三份独立证据。
• 检查答案正确性、完整性、引用支持和无答案时的表现，同时记录 P95 延迟、索引体积、构建耗时和调用成本。

对照实验要固定语料版本、问题集、embedding、检索与重排设置、生成提示词。既可以在同一 K 下比较检索，也应在相同最终证据 token 预算下比较回答；否则大块方案可能只是给模型看了更多文字。调参集与最终测试集应分开，并对关键改动做消融。

Chroma 的研究提供了基于相关 token 的精确率、召回率和 IoU 评估思路。其具体实验结果受语料和模型影响，不能直接当作某种切分方法在所有业务中的排名。

参考：Chroma 文档切分评测方法

九、面试回答示例

常见切分策略有固定长度、句子或段落、递归、文档结构、语义切分和 LLM 辅助切分。固定长度便宜但容易截断语义；递归切分适合作为通用基线；结构切分适合手册、代码和表格；语义及 LLM 方法更灵活，但有额外成本且需要验证。

实际项目中，我会先做好解析，按文档结构切分，再对超长部分递归细分，按 tokenizer 控制长度，并保留标题和来源。跨块上下文可通过适量重叠、父子检索或句子窗口补全。最终用真实问题，在相同证据预算下比较召回完整性、答案质量、延迟和成本，而不把某个固定块长或高级策略当成标准答案。