RAG 切块不是越碎越安全吗？

[小周]

我们把制度文档切到 300 字一个块，召回数量上去了，但回答反而更飘。是不是 overlap 还不够？

[林小北]

不一定是 overlap。太碎以后上下文关系断掉，模型拿到的是一堆碎片，不知道哪句属于哪个章节。

[nora]

你们有没有把标题层级带进去？比如一级标题、二级标题、文件名。只靠正文切块会很吃亏。

[米饭]

我以前也以为越碎越准，后来发现“考勤补卡”这种内容，前半段是条件，后半段是例外，拆开就完了。

[rootless]

300 字对政策类可能太短。代码注释、FAQ 可以短，制度和合同至少让一个完整条款在同一块里。

[小潘同学]

overlap 开太大还有副作用，top_k 里全是同一段的近邻，rerank 前就挤掉别的证据了。

[阿航]

可以先做一个小测试集。不要看向量库返回分数，看“答案需要的证据是否同时回来”。

[不想写周报]

我这边是按标题先切，再用长度兜底。标题断了就不切，宁愿块大一点。

[小吴]

有人试过 parent-child chunk 吗？小块召回，大块喂模型。

[小路灯]

试过，适合文档结构稳定的场景。坏处是引用要处理好，不然引用显示大块，用户找不到原句。

[青菜]

我补个反例。客服知识库短问答，如果块太大，模型会把相邻问题混在一起答。

[林小北]

所以切块不是全局参数，是文档类型参数。制度、FAQ、表格说明、会议纪要要分开策略。

[小周]

我们现在所有文档一套策略，怪不得。明天我按文档类型拆一版测试。

[小周]

隔天补：制度块调到 800-1200 字，FAQ 还是 300-500 字，误答少了。不是最终方案，但方向对。

[nora]

这个结果可以沉淀。记得把“块命中但答案缺证据”的样例也留着，后面调 rerank 用得上。