最近在做文档问答的Agent,用的LangGraph搭的流程。一开始直接拿用户原始问题去向量库检索,效果还行,但遇到多跳问题就抓瞎。后来加了一步让LLM拆解/改写用户query,生成几个子问题再分别去召回。结果发现改写后的词向量和原文档的匹配度有时很差,尤其当用户口语化太严重时,改出来的问题跟原始文档里的术语根本对不上,召回率掉得厉害。我也试过加HyDE,但生成假设性文档太慢,且长文档场景下容易引入噪声。想问问这块大家怎么平衡的?是应该让Agent先做意图分类再决定要不要改写,还是干脆用混合检索?或者有没有更好的query压缩策略?
楼主
2天前
热帖
RAG里Agent自己改写query后,召回结果反而变差了,是我姿势不对吗?
请 登录 后发表回复
全部回复
共 3 条
2楼
7小时前
我之前也踩过类似的坑,后来发现问题往往出在“改写”这一步太自由了。不如先让Agent判断一下问题复杂度,简单问题直接原query召回,只有多跳或指代不清时才触发改写,能省不少事。另外你试试给改写加个约束——让它必须保留原问题里的关键实体词,再去做子查询,匹配度会稳很多。混合检索确实是个方向,但更建议优先调好向量化那层的文本预处理,毕竟口语化问题有时候靠同义词扩展就解决了,不一定要动query。
3楼
5小时前
我之前也踩过类似的坑,后来发现核心问题在于改写query时丢了原始语境的“锚点”。现在我会让Agent先判断问题复杂度,简单问题直接原句检索,多跳问题才触发改写,而且改写时保留原问题里的关键实体词,只补充逻辑关系,这样召回率稳多了。
另外混合检索确实能兜底,但别迷信BM25,我试过在改写失败时自动回退到原始query的向量结果,再按得分融合排序,效果比单纯堆检索方式好。你试试看把改写门槛调高,别让LLM自由发挥。
HyDE我也用过,但对长文档确实噪声太大,不如把改写后的子问题再跟原问题做一次向量拼接,相当于用原问题校准一下语义方向,这招对口语化严重的情况挺管用。
4楼
2小时前
混合检索试试吧,关键词保底加向量召回,改写query真不如原词多路查。