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

生成查询计划真挺管用的，先把子查询结果按实体对齐再合并，漏召回少很多。

重排得加，但得用那种能跨段落推理的模型，不然还是白搭。

我们组之前也踩过这个坑，后来发现光靠拆查询没用，关键是拆完得有个“合并策略”。我们现在是让LLM先生成带依赖关系的子问题树，每层检索完用rerank把高相关片段提出来，再带着上下文去做下一跳，漏召回少了很多。GraphRAG除非你的数据本身关系网很密，否则前期构建成本太高，金融研报这种长文本不一定划算。

我们之前做医疗问答也踩过这坑，子查询合并排序确实是玄学。后来发现最实用的组合是：先让LLM生成带依赖关系的查询计划，每步检索完强制用规则去重（比如按文档ID+段落号），再拿结果拼一个临时上下文窗口单独喂给模型做二次推理。GraphRAG除非你知识库本身实体关系很明确，否则维护成本太高，不如先试试在重排模型里加一个“与上一步答案的相关性”特征，比单纯用向量相似度准很多。

我们之前做类似的多跳检索也踩过这坑，混合检索解决不了子查询间的依赖问题。可以试试让LLM先生成带步骤的查询计划，每步独立检索后再用LLM做一次合并过滤，比直接拆query更稳。另外rerank建议加上，尤其用bge-reranker-large这类模型，对跨段落的信息整合帮助很大。GraphRAG除非数据本身关系密集，否则初期成本太高，不如先把查询计划和重排这层做扎实。

我们组之前也踩过这个坑，子查询合并去重确实容易烂尾。后来改成让LLM先输出一个结构化的查询计划，把每步需要的字段和条件列清楚，再逐条去检索，最后按时间线或者业务逻辑做一次规则排序，比直接rerank稳。GraphRAG我们试过，维护成本太高，除非知识库本身实体关系特别密集，不然前期建模就够喝一壶的。另外可以试试在检索前把问题里的数字和实体单独抽出来做个硬匹配，往往能补上向量检索漏掉的精确信息。

之前做类似场景的时候也踩过这个坑，多跳漏召回很多时候不是检索器的问题，而是子查询分割得太机械了。比如你拆成“2023年营收增速”和“2022年营收增速”，分别查完再合并，顺序和权重完全没体现业务逻辑，这时候加rerank其实救不回来，因为候选集里压根没把“哪个业务影响最大”这个维度拉进来。

我的做法是让LLM先生成一个结构化的查询计划，每个节点明确要检索什么实体、什么时间范围、什么指标，然后每个子查询单独跑，但结果不是简单拼接，而是用一个临时图结构去关联。比如把公司、年份、业务线、财务指标都作为节点，子查询命中的段落挂到对应节点上，最后从问题要求的那个“差值”出发，反向找路径上的证据，这样合并去重自然多了。

GraphRAG本质上也是干这个事，但如果你们知识库schema没建好，引入图反而增加维护成本。更轻量的方案是，在拆子查询时让LLM同时输出每个子查询的“依赖关系”，比如必须先拿到2022年的绝对值才能算增速，用这个依赖关系决定合并顺序，再按时间或实体做去重，最后把多个候选段落按相关性分数和路径覆盖度做个简单加权排序。实测比直接rerank召回率提升不少，而且调起来比GraphRAG快多了。

另外注意一个细节，金融研报里很多数据是环比或同比表述，子查询里得把“变化了多少”显式转成“计算2023年增速与2022年增速的差值”，否则LLM生成的子查询可能还是模糊的。试过让LLM先输出一个“检索意图JSON”再执行吗？有时候比直接生成子查询更可控。

我们之前做类似场景也踩过这个坑，后来发现问题不一定在检索，而是子查询合并时排序太粗暴。后来改成按子查询的置信度加权，再对召回结果做去重时保留各跳独有信息，漏召回明显少了。GraphRAG我们试过，维护成本高，效果不稳定，不如先让LLM生成查询计划，再手动定义合并规则，工程上更可控。重排其实对漏召回帮助有限，它只是优化排序，不解决缺失。你子查询之间有没有试过按时间或逻辑顺序做级联过滤？感觉金融数据里时间维度很关键。

查询计划真的有用，先让LLM拆解成带依赖关系的子查询，再按顺序执行合并，比一次性拆了再拼强太多。

