简介这份PPT围绕能源行业数字化转型系统讲解如何依托数据底座与AI底座构建“云-边-端”三级架构并落地数据治理与大模型应用适合能源企业数字化负责人、数据治理工程师、AI解决方案架构师学习参考。资源为1个pptx文件压缩包约12.62MB图文结合呈现从产品体系、数据治理体系到矿山行业大模型应用的全景路径既包括数据标准、数据架构、数据质量、数据安全四大模块也涵盖大数据湖建设、12000个采集测点、1.5亿条日均入湖数据量等落地指标同时梳理视觉大模型、图网络、多模态、自然语言处理在防冲卸压、智能洗选、人员安全、掘进作业等场景的准确率与降本增效数据。目前已有69人浏览学习。通过研读可掌握能源行业数据治理方法论、矿山行业大模型案例框架理解从数据标准编制、质量规则沉淀到模型参数调优的端到端建设逻辑对规划同类项目、编写汇报方案或开展内部培训均有直接借鉴意义。1. 先从一张能源行业的数据治理地图说起把12000个平均采集测点、日均1.5亿条数据接到同一个湖仓再让几十个AI模型跑在统一底座上这个规模放在能源行业算顶配了。真正值得多看两眼的是它解决的核心问题并不是缺模型而是数据治理能力不足这个隐藏瓶颈数据孤岛、口径不统一、共享机制缺失导致再强的算法也找不到可用数据。把数据底座和AI底座拆开各自建设再通过“云-边-端”三级架构串联先治数、再上模型最终落到防冲卸压、人员安全、焦化配煤这类具体生产场景。这篇文章适合正在做智慧矿山、智慧化工或者集团级数据中台的工程师和架构师看完可以照着这套思路重新评估你们的数据链路和模型部署路径。2. 双底座与“云-边-端”三级架构数据底座和AI底座怎么分层能源行业做数据中台烟囱式建设是降本增效最大的敌人。原本每家矿、每个二级公司各搭一套平台分析应用挂一个、AI应用又挂一个底层IAAS各自买一遍数据模型各自建一遍最后指标口径对不上运维成本翻倍。材料里把这个问题总结得很直接能力重复建设、建设成本高、响应速度慢、体验不一致。拆成双底座后数据统一存储处理、共性能力集中建设数据底座提供全域数据“采存治用”能力AI底座提供全业务域智能化场景能力两边各自演进只通过标准接口交互。2.1 为什么一定要把“数据底座”和“AI底座”拆开data底座和AI底座看起来都离不开大数据平台不少团队会试图放成一套实际跑起来会发现两边的生命周期完全不同。数据底座处理的是存量数据的集成、标准化、质量和安全核心产出是干净可控且可追溯的数据资产AI底座处理的是样本、模型、推理和持续调优核心产出是面向具体场景的算法能力。强耦合的话模型每次更新都要动数据链路数据每次变更都要重新对齐算法系统复杂度会指数上升。拆开之后的两条线很清晰数据底座对AI底座只暴露数据集和数据服务AI底座对数据底座只回传模型推理结果和反馈标签。这样两边都能独立扩容模型迭代不会打断数据管线。材料里“数据底座 AI底座 1套数字化管控体系”的组织方式本质上就是把数据治理和人工智能应用做成两个可以独立演进的平台资产再靠管控体系把标准和流程统一起来。2.2 云-边-端三级架构的职责边界三级架构的划分有明确边界。集团侧是“云端”部署湖仓、数据治理平台、AI训练集群二级公司和生产单位侧是“边”每个生产单位构建一个边缘数据中心放置边缘计算平台、工业防火墙和采集网关再往下是“端”也就是采掘工作面系统、掘进系统、通风监控、安全监控、人员定位、双重预防管理等现场设备和工控系统。层级典型组件职责故障影响中心云湖仓、数据治理平台、AI训练集群全域数据汇聚、模型训练、数据服务开放数据补传与模型发布延迟边缘侧边缘计算平台、工业防火墙、采集网关实时采集、断点缓存、轻量推理局部监控降级生产不中断端侧采掘设备PLC、传感器、摄像仪原始信号与图像采集、执行控制单点数据缺失自动补采边缘侧是这套架构里最容易翻车的点。井下网络抖动是常态直接把数据推到中心不现实所以边缘采集网关必须带本地缓存和断点续传模型推理也要能在边缘独立跑起来不能一断网就全盲。材料里提到的“每个生产单位构建一个边缘数据中心”就是为了把时延控制在秒级以内同时减轻中心侧带宽压力。2.3 边缘采集网关配置与数据格式约定采集网关的配置决定了数据质量的下限。这里给出一个典型的边缘采集网关配置协议层覆盖OPC UA和Modbus TCP输出走Kafka的JSON Lines格式。gateway: site_id: mine-1203 protocol: - opcua - modbus_tcp tags: - name: drill_depth_12 address: 1/3/40001 type: float32 sampling_interval_ms: 5000 - name: person_zone_count address: 2/5/10002 type: int32 sampling_interval_ms: 1000 security: industrial_firewall: true acl: - *.oee.sensor - *.sic output: broker: kafka://cn-edge.emqtt.internal:9092 topic_prefix: raw/mine/physical format: json_lines persist_on_offline: local_buffer_4hsampling_interval_ms决定了测点采集频率一般工艺参数设5秒已足够人员定位这种变化快的设1秒。persist_on_offline建议至少4小时井下故障恢复时间通常以小时计缓存不够会直接丢数据。topic_prefix建议带上站点和数据类型方便后续按“一数一源”做数据责任划分。现场实施时还要注意视频流不要走采集网关要单独走边缘存储12000个测点下文本类数据每秒新增量并不大但一路1080P视频动辄4Mbps以上混在一起会把Kafka集群打挂。3. 数据湖建设与数据治理实施标准、质量、血缘缺一不可数据底座的落地不能只靠一套大数据平台材料里给出的路径是建设数据湖、建设采集实施、实施数据治理三步走核心是形成“采存治用”数据治理体系。数据湖基于湖仓一体化架构建设向上能为应用提供数据支撑向下能整合各类数据源。这个阶段最容易犯的错是一上来就追求数据大而全结果花了三个月接入几十套系统真正能被模型使用的数据集却没几个。正确做法是先把标准和质量规则定义好再倒推需要接哪些数据。3.1 湖仓一体下的数据资产汇集湖仓一体的关键不是“湖”或“仓”选哪个而是让同一份数据能同时支持批处理和实时计算。材料里覆盖了集团统建系统和外部数据的采集入湖包含生产矿井安全生产类数据的全覆盖最终实现“一数一源”。实施时我一般会从三个维度评估数据源类型、数据时效要求、数据质量成熟度。经营管理类数据如财务、物资时效要求不高走T1批处理安全监控类和人员定位类数据必须秒级延迟走Kafka实时链路。数据入湖之后的组织方式也值得推敲。材料里做了数据盘点900余项数据指标、32个主题域组、177个主题域、1109个业务对象、741个数据实体、8694个数据属性、140余个数据资源目录。这组数字说明治理工作不是停在标准文档而是真正把业务对象拆到了属性级。业务对象和属性能对得上数据模型才能真正被后续的数据应用复用。3.2 数据标准体系如何落到业务对象标准体系是一层层堆出来的。材料里提到参与编制行业标准28项建立能源集团数据标准体系形成基础类标准10项、对象类标准3项、架构类2项、作业类4项加上数据分级定级、数据安全、数据共享要求等专项规范。标准类别数量包含内容示例基础类10井工煤矿数据分类及编码规范、通信接口与协议规范对象类3数据架构规范、主数据规范架构类2数据存储技术规范、数据共享基本要求作业类4数据质量管理规范、数据安全规范行业专项28露天矿山车辆数据共享、矿用5G智能终端数据共享等这些标准的落地要避免两个偏差。第一是只做文档不做映射标准写了但数据模型里没体现等于白做第二是只做映射不落库标准与物理表字段对不上。实施时我会把标准编号直接写进数据字典的扩展属性里让每一个字段都能追溯其标准来源后续做合规审计和数据质量评估会省很多时间。3.3 数据质量规则与血缘可视化落地材料中沉淀了70余类数据质量规则完成619个数据质量评估输出63对矿井数据质量报告。质量规则不是越多越好而是要和业务风险挂钩。井下人员定位数据缺测直接影响安全监控预警这类规则必须优先实现。以人员定位数据的连续性检查为例一个可用的质量规则SQL如下-- 井下人员定位连续性检查 WITH raw AS ( SELECT person_id, ts, zone_id FROM kafka.people_position_raw WHERE ts now() - interval 5 MINUTE ), summary AS ( SELECT person_id, count(1) AS sample_cnt FROM raw WHERE zone_id IS NOT NULL GROUP BY person_id ) SELECT person_id, sample_cnt FROM summary WHERE sample_cnt 3;这个SQL解决的是“定位数据是否连续”的问题。一个人若5分钟内有效定位样本少于3次基本可以判断为信号丢失或设备异常。其中kafka.people_position_raw是流表interval 5 MINUTE是时间窗口zone_id IS NOT NULL用于剔除无效数据。规则跑出问题后要能顺着数据链路往回查落到具体是哪个采集网关、哪个传感器出了问题。血缘关系是实现“回查”的基础设施通常在数据开发平台里自动生成。这里给出一个解析SQL血缘的最小Python示例便于理解血缘节点如何构建。import re def extract_lineage(sql: str) - dict: target re.search(rinsert\sinto\s(\w), sql, re.I).group(1) sources set(re.findall(r(?:from|join)\s(\w), sql, re.I)) return {target: target, sources: sorted(sources)} sql insert into dws_mine_person select a.person_id, b.mine_name from dwd_mine_person a join dim_mine b on a.mine_id b.mine_id print(extract_lineage(sql))extract_lineage从SQL文本中提取目标表和源表在真实平台上血缘会沿抽取、清洗、标准化、主题建模、应用数据集逐层传递。有了血缘数据质量告警才能从结果指标一路反查到原始测点这也是材料里“数据血缘可视化展示可查看数据从接入到应用的全链路”的实际含义。4. 视觉大模型与多模态推理的部署骨架能源行业的大模型应用最成熟的方向不是文本对话而是视觉和多模态。材料里的做法很明确视觉大模型技术就是“用摄像仪替代人眼”针对煤矿已有的视频监控按每个摄像仪的功能需求部署不同算法模型做分级预警和联动控制。这背后需要的不是一套通用的图像识别系统而是基于行业预训练模型架构的视觉大模型、图网络和多模态融合技术栈。4.1 从视频监控到视觉大模型的改造路径煤矿视频监控的特点是“装得多、看得少”大量摄像头只是被动记录没有形成主动预警能力。改造时先做场景梳理把摄像仪分为安全管理、岗位人员、巡检人员三类角色。比如转载机入料口卡堵识别解决的是溜煤眼堵塞导致的生产中断危险区域人员入侵检测解决的是人员违章进入高风险区域防冲卸压工程打钻深度监管则要求模型结合视频帧和工艺参数判断钻孔深度是否达标。这个改造过程中模型输出不能只报“有风险”或“无风险”要直接对接现场控制系统。材料里提到“分级预警及联动控制”落地时一般分三步第一步算法输出结构化结果比如目标框和置信度第二步规则引擎判断风险等级决定是弹窗提醒还是联动广播喊话第三步将结果发给PLC执行停机和闭锁动作。这一步的延迟和数据可靠性决定了系统能否真正下放到生产现场。4.2 本地部署大模型vLLM配置与参数说明视觉大模型在煤矿场景基本不可能用公有云API数据主权和网络条件都不允许。本地部署是常规选择。对于视觉语言类的7B模型vLLM是目前工程上比较稳的推理框架之一显存利用率和吞吐都比原生HuggingFace实现高不少。from vllm import LLM, SamplingParams llm LLM( model/models/mine_energy_vlm_7b, tensor_parallel_size2, gpu_memory_utilization0.85, dtypebfloat16, trust_remote_codeTrue, ) params SamplingParams( temperature0.1, top_p0.85, max_tokens128, ) prompts [ 请判断画面中转载机入料口是否存在卡堵风险只回答风险等级和依据。, 请检测回采面危险区域是否有人入侵只回答有或无。, ] out llm.generate(prompts, params) for r in out: print(r.outputs[0].text)tensor_parallel_size2表示将模型切到2张GPU上并行推理适合单卡显存放不下整个模型的情况。gpu_memory_utilization0.85预留了15%显存给推理过程中的临时张量避免OOM。dtypebfloat16在A100或H800这类卡上能稳定降低显存占用。temperature0.1和top_p0.85组合是为了让输出尽量确定安全告警场景不需要创造性每句话都应该是可复现的。这里最容易被忽略的是max_tokens128安全场景的输出必须短直接输出结构化的风险等级和依据不要开放性的长文本。4.3 多模态场景选型与效果对比不同场景对模型形态的要求不一样。材料里的数据可以整理成一张选型参考表直接对接场景和准确率指标。场景模型类型指标说明转载机入料口卡堵识别视觉检测模型准确率95%基于边缘视频流检测卡堵并联动控制系统危险区域人员入侵视觉定位数据融合识别率95%与井下人员定位数据交叉验证防冲卸压打钻深度多模态融合模型准确率90%结合视频图像和钻机工艺参数焦化配煤质量预测机理模型机器学习准确率95%融合煤质检验和工况数据多模态场景的核心不是把视频和文本拼在一起做输入而是要让不同模态的数据在时间轴上对齐。比如打钻深度监管视频显示钻杆推进位置工艺参数表显示当前压力两者必须按同一个时间基准打点。实际部署中我一般会在边缘侧先做一层时间对齐处理把视频抽帧和传感器数据写入同一份HDF5或Parquet文件中再送入模型训练或推理。这个预处理步骤比模型本身更容易被忽略也更容易出问题。5. 焦化配煤与工艺优化把Excel经验变成可求解的模型问题材料里焦化配煤智能应用这一段是整个PPT中最贴近“大模型值多少钱”的场景。传统焦化配煤依赖专家经验用Excel算配比取值保守成本偏高而且无法回溯验证。改成AI方案后配合煤每吨成本降低3到5元焦炭质量预测准确率超过95%耗时从原来的“天级小焦炉实验”缩短到分钟级。这个场景的改造思路非常清晰先数据化再模型化最后优化下发。5.1 从专家经验到数据模型的转变传统配煤的问题有三层一是依赖老师傅经验配比是否最优没人能证明二是Excel只能线性估算但焦炭质量与煤质参数之间不是简单的线性关系三是过程不可追溯同样的原料参数变化后很难解释为什么配比变了。AI应用要解决的就是这三点。模型化之后输入数据包括原煤检验数据、焦炭检验数据、生产过程数据输出是配比方案和焦炭质量预测。材料里提到的“模型训练、调优”和“数据工程”阶段前置工作比模型本身更琐碎需要处理不同煤种的工业分析指标、煤岩数据、单种煤炼焦数据以及焦炉的温度和结焦时间。这几个特征维度来自不同系统时间粒度也不一致典型的数据工程问题。5.2 特征工程与数据准备配煤模型的特征工程有两个关键点第一是特征对齐不同煤种同一批次的数据要按“入炉时间煤仓号”对齐才能反映真实配比第二是小样本处理单个焦化厂可用批次数据往往只有几百条直接训练深度模型很容易过拟合。工业实践上会用机理模型先算一遍理论焦炭质量再把机理模型结果作为特征输入机器学习模型构成“机理数据”混合建模材料里对应“基于配煤机理自动学习复杂参数”。特征类型典型字段数据来源煤质数据灰分Ad、硫St、挥发分Vdaf原煤检验系统煤岩数据反射率、显微组分煤质化验室单种煤炼焦数据焦炭强度CSR、CRI小焦炉实验数据工况数据焦炉温度、结焦时间生产执行系统MES特征构建完成后数据标准化、缺失值填充和异常值剔除都要按批次做。这里有个容易踩的坑不要把不同煤种的数据混在一起做归一化因为不同煤种的灰分分布范围差异明显混在一起会抹掉煤种间的区分度。正确做法是按煤种分组标准化或者直接用原始值加煤种ID做类别特征。5.3 配比优化与下发线性规划示例配比优化本质是一个带约束的线性规划问题。目标函数是配煤成本最小化约束是焦炭质量指标必须落在工艺允许范围内。以下是使用PuLP求解的可运行示例import pulp as pl coal_spec { 肥煤: {cost: 920, ash: 10.2, sulfur: 0.50}, 焦煤: {cost: 980, ash: 8.8, sulfur: 0.65}, 瘦煤: {cost: 780, ash: 11.0, sulfur: 0.40}, 气煤: {cost: 850, ash: 9.5, sulfur: 0.45}, } prob pl.LpProblem(coke_blend_optimization, pl.LpMinimize) x {k: pl.LpVariable(fx_{k}, 0, 1) for k in coal_spec} # 目标配煤综合成本最小化 prob pl.lpSum(v[cost] * x[k] for k, v in coal_spec.items()) # 约束1配比合计必须等于100% prob pl.lpSum(x.values()) 1.0 # 约束2混合灰分不超过9.8% prob pl.lpSum(v[ash] * x[k] for k, v in coal_spec.items()) 9.8 # 约束3混合硫分不超过0.55% prob pl.lpSum(v[sulfur] * x[k] for k, v in coal_spec.items()) 0.55 prob.solve() result {k: round(x[k].value(), 3) for k in x} print(配比方案:, result) print(综合成本:, round(pl.value(prob.objective), 2))这段代码中x是每种煤的配比范围0到1。成本、灰分、硫分的系数来自煤质检验数据和采购价格约束值来自焦炉工艺要求。模型求解完成后的配比还要经过一个校验流程把配比送回质量预测模型算一遍焦炭强度确认CSR等指标在允许区间内再下发到配煤系统。下发接口一般走OPC UA或Modbus写配比参数同时要记录下发时间和操作人方便异常时回溯。这里我一般会额外加一条软约束相邻两批次配比变化不超过5个百分点避免频繁调整给下游焦炉工况带来扰动这条约束在模型里体现为正则项或动态边界。6. 验证模型效果与治理闭环血缘反查、影子压测与版本回退模型部署只是起点真正决定项目成败的是验证机制和回退方案。先说影子压测。新模型上线前把它部署到影子模式只计算结果不参与控制与当前生产系统并行运行7到14天。每天对比影子模型输出和人工核查结果统计误报率和漏报率。以转载机卡堵识别为例需要回放至少一周的历史视频用时间戳对齐的方式逐帧判断模型输出。这里有一个实际技巧回放时把视频播放速率降到0.5倍同时打印模型输出的置信度重点看“置信度在0.4到0.7之间”的模糊区间的样本真正决定告警质量的往往是这一批模糊样本的处理策略。其次是血缘反查。当模型告警和生产记录不一致时需要从告警结果反向查数据链路。我在实施时会把每次推理请求的输入帧、传感器数据和模型版本写入日志表格式如下{ request_id: eval_20250918_001, model_version: vlm_v7.2.1, input: { video_url: edge://camera-12/frames/20250918T0000, sensor_snapshot: belt_speed3.2m/s, load68% }, output: { risk_level: high, confidence: 0.93 } }这份请求日志价值很大当模型出现漏报可顺着request_id找到对应的输入帧确认是标注质量问题还是模型漂移当数据源出现问题比如传感器snapshot字段为空日志会直接暴露采集链路故障。建议将该日志与数据治理平台的血缘图打通让每一次推理请求都能追溯到原始测点真正闭环“数据质量影响模型结果”的链路。最后是版本回退模型文件、配置和权重一定要支持秒级回退。MODEL_DIR/edge/models/mine_vlm # 每次上线前将当前版本备份到 rollback 目录 cp -r $MODEL_DIR/serving $MODEL_DIR/rollback/$(date %s) # 将上一已知良好版本切换到 serving cp -r $MODEL_DIR/good/v7 $MODEL_DIR/serving # 重启推理服务并确认健康状态 systemctl restart mine-vllm curl -s http://127.0.0.1:8000/health | jq .curl /health返回的状态是回退是否成功的唯一标准不要只看进程有没有起来。模型加载完成和真正能接受推理请求之间有时间差建议在健康检查里加一个“模型是否ready”字段否则会出现服务已启动但推理还不可用的窗口期。另外一个容易被忽略的点回退后要自动校验输入输出schema防止新模型引入的prompt模板变化在回退后造成解析失败。本文还有配套的精品资源点击获取 能源行业数据治理与AI底座建设：从湖仓一体到视觉大模型
简介这份PPT围绕能源行业数字化转型系统讲解如何依托数据底座与AI底座构建“云-边-端”三级架构并落地数据治理与大模型应用适合能源企业数字化负责人、数据治理工程师、AI解决方案架构师学习参考。资源为1个pptx文件压缩包约12.62MB图文结合呈现从产品体系、数据治理体系到矿山行业大模型应用的全景路径既包括数据标准、数据架构、数据质量、数据安全四大模块也涵盖大数据湖建设、12000个采集测点、1.5亿条日均入湖数据量等落地指标同时梳理视觉大模型、图网络、多模态、自然语言处理在防冲卸压、智能洗选、人员安全、掘进作业等场景的准确率与降本增效数据。目前已有69人浏览学习。通过研读可掌握能源行业数据治理方法论、矿山行业大模型案例框架理解从数据标准编制、质量规则沉淀到模型参数调优的端到端建设逻辑对规划同类项目、编写汇报方案或开展内部培训均有直接借鉴意义。1. 先从一张能源行业的数据治理地图说起把12000个平均采集测点、日均1.5亿条数据接到同一个湖仓再让几十个AI模型跑在统一底座上这个规模放在能源行业算顶配了。真正值得多看两眼的是它解决的核心问题并不是缺模型而是数据治理能力不足这个隐藏瓶颈数据孤岛、口径不统一、共享机制缺失导致再强的算法也找不到可用数据。把数据底座和AI底座拆开各自建设再通过“云-边-端”三级架构串联先治数、再上模型最终落到防冲卸压、人员安全、焦化配煤这类具体生产场景。这篇文章适合正在做智慧矿山、智慧化工或者集团级数据中台的工程师和架构师看完可以照着这套思路重新评估你们的数据链路和模型部署路径。2. 双底座与“云-边-端”三级架构数据底座和AI底座怎么分层能源行业做数据中台烟囱式建设是降本增效最大的敌人。原本每家矿、每个二级公司各搭一套平台分析应用挂一个、AI应用又挂一个底层IAAS各自买一遍数据模型各自建一遍最后指标口径对不上运维成本翻倍。材料里把这个问题总结得很直接能力重复建设、建设成本高、响应速度慢、体验不一致。拆成双底座后数据统一存储处理、共性能力集中建设数据底座提供全域数据“采存治用”能力AI底座提供全业务域智能化场景能力两边各自演进只通过标准接口交互。2.1 为什么一定要把“数据底座”和“AI底座”拆开data底座和AI底座看起来都离不开大数据平台不少团队会试图放成一套实际跑起来会发现两边的生命周期完全不同。数据底座处理的是存量数据的集成、标准化、质量和安全核心产出是干净可控且可追溯的数据资产AI底座处理的是样本、模型、推理和持续调优核心产出是面向具体场景的算法能力。强耦合的话模型每次更新都要动数据链路数据每次变更都要重新对齐算法系统复杂度会指数上升。拆开之后的两条线很清晰数据底座对AI底座只暴露数据集和数据服务AI底座对数据底座只回传模型推理结果和反馈标签。这样两边都能独立扩容模型迭代不会打断数据管线。材料里“数据底座 AI底座 1套数字化管控体系”的组织方式本质上就是把数据治理和人工智能应用做成两个可以独立演进的平台资产再靠管控体系把标准和流程统一起来。2.2 云-边-端三级架构的职责边界三级架构的划分有明确边界。集团侧是“云端”部署湖仓、数据治理平台、AI训练集群二级公司和生产单位侧是“边”每个生产单位构建一个边缘数据中心放置边缘计算平台、工业防火墙和采集网关再往下是“端”也就是采掘工作面系统、掘进系统、通风监控、安全监控、人员定位、双重预防管理等现场设备和工控系统。层级典型组件职责故障影响中心云湖仓、数据治理平台、AI训练集群全域数据汇聚、模型训练、数据服务开放数据补传与模型发布延迟边缘侧边缘计算平台、工业防火墙、采集网关实时采集、断点缓存、轻量推理局部监控降级生产不中断端侧采掘设备PLC、传感器、摄像仪原始信号与图像采集、执行控制单点数据缺失自动补采边缘侧是这套架构里最容易翻车的点。井下网络抖动是常态直接把数据推到中心不现实所以边缘采集网关必须带本地缓存和断点续传模型推理也要能在边缘独立跑起来不能一断网就全盲。材料里提到的“每个生产单位构建一个边缘数据中心”就是为了把时延控制在秒级以内同时减轻中心侧带宽压力。2.3 边缘采集网关配置与数据格式约定采集网关的配置决定了数据质量的下限。这里给出一个典型的边缘采集网关配置协议层覆盖OPC UA和Modbus TCP输出走Kafka的JSON Lines格式。gateway: site_id: mine-1203 protocol: - opcua - modbus_tcp tags: - name: drill_depth_12 address: 1/3/40001 type: float32 sampling_interval_ms: 5000 - name: person_zone_count address: 2/5/10002 type: int32 sampling_interval_ms: 1000 security: industrial_firewall: true acl: - *.oee.sensor - *.sic output: broker: kafka://cn-edge.emqtt.internal:9092 topic_prefix: raw/mine/physical format: json_lines persist_on_offline: local_buffer_4hsampling_interval_ms决定了测点采集频率一般工艺参数设5秒已足够人员定位这种变化快的设1秒。persist_on_offline建议至少4小时井下故障恢复时间通常以小时计缓存不够会直接丢数据。topic_prefix建议带上站点和数据类型方便后续按“一数一源”做数据责任划分。现场实施时还要注意视频流不要走采集网关要单独走边缘存储12000个测点下文本类数据每秒新增量并不大但一路1080P视频动辄4Mbps以上混在一起会把Kafka集群打挂。3. 数据湖建设与数据治理实施标准、质量、血缘缺一不可数据底座的落地不能只靠一套大数据平台材料里给出的路径是建设数据湖、建设采集实施、实施数据治理三步走核心是形成“采存治用”数据治理体系。数据湖基于湖仓一体化架构建设向上能为应用提供数据支撑向下能整合各类数据源。这个阶段最容易犯的错是一上来就追求数据大而全结果花了三个月接入几十套系统真正能被模型使用的数据集却没几个。正确做法是先把标准和质量规则定义好再倒推需要接哪些数据。3.1 湖仓一体下的数据资产汇集湖仓一体的关键不是“湖”或“仓”选哪个而是让同一份数据能同时支持批处理和实时计算。材料里覆盖了集团统建系统和外部数据的采集入湖包含生产矿井安全生产类数据的全覆盖最终实现“一数一源”。实施时我一般会从三个维度评估数据源类型、数据时效要求、数据质量成熟度。经营管理类数据如财务、物资时效要求不高走T1批处理安全监控类和人员定位类数据必须秒级延迟走Kafka实时链路。数据入湖之后的组织方式也值得推敲。材料里做了数据盘点900余项数据指标、32个主题域组、177个主题域、1109个业务对象、741个数据实体、8694个数据属性、140余个数据资源目录。这组数字说明治理工作不是停在标准文档而是真正把业务对象拆到了属性级。业务对象和属性能对得上数据模型才能真正被后续的数据应用复用。3.2 数据标准体系如何落到业务对象标准体系是一层层堆出来的。材料里提到参与编制行业标准28项建立能源集团数据标准体系形成基础类标准10项、对象类标准3项、架构类2项、作业类4项加上数据分级定级、数据安全、数据共享要求等专项规范。标准类别数量包含内容示例基础类10井工煤矿数据分类及编码规范、通信接口与协议规范对象类3数据架构规范、主数据规范架构类2数据存储技术规范、数据共享基本要求作业类4数据质量管理规范、数据安全规范行业专项28露天矿山车辆数据共享、矿用5G智能终端数据共享等这些标准的落地要避免两个偏差。第一是只做文档不做映射标准写了但数据模型里没体现等于白做第二是只做映射不落库标准与物理表字段对不上。实施时我会把标准编号直接写进数据字典的扩展属性里让每一个字段都能追溯其标准来源后续做合规审计和数据质量评估会省很多时间。3.3 数据质量规则与血缘可视化落地材料中沉淀了70余类数据质量规则完成619个数据质量评估输出63对矿井数据质量报告。质量规则不是越多越好而是要和业务风险挂钩。井下人员定位数据缺测直接影响安全监控预警这类规则必须优先实现。以人员定位数据的连续性检查为例一个可用的质量规则SQL如下-- 井下人员定位连续性检查 WITH raw AS ( SELECT person_id, ts, zone_id FROM kafka.people_position_raw WHERE ts now() - interval 5 MINUTE ), summary AS ( SELECT person_id, count(1) AS sample_cnt FROM raw WHERE zone_id IS NOT NULL GROUP BY person_id ) SELECT person_id, sample_cnt FROM summary WHERE sample_cnt 3;这个SQL解决的是“定位数据是否连续”的问题。一个人若5分钟内有效定位样本少于3次基本可以判断为信号丢失或设备异常。其中kafka.people_position_raw是流表interval 5 MINUTE是时间窗口zone_id IS NOT NULL用于剔除无效数据。规则跑出问题后要能顺着数据链路往回查落到具体是哪个采集网关、哪个传感器出了问题。血缘关系是实现“回查”的基础设施通常在数据开发平台里自动生成。这里给出一个解析SQL血缘的最小Python示例便于理解血缘节点如何构建。import re def extract_lineage(sql: str) - dict: target re.search(rinsert\sinto\s(\w), sql, re.I).group(1) sources set(re.findall(r(?:from|join)\s(\w), sql, re.I)) return {target: target, sources: sorted(sources)} sql insert into dws_mine_person select a.person_id, b.mine_name from dwd_mine_person a join dim_mine b on a.mine_id b.mine_id print(extract_lineage(sql))extract_lineage从SQL文本中提取目标表和源表在真实平台上血缘会沿抽取、清洗、标准化、主题建模、应用数据集逐层传递。有了血缘数据质量告警才能从结果指标一路反查到原始测点这也是材料里“数据血缘可视化展示可查看数据从接入到应用的全链路”的实际含义。4. 视觉大模型与多模态推理的部署骨架能源行业的大模型应用最成熟的方向不是文本对话而是视觉和多模态。材料里的做法很明确视觉大模型技术就是“用摄像仪替代人眼”针对煤矿已有的视频监控按每个摄像仪的功能需求部署不同算法模型做分级预警和联动控制。这背后需要的不是一套通用的图像识别系统而是基于行业预训练模型架构的视觉大模型、图网络和多模态融合技术栈。4.1 从视频监控到视觉大模型的改造路径煤矿视频监控的特点是“装得多、看得少”大量摄像头只是被动记录没有形成主动预警能力。改造时先做场景梳理把摄像仪分为安全管理、岗位人员、巡检人员三类角色。比如转载机入料口卡堵识别解决的是溜煤眼堵塞导致的生产中断危险区域人员入侵检测解决的是人员违章进入高风险区域防冲卸压工程打钻深度监管则要求模型结合视频帧和工艺参数判断钻孔深度是否达标。这个改造过程中模型输出不能只报“有风险”或“无风险”要直接对接现场控制系统。材料里提到“分级预警及联动控制”落地时一般分三步第一步算法输出结构化结果比如目标框和置信度第二步规则引擎判断风险等级决定是弹窗提醒还是联动广播喊话第三步将结果发给PLC执行停机和闭锁动作。这一步的延迟和数据可靠性决定了系统能否真正下放到生产现场。4.2 本地部署大模型vLLM配置与参数说明视觉大模型在煤矿场景基本不可能用公有云API数据主权和网络条件都不允许。本地部署是常规选择。对于视觉语言类的7B模型vLLM是目前工程上比较稳的推理框架之一显存利用率和吞吐都比原生HuggingFace实现高不少。from vllm import LLM, SamplingParams llm LLM( model/models/mine_energy_vlm_7b, tensor_parallel_size2, gpu_memory_utilization0.85, dtypebfloat16, trust_remote_codeTrue, ) params SamplingParams( temperature0.1, top_p0.85, max_tokens128, ) prompts [ 请判断画面中转载机入料口是否存在卡堵风险只回答风险等级和依据。, 请检测回采面危险区域是否有人入侵只回答有或无。, ] out llm.generate(prompts, params) for r in out: print(r.outputs[0].text)tensor_parallel_size2表示将模型切到2张GPU上并行推理适合单卡显存放不下整个模型的情况。gpu_memory_utilization0.85预留了15%显存给推理过程中的临时张量避免OOM。dtypebfloat16在A100或H800这类卡上能稳定降低显存占用。temperature0.1和top_p0.85组合是为了让输出尽量确定安全告警场景不需要创造性每句话都应该是可复现的。这里最容易被忽略的是max_tokens128安全场景的输出必须短直接输出结构化的风险等级和依据不要开放性的长文本。4.3 多模态场景选型与效果对比不同场景对模型形态的要求不一样。材料里的数据可以整理成一张选型参考表直接对接场景和准确率指标。场景模型类型指标说明转载机入料口卡堵识别视觉检测模型准确率95%基于边缘视频流检测卡堵并联动控制系统危险区域人员入侵视觉定位数据融合识别率95%与井下人员定位数据交叉验证防冲卸压打钻深度多模态融合模型准确率90%结合视频图像和钻机工艺参数焦化配煤质量预测机理模型机器学习准确率95%融合煤质检验和工况数据多模态场景的核心不是把视频和文本拼在一起做输入而是要让不同模态的数据在时间轴上对齐。比如打钻深度监管视频显示钻杆推进位置工艺参数表显示当前压力两者必须按同一个时间基准打点。实际部署中我一般会在边缘侧先做一层时间对齐处理把视频抽帧和传感器数据写入同一份HDF5或Parquet文件中再送入模型训练或推理。这个预处理步骤比模型本身更容易被忽略也更容易出问题。5. 焦化配煤与工艺优化把Excel经验变成可求解的模型问题材料里焦化配煤智能应用这一段是整个PPT中最贴近“大模型值多少钱”的场景。传统焦化配煤依赖专家经验用Excel算配比取值保守成本偏高而且无法回溯验证。改成AI方案后配合煤每吨成本降低3到5元焦炭质量预测准确率超过95%耗时从原来的“天级小焦炉实验”缩短到分钟级。这个场景的改造思路非常清晰先数据化再模型化最后优化下发。5.1 从专家经验到数据模型的转变传统配煤的问题有三层一是依赖老师傅经验配比是否最优没人能证明二是Excel只能线性估算但焦炭质量与煤质参数之间不是简单的线性关系三是过程不可追溯同样的原料参数变化后很难解释为什么配比变了。AI应用要解决的就是这三点。模型化之后输入数据包括原煤检验数据、焦炭检验数据、生产过程数据输出是配比方案和焦炭质量预测。材料里提到的“模型训练、调优”和“数据工程”阶段前置工作比模型本身更琐碎需要处理不同煤种的工业分析指标、煤岩数据、单种煤炼焦数据以及焦炉的温度和结焦时间。这几个特征维度来自不同系统时间粒度也不一致典型的数据工程问题。5.2 特征工程与数据准备配煤模型的特征工程有两个关键点第一是特征对齐不同煤种同一批次的数据要按“入炉时间煤仓号”对齐才能反映真实配比第二是小样本处理单个焦化厂可用批次数据往往只有几百条直接训练深度模型很容易过拟合。工业实践上会用机理模型先算一遍理论焦炭质量再把机理模型结果作为特征输入机器学习模型构成“机理数据”混合建模材料里对应“基于配煤机理自动学习复杂参数”。特征类型典型字段数据来源煤质数据灰分Ad、硫St、挥发分Vdaf原煤检验系统煤岩数据反射率、显微组分煤质化验室单种煤炼焦数据焦炭强度CSR、CRI小焦炉实验数据工况数据焦炉温度、结焦时间生产执行系统MES特征构建完成后数据标准化、缺失值填充和异常值剔除都要按批次做。这里有个容易踩的坑不要把不同煤种的数据混在一起做归一化因为不同煤种的灰分分布范围差异明显混在一起会抹掉煤种间的区分度。正确做法是按煤种分组标准化或者直接用原始值加煤种ID做类别特征。5.3 配比优化与下发线性规划示例配比优化本质是一个带约束的线性规划问题。目标函数是配煤成本最小化约束是焦炭质量指标必须落在工艺允许范围内。以下是使用PuLP求解的可运行示例import pulp as pl coal_spec { 肥煤: {cost: 920, ash: 10.2, sulfur: 0.50}, 焦煤: {cost: 980, ash: 8.8, sulfur: 0.65}, 瘦煤: {cost: 780, ash: 11.0, sulfur: 0.40}, 气煤: {cost: 850, ash: 9.5, sulfur: 0.45}, } prob pl.LpProblem(coke_blend_optimization, pl.LpMinimize) x {k: pl.LpVariable(fx_{k}, 0, 1) for k in coal_spec} # 目标配煤综合成本最小化 prob pl.lpSum(v[cost] * x[k] for k, v in coal_spec.items()) # 约束1配比合计必须等于100% prob pl.lpSum(x.values()) 1.0 # 约束2混合灰分不超过9.8% prob pl.lpSum(v[ash] * x[k] for k, v in coal_spec.items()) 9.8 # 约束3混合硫分不超过0.55% prob pl.lpSum(v[sulfur] * x[k] for k, v in coal_spec.items()) 0.55 prob.solve() result {k: round(x[k].value(), 3) for k in x} print(配比方案:, result) print(综合成本:, round(pl.value(prob.objective), 2))这段代码中x是每种煤的配比范围0到1。成本、灰分、硫分的系数来自煤质检验数据和采购价格约束值来自焦炉工艺要求。模型求解完成后的配比还要经过一个校验流程把配比送回质量预测模型算一遍焦炭强度确认CSR等指标在允许区间内再下发到配煤系统。下发接口一般走OPC UA或Modbus写配比参数同时要记录下发时间和操作人方便异常时回溯。这里我一般会额外加一条软约束相邻两批次配比变化不超过5个百分点避免频繁调整给下游焦炉工况带来扰动这条约束在模型里体现为正则项或动态边界。6. 验证模型效果与治理闭环血缘反查、影子压测与版本回退模型部署只是起点真正决定项目成败的是验证机制和回退方案。先说影子压测。新模型上线前把它部署到影子模式只计算结果不参与控制与当前生产系统并行运行7到14天。每天对比影子模型输出和人工核查结果统计误报率和漏报率。以转载机卡堵识别为例需要回放至少一周的历史视频用时间戳对齐的方式逐帧判断模型输出。这里有一个实际技巧回放时把视频播放速率降到0.5倍同时打印模型输出的置信度重点看“置信度在0.4到0.7之间”的模糊区间的样本真正决定告警质量的往往是这一批模糊样本的处理策略。其次是血缘反查。当模型告警和生产记录不一致时需要从告警结果反向查数据链路。我在实施时会把每次推理请求的输入帧、传感器数据和模型版本写入日志表格式如下{ request_id: eval_20250918_001, model_version: vlm_v7.2.1, input: { video_url: edge://camera-12/frames/20250918T0000, sensor_snapshot: belt_speed3.2m/s, load68% }, output: { risk_level: high, confidence: 0.93 } }这份请求日志价值很大当模型出现漏报可顺着request_id找到对应的输入帧确认是标注质量问题还是模型漂移当数据源出现问题比如传感器snapshot字段为空日志会直接暴露采集链路故障。建议将该日志与数据治理平台的血缘图打通让每一次推理请求都能追溯到原始测点真正闭环“数据质量影响模型结果”的链路。最后是版本回退模型文件、配置和权重一定要支持秒级回退。MODEL_DIR/edge/models/mine_vlm # 每次上线前将当前版本备份到 rollback 目录 cp -r $MODEL_DIR/serving $MODEL_DIR/rollback/$(date %s) # 将上一已知良好版本切换到 serving cp -r $MODEL_DIR/good/v7 $MODEL_DIR/serving # 重启推理服务并确认健康状态 systemctl restart mine-vllm curl -s http://127.0.0.1:8000/health | jq .curl /health返回的状态是回退是否成功的唯一标准不要只看进程有没有起来。模型加载完成和真正能接受推理请求之间有时间差建议在健康检查里加一个“模型是否ready”字段否则会出现服务已启动但推理还不可用的窗口期。另外一个容易被忽略的点回退后要自动校验输入输出schema防止新模型引入的prompt模板变化在回退后造成解析失败。本文还有配套的精品资源点击获取