最终我们还是从模型上线的业务价值来看，设备的故障预警模型，上线之后是不是真的成功发现早期故障？工艺优化、质量控制模型，是不是提高了成功率、提高了良率、提高了产能？当然，指标是综合的表现，有些是模型作用，有些可能跟模型有关，但不见得是模型直接影响。
怎么设计和评价这些指标，不是一个技术问题。如何去定义模型的业务闭环，是弱闭环的决策支持，还是强闭环直接去干预生产过程，是业务和管理问题。当然，真正能做到强闭环的模型，市面上比较少。
如果模型上线之后没有任何的监控，出现问题就只能等业主那边反馈，比如在模型作用下的某台设备成功率不如人工作用的那台设备了，然后被动去查找原因。如果没有提前做好设计，没有对每一个关键节点的相应输出结果做好关键动作监控，那追溯本身就非常困难。
长流程生产可能有好多道工序，每道工序都会有相应的检测结果。借鉴到数据工程领域，从数据接入、数据清洗、数据准备、特征提取切分、再到模型载入、模型预测等等一系列流程，每个节点都要监测是否正常运行。一旦出现异常，是某些算法或者不常见的bug导致，还是数据本身就有异常。如果是数据质量本身的问题，单纯评估模型就没有意义。
很多时候，客户反馈模型又有问题了，实际查证发现大部分时候是数据的问题、设备本身的问题，或是一些特殊工况、异常事件，极少情况是模型本身的问题。但为了避免责任不清带来的争议，从最开始的接入到最后的预测，每个节点都做埋点监控，用事实说话，才能更快速定位问题、解决问题。可以用这套标准去推进模型的优化和更新，包括以后新模型上线之后的效果监控。跟其他的软件工程一样，模型运行的性能也需要进行监控、评估，也有相应的运维工作。
全链的监控措施下，一旦出现问题，通常处理流程是什么？
从分析的方式来说，报出异常，比较传统的方式是日志，埋点也会有相应的结果输出。如果在某个时区段某个埋点异常多发，对应业务指标下降，我们可能会做关联分析，做一个强关联的推测。例如设备或零部件更换之后呈现良率下降或者呈现波动的明显趋势，我们可以做一个强化监控，能一定程度上推测是模型本身的问题，还是实际现场操作造成的一些异常。
例如设备健康、故障预警类的模型，遇到设备大修之后，基准肯定就变了，因为整个设备要拆，传感器、控制器都要重新调整。数据模型有一个天生的缺点，它是基于过去那段时间的数据表现来建模，很有可能调过之后，数据表现会发生一些偏移。之前我们做一套大型电机的振动预警，大修前某指标量平均水平差不多在12-13左右，大修后就变成15-16，都挺正常的，因为报警线在40。但出现波动，模型肯定会报警。这种情况下，这个模型需要被重新调整。与之类似，有些生产工艺调整之后，配套模型也得做一些微调。
