在 RAG 系统中，原始文档需要被切分成若干文本片段（chunk）才能生成向量并入库。分块策略直接决定了检索环节能“找回什么”，进而影响最终回答的质量。一个看似微小的切分差异，可能导致关键信息被割裂或淹没，让系统面对正确文档却无法给出准确答案。
理解分块策略的影响，可以从三个相互关联的维度入手：块大小、重叠度和语义完整性。
5.2.1 块大小：信息密度与检索精度的平衡
块大小通常以 token 数（或字符数）衡量，决定了每个片段承载的信息量。
- 小块（如 100～200 token）：信息集中、语义单一，检索时容易实现高精度匹配。当用户查询是一个具体术语、参数或短句时，小块能精准命中。但过小的块容易丢失上下文——一个答案需要的信息可能分布在多个相邻块中，当只召回其中一块时，模型缺少足够的背景，回答可能不完整或不准确。
- 大块（如 800～1500 token）：携带丰富的上下文，检索到一个块往往就能覆盖一个完整的小节或说明，有利于模型理解问题并生成连贯答案。但块变大会使语义信息变得混杂，一个块内可能同时涉及多个主题，降低检索的准确性——与问题部分相关的块也可能因为计算相似度时“噪声”增多而被排到较后，甚至被漏掉。
实际做法：块大小应与知识内容及预期问题的粒度匹配。对于 FAQ、术语定义类内容，偏小块通常效果好；对于操作手册、合同条款等需要完整上下文才能理解的内容，偏大块更合适。实践中，许多系统从 500～800 token 起步，再根据检索命中率与答案质量进行微调。
5.2.2 重叠度：防止信息在切口处断裂
分块时如果只按固定长度硬切，重要信息很容易在切口处断开。例如，一个完整的操作说明被切成两段，前半段是“请确保设备已断电，然后”，后半段是“按住复位键 5 秒后松开”。任何一块单独看都不完整，检索相关但召回不完整的片段，会导致模型无法给出正确指示。
重叠（overlap） 是解决这一问题的常用手段：相邻块之间保持一定数量的重叠文本。例如，块大小为 500 token，重叠 50 token，意味着块 A 的最后 50 token 会同时出现在块 B 的开头。
- 重叠的作用：为切口附近的句子提供“跨块存在”的机会，确保完整语义被至少一个块完全覆盖。
- 合适的重叠量：一般设置为块大小的 10%～20%。过小的重叠仍然可能错过断裂点；过大的重叠则会造成大量重复索引，浪费存储空间，也可能让检索结果中出现高度雷同的多个块，降低多样性。
示例：某技术手册中的一段“警告：操作前必须佩戴防静电手环，否则可能导致设备损坏。”被硬切后，“否则可能”进入上一块，“导致设备损坏”进入下一块。增加少量重叠，能使完整警告处在一个块内，提高检索召回后的可用性。
5.2.3 语义完整性：遵循文档的自然边界
单纯依赖固定长度和重叠仍不足以解决所有问题。文档天然具有结构——章节、段落、列表、表格——这些边界通常意味着一个完整的信息单元。强行按 token 数切断，会破坏这些语义单元，造成信息残缺或歧义。
追求语义完整性，意味着在分块时尽量尊重原文的自然边界：
- 按段落或小节切分：以自然段作为基础单位，将相邻的短段落合并至接近目标块大小。避免在一段中间断开。
- 保持标题与正文的关联：在某些方案中，会将章节标题附加到该章节下的每一个块中，例如块内容前加上“## 第三章 安装步骤”，确保检索到的片段自带分级定位信息，有助于模型准确理解。
- 处理特殊内容：表格、代码块、公式等以整体保留为宜，跨块截断容易彻底丧失可读性。
实践心得：与其投入过多精力寻找“完美块大小”，不如先用文档原生的段落/章节作为切分依据，再辅以长度控制与重叠。很多 RAG 框架（如 LangChain、LlamaIndex）提供的分块器都支持按句分割、按段落分割以及保护分隔符的策略，选择或定制适合文档类型的拆分规则，比单纯调参数更重要。
5.2.4 对检索效果的综合影响评估
| 策略维度 | 设置不当的典型问题 | 优化方向 |
|----------|-------------------|----------|
| 块大小 | 过小：答案不完整、上下文缺失；过大：检索精度下降、无关信息干扰模型 | 根据内容类型与问题长度选择，通常 300～800 token 为起步区间 |
| 重叠度 | 无/过小：关键句被截断无法命中；过大：冗余召回路、噪音增加 | 设 10%～20% 重叠，并验证切口处句子的完整度 |
| 语义完整性 | 标题脱节、碎片化列表、表格截断导致不可读 | 遵循段落/章节边界，附加标题，对特殊内容整体保留 |
一个验证方法：在正式上线前，选取几十个真实场景的问题，人工检查检索召回的片段是否直接包含了必要信息。如果出现“确实检索到了正确文档，但片段内缺关键数据”的情况，很可能就是分块策略需要调整的信号。
分块看似是一项基础的数据预处理任务，但它是检索质量的起点，也是后续大量优化工作的底座。投入时间设计合理、适合自有文档特征的分块策略，能显著降低 RAG 系统后期调优的难度，让检索更准、回答更稳。