简介这是一份关于“大模型智慧河长”的完整解决方案演示文稿面向水利信息化建设者、解决方案架构师以及河长制项目管理人员适用于项目汇报、方案设计与技术选型可帮助理解如何将大模型能力落地到河流治理与监管业务中。资源包内共1个pptx文件压缩包约5.65MB页面与章节结构完整可直接打开用于汇报也可基于框架快速整理成自己的材料。目前该资源已有98人浏览学习作为智慧水利与大模型融合方向的方案样例参考价值较强。方案主体围绕引言、大模型技术及应用、智慧河长系统架构、关键技术应用、实施方案与效果评估等章节展开重点覆盖水质监测预警、水量调度优化、水生态修复与保护等典型场景并介绍物联网、人工智能、云计算与大模型训练推理等技术的融合路径。读者可从中获得一套完整的智慧河长规划思路、平台功能拆解和汇报演示模板适合作为水利行业信息化方案的设计参考。1. 河长手里那一摞表格为什么需要大模型来读巡河记录、督办单、水质通报、遥感影像、群众举报这些数据分散在不同系统里多半还是照片、语音、手写扫描件。河长打开巡河App看到的是几十条“乱堆乱放”“水面有漂浮物”的短句背后对应的照片、坐标、整改期限、责任单位都要人工去翻。大模型在这里的角色不是做一个能聊天的机器人而是把非结构化数据结构化把分散的数据串成一条可追踪的决策链条。这套“大模型智慧河长”解决方案核心是把多模态识别、知识库检索、自动报告生成三个能力嵌进巡河、上报、分派、考核的业务闭环里。下面的方案分解按从感知到决策的顺序展开最后落到可验证的落地指标上。2. 智慧河长里的“大模型”应当拆成哪几块感知层、知识层与生成层2.1 先分清河湖场景里有两类“大模型”在起作用做智慧河长方案时最常见的误区是把所有问题都丢给一个对话式大模型。实际业务中对图像、文本、语音的处理逻辑完全不同至少要拆成感知和决策两层。感知层处理的是巡河照片、卫星遥感影像、无人机视频。这类任务主要靠目标检测模型识别河面漂浮物、河道乱占乱建、岸线堆载等问题常见做法是用 YOLO 系列或 RT-DETR 训练专用检测器也可以直接用多模态大模型做零样本识别。决策层处理的是文本包括工单分类、法规问答、报告生成这一层用 LLM 更合适比如 Qwen、GLM、DeepSeek 系列。两层模型的部署形态、硬件要求和验收指标也不同。下面这张表是在方案评审时经常用到的对比任务类型典型模型部署形态硬件参考验收关注点河面漂浮物识别YOLOv8 / RT-DETR边缘盒子或GPU服务器NVIDIA RTX 4090 / Jetson OrinmAP、单帧延迟四乱问题图文理解Qwen-VL / GLM-4VGPU服务器24GB以上显存分类准确率、误报率法规知识问答Qwen / GLM 7B~14B本地GPU或国产算力16GB~48GB显存检索命中率、答案溯源率巡河报告生成7B~32B量化模型GPU服务器24GB以上显存格式合规率、业务要素完整率感知层更在意“有没有、在哪里”决策层更在意“是什么、怎么办”。方案里如果把这两层混在一起谈大模型能力评审时容易被问住。2.2 多模态识别怎么接入巡河照片流实际巡河场景里照片质量参差不齐逆光、水雾、手机抖动都很常见。早期方案依赖人工看图分类一个县一天几百张照片分类员根本看不过来。引入多模态大模型后可以把“看图-描述-归类-提取关键信息”一步做完。常用做法是选一个支持视觉输入的本地部署模型通过 OpenAI 兼容接口调用。核心代码逻辑如下from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def analyze_river_photo(image_path: str): response client.chat.completions.create( modelqwen-vl, messages[ { role: user, content: [ {type: image_url, image_url: {url: ffile://{image_path}}}, { type: text, text: ( 你是河湖巡查图像分析助手。请判断图中是否存在以下问题 水面漂浮物、岸线垃圾、违法建筑、非法排污、围垦养殖。 如有问题输出JSON{\problem_type\:\...\,\location_desc\:\...\, \severity\:\high/medium/low\,\advice\:\...\}。 如果没有问题输出{\problem_type\:\none\}。 ) } ], } ], max_tokens512, temperature0.1, ) return response.choices[0].message.content这段代码走的是本地推理服务的 OpenAI 兼容接口。temperature0.1是为了让识别输出尽量稳定避免同一张照片每次返回不同类型。max_tokens512对结构化输出足够输出太长反而容易出现格式断裂。实际部署时建议对返回的 JSON 做一次二次校验解析失败就降级到人工标注队列不要直接丢弃。2.3 知识库检索RAG比微调先到位河长业务里有大量需要“查一下”的场景某段河道属于哪个社区管辖、某类涉河建设项目需要什么审批材料、去年某段河道的督办件整改结果。这些知识散落在“一河一策”文档、水法规、历史工单和巡查台账里。微调能解决术语理解和输出风格问题但解决不了“知识更新”的问题。水法规更新、行政区划调整、考核细则每年都在变微调一次的成本和周期都不小。RAG 的优势在于知识以文档形式进向量库更新文档就更新了知识而且回答时可以附上来源文件便于追责和复核。文本切分策略直接决定检索质量。河湖文档经常是条款式和段落式混排按固定字数切会把一条完整规定切成两半。我一般会先把文档按章、条、款层级拆成语义块再对超过 500 字的块做重叠切分重叠长度设 50~100 字。这样既保留了条款完整性又不会因为块过大超出 embedding 模型的输入上限。2.4 生成式报告把调度会前的人工汇总交给大模型县级河长办每月要出巡河通报、问题整改台账、水质变化分析。这些报告 80% 的内容是固定模板加数据替换但数据要从四五个系统里导出来再手工填。大模型做这件事的价值在于把数据查询、指标解读、段落生成串成一个流程。报告生成前先把结构化查询结果拿回来比如问题总数、已整改数、逾期数、各类问题占比。大模型只负责把这些数字翻译成符合公文习惯的句子。注意不要在提示词里让模型自己“编数字”数字必须由外部查询注入模型只做润色和编排。3. 用 RAG 给河长搭一个本地知识库文档解析到问答跑通3.1 数据准备一河一策、法规与历史工单从哪来知识库的构建数据源至少要覆盖四类一是“一河一策”方案每条河一份包含河流概况、问题清单、治理目标二是水法律法规和地方法规重点是涉河建设项目审批、排污口管理相关条款三是历史巡河工单选近两年已办结的去掉身份证号、手机号等个人信息四是水质监测月报按监测断面组织。这四类数据的格式差异很大PDF、Word、Excel、图片扫描件都有。前期数据清洗工作往往比模型选型更耗时建议在方案里单列一版“数据治理工作计划”明确每一类文档的归口单位、更新频率和质检责任人。3.2 文档解析与切分的工程细节PDF 解析建议优先用支持布局分析的解析库保留标题层级和表格结构。扫描件要先过 OCR中文识别质量直接决定后续切分效果。表格类数据不要直接转成纯文本尽量转成 Markdown 表格或 JSON否则检索时一问到“某断面某月氨氮浓度”向量检索很难把对应行捞出来。切分后的每个片段要保留元数据至少包括来源文档名、章节路径、页码、更新日期。这些字段在回答时用来生成引用标注没有来源的回答在政务场景里没有说服力。3.3 Embedding 与向量库选型中文河湖文档里大量出现专业术语、地名和法规名称embedding 模型要选中文效果好的。目前常用的是 BGE 系列或 M3E 系列按 1024 维向量入库。向量库选型上数据量在百万级以下用轻量方案就够不必一上来就上分布式集群。向量库适合场景运维成本备注Chroma原型验证低单机文件型适合演示Milvus生产环境中支持标量过滤与向量混合检索Elasticsearch knn已有ES的团队中统一日志与知识库检索栈3.4 从查询到回答打通 RAG 完整链路搭好向量库后查询链路分四步改写问题、检索片段、拼接上下文、生成回答。如果用户问“滨江路那段河为啥上周督办逾期了”直接拿这句话去向量库检索效果一般。先把问题里的地点和实体抽取出来改写成一个更利于检索的语句比如“滨江路段河道 督办 逾期 原因”检索命中率会高不少。def rag_query(question: str, top_k: int 5) - str: # 1. 生成问题向量 q_vec embed_model.encode(question, normalize_embeddingsTrue) # 2. 向量检索返回 top_k 个相关片段 hits vector_db.search(q_vec, top_ktop_k) contexts [] for hit in hits: contexts.append({ text: hit.payload[text], source: hit.payload.get(source_doc, ), page: hit.payload.get(page, 0), score: round(hit.score, 4) }) # 3. 拼接上下文 context_text \n\n.join([c[text] for c in contexts]) # 4. 调用LLM生成带引用的回答 prompt f你是河长制业务助手。请基于以下资料回答问题。 资料中没有的信息明确说\资料中未找到\不要推测。 [资料] {context_text} [问题] {question} 回答时在每条信息后用[来源: 文档名-页码]标注。 return llm_generate(prompt)top_k5是起始值实际调优时要看回答效果检索片段太少找不到答案太多会稀释有效信息。打分阈值建议设 0.35 左右低于阈值的片段宁可不给模型也不要硬塞进去。回答时强制要求标注来源这件事要在提示词里反复强调并保留一个“资料中未找到”的选项防止模型编造。4. 巡河工单的智能分类与结构化输出让一线汇报可直接入库4.1 从口语化巡河描述到结构化工单字段一线巡河人员上报的内容通常是“xx桥下面好多垃圾袋”“河水颜色不对有点发黑”“有人在河边倒建筑垃圾”这类口语化描述。直接存进工单系统后续做统计分析几乎不可能因为问题类型、位置、严重程度都埋在自然语言里。用大模型做结构化抽取相当于在录入环节加一道转换。关键是要把输出格式锁死让后续流程只认这个格式。{ problem_type: 乱堆垃圾, location: { description: 滨江东路桥下东侧河滩, river_name: 清源河, coordinates: {lat: 31.2304, lng: 121.4737} }, severity: high, evidence: [垃圾袋沿河岸散布约20米, 河滩有明显堆积], suggested_action: 通知属地街道安排保洁员清理并排查周边监控溯源倾倒源头, deadline_suggestion: 24小时内 }提示词里要给出这个 JSON 格式的示例和字段说明并要求模型只输出 JSON不要输出解释性文字。实际跑下来会发现两个问题一是坐标经常缺失因为照片 EXIF 信息不全或巡河员没开定位二是问题类型容易把“乱堆”和“乱倒”搞混。解决方法是把问题类型枚举值写死在提示词里并给每个枚举值配一个典型示例。4.2 本地部署的推理服务并发与延迟怎么定智慧河长方案的落地形态多数是政府内网私有化部署数据不出域是硬约束。本地跑大模型推理常见方案有两种轻量用 Ollama 起服务生产用 vLLM 做高并发。Ollama 适合试点阶段一条命令就能把模型拉起来ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct做方案验证没问题但生产环境就力不从心。vLLM 的 PagedAttention 机制显存利用率更高连续多轮请求吞吐明显好于原生推理框架。启动命令里几个参数要重点调python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-14b-instruct-awq \ --served-model-name river-llm \ --max-model-len 8192 \ --max-num-seqs 32 \ --gpu-memory-utilization 0.9 \ --quantization awqmax-model-len决定了上下文窗口有多长业务上工单分类给 2048 就够报告生成给到 8192 更稳。max-num-seqs控制并发请求数默认值往往偏保守对 7B 模型在 24GB 显存上开到 32 并不会 OOM。gpu-memory-utilization设 0.9 是经验值留出一点显存给 CUDA 上下文和临时张量。4.3 识别结果对不回坐标时怎么办结构化输出的坐标缺失率高是落地时被问得最多的点。常见做法是加一层地理编码兜底把“滨江东路桥下”这样的地点描述交给地理编码服务转成坐标。如果地理编码也失败就退回乡镇/街道粒度至少保证工单能派到属地而不是卡在录入环节。5. Agent 工作流从发现问题到生成处置建议的完整链路5.1 巡河工单怎么走通“识别-检索-建议-分派”全流程单点的大模型能力要真正减轻基层负担必须串成工作流。一次完整的智能处置链路是这样的巡河照片/语音进入系统语音先转文字照片走多模态识别文本描述与识别结果合并进 LLM 做工单结构化结构化字段触发规则引擎问题类型 位置 严重程度LLM 根据知识库检索历史同类工单处置方案生成处置建议工单写入业务系统按属地自动分派这条链路里大模型承担了三处工作结构化抽取、处置建议生成、必要时生成给上级的汇报摘要。规则引擎负责做硬约束比如“饮用水水源保护区内的问题自动标记为 high severity”这类判断不能交给大模型自由发挥。5.2 工具调用让模型读水质数据、查地图边界Agent 要会“用工具”而不是凭训练时的记忆回答问题。比如问“清源河最近三个月氨氮趋势怎么样”大模型必须去调水质数据库接口而不是自己编一串数字。def query_water_quality(river_name: str, months: int 3) - dict: # 调用内部水质监测平台的 HTTP 接口 endpoint http://10.20.30.40:8080/api/water-quality/trend params {river: river_name, months: months} resp requests.get(endpoint, paramsparams, timeout5) resp.raise_for_status() return resp.json() # Agent 注册工具 tools [ { type: function, function: { name: query_water_quality, description: 查询指定河流近N个月的水质指标趋势, parameters: { type: object, properties: { river_name: {type: string, description: 河流名称}, months: {type: integer, description: 查询月份数} }, required: [river_name] } } } ]工具调用要限定白名单不能让模型任意发 HTTP 请求。每个工具接口都要做超时控制水质平台接口慢的时候模型等不了 30 秒。实际工程里建议把 Agent 的思考过程输出到日志里方便定位是哪一步出了问题是检索没召回、工具调用失败还是生成阶段格式坏了。6. 效果验证让大模型输出从“能聊”到“能考核”6.1 用历史工单做回归测试集方案评审时最怕被问“准确率多少”。这个数字不能靠演示时的几个案例说明要从历史数据里抽一套稳定的测试集。做法是抽取近一年已办结的 500 条工单人工标注问题类型、位置、严重程度再拿这套标注数据跑模型算结构化输出的字段准确率。测试集要与模型训练数据隔离。如果微调过模型这 500 条不能混进训练集否则测试分数虚高部署到真实场景立刻露馅。6.2 评测指标分三级格式合规率、要素完整率、处置建议采纳率格式合规率是硬门槛要求输出能被 JSON parser 直接解析这条不达标后面都谈不上。要素完整率看位置、时间、类型、严重程度四个核心字段是否齐全。处置建议采纳率需要业务侧配合把模型生成的建议给审核人员打标统计“可直接采纳”“需修改”“不可用”的比例。前两个指标上线一周就能跑出来第三个指标至少要跑一个月才有统计意义。6.3 提示词版本管理与 A/B 测试提示词也是代码要进 Git。每个版本的提示词改动都要先在 6.1 的测试集上跑一遍记录三项指标的变化。灰度发布时按工单来源分流比如某两个乡镇先用新版本对比旧版本的关键指标数据足够后再全量切换。这套做法不复杂但能把大模型能力从“演示”推进到“业务系统的一部分”。本文还有配套的精品资源点击获取 大模型+智慧河长：多模态识别与RAG构建巡河智能闭环
简介这是一份关于“大模型智慧河长”的完整解决方案演示文稿面向水利信息化建设者、解决方案架构师以及河长制项目管理人员适用于项目汇报、方案设计与技术选型可帮助理解如何将大模型能力落地到河流治理与监管业务中。资源包内共1个pptx文件压缩包约5.65MB页面与章节结构完整可直接打开用于汇报也可基于框架快速整理成自己的材料。目前该资源已有98人浏览学习作为智慧水利与大模型融合方向的方案样例参考价值较强。方案主体围绕引言、大模型技术及应用、智慧河长系统架构、关键技术应用、实施方案与效果评估等章节展开重点覆盖水质监测预警、水量调度优化、水生态修复与保护等典型场景并介绍物联网、人工智能、云计算与大模型训练推理等技术的融合路径。读者可从中获得一套完整的智慧河长规划思路、平台功能拆解和汇报演示模板适合作为水利行业信息化方案的设计参考。1. 河长手里那一摞表格为什么需要大模型来读巡河记录、督办单、水质通报、遥感影像、群众举报这些数据分散在不同系统里多半还是照片、语音、手写扫描件。河长打开巡河App看到的是几十条“乱堆乱放”“水面有漂浮物”的短句背后对应的照片、坐标、整改期限、责任单位都要人工去翻。大模型在这里的角色不是做一个能聊天的机器人而是把非结构化数据结构化把分散的数据串成一条可追踪的决策链条。这套“大模型智慧河长”解决方案核心是把多模态识别、知识库检索、自动报告生成三个能力嵌进巡河、上报、分派、考核的业务闭环里。下面的方案分解按从感知到决策的顺序展开最后落到可验证的落地指标上。2. 智慧河长里的“大模型”应当拆成哪几块感知层、知识层与生成层2.1 先分清河湖场景里有两类“大模型”在起作用做智慧河长方案时最常见的误区是把所有问题都丢给一个对话式大模型。实际业务中对图像、文本、语音的处理逻辑完全不同至少要拆成感知和决策两层。感知层处理的是巡河照片、卫星遥感影像、无人机视频。这类任务主要靠目标检测模型识别河面漂浮物、河道乱占乱建、岸线堆载等问题常见做法是用 YOLO 系列或 RT-DETR 训练专用检测器也可以直接用多模态大模型做零样本识别。决策层处理的是文本包括工单分类、法规问答、报告生成这一层用 LLM 更合适比如 Qwen、GLM、DeepSeek 系列。两层模型的部署形态、硬件要求和验收指标也不同。下面这张表是在方案评审时经常用到的对比任务类型典型模型部署形态硬件参考验收关注点河面漂浮物识别YOLOv8 / RT-DETR边缘盒子或GPU服务器NVIDIA RTX 4090 / Jetson OrinmAP、单帧延迟四乱问题图文理解Qwen-VL / GLM-4VGPU服务器24GB以上显存分类准确率、误报率法规知识问答Qwen / GLM 7B~14B本地GPU或国产算力16GB~48GB显存检索命中率、答案溯源率巡河报告生成7B~32B量化模型GPU服务器24GB以上显存格式合规率、业务要素完整率感知层更在意“有没有、在哪里”决策层更在意“是什么、怎么办”。方案里如果把这两层混在一起谈大模型能力评审时容易被问住。2.2 多模态识别怎么接入巡河照片流实际巡河场景里照片质量参差不齐逆光、水雾、手机抖动都很常见。早期方案依赖人工看图分类一个县一天几百张照片分类员根本看不过来。引入多模态大模型后可以把“看图-描述-归类-提取关键信息”一步做完。常用做法是选一个支持视觉输入的本地部署模型通过 OpenAI 兼容接口调用。核心代码逻辑如下from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) def analyze_river_photo(image_path: str): response client.chat.completions.create( modelqwen-vl, messages[ { role: user, content: [ {type: image_url, image_url: {url: ffile://{image_path}}}, { type: text, text: ( 你是河湖巡查图像分析助手。请判断图中是否存在以下问题 水面漂浮物、岸线垃圾、违法建筑、非法排污、围垦养殖。 如有问题输出JSON{\problem_type\:\...\,\location_desc\:\...\, \severity\:\high/medium/low\,\advice\:\...\}。 如果没有问题输出{\problem_type\:\none\}。 ) } ], } ], max_tokens512, temperature0.1, ) return response.choices[0].message.content这段代码走的是本地推理服务的 OpenAI 兼容接口。temperature0.1是为了让识别输出尽量稳定避免同一张照片每次返回不同类型。max_tokens512对结构化输出足够输出太长反而容易出现格式断裂。实际部署时建议对返回的 JSON 做一次二次校验解析失败就降级到人工标注队列不要直接丢弃。2.3 知识库检索RAG比微调先到位河长业务里有大量需要“查一下”的场景某段河道属于哪个社区管辖、某类涉河建设项目需要什么审批材料、去年某段河道的督办件整改结果。这些知识散落在“一河一策”文档、水法规、历史工单和巡查台账里。微调能解决术语理解和输出风格问题但解决不了“知识更新”的问题。水法规更新、行政区划调整、考核细则每年都在变微调一次的成本和周期都不小。RAG 的优势在于知识以文档形式进向量库更新文档就更新了知识而且回答时可以附上来源文件便于追责和复核。文本切分策略直接决定检索质量。河湖文档经常是条款式和段落式混排按固定字数切会把一条完整规定切成两半。我一般会先把文档按章、条、款层级拆成语义块再对超过 500 字的块做重叠切分重叠长度设 50~100 字。这样既保留了条款完整性又不会因为块过大超出 embedding 模型的输入上限。2.4 生成式报告把调度会前的人工汇总交给大模型县级河长办每月要出巡河通报、问题整改台账、水质变化分析。这些报告 80% 的内容是固定模板加数据替换但数据要从四五个系统里导出来再手工填。大模型做这件事的价值在于把数据查询、指标解读、段落生成串成一个流程。报告生成前先把结构化查询结果拿回来比如问题总数、已整改数、逾期数、各类问题占比。大模型只负责把这些数字翻译成符合公文习惯的句子。注意不要在提示词里让模型自己“编数字”数字必须由外部查询注入模型只做润色和编排。3. 用 RAG 给河长搭一个本地知识库文档解析到问答跑通3.1 数据准备一河一策、法规与历史工单从哪来知识库的构建数据源至少要覆盖四类一是“一河一策”方案每条河一份包含河流概况、问题清单、治理目标二是水法律法规和地方法规重点是涉河建设项目审批、排污口管理相关条款三是历史巡河工单选近两年已办结的去掉身份证号、手机号等个人信息四是水质监测月报按监测断面组织。这四类数据的格式差异很大PDF、Word、Excel、图片扫描件都有。前期数据清洗工作往往比模型选型更耗时建议在方案里单列一版“数据治理工作计划”明确每一类文档的归口单位、更新频率和质检责任人。3.2 文档解析与切分的工程细节PDF 解析建议优先用支持布局分析的解析库保留标题层级和表格结构。扫描件要先过 OCR中文识别质量直接决定后续切分效果。表格类数据不要直接转成纯文本尽量转成 Markdown 表格或 JSON否则检索时一问到“某断面某月氨氮浓度”向量检索很难把对应行捞出来。切分后的每个片段要保留元数据至少包括来源文档名、章节路径、页码、更新日期。这些字段在回答时用来生成引用标注没有来源的回答在政务场景里没有说服力。3.3 Embedding 与向量库选型中文河湖文档里大量出现专业术语、地名和法规名称embedding 模型要选中文效果好的。目前常用的是 BGE 系列或 M3E 系列按 1024 维向量入库。向量库选型上数据量在百万级以下用轻量方案就够不必一上来就上分布式集群。向量库适合场景运维成本备注Chroma原型验证低单机文件型适合演示Milvus生产环境中支持标量过滤与向量混合检索Elasticsearch knn已有ES的团队中统一日志与知识库检索栈3.4 从查询到回答打通 RAG 完整链路搭好向量库后查询链路分四步改写问题、检索片段、拼接上下文、生成回答。如果用户问“滨江路那段河为啥上周督办逾期了”直接拿这句话去向量库检索效果一般。先把问题里的地点和实体抽取出来改写成一个更利于检索的语句比如“滨江路段河道 督办 逾期 原因”检索命中率会高不少。def rag_query(question: str, top_k: int 5) - str: # 1. 生成问题向量 q_vec embed_model.encode(question, normalize_embeddingsTrue) # 2. 向量检索返回 top_k 个相关片段 hits vector_db.search(q_vec, top_ktop_k) contexts [] for hit in hits: contexts.append({ text: hit.payload[text], source: hit.payload.get(source_doc, ), page: hit.payload.get(page, 0), score: round(hit.score, 4) }) # 3. 拼接上下文 context_text \n\n.join([c[text] for c in contexts]) # 4. 调用LLM生成带引用的回答 prompt f你是河长制业务助手。请基于以下资料回答问题。 资料中没有的信息明确说\资料中未找到\不要推测。 [资料] {context_text} [问题] {question} 回答时在每条信息后用[来源: 文档名-页码]标注。 return llm_generate(prompt)top_k5是起始值实际调优时要看回答效果检索片段太少找不到答案太多会稀释有效信息。打分阈值建议设 0.35 左右低于阈值的片段宁可不给模型也不要硬塞进去。回答时强制要求标注来源这件事要在提示词里反复强调并保留一个“资料中未找到”的选项防止模型编造。4. 巡河工单的智能分类与结构化输出让一线汇报可直接入库4.1 从口语化巡河描述到结构化工单字段一线巡河人员上报的内容通常是“xx桥下面好多垃圾袋”“河水颜色不对有点发黑”“有人在河边倒建筑垃圾”这类口语化描述。直接存进工单系统后续做统计分析几乎不可能因为问题类型、位置、严重程度都埋在自然语言里。用大模型做结构化抽取相当于在录入环节加一道转换。关键是要把输出格式锁死让后续流程只认这个格式。{ problem_type: 乱堆垃圾, location: { description: 滨江东路桥下东侧河滩, river_name: 清源河, coordinates: {lat: 31.2304, lng: 121.4737} }, severity: high, evidence: [垃圾袋沿河岸散布约20米, 河滩有明显堆积], suggested_action: 通知属地街道安排保洁员清理并排查周边监控溯源倾倒源头, deadline_suggestion: 24小时内 }提示词里要给出这个 JSON 格式的示例和字段说明并要求模型只输出 JSON不要输出解释性文字。实际跑下来会发现两个问题一是坐标经常缺失因为照片 EXIF 信息不全或巡河员没开定位二是问题类型容易把“乱堆”和“乱倒”搞混。解决方法是把问题类型枚举值写死在提示词里并给每个枚举值配一个典型示例。4.2 本地部署的推理服务并发与延迟怎么定智慧河长方案的落地形态多数是政府内网私有化部署数据不出域是硬约束。本地跑大模型推理常见方案有两种轻量用 Ollama 起服务生产用 vLLM 做高并发。Ollama 适合试点阶段一条命令就能把模型拉起来ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct做方案验证没问题但生产环境就力不从心。vLLM 的 PagedAttention 机制显存利用率更高连续多轮请求吞吐明显好于原生推理框架。启动命令里几个参数要重点调python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-14b-instruct-awq \ --served-model-name river-llm \ --max-model-len 8192 \ --max-num-seqs 32 \ --gpu-memory-utilization 0.9 \ --quantization awqmax-model-len决定了上下文窗口有多长业务上工单分类给 2048 就够报告生成给到 8192 更稳。max-num-seqs控制并发请求数默认值往往偏保守对 7B 模型在 24GB 显存上开到 32 并不会 OOM。gpu-memory-utilization设 0.9 是经验值留出一点显存给 CUDA 上下文和临时张量。4.3 识别结果对不回坐标时怎么办结构化输出的坐标缺失率高是落地时被问得最多的点。常见做法是加一层地理编码兜底把“滨江东路桥下”这样的地点描述交给地理编码服务转成坐标。如果地理编码也失败就退回乡镇/街道粒度至少保证工单能派到属地而不是卡在录入环节。5. Agent 工作流从发现问题到生成处置建议的完整链路5.1 巡河工单怎么走通“识别-检索-建议-分派”全流程单点的大模型能力要真正减轻基层负担必须串成工作流。一次完整的智能处置链路是这样的巡河照片/语音进入系统语音先转文字照片走多模态识别文本描述与识别结果合并进 LLM 做工单结构化结构化字段触发规则引擎问题类型 位置 严重程度LLM 根据知识库检索历史同类工单处置方案生成处置建议工单写入业务系统按属地自动分派这条链路里大模型承担了三处工作结构化抽取、处置建议生成、必要时生成给上级的汇报摘要。规则引擎负责做硬约束比如“饮用水水源保护区内的问题自动标记为 high severity”这类判断不能交给大模型自由发挥。5.2 工具调用让模型读水质数据、查地图边界Agent 要会“用工具”而不是凭训练时的记忆回答问题。比如问“清源河最近三个月氨氮趋势怎么样”大模型必须去调水质数据库接口而不是自己编一串数字。def query_water_quality(river_name: str, months: int 3) - dict: # 调用内部水质监测平台的 HTTP 接口 endpoint http://10.20.30.40:8080/api/water-quality/trend params {river: river_name, months: months} resp requests.get(endpoint, paramsparams, timeout5) resp.raise_for_status() return resp.json() # Agent 注册工具 tools [ { type: function, function: { name: query_water_quality, description: 查询指定河流近N个月的水质指标趋势, parameters: { type: object, properties: { river_name: {type: string, description: 河流名称}, months: {type: integer, description: 查询月份数} }, required: [river_name] } } } ]工具调用要限定白名单不能让模型任意发 HTTP 请求。每个工具接口都要做超时控制水质平台接口慢的时候模型等不了 30 秒。实际工程里建议把 Agent 的思考过程输出到日志里方便定位是哪一步出了问题是检索没召回、工具调用失败还是生成阶段格式坏了。6. 效果验证让大模型输出从“能聊”到“能考核”6.1 用历史工单做回归测试集方案评审时最怕被问“准确率多少”。这个数字不能靠演示时的几个案例说明要从历史数据里抽一套稳定的测试集。做法是抽取近一年已办结的 500 条工单人工标注问题类型、位置、严重程度再拿这套标注数据跑模型算结构化输出的字段准确率。测试集要与模型训练数据隔离。如果微调过模型这 500 条不能混进训练集否则测试分数虚高部署到真实场景立刻露馅。6.2 评测指标分三级格式合规率、要素完整率、处置建议采纳率格式合规率是硬门槛要求输出能被 JSON parser 直接解析这条不达标后面都谈不上。要素完整率看位置、时间、类型、严重程度四个核心字段是否齐全。处置建议采纳率需要业务侧配合把模型生成的建议给审核人员打标统计“可直接采纳”“需修改”“不可用”的比例。前两个指标上线一周就能跑出来第三个指标至少要跑一个月才有统计意义。6.3 提示词版本管理与 A/B 测试提示词也是代码要进 Git。每个版本的提示词改动都要先在 6.1 的测试集上跑一遍记录三项指标的变化。灰度发布时按工单来源分流比如某两个乡镇先用新版本对比旧版本的关键指标数据足够后再全量切换。这套做法不复杂但能把大模型能力从“演示”推进到“业务系统的一部分”。本文还有配套的精品资源点击获取