直播回顾 | 工业数据分析模型的规模化应用，如何做？

科技 2024-07-25 17:57 北京

上次直播聊到，数据分析应用落地会逐步经历小规模验证阶段和大规模应用阶段。过去很多算法研究和科研项目试点都还是聚焦在小规模验证，一旦进入大规模应用，会面临哪些挑战导致很多想法技术和现场业务结合不起来？从量变引发质变，怎么去做工程化的管理，怎么分组？时间维度上，数据分析应用如何和业务结合，不断迭代演进并持续运营？未尽问题，本周继续。

1、当我们进行工业数据分析模型的小规模研发和验证时，到底从哪个车间、从哪几台设备来着手做小规模的验证？

如果在一开始就考虑到日后的大规模推广，我们会倾向于一开始就尽量多地收集样本，而不是随意找两台先试试。例如某个工厂现在有1000台同类型的设备，虽然都是干同样的活，工作原理可能差不多，但是不同的车间，有不同的型号、不同的版本，多少有点差别。

我们的原则是，先做一些面上的数据探索，对这些设备的特性、数据的情况、关键业务指标（如良率、能耗等）、关键特征指标（如温度、压力等），以及物理上的产品型号、所属厂区、工艺版本等做一些划分，然后选取在各方面都比较相似的且有一定代表性的组别，以及数据基础、整体表现等方面比较稳定的设备，去做小规模验证。

模型刚开发要抓主要矛盾，忽略次要矛盾。先保证在相对理想的条件下，模型能做出来。

那为什么要先做一个尽量全的聚类分析（非特指狭义的聚类算法）去找这些相似性？因为在这个过程中，我们要有意识地考量，相对这次小规模选中的几台设备，其他设备到底在哪些方面有些差异？一旦未来往大规模推广，可能需要提前考虑和涉及到一些什么情况。这是真正的起点。

2、小规模验证之后，会有什么样的阶段性交付物交到数据分析工程师手上？

类似于泛机器学习类的项目，这个阶段数据科学家的交付物是两套代码加一套文件、及相对应的数据集。一套是基于离线数据集训练的代码，一般会低频使用，代码上线前可能需要迭代很多轮，可以针对不同的片区去做适配。另一套，是用于在线实时预测的代码，怎么去使用训练得到的模型。我们一般会把训练完的模型存成一个文件，把文件交给预测的那部分的代码，去实时预测。

3、数据分析工程师拿到交付物之后，面向大规模推广，还需要做哪些准备工作？

在不同的片区做离线模型的训练，肯定会发现推广不顺。这个时候就需要科学家介入，重新去发现问题、解决问题。这个过程中，可能会动代码、可能会动特征工程、可能会动一些模型的参数。这一套代码推广了一个片区，到下一片区又不适用了，得来回回反复调试，这时候需要版本管理。

需要多个片区同时推广的时候，数据工程师可以和数据科学家做个分工，数据工程师提前了解这个版本的更新点是什么，然后把训练的数据集提前准备好。从数据集开始就要去区分，相当于每个版本的数据集都要做版本管理。

模型训练的数据集从一开始筛选数据的范围，到怎么去做异常数据的过滤，到特征加工的细节、参数的选择，整个过程中的配置改变任何一项，数据集的版本就不一样，模型的结果就不一样。

对应版本的数据集，由不同的训练脚本生成不同的模型文件。不论是云端的模型管理系统，还是边缘侧的本地服务，都要提前要想好如何管理模型版本信息。

版本管理，不仅仅只是一个简单的代码版本管理，模型版本和对应的数据集的版本管理也得纳入到整个体系里面来。

每训练完一个新版本的模型，不能等到模型上线才验证效果，所以需要制定模型训练应该输出的标准范式，中间有哪些信息必须要查验，有了这些信息，就大概知道这个模型效果如何。

需要注意的是，模型训练只输出模型精度远远不够。建模的时候，我们要确认数据特征和分布是不是满足要求。模型做完之后要去检查残差，它是不是一个单峰的正态分布？要去检查一些关键特征是不是跟前一个片区推广时一致？如果在那个片区特征是正相关，到了这个片区变成负相关了，那机理上是相悖的。这些都是在训练信息输出怎么标准化的时候要去考虑的内容。

4、如果我们已经控制了数据集的版本、模型的版本，下一步大规模推广，是否有可参考的标准步骤？

规模化推广，SOP是为了保证团队协同的时候减少犯错的几率，每个人都很清楚自己的职能和边界，从而提高推广的效率。

在新的服务器里建起全套服务，从整体的数据库建表、到起服务键、到部署日志文件，怎么部署测试集，怎么做测试，需要输出哪些测试的结果……所有这一套规范下来，整个服务的setup才真正完成。（这里有点单薄）

整个流程中，所有中间的输出结果，团队可以互相交流，过程可以随时审核，判断相应的结果是否符合预期。团队成员主要角色有数据科学家、数据分析工程师以及产品经理（负责业务侧把技术和业务打通）。还有一些辅助角色，例如数据接入、测试、运维等。

