工业数据分析的算法研究和现场项目中的模型规模化应用，有什么本质区别？
传统软件工程，更多是从需求分解、概要设计、详细设计一层层去开发，从单元测试到集成测试，再变成上线系统，是一个非常体系化的工作过程。但工业数据分析项目的实施有其特殊性。特别是前期多因素共同作用下，需要有综合能力比较强的数据科学家去带领项目进行算法的快速探索、风险评估以及可行性验证。对应到项目形态上讲，这个阶段可能会是一个科研类项目，甚至是一个POC形态的项目。做出算法原型并确认可行之后，就需要开展规模化工程应用的工作了。这个阶段往往对应的就是一个实施项目了。基于核心算法的项目开发怎么落地，如何部署、运行、监控，需要多角色配合进行。
算法模型要落地应用，在小规模验证阶段，会面临哪些问题？
从数据科学家的角度，将算法模型建立之后，一方面需要知识转移，前面两三个月做的算法，要让工程化团队，甚至运维团队都能接得住；另一方面，整个工程化上线调试、运行推广，需要各司其职，让协同效率最大化。他们各自的能力边界在哪里？怎么让不同的角色在不同阶段去承担各自的责任？
对数据工程师来说，数据科学家将模型的核心思路确认之后，再交到工程师手里，完成模型的标准化和工程化上线。读数据科学家的代码本就不容易，他们思路顺的时候会一直往下写，如果稍有不顺，可能天马行空随时转折。而尝试复现他们的代码效果的时候，就可能会出现一些数据科学家自己也不清楚的bug。
因为在第一时间以效率优先去快速探索、试错验证的过程中，数据科学家可能会忽略掉一些在工程角度上非常重要，但是从试错的角度，必须降低优先级的因素。而前期做数据探索或者数据验证，从一定程度上出于数据保密的要求，数据样本量不大。此外，最开始做模型研发，不管设备还是产线，从数据的质量到数据的传感器，通常都会挑比较理想的示范机组。不知道这事能不能成之前，一般不会拿一个数据最少的、传感器最少的、数据质量最差的来挑战自己。
POC验证差不多的时候，到小规模验证，就可能会模型失效。因为工厂设备本身差异很大，尺寸大小不一样，核心零部件供应厂商不一样，配套的自动化厂商不一样，甚至人工操作习惯也不一样，等等。
之前POC阶段在数据上无法体现的一些现象，到了实际应用的时候，会影响整体的进度，工程师整体调试难度很大，很难分解。如果小范围都无法推广，更何谈接下来更大范围的推广。这也是为什么停留在论文层面的理论研究很多，而在生产环境下实际解决问题却很难。
小规模试运行测试之后，做大规模推广的过程中，还会碰到哪些困难？
POC到小规模验证，已经有一定程度的困难，从小规模到大规模，存在的变量就更多。因为工厂讲究多元化，同一个工厂下的不同产线，自动化供应商不一样、设备供应商不一样、材料供应商不一样，等等。如果推广到不同的生产基地下的不同工厂，复杂度就更高。
以前在一个小范围片区里面，我们用一整套稍微大一点的模型去管理（不是现在意义上的大模型）100-200个机台，还能用。当把这个数量乘以10、乘以100，在全国范围覆盖的时候，管理起来会相当困难。
我们不可能在每一条产线，每次都花大量时间训练一遍。模型训练也不是一成不变的，例如批次的控制，上一批失败了，下一批怎么调，那上一批是成功的，下次怎么调？有可能两个厂商乘以两个供应商再乘以原材料种类的乘积，复杂程度就是几何倍数的增长，那模型就数不胜数。以前的方式就不再可用。
我们需要考虑，这里哪些是共性的，哪些是个性化的，我们怎么用模型组去更好的管理？
关联问题：怎样算大规模？分行业和场景而异。在机理相对明确、可变因素相对较少的时候，可能把单机模型扩到几百个，甚至上千个的规模，我们认为是大规模；但是有一些更特殊情况，场景复杂，影响因素比较多，能从一扩到十就很不容易了，扩到几十台机组，就算是大规模部署了。
以温度为例，温度的常见工况有升温、温度维持或者降温，这是简单的一个分类。如果在舱体容器里，温度和压力是同时存在的，那可能会存在既加压又加温的情况。但往往两者的速率不一样。可能是压力快速达到目标值后，迅速进入维持阶段，然后温度缓慢上升。常规定义可能就只是简单的升温升压阶段。
实际训练模型时，我们需要把它进行拆分、组合，相当于一个工艺段的两个细分阶段。如果类似的情况再增加就需要再细分，有各种可能的组合。不只是明面上的五种或六种工况，切分后底下可能是10种至20种工况，都得做针对性的交叉训练，模型组的概念就出现了。
模型组的定义很重要，首先群组内的核心算法和逻辑是一致的，要挑战的是工程化过程中不同的变量带来的差异性问题。但定义组不能太琐碎，否则后面开发、维护的工作量就会巨大；另外一方面，又不能定得太过粗放，否则无法覆盖或者解决上述提到的问题。很考验工程师的经验和技术能力。
模型的规模化，除了量变引发质变，还有时间周期上的持续运营问题。
算法可以规模化的上线之后，再往后可能还会碰到怎么去持续管理和运营的问题。这是大家在项目管理上需要去考虑的一个因素。
模型上线，大家肯定都要看效果，有时候大家过于关心模型精度怎么样。实际上由于很多不可控的干扰因素，模型理论精度就不一定高，否则反而过拟合。那些不可控因素甚至可能占了五成，你根本控制不住。
最终我们还是从模型上线的业务价值来看，设备的故障预警模型，上线之后是不是真的成功发现早期故障？工艺优化、质量控制模型，是不是提高了成功率、提高了良率、提高了产能？当然，指标是综合的表现，有些是模型作用，有些可能跟模型有关，但不见得是模型直接影响。
怎么设计和评价这些指标，不是一个技术问题。如何去定义模型的业务闭环，是弱闭环的决策支持，还是强闭环直接去干预生产过程，是业务和管理问题。当然，真正能做到强闭环的模型，市面上比较少。
如果模型上线之后没有任何的监控，出现问题就只能等业主那边反馈，比如在模型作用下的某台设备成功率不如人工作用的那台设备了，然后被动去查找原因。如果没有提前做好设计，没有对每一个关键节点的相应输出结果做好关键动作监控，那追溯本身就非常困难。
长流程生产可能有好多道工序，每道工序都会有相应的检测结果。借鉴到数据工程领域，从数据接入、数据清洗、数据准备、特征提取切分、再到模型载入、模型预测等等一系列流程，每个节点都要监测是否正常运行。一旦出现异常，是某些算法或者不常见的bug导致，还是数据本身就有异常。如果是数据质量本身的问题，单纯评估模型就没有意义。
很多时候，客户反馈模型又有问题了，实际查证发现大部分时候是数据的问题、设备本身的问题，或是一些特殊工况、异常事件，极少情况是模型本身的问题。但为了避免责任不清带来的争议，从最开始的接入到最后的预测，每个节点都做埋点监控，用事实说话，才能更快速定位问题、解决问题。可以用这套标准去推进模型的优化和更新，包括以后新模型上线之后的效果监控。跟其他的软件工程一样，模型运行的性能也需要进行监控、评估，也有相应的运维工作。
全链的监控措施下，一旦出现问题，通常处理流程是什么？
从分析的方式来说，报出异常，比较传统的方式是日志，埋点也会有相应的结果输出。如果在某个时区段某个埋点异常多发，对应业务指标下降，我们可能会做关联分析，做一个强关联的推测。例如设备或零部件更换之后呈现良率下降或者呈现波动的明显趋势，我们可以做一个强化监控，能一定程度上推测是模型本身的问题，还是实际现场操作造成的一些异常。
例如设备健康、故障预警类的模型，遇到设备大修之后，基准肯定就变了，因为整个设备要拆，传感器、控制器都要重新调整。数据模型有一个天生的缺点，它是基于过去那段时间的数据表现来建模，很有可能调过之后，数据表现会发生一些偏移。之前我们做一套大型电机的振动预警，大修前某指标量平均水平差不多在12-13左右，大修后就变成15-16，都挺正常的，因为报警线在40。但出现波动，模型肯定会报警。这种情况下，这个模型需要被重新调整。与之类似，有些生产工艺调整之后，配套模型也得做一些微调。
模型跟现在的设备、现在的数据已经不匹配了，其实就是业界常说的模型漂移问题。我们确认不是人为、不是设备的、不是网络或是数据的问题，那模型该重新训练就得重新训练。
模型漂移后，能不能让一般的数据分析师也可以快速重新训练，让这个模型继续工作起来？
从数据采集的角度，某一条产线或者设备上原来的传感器比较少，但在当时的条件下已经是最好了。我们在既有条件下建模，过了段时间，可能新线上来了，或者技改增加了传感器，数据量增加了，模型就面临调整。
以这个场景为例，采集频率高了、数据多了、变量多了，肯定是好事。至少把它又变成少数量低采样频率的情况下，按照业务指标去衡量，原来的模型依然工作，那就先让它继续运行着。但凡做的还是同一个设备，解决的是同一个问题，那数据科学家开发算法的时候就有义务让所做的模型能抓住设备和数据的问题本质，不会因为这些改变，让这个模型又得从头开发一遍。这个底线是肯定的。
通常来讲，更多的数据、更高的精度，确实会带来更多的输入，方便加工一些其他的特征。基于模块化的架构，我们可以在这些新的特征基础上很快实现新的探索和模型的更新，让模型更精准，不需要从零重新去训练模型。
一旦面临需要重新训练的情况，我们需要注意中间结果的输出，随时评估模型训练的效果，比如预测标准有没有改善，之前好的对象有没有变差，坏的对象有没有变好，类似的对比工作是必要的。
除此之外，如果这套流程已经完全跑通，规模复制的流程还要按照SOP的形式落到纸面上，需要输出哪些内容，保证这些模型的效果和以前是相似的，或者是更好。作为新入职的工程师，能不能按照这样的方式去复制这一套形式，而不再需要更多的去理解这个过程。
