RAG检索老召回一堆无关chunk，重排序也救不回来，是我切分方式有问题吗？

你这个现象我太熟了，之前做合同审查RAG也踩过类似的坑。你现在的chunk策略其实不算离谱，但问题很可能出在“语义边界”和“粒度”这两个点上——人事政策里“年假”和“考勤”经常出现在同一章节甚至同一段落里，按300字硬切很容易把“入职第一年”这个前提条件和“年假计算规则”切到两个chunk里，召回时自然就混了。我后来改用标题层级+段落为单位，先按文档结构切出大块，再对超过500字的大块做二次切分，但切分点选在句号或分号之后，并且保证每个chunk里包含完整的条件-结论对，效果好了不少。另外你提到query处理，我觉得“入职第一年”这种带时间限定和逻辑关系的问法，光靠意图改写不够，不如试试在retrieval前做一个轻量级的实体抽取，把“第一年”“年假”拆成两个子查询分别召回再合并，或者给每个chunk手动打上“适用范围”标签，比如“入职年限”“适用人群”，这样reranker能拿到更多信号。不过我还是有点好奇，你用的bge-m3本身对长文本语义切分就敏感，有没有试过在切分时加上一句话摘要作为chunk的索引？这块我还没试通，但感觉能缓解纯字面匹配的问题。

之前做类似问答也踩过这个坑，后来发现单纯按字数切分确实会把语义连贯的段落拦腰截断。你可以试试按文档的标题层级和表格边界做结构化切分，比如把“年假”相关的条款单独抽成一个chunk，再配合关键词过滤前置过滤掉考勤调休。另外topk20对垂直领域有点大，我一般调到10以内，重排序压力会小很多。query改写这块儿，如果意图本身不明确，改写反而会带偏检索方向，不如直接做同义词扩展试试。

说实话我觉得你这问题可能真不在切分上，300字带重叠对人事政策这种强结构化文本来说不算离谱。年假、考勤、调休在语义上天然挨得近，bge-m3这类通用向量模型对细粒度政策条款的区分力本来就有限，reranker也只能在召回集里挑相对相关的，救不了源头混入的噪音。我之前做过类似劳动法问答，后来发现把每个条款的标题、适用条件、例外情况单独抽出来建索引，比盲目按字数切有效得多，比如“入职第一年”这种限定词就该和“年假”绑定在一个chunk里。另外你试过用LLM改写query，但有没有试过反过来，把用户的自然问句拆成多个子查询分别检索再合并？比如“入职第一年有没有年假”可以拆成“入职第一年”和“年假资格”两条，召回交集后再重排，效果往往比单条改写好。还有个小坑，topk=20对垂直领域来说偏高，尤其你chunk粒度小，前20里可能塞了七八个讲考勤的，不如砍到10以内，逼reranker在更精准的池子里挑。当然你也可以看看是不是标题和正文没分开embedding，很多库默认把整段文本一起编码，导致标题语义被稀释了。卡几天正常，这问题本来就要调一阵，别急着全盘重来，先按条款边界重切一批，同时把query拆解逻辑加上，应该能明显改善。

我遇到过一模一样的坑，人事政策这种文档有个特点，条款之间互相引用特别多，按字数硬切很容易把“年假”的适用条件和“考勤”的例外条款搅在一起。你试试按文档原有的章节标题和列表结构来切，比如每个条款单独成一个chunk，别管字数，然后给每个chunk打个标签（比如“年假-适用条件”），检索时先按标签过滤再向量召回，效果会好很多。另外bge-m3对长文本的语义边界其实挺敏感的，你300字可能太长，我后来改成150-200字，重叠降到30，反而准了不少。至于query处理，你那个“入职第一年”其实是个时间限定条件，纯向量检索抓不住这种逻辑关系，可以试试把query拆成主事件+条件两部分，分别检索再取交集。重排序那个环节，bge-reranker对短文本更友好，长chunk它也会乱，所以源头切分确实是大问题。还有个土办法，把常见问题的标准答案做成小样本，用LLM生成一些“伪query”去测试切分效果，比你自己瞎调快多了。

