矿山大模型落地实践：从智能问答到辅助决策

今年下井调研的时候有位调度主任跟我讲了一句话我一直记着——“软件上了一堆真正常用的没三个。”这就是矿山智能化最真实的处境。井下千米的AI矿山大模型听起来像概念包装但它解决的恰恰是“系统不会说话、知识沉在老师傅脑子里、决策靠经验拍板”这几个老大难问题。我想以自己参与过的项目经历把这几年做矿山大模型落地的东西整理出来。不会讲太多学术名词重点说清楚为什么矿业需要大模型、通用大模型为什么在井下不适用、落地过程中最难的不是算法而是什么。如果你在矿业信息化、智能化部门工作或者你所在的行业正准备上大模型这篇内容可以当一份“避坑手册”来看。1. 为什么矿山需要大模型井下千米的真实困境1.1 矿山数字化到智能化的断层很多人以为矿山已经很智能了毕竟井下有传感器、有摄像头、有自动化采煤机各种系统上了几十套。真正待过现场的都知道自动化系统和人的决策之间有一条巨大的断层传感器把数据采上来了但数据是“死”的没有人看监控大屏上几百个报警调度员根本处理不过来现场出现异常还是要打电话找老师傅问经验。这套模式的症结在于数据在系统里知识在人脑里。系统只会按预设逻辑报警既不会解释“为什么会这样”也不会给出“接下来该怎么做”。一条设备故障从发生到处置中间隔着电话沟通、翻规程、查台账等把问题搞清楚半小时已经过去了。井下生产是一环扣一环的半小时的停机损失非常大。1.2 井下场景对AI的三个特殊约束在矿山做AI跟在城市做AI完全是两回事。第一个约束是安全等级高。煤矿是高危行业井下任何一条结论都要严谨出错了不是多花点钱的问题是可能出人命的事故。这决定了我们不能像普通客服机器人那样回复内容有点偏差无所谓。第二个约束是网络环境差。井下虽然有环网和5G基站但信号盲区依然存在设备震动、粉尘、电磁干扰都会影响网络质量。如果模型推理完全依赖云端接口网络一抖动井下就“断脑”了。第三个约束是知识高度专业化。矿井的术语体系外人根本看不懂“瓦斯抽采”“煤壁片帮”“顶板离层”“隅角”这些词通用大模型根本理解不了没有领域知识加持问十个问题错八个。这也是我坚持认为通用大模型直接部署到矿山行不通的原因不是模型不够强是它不懂这个行业。1.3 矿山大模型的本质把“老师傅经验”变成组织能力那大模型在矿山到底起什么作用我个人理解本质上它是在做知识的整合与复用。矿山最宝贵的资产除了矿产资源还有一批干了二三十年的老师傅他们脑子里装着各种异常情况的判断和处理方式。经验越多的老师傅越难约谈、越难复制更麻烦的是随着他们退休这些经验就跟着流失了。矿山大模型要做的就是把操作规程、历史工单、调度记录、设备手册这些散落在各处的知识和老师傅口头传下来的处置经验统一“装”进一个系统里。工人遇到问题直接问模型基于规程和经验给出带依据的回答。这一下就把“人找知识”变成了“知识找人”——用接近自然语言的方式把原来翻手册、问老师傅才能得到的答案直接送过来。2. 技术底座与方案选型不是把通用大模型搬下井2.1 矿山大模型和通用大模型的差异市面上热门的大模型产品什么都会聊但拿到矿上就失灵。通用大模型的训练数据主要来自互联网公开内容工业领域的知识覆盖少煤矿相关的就更少。你用通用模型问“采煤机摇臂异响可能是什么原因”它大概率给你一个极其空泛的回答甚至编造一个不存在的部件名称。这在矿山场景是绝对不能接受的。所以矿山大模型要做领域化的“降维”。参数规模和通用模型不在一个量级但专业性要强得多。它不需要跟你聊文学历史只需要把“液压支架压力异常时如何分析”“皮带跑偏后的处置流程”这类问题答得又准又稳。换句话说通用大模型追求的是“通”矿山大模型追求的是“精”。2.2 方案选型开源底座领域微调私有化部署技术路线我们最终选了“开源底座领域微调私有化部署”的组合这个选择背后有一条很现实的理由数据不能出矿。矿业集团的核心生产数据属于敏感信息不可能直接传到公共大模型的服务商那里做分析必须把模型部署在自己的机房里面。底座选择上用的是国内可获取的开源基座模型参数规模不需要最大但中文理解能力和指令跟随能力要好。拿到底座之后最关键的一步是领域微调。我们用矿山相关语料对模型进行训练让它学会行业术语、理解上下文语义。具体用的是参数高效微调的方式业内常用的LoRA可以在有限算力下实现效果提升。微调数据里除了规程文档还把历史工单里的“故障现象-原因分析-处置办法”做了结构化抽取让模型形成“遇到问题先找原因再给方案”的推理习惯。部署上采用私有化方式模型文件全部放在矿业集团的灾备机房终端通过内网访问。这样做的好处是安全合规数据不出内网满足矿业行业的数据管控要求。2.3 算力与网络井上训练、井下推理大模型的训练和推理是两种不同的算力需求。训练阶段要把海量语料“喂”给模型算力消耗大这部分放在井上的数据中心做买一两台带高性能显卡的服务器就够了配置不用追求顶配够训练就行。真正需要精心设计的是“井下推理”这个环节。网络抖动是常态所以我们采用了“井上中心节点井下边缘节点”的混合架构。日常简单问题直接由井下防爆边缘计算盒来处理模型是剪过枝、量化过的轻量版本复杂问题通过井下5G专网转发到井上服务器做完整推理。这不是技术上的炫技而是做了断网演练之后得出的教训地面到井下的链路一断如果所有请求都发不上去现场就会直接“停摆”。边缘节点伴随式的推理把最关键的应急问答兜住了。3. 三类核心场景的落地细节与实操步骤3.1 智能问答助手让大模型读懂矿山规程智能问答是矿山大模型最容易出效果的场景因为它解决的问题足够痛一线工人遇到异常翻操作规程找不到、打电话问人未必有人接、而处置时间窗口又很短。构建这个场景核心不是训练模型而是做知识库。我们把矿上的操作规程、作业规程、应急预案、设备说明书整理成结构化的知识库。这里有个操作细节文档直接扔给模型去读是不行的必须做切片处理再把切片向量化存入向量数据库。遇到用户提问时先在知识库里检索最相关的片段再让模型基于检索结果生成回答这个流程在业界叫检索增强生成。给你一组我们踩过坑之后定下来的实践参数文档切片长度控制在300到500个字符之间重叠区间保留50字符左右切片时优先按章节标题做切分避免把两个不相关的主题硬拼到一个切片里检索结果取前5到8条并做重排把最相关的排到前面模型回答时必须引用知识来源的编号方便工人点击查看原文。同时我们对模型做了“在不知道的时候承认不知道”的训练约束。涉及安全问题的回答宁可说“该问题需要向调度室确认”也不能编一个处置步骤出来。这一点在安全要求高的行业非常关键模型“幻觉”在这里是不可接受的。3.2 设备告警与运维分析从“看得见”到“看得懂”矿山自动化程度越高告警就越多。一个中型矿井传感器和摄像头成千上万每天产生几百条告警调度室里十个大屏都刷不过来。传统的视觉算法只能告诉你“这里有异物”大模型的价值在于让系统“看得懂”。以皮带异物识别为例视觉检测模型先定位到皮带上有一块大矸石这个盒子框出来下一步把它传给大模型模型结合当天生产记录和皮带运行参数推理出“当前煤量偏大、矸石含量高可能与工作面地质条件变化有关”再自动生成一条处置建议减少给煤量、通知采煤机司机调整截割深度。这就把视觉识别从“报警工具”升级成了“辅助决策工具”。实操中最重要的一步是把多路数据串联起来。关键点如下视觉模型输出结果先“文本化”即把检测到的事件转成一句标准描述大模型再将这句话与设备运行参数、历史工单记录进行关联分析输出的建议必须带置信度等级高置信度的直接推送给当班人员低置信度的进入待审核队列。这套流程跑通后调度员面对的不再是几百条冷冰冰的告警而是几条有来龙去脉、有处置建议的事件描述工作量至少降了一个数量级。3.3 报表台账自动生成帮一线减负这个场景最初没在我们计划里是一线班组长提的需求。他们每天下班后要花一个多小时填班报把当班产量、设备运行时长、故障记录、隐患排查情况一项项敲进电脑。填错一个数字还要被考核工人压力很大。大模型在这里做的事情非常朴素工人用语音或文字口述当班情况模型自动将其整理成结构化班报并把涉及异常的内容单独提取出来生成注意事项。比如工人说“二班皮带停了半小时好像有异响电工查了说是托辊坏了换了新的”大模型就能自动生成一条班报记录故障设备、故障类型、处置方式、影响时长一条不漏。这个场景的技术门槛不高但价值极其直观。报表时间从每小时压缩到几分钟工人的接受度非常高。这也让我意识到大模型在矿山的落地不一定非要一上来就搞“智能决策”先帮一线省时间反而更容易推进。4. 数据治理与组织保障真正的隐形工程4.1 数据从哪来、怎么清洗想把大模型在矿山落地数据是绕不开的坎。我们当时调研发现矿业集团的数据状况比想象中还要乱一些不同年代的文档格式五花八门有扫描版的PDF需要用OCR识别成文字有手写的交接班记录需要人工录入有Excel表格但字段名混乱同一指标在三个表格里叫三种名字。如果把这样的数据直接喂给模型结果可想而知。我们的清洗流程大概分四步走。第一步是格式统一把所有文档转成标准文本格式第二步是OCR识别扫描件并做人工复核这一步尤其耗时间但必须做第三步是术语对齐建立矿山领域词表把“皮带”和“带式输送机”这类同义词统一第四步是质量抽检随机抽取一批数据进行人工打分准确率没过95%就返工清洗。数据量其实不需要特别大我们最终使用的有效语料也就几万份文档但每一份都经过了清洗和标注质量比数量重要得多。4.2 用指标把“靠谱”定义清楚模型做出来之后怎么判断它“靠谱”不“靠谱”不能靠感觉要把评估指标定清楚。我们当时建了一套评估集里面放了来自真实生产场景的三千多道测试题覆盖规程问答、故障分析、报表生成等场景。每道题都有标准答案或人工评分标准。核心指标我们看四个。第一是回答准确率测试集上模型输出的内容与标准答案一致的占比目标定在85%以上第二是知识检索命中率判断模型在作答时是否真正引用了知识库中的相关内容防止它“瞎编”第三是安全合规率凡是涉及安全操作的问题模型给出的建议必须与规程一致这条是一票否决项不达标就不能上线第四是响应时间边缘节点上的回答时间控制在5秒以内让井下的工人觉得“够快”。4.3 IT、OT与业务三方协同才走得动这是个容易踩坑的点。一开始我们把项目当成一个纯信息化项目来做开发团队闷头做产品做完了拿给矿方看对方反馈是“这东西看着挺好但跟我们的实际流程对不上”。后来才明白矿山大模型这种项目IT团队、OT团队自动化控制团队和业务部门必须从一开始就绑在一起。具体协作方式上我们建立了一个跨部门的小组每两周开一次评审会。调度室主任负责提真实业务问题电气工程师负责解释设备数据结构模型团队负责把问题转化为训练样本。只有业务侧愿意把一线的“真问题”抛出来模型才能学到真正有价值的知识。这个环节没人能偷懒没有业务侧深度参与做出来的东西必然是空中楼阁。5. 井下部署的踩坑记录与问题排查实录5.1 网络抖动让模型“答非所问”第一次井下试运行时我们遇到了一个尴尬的问题井下工人上午提问还正常下午网络波动明显的时候模型回答的延迟一下从2秒飙到了20秒有些问题直接返回超时。更麻烦的是偶发性的网络重传会导致模型收到残缺的提问答出来的内容让人摸不着头脑。排查后发现问题出在井下基站切换时存在丢包TCP连接大量重连。我们的解决方案是双管齐下一是把轻量化模型部署到井下边缘节点常见问题直接本地推理不走网络二是为在线推理增加超时降级逻辑一旦检测到网络超过3秒没有响应系统自动切换到边缘节点保证“永远有回应”。这样做之后工人感知到的响应时间就基本稳定了。5.2 告警误报多阈值怎么设才不“狼来了”告警场景上线两周后我们接到了调度室的投诉——“模型报得太勤了像狼来了大家已经开始不当回事了”。原因是我们为了追求“不遗漏”把告警触发阈值调得过低加上大模型推理时存在不确定性导致每天产生大量低价值告警。为了控制误报率我们做了三件事。第一对告警事件按置信度分级只有高置信度事件才自动推送给值班人员中低置信度只记录不提醒第二给模型输出增加“上下文一致性校验”把当前告警和历史数据做比对如果这条告警与上下文矛盾就暂时压住不推送第三建立人工反馈机制每条告警下面放“有效/无效”按钮每周根据反馈调整模型参数。迭代三周之后有效告警率从不足20%提升到了70%以上。5.3 知识库更新不及时模型还在说旧规程这个坑坑得很惨。矿上更新了一版操作规程修改了瓦斯传感器的安装位置和报警阈值但我们没及时同步知识库结果有工人问相关问题模型还按旧规程回答。幸好这类问题被安全员抽查发现否则后果难以想象。从那以后我们给知识库同步加上了强制流程所有规程类文档的更新必须走版本管理新文档审批通过后自动触发知识库重建同时在系统里置顶“版本更新公告”一周。安全相关的问题回答时模型还会在旁边附一句“该回答基于XXXX版操作规程如有疑问请与安全管理部门确认”。这个问题解决之后团队的心里才踏实了一些。5.4 一线工人不用交互设计才是突破口项目刚上线那阵子使用率很低。后来去现场蹲点才发现问题很简单井下工人大多戴着厚厚的防护手套用键盘打字根本不现实屏幕在粉尘环境下也不方便操作。你让工人去电脑上敲一行字提问这个流程本身就违背了使用习惯。我们后来把交互方式改成了语音为主、拍照为辅。工人拿着防爆手机或者手持终端对着设备拍张照片再说一句“这什么情况”系统就能识别设备状态并给出分析。语音识别在井下噪音环境下做了专门的降噪处理识别率实测下来可以到90%以上。改完交互之后工人开始愿意用了尤其是年轻工人把这个当成了“随身专家”。6. 效果评估与后续演进从单点助手到辅助决策6.1 科学设定评估指标项目上线一个季度后我们做了一次阶段性复盘评估不能只看技术指标更要看业务效果。我们围绕四条线来算账问答服务的覆盖率和使用频次、告警处置的时效、报表填写的耗时、安全违规事件的趋势。拿具体数据来说智能问答上线三个月累计被调用超过两万次高频问题集中在“设备故障处理”和“操作规程确认”两类告警处置时间从平均半小时压缩到10分钟以内报表填写时间从每班一个半小时压缩到20分钟。安全指标变化短时间内还看不出来需要拉长时间线观察但至少调度员和一线班组长都反馈“值班轻松了”。这些数字不夸张但它们足够说明问题矿山大模型的商业价值不是画出来的饼是能在生产数据里找到印证的。6.2 演进路径模块化落地逐步构筑智能体做这类项目我最大的心得是千万别想一口吃成胖子。我们的路径是先做知识问答再做告警分析再做报表生成每一步都是独立的业务价值不会因为某个环节失败就全盘推翻。后面计划中的方向是把大模型从“被动回答”升级为“主动提示”。比如当调度系统检测到某工作面瓦斯浓度持续上升时模型主动调取该区域最近的生产记录、通风数据生成一份风险研判摘要推送给值班人员而不是等人工去问。这就是“矿山智能体”的雏形了它不再是问答机器而是能够主动观察、分析、输出建议的辅助决策系统。基础设施齐备之后不同矿井的知识库也可以做成模板化复制把成熟经验快速推广到其他矿区。写在最后的一个建议做完整个项目我个人体会最深的一点是矿山大模型这事儿三分在模型七分在工程和数据。模型效果不好可以换底座、调参数但数据脏、业务不参与、交互反人类这些问题不解决模型再强也是白搭。最后再分享一个小技巧如果你想在矿业集团推动大模型落地不要从“智慧矿山”“数字化转型”这种大词开始讲直接选一个一线工人每天都要面对的小痛点比如报表填写费时费力做出一个能用的工具给他们试试。只要一线的人觉得“这东西确实省事”项目的阻力就小了大半。技术只能解决“能不能做”的问题真正决定“做不做得成”的是能不能让井下那些人真心愿意用起来。