RAG分块重叠与冗余估算器

分块是 RAG 效果的第一道闸门

分块方式决定了检索系统「看到」的知识单元。块太小，一句话被拆开，检索到的片段缺少上下文，模型拼不出完整答案；块太大，一个块里混了多个主题，向量表示被平均掉，相似度反而不准。行业经验是对中文文档用 300 到 800 字符，英文用 200 到 500 词。

重叠解决什么问题

假设答案正好跨在两块的交界处：「本服务支持退款，」在第一块结尾，「有效期为 7 天。」在第二块开头。没有重叠时，两块都不包含完整答案，检索任何一个都无法回答。加上重叠后，交界处的内容会同时出现在两块里，至少有一块能包含完整句子。

重叠比例建议取块长的 10% 到 20%。低于 10% 时边界保护不足，高于 30% 时收益迅速递减——因为索引体积是按比例膨胀的，而召回质量的提升是对数级的。

重叠的隐性代价

• 存储膨胀：20% 重叠意味着向量总量增加约 25%，向量库的存储与内存开销同步上升。
• 检索重复：相邻块内容高度相似，TopK 返回的结果里可能有 2 到 3 条是同一段内容，浪费了宝贵的上下文配额。
• 注意力稀释：重复内容会让模型误以为该信息更重要，有时反而压制了其他关键信息。

对应的缓解措施是去重：检索后对结果做相似度过滤，把与已选中的块相似度超过阈值的候选剔除，再交给模型。这一步通常比调整重叠长度更有效。

常见问题

应该按固定长度切还是按语义切

按语义切（按标题层级、段落、句子边界）通常优于按固定长度硬切，因为它保证了块内主题一致。实践中常采用组合策略：先按标题与段落做粗切，对超过上限的段落再按句子边界细切，最后给每块补上所属章节标题作为前缀，让块即使脱离上下文也保留语义坐标。

向量存储只有几十 MB，还需要优化吗

存储本身确实不贵，真正的影响在检索延迟和上下文成本。向量条数越多，近邻搜索越慢；TopK 返回的块越大，注入模型的 token 越多，每次查询的费用越高。所以优化分块策略的目标不只是省存储，更是省延迟和省 token。

你可能还想问

重叠比例设多少合适？

常见为块长的一到两成；重叠太少会切断语义，太多则索引膨胀、检索重复，需按文本结构类型调整。

冗余会带来什么代价？

存储与向量检索成本上升、召回片段重复导致上下文浪费；重复内容还可能挤占更有价值片段的入选机会。

怎么判断分块是否合理？

用真实问题做回归测试：看命中片段能否独立回答、是否频繁跨越边界；若常丢关键信息，就增大重叠或改用按语义切分。

相关工具

相关内容