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

我也踩过这个坑，子查询拆完合并那步确实最容易掉链子。后来我是让LLM先出个查询计划，每个子查询带个依赖标记，检索完按依赖链拼上下文而不是简单去重，效果稳不少。GraphRAG对多跳确实友好，但建图成本高，金融研报实体关系又密，维护起来挺累的。可以先在rerank那层加个cross-encoder试试，成本低，能救回不少漏召的片段。

多跳漏召回这个问题我们踩过差不多的坑，说点实在的。你现在的痛点其实不在检索层，而在“查询规划”和“证据聚合”这两块没打通。把问题拆子查询方向是对的，但别让每个子查询独立去召回然后硬合并，那样去重和排序必然乱。我的做法是让LLM先出一个带依赖关系的查询计划，比如先查营收增速、再查业务构成，第二步的检索query里带上第一步的结果作为上下文，这样召回是链式的而不是并行的。GraphRAG在实体关系密集的场景确实有用，但金融研报里表格和数字多，图构建成本高、更新也麻烦，不一定划算。rerank一定要加，但它是补救不是主菜，放在链式检索每一跳之后做精排，能明显减少噪声。另外建议把召回评估从“命中率”换成“证据覆盖率”，看每跳需要的证据是不是都齐了，不然你永远不知道是哪一步断的。真正实用的组合是：查询计划+链式检索+每跳rerank，GraphRAG当补充手段而不是主力。

多跳漏召回这事我踩过坑，说点实在的。你现在的混合检索加子查询拆分方向没错，但问题往往出在子查询之间的“桥接实体”没接上，比如第一跳查出公司A的营收数据，第二跳要查业务构成时，检索query里如果没带上公司A或者具体年份，向量和BM25都容易飘。我的做法是在每跳检索后加一个小步骤：让LLM从已召回片段里抽一个“中间答案锚点”，再拼进下一跳的query里，比单纯拆子查询管用。至于GraphRAG，金融研报这种实体关系密集的场景确实有优势，但构建和维护成本不低，如果只是问答不是推理链路特别长，先别急着上。rerank我建议加，但别指望它救漏召回，它只能把已经召回的排好，漏了的它找不回来。生成查询计划再执行这个思路可以，但重点是计划里要包含“每跳的验证条件”，否则LLM生成完就一路跑偏。我目前比较稳的组合是：混合检索+中间锚点回填+轻量rerank，GraphRAG当补充索引，不是替代。

多跳漏召回不一定是检索器的问题，很多时候是子查询拆得不对。我们之前也踩过坑，后来改成让LLM先出查询计划，明确每一步要查什么实体、什么指标，再按依赖顺序执行，合并时用实体+时间做key去重，效果比单纯换GraphRAG稳。rerank可以加，但别指望它救回根本没召回的片段。GraphRAG成本高，金融研报这种实体关系密集的场景可以试，但先把查询规划做扎实更划算。

多跳漏召回这事儿我也踩过坑，说点实际感受。你现在的混合检索加子查询拆分方向没错，但问题往往出在子查询是并行跑的，彼此不知道对方捞到了什么，合并时又只按分数排，结果就是关键那跳被稀释掉了。我之前试过让LLM先出一版查询计划，把每跳的依赖关系显式写出来，比如第二跳必须带上第一跳的实体，这样检索时能强制注入上下文，召回率提升挺明显。GraphRAG不是不能上，但抽取实体关系那步在金融研报这种长文本上很容易漏边，维护成本也高，小团队慎入。重排这层肯定要加，但别指望它救召回，它只能把已经召回来的排好，漏了的还是漏。更实用的做法是检索后加个轻量的“缺口检测”，让模型判断当前证据够不够回答，不够就自动补一轮针对性检索，而不是硬答。另外子查询合并可以去重后按覆盖度加权，而不是单纯看相似度分数，这个改动成本低但效果立竿见影。

我之前也遇到过类似问题，后来换了方案。

先让LLM出查询计划再拆子查询，合并时按实体对齐去重，比纯调rerank管用。

先让LLM生成查询计划再执行确实更稳，子查询合并时给每个结果加个来源权重试试。

多跳漏召回太常见了，我去年做尽调问答也踩过一模一样的坑。你现在的瓶颈其实不在检索器本身，而是子查询之间缺一个“证据对齐”的环节，拆完各自召回再合并，模型根本不知道哪条是支撑哪一步的。我的土办法是让LLM先出查询计划，但每个子问题都带上“依赖上一步的哪个实体”，检索时把上一步命中的chunk里的关键实体抽出来拼进下一步query，这样召回率能提不少。GraphRAG我也试过，实体关系建起来成本高，而且金融研报里指标口径变化多，图很容易建歪，不太划算。Rerank只能解决排序，解决不了“压根没召回到”的问题，所以它得放在对齐之后当精排用。真正管用的还是查询计划加中间结果回填，再配一个轻量的去重（按chunk id加实体覆盖度）。另外建议你留个兜底，某一步召回置信度低就让Agent主动反问用户缩小范围，比硬答强。

我之前也踩过这个坑，后来发现子查询合并那步别太依赖向量相似度，用RRF做融合再按实体对齐去重会稳不少。GraphRAG对多跳确实有用，但建图成本高，研报更新频繁的话维护起来挺累的。可以试试让LLM先出个查询计划，每个子问题只负责召回自己那块，最后再统一rerank，这样至少不会漏得太离谱。

我们之前也踩过这个坑，后来发现关键不是换GraphRAG，而是把子查询的合并逻辑做扎实。每个子查询单独召回后，别急着拼一起，先按实体对齐去重，再做一轮cross-encoder重排，最后把top片段按依赖顺序喂给LLM。查询计划那步确实有用，但别让LLM自由发挥，得给它限定好模板，不然生成一堆没用的子问题反而更乱。

先让LLM出查询计划再执行，比事后拆子查询靠谱，合并那步用重排兜底就行。