在 RAG 系统中，知识库的构建质量很大程度上决定了检索和回答的上限。而构建知识库的第一步，就是文档分块——将长文档切分成若干个适当大小的文本片段。语义分块则是一种更智能的方式：它不仅考虑文本长度，还依据内容的自然边界（段落、章节、话题转换点）进行切分，确保每个片段内部语义相对完整、独立。
1. 为什么固定长度切分不够用
最简单的分块策略是按固定 Token 数或字符数切割，例如每 500 个 Token 一段。这种方式实现简单，但容易产生两个问题：
- 语义被强行截断：一个完整的操作步骤可能在 499 个 Token 处被拦腰切断，检索时只能召回半个流程，生成回答时上下文残缺。
- 信息密度不均：有些段落用很少的字数就说清了一个关键定义，固定长度会把它们和其他无关内容压在一起，稀释了检索精度。
语义分块的目标就是让每个 chunk 在大小适宜的前提下，尽可能成为一个自包含的、有独立意义的信息单元。
2. 什么是语义分块
语义分块指的是根据文档的逻辑结构和语义边界来划分文本块。这些边界包括但不限于：
- 段落边界：大多数自然语言中以换行分隔的段落，本身就在同一主题下展开。
- 章节标题：Markdown 中的
#、##标题，PDF 中的大纲层级，标志着话题的切换。 - 列表、表格等结构化元素：有序/无序列表的开始与结束，表格的前后往往需要保持完整。
- 语义相似度突变点：通过计算相邻句子或段落的向量相似度，当相似度明显下降时，表示话题即将转换，这是一个合适的切分点。
3. 常用的实现方法
实践中，语义分块通常组合使用以下策略，而非依赖单一规则：
基于文档结构的分割（最可靠）
如果源文档带有结构标记（如 Markdown、HTML、Word 中的标题样式），直接按照这些层级进行拆分。例如：
- 每个
##二级标题及其下属内容作为一个 chunk； - 如果某个 chunk 仍然过长，再在它的内部按段落或小节进一步分割。
这种方法的效果最好，因为文档作者本身已经标注了信息的组织方式，我们只是在利用已有的结构。
递归字符分割 + 分隔符优先级
LangChain 等框架提供的 RecursiveCharacterTextSplitter 是一种折中方案。它按照优先级从高到低依次尝试用不同分隔符切割：
"\n\n"（段落）"\n"（换行）"。"（中文句号）或"."（英文句号）- 空格或字符
当某个分段长度超出阈值时，用次优的分隔符继续分割。这样既尽量尊重了自然边界，又保证了 chunk 大小不会失控。
基于语义嵌入的分割
对于无结构（如纯文本转录稿）或结构混乱的文档，可以采用语义分割：
- 将文档按句子拆分，计算每个句子的嵌入向量；
- 计算相邻句子向量的余弦相似度；
- 在相似度出现显著下降的位置（例如低于阈值或出现局部极小值）设置分块边界。
这种方法能自动感知话题切换，但计算量较大，适合离线预处理。
4. 实用建议与参数权衡
chunk 大小与重叠的选择
- 大小：常用范围在 256~1024 Token。较小的 chunk 有利于精确定位，但可能丢失上下文；较大的 chunk 能保留更多背景，但精度下降。需要根据文档类型和下游任务测试决定。
- 重叠：在相邻 chunk 之间保留 10%~20% 的内容重叠。这样即使一个完整意思被分在边界附近，重叠部分也能让相邻的 chunk 都包含关键信息，避免遗漏。
优先保留完整表格和列表
表格中的一行单独拆开毫无意义，列表项脱离上下文也容易产生歧义。在分块时，应当将整个表格或整组列表作为一个单元进行切分，即便它超出常规 chunk 大小。可以在元数据中标注“此 chunk 为完整表格”，以便生成时特殊处理。
元数据增强
分块过程中，应尽量为每个 chunk 附加来源信息，包括但不限于：
- 文档名称、版本号、最后更新时间
- 所属章节标题（例如“第 3 章 员工福利”）
- 页码（对 PDF 等格式）
- 归属结构标签（是“条款”、“FAQ”、“步骤说明”等）
这些元数据在检索时本身不参与向量相似度计算，但可以用于后续的过滤（例如只检索特定文档的 chunk）和在生成答案时展示来源。
5. 真实场景示例
某公司需要将《内部技术运维手册》录入 RAG 知识库。该手册为 Markdown 格式，有清晰的层级标题。
- 分割策略：以
##标题为第一级切分点。对于某个特别长的##章节（包含多个故障排查步骤），再根据###子标题或空行进一步切割。 - 重叠设置：每个 chunk 开头和结尾各重叠 100 Token，保证“问题描述”和“解决步骤”跨 chunk 时不丢失相互引用。
- 结果：得到约 200 个语义完整的 chunk。测试阶段，用户提问“服务器 CPU 过高怎么排查？”，系统准确召回包含“CPU 过高排查”步骤的整个 chunk，回答内容完整且可操作。
语义分块不是一套死板的算法，而是需要结合文档特点、业务场景和检索要求来定制的工程实践。花在分块策略上的调优时间，往往能带来检索准确率的显著提升，是 RAG 系统建设中性价比很高的一环。