POC到小规模验证，已经有一定程度的困难，从小规模到大规模，存在的变量就更多。因为工厂讲究多元化，同一个工厂下的不同产线，自动化供应商不一样、设备供应商不一样、材料供应商不一样，等等。如果推广到不同的生产基地下的不同工厂，复杂度就更高。
以前在一个小范围片区里面，我们用一整套稍微大一点的模型去管理（不是现在意义上的大模型）100-200个机台，还能用。当把这个数量乘以10、乘以100，在全国范围覆盖的时候，管理起来会相当困难。
我们不可能在每一条产线，每次都花大量时间训练一遍。模型训练也不是一成不变的，例如批次的控制，上一批失败了，下一批怎么调，那上一批是成功的，下次怎么调？有可能两个厂商乘以两个供应商再乘以原材料种类的乘积，复杂程度就是几何倍数的增长，那模型就数不胜数。以前的方式就不再可用。
我们需要考虑，这里哪些是共性的，哪些是个性化的，我们怎么用模型组去更好的管理？
关联问题：怎样算大规模？分行业和场景而异。在机理相对明确、可变因素相对较少的时候，可能把单机模型扩到几百个，甚至上千个的规模，我们认为是大规模；但是有一些更特殊情况，场景复杂，影响因素比较多，能从一扩到十就很不容易了，扩到几十台机组，就算是大规模部署了。
以温度为例，温度的常见工况有升温、温度维持或者降温，这是简单的一个分类。如果在舱体容器里，温度和压力是同时存在的，那可能会存在既加压又加温的情况。但往往两者的速率不一样。可能是压力快速达到目标值后，迅速进入维持阶段，然后温度缓慢上升。常规定义可能就只是简单的升温升压阶段。
实际训练模型时，我们需要把它进行拆分、组合，相当于一个工艺段的两个细分阶段。如果类似的情况再增加就需要再细分，有各种可能的组合。不只是明面上的五种或六种工况，切分后底下可能是10种至20种工况，都得做针对性的交叉训练，模型组的概念就出现了。
模型组的定义很重要，首先群组内的核心算法和逻辑是一致的，要挑战的是工程化过程中不同的变量带来的差异性问题。但定义组不能太琐碎，否则后面开发、维护的工作量就会巨大；另外一方面，又不能定得太过粗放，否则无法覆盖或者解决上述提到的问题。很考验工程师的经验和技术能力。
模型的规模化，除了量变引发质变，还有时间周期上的持续运营问题。
算法可以规模化的上线之后，再往后可能还会碰到怎么去持续管理和运营的问题。这是大家在项目管理上需要去考虑的一个因素。
模型上线，大家肯定都要看效果，有时候大家过于关心模型精度怎么样。实际上由于很多不可控的干扰因素，模型理论精度就不一定高，否则反而过拟合。那些不可控因素甚至可能占了五成，你根本控制不住。
