在 RAG 系统的索引构建阶段，如何将文档切分成适合检索的片段（chunk），直接决定了后续召回内容的质量。传统的固定长度分块（例如每 500 个字符切一刀）虽然实现简单，但往往会在语义上造成割裂，影响检索精度。语义分块（Semantic Chunking）是一种更智能的替代方案，它依据文本自身的语义边界进行切分，让每个片段都保持相对完整的意思。
1. 固定分块的问题在哪里
固定分块忽略文档的自然结构，只按字符数或词数硬性截断。实际应用中会暴露出三类典型缺陷：
- 语义断裂：一个完整的操作步骤被拦腰截断，前半段讲“点击设置按钮”，后半段讲“选择高级选项”，两个片段分开看都失去意义。
- 上下文丢失：一段需要结合前文才能理解的论述（比如“如上所述，此方法的局限性在于……”），被切到新的片段后，模糊的指代让检索难以命中和匹配。
- 冗余与噪声：为了让每个片段都包含足够上下文，往往需要设置重叠窗口（overlap），这又会导致部分内容重复出现，降低检索效率，还可能让生成环节接收到重复信息。
直观感受：想象把一本菜谱按每 300 字强行拆开，很可能出现“加入 3 克盐”和“搅拌均匀”分属两个片段的情况，检索出前者而遗漏后者，就做不出一道完整的菜。
2. 语义分块的做法
语义分块的核心思路是“尊重文档本身的结构和语义边界”。它不预设统一的切分长度，而是根据内容特征动态确定切割点。常见的实现方式包括：
- 基于自然分隔符：优先在段落、换行、标题标记等天然断点处切分，保持段落级的完整性。
- 利用模型理解语义边界：使用一个小型嵌入模型或专门的断句模型，逐句分析相邻句子之间的语义连贯性。如果前后句的向量相似度出现明显下降，说明话题发生了转变，此处就是一个合理的切分点。
- 结合文档结构元数据：对于 PDF、Markdown 等带格式的文档，直接识别章节标题、列表项边界，将同一标题下的内容尽量合并为一个片段。
实际工程中，通常会组合使用上述方法。例如：先按章节标题切大块，再在每个大块内部，用语义相似度阈值判断是否需要进一步细分，确保每个片段的主题相对集中。
3. 语义分块带来的实际提升
采用语义分块后，RAG 系统的检索和生成质量会有明显改善：
- 精准召回：因为每个片段都承载了一个完整的信息点，用户提问的语义更容易和片段语义对齐。不会出现“命中了片段后半句，但前半句才是想要的”的尴尬。
- 减少无效 token 消耗：片段不再需要大量重叠来弥补上下文缺失，单个片段更精炼，传递给生成模型的信息密度更高，既节省成本，也加快响应速度。
- 更好的溯源可读性：当答案引用某个片段时，用户查看原文片段，能直接看到一个完整的句子、一个完整的步骤，而不是一段被硬生生截断的残文，理解更顺畅。
- 适应多类型文档：对于排版复杂的文档（如合同条款、技术手册），语义分块能自适应不同部分的密度，而不用为整体设定一个一刀切的长度。
4. 一个真实的选择场景
某公司用 RAG 处理内部技术手册，最初直接使用 512 token 固定分块。测试中发现，当员工提问“如何配置负载均衡的健康检查”时，召回的第 1 个片段末尾刚说到“进入负载均衡设置页面”，第 2 个片段开头却紧接着一段无关的日志配置说明。原因就是固定分块恰好在关键步骤中间切断了。
切换到语义分块后，系统能够识别“## 健康检查配置”这一节标题，并将该节下的 3 段内容完整保留为一个片段。员工再提问时，这 3 段被一次召回，模型能据此给出完整的配置步骤，回答准确率从 72% 提升到了 91%。
5. 实施中的实用建议
- 不需要“完美”语义理解。用简单的句子相似度模型（如 all-MiniLM）就能取得不错的效果，成本远低于肉眼分块。
- 设置最小和最大长度保护。避免出现单个片段短到只剩一个词，或长到超过模型上下文窗口的极端情况。例如，最小 100 字符，最大 1000 字符。
- 版本化管理分块策略。语义分块的边界可能随模型或参数调整而变化，建议将分块策略记录在知识库元数据中，便于追踪和复现。
- 离线处理，不增加在线时延。语义分块完全在索引构建阶段完成，对用户提问时的检索速度没有影响。
语义分块不是“花架子”，而是通过更合理地保留信息完整性，直接提升了检索命中的有效率和生成答案的可用性。对于知识密集、文档结构复杂的业务，它往往是小投入换来大提升的关键优化项。