MLOPS概念是什么意思

        MLOps (mache learng operations)是用来帮助机器学习有关人员更加高效的开发以及维护机器学习生产线。我个人的理解有点像是服务机器学习的devOps。机器学习的生产线大概有三步，这三者环环相扣，最好能够形成一个反馈系统，也就是说运维的输出能够反哺到第一步的算法设计。这样一来，整个系统就会健康地运转起来，更多的数据意味着模型的进一步优化。

为什么会有这个岗位，为什么需要他？

要搞清楚这个问题，得看现在的机器学习项目本身有哪些需求，也可以理解成best practices。

机器学习项目是可以共同合作的

机器学习项目不是一个黑盒子，只管进出。相反，从数据提取，到模型开发，甚至到的监控，这些环节都要求是透明的，牵一发动全身是能够量化的。

机器学习模型是可以复现的

相对于传统的软件开发，做好了代码的版本管理，基本就可以实现复现。机器学习模型的复现要求会更高一些，除了代码的版本管理，数据也需要做版本管理，甚至是整个fra的平台也需要做版本管理。简而言之，给我一个fra平台的版本号，给我一波数据的版本号，给我一个代码的版本号，我就能够重新复现模型。

机器学习是可持续的

这个概念就是之前提到的，模型训练不是一次性的事情，随着场景的增加，对模型的要求会越多越多。所以这时候就需要保证机器学习这个pipele是可持续的，喂进去新的数据，我能够重新训练得到新的模型。

机器学习是可以测试和监控的

这一点和传统的软件开发很像，只不过对于机器学习来说，他观察的指标相对于传统软件开发会更多一点，比如说模型预测的各种指标，期待的表现等等。

明确了上面几点需求，我们就会发现现在的机器学习从业人员或者fra团队很难满足这些。

算法工程师会主要钻研于模型的设计，他的最大目标可能是提升模型的精度，

传统的fra团队他又不太了解机器学习，很难有针对性地服务机器学习项目。

这样一来，也就有了这个交叉的领域，MLOps，专门针对Mache Learng的Operations。

MLOps能带来什么好处呢？

支持scale up，数据变多不再变得可怕，人员变多不再变得可怕，项目变多不再变得可怕

减小风险，减小了由于人工操作所带来的很多的风险，因为自动化意味高效和稳定

各司其职（这个是我自己的体会），算法工程师就只需要关注算法模型的提升，数据工程师就只需要关心数据的分析和获取，fra/IT就专注去搭建工具。中间很多的交叉活统统交给MLOps去搞。

MLOps具体要干哪些活呢？

回答这个问题，其实也就是对应上面聊过的需求，而提出的解决方案。

为了实现上面这些best practices，需要具体从哪几个方面入手？

搭建可以共享的fra平台，比如说数据的管理，代码库的管理，docker的管理

代码，数据，模型做版本管理，做到每一个mit都有迹可循，每一个模型都有相应的metadata

搭建机器学习pipele，可以跑end to end的模型训练，（而不是人人都有一套祖传的pipele）

搭建测试和监控环境，确保模型是在预期的表现

那么从何做起呢？

既然已经知道了MLOps是多么多么的好，从道理上感觉也说得过去，那么应该怎么开始呢？

说句实话，我现在还没太多的发言权。

这个问题有点难。

这里面临的难点是，

团队人员结构的改变，每个人员责任的变化

改变用户本身的使用习惯

技术方面，相关的机器学习平台各种各样，也不是套一套就能解决所有的问题，哪些用开源软件，哪些需要自定义，哪些需要去买license

前期的坑很多，搞了半年不一定能立马见效，然后可能就没机会了（就像机器学习模型本身是就应该慢慢迭代增量，这个机器学习平台也是如此，只有经过慢慢地迭代调整，才能找到最合适团队，最合适商业的方案。）

        我个人的理解是，确认好大方向，就是刚才提到的那几点best practices，然后结合团队现在的痛点，慢慢往里面助力。比如说之前大家没做数据的版本管理，然后发现无法复现模型，那么你就可以整一套数据的版本管理，模型的版本管理，来解决这个痛点。又比如说之前大家没有模型的监控，出了问题，过了几天才知道，你就可以设计实现相应的监控平台来帮助。总而言之，这个MLOps的Best practices让我感到兴奋，感觉这就是一个项目应该有的样子。在接下去的日子，我希望多记录自己在这个方面的实战体会和感悟，也欢迎各种大家来交流。下一期我就准备介绍下我所了解的MLOps的社区，帮助新的从业人员能够快速地进入这个领域。