算法开发有可能更高效吗

作为一个算法技术人员，学习了产品和开发的一些概念，例如MVP(minimum viable product）和敏捷开发的小步快跑。

最近在思考一个问题，为什么算法研发和上线总是那么漫长，那么不敏捷？

 

首先，算法研发，尤其是机器学习算法应用研发主要分为这几个部分： 方案，数据，和模型；

• 方案或者说业务需求，决定我们对于问题的归类和即将要采取的方法，是分类问题、回归问题还是聚类问题等。
• 数据决定了我们如何开展研发，满足需求。有什么数据，有多少数据，多久能拿到数据都至关重要，因为我们都知道：
• 再好的模型只是逼近数据自己本身的上限。

那么，算法应用的研发，也就自然而然要涉及到对接：

• 前期对接产品方、评估可行性，寻找解决方案
• 中期对接数据方，也就是服务日至或者大数据ETL的同学，获取我们需要的数据
• 中后期对接开发人员，把算法模型产品化上线
• 然后继续从数据方获取线上表现反馈，优化模型、解决问题再迭代到开发上线，如此反复。

到这里基本上可以看出来，为什么算法研发项目的周期都这么长，基本可以总结为以下几个原因：

• 第一个问题，业务理解问题。正常的业务需求发起，由业务方与产品进行对接，产品从产品维度进行理解和方案初步制定，再对接到算法研发，很多时候就这一层的对接，很容易导致需求误解、不完全是需求方向，而是需求的宽度边界，效果预期等不一致。那么算法开发就不完全理解业务诉求，自然沟通成本增加
• 第二个问题，研发链路太长。算法人员接到需求，需要先联系数据开发的同学，进行研发必须的数据抽取和准备，然后才能进行算法预研。如果数据本身不存在，那么可能还需要先设计埋点，开发上线，过上一个子版本的正常迭代才有数据回来。这里面不仅存在沟通成本，还存在多方配合的意愿度，排期等各种问题，一层下来，数据到手的时候，时间又过去了一部分。
• 第三个问题，算法团队能力闭环问题。有些算法人员，对于产品上线，不管是普通的服务端模型上线，还是终端（android）方面的产品上线，并不会直接进行把控，认为离线算法效果不错，上到线上也是一样，但是往往不如人意。究其原因，一部分是开发人员再数据准备方面不一定和算法离线的完全做到一致，另一方面一些算法同学缺乏对终端产品上线的review和跟踪能力 （比如一些算法同学可能完全不懂安卓，工作到模型转交即结束）。 自然会导致很多理解成本、沟通成本、和返工。

以上这些问题自然不能尽如人意全部避免，但是我认为通过一些组织上的、方法上的改进，一定程度上也能减轻一些成本，提升一些算法研发效率做到更加敏捷：

　　首先是算法研发人员应该多参与原始需求讨论，真正理解业务方的真实诉求，甚至从技术可行性上引导业务方的产品模式和方案。 

       其次，研发链路这个问题需要算法团队从组织架构上，对团队内部的能力进行拓展，不能完全沉迷算法原型验证。要从两个维度进行拓展，第一个是数据开发能力，指的是算法人员应该有一些关键数据提前预设和埋点意识，指导数据生产和储备，不能完全依赖于数据开发工程师做通用数据开发满足所有需求。第二个是，算法研发团队内部需要具有基础的数据ETL和抽取能力，尽量缩短数据准备周期和数据沟通成本，不仅是在开发预演阶段的数据获取，同时也是上线或者灰度后的数据抽取和分析能力。 

       再有，算法数据模型的交付不是终点。需要跟踪开发的进展，把控开发的数据准备，特征处理等问题，对自己的模型最终业务表现负责，而不是离线结果负责（然后互相甩锅）。 当然，这个问题本身没有这么简单，还涉及到例如项目主导权的问题，其中一个重点就是，一般而言，项目主导者对于整个项目的跟踪和交付都具有责任感而参与者则略弱。 所以这个问题的解决方案可能还包括任务边界的区分，和主导权的问题（本不该这么复杂o(╯□╰)o）