Agent+RAG做复杂查询时，多跳检索总是漏召回，大家怎么优化的？

我之前做类似的多跳问答也踩过这个坑，后来发现子查询拆完别急着合并，先把每个子查询的结果按相关度截断到top20，然后用一个轻量级rerank模型（比如bge-reranker）统一打分，能压掉不少噪声。另外建议试试让LLM先生成带逻辑顺序的查询计划，把中间结果作为上下文塞回下一步查询，比单纯拆词效果好很多，GraphRAG成本太高，暂时没必要上。还有个土办法是手工维护一个实体同义词表，金融研报里公司简称和股票代码经常对不上，补上后召回率提升挺明显的。

我们团队之前也踩过这个坑，后来发现光靠拆查询不够，关键是子查询结果得带上下文做合并，不然排序肯定乱。建议你试试让LLM先生成带依赖关系的查询计划，然后每个子查询结果单独存，最后再喂给模型做综合判断，比单纯rerank稳定。GraphRAG除非你知识库实体关系特别密集，否则工程成本有点高，可以先缓一缓。另外去重这块可以按文档来源和段落位置做个简单聚类，效果会比纯向量相似度好。

可以先让LLM把问题拆成带依赖关系的子查询，再按顺序检索合并，比直接并行拆效果稳很多。

重排可以留着最后做，但前提是召回够全，不然rerank也救不回来。

说实话你这情况我太熟了，金融研报这种强逻辑链条的场景，光靠向量召回就是会漏，因为子问题之间是隐式关联的，不是单纯语义相似能覆盖的。我的建议是先别急着上GraphRAG，那玩意工程成本高，而且你现有库没做实体链接的话迁移很痛苦。我试过比较管用的路子是让LLM先生成查询计划，但别让它一次生成所有子查询，而是每步只生成一个，检索完把结果喂回去再决定下一步，这样能减少错误累积。至于合并去重，我自己的土办法是保留每个子查询的top5，然后按文档来源的置信度加权，再让LLM根据和主问题的相关性做一次轻量重排，别用那种大模型做rerank，太慢，用个小点的交叉编码器就行。另外你提到的BM25混合没问题，但建议把BM25的权重调高一点，尤其对于数字、年份这种精确匹配项。还有个坑是子查询之间往往有重叠内容，去重时别光看文本相似度，得看文档ID和上下文范围，不然容易把关键的补充段落误删。你现在的失败case有没有统计过是漏在第一步还是后续步骤？如果是最后一步，可能不是检索问题，是LLM在合并信息时把某些字段忽略了，这时候加个结构化输出约束会更有效。

说实话我跟你情况差不多，也是做金融问答的，多跳这块卡了挺久。后来发现光靠拆query真不行，子查询结果合并时权重怎么给都是玄学，我最后是直接让LLM先生成一段“检索计划”，明确每一步要找什么字段、什么时间范围，然后按计划去向量库和BM25里分别捞，再用LLM自己判断哪些片段是同一跳的上下文，拼起来喂回去。重排我也试过，但像bge-reranker那种模型对跨段落的信息整合帮助有限，它只是把相关片段提上来，可多跳问题关键是“片段之间缺了链接”。GraphRAG我也调研过，如果你们知识库实体关系已经建好了，确实能解决一部分漏召回，但前期构建成本很高，金融研报里隐含关系太多，维护起来想死。我目前最实用的组合是：计划生成加粗粒度过滤，比如先按年份和公司名把候选集压到几百条，再做混合检索，最后把召回的段落按时间倒序拼给LLM，让它自己推理出变化和归因。漏召回这事别追求完美，能覆盖80%核心事实就够用了，剩下靠LLM的领域知识兜底。你们子查询合并时试过按“实体共现”做聚类吗？我试了下比单纯去重效果好点。

