Agent+RAG做复杂问答时，怎么让LLM正确选择多个子知识库？

多库路由确实容易翻车，我后来直接并行查所有库再用rerank合并，召回反而稳了。

我之前也踩过这个坑，路由错库本质上是LLM在意图分类时把复合问题当成单意图了。后来在prompt里强制让它先输出子问题列表，每个子问题标注目标库，再按标注并行检索，召回率提升不少。另外向量库加一层部门标签做元数据过滤，比纯靠语义匹配稳很多。你们试过用query改写把复合问句拆成原子问句吗？

这种跨库问题我踩过类似的坑，说实话靠提示词让LLM稳定判断“该查哪几个库”基本是玄学，尤其是问题里同时涉及流程和制度的时候。我们后来是把每个子库的元数据描述做得很细，比如给HR库打上“假期政策、考勤规则、员工福利”这类标签，检索前先用一个轻量分类模型或embedding相似度做库级别的粗筛，而不是让主LLM直接拍脑袋选。另外你提到的并行查所有库再合并，确实更稳，但得配一个rerank或者去重逻辑，不然上下文里全是重复片段反而干扰回答。多跳检索的话，可以试试让Agent显式输出一个检索步骤的JSON，比如先查财务的报销规则，再拿结果去HR库匹配年假条款，这样比纯自然语言提示可控一些。不过说实话，如果库不多，并行召回加融合排序可能比让LLM做路由更省心，代价就是延迟和token会上去。你们现在几个库的规模大概多少，如果就三五个，我倾向于直接全查再筛。

多库路由确实容易翻车，我后来干脆让Agent并行全查再重排，召回反而稳了，就是费token。

多库场景下让LLM自己选库确实容易翻车，我们后来改成先让模型拆子问题、每个子问题带上部门标签再并行检索，效果稳不少。元数据过滤挺关键的，给每个chunk打上部门字段，检索时按意图动态拼filter，比纯靠prompt靠谱。你说的“报销和年假冲突”这种跨域问题，本质是多跳，不如直接并行查所有相关库再让rerank合并，别指望一次路由就选对。

我踩过一样的坑，路由靠意图识别真不太稳，尤其是问题跨部门的时候。后来改成让Agent先并行查所有库，再用rerank合并去重，虽然多花点token但召回稳多了。其实可以给每个chunk带上部门元数据，检索时按问题里提到的实体做过滤，比纯靠prompt靠谱。多跳那块我试过在prompt里塞几个few-shot例子，让它明确输出“先查A再查B”的步骤，效果有提升但也就那样，感觉还是得靠图结构兜底。

我最近也在踩这个坑，感觉靠prompt让LLM稳定选库确实不太现实，尤其是问题里跨了两个部门的时候，模型很容易被第一个命中的关键词带跑。我们后来把路由拆成了两步：先用一个小模型或者规则做“涉及哪些域”的分类，允许多标签输出，再让Agent按域并行去查，最后合并去重后再生成答案。元数据过滤挺有用的，但前提是你的chunk打标要够干净，不然过滤反而把该召回的给筛掉了。混合检索能缓解召回问题，但解决不了“该不该跨库”的判断，所以多跳这块还是得在编排层做文章。我比较好奇你们有没有试过把每个库的摘要和典型问题做成一个轻量索引，先让LLM在这个索引上做路由，而不是直接面对全部向量库？另外并行查所有库再重排，在库不多的时候其实挺香的，就是延迟和成本得权衡一下。