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

混合检索真得赶紧加上，bm25对口语化query的容错比纯向量好太多，我们线上也是这么救回来的。另外重排权重别调太猛，monoT5对长文档容易过度自信，建议把重排后的分数和向量相似度做个加权融合，能压住幻觉。query改写这块可以试试只对名词实体做扩展，别动动词和语气词，不然容易跑偏。你们线上有没有做相关性反馈？可以拿badcase去微调一下bge，比纯调重排管用。

实话实说，你这个情况我太熟了，上线前后简直是两个世界。我觉得你现在的核心问题不是重排或召回单点的事，而是整个链路对“口语化query”的容错太差，bge-large对短文本和术语的匹配还行，但遇到“违约金咋算”这种省略主语的问法，向量空间里根本拉不远。我个人建议先别急着动embedding，那玩意微调成本高且容易过拟合，不如先把混合检索加上，BM25对关键词的精确命中能兜住向量召回的漏，至少能把Top20里的有效段落从2-3条拉到6-7条。至于重排调高后幻觉变多，我怀疑是monoT5在重排时给了那些“语义相关但事实不匹配”的段落过高分数，你不如把重排后的段落做个事实一致性校验，比如用NLI模型或者简单的实体对齐过滤一遍，不然它会把A合同的条款和B合同混在一起生成。另外query改写这块，我试过用LLM做多轮改写然后取交集，但效果确实不稳定，现在生产上我干脆不用了，改成对原始query做同义词扩展加BM25，反而更稳。你排查的时候最好把线上失败的case拉出来，看看是召回阶段就错了，还是重排阶段把错的排上来了，同时监控下Top5和Top20的命中率变化，别只看最终答案准不准。反正这条路没有银弹，混合检索+轻量过滤大概率比单点优化见效快，你可以先试一周看看线上反馈。

混合检索肯定得先加上，BM25对口语化query的精确匹配比向量靠谱多了，尤其你这种合同条款场景。重排别光调权重，试试把重排结果和原始向量得分做个融合，不然容易让模型硬着头皮选不相关的段落。另外幻觉问题大概率是生成阶段太信任重排后的Top1，建议加个引用溯源校验，让LLM只基于检索到的原文片段回答，答不出来就直说。

混合检索肯定得加，BM25对口语化query的容错比纯向量好太多，你Top20里能用的才2-3条，这召回基线就有问题，重排只是放大噪声。另外monoT5吃query和passage的交互特征，但前提是候选里得有正确答案，建议先拿那几轮badcase跑一下检索链路，看看是向量距离本身就不近，还是embedding对合同术语的语义理解太弱。至于幻觉，重排权重拉高确实可能让模型更自信地去“脑补”，可以试试在生成阶段加个引用校验，强制答案必须落在检索段落里，不然就拒答。

混合检索大概率得加，你这个问题我在生产环境也撞过，纯向量对口语化查询特别容易跑偏，BM25至少能兜底把关键词命中的段落拉回来。重排权重调太高确实会放大幻觉，因为monoT5本身就是在相关性上做文章，它不关心事实一致性，建议你试试把重排后的结果做个来源校验，跟原文做实体对齐，过滤掉那些找不到出处的细节。另外query改写这块，别全局套用，只对低置信度的查询触发可能更稳，我之前这么改完效果比无脑改写靠谱不少。

先查下你们切分粒度，长文档硬切最容易把A合同条款混进B上下文里。

混合检索得加上，你这情况典型是召回源就偏了，重排再强也救不回根本问题。

混合检索必须上，BM25对口语化query的实体匹配比向量稳太多了，尤其是合同这种专有名词密集的场景。重排调高权重确实容易让模型脑补，建议你给monoT5加一个“仅重排不生成”的硬约束，或者直接把重排分数和向量分数做加权融合，别让单一信号主导。另外query改写别乱用，先试试把口语词映射到知识库里的标准术语，比如“违约金咋算”改成“违约金计算方式”，这种规则比模型改写可控。

混合检索真得赶紧加上，BM25对口语化query的精确匹配往往比向量更稳，能先把Top20的底子垫厚。重排权重不是越高越好，monoT5容易把语义相关但实体错误的段落顶上去，你那个幻觉八成是重排过拟合了长尾表述。建议先拿用户真实query做个小样本，看看是召回源头烂了还是重排把错误信息放大了，再决定动哪块。另外query改写别全局套，只对带数字、合同名等强实体词的口语化问句触发，效果会稳很多。

