5%的时间做算法，95%的时间做工程_google 数据分析师只有5%的时间花在-CSDN博客

探讨一下算法工程师的工作体验问题。

1. 一地鸡毛的现实

从我最近几年观察来看，在很多算法团队，算法工程师不是算法工程师，更像是运营开发工程师或者业务规则工程师（当然也有不少团队不是这样的）。“根本不是来提特征调模型的，是来实现业务规则的”，“5%的时间做算法，95%的时间干工程”，“拉通数据花了我2周，模型训练一天搞定”。这些都是算法工程师常见的体验。看得开的会说，“这也许就是工业界的现实吧？”，看不开的则会说，“这也许就是工业界的现实吧！”。

2. 应然和实然的冲突

2.1 事情应该是这样

首先从事情本身来说。问题建模->打通数据->数据分析->提取特征->训练模型->模型预测，这个算法应用流程中，和提升效果联系最直接的工作有问题建模、数据分析、提取特征和训练模型。其中问题建模，基本是一锤子买卖，而且套路也比较固定，因此算法工程师要想提升效果应该在数据分析、提取特征和训练模型上下功夫。数据分析、提取特征和训练模型最需要的是模型调优和数据分析能力。

我们的教育系统很好地教学了我们的算法工程师模型调优能力和数据分析能力。在研究生教育阶段，未来的算法工程师主要工作就是发论文做项目。实验室的数据要么是公开数据集，要么是项目合作方处理好的。这些静态数据集使得打通数据不需要了，模型预测变得非常简单。未来的算法工程师只需要提出 Idea，并反复进行数据分析、提取特征和训练模型，一般就能得到良好的效果。模型调优能力和数据分析能力在此过程中得到极大锻炼，甚至一些优秀的学生在这方面的能力积累，能够超过 5 年正式工作的员工。

2.2 事情实际是那样

2.2.1 工业界对算法工程师的要求

工业界对算法工程师的工作职责，是把算法应用在自己负责的业务场景中。但是在工业界，生产系统毕竟是一个非常复杂的系统。

数据是线上系统来的，充满了脏数据，并且获取流程复杂；模型直接应用线上系统，需要模型上线以及各种线上后处理过程。这些特征导致问题建模->打通数据->数据分析->提取特征->训练模型->模型预测中的打通数据和模型预测工作量很大。

如果没有相关团队的支持，那么打通数据和模型预测相关的工作，就只能由算法工程师承担了。因此打通数据和模型预测要求的离线任务能力（Spark, Flink）和在线任务能力（C++, Golang）。在整理数据和模型预测上会花费大量的时间，数据分析、提取特征和训练模型上的时间非常少。这也是 “5%的时间做算法，95%的时间干工程” 说法的来源。

2.2.2 这个要求不合理

但是这个要求不是合理的。按照事情应该的样子来说，提升效果联系最需要投入时间的是数据分析、提取特征和训练模型，而不是在打通数据和模型预测。这两个任务的主要作用是拉通流程，对提升效果是辅助性的工作。

另外，从算法工程师的普遍的教育背景来说，算法工程师做这些工作效率不高也不专业。一些算法工程师本科是计算机科班，上过数据结构和算法课程。另外一大部分算法工程师，其中一些还很优秀，是非计算机科班甚至非理工科，没有上过数据结构和算法的课程。当然有一些算法工程师自学数据结构和算法课程，但毕竟少数。整体来看，现在工业界中，上过数据结构和算法的课程的算法工程师就不是占绝大多数。即使上过数据结构和算法课程，也不见得是认真学通数据结构和算法，从而提升工程能力。算法工程师的算法和数据能力优秀，而工程实现能力偏差，做这些明显工程性工作会比较吃力。

3. 实然走向应然之路

那么怎么解决这个问题呢？或者说有没有办法解决这个问题呢？

办法总比问题多，但是解决这个问题的办法都指向了理念的改变——要认识到算法工程师是 “娇贵” 的。这里说的 “娇贵” 不是说具体某个算法工程师没有办法承担重任，相反我认识的大部分算法工程师都有想法有干劲有实力。这里说的 “娇贵” 是指，算法工程师需要后台开发帮忙开发线上服务和策略，需要数据开发帮忙开发数据流，需要运营开发帮忙开发配置和分析系统，才能把自己精力集中在提升效果上来从而发挥算法工程师应有的价值。为什么很多算法团队的现状是一地鸡毛呢？主要很多算法团队的老板们，并没有真正意识到算法工程师是 “娇贵” 的工种——要想让算法团队有所产出，除了算法团队本身之外，还需要配置强力的支持团队才行。

如何配置强力的支持团队，是有讲究的。

3.1 明确指挥关系

最重要的事情是，明确算法和支持团队之间是指挥关系。这句话的意思是，算法对支持团队要做什么以及做出来的东西怎么使用，有明确的决定权。不要怀疑你刚刚看错了，就是明确算法对支持团队的工作内容有决定权。这个决定权既可以通过需求评审和技术评审中的一票否决来实现，也可以走得更极端建立汇报关系来实现。但是这个决定权能否落到实处，还要看算法团队的能力建设，就是算法工程师中有没有工程能力优秀的人。如果算法工程师中没有工程能力优秀的人，即使组织上制度上给了这个决定权，也没有人站在算法需求的角度上梳理和评审工程技术方案。

有人要问了，如果是指挥关系，那么支持团队的成就感怎么办。我们拿工程团队为例。工程团队的目标本来就不是决定做什么和做成什么样，而是应该把系统做快做强做通用。一般工程团队做什么或者做成什么样是由产品经理决定的，现在只不过把产品经理换成了算法工程师而已。

3.2 明确支持团队的人力结构

大家有一个疑问，支持团队比如数据团队，是不是招聘一些算法工程师比较好，比较能理解算法的需求。我的理解是支持团队一定不要算法工程师，负责线上的直接找后台开发，负责数据开发的直接找数据开发，负责数据洞察的直接找数据分析。在支持团队的算法工程师也是算法工程师啊，算法工程师的探索新算法用于提升效果的本能以及制度要求，是不会改的。这个时候，不在提升效果第一线的算法工程师，很容易脱离实际场景做一些实验性验证性的算法模型。“一线战场已经炮火连天了，支持部队还在风花雪月”。

拿我们团队做例子。2018年 11 月之前，我们团队工作模式是 “算法负责离线立场，后台负责线上流程”。从 2018 年 11 月（我们内部 golang 推荐服务框架开发完成）开始，我在老板支持下花了半年时间，推动了 “算法工程师全流程负责算法应用”，包括线上服务开发工作。但是在 2020 年 10 月份，我发现开发线上逻辑占据了算法工程师大量的时间，不剩下什么时间来做尝试新算法了。虽然 “算法只负责离线流程” 的时候，算法工程师就有说法 “5%的时间做算法，95%的时间干工程”，但是 “算法工程师全流程负责算法应用” 无疑是加剧了这个问题。想来想去，为了让算法工程师腾出更多时间来提升效果，我改成推动恢复 “开发负责线上服务而算法只负责提升效果”，同时还要增加数据开发负责数据流开发。现在还处在转变中。

4. 总结

刚从学校出来的工程师的能力模型和工业界需求不匹配，我们的第一反应是学校教学内容落后了，没有满足工业界需求。但是算法工程师的种种不适应，我个人倒是认为，工业界没有好好想清楚，算法工程师怎么样才能发挥作用。