一句话先说清RAG 切文档的时候相邻两块之间要不要留一段重叠overlap留多少这事比很多人想的重要。重叠太小一句关键的话被生生切两半两边都召回不全重叠太大向量库里全是冗余检索还容易把好几块几乎一样的段落一起捞回来。我拿一份运维手册实测过一组今天把怎么定 overlap 讲透。不留重叠会怎样先看反面教材。我最早图省事按固定 500 字硬切零重叠。结果有个问题死活答不对「数据库主从切换后缓存要不要手动刷新」。扒日志发现手册里这句话的答案——「主从切换后需手动执行 flush否则会读到旧数据」——刚好被切在两个 chunk 的接缝上。前半块「主从切换后需手动」后半块「执行 flush 否则读到旧数据」单看哪一块向量都跟问题不够贴两块都没进 top5。这就是零重叠的典型坑语义被物理切割截断。一个完整的因果、一组步骤、一个定义被字数硬生生劈开两半各自残缺。overlap 怎么定给个实测参考我固定 chunk 大小 500 字只动 overlap拿同一份标注集量 recall5overlaprecall5向量库膨胀备注00.78基准接缝处的答案捞不全5010%0.8811%性价比最高10020%0.9125%还在涨但变缓20040%0.9260%几乎不涨了纯浪费规律很清楚从 0 加到 10%~20%召回明显往上走再往上加收益迅速摊平存储和检索成本却线性涨。所以我现在的默认值就是chunk 大小的 15% 左右比如 500 字的块留 75 字重叠按句子边界对齐别从字中间切。def split_with_overlap(text, size500, overlap75): chunks, start [], 0 while start len(text): end start size chunks.append(text[start:end]) start end - overlap # 回退 overlap制造重叠 return chunks重叠太大的反噬overlap 拉到 40% 那次我还碰上个意外问题检索回来的 top5 里有三段内容高度雷同因为它们本就大面积重叠。等于五个名额被同一坨信息占了三个真正多样的资料反而挤不进来模型看到的视野变窄了。后来我在重排那步加了个去重把相似度过高的块合并才缓过来。所以重叠不是越大越保险。它解决的是「接缝截断」代价是「冗余和重复召回」得卡在一个平衡点。还有个更省心的法子如果你的文档结构清楚有标题层级、有明确的步骤编号与其纠结字数重叠不如按语义边界切——一个小节一块、一个步骤一块天然不会从句子中间断开overlap 的需求就小很多。我现在的策略是结构化文档优先按标题切实在是大段连续正文才退回固定长度重叠。这些切法我没自己写一堆解析代码。智能体配在一个零代码就能搭 RAG 的平台上文档传上去能选切分方式、调 chunk 大小和重叠比例向量化它自动做我主要精力花在调参和量召回上。当然它给的切分策略也就那几档真遇到特别刁钻的版式还得自己预处理过一遍再喂进去别指望它全自动搞定。(模型和知识库我都走讯飞星辰 MaaS托管的现成大模型和 RAG直接调没自部署)你们 overlap 一般留多少有没有也遇到过答案卡在接缝上死活召回不到的评论区说说你的切分配方。