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

并行查所有库其实是最稳的兜底方案，成本可控的话直接上，反正多跳问题里漏查比多查致命多了。另外可以试试在路由前加一层“部门实体识别”，把报销、年假这种词硬映射到对应库，比纯靠LLM意图判断靠谱。Prompt里别光写“考虑多库”，给几个具体交叉场景的例子，few-shot比抽象指令管用。

并行查所有库这个思路其实挺实用的，成本高点但能避免漏召回，我司之前也是先全查再用LLM做rerank，准确率上来不少。另外你可以在每个知识库的chunk里强加部门标签，检索时用元数据硬过滤，比让LLM选库更可控。Prompt里可以试试把“多跳”拆成显式的子问题模板，比如“先判断涉及哪些部门，再分别用部门名作为查询条件”，但别指望纯靠提示词稳定，最好在Agent流程里加个“验证步骤”，让LLM检查当前答案是否覆盖所有相关实体。

先并行查所有库再合并，成本高但能兜底，比选错库强多了。

碰到这个问题太真实了，我们之前做类似的多域问答也踩过这坑。与其让LLM硬做路由，不如把“选库”变成“过滤”思路：给每个文档块打上部门元数据，检索时先并行查所有库，再用一个轻量级rerank模型按相关性把结果统一排序，最后由LLM基于排序后的上下文生成答案，这样就算意图识别偏了，至少不会彻底漏掉某个域。关于多跳意图，我觉得光靠提示词确实虚，可以试试在Prompt里显式要求“列出所有可能涉及的部门，再针对每个部门生成独立query”，同时给几个带冲突场景的few-shot示例，让它模仿你的拆解逻辑。另外LangGraph里可以加个验证节点，让LLM先自检“这个问题是否跨部门”，如果是就强制触发全库检索，这样比完全依赖第一步路由更稳。混合检索也建议加上，比如BM25和向量检索的分数融合，因为财务和HR的术语重叠度高，纯语义容易混淆，关键词能兜底。最后一点，如果数据量不大，干脆把几个库的索引合并成一个，用文档的source字段做过滤，反而省心。

并行查所有库其实是个保底方案，成本高点但至少不会漏，我这边试过用多路召回再让LLM做rerank，比硬路由稳很多。另外你可以在每个知识库的chunk里塞上部门元数据，查完后按元数据过滤一遍，能减少不少误召。Prompt的话别让它“列计划”，改成让它先输出“问题涉及哪些实体和部门”，再基于这个做检索，效果会好一点。还有个小技巧，把历史问答对做成few-shot，专门放几个跨库的例子，比纯描述管用。

我最近也踩过这个坑，并行查所有库再合并其实挺稳的，就是成本高点，但至少不会漏。你可以试试在路由前先让LLM输出一个“涉及部门列表”的JSON，再用这个列表去触发对应库的检索，比直接让它选一个库要准。另外多跳意图别光靠提示词，可以在每个知识库的description里加一些交叉场景的例子，比如财务库描述里就写“也涉及年假抵扣问题”，这样路由时的语义匹配会好很多。

并行查所有库再合并其实挺实用的，成本高点但能防止漏检，尤其你这种跨部门问题。另外可以试试在召回阶段先用一个轻量级分类器或者embedding相似度把候选库缩小到两三个，再让LLM做精细路由，比纯靠提示词稳定。Prompt里可以明确告诉它“如果问题涉及多个主体或流程，必须列出所有相关库”，甚至给几个反例。你那个“先列计划再执行”的链路，有没有记录过失败case？我怀疑是LLM计划写了但执行时没严格按计划走。