多跳检索漏召回太真实了，子查询合并这块我也踩过坑。个人感觉别急着上GraphRAG，工程成本高不说，金融研报里实体关系未必建得全。可以先试试让LLM生成查询计划并带上依赖关系，比如让每个子查询输出它需要哪些前置信息，然后用一个简单的状态机去串，比单纯合并向量结果靠谱。重排的话，建议用交叉编码器只对前20-30个候选做精排，能救回来不少。另外注意子查询去重时别只看文本相似度，语义相同但表述不同的情况很常见。

我之前做类似场景也踩过这坑，后来发现光靠拆查询不够，关键是拆完得带上下文去检索，不然子问题之间信息断层。重排确实能救回一点，但更实用的做法是让LLM先生成带依赖关系的查询计划，每个子查询带上父查询的结果摘要再搜。GraphRAG对这种跨实体关联有帮助，但初期成本太高，建议先用普通RAG配合查询改写和重排试，效果不够再上图谱。另外，合并结果时按子查询的依赖顺序做加权，比单纯去重排序靠谱得多。

试过让LLM先出子查询再带上下文逐跳检索，比直接拆好用，合并时按文档来源加权就行。

我们最后是查询计划+每跳独立召回，结果拼一起再让LLM自己挑，漏召回少很多。

先让LLM把子查询结果按实体对齐再合并，比直接拼topK靠谱，重排能救回来一截。

我是做企业搜索的，这种多跳漏召回太典型了，尤其金融数据这种实体关系密集的场景。我建议别急着上GraphRAG，那个工程成本高，而且你现在的关键问题其实是“子查询合并”而不是“检索范围不够”。我们试过让LLM先生成查询计划，但发现它经常把问题拆得太碎，反而引入了噪音，后来改成两步：先让LLM识别出问题里的核心实体和关系类型，然后针对每个关系单独做一次带过滤条件的检索，最后用BM25分值和向量相似度的加权来排序，而不是简单合并去重。

你提到的rerank确实值得加，但别用那种重模型，试试点开源的cross-encoder，比如bge-reranker，能把“相关但顺序不对”的片段重新排准。另外我有个土办法：把子查询的结果按文档ID聚簇，每个簇里取最高分的片段，再让LLM基于这些簇做答案生成，这样能避免一个文档反复出现在不同子查询结果里导致的信息冗余。最后，针对你那个营收增速对比的例子，我建议在检索前先让LLM把时间维度和指标维度拆出来，然后用结构化查询去数据库里拿确切数字，再配合RAG的上下文，这样比纯靠向量召回可靠得多。你试过给子查询加时间范围过滤吗？很多时候漏召回就是因为这个。

说实话你这情况我也踩过坑，子查询拆完合并排序确实是玄学。我的做法是先用LLM生成带依赖关系的查询计划，然后每个子查询结果都带上来源文档的上下文片段，最后按文档重合度聚类再喂给模型，比直接rerank稳。GraphRAG先别急着上，那玩意儿维护成本高，金融研报这种结构化不强的文本，效果未必比你这套好。

先让LLM生成子查询计划，再按业务规则加权合并结果，比单纯rerank稳很多。

我们组之前也踩过这个坑，金融场景尤其明显，因为问题里经常藏着时间、主体、对比关系这些隐含条件。你试过拆子查询但合并不好，我觉得关键不是怎么排序，而是子查询之间要有“证据链”的意识，比如先查出2023年增速，再拿这个结果里的业务名去查2022年，而不是两个查询平级地各自召回。GraphRAG我们后来试了，构建成本真的高，而且对于这种临时性的对比问题，图谱关系反而容易僵化，不如在检索后加一个轻量级的rerank，但别用太重的模型，用那种基于交叉编码器的，能直接对“问题-子文档对”打分，把漏召回的那部分靠相关性排序顶上来。另外你说让LLM生成查询计划，这个我们实践下来是有效的，但别让它自由发挥，要给它一个固定的模板，比如“先定位时间范围，再锁定实体，最后提取比较维度”，这样出来的子查询更可控。合并去重这块，我建议别用简单的向量相似度去重，容易把语义相近但事实不同的内容删掉，可以按文档来源和段落ID做结构化去重，再按rerank分数加权融合。最后一个小技巧，金融研报里很多数据藏在表格里，你这问题八成是表格抽取不全导致的，试试把PDF解析时单独把表格转成文本存索引，召回率会明显提升。

