RAG 文档切片重叠过大时如何控制上下文膨胀

RAG 检索结果突然变长，最常见的原因不是模型“记住得更多”，而是相邻文档块带着大量相同文字一起进入上下文。处理方法是先把 chunk_overlap 限制在 chunk_size 的一半以内，再结合段落边界、召回数量和唯一 token 比例做小步调整。重叠窗口负责保留跨块语义，不应该承担“把整段原文复制到下一块”的职责。

如果使用 OpenAI Vector Store，可先查看官方参数说明：https://platform.openai.com/docs/api-reference/vector-stores-files。官方文档中的自动切片示例是 800 token 块、400 token 重叠；静态切片还要求重叠不超过块大小的一半。这个数值是接口边界和起点，不是所有知识库的最佳答案。

为什么 overlap 变大后上下文会失控

假设每个块有 800 token，重叠 400 token，连续三个块至少有两段重复区域；当检索同时命中相邻块时，模型收到的不是三份独立证据，而是被重复拼接的同一段内容。重叠比例越高，文档被切出的块越多，向量索引、元数据和召回后的去重工作也会同步增加。

这里要分开看三个量：切片数决定候选规模，召回数决定送入重排或生成阶段的片段数量，重叠比例决定这些片段之间有多少重复。只调小召回数可能让答案漏掉关键段落，只调大块大小又可能把无关内容一起召回。真正要压缩的是“重复内容占上下文的比例”。

先用硬上限，再按语义边界下调

调参时先记录当前块大小，不要同时改变 embedding 模型、召回数量和重排阈值。一个简单的起点是：

chunk_size = 800
overlap = 160  # 先从 20% 起步，保留跨段语义
assert overlap 

160 token 的重叠只是示例。说明书、API 参考通常需要保留标题和前置条件，可以略高；日志、FAQ 列表或彼此独立的短条目则应更低。优先按标题、列表项、代码块和表格边界切分，再让 overlap 兜底跨越少量上下文。不要用 overlap 修补一个本来就错误的分段器。

用一组可比较的指标判断是否有效

每次只改一个参数，固定同一批查询和答案标准。对每个查询记录召回片段总 token、拼接后的唯一 token、重复 token 占比、命中金标准段落的覆盖率，以及最终答案引用是否完整。可以用下面的关系快速定位问题：重复比例 = 1 - 唯一token数 / 召回token总数。重复比例下降但覆盖率也下降，说明 overlap 削得过猛。

建议至少比较三组：低重叠、中重叠和当前配置。把查询按“定义、步骤、跨段关系、表格字段”分组，分别看结果。若只有跨段关系类问题变差，不要把所有文档都调回高重叠，可以只给这类文档保留结构化父子块或更清晰的段落边界。

生产配置保留一条可回滚的基线

切片配置应和索引版本一起保存，例如记录文档解析器、chunk size、overlap、召回数量和评测集版本。上线时先用小批文档重建索引，确认回答引用没有明显退化，再切换读流量。若上下文成本下降却出现“答非所问”，优先恢复上一版索引，而不是继续叠加更复杂的过滤条件。

常见问题

overlap 越大，RAG 答案一定越准确吗？

不一定。它只提高跨边界保留信息的机会，也会增加重复内容；当相邻块本来语义独立时，收益很小。

应该先调 chunk size 还是召回数量？

先固定召回数量和评测集，调整 chunk size 与 overlap；确认重复比例后，再单独优化召回数量。

如何判断是切片问题还是模型上下文问题？

先把召回片段原文和 token 统计记录下来。如果输入已经重复或缺少关键段落，问题在切片或检索；输入合理而回答仍错，再检查提示词和模型。