RAG系统里文档切片后召回结果总是不准，怎么调切片策略？

可以试试按标题和章节层级切，长段落再二次分割，比固定token稳得多。

切片这事真没有银弹，我们之前也踩过类似的坑。后来改成先用spaCy做语义段落识别，再对超长段落按标题和列表结构二次切分，召回准了不少。你可以试试按“语义完整性”优先，而不是死磕token数，比如把步骤性内容强制保留在一个块里。另外建议给每个切片生成一句摘要作为元数据，检索时用摘要+原文双重匹配，能缓解上下文割裂的问题。至于评估，我们当时简单粗暴地建了个50道题的测试集，手动标注正确答案所在切片，跑一遍算召回率，比看embedding相似度直观多了。

我之前也踩过这个坑，固定token切文档最大的问题就是它根本不理解内容结构，尤其技术手册里步骤和警告信息往往是强绑定的，一拆就散。后来我改成“结构感知”的切法，先按markdown标题和列表层级分块，再对超长段落做二次切分，切分点强行卡在句号和换行符上，召回率明显稳了。你那个512 token上限其实不用太死，我试过对复杂步骤用256的块加128的父子重叠，反而比单纯重叠20%效果好。另外embedding模型换一下可能也有用，OpenAI那个对长句的语义粒度不够细，可以试试bge-m3或者Cohere的embed-v3，在技术文档上差别挺大的。至于自动评估工具，我自己写了个脚本，从标注好的问答对里随机抽几十条，用hit_rate和MRR算不同策略的分数，比肉眼判断靠谱多了。你可以先拿十个典型问题跑一遍，看哪些片段是“表面相关但缺关键动作”的，再针对性调块大小。最后提醒下，别光调切片，检索后的重排序也很重要，加个cross-encoder能把那些混进来的无关段落踢掉。

我之前也踩过这个坑，固定token切对步骤类文档确实不友好。后来换成按标题层级切，再用小模型判断段落是否完整，效果好了不少。你们文档有没有明确的结构标记？如果有的话可以试试递归切分配合语义去重，召回时再加重排序，能缓解割裂问题。

按标题层级切再合并试试，手册类文档结构比长度靠谱多了。