RAG项目上线后召回率暴跌，重排救了回来但幻觉反而变多了？

之前我们上线也遇到过类似情况，后来发现根因不在重排，而是召回阶段就丢了关键信息，重排只是矮子里拔将军。建议你先别急着微调embedding，把BM25和向量检索的结果做融合，很多口语化query靠关键词反而更稳。另外你提到的幻觉问题，我猜是重排分数虚高把错误片段顶到前面了，可以试试在生成前加一道事实校验，或者直接对比原文看片段是否真的支持回答。

混合检索得加上，口语化query靠BM25兜底，向量召回太吃语义精确度了。重排调太狠容易让模型脑补，先卡个相关性阈值。

说到这个我太有同感了，我们之前上线一个法律咨询的RAG也是这德行，用户问“试用期被辞退有赔偿吗”，召回的全是“试用期约定”和“辞退程序”的条款，压根拼不到一块去。后来排查发现，bge-large对口语化短query的语义理解真的弱，尤其缺行业术语泛化，你那个“违约金咋算”其实跟“违约金的计算方式”在向量空间里距离挺远的。

我建议你先别急着调重排，monoT5本质上是在给定候选里挑相对好的，如果Top20里就没几条靠谱的，重排再强也是矮子里拔将军，反而会把那些语义近但事实错的段落排到前面，幻觉自然就多了。混合检索确实值得试，BM25对实体词（合同、违约金）很敏感，能先把硬匹配的段落捞回来，再跟向量结果做RRF融合，我们当时加了之后召回Top10的有效率从20%提到50%左右。

另外你说的query改写，我试过用LLM做，但得加约束，比如只拆解关键词、不扩展同义词，否则它容易把“咋算”改写成“怎么计算方式”这种画蛇添足的，反而更偏。还有个坑是embedding微调，别一上来就全量微调，先用你线上真实用户query去挖掘难负样本，做领域适配，不然容易过拟合到测试集。排查顺序建议是：先看召回源头，统计Top20里有效段落占比，如果低于30%，那问题在检索不在重排，再考虑是否切分粒度太大，比如长合同按章节切而不是固定512字。

混合检索先加上吧，BM25兜底口语化查询很有效，重排调太猛确实容易幻觉。

重排权重别拉太高，先试试召回阶段用BM25+向量融合，比单调精排稳得多。

混合检索真得赶紧加上，BM25对口语化query的容错比向量好太多，我之前也是纯向量召回惨不忍睹，加了关键词权重立马稳了。重排调太高确实会引入幻觉，建议你检查下monoT5是不是把不相关段落也硬排上来了，可以试试给重排结果加个相关性阈值过滤。query改写这玩意儿我也试过，小模型容易矫枉过正，不如直接拿用户原query和改写后的各跑一遍召回再合并。

混合检索先加上吧，你这明显是召回源头就偏了，重排救不回来还容易引入幻觉。

加个BM25兜底，再对重排阈值卡严点，比瞎调embedding快。

我遇到过几乎一样的情况，上线前测试集太干净了，用户一开口全是口语和指代，召回崩是必然的。你提到的重排权重调高反而带来幻觉，这个我太有同感了——monoT5这类精排模型本质是在“矮子里拔高个”，Top20里本来就没啥靠谱段落，它硬挑一个相对相关的出来，LLM再一生成，细节就自己脑补了，A合同条款安到B合同上我这边也出过。

我觉得你先别急着微调embedding，那个成本高且见效慢，更关键的是先解决“根本召不回”的问题。混合检索（BM25+向量）几乎是生产环境的标配了，BM25对关键词和专有名词（比如“违约金”、“合同编号”）特别敏感，能补上向量检索对精确匹配的短板。我当时的做法是双路召回，BM25和向量各取Top30，然后合并去重再进重排，召回率立刻稳了不少。

至于query改写，我试过LLM改写和规则改写，感觉它更适合“口语转书面语”这种明确转换，如果用户问题本身信息量就少（比如只说“那个条款咋写的”），改写反而会放大歧义。你可以先做轻量预处理，把明显的口语词映射到知识库里的标准术语，别全盘依赖模型重写。

还有个排查点你可能忽略了：检查一下用户提问里的实体是不是在知识库里确实存在。如果检索结果里压根没有B合同的内容，那模型把A合同内容安过去，本质是它在硬凑答案，这时候该考虑的是加一个“无答案兜底”逻辑，而不是继续调重排。我建议你按这个顺序试：先上混合检索，再调重排阈值（宁可拒答也别给幻觉），最后看badcase分布决定要不要碰embedding。

我们之前也遇到过类似的坑，口语化query直接把向量检索带偏了，后来发现单纯调重排权重治标不治本，反而把噪声放大了。建议先上混合检索，BM25做关键词兜底基本能保住“违约金”这类实体词，至少召回不会那么飘。至于幻觉，我怀疑是重排把高相关的片段硬塞给LLM，但片段本身跨文档切碎了，信息冲突没被识别出来，可以试试在生成前加一道事实校验，或者按文档来源做分组再送prompt。另外query改写对口语真不一定友好，不如直接做同义词扩展，成本低见效快。

混合检索先上，BM25兜口语化漏召，重排权重别拉太高，不然模型容易自己编。

