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

这问题我太有同感了，之前做类似项目时也被跨库漏检坑过。你试过让LLM先列计划再执行，但我觉得核心瓶颈在于它根本不知道某个库“有没有答案”，所以光靠意图识别去路由天然就存在盲区。我后来是改成两层结构：第一层用轻量级embedding对所有库做粗召回，把每个库的top3结果都拿回来，第二层再让LLM基于这些片段做交叉判断和答案生成，效果比强行路由稳很多。关于多跳意图，与其在prompt里反复强调“可能涉及多个库”，不如在系统消息里直接给几个典型的多跳问题样例，让模型模仿那个推理路径。另外，元数据过滤确实能帮上忙，比如把部门标签、日期范围、文档类型提前过滤掉不相关的库，减少误判概率，但前提是你要对问题里的实体有比较准的抽取。还有个偏门但有用的技巧——给每个库写一段“能力描述”，包括常见问题类型和边界，让LLM在路由前先读一遍这些描述，相当于给它一份“地图”，比裸库名信息量大得多。你现在的LangGraph是每个库单独一个检索节点吗？如果改成并行调用所有库，然后用一个reranker统一排序，可能比指望LLM精确选择更省心。

并行查所有库再合并其实是个可行的兜底方案，代价就是慢一点，但至少不会漏。我建议你在路由前加一层“关键词+语义”的双重预筛，比如把“报销”和“年假”拆成两个独立query分别去对应库检索，最后用LLM做答案融合，比让它一次选库靠谱多了。另外prompt里别只写“考虑多部门”，可以明确给它几个示例，比如“如果问题涉及两个不同部门的术语，必须分别检索”，这样比抽象指令要稳定。

并行全查再合并虽然费点token，但能避免选错库，交叉验证下比硬靠路由靠谱多了。

干脆先并行全查再合并吧，多跳问题走路由就是容易翻车，费点token总比答错强。

做过类似的坑，说下我的感觉：你那个“报销和年假冲突”的例子其实暴露了路由的底层问题——意图识别本身就不是非黑即白的分类任务，而是多标签的。与其让LLM硬选一个库，不如把路由改成“召回打分”模式，比如先用轻量级embedding把query向量化，同时去几个库里各topK捞一遍，再让LLM基于捞回来的片段做综合判断，这样就算它选错库，答案素材也在手里。元数据过滤确实能帮上忙，但最好把部门标签做成动态的，比如根据query里的实体（“报销”+“年假”）自动映射到多标签，而不是让LLM自由发挥。另外并行查所有库再合并，成本高但效果稳，适合库少的情况，你可以先跑个基线，看看漏召回率到底有多高再决定。Prompt方面，别指望它自己列计划，试试给几个强结构化的few-shot样例，明确写出“需要同时涉及哪些部门的哪些信息”这种提示，比抽象说“多跳检索”有用得多。还有个细节：把每个库的摘要（比如“财务库含报销规则和预算”）塞进system prompt，让LLM做路由前先读一遍，能明显减少低级错误。最后，如果LangGraph里能记录失败case，定期拿这些样本微调路由模型，比纯靠prompt硬撑靠谱多了。

这问题我太有同感了，之前做多域客服机器人也踩过这坑。你那个“报销和年假冲突”的例子特别典型，本质是LLM在做意图识别时只抓了表面关键词，没理解问题里的隐含关联。我试下来最有效的不是让LLM自己选库，而是加一层显式的实体-关系抽取，先把问题里的“报销流程”和“年假规则”拆成两个独立查询条件，再分别路由，这样比直接问“该查哪个库”稳定得多。另外你说的并行查所有库再合并，我觉得在小知识库场景下其实成本不高，尤其是LangGraph里用map-reduce模式，让每个子库先返回top5片段，再做重排序，比猜路由准多了。Prompt方面别光写“你要多跳检索”，得给正反例，比如明确告诉它“如果问题同时涉及两个部门的政策，必须分别查询”，甚至可以把容易混淆的边界场景写进few-shot里。还有个小技巧，给每个知识库维护一份带关键词和别名索引的元数据，检索前先用轻量模型做一次关键词匹配，把置信度低的库也拉进来，能有效防止漏检。最后想说的是，纯靠提示词确实不牢靠，建议在Agent后面加个“回答完整性校验”步骤，比如让LLM回答前先自问“我有没有用到所有相关部门的资料”，能救回来不少漏掉的case。

并行查所有库再合并其实最稳，反正成本可控，别让LLM做单选题。

并行查所有库再合并真没那么可怕，成本可控的话可以试试，至少能兜底。另外你那个“报销和年假”的例子，本质是单轮里隐含了两个独立实体，不如让Agent先抽取出“报销流程”和“年假规则”两个查询词，分别路由再聚合，比让它自己判断“该查哪个库”稳得多。Prompt里别只写“考虑多跳”，给个类似“如果问题涉及多个部门名词，必须生成等量检索任务”的硬规则，会好使点。

