在 RAG 系统中，将长文档切分成较小的片段（chunks）是索引构建的关键步骤。而分块策略中一个容易被忽视却对检索质量影响很大的参数，就是重叠度（overlap）。所谓重叠，指的是相邻两个 chunk 之间共享的部分文本。合理设置重叠度，可以避免重要信息被切分切断，同时维持检索效率。
1. 为什么需要重叠？
文档的自然段落、句子之间往往存在紧密的语义连贯性。如果严格按照固定长度切分而不重叠，一个完整的概念可能恰好落在两个 chunk 的边界上被“腰斩”。
举例说明：
原文某段是：“申请报销需提交发票原件和出差审批单。财务部门在收到完整材料后的 5 个工作日内完成审核。”
若按每 20 字切分，第一个 chunk 可能结束于“完整材料后”，第二个 chunk 以“的 5 个工作日……”开头。当用户提问“报销审核需要多长时间？”时，检索可能只命中第二个 chunk，而缺少前置条件“在收到完整材料后”，导致模型只看到“5 个工作日”，遗漏了关键的限定条件。
通过设置重叠，让第二个 chunk 也包含一部分上一个 chunk 的文本，可以有效保留跨越边界的语义完整性。
2. 重叠度的核心考量因素
重叠度通常以字符数、词数或句子数定义，也可用 chunk 大小的百分比来表示。没有“一刀切”的最佳值，但可以从以下几个方面权衡：
- chunk 大小：chunk 越大，重叠比例通常可以设置得较低，因为大 chunk 自身已有较强的上下文。小 chunk（如 100～200 字）则建议较大的重叠（如 10%～20%），防止碎片化。
- 文本类型：结构化程度高的文档（如表格、条款）对边界的位置较敏感，可适当增加重叠；叙事性文档（如新闻、博文）对不完整语义的容忍度略高。
- 嵌入模型的最大序列长度与语义敏感度：某些嵌入模型会将很短的片段向更大的语义单元对齐，此时在句子边界切分并设置 1～2 句的重叠更利于保留语义。
- 检索与生成的平衡：过多的重叠会增加索引大小和检索噪音，甚至导致同一个信息在多个 chunk 中重复出现，影响回答的简洁性。需要在覆盖度和信号噪声比之间找到折中。
3. 实用的设置方法与经验值
基于句子或段落切分优于简单按字数切割，因为自然语言的边界本身就是语义信号。建议的常用策略：
- 以句子为单位切分，设定 1～3 句的重叠。例如每个 chunk 包含 5～10 个句子，相邻 chunk 共享 1～2 句。
- 如果采用固定长度切割（如 512 tokens），推荐设置 10%～20% 的重叠量（例如 50～100 tokens）。很多实践者发现，token 级别的 15% 重叠在大多数场景中表现稳定。
- 对于包含大量步骤或长关联逻辑的文档（如合同条款、技术规范），可以考虑将重叠度提高到 25%，确保逻辑链条不因切割而断裂。
探索与调整方法：
选取一批典型的测试问题，改变重叠度，观察检索到的 chunk 是否完整覆盖答案所需信息。对比多个重叠值下的回答准确率，快速找到适合本知识库的平衡点。
4. 配合其他分块技巧
重叠度并非孤立参数，它常与以下策略搭配使用：
- 尽量在自然分隔符处进行切割（如句号、段落结束、换行）以维持语义块的自包含性。
- 携带元数据：将上级标题、章节名等作为上下文前缀附加到每个 chunk，可进一步补偿因切割丢失的全局信息，此时可略微降低重叠度。
- 动态分块：针对 FAQ 或对话记录等短文本，可以选择不切割，仅添加少量元数据重叠；而对于长文，结合重叠度和句子边界更稳健。
5. 常见误区与提醒
- 过度重叠：有时为了“绝对不遗漏”将重叠设为 50% 甚至更高。这会极大增加存储和计算开销，同时让检索结果中出现大量重复信息，反而干扰模型判断。一般超过 30% 就需要谨慎评估必要性。
- 忽略切分顺序：重叠应发生在相邻 chunk 之间，而不是所有 chunk 随机覆盖。保证原始文档的逻辑顺序通过有序 chunk 序列被保留。
- 硬性数字崇拜：遵循“最优值”而不根据自身文档特点做实验是常见错误。同样的重叠度在新闻语料和法规条款中的效果可能截然不同。
总结：重叠度的设计目标不是让 chunk 之间“连续不断”，而是确保任何一个需要完整上下文的答案点，都至少完整地存在于某一个 chunk 中。从 10%～20% 的句子级共享开始尝试，结合实际查询效果做微调，是用好这一参数的最务实路径。