公司组建一支算法团队的隐性成本都有哪些？

这个题目“隐性”一词特别精髓。作为工程师团队本身肯定有很多成本：招聘、团队维护、系统搭建、硬件支持等等，但是这都是“显性”的，所有的工程师团队都会有。而算法团队由于其独特的性质，自然会有一些其他的额外的成本。

这里的几个想法主要是针对中小型公司，以业务为主线，没有前中后台之类的架构一说。毕竟大公司资源丰富，靠堆人和砸钱能够解决大部分问题。

团队架构与业务 Ownership 不明确

公司工程师的团队架构一般有两种模式，一种是跟着业务线走，叫做垂直架构，每个业务线有单独前端、后端、数据等等；另一种水平架构，前端大组，后端大组，数据大组，对接所有的业务线。

算法团队有个特质，一方面其本身对业务的影响格外重大，比如推荐、搜索等等，应该为业务负责，适合垂直架构。但另一方面算法工程师与其他工程师日常工作隔离很大，内部又有大量资源复用的需求，需要日常交流讨论，适合水平架构成立算法大组，对接所有业务。

所以算法团队很多都是双重架构，有的是算法跟业务走，再有虚拟的算法大组，有的是实体的算法大组，内部有细分每个同学负责不同的业务。不同的方法都各有利弊，但是总体来说都不完美，容易有错位感 (misalignment)，经常感觉业务中重要的东西没人做、做的东西不重要、重复造轮子多、同学自己的成长也没有保障，这对于团队负责人、业务负责人、同学的个人成长、技术的选择等等，都有很大额外的开销。

算法产品迭代的产品与项目管理难

在做业务决定的时候，我们永远都会讨论 ROI （付出回报比）。这里面就是两个核心的因素：成本与回报。

成本往往是好估算的，要招多少人，买多少设备，租用多大的办公室等等，而回报的估算就极难。但至少对于有些用户功能设计我们知道肯定是好的，比如用户肯定需要搜索功能，更加顺滑的过场动画大家也喜欢。

但是对于算法产品而言，回报的估算基本就是一抹黑。组十个人的团队做深度模型就一定会出更好的结果吗？上了增强学习 KPI 就会涨吗？机器学习中大量的迭代方向：特征工程、排序、召回、采样、数据清洗、探索&利用等等，究竟那些方向值得花资源，花多少资源，能带来多大的回报呢？如果 ROI 不好，究竟是机器学习本身不行，还是团队负责人不行呢？我在之前的一个答案[1]中提到过：

由于不能直接观测一个人的对于推荐系统的喜好，而要同时观测一百万、一千万用户的体验，所有传统的对于产品体验评价的手段，都是毫无意义的。深入了解海量用户体验需要大量精细化数据支撑，同时理解机器学习模型的特性。整个行业都非常缺乏对用户体验直接负责的机器学习产品经理。 不仅如此，机器学习的产品迭代有一种完全不同的方法论，传统的瀑布流或者敏捷开发在这里都无能为力。不论是特征的选择，还是模型的改变，都有大量的不确定性，线下指标和线上指标往往也没有一定的定量关系。花多少精力，带来多少提升，一切都是在不确定的风险中迭代。能够为机器学习项目进度而直接负责的项目经理也少之又少。

对于兄弟团队前端、后端、数据的配合程度要求极高

项目有大小之分，比如前端改一改按钮，换一换颜色，不需要后端的配合，肯定是小项目。而算法团队的每一个新项目，肯定都是大项目：上一套推荐、搜索，都需要前端、后端、数据的大量支持。而就算上线了，数据团队也需要很多配合，而前端、后端的不少改动，可能影响数据质量，也会极大的影响算法本身的效果。一但出问题，“garbage in garbage out”，谁也不能确定算法的结果。

好的算法团队很难建立

不比不知道，一与其他工程师团队对比就显得**算法团队很“娇贵”：自己单独的存在不能输出，干啥都需要其他团队配合，其他团队改点什么东西还都会影响算法。不仅如此，算法团队输出本身还不稳定，可能干了几个季度对于公司的 KPI 也没有什么明显的影响。**记得以前翻译过一篇文章：

陈然：如何作大死地为创业公司招聘第一位数据科学家 但另一方面，算法的价值又是巨大的。做的好的公司靠着自己的方法论，把“算法驱动”[2]做成了核心竞争力，在业务上一骑绝尘，别人看不懂也追不上。我想这也是做算法有意思的地方吧。