说实话我觉得你这问题挺典型的，我之前做法律政策问答也踩过一模一样的坑。300字带重叠对于人事政策这种强逻辑关系的文本确实容易切碎，比如“入职第一年”这种限定条件经常被甩到下一个chunk里，检索时就丢了关键约束。我后来改成按条款和段落边界切，遇到那种长段落再按句号拆，重叠控制在100字，效果立马不一样。另外你换个思路，别只盯着chunk，query侧其实更关键——“入职第一年有没有年假”这种带时间限定和否定语义的问法，bge-m3直接编码其实挺吃亏的，我试过先用LLM抽取出显式的条件实体（比如“入职第一年”、“年假资格”），再拿这些词去检索，比单纯意图改写靠谱多了。还有你topk=20再重排，前面混着不相关太正常了，因为向量召回本身就把很多语义近但无关的文本拉进来了，我建议你试试混合检索，加个BM25权重，至少能把考勤调休这种高频词干扰压下去。不过话说回来，如果文档本身有明确的结构，比如政策条款带编号，直接用标题+段落做层级索引可能比纯切分更省事，你可以看看那些条款是不是有固定格式。

我之前做类似垂直域问答也踩过这个坑，300字固定窗口+重叠确实容易把语义边界切碎，尤其人事政策里“入职第一年”这种限定条件，经常被切进上一段考勤描述里。后来我试过按文档本身的章节标题和列表结构做切分，先手工标注几轮，让chunk尽量保持一个完整条款或问答对，效果比单纯调字数好很多。另外你说query改写试过，但有没有考虑过对query做关键词权重强调？比如把“第一年”这种限定词单独抽出来做检索前置过滤，我试过把这种时间/条件实体抽出来跟向量检索结果做交集，能滤掉不少无关chunk。还有个思路是干脆把重排序换成两阶段，先跑一个轻量bi-encoder粗排，再用cross-encoder精排，有时候bge-reranker直接上太激进，反而把低分但相关的内容压下去了。你现在的chunk是纯文本还是保留了表格结构？人事政策里表格特别多，换行和缩进丢了信息丢失很严重。

我之前也踩过类似的坑，后来发现光调chunk没用，问题多半在query和索引的匹配上。你那个“入职第一年有没有年假”的query，语义上其实包含“入职时间”和“年假资格”两个子意图，bge-m3对这种复合意图的区分本来就不够敏感，建议试试把query拆成多个子问题分别检索再合并结果。另外切分上可以试试按政策条款的“条件-规则”结构来切，而不是死磕字数，人事文档里每一条政策都有明确的适用条件和例外情况，这比300字带重叠靠谱多了。重排序救不回来有时候是因为召回的候选集本身就太偏了，你可以先看下没重排前的top20里到底混了多少噪音，如果比例高，那问题确实在源头。

试试按政策条款的语义边界切块，别死守300字，年假这种高频问题单独做成QA对索引。

试试把问答对拆开存吧，政策类query意图太细，整段切分容易把关键条件割裂了。

说实话我觉得问题可能出在query跟chunk粒度不匹配上，“入职第一年有没有年假”这种复合语义问题，你按300字硬切很容易把“入职”和“年假”拆到两个chunk里。我之前做类似场景是把规则类文档按“条件+结论”结构切，每个chunk尽量保持一个完整逻辑闭环，另外embedding前对query做个轻量实体抽取，把“第一年”这种修饰词单独拎出来扩写，效果比单纯调topk明显。你可以先看看badcase里被召回的chunk是不是都缺了某个关键条件词。

说实话我觉得问题更可能在query和chunk的语义粒度不匹配上，“入职第一年有没有年假”这种带隐式条件的问法，跟“年假怎么算”表面相似但意图差很远，bge-m3对这种细微差别不一定抓得住。你可以试试先做一层轻量的query结构化，把“入职第一年”这种时间约束拆出来单独过滤，而不是全靠向量检索。切分方面300字对于政策条款确实容易把不同主题硬缝在一起，我习惯按法条编号或者“情形+规定”的自然段落切，重叠降到20字就够。另外topk20对reranker来说噪声太多，不如降到10以内，让第一轮召回更精准。