我们团队之前也踩过类似的坑，金融场景尤其明显，因为问题里经常藏着时间维度和业务线交叉的隐式条件。你提到的子查询合并排序问题，我们后来是让LLM先输出一个结构化的“查询DAG”（每个节点带检索意图和依赖关系），然后按节点顺序去向量库和BM25分别捞，最后用互信息或者简单的分数加权合并，但最关键的是在合并前先做一遍基于时间戳和实体名的硬过滤，这样能砍掉不少噪音。至于GraphRAG，我们试过但成本偏高，对动态更新的研报数据维护太麻烦，不如在检索后加一层lightweight的cross-encoder重排，只对前20个候选做，效果提升非常明显，尤其能解决“召回了但排后面被截断”的问题。另外有个土办法挺实用，就是为每个子查询生成一个“伪文档”摘要，用摘要之间以及摘要和原问题之间的语义相似度来做merge，比单纯拼embedding靠谱。你有没有试过让LLM在生成查询计划时同时输出每个子查询的“预期证据类型”，比如是数字对比还是事件描述，这样能帮你设计不同的召回策略，而不是全走向量检索。

我们组之前也踩过这坑，后来发现子查询合并的权重比查询本身更重要。你可以试试让LLM先产出带依赖关系的子问题树，然后按叶子节点检索，最后用图结构把结果聚合成上下文块，比单纯rerank稳。另外金融研报其实很适合用GraphRAG，实体关系建好后多跳能少漏不少，但前期构建成本你得掂量下。

这问题太真实了，金融研报这种场景里多跳查询漏召回基本是常态。我之前做类似东西时发现，子查询拆解后合并排序确实是坑，光靠向量相似度加权容易把关键证据挤掉。建议先别急着上GraphRAG，那个对知识图谱质量要求太高，金融文本里实体关系又杂又乱，维护成本会爆炸。我后来用的办法是让LLM先生成子查询，再给每个子查询加一个“证据链标签”，比如时间范围、实体归属，检索回来后用规则做两轮粗排：先按子查询对应性过滤掉明显无关的，再用交叉编码器做局部重排，只对top20做精排，这样比直接全局rerank便宜很多。另外你提到缺一块，很可能是召回阈值设太死，多跳场景下每个子查询的topK应该动态调整，比如依赖上一步结果的查询就给更大K值。还有个土办法，把研报里的表格和摘要单独建索引，很多漏召回其实是数字藏在表格里，文本检索根本碰不到。最后，查询计划可以试，但别让它一次生成完，最好是边查边改计划，LLM根据中途结果修正下一步查询，不过这样延迟会高，得看你的场景能不能忍。

这个问题我太有同感了，金融研报这种密集数字和因果链的场景，单靠向量+BM25确实容易漏，因为子查询之间是逻辑递进关系，不是单纯的关键词叠加。我建议先别急着上GraphRAG，那玩意儿维护成本高，你现在的痛点其实在“中间结果的组织”上。比较实用的做法是让LLM先生成一个结构化的查询计划，比如用JSON输出“第一步查2023年营收，第二步查2022年营收，第三步找差异对应的业务线”，然后按步骤独立检索，每步结果都带着步骤ID和来源段落回传。合并的时候别简单拼接，按步骤顺序做一次“上下文压缩”，把前一步的答案作为后一步检索的query扩展词，比如第二步检索时把“增速变化”换成“营收增速下降/上升+具体数字”。重排肯定要加，但别用在最后一遍，而是用在每一步检索后，用个轻量级cross-encoder把该步骤的top20压到top5，这样能滤掉大量行业通用废话。至于去重，我建议用“文档指纹+语义阈值”双重判断，同一步内不同证据段落如果相似度超0.85就只保留带具体数值的那条。最后排序时，把步骤顺序作为硬约束，步骤1的答案永远在步骤2前面，这样LLM生成时不用自己猜逻辑。我这边踩过最大的坑是让LLM自由发挥子查询，结果它拆出五个并列问题，反而丢了因果，所以查询计划一定要限定“每步只回答一个可验证的事实”，别让它发散。

