机器学习项目为什么未实现敏捷开发

wpppjwpppj
一直在非主流的互联网公司从事机器学习相关的工作,最近重温了两个老的概念:
  1. 敏捷开发,这种做法在我们公司的研发部门公司在运行;
  2. MVP(最小可行性产品),小步快跑,这个做法在我们的产品PM团队在试行。

而我带领的机器学习算法团队还是在按部就班的在进行着:确定目标-准备数据-训练模型-优化模型-API开发-上线-效果评估的的全流程中,并没有体现出一丁点的敏捷开发和MVP的意味。最近一段时间也在思考:是否我们的算法团队也能实现,敏捷开发或者MVP呢?

时至今日,还是没有找到很好的突破点,在此把我的思考过程发布于各位分享,看一下其他的大拿们能够点醒我。

实质上,敏捷开发的和MVP是为了适应互联网中两个思路:一个是分布式开发,替代过去的瀑布式项目管理,快速迭代开发,并快速纠正错误;二是快速试错,测试市场的反应,看一下产品的定位是否与你预期的一致,小而美,如果有效果了再快速扩大范围。不管是哪种方法,都体现了"快"的思想。

而我们现在做的机器学习项目,是基于业务的智能化的实现方式,和业务本身稳定性是息息相关的,照理说我们没有必要追求又好又快,这是个慢工出细活的事;举个例子,如果你是新兴业务,那么你的数据累积量不够,你做的模型可参考性不够,你的模型也很难做准;如果你是成熟的业务,你的数据累计量就足够了,机器学习的威力就更大一些,你可以把模型做的更准,可以持续的进行优化。但在很多特定的场景下,如果你项目拖得时间太长,那么对业务的帮助也就越小,他们没有足够的耐心等你一年、半年来获得成效,因为他们很多项目都是需要很快速的取得效果的,但是我们的很多算法项目并不能决定一个项目的成败,只能作为一个辅助手段来进行实施,所以从这点上要求我们需要更快速的相应号召,尽快的把算法做出来上线并持续的优化使得对业务的帮助最大化。

最近统计了一下我们之前实施的算法累项目,发现我们的流程实在是有点漫长,让整个项目的执行过程有点太过于拖沓,我们需要太长的时间。我们的有些算法项目从开始立项到正式上线这整个周期,长的有过一年,中的半年,短的也要两到三个月的时间,所以我想要scrum是不可能的事情。上线之后又有一些线上的问题,模型迭代或者修bug,首先定位问题,然后开发、测试到再次上线,又大半个月过去了,这一整套流程下来,模型起到的作用,影响业务的效果就大打折扣,有时候时机就失去了。所以我最近都在思考,为什么我们会这么慢,为什么我们不能快一点?

针对这个问题,我觉得我们现在的做法有些地方可以进行优化:

1、首先,部门结构可以做一些微调,我们的组织结构是:算法隶属于团队A,ETL工程师和API团队隶属于团队B,开发团队隶属于团队C,产品团队隶属于D,业务团队隶属于团队F,测试团队隶属于E。我不知道有多少公司是跟我们一样的组织结构,我挺赞同专业的人做专业的事情,可是这样的团队组织结构会导致出现一些潜在的问题:

  • 太多的团队合作,一个算法项目需要协调ABCDEF团队;跨团队合作最大的问题是沟通问题和资源优先级问题。沟通的问题只需要一个强大的项目Owner就可以了,他既当项目经理也又做其他的角色,这个角色总可以找人担当,问题不大;第二个问题就比较难了,大家都有自己的事情,如果此类型的项目多了,那么其他团队想要达到快速响应就很难了,我们经常会把BCDE团队集合在一起,讨论一下大家都比较空闲的时间,然后进行排期,如此几次,甚是劳心伤神,进行缓慢;有时候还不得不拉上各team的高级领导们进行协调,沟通;
  • 算法项目的上线需要产品团队和业务团队保持好相关的沟通,算法团队夹在中间,和业务偏离有点远,又无法直接对接开发团队,所以导致中间资源损耗,总是觉得上线个东西很辛苦;
  • 项目的责任人不清晰,没有一个明确的说法说:由哪个团队主导,所以会出现一些扯皮的事情;

以上列出了一些目前碰到的问题,那么对于其他公司的启发是:

  • 首先从团队A(算法团队)上进行优化,一个好的算法团队应该有自治能力,即有API的开发能力和数据开发的能力,这个在有些公司就是硬性要求的,我们目前还没有。我们假想一下,如果算法团队内部有能力封装API,那么开发团队只要调用API就上线模型了,同事因为从模型到API开发都是在算法内部团队内流转的,那么实现Scrum就有可能了。
  • 我觉得以后算法模型应用的趋势是类似这种微服务自治的方式,我们提供相应的API,供各调用方使用,在不同的场景使用,这样可以大大的提高代码复用、模型复用、减少很多重复工作;
  • 另外在算法团队的职能上看,如果要让算法发挥更大的价值,那么算法团队应该独立于业务和技术,应该是介于这两个之间,算法与技术和业务的结合就更紧密一些;根据不同的阶段,算法团队和这两个团队的关系是不同的,在前期和业务结合的更好一些,后期上线和技术结合的更紧密些;
  • 明确约定算法主导的项目有算法团队的人主导,对其考核KPI,对结果负责,这样才能让算法起到更大的作用;
  • 造成目前的一个问题还有一个原因是大数据平台数据的不可持续性,因为业务变化导致数据的变化太多,表结构变化了、建新表了、废弃旧表了、新增字段了等等烦心的事情。基于hadoop平台的数据应用流程,我觉得可以做一些微调,就是以前开发团队只管写代码,生产数据;我觉得可以多迈一步,开发团队既生产数据,也负责把D+1的数据导入到hadoop集群。这样做的话:

  1. 保持了线上数据与hadoop历史数据的一致性,开发团队会保证数据生产的有效性,其他团队的人可以畅通无阻的使用这些数据,这样就可以让每个人都是数据的消费者。
  2. 减少了数据团队和开发团队的多次交流和沟通,其他的任何团队,比如产品、业务的人可以直接取到生产上的D+1的数据进行加工,数据仓库工程师的人员可以全力去做下游的仓库建设工作。基于hadoop平台,各个团队都可以接触到非敏感性的数据,进行相关的数据分析工作。这样可以减少单纯查询数据的ETL工程师的人员,实现了很多的数据查询自治。养着这么多的数据查询工程师的人员,对他个人是没有成长空间的,工作又没有挑战性,很容易使得人员流失;
  3. 根据数据侵染和大环境的发展趋势,以后的方向是大部分的开发和业务人员都是数据分析个中高手,他们能轻松的接触到数据,又能至少做些简单的分析工作。比如产品经理,如果你都不知道你的产品的表现怎么样,你怎么去进行优化,业务都不知道自己的KPI的数据是什么,还怎么做业务。

以上就是我的一些思考,最后我想说的是,我对敏捷的思考有个漏洞,为什么我非要上线才知道效果呢?实际上做过算法的人都知道,算法模型大部分在Offline的时候都会有相应的评估指标,比如RMSE,auc,Recall,Precision,NDCG@,MAP...,所以我们能事先评估出来。但在实践中,我们发现这种Offline评估的效果总是和真实上线后不是完全match的在线上的模型受到的干扰很多,甚至会出现模型影响模型自身的情况,所以我们看实际效果的时候都是以线上的为准,因此才有以上说的重视线上效果的一些思考。

1 条评论