说实话，你这个问题我太有共鸣了，之前做法律条文问答也卡在多跳上，混合检索和子查询都试过，最后发现瓶颈不在召回，而在“怎么把零散证据串成一条逻辑链”。我后来没上GraphRAG，太重了，而是先让LLM生成一个带依赖关系的查询计划，比如先查“2022年营收”再查“2023年增速”，每一步检索结果都带着来源和置信度，最后再让LLM按计划逐步判断哪些证据能连起来，连不上的就明确标注“未找到”，宁可让它说不知道，也别瞎编。关于子查询合并，我试过最实用的办法是不合并，直接按查询顺序把每步的top-k结果塞给LLM，让它自己决定用哪些，但前提是prompt里明确告诉它“你看到的是分步检索结果，不是完整答案，需要自己推理哪些是相关证据”。重排我加了，但只用在最后一步，前面几跳用普通向量检索就行，因为重排模型对跨文档的因果关系帮助不大。另外有个小坑，金融研报里“增速变化”这种词，嵌入模型经常分不清是“增速”还是“变化”，我就在查询计划里强制LLM把数值型指标转成公式描述，比如“2023营收减去2022营收再除以2022营收”，检索准确率会高不少。GraphRAG我也试过demo，但建图成本太高，研报里实体关系太密，反而容易把噪音也召回来，我觉得你不如先试试“查询计划加分段证据输入”这个组合，成本低很多，效果可能立竿见影。

搭过类似的金融问答，你这个痛点太真实了。我的经验是别一上来就上GraphRAG，成本和维护都高，先试试把子查询结果按“证据链”来合并：每个子查询带上它对应的推理步骤，最后用LLM按步骤顺序去验证和拼接，比单纯按相似度去重靠谱很多。另外rerank一定要加，尤其对多跳场景，用那种能理解语义交叉的模型，能把漏掉的强相关片段提上来，比调检索参数见效快。

我们团队之前也踩过这个坑，子查询拆完合并排序确实容易乱。后来试了让LLM先输出带依赖关系的查询计划，按步骤执行并缓存中间结果，比单纯并行拆解召回率高不少。重排我们放在最后一步，主要用cross-encoder过滤掉明显不相关的段落，但别指望它能把漏掉的补回来。GraphRAG除非你的知识库本身实体关系很密集，否则落地成本挺高的，可以先试试在查询计划里加入“验证步骤”，让模型自己检查哪一跳缺了再补查一轮。

我之前做类似场景的时候，发现子查询合并这块其实比检索本身更关键，单纯拼接结果集肯定不行，得按实体或时间维度做归一化，不然重复信息会淹没真正缺的那块。你提到的重排我试过，但对漏召回帮助不大，它只是把已有的结果排得更准。后来我改成让LLM先输出一个结构化的查询计划，比如明确第一步找哪些文档、第二步从这些文档里抽什么字段，然后再分步去检索，召回率反而稳定不少。GraphRAG对关系型问题确实有用，但落地成本高，如果你的知识库实体间关联不是特别复杂，建议先试试在子查询里加上关键词约束，比如财报里的特定术语，可能比换架构来得快。

查询计划先试，拆完子查询直接按业务时间线合并排序，比盲目上GraphRAG靠谱。

先让LLM生成查询计划再逐跳验证，比直接拆子查询靠谱，漏召回还能定位哪跳断了。重排对漏召回帮助有限，别指望它兜底。

先让LLM出结构化查询计划，每步检索完用答案反查补漏，比直接堆rerank省事不少。