搭建 RAG 知识库时，大家通常把精力放在选模型和选向量数据库上，却很少认真对待文档切分。实际上，切分方式决定了检索的基本单位，切得不好，后面的检索和生成再强也无法弥补：要么关键信息被切断在两个块之间，要么一个块里塞了太多无关内容，稀释了语义。

为什么需要切分

一方面，Embedding 模型有输入长度上限，整篇长文档无法直接编码；另一方面，一个向量很难同时准确代表一篇文档里的多个主题。把文档切成较小的片段，每个片段语义更集中，检索时也能只把相关部分送进大模型，节省上下文和成本。Embedding 的基本原理可参考文本向量入门。

常见的切分策略

固定长度切分

按固定的字符数或 Token 数切分，简单直接，适合格式混乱、没有明显结构的文本。缺点是完全不考虑语义，可能把一句话从中间切开。

按段落或句子切分

以自然段或句子为边界，再把相邻的小段合并到目标长度。语义完整性更好，是大多数场景的合理起点。

按文档结构切分

利用标题层级、章节编号、Markdown 或 HTML 标签切分，让每个块对应一个完整的小节。适合产品手册、制度文件、技术文档等结构清晰的资料，通常效果最好。

语义切分

计算相邻句子的语义相似度，在话题明显转换处切分。理论上更贴合内容，但计算成本较高，效果也依赖具体文本，并不总是优于结构化切分。

块大小怎么定

块大小没有通用最优值，需要根据内容和问题类型权衡：

  • 块太小：语义不完整，缺少上下文，比如只检索到“该条款不适用于以下情况”，却不知道“该条款”是哪条；
  • 块太大：包含多个主题，向量代表性下降，检索精度降低，同时占用更多上下文。

实践中，可以从中等长度开始，例如几百个 Token，用真实问题测试检索命中率后再调整。事实型问答通常适合较小的块，需要综合理解的问题则适合较大的块。

重叠的作用与代价

相邻块之间保留一定重叠，可以降低关键信息恰好被切断的风险。但重叠会增加存储量，也可能让检索结果中出现内容高度重复的多个块。一般设置为块大小的一小部分即可，结构化切分时可以少用甚至不用重叠。

让块“自带上下文”

一个非常有效的技巧是给每个块补充元信息：

  • 在块的开头加上文档标题和所属章节路径，例如“员工手册 > 休假制度 > 年假”；
  • 记录来源文件、页码、更新时间，便于引用和过滤；
  • 对于含义依赖上下文的块，可以用大模型生成一句简短说明，描述该块在全文中的位置和主题。

这些信息既能提升检索准确率，也方便在回答中标注出处。

特殊内容的处理

表格

不要把表格按行硬切。小表格整体作为一个块；大表格可以按行分组，但每组都要保留表头。复杂表格的解析问题见 PDF 与表格解析的坑。

代码

按函数或类切分，保留文件路径和所属模块信息，避免把一个函数切成两半。

FAQ

一问一答天然适合作为一个块，问题本身也是很好的检索锚点。

用评测指导调整

切分策略的好坏最终要靠数据说话。准备一批真实问题并标注应该命中的文档段落，比较不同切分方式下的召回率，再结合重排序模型和混合检索整体优化。

小结

文档切分没有万能方案。优先利用文档自身结构，为每个块补充标题和来源等上下文，对表格、代码等特殊内容单独处理，再用真实问题评测迭代，是提升 RAG 检索质量最具性价比的方法之一。