工业大模型数据治理：从脏数据到决策资产的转化路径

有个做工业大模型的同行告诉我，他们给一家钢铁厂做的炼钢参数优化模型，上线三个月后准确率从预期的85%掉到了42%。排查了两个月后发现：传感器每年校准两次，校准前后数据存在明显的系统性偏移，这些偏移数据没被清洗就直接喂给了模型，模型学进去的是传感器校准的数学规律而不是炼钢的工艺规律。

这个案例说明的问题不是模型设计有问题，是数据质量有问题。工业大模型项目的失败，70%的原因在数据，30%的原因在模型。数据治理不是大模型项目的"前期准备阶段"，而是整个项目的核心工作。

一、工业数据为什么脏：理解数据污染的来源

工业现场的数据污染来源主要有四种，每种有不同的识别和修复方法。

第一种是传感器故障和漂移。传感器用久了会漂移——热电偶的接线头氧化导致接触电阻增大，温度读数系统性偏低；压力变送器的膜片结垢导致响应迟滞，测量值滞后于实际值。传感器漂移的特点是变化缓慢、持续时间长，不容易被识别为故障，容易被当成工艺正常波动。

识别方法是用时间窗口内的自相关分析——正常工艺参数的时序数据在短期内具有自相关性（前一个时刻的值和后一个时刻的值有关联），而传感器漂移破坏了这种自相关。一旦发现某个传感器的自相关系数显著低于同类传感器，该传感器很可能存在漂移问题。

修复方法取决于漂移程度。轻微漂移可以用线性校正模型修复（用校准前后的实测值建立线性校正方程）；严重漂移必须标定传感器或更换传感器后才能相信其数据。

第二种是数据缺失。数据缺失在工业现场是常态——设备停机期间数据停止记录，通讯中断期间数据丢失，人工操作导致某些参数在特定时段没有被采集。数据缺失本身不是问题，问题是缺失后用什么值填补。

填补方法不能随便选。常数填补（用均值或零填补）是最常见的错误做法，这种填补方式会在模型训练时引入系统性偏差。正确的方法是：根据缺失原因选择填补策略——随机缺失（MCAR）可以用线性插值；非随机缺失（MNAR，即缺失和数据本身有关）需要用多重填补或专门的时间序列填补算法如ARIMA。

第三种是工况切换带来的数据异质性。工业过程不是稳态运行的，有启停操作、有负荷调整、有检修维护。不同时期的数据代表完全不同的工况，把它们混在一起训练模型，模型学到的是不同工况的混合规律，在任何单一工况下都表现不好。

解决方案是工况标注——把数据按工况分类：正常稳态运行数据、启停过程数据、负荷调整过程数据、异常工况数据。不同工况分别建模，或者在模型输入中加入工况标签作为额外特征。

第四种是人工录入数据的不一致性。操作工手动记录的产量、能耗、质量数据往往和实际有偏差——四舍五入、估算填数、甚至为了"好看"而调整数据。人工数据的识别要看数据分布——真实数据的分布通常是连续且有合理边界的，人工捏造的数据往往在某些数值上聚集过多。

二、数据清洗工程：从原始数据到可用数据集

数据清洗是一个系统工程，不是针对某一个数据的修修补补，而是一条从原始数据到可用数据集的完整流水线。

流水线第一步是数据接入和解析。工业数据来源多样：PLC通过OPC DA/UA推送数据，SCADA historian有专有的存储格式，MES系统通过数据库直接查询。先要把这些异构数据源统一接入到同一个数据湖（常用方案是Kafka做实时数据接入、Flume/Logstash做历史数据批量导入），再统一解析成标准时序数据格式。

第二步是数据质量检测。数据接入后不要急着存，先做质量检测。检测内容包括：数据完整性（缺失率是否超过阈值）、数值合理性（是否超出物理可能范围，如绝对压力出现负值）、时序连续性（时间戳是否连续、有没有时间戳跳跃）、相关性检验（物理上相关的两个参数（如压力和温度）是否符合热力学关系）。

第三步是数据标注。标注是数据清洗中最耗时、也最体现工艺知识的环节。标注内容包括：工况标签（启/停/稳态/异常）、事件标签（故障开始/故障结束/维护开始/维护结束）、质量标签（合格/不合格，以及不合格的等级和原因）。标注需要工艺工程师参与，不是数据工程师能独立完成的。

三、工业时序数据库：数据治理的技术底座

工业时序数据（温度、压力、流量、振动等随时间变化的参数）有其特殊性——数据量大（一个中型工厂每秒产生数千个数据点）、查询模式以范围查询和聚合查询为主、需要支持时间线上的对齐和关联。传统关系型数据库在处理这种负载时性能很差，需要专用的时序数据库（TSDB）。

主流的开源工业时序数据库有几个选择：InfluxDB（单节点性能好但集群方案贵）、TimescaleDB（基于PostgreSQL，SQL兼容性好）、Apache IoTDB（国产开源，专门针对工业物联网场景优化，支持设备层级结构和丰富的聚合函数）。选型时主要看数据量级、查询延迟要求和团队技术栈。

时序数据库的选型还影响后续的数据分析路径。如果团队熟悉Python和Pandas，用TimescaleDB的SQL接口接 Jupyter Notebook是最快的分析路径；如果需要处理高频数据（毫秒级采样，如振动分析），选IoTDB的高压缩引擎更合适。

四、数据资产管理：让数据持续产生价值

数据治理不是一次性项目，是持续运营的工作。一次性清洗出来的干净数据集，用着用着又会变脏——传感器会漂移、工况会变化、新的数据源会接入。数据资产管理的目标是把数据治理变成一个可持续运转的机制，而不是每次做AI项目都要从零开始清洗数据。

建立数据资产目录是第一步。目录内容包括：有哪些数据源、数据质量等级是多少、数据Owner是谁、数据更新频率是多少、数据的主要使用场景是什么。数据资产目录不是给领导看的PPT，是给工程师用的工具——工程师在开始一个AI项目之前，应该先查目录看有没有可用的数据，而不是先采集数据再做分析。

建立数据质量监控是第二步。和生产系统需要监控设备健康状态一样，数据系统也需要监控数据健康状态。监控内容包括：各数据源的实时缺失率、数据值的分布是否发生变化、相邻时间点的跳变是否异常。数据质量出现异常时自动告警，触发数据工程师的介入处理。

建立数据访问和共享机制是第三步。工厂的数据分散在工程部门、IT部门、生产车间各自手中，互相不共享。建立数据访问API和数据共享审批流程，让数据在受控的前提下流动起来——既避免数据成为孤岛，也避免数据滥用带来的安全风险。

五、写在最后

工业数据治理的核心投入不是软件工具，是工艺知识。传感器为什么会漂移、哪些工况切换需要标注、不同工艺参数之间的物理约束是什么——这些知识只有现场工程师知道，不是数据工程师能凭空想出来的。

数据治理项目的组织结构应该是：工艺工程师负责定义数据质量的评判标准和标注规则，数据工程师负责搭建数据管线和清洗工具，算法工程师负责在清洗好的数据上做模型训练。这三个角色的协作质量决定了数据治理的最终效果。

一个实用的判断标准是：如果数据清洗和治理占整个大模型项目的比例不到50%，那这个项目大概率会以失败告终。模型训练反而是相对简单的部分——选对模型架构、调好超参数，工程化落地才是真正的硬仗。