说实话你这个场景我太熟了，之前做客服系统也踩过同样的坑。并行查所有库再合并其实挺有效的，尤其是当query本身模糊的时候，成本高一点但至少不会漏，然后你可以加个rerank环节，根据相关性打分把不相关的库结果压下去，这样LLM最后生成时看到的就是混合但有序的上下文。另外关于多跳意图，我觉得别光靠prompt硬掰，可以在路由前加一步query分解，比如让LLM把“报销流程和年假冲突”拆成两个独立子问题，分别打上财务和HR标签，再各自检索后合并，这样比直接让它选库稳定得多。元数据过滤也值得试，但不是过滤库，而是过滤chunk，比如给每个向量库的chunk打上部门属性，检索时带条件，这样即使路由错了，结果里也可能命中正确信息。还有个细节，你可以在LangGraph里加个反馈回路，让LLM先看到初步检索结果，如果发现关键实体缺失就自动触发第二轮补查，比一次性决策靠谱。Prompt里可以给几个带歧义的few-shot例子，明确展示“先拆解再查”的思维链，比单纯命令它“多跳”有用。最后建议你跑个评估集，把常见跨部门问题整理出来，每次改完逻辑都能回归测试，不然全靠感觉调真的会崩溃。

试试让Agent先把问题拆成多个子查询再分别路由，比直接选库稳得多，成本和延迟也可控。

并行查所有库再合并其实是个可行的兜底方案，成本高一点但能避免漏检，关键是要在合并时让LLM按相关性打分排序，而不是简单拼一起。元数据过滤可以配合用，比如问句里出现“报销”就优先财务库，但“年假”这类词容易触发多库，所以还得加个规则判断是否涉及跨部门。Prompt里别光写“考虑多跳”，直接给例子，比如“报销流程和年假冲突”这种具体问法，让LLM模仿拆解步骤，比抽象指令稳得多。

碰到这种跨库的复合问题，建议别让LLM做路由决策，直接改成“先并行查所有库、再统一rerank”的架构，虽然成本高一点但稳定性提升明显。另外可以在每个知识库的chunk里埋部门标签和业务关键词，检索时用元数据过滤+混合检索双通道，最后让LLM基于所有结果做综合判断。Prompt里别让它“计划”，直接给场景化例子，比如“报销和年假同时出现时，必须查财务和HR两个库”，few-shot比抽象指令管用得多。

这问题太典型了，我们之前也踩过这个坑。你可以试试让Agent先做一次全局的“查询分解”，把“报销流程”和“年假冲突”拆成两个子查询，再分别路由到对应库，最后用map-reduce合并，比硬让LLM选库稳得多。另外别太信Prompt，可以在路由前加个轻量级分类模型做兜底，或者干脆并行查所有库再让LLM挑相关片段，成本高点但正确率上去了。

我之前也踩过这个坑，后来是把意图识别拆成两步：先让LLM判断问题涉及哪些部门，再根据结果并行查库，最后汇总时加个“互相矛盾”的校验，比直接路由稳很多。另外可以试试在向量库里存部门元数据，检索时强制过滤候选集，能减少误选概率。Prompt里别光写“多跳”，给个具体例子比如“查报销规则时也要确认年假政策是否相关”，模型会更听话。你现在的LangGraph里，路由节点有没有加置信度回退机制？比如低于阈值就全查。

多库路由这事儿我踩过类似的坑，光靠提示词让LLM做“计划再执行”确实容易翻车，因为它对每个库的边界理解是模糊的。我后来改成两步走：先让LLM基于问题生成一个“需要哪些部门知识”的标签列表，再用这些标签去匹配库的元数据，而不是直接让它选库。比如“报销和年假冲突”这种问题，标签会同时命中“财务”和“HR”，路由精度一下就上来了。你提到的并行查所有库再合并其实也是个保底方案，但要注意结果冲突时的裁决逻辑，不然合并出来的答案可能自相矛盾。还有个土办法，就是在每个库的描述里加一些强相关的示例问题，让LLM在做路由时能“对号入座”，比干巴巴的“本库包含报销政策”有效得多。至于多跳检索的Prompt，我试过在系统提示里加入“如果问题涉及多个实体或流程，必须拆分搜索关键词并分别查询”这种硬性约束，虽然不完美，但至少比“请思考”这种软性引导强。另外可以考虑在LangGraph里加一个“二次确认”节点，当LLM只选了一个库但问题里出现“和”“与”“冲突”等连接词时，强制它再跑一次路由，代价是延迟，但稳定性提升明显。最终我自己的项目是混合方案：低置信度问题走并行全库检索，高置信度才走单库，效果比纯路由好很多。