你描述的这个情况我去年做法律知识库的时候几乎一模一样，口语化query确实是向量检索的硬伤，bge对“违约金咋算”这种表达泛化能力有限，Top20里能命中2-3条已经不算最差了。我当时的排查思路是先别急着动模型，把badcase拉出来分类看，是检索没召回到还是召回了但排序靠后，这两个问题的解法完全不一样。重排权重调高导致幻觉变多，这个我觉得不是重排本身的锅，而是精排把语义相关但事实不同的段落推上来了，模型看到高置信度的上下文就容易“脑补”拼接。混合检索我是强烈建议加的，BM25对合同编号、金额、条款号这类关键词的命中是向量补不上的，而且实现成本比微调embedding低太多。query改写不稳定很正常，可以试试只在检索失败时触发改写，而不是每次都改，另外改写后要做一致性校验，偏太远的直接丢弃走原query。embedding微调放到最后再考虑，那个投入产出比在生产环境里往往不如先把检索链路的分层策略做扎实。

口语化query确实得先做归一化，不然embedding再强也白搭，我们之前拿用户日志跑了一轮同义改写才把召回拉回来。重排权重调高反而幻觉多，大概率是精排把语义相近但实体不同的段落排上来了，得在prompt里加一句“只允许引用检索到的原文”。混合检索值得试，BM25对“违约金”这种关键词特别稳，向量补语义，俩分数融合比单调重排靠谱。另外建议先别急着微调embedding，拿真实badcase做个评估集，半个月就能定位到底是检索还是生成的问题。

你们这个情况我踩过类似的坑，重排权重拉高确实容易把“语义相近但事实不同”的段落顶上来，模型一看上下文全是相关句子，就开始自己脑补细节了。建议先别急着微调embedding，把混合检索加上BM25试试，口语query里关键词匹配往往比纯向量靠谱。另外重排后可以卡个阈值，低分的宁可让它说“没找到”也别硬答，幻觉能压不少。

你这个幻觉变多大概率不是重排的锅，是精排把语义相近但实体不同的段落也拉上来了，模型看到A合同和B合同混在一起就开始自由发挥。我之前也踩过类似的坑，后来在重排后加了一层规则过滤，比如按合同编号或元数据做硬约束，幻觉立马降下来。口语化query这块，光靠query改写确实不稳，建议先用BM25兜底召回，再让向量补语义，混合检索比单折腾embedding微调见效快。排查顺序我一般先看召回里有没有正确答案，再看排序有没有把它顶上来，最后才查生成阶段的prompt约束。

这个坑我们去年也踩过，场景几乎一模一样。你描述的第二点其实特别典型：重排把相关性拉高了，但它只保证“段落和query更匹配”，并不保证“段落之间的一致性”，于是模型在拼接上下文时容易把不同文档的实体混在一起，幻觉反而更严重。我后来在重排后面加了一层轻量的实体校验，把候选段落里出现的合同编号、金额、主体名称抽出来做交叉比对，不一致的直接踢掉，幻觉降了不少。混合检索确实值得试，BM25对“违约金咋算”这种口语短句的兜底能力比纯向量强，但别指望它解决所有问题，query改写才是关键，你效果不稳定大概率是改写时丢了领域词，可以试试约束改写只做同义扩展、不做意图漂移。另外embedding微调成本高、周期长，建议放在最后，先把检索链路里的召回、重排、上下文组装这三段分开打点，定位到底是哪一段在退化。上线前后用户分布变化很大，测试集那套问题根本代表不了真实提问，这点得认。

口语化query直接上向量检索确实容易翻车，建议先别急着微调embedding，试试BM25加向量做混合召回，口语query里关键词匹配往往比语义更稳。重排权重拉太高确实容易把弱相关但字面相似的段落顶上来，模型看到这些噪声就爱脑补，幻觉多半是这么来的。query改写不稳定的话可以只对短query或明显口语化的做，改完还可以加个回退机制，改写结果检索不到原query的分数就弃用。排查时先分层看是召回漏了还是重排排错了，别一上来就动模型。

这坑我去年踩过一模一样的，先说结论：你现在的幻觉变多，大概率不是重排本身的锅，而是重排把那些“语义相似但事实不对应”的段落排上来了，模型拿到这种上下文反而更容易张冠李戴。bge这类稠密向量对口语化query确实吃力，尤其是“违约金咋算”这种，它匹配的是语义相近而不是关键词命中，Top20里只有2-3条有用太正常了。我建议先别急着微调embedding，那个成本高且见效慢，优先上混合检索，BM25对这种短query+专有名词的组合提升非常明显，很多时候能把召回从2-3条拉到7-8条。重排权重调高导致幻觉，我的经验是重排后要加一层“引用约束”，比如让生成模型只允许基于重排后Top3的原文回答，并且要求它标注来源段落编号，这样A合同安到B合同上的情况会少很多。query改写不稳定是因为改写模型本身可能引入幻觉或者丢掉了关键实体，你可以试试只做轻量改写，比如补全指代和省略，别让它自由发挥。最后排查思路我习惯先看召回阶段漏了什么，再看重排有没有把正确段落压下去，最后才看生成，分层定位比一上来就换方案靠谱。

先别急着微调embedding，混合检索加BM25试试，口语化query纯向量确实容易飘。

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

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