当然，实际过程中有的时候会一人身兼多职。不同企业的不同课题，颗粒度各有不同，从项目的规划、组织资源的协调、时间、经费等各方面考虑，对人员对组织的要求也不同。

这是一项算法软件工程，标准化的工作流程也是后面能够实现模型稳定可靠持续运行的基础。

5、以异常检测为例，从模型小规模验证到大规模推广，尝试梳理整个流程。

以泵的异常检测为例，泵用在不同的环节，它的大小不同，控制模式不同，很显然，它物理上就会分成不同组。从这开始，我们就要有意识的区分组。

某泵去年一年在同等工况下，震动、噪声、效率都在一个相对平稳的区间内。为什么从这个月开始，没有偶发干扰，噪声却在逐渐变大，效率在逐渐下降？这时候我们不去跟泵的设计值比，而是跟正常状态建立的模型相比，有明显偏离。（异常检测不是故障诊断，异常背后的原因才是诊断，这里我们先看异常检测。）

在这个场景下，数据科学家按业务要求理解，根据泵的大小、泵所在的工艺环节等一些相应的差异进行了设备分组，而且数据工程师把对应的历史数据集找到，数据科学家按照基准偏离的方式把模型的异常算法开发出来，将两套代码一套文件，还有一套数据集，交给数据分析工程师。

数据工程师在准备数据集以及流程性代码的编写过程中，已经开始了解代码的基本逻辑和设计思路，上述文件和代码拿到手之后，项目组团队该去一线试一试。

这时候分工更精细一点，比如说有负责数据接入、数据质量监测的，有负责模型部署运维、部署实施的。先要持续累积一段时间的数据，当然这一部分数据可能提前获取，也可能是产品布上去之后持续积累。获取了历史数据之后，我们按照之前的一些标准进行筛选，之后开始训练模型，输出相应的结果保存下来，大家相互查验没有问题，就上线了。

模型监控跑起来之后，我们要做一些试运行的测试集，比如说调度触发式的模型，可以人工创造多个触发案例，先把整个模型流程跑一下，有没有问题。至于跟实际业务的出入大不大，我们后面再看。

模型正式调度起来，持续积累数据和异常，模型监控（如成功率、异常的错误分类等）同步跑起来，定期review。我们还要去看今天成功率高，明天成功率低，是不是和模型有关系，跟模型的概率有多大？如有需要，我们直接主动去改善代码。

一旦发生设备大修等情况，就再把之前那一套再走一遍，把模型该更新的更新，更新了哪些内容一定要记录下来，包括版本的更新，更新的要点，这些都要确认下来。基本上就是这样的一个逻辑。

6、关于异常检测模型的补充提示

对设备异常监测模型最好的实践方式，是用大修之后的一段数据作为训练基准。我们认为大修之后这段时间是最正常的，但是不是真修好了其实数据不知道。有了这样的训练结果，就能让模型跑起来。

最期待的正常情况是这个模型在大修期区间不会再变了。但很有可能还是会变，你发现这个模型确实飘了。

因为模型考虑不周到。例如说大修期间，模型的训练集是前三个月的，但是跑到第六个月的时候出现了一个新工况，我的模型恰好没考虑到这类新工况，报出异常。而业务人员去确认了，这不是异常，而一次特殊工况。

这个时候应该去重新训练模型吗？我们一般不建议重新训练模型。

如果是偶尔的干扰，一个特殊工况，你只需要把这一次的异常检测打一个标签，标注这是一个特殊工况，无需报警。我下一个版本训练模型的时候，有意识的去对这个特殊工况，做单独的建模处理或直接简单滤除，就能保证下个版本的模型会变得更好。

昆仑数据K2Data

昆仑数据是工业互联网领域的领军企业，蝉联“中国大数据企业50强”，受邀参与制订《中国制造2025》工业大数据技术路线图，发起成立并主导运营工业大数据制造业创新中心，致力于用大数据和人工智能技术，推动中国工业智慧升级。

最新文章

数据探索系列 | 可视化是拨乱反正的关键一步

昆仑数据K2Assets入选2024年北京市工业互联网平台名单

陆薇博士应邀在《ACM通讯》发表文章

数据探索系列：拨开迷雾，找到一条通往终点的最短路

数据探索系列 | 为什么会那么多算法，还是做不好工业数据分析？

2024爱分析·数据要素x厂商全景报告

K2动态 | 《国家工业互联网大数据中心工业智算基地评估规范》正式发布

技术干货 | 工业数据分析的3种载体形式

昆仑数据受邀出席数智化促进核能新质生产力发展会议

技术干货 | 分析场景识别中的常见问题

清洁能源数字化的现状、趋势和未来

直播预告 | 清洁能源数字化现状、趋势和未来

伺服电机滚动轴承的智能化寿命预测

工业数智化趋势和需求是什么？向数据要更多价值

昆仑数据亮相CCKS 2024全国知识图谱与语义计算大会