AutoMLOps，建模的敏捷之路！
这是傅一平的第337篇原创
【与数据同行】已开通综合、数据仓库、数据分析、产品经理、数据治理及机器学习六大专业群，加微信号frank61822702 为好友后入群。新开招聘交流群，请关注【与数据同行】公众号，后台回复“招聘”后获得入群方法。
正文开始
AutoMLOps是自己创造的新词，来自于笔者对于建模实践的思考，当公司的精确营销体系达到一定规模的时候，模型的运营压力也在持续增大，特别是当你的在线模型超过100个的时候，靠人工优化显然会碰到瓶颈。
那么怎么办呢？
这个问题其实可以换一种问法，即在建模的整个闭环体系中，哪些是必需要人参与的，哪些是可以用机器替代的？
把可以用机器的环节全部替换掉，就是当前建模能达到的极致速度。笔者认为AutoMLOps是一种可以追求的解决方案。
AutoMLOps是什么？
当你端到端的运营一个模型的时候，其实经历了业务分析、数据准备、模型训练（含评估等）、模型发布、在线预测、效果收集等过程，通过这些过程的闭环迭代不断来提升模型效果。
现实中我们去做建模，对于其中的每个过程往往都是线下人工操作。
1、业务分析就不用说了，全要靠人
2、数据准备往往要临时建一张宽表，训练前要基于宽表去生成样本和测试集，然后还要将样本倒入到挖掘引擎，生产发布的时候也涉及到宽表的构建。
3、模型训练往往要依赖经验做一些调参，面对神经网络这个调参工作量很大
4、模型发布一般要走线下流程，现在DevOps很火，CRM领域搞DevOps如火如荼，但建模领域对于这一块并不感冒
5、效果收集基本是线下的，数据准备还要重来一次
6、以上的流程基本是割裂的
你能很容易的理解为什么数据建模大多时间花在了非核心的工作上，比如变量准备就耗费了70%。
但仔细分析又会发现，除了业务分析，其实上面列出的每个环节都可以做到一定程度的自动化，而且这些环节在流程上也是能够完全贯通的，数据建模其实是个系统工程，这意味着有很大的提升空间。
AutoMLOps是我认为的一种解决方案，它一方面要解决模型训练过程的自动化问题，即AutoML，另一方面要解决生产流程不畅的问题，即MLOps。
首先讲AutoML，示意图如下：
AutoML主要包括三种自动化的形式：
1、算法和算法超参数保持不变，使用最新的训练数据；
2、算法保持不变，改变输入和算法超参数
3、全部改变，在最新的数据上搜索最优的算法和超参数
当前已经有相关的自动化建模的引擎，当然也可以自己做，下面列出了三种典型引擎：
1、Auto KERAS
优势：谷歌支持，自然语言处理较好
劣势：扩展性差，多分类问题表现差
2、Auto -sklearn
优势：生态好，扩展性兼容性较好，流行
劣势：自然语言处理缺乏有效工具
3、TPOT
优势：扩展SKLearn，简单易用
劣势：扩展性差，超参搜索耗时大
如果能将这些能力集成到企业的挖掘引擎上，就可以有效降低调参的时间，它是整个建模工程自动化重要的一环。
其次讲MLOps，示意图如下：
主要分为关键的四步：
1、持续发布模型：模型发布要能做到持续集成和持续部署，无需人工干预，否则迭代速度就太慢了，这个涉及到敏捷的一系列工作。
比如我们的数据开发平台由于集成了挖掘引擎，就可以很方便的实现持续发布，但如果采用的挖掘引擎是商用的或者不够开放，要做到这一点就有很大的挑战。
2、在线进行预测：生产系统要能自动生成输入，比如按周期自动生成宽表，然后输出预测结果，并能自动推送到生产进行应用。
3、自动效果归集：生产系统的最终效果数据要能直接回到数据仓库，这个时候数仓和生产系统的协同就非常重要了。
为了确保自动归集，数仓就必须建章立制，比如明确回传接口的规范，现实中企业大量的线下操作阻断了数据回流的路径。
4、数据自动准备：数据仓库要能自动准备好挖掘宽表，并基于返回的效果数据自动生成样本和测试集，从而实现闭环迭代，挖掘宽表能否通用化是AutoMLOps成功的一个关键。
最近团队的小伙伴分析了近几年所有的数据挖掘涉及的变量，大概3000多个，然后抽象提炼出了一套通用挖掘宽表，可以满足存量90%以上的挖掘需求，这是一个很好的开始。
其实自己对做挖掘宽表曾经有过质疑，既然能设计出挖掘宽表，为什么现在的融合模型就不可以？
但康威定理说得好，有什么样的组织就有什么样的系统，对于数据也一样。由于做融合模型和做数据挖掘的是两拨人，意味着做融合模型的人可能做不出专业的数据挖掘宽表。
做数据挖掘的人能主动跳出来进行改进是天大的好事，至于是否要再整合则是以后考虑的事情。
AutoMLOps的理念最终体现为下图的两个圈，外圈是敏捷流程，内圈是自动化建模。
当然，AutoMLOps也面临着组织、流程和技术上的一系列挑战，要一把做成其实挺难，但可以循序渐进，以下是我们的一个规划示例：
第一步：线上流程打通，包括预测结果归集、数据自动准备，持续发布，敏捷建模试点可行
第二步：敏捷建模平台及工具改造完成，非核心模型实现敏捷建模
第三步：集成自动化建模成熟框架，模型自动化敏捷迭代规模化，核心模型实现自动化敏捷建模
总之，建模人员未来应该更多的关注业务和应用，不要被大量重复的工作拖了后腿，现在DevOps、云原生、微服务如火如荼，我们的数据和系统也要对建模人员好一点。
当然即使AutoMLOps完成了，也并不意味着模型本身会有很大的提升，但节省下来的人力可以去做更多有价值的工作。