部门过滤与综合研判从问答机到研判助手M6 落地实测系列城市管理 Agentic RAG —— 从零搭建城市管理问答系统本篇M6 · 部门过滤命令 综合研判输出实测版源码https://gitee.com/Chester_Xue/city-agentic-rag一、M5 之后还差什么M5 给系统装上了「自适应检索」和「答案反思」会自己换姿势找资料、答完自己检查作业。但用着用着发现它还只是个被动应答的问答机——你问一句它答一句每次只给一个答案。真实的城市管理场景不是这样的场景一领导想看全局。「XX 社区暴雨应急准备」——这不是一个单一问题它牵扯气象预警、卫健急救、民政弱势群体、热线积水投诉四个领域。你只想要一段话还是想要一份分部门、带来源、能直接拿去开会的研判报告场景二你要盯住某个部门。想单独看卫健委的急救资源情况系统却自作主张把气象局、民政局的资料也混进来——信息是多了但不聚焦甚至可能带偏结论。M6 要做的就是两件事部门过滤命令——/dept 卫健委 急救资源你说查哪个部门就查哪个部门扩展也只在这个领域内扩综合研判输出——/all或问题本身跨领域时输出四部门分块研判报告气象、卫健、民政、热线各一段各带来源最后给综合建议。打个比方M5 之前是「前台接电话」M5 是「接电话的人会查资料、会复核」M6 是「这个人会给你写会议纪要」——还是分部门、带出处的会议纪要。二、先看效果验收场景实测按推进表M6 的验收是输入「XX社区暴雨应急准备」→ 输出四部门分块报告。先看实测结果验收 ①/all XX社区暴雨应急准备→ 四部门分块报告❓ 问题 /all XX社区暴雨应急准备 [路由] all/all 命令 → 综合研判四业务域分块报告 [检索] 按域检索每域 top_k2命中 8 块 气象局×1、应急局×1、120急救中心×1、12345热线×2、民政局×2、卫健委×1 最高分 0.704 综合研判 【气象研判】来自气象局/预警等级.txt、应急局/防汛应急响应预案.txt 研判XX社区暴雨应急准备需依据预警等级与响应预案联动。若气象局发布暴雨橙色及以上预警 应急局预案要求启动Ⅳ级及以上响应成员单位到岗、强制转移危险区群众。 当前资料未提供社区具体内涝点、水位数据无法预判具体响应级别需实时监测补充。 【卫健研判】来自120急救中心/急救流程.txt、卫健委/急救资源.txt 120急救中心要求城区接警响应≤15分钟市第一人民医院为三甲空闲床位320张 可作急救转运接收点。但资料未提供社区具体位置、急救站点距离及暴雨专项预案 无法评估实际响应时效需补充信息。 【民政研判】来自民政局/弱势群体统计.txt、民政局/养老服务设施.txt XX社区为老旧小区老年人口占比32%需优先保障独居老人156人、残疾人223人及低保户587人。 但资料未提供社区具体应急物资储备、避难场所及转移方案资料不足建议补充。 【热线研判】来自12345热线/高频诉求统计.txt、12345热线/工单案例.txt 7月市政设施类诉求占23%2891件且环比上升15%热点区域为XX路与YY路交叉口 该处7月20日积水深30cm已派城管局处置。建议优先部署该点位排水及井盖巡查。 【综合建议】 优先级排序① 气象与应急联动 → ② 民政弱势群体转移 → ③ 热线积水点处置 → ④ 卫健急救保障。 跨部门协调应急局牵头启动预案气象局实时推送预警民政对接街道落实弱势群体转移 城管局优先疏通积水点卫健委预留急救通道。 行动建议立即补充社区内涝点、物资储备数据完善专项预案建立信息共享群每2小时通报。四个部门各一段每段开头标注来源文件最后综合建议给出优先级、跨部门协调、行动建议——这已经是一份能直接拿去做会前准备的研判材料了。验收 ②/dept 卫健委 急救资源是否充足→ 只查卫健域❓ 问题 /dept 卫健委 急救资源是否充足 [路由] 跳过/dept 命令→ 检索范围: 卫健委 [检索] 首轮 top_k3卫健委最高分 0.476 [检索] 扩展① top_k5卫健委/120急救中心最高分 0.514 [反思] 核查通过与引用资料一致无编造 回答 根据现有资料无法全面判断急救资源是否充足…… 1. 救护车配置全市救护车45辆其中负压救护车12辆来源卫健委/医院床位资源.txt。 2. 医院床位与ICU市第一人民医院总床位1200张ICU 80张空床率8%…… 引用来源 - 卫健委/医院床位资源.txt - 120急救中心/急救流程.txt检索范围死死锁在卫健域卫健委 120急救中心回答全部有据可查还主动说明了「缺需求侧数据无法判断是否充足」——不硬答。验收 ③不敲命令问题本身跨领域也会自动触发❓ 问题 如何统筹全市应急资源应对灾害 [路由] all → 综合研判四业务域分块报告路由判断这是跨领域综合问题不需要用户记命令自动切换成研判模式。命令是给「想要控制权」的人用的普通用户直接问就行。三、命令系统给用户一个「方向盘」M6 给 CLI 加了三个命令parse_command解析❓ 问题/help可用命令/dept部门[,部门...]问题指定部门精准问答如/dept 卫健委 急救资源充足吗/all问题全部门综合研判四业务域分块报告综合建议/help显示本帮助 直接输入问题则自动路由到相关部门跨领域综合问题自动输出综合研判报告 可用部门气象局、应急局、卫健委、120急救中心、民政局、12345热线三个细节值得说1. 部门名有校验。敲/dept 城管委 积水数据里没有这个部门系统不会静默查空而是提示⚠️ 未知部门城管委可用气象局、应急局、卫健委、120急救中心、民政局、12345热线2. 多部门支持逗号/顿号。/dept 气象局,民政局 暴雨影响一次锁两个部门。3. 命令前缀防误判。一开始用startswith(/dept)判断结果输入/deptx 卫健委这种问题也被当成命令。改成「前缀后接空白或直接结束」才修好——一个小坑见第五节。四、综合研判报告怎么生成核心是一个新模块src/formatter.py的ReportFormatter类。设计上有一个关键决策分块生成而不是一次生成。如果把四部门资料一次全塞给大模型让它一口气输出四块综合建议会出现两个问题模型可能漏块写着写着少了一个部门、可能合并把民政和热线并成一段。分块生成则完全可控fordomain,hitsinself.group_by_domain(results):contextformat_context(hits)# 只放这一个域的资料promptSECTION_PROMPT.format(domaindomain,questionquestion,contextcontext)textself.llm.chat(prompt,...)# 每块独立调用一次blocks.append(f【{domain}研判】来自{self._sources(hits)}\n{text})每块只喂本域资料、只生成一段研判格式 100% 可控、来源逐块标注。最后把各块研判汇总再调一次模型生成综合建议——模型只做「汇总提建议」不重复读原始资料省 token 又聚焦。另外每个域块内的 prompt 都有硬约束只依据给定资料作答资料不足时明确说明严禁编造。所以民政块即使只有 0.45 分的弱相关资料也会老老实实写「资料未提供应急物资储备……建议补充」而不是编一份转移方案出来——这和 M5「信息不足请明确告知」是一脉相承的底线。五、踩过的坑三个都是真实的坑 1全库 top-k 检索会被「高分域」霸榜低分但相关的域直接被挤出。第一版综合研判用全库检索取前 8 条结果四域报告只有三块——民政没了。查原因「XX社区暴雨应急准备」对气象/热线资料的相似度普遍 0.5~0.7而对民政数据弱势群体统计只有 0.447前 8 名被气象和热线占满民政一条都进不来。但民政恰恰是暴雨应急要重点关注的独居老人、低保户转移按相似度全局排序不等于按业务价值排序。解法综合研判按业务域分组检索每域独立取 top_k默认 2 条合并后再排序。这样每个域都有候选块四域报告不会缺角for_domain,deptsinREPORT_GROUPS:# 气象/卫健/民政/热线四域hits.extend(retrieve(question,top_ktop_k,dept_filterdepts))坑 2/dept命令如果沿用自适应检索的「放开全库」会把别的部门资料混进来。/dept 卫健委 急救资源第一版跑出来回答居然引用了应急局/防汛应急响应预案.txt——因为 M5 的自适应检索在首轮分低时会自动「移除部门过滤」放开全库再搜。这个机制对自动路由是对的防止路由误判漏检但对用户显式指定部门就是灾难用户明明说只看卫健委系统却把应急局的预案拿来讲急救资源。解法给自适应检索加strict_deptexpand_dept_filter参数——/dept命令首轮严格按指定部门扩展轮只在同域内找卫健委 → 卫健委120急救中心两个部门同属卫健域既保领域纯净又避免单部门数据太少直接判无果。坑 3startswith(/dept)会把/deptx 卫健委误判成命令。一个 5 分钟能修的小 bug但值得记命令前缀判断必须「后接空白或直接结束」否则任何以 /dept 开头的正常问题都会被吞掉。六、验收汇总与回归验收项结果①/all XX社区暴雨应急准备✅ 四部门分块报告气象/卫健/民政/热线 综合建议各块带来源②/dept 卫健委 急救资源✅ 只检索卫健域卫健委120急救中心不污染其他领域③ 多部门命令/dept 气象局,民政局 暴雨影响✅ 同域扩充到气象局/应急局/民政局④ 自然输入「如何统筹全市应急资源应对灾害」✅ 路由 all 自动触发四域综合研判⑤ 未知部门提示✅ 列出可用部门清单回归抽查M1~M5 能力不退化暴雨响应 → 首轮强相关直接答 ✅独居老人救助 → 路由联动 civilweather ✅低保申请 → 只查民政不误伤 ✅你好 → 零成本欢迎语 ✅气象局局长电话库内没有→ 明确告知零编造 ✅七、本阶段小结M6 之后系统从「问答机」变成了「研判助手」给用户方向盘——/dept指定部门、/all全量研判命令简单直接自动识别跨领域——路由判 all 时自动切研判模式不强制用户记命令报告可溯源——四域分块、逐块标注来源、资料不足如实说明综合建议基于各块研判生成。架构上ReportFormatter是推进表早就预留的接口format()是报告模板唯一入口——二期想加 JSON 模板、图表渲染只扩展这个类就行调用方不用改。八、下一步M6 的能力都在命令行里演示给领导看还不够直观。M7 计划做Gradio Web 界面顶部四个场景按钮暴雨应急、医疗调度……、侧边部门过滤下拉、下方输出区渲染综合研判报告——把今天这些命令变成点两下鼠标就能出报告的界面。上一篇M5 自适应检索与答案反思让系统自己检查作业下一篇M7 Gradio Web 界面点两下就出研判报告系列目录城市管理 Agentic RAG —— 从零搭建城市管理问答系统想了解更专业的内容本文是项目实战记录。如果你对 RAG 的原理、Prompt 工程技巧、大模型 API 接入的完整方案感兴趣欢迎访问我的 CSDN 专栏喵本喵叁肆的 Agentic RAG 实战专栏阅读完整的技术博客系列含可运行代码、架构图与验收标准。