RAG里文档切片到底切多大合适？试了好多效果都不太稳

我现在基本不纠结固定切多少了，纯按 token 切确实很容易把一段完整逻辑拦腰砍断，尤其技术手册里一个参数说明跨了好几段，切完就只剩半句话。我后来改成先按标题层级和段落做自然切分，再对超长段落做二次拆分，短段落就合并到相邻块里，overlap 只留一点点防止边界丢信息就够了。效果不稳很多时候不是切片尺寸的问题，而是召回阶段就没把对的块捞出来，你可以先单独看下 top-k 召回的片段里到底有没有答案，没有的话调切片也白搭。还有个坑是 PDF 解析，表格和双栏排版经常被抽成乱序文本，这种脏数据切多大都救不回来。评估的话我会攒一小批带标准答案的问题，固定住 embedding 和模型，只换切片策略跑一遍，看命中率和答案正确率，比凭感觉调靠谱多了。另外块大小最好跟着 embedding 模型的最优区间走，别硬套别人的 512。

按段落自然切再配上标题做上下文，比死磕token数稳多了，可以试试。

我最近也踩过这个坑，后来发现光调 chunk size 意义不大，关键得看文档结构。技术手册和 PDF 报告里表格、代码块多，硬按 token 切经常把一段完整逻辑劈开，检索时自然就飘了。我现在基本是先用正则按标题层级切，再对超长段落做二次拆分，overlap 只留 10% 左右。评估的话可以搞一批问答对，看召回片段里有没有正确答案，比凭感觉靠谱。

我现在的做法是按文档结构走，优先按标题和段落切，实在超长再按token硬切，纯按固定token切很容易把一句话拦腰截断。另外检索效果不稳不一定是切片的问题，embedding模型和query改写影响也很大，可以先固定切片策略去调那两个变量。评估的话我一般拿二三十个真实问题做小测试集，看召回率而不是光看最终回答，这样能快速判断到底是没检索到还是生成跑偏了。

有没有更详细的教程推荐？

刚入门，这个对我帮助很大。