Agentic 路由让每个问题找到对的部门M4 落地实测系列城市管理 Agentic RAG —— 从零搭建城市管理问答系统本篇M4 · Agentic 路由实测版源码https://gitee.com/Chester_Xue/city-agentic-rag一、M3 之后还差什么M3 做完系统能「查」能「答」了。但用起来有个明显的别扭❓ 问题 XX社区老人需要救助吗 回答……把气象、民政、卫健、热线的资料全捞出来一起答检索是盲目的——没有「意图」概念。你问老人救助它把四个部门的知识库全部捞一遍然后让大模型自己挑有用的。数据少的时候问题不大可一旦数据量上来检索噪音变多、回答变慢、还可能把不相关的资料混进答案。打个比方没有路由的系统像一家没有分诊台的医院——你来看胃病护士把你的病历复印了八份全院每个科室都给你看一遍最后外科医生和内科医生各说各的。效率低还容易误诊。M4 要做的事就一件加一个分诊台路由让每个问题先去对的科室。二、路由在干什么大白话版路由Router就是问题的意图分类器先判断「这个问题属于哪个领域」再决定去哪个部门的知识库检索。你的问题 │ ▼ [路由] 这是气象问题医疗问题民政问题还是投诉 │ weather / healthcare / civil / hotline / all / greeting ▼ [检索] 只查路由指定的部门气象局应急局 / 卫健委120 / 民政局 / 12345热线 │ ▼ [生成] 大模型照检索到的资料回答分类的六个类别对应项目四大业务域 两个特殊情况类别含义检索范围weather气象/预警/防汛气象局 应急局healthcare医疗/急救/床位卫健委 120急救中心civil民政/老人/低保民政局hotline投诉/工单/热线12345热线all跨领域综合全部部门greeting问候寒暄不检索直接回复三、两级分类关键词省钱大模型判得准路由怎么做分类两条路关键词规则或者大模型。我的实现是两级都用各管一段。第一级关键词规则ROUTE_RULESROUTE_RULES{weather:[暴雨,预警,降雨,台风,天气,防汛,内涝,气象,洪水],healthcare:[医院,床位,急救,120,医疗,救护,卫健委,医生],civil:[老人,低保,人口,救助,养老,民政,弱势,孤儿,残障],hotline:[投诉,工单,派发,热线,12345,举报,诉求],}为什么不全用大模型省钱。路由分类在每轮问答都要跑一次一次大模型调用要钱还要几百毫秒。而「问候语」这种明显不需要分类的问题一个if就完事了GREETING_RULES[你好,您好,嗨,哈喽,hello,hi,谢谢,感谢,再见,拜拜]def_is_greeting(question:str)-bool:qquestion.lower()returnany(kwinqforkwinGREETING_RULES)实测效果零大模型调用纯规则你好 - {route: greeting, depts: None, method: greeting} 暴雨积水投诉 - {route: [weather, hotline], depts: [气象局, 应急局, 12345热线], method: keyword}第二条是「多命中快速通道」问题里同时出现「暴雨」和「投诉」两个领域的关键词意图明确是跨领域直接返回两个类别省一次大模型调用。第二级大模型极小 prompt关键词没命中或只命中一个时交给大模型判。prompt 刻意做得极小——只有分类说明和一行问题max_tokens16一次调用几分钱你是问题路由分类器。判断问题属于哪个领域只输出类别代码多个用英文逗号分隔不要输出其他内容。 类别说明 weather气象/天气/预警/防汛/台风 healthcare医疗/医院/急救/床位 civil民政/老人/低保/救助/弱势群体 hotline投诉/工单/热线/诉求 all跨多个领域或无法确定 greeting问候/寒暄 问题{question}模型输出「weather」或「weather,civil」这种短代码解析起来也简单按逗号/顿号切开校验合法性非法项丢弃全非法就兜底为 all。实测走大模型今天暴雨吗 - {route: weather, depts: [气象局, 应急局], method: llm} 医院床位够吗 - {route: healthcare, depts: [卫健委, 120急救中心], method: llm} 积水投诉找谁 - {route: hotline, depts: [12345热线], method: llm}三个问题全部命中正确领域。四、踩坑大模型不跨领域验收差点挂了M4 有两条验收标准第二条是「XX社区老人需要救助吗」→必须检索气象 民政两个部门。这是 S1 场景暴雨预警后关注弱势群体的简化灾害背景下的「救助」既要有民政的弱势群体数据也要有气象的应急响应要求。第一次跑结果很尴尬❓ 问题 XX社区老人需要救助吗 [路由] civil → 检索范围: 民政局llm ← 只有民政大模型只判了 civil。模型错了吗没错——问题里根本没有天气词正常人听了也会觉得这是纯民政问题。但业务验收要求「气象民政」因为这类问题在真实场景里总是出现在灾害背景下。我在 prompt 里加了 few-shot 示例「暴雨橙色预警XX社区老人需要救助吗 → weather,civil」重测……模型还是判 civil——示例里的天气词没出现在用户问题里模型没被引导到跨领域。这是小 prompt 的天然局限业务领域的隐性关联「救助」在应急语境下气象民政不该指望一个 16 token 的分类 prompt 自己悟出来。这类领域知识应该固化在规则里于是有了领域联动# 领域联动救助/支援类问题通常伴随灾害背景S1 预警研判场景# 命中 civil 且含触发词「救助」时自动追加 weather实现「气象民政」联合检索。ROUTE_JOINTS{civil:(救助,weather),}命中 civil 且问题含「救助」→ 自动补一个 weather。重测❓ 问题 XX社区老人需要救助吗 [路由] civilweather → 检索范围: 民政局/气象局/应急局keyword ← 达标关键细节这是关键词阶段完成的零大模型调用。规则比模型便宜也比模型稳定。再验证「不误伤」——纯民政问题不带灾害背景不该被联动低保申请需要什么材料 - {route: civil, depts: [民政局], method: llm} ← 只查民政 ✅五、检索落点dept_filter 从单部门到多部门路由判出了部门列表如[民政局, 气象局, 应急局]检索接口要接得住。M3 的dept_filter只支持单个部门字符串M4 扩展成支持部门列表# M4dept_filter 支持 str / list / None 三种形态hitsdb.query(暴雨,top_k3,dept_filter气象局)# 单部门hitsdb.query(暴雨老人,top_k3,dept_filter[气象局,民政局])# 多部门路由用hitsdb.query(暴雨,top_k3)# 全库实现上有个坑气象局和应急局共用一个 collection同属应急领域M2 的数据隔离设计。部门列表过滤时同一个 collection 内多个部门要用 Chroma 的$in条件精确过滤否则 dept_filter[气象局] 会把应急局的数据也带出来# 部门 - collection 分组后每组用 $in 精确过滤where{dept:{$in:dept_group}}实测联合检索池top_k8问题「XX社区老人需要救助吗」路由范围民政局气象局应急局部门分布: 民政局 3 条 / 应急局 2 条 / 气象局 2 条注意卫健、热线的数据一条都没进来——数据隔离原则在路由这层真正落地了。检索只在「该去的地方」找。六、cli 改造路由 → 检索 → 生成一条新链路M3 的 cli 是「检索 → 生成」M4 在前面加了路由环节一行[路由]日志让判定过程可见演示用可关❓ 问题 今天暴雨吗 [路由] weather → 检索范围: 气象局/应急局llm 回答 根据现有资料无法直接判断今天是否下暴雨知识库不含实时天气数据…… 1. 资料中不包含实时或今日的天气预报数据…… 2. 如需判断今日是否暴雨需要以下信息当前资料缺失…… 引用来源 - 气象局/预警等级.txt - 应急局/防汛应急响应预案.txt这条回答我很喜欢——它诚实地承认了知识库没有实时天气而不是编一个「今天有暴雨」。这是 M3 定下的 Prompt 硬约束在起作用到了 M4 依然稳定。问候语也顺手处理了零成本❓ 问题 你好 回答 你好我是城市应急与民生服务问答助手可以问我暴雨预警、急救资源、老人救助、积水投诉等问题……七、验收总览验收项路由判定检索范围结果「今天暴雨吗」weather气象局应急局只检索气象✅「XX社区老人需要救助吗」civilweather民政局气象局应急局气象民政✅外加抽查积水投诉 → 只查热线 ✅低保咨询 → 只查民政不误联动✅你好 → 直接回复不检索 ✅。至此系统从「有问必答什么都捞」进化成「先分诊、再精准检索」——路由这层为后面 M5 的自适应检索和答案反思铺好了「意图」这个维度。八、下一步路由让检索变「聪明」了但还有两个问题悬着检索分数低的时候怎么办要不要自动扩大范围再搜一次模型回答完要不要自我核查一遍和引用资料对不对得上这就是 M5自适应检索 答案反思。下一篇M5 自适应检索 答案反思让系统自己检查作业上一篇M3 检索大模型让系统「开口回答」系列目录城市管理 Agentic RAG —— 从零搭建城市管理问答系统想了解更专业的内容本文是项目实战记录。如果你对 RAG 的原理、Prompt 工程技巧、大模型 API 接入的完整方案感兴趣欢迎访问我的 CSDN 专栏喵本喵叁肆的 Agentic RAG 实战专栏阅读完整的技术博客系列含可运行代码、架构图与验收标准。
Agentic 路由让每个问题找到对的部门M4 落地实测系列城市管理 Agentic RAG —— 从零搭建城市管理问答系统本篇M4 · Agentic 路由实测版源码https://gitee.com/Chester_Xue/city-agentic-rag一、M3 之后还差什么M3 做完系统能「查」能「答」了。但用起来有个明显的别扭❓ 问题 XX社区老人需要救助吗 回答……把气象、民政、卫健、热线的资料全捞出来一起答检索是盲目的——没有「意图」概念。你问老人救助它把四个部门的知识库全部捞一遍然后让大模型自己挑有用的。数据少的时候问题不大可一旦数据量上来检索噪音变多、回答变慢、还可能把不相关的资料混进答案。打个比方没有路由的系统像一家没有分诊台的医院——你来看胃病护士把你的病历复印了八份全院每个科室都给你看一遍最后外科医生和内科医生各说各的。效率低还容易误诊。M4 要做的事就一件加一个分诊台路由让每个问题先去对的科室。二、路由在干什么大白话版路由Router就是问题的意图分类器先判断「这个问题属于哪个领域」再决定去哪个部门的知识库检索。你的问题 │ ▼ [路由] 这是气象问题医疗问题民政问题还是投诉 │ weather / healthcare / civil / hotline / all / greeting ▼ [检索] 只查路由指定的部门气象局应急局 / 卫健委120 / 民政局 / 12345热线 │ ▼ [生成] 大模型照检索到的资料回答分类的六个类别对应项目四大业务域 两个特殊情况类别含义检索范围weather气象/预警/防汛气象局 应急局healthcare医疗/急救/床位卫健委 120急救中心civil民政/老人/低保民政局hotline投诉/工单/热线12345热线all跨领域综合全部部门greeting问候寒暄不检索直接回复三、两级分类关键词省钱大模型判得准路由怎么做分类两条路关键词规则或者大模型。我的实现是两级都用各管一段。第一级关键词规则ROUTE_RULESROUTE_RULES{weather:[暴雨,预警,降雨,台风,天气,防汛,内涝,气象,洪水],healthcare:[医院,床位,急救,120,医疗,救护,卫健委,医生],civil:[老人,低保,人口,救助,养老,民政,弱势,孤儿,残障],hotline:[投诉,工单,派发,热线,12345,举报,诉求],}为什么不全用大模型省钱。路由分类在每轮问答都要跑一次一次大模型调用要钱还要几百毫秒。而「问候语」这种明显不需要分类的问题一个if就完事了GREETING_RULES[你好,您好,嗨,哈喽,hello,hi,谢谢,感谢,再见,拜拜]def_is_greeting(question:str)-bool:qquestion.lower()returnany(kwinqforkwinGREETING_RULES)实测效果零大模型调用纯规则你好 - {route: greeting, depts: None, method: greeting} 暴雨积水投诉 - {route: [weather, hotline], depts: [气象局, 应急局, 12345热线], method: keyword}第二条是「多命中快速通道」问题里同时出现「暴雨」和「投诉」两个领域的关键词意图明确是跨领域直接返回两个类别省一次大模型调用。第二级大模型极小 prompt关键词没命中或只命中一个时交给大模型判。prompt 刻意做得极小——只有分类说明和一行问题max_tokens16一次调用几分钱你是问题路由分类器。判断问题属于哪个领域只输出类别代码多个用英文逗号分隔不要输出其他内容。 类别说明 weather气象/天气/预警/防汛/台风 healthcare医疗/医院/急救/床位 civil民政/老人/低保/救助/弱势群体 hotline投诉/工单/热线/诉求 all跨多个领域或无法确定 greeting问候/寒暄 问题{question}模型输出「weather」或「weather,civil」这种短代码解析起来也简单按逗号/顿号切开校验合法性非法项丢弃全非法就兜底为 all。实测走大模型今天暴雨吗 - {route: weather, depts: [气象局, 应急局], method: llm} 医院床位够吗 - {route: healthcare, depts: [卫健委, 120急救中心], method: llm} 积水投诉找谁 - {route: hotline, depts: [12345热线], method: llm}三个问题全部命中正确领域。四、踩坑大模型不跨领域验收差点挂了M4 有两条验收标准第二条是「XX社区老人需要救助吗」→必须检索气象 民政两个部门。这是 S1 场景暴雨预警后关注弱势群体的简化灾害背景下的「救助」既要有民政的弱势群体数据也要有气象的应急响应要求。第一次跑结果很尴尬❓ 问题 XX社区老人需要救助吗 [路由] civil → 检索范围: 民政局llm ← 只有民政大模型只判了 civil。模型错了吗没错——问题里根本没有天气词正常人听了也会觉得这是纯民政问题。但业务验收要求「气象民政」因为这类问题在真实场景里总是出现在灾害背景下。我在 prompt 里加了 few-shot 示例「暴雨橙色预警XX社区老人需要救助吗 → weather,civil」重测……模型还是判 civil——示例里的天气词没出现在用户问题里模型没被引导到跨领域。这是小 prompt 的天然局限业务领域的隐性关联「救助」在应急语境下气象民政不该指望一个 16 token 的分类 prompt 自己悟出来。这类领域知识应该固化在规则里于是有了领域联动# 领域联动救助/支援类问题通常伴随灾害背景S1 预警研判场景# 命中 civil 且含触发词「救助」时自动追加 weather实现「气象民政」联合检索。ROUTE_JOINTS{civil:(救助,weather),}命中 civil 且问题含「救助」→ 自动补一个 weather。重测❓ 问题 XX社区老人需要救助吗 [路由] civilweather → 检索范围: 民政局/气象局/应急局keyword ← 达标关键细节这是关键词阶段完成的零大模型调用。规则比模型便宜也比模型稳定。再验证「不误伤」——纯民政问题不带灾害背景不该被联动低保申请需要什么材料 - {route: civil, depts: [民政局], method: llm} ← 只查民政 ✅五、检索落点dept_filter 从单部门到多部门路由判出了部门列表如[民政局, 气象局, 应急局]检索接口要接得住。M3 的dept_filter只支持单个部门字符串M4 扩展成支持部门列表# M4dept_filter 支持 str / list / None 三种形态hitsdb.query(暴雨,top_k3,dept_filter气象局)# 单部门hitsdb.query(暴雨老人,top_k3,dept_filter[气象局,民政局])# 多部门路由用hitsdb.query(暴雨,top_k3)# 全库实现上有个坑气象局和应急局共用一个 collection同属应急领域M2 的数据隔离设计。部门列表过滤时同一个 collection 内多个部门要用 Chroma 的$in条件精确过滤否则 dept_filter[气象局] 会把应急局的数据也带出来# 部门 - collection 分组后每组用 $in 精确过滤where{dept:{$in:dept_group}}实测联合检索池top_k8问题「XX社区老人需要救助吗」路由范围民政局气象局应急局部门分布: 民政局 3 条 / 应急局 2 条 / 气象局 2 条注意卫健、热线的数据一条都没进来——数据隔离原则在路由这层真正落地了。检索只在「该去的地方」找。六、cli 改造路由 → 检索 → 生成一条新链路M3 的 cli 是「检索 → 生成」M4 在前面加了路由环节一行[路由]日志让判定过程可见演示用可关❓ 问题 今天暴雨吗 [路由] weather → 检索范围: 气象局/应急局llm 回答 根据现有资料无法直接判断今天是否下暴雨知识库不含实时天气数据…… 1. 资料中不包含实时或今日的天气预报数据…… 2. 如需判断今日是否暴雨需要以下信息当前资料缺失…… 引用来源 - 气象局/预警等级.txt - 应急局/防汛应急响应预案.txt这条回答我很喜欢——它诚实地承认了知识库没有实时天气而不是编一个「今天有暴雨」。这是 M3 定下的 Prompt 硬约束在起作用到了 M4 依然稳定。问候语也顺手处理了零成本❓ 问题 你好 回答 你好我是城市应急与民生服务问答助手可以问我暴雨预警、急救资源、老人救助、积水投诉等问题……七、验收总览验收项路由判定检索范围结果「今天暴雨吗」weather气象局应急局只检索气象✅「XX社区老人需要救助吗」civilweather民政局气象局应急局气象民政✅外加抽查积水投诉 → 只查热线 ✅低保咨询 → 只查民政不误联动✅你好 → 直接回复不检索 ✅。至此系统从「有问必答什么都捞」进化成「先分诊、再精准检索」——路由这层为后面 M5 的自适应检索和答案反思铺好了「意图」这个维度。八、下一步路由让检索变「聪明」了但还有两个问题悬着检索分数低的时候怎么办要不要自动扩大范围再搜一次模型回答完要不要自我核查一遍和引用资料对不对得上这就是 M5自适应检索 答案反思。下一篇M5 自适应检索 答案反思让系统自己检查作业上一篇M3 检索大模型让系统「开口回答」系列目录城市管理 Agentic RAG —— 从零搭建城市管理问答系统想了解更专业的内容本文是项目实战记录。如果你对 RAG 的原理、Prompt 工程技巧、大模型 API 接入的完整方案感兴趣欢迎访问我的 CSDN 专栏喵本喵叁肆的 Agentic RAG 实战专栏阅读完整的技术博客系列含可运行代码、架构图与验收标准。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