这问题我太熟了，垂直领域rag十个有八个栽在切分上。300字固定窗口对人事政策这种条款式文本真不友好，年假和考勤经常在同一个段落里，建议你试试按文档原有结构切，比如条款编号或者小标题做边界，再不行就上语义切分。不过我觉得query处理也得分锅，“入职第一年”这种隐含条件，bge-m3不一定抓得住，你试试在改写时把意图补全成完整句子，比如“入职第一年是否有年假”，让检索更聚焦。

说实话我觉得你这问题可能真不在切分上，300字带重叠对人事政策这种文档来说算挺常规的操作了。bge-m3本身对长句和语义边界的敏感度其实还行，但“入职第一年有没有年假”这种query有个坑——它隐含了时间条件和规则例外，而你的chunk大概率是把“年假通用规则”和“入职当年特殊条款”拆到了不同片段里，Top20召回后重排序模型又没学到这种条件关联，自然就乱套。我之前做社保问答也踩过类似的，后来发现与其纠结切分，不如先试试在召回前加一步query结构化，比如把“入职第一年”拆成“入职时间”加“年假资格”两个子意图，或者用LLM生成几个同义改写再分别检索，最后合并去重。另外你重排序用的是bge-reranker的默认阈值吗？我建议把分数分布打出来看看，有时候前排混着不相关的东西是因为分数普遍偏低，模型在矮子里拔高个，这时候不如直接设个动态截断。如果非要动切分，可以试试按文档里的“条款编号”或“定义-适用范围-例外”这种结构来切，而不是纯按字数，尤其人事政策里“例外条款”经常是被误召回的重灾区。

同款问题，bge-m3在垂直领域确实容易把语义近似的词拉到一起，年假、考勤、福利在向量空间里距离太近了。建议试试按政策条款的语义单元切分，比如每一条具体规定单独成块，别死守300字，重叠可以去掉。另外你query改写方向可能反了，这种问题更适合做个简单的规则前置，把“入职第一年”这类条件单独抽出来做过滤，比让LLM瞎改靠谱。

感觉你这个问题更像query和chunk粒度不匹配，300字带重叠对“年假怎么算”够用，但“入职第一年有没有年假”其实是复合意图，得拆成“入职第一年”和“年假资格”两个子问题分别检索再合并。我之前做政策问答也踩过这个坑，后来改成按条款编号切分，再额外维护一个“政策关键词-条款”映射表做预过滤，比单纯靠向量召回稳很多。另外你可以试试在重排序前先做个基于规则的粗筛，把明显不是休假相关的chunk直接踢掉，再送reranker，效果会比直接调topk明显。

我也踩过类似的坑，垂直领域里语义边界比字数重要得多，人事政策这种条款型文本建议按“条款+解释”整体切，300字硬切很容易把“年假条件”和“考勤规则”焊死在一个chunk里。另外bge-m3对长尾query本来就敏感，你可以试试把用户问题先做实体和意图双抽取，再带上下文去检索，比单纯改写效果稳。topk降到10以内，重排序前先看召回里的标题/来源字段做个粗过滤，能省很多事。

试试按政策条款的“条件-动作”结构切块，比固定字数稳，你这种场景语义边界比重叠重要。

另外query里“入职第一年”这种限定词，建议先抽出来做过滤条件，再进向量检索，效果会好很多。

试试按政策条款的语义边界切块，别死守300字，年假这种条目单独成块，召回能准不少。

我最近做法律问答也踩过类似的坑，后来发现问题确实可能在切分上。300字固定窗口对语义边界太粗暴了，像“入职第一年”这种条件句很容易被切散，建议试试按自然段或句号先合并再切，或者用文档结构（章节标题）作为硬边界。另外topk降到10以内，重排序前先做一遍关键词过滤，把明显和年假无关的实体（比如考勤系统）直接剔掉，效果会稳很多。

试试父子chunk，小chunk召回大chunk重排，政策条款按条款编号切分，重叠区留长点，我这么改完效果好不少。