RAG里Agent自己改写query后，召回结果反而变差了，是我姿势不对吗？

我之前也踩过类似的坑，后来发现问题往往出在“改写”这一步太自由了。不如先让Agent判断一下问题复杂度，简单问题直接原query召回，只有多跳或指代不清时才触发改写，能省不少事。另外你试试给改写加个约束——让它必须保留原问题里的关键实体词，再去做子查询，匹配度会稳很多。混合检索确实是个方向，但更建议优先调好向量化那层的文本预处理，毕竟口语化问题有时候靠同义词扩展就解决了，不一定要动query。

我之前也踩过类似的坑，后来发现核心问题在于改写query时丢了原始语境的“锚点”。现在我会让Agent先判断问题复杂度，简单问题直接原句检索，多跳问题才触发改写，而且改写时保留原问题里的关键实体词，只补充逻辑关系，这样召回率稳多了。

另外混合检索确实能兜底，但别迷信BM25，我试过在改写失败时自动回退到原始query的向量结果，再按得分融合排序，效果比单纯堆检索方式好。你试试看把改写门槛调高，别让LLM自由发挥。

HyDE我也用过，但对长文档确实噪声太大，不如把改写后的子问题再跟原问题做一次向量拼接，相当于用原问题校准一下语义方向，这招对口语化严重的情况挺管用。

混合检索试试吧，关键词保底加向量召回，改写query真不如原词多路查。

确实遇到过类似的情况，query改写这事儿真不是无脑上就行的。我后来试下来感觉，问题可能出在改写目标和检索目标是两套逻辑——LLM觉得它在做“语义等价转换”，但实际上向量空间里它生成的词很可能跟原文术语分布差很远，尤其口语化输入时更是这样。

我现在的做法是分了两步走，先做个轻量的意图分类，判断是不是真的需要多跳拆解，如果只是简单事实类问题就直接用原query检索，省得引入额外噪声。真要拆的话，我也不让Agent自由发挥，而是给它限定几个改写模板，比如必须保留原文里的关键名词和实体，这样能很大程度减少术语漂移。

另外你说的HyDE慢和噪声问题我也踩过坑，后来改成了“局部HyDE”——只对拆出来的子问题生成假设性答案，而且强制要求假设里带上原文可能出现的术语，而不是泛泛地描述。效果比全量HyDE好不少，但确实还是慢，所以我现在是混合检索兜底，向量召回加BM25交叉验证，改写query和原query都跑一遍，最后用reranker合并排序。

我倒想问问，你那个LangGraph流程里，Agent改写query的时候有没有让LLM参考一下文档目录或标题？我之前试过把文档结构喂进去，感觉改写出来的query会更贴近语料风格，但不太确定这个是不是普适的解法。

试试先做意图分类再决定改不改写，多跳才拆，简单问题直接原句检索，能少很多噪声。

我踩过一模一样的坑，后来发现让LLM改写query时得把原始query也保底召回一次，两路结果用RRF融合，改写翻车了也不至于崩。另外意图分类挺关键的，寒暄类或者简单事实型问题压根不用改写，硬拆反而丢信息。HyDE我基本只在术语密集的垂直领域用，通用场景确实不划算。你可以试试先做query难度判断，只对多跳问题走改写分支，单跳直接原query加BM25混检。

改写前先让LLM抽关键词做混合检索，纯向量对口语化query确实容易崩。

我踩过一样的坑，后来发现让LLM改写query之前先做一步意图分类确实有用，闲聊类直接走原query，只有多跳推理才触发拆解。另外改写时我加了个约束，让它尽量保留原文里的关键实体和术语，别自己发挥，召回率稳了不少。HyDE我基本弃了，延迟顶不住，现在用混合检索兜底，向量加BM25，口语化query的短板能补回来一些。

先别急着改写，试试意图分类判断要不要动query，口语化严重的直接上混合检索兜底更稳。

我踩过一模一样的坑，改写query这事真得看场景，口语化问题直接扔给LLM拆解很容易跑偏，术语全丢了。后来我改成先做意图分类，简单事实类问题就不改写了，多跳的才拆，召回率稳了不少。另外混合检索确实能兜底，BM25对术语匹配比纯向量靠谱，配合RRF融合效果比单独调query强。HyDE我也放弃了，长文档场景延迟高收益还不稳定，不如把预算花在rerank上。

先意图分类再决定改不改写更稳，口语化query直接改写确实容易跑偏。

这个问题我也踩过，改写query确实是把双刃剑。我的经验是别让LLM直接“重写”，而是让它做“术语对齐”——把口语化的表达映射到文档里可能出现的专业词，比如用户说“电脑连不上网”就扩展成“网络连接失败、网卡异常”这类同义表达，而不是改成一个语义偏移的新问题。另外我现在的做法是先拿原始query跑一次召回，再拿改写后的跑一次，两路结果做RRF融合，而不是完全替换，这样多跳问题能捞到，简单问题也不至于被改写带偏。意图分类那步我觉得值得加，但不用太复杂，判断是单跳还是多跳、是事实型还是对比型就够了，分类结果决定走几路召回、要不要拆子问题。混合检索确实是保底方案，BM25对术语匹配的鲁棒性比纯向量好太多，尤其你们文档里专业名词多的话，稀疏检索能兜住改写带来的语义漂移。HyDE我也试过，长文档场景下生成的假设文档太容易跑偏，后来只在短query且召回为空的时候才触发，当兜底而不是主路径。

我也踩过这个坑，改写query看着美好，实际经常把用户的口语“翻译”成另一套词，跟文档里的术语反而更远了。后来我的做法是别一上来就改写，先用意图分类判断是不是多跳问题，简单问题直接原query走混合检索，BM25兜底能救回不少术语对不上的情况。多跳的再拆子问题，但每个子问题都保留原始关键词做拼接，别让LLM自由发挥。HyDE我也放弃了，延迟高还容易飘，不如把预算花在rerank上。

改写不如先意图分类，多跳再拆，单跳别动，混合检索兜底更稳。

先意图分类再决定改不改，口语化query直接改写容易丢关键词，混合检索加BM25兜底更稳。

先意图分类再决定改不改，别让LLM瞎拆；配合混合检索兜底，术语对不上时BM25能救回来。