我们团队之前也遇到过类似情况，上线后召回崩得比你更夸张，后来排查发现是bge对口语化query的泛化能力确实弱，特别是金融合同这种术语密集的场景。你提到重排调高后幻觉变多，这个很典型——monoT5本质上是在做相关性打分，它会把一些语义上沾边但事实错误的段落强行排到前面，生成阶段一看相关性高就信了，根本不管事实一致性。我的建议是别急着微调embedding，那玩意成本高不说，对口语化问题改善有限，不如先上混合检索，BM25负责把关键词命中的段落捞回来，向量负责语义扩展，两条路合并后再进重排，召回质量会稳很多。另外query改写这块，我们试过LLM改写，但发现改写后的query跟原始query的向量距离经常拉得太远，导致检索空间偏移，后来改成只做轻量级同义词替换，效果反而更稳定。至于幻觉，建议在重排之后加一道事实校验，拿生成答案里的实体跟原文段落做比对，比如合同编号、金额这些关键信息，对不上就直接降权或者拒答。你现在的Top20里只有2-3条有用的，这个比例太低了，先检查一下是不是索引切分粒度有问题，我们之前是因为chunk设太大，导致段落里混了好几个合同条款，召回噪声特别高。总之别纠结单点优化，先搭个混合检索+重排+校验的流水线，再逐步调参，上线前多拿真实用户问题做对抗测试，比什么都管用。

混合检索真得赶紧加上，BM25对口语化query的实体匹配比纯向量稳太多了，我这边加了之后召回直接涨了十几个点。重排权重别调太狠，monoT5对长文档容易过拟合，我之前就是重排太猛把B合同内容带上来了，后来限制重排只在前20里挑且加了个相似度阈值才压住。query改写建议先别折腾，生产环境用户问法千奇百怪，改错方向反而带偏，不如先看看是不是embedding该用领域数据微调一下。

我们之前也踩过类似的坑，口语化query直接打崩向量召回是常态，后来把BM25和向量结果做了加权融合，召回率稳定了不少。重排调太狠确实容易让模型脑补，建议给monoT5加个阈值，低于置信度的结果直接不返回，宁缺毋滥。你那个query改写可以试试只用它做扩展词，别替换原query，改动越小越不容易跑偏。

你这情况我太熟了，生产环境跟测试集完全俩世界。我建议先别急着动embedding，你那个“A合同条款安到B合同”的问题，八成是重排权重过高把原本正确的候选给压下去了，monoT5对长文档和口语化query本来就容易过拟合相关性，幻觉反而会放大。混合检索这步真得加，bm25抓关键词，向量抓语义，先拿recall@20稳住，再让重排在融合后的结果上做精排，不然你光调重排就是给漏掉的信息二次加工。另外query改写这块，别用通用模型，拿你们企业语料里的真实问法做few-shot，或者干脆把改写逻辑做成规则+模型双通道，命中“违约金咋算”这种口语就直接拆词，别硬转书面语。最后你排查时候建议按层拆：先看检索召回里到底混入了什么噪音，是实体混淆还是句子粒度不匹配，然后单独测重排前后的hit率变化，别一上来就叠buff。我上次就是先加了混合检索，召回从2-3条拉到7-8条，幻觉明显降了，重排再做轻量微调才稳下来。

混合检索大概率得加上，你这场景纯向量对口语化query太吃亏了，BM25至少能保证关键词命中。重排调太高确实容易让模型脑补，建议把重排得分和向量得分做加权融合，别直接硬顶。另外query改写别全局套用，可以只对低置信度的query触发，或者试试把用户原词和改写结果都拿去检索再合并。最后强烈建议抽一批线上bad case做针对性badcase回归，比盲目调参效率高。

混合检索先安排上吧，BM25兜底口语词，向量管语义，你这情况大概率是召回源就歪了。

混合检索先加上吧，你这情况明显是向量召回天花板太低，BM25能兜底口语化问题。

混合检索先加上吧，BM25兜底口语词比单靠向量稳，重排权重降点试试。

先查下召回阶段是不是真没召回到，重排只是放大噪声，你那个A合同硬安B合同八成是重排把不相关段落顶太高了。

混合检索必须上，BM25兜底专治口语化漏召回，bge那玩意儿对长尾表达太钝了。另外重排别调太狠，monoT5给分高不等于事实正确，你可以在重排后加个去重+来源一致性校验，专杀跨文档幻觉。最后query改写建议只对名词短语做扩展，别让模型自由发挥，否则越改越飘。

混合检索先加上吧，口语化问题BM25能兜底，重排调太高肯定喂幻觉。

我们团队之前也踩过类似的坑，上线前测试集太干净，一上生产就露馅。你这个问题我觉得核心不在重排还是embedding，而是你的检索链路对口语化query太敏感了，bge-large对短查询和长文档的语义匹配本来就不算强，加上企业知识库里的合同条款又高度相似，召回差很正常。monoT5重排虽然能把相关段落顶上来，但它本质上是“在给定候选里找最好的”，如果Top20里就没几个真正相关的，重排只会把错误答案排得更靠前，幻觉自然就多了。我建议你先别急着微调embedding，那个成本高且效果未必可控，不如先上混合检索，BM25负责精确词匹配，向量负责语义扩展，两路结果做加权融合，对口语化输入会稳很多。另外query改写这块，你可以试试不重写整个query，只做关键实体纠错和同义词扩展，比如“违约金”补成“违约金的计算方式”，这样比生成式改写更可控。最后排查的时候，一定要把线上bad case收集起来，按query类型分类看，到底是实体识别问题还是语义偏移问题，再决定动哪一层，别一上来就全链路重构。