延伸(1)-ML接入团队的原本开发生态 | ML#Day29

背景提要

团队走DevOps文化，所以频繁地沟通理解，以及任何东西考虑对於系统的定位，已经是我们再熟悉不过的工作思维。

微服务化的系统，就我自己的解释，会说每个部件专注在自己的业务，系统其他的部分会了解这个部件在做什麽，以及这个部件跟系统的关系和交互作用是什麽就好，但细节处理交给每个部件自己管理好。

人员的作业也是一样，对自己负责的范围专注且负责，同时了解系统其他的部分对自己守备的范围有什麽交互作用，自己的东西调整或新增会影响系统的什麽，又或者别人守备的范围调整的时候，主动思考自己的部分会被影响什麽。

那麽想要把ML的东西放入团队的生态系，我们要怎麽将它摆到正确的位置呢？

首先，可以专心研究ML的人员，大概只占不到团队人数的1/5，这意味者大部分的人无法有多的时间持续吸收相关知识，而且我们都缺乏相关的背景。

专职的人员一样负责掌握细节，但对於ML的定位和理解，是前所未有的经验。

这个东西不是新的程序语言，也不是新的DB，或者另一种CI/CD自动化工具，或者类似目前系统的任何一个服务。

所以我们花了几周的时间陆续讨论和解释，AI或者说ML大概能做到的事情，以及可能对於系统和商业能够带来什麽帮助。

最终至少大家大致明白了ML不是万能的圣杯，想怎麽许愿就怎麽许愿，模型无法处理所有问题，而且非常多的局限性。

没有错误的理解，就没有错误的期待，而且模型出来的东西有一定的误差，只能作为次要的辅助判断，而非绝对的指示。

当成员原本就知道自己产品的商业模式，又了解了ML的限制和提供的可能价值，大家就可以一起参与发想应用的方式，以及系统每个部分可以提供什麽协助。

ML的东西就不会被排除在外，反而受到我们原有的生态系统扶植，如果计画能够持续下去，相信经过时间的长，所能看到的效果越显着。

另外或许训练模型和统计资料分布需要比较专精的知识和技能，但尝试抓到重要的参数或因子关系，只需要众人的观察和想像，这个部分能够越多的脑力支援越有帮助，尤其现在又有Vertex的帮助，收集新的参数有没有发挥作用，Vertex自动化的判断会告诉我们，我们只需要更多的尝试。

能够快速的迭代，从错误中寻找价值，给予我们这种ML外行团队很大的帮助，以及建立一种有效的经验学习方式。

在大家逐渐认识到资料收集和处理的复杂和重要性，这部分很多人就可以帮忙协助，因为对於後端工程师，无时无刻都在处理资料，我们已经有许多处理资料的经验，现在只是想要交给ML，尝试将资料进一步的应用。

所以与其说是跨足新的项目，我会说对於原本的工程师团队，不如想作是价值的延伸，既然是整体价值的延伸，我们就更有共识地同进同退。

当模型完成後，团队对於服务与系统Ops(部署、维运、管理)的流程也是熟门熟路，除了选择Google提供的课金代管服务，这部分又可以另外选择交给其他成员帮忙，让探索ML的人员专注在研究资料与模型的处理上。

这又回到专注业务细节，又能够交融於系统的基础上。

虽然没有经验丰富的成员在前面拉拔着前进，但本质上我们也不会因为踏入AI的失败，而让部门会有绩效上的压力(感谢成员们工作的cover)，原本的任务还是持续进行着，大家也因为理解这是不确定的东西，没有一定会有效果的成见。

这两年Google也提出了新名词MLOps，描述了用商业应用的角度去看，ML code其实只是其中的一部分，要有相关的operation流程才算完整。

或许相比有的团队拥有ML knowledge，但是Ops相对辛苦，我们则是拥有Ops的基础，相对缺少的是ML knowlege，也就是说至少环境条件不算差，希望能够继续走下去。