你这个问题我太有共鸣了，之前做类似的多部门知识库也踩过这坑。核心矛盾其实不在Prompt，在于你让LLM做“单选题”本身就反直觉——它没法预知每个库的边界，更别说“报销和年假”这种天然跨域的case。我试过最稳的土办法是，把路由改成两级：先用一个轻量分类器（比如微调的小模型或者简单的关键词+向量召回打分）筛出候选库，再让LLM只做“排序”而不是“选择”，准确率能上来不少。关于并行查所有库，成本没那么吓人，尤其企业场景下库数量有限，其实可以无脑全查，最后用Reranker按相关性合并，反而省了纠结路由的功夫。至于让LLM列计划，我建议别让它“想”要做什么，而是给它一个固定的JSON模板，强制它填“涉及部门”和“查询条件”，结构化约束比自然语言提示词可靠得多。最后，元数据过滤一定要做，比如把文档里的政策生效日期、部门标签都存进filter字段，这样即便LLM选错主库，精确的filter也能把错误结果压下去。说到底，这种场景别追求一步到位，先用“全查+重排”保底，再慢慢优化路由策略，比死磕Prompt划算。

这个问题我们之前也踩过坑，后来是把路由从“选一个库”改成了“相关性打分”，让LLM对每个库输出0-1分，再设个阈值决定查几个，这样多跳问题就不会漏了。另外你那个报销和年假的例子，本质是隐式逻辑关联，光靠提示词确实难，建议在query阶段做个实体抽取，把“年假”“报销”拆出来分别去对应库检索，最后用LLM做答案融合。并行查所有库成本高但稳定性最好，可以先拿小流量对比下效果。

先并行查所有库合并结果最稳，成本高但比选错强，元数据过滤只能辅助别依赖。

试试让LLM输出JSON格式的检索需求，强制列出涉及部门，再用路由规则校验兜底。

我试过类似场景，并行查所有库再合并结果确实比硬路由稳，但得在prompt里让LLM先按置信度列出所有可能相关的库，不然它会偷懒只查一个。元数据过滤可以加，但更关键的是在向量检索前先用关键词或分类器粗筛一遍问题里的实体，比如“报销”和“年假”同时出现就直接标记双库。另外多跳意图别靠提示词硬撑，可以在LangGraph里加个显式的“缺失信息检测”节点，如果第一轮结果里某个实体没覆盖到就强制触发第二轮查询。你现在的路由是基于意图标签还是直接让LLM输出库名？后者经常被上下文带偏。

并行查所有库再合并其实挺稳的，成本高点但能避免漏检，多跳问题可以先让LLM拆解子问题再分别路由。

同款问题我踩过坑，核心是别把路由当分类任务，而是当检索任务。你那个报销和年假的例子，本质是问题里的实体就跨了库，光靠意图识别肯定漏。我后来是把每个子库的摘要、关键词、典型问题样例都做成一个“路由索引”，让LLM先在这个小索引里匹配，而不是直接生成库名，准确率会稳很多。另外你说的并行查所有库再合并，其实成本没那么可怕，现在很多场景下甚至是最优解，尤其库里数据量不大时，召回率提升明显，代价就是得写个简单的重排逻辑，别让无关结果污染答案。Prompt方面，别让LLM“列计划”，让它“列出问题中可能涉及的所有部门或主题词”，再对应到库，这样比让LLM自己推流程靠谱。还有个偏方，把每个库的元数据（比如HR库的字段带“假期、考勤”，财务库带“报销、预算”）直接拼进检索结果里，让LLM最后再判断一次要不要补充查别的库，相当于后置校验。总之别指望单点解决，路由+并行检索+后置校验三层兜底，比纯调Prompt实用多了。

并行查所有库再让LLM合并确实更稳，元数据过滤救不了跨部门问题。

多库路由确实容易翻车，我后来直接让Agent并行查所有库再重排，反而稳多了，元数据过滤也加上。

我们之前也踩过这个坑，后来干脆把路由从LLM里拆出来，先用query分类模型判断涉及哪几个域，再并发检索合并。报销和年假这种跨域问题，硬让LLM一步选库确实容易漏。另外可以在每个chunk里塞部门元数据，检索时按意图做过滤而不是只靠向量相似度。多跳的话建议上query rewrite，先把复合问题拆成子问题再分头查，比在prompt里反复强调管用。

并行查所有库再让LLM合并更稳，别指望它自己选对，元数据过滤加交叉验证也管用。

多库路由确实容易翻车，我们后来直接并行查所有库再用rerank合并，比让LLM猜靠谱多了。

我也遇到过，后来直接并行查所有库再让模型合并，准确率反而高了，选库那步太容易翻车。