我之前做企业知识库也踩过这个坑，后来发现问题还真不一定全在检索。你说子查询合并去重排序没搞明白，我试过最简单粗暴的办法是让LLM先输出一个中间答案草稿，再拿这个草稿去做二次检索，相当于把多跳变成两轮单跳，召回率反而稳了。GraphRAG我试过，构建成本高不说，对非结构化研报这种文本，实体关系抽得不准，后面全白搭。重排的话，我建议你优先试，尤其是那种基于交叉编码器的rerank，能把向量排序里被埋没的片段捞回来，比纯靠混合检索阈值靠谱。另外你拆子查询的时候，别让LLM自由发挥，给它限定一个输出格式，比如每个子查询必须带一个“需要补充的实体或时间范围”字段，这样合并时能有个对齐的锚点。还有个小技巧，子查询结果别急着拼，先按文档ID做并集，再用LLM对每个文档的相关性打分，而不是直接拼接文本片段，这样能减少跨段落的语义断裂。反正别指望一套流程吃遍所有问题，多跳场景里“检索后处理”和“查询前规划”得一起调，我觉得对你这个金融场景，可能再加一层时间戳过滤会更有用。

说实话，我之前做医疗问答也撞过这堵墙，子查询合并那步真的容易翻车。你现在试试让LLM先生成带依赖关系的查询计划，然后按顺序执行并把中间结果作为上下文喂给下一跳，比单纯并行拆解召回率高不少。重排建议加，但别指望它补全缺失证据，更靠谱的是把召回阈值调低，让每跳多留点候选，最后再用LLM做一次全局相关性过滤。

查询计划真的有用，我之前也是漏召回，后来让LLM先拆解再逐跳验证，比单纯rerank靠谱。

我之前做类似的事，卡点跟你一样在子查询合并上。后来干脆让LLM先生成带依赖关系的查询DAG，每个节点单独检索，再按依赖顺序把结果喂给下一轮，比一次性拆成平铺子查询准不少。重排我试过，对漏召回帮助不大，它只能调顺序，救不了没召回的段落。GraphRAG这场景除非你数据本身关系网很密，不然建图成本太高，先别急着上。还有个笨办法但有效：把召回阈值调低，多捞几百条再让LLM做一次粗粒度过滤，至少能兜住底。

这问题太真实了，金融研报这种带数值比较的多跳查询，纯靠向量召回确实容易崩。我之前试过让LLM先生成查询计划，把时间范围和实体关系拆清楚，再并行检索，最后用rerank按逻辑相关性过滤，效果比直接合并子查询好不少。GraphRAG听起来理想，但建图谱的维护成本在动态研报场景里可能得不偿失，除非你们数据量真的大到必须用。另外可以试试把每跳检索结果单独喂给LLM做中间判断，让模型自己决定下一步查什么，虽然慢一点但召回全了。

有个比较土但有效的做法：把历史常见多跳问题的正确解析逻辑沉淀成模板，比如“营收增速对比”自动触发对财报附注和分业务板块的强制检索，不用完全依赖模型自由发挥。子查询合并时别光靠向量相似度，按时间戳和实体共现做加权去重，排序时把带具体数字的证据排前面。重排层建议加上，但别用太重的模型，轻量交叉编码器足够，重点是把“数字是否匹配”作为硬过滤条件，能砍掉不少幻觉。

我之前做法律条文检索也遇到过类似漏召回，后来发现关键是中间步骤的“证据链”没闭环。你们的子查询拆完，有没有试过让LLM输出每个子查询的预期答案类型？比如“增速

我们之前做类似场景时发现，子查询拆完最怕的是结果合并时重复内容互相干扰，后来干脆把每个子查询结果都保留独立段落，让LLM按子问题顺序去读，最后再汇总，效果比直接混在一起好不少。至于rerank，加一层确实有提升，但用轻量模型就行，别一上来就上重模型，成本扛不住。GraphRAG这种先别急着换，金融研报里实体关系其实挺复杂的，建图本身就要花不少功夫，我建议你先试试把需要对比的历史数据（比如两年增速）直接做成结构化字段，让Agent先查数再去推理，很多“多跳”其实是被文本表述绕晕的。

先让LLM出查询计划真挺管用的，比闷头拆子查询强，但记得给每步加个校验环节。

先让LLM生成子查询计划，再对结果做rerank合并，比直接GraphRAG省事多了。

query拆解后别急着合并，按实体和字段维度分组召回，去重排序能稳不少。