并行全查再合并其实挺实用的，特别是你这种跨库意图明显的场景，反正向量库检索成本不算高，先拿top结果回来让LLM统一判断反而能避免漏检。另外可以试试在路由前加一层“问题重写”，把“报销和年假”这种复合实体拆成两个独立子查询，再分别路由，命中率会稳很多。Prompt里别光说“多跳”，直接给几个正反例，比如“漏掉HR库会导致回答不完整”，模型会更敏感。

我觉得并行查所有库其实是个保底方案，尤其你这种跨部门问题，先都捞一遍再用LLM做rerank，比让它一开始就选对库靠谱得多。另外可以在每个知识库的chunk里强塞部门元数据，检索时用混合检索（向量+关键词）做个粗筛，最后让LLM根据命中的片段内容自己判断哪些相关，别依赖它规划路由。Prompt里别写“多跳”这种抽象词，直接给几个你业务里的具体例子，比如“报销和年假同时问”就让它输出“财务库+HR库”，few-shot比规则描述管用。

并行查所有库这个思路其实挺实用的，成本高一点但能避免漏检，回头用rerank把最相关的几个chunk挑出来就行。另外你可以在每个知识库的向量里加上部门标签做元数据过滤，同时让LLM先输出一个结构化查询条件（比如部门+关键词），这样路由准确率会稳很多。至于多跳意图，建议别只靠prompt，可以在Agent里加一步显式的“子问题分解”节点，把“报销和年假冲突”拆成两个独立问题分别检索，最后再让LLM汇总，比让它自己规划可靠。

并行查所有库再合并其实是最稳的兜底方案，成本高但能防漏。你那个跨部门问题，本质是意图边界模糊，不如在路由前加一层关键实体抽取，比如识别出“报销”和“年假”两个实体再去触发多库查询，比单纯靠LLM自觉靠谱。Prompt里可以明确写“如果问题涉及多个部门概念，必须列出所有相关库名并逐一检索”，但别指望提示词能根治，架构上做兜底才是正经。

这问题我太有同感了，之前做类似的多域助手也踩过这个坑。我的经验是别太指望LLM靠“意图”选库，它本质上是概率匹配，对跨部门概念的组合特别容易短路。你试过的“先列计划再执行”其实方向对，但问题是计划和执行如果分离，Prompt里没把“每个检索动作必须标注关联的知识库标签”这个约束写死，它就容易省略。我现在更倾向于把路由从“二选一”改成“打分制”，让模型对每个库输出一个0到1的相关度分数，然后设定一个阈值，超过0.3的库就都查，最后用rerank合并去重。这样比让它硬选一个准得多。另外元数据过滤一定要用，比如在文档chunk里预埋“部门”和“主题”标签，检索时先按时间或关键词粗筛一遍，再让LLM在候选集里做精排，这比让LLM直接面对整个库要稳。至于Prompt，别写“如果涉及多个部门就查多个库”这种模糊话，改成“请先拆解问题中的实体和动作，对每个实体列出它可能归属的所有部门标签”，强制结构化输出。还有个偏方，就是给每个库做个“库摘要”，检索前让LLM先读一遍摘要再决定，成本高一点但准确率提升明显。你现在的LangGraph流程里，有没有试过把路由节点改成并行分发加一个合并节点？我觉得这比硬让LLM做规划更符合它的能力边界。

并行查所有库再合并这个思路其实挺实用的，代价就是多花点token，但能避免漏检。我建议你试试在路由前先加一层“关键词覆盖检查”，把问题里出现的部门相关词都抓出来，强制触发对应库的检索。另外Prompt里别让LLM“想”，直接给它一个固定句式，比如“列出所有可能涉及的部门”，比让它自由发挥稳得多。