导读：在这篇文章中，我们阐述进行有效的数据产品开发的关键要素。数据产品都是算法工程师们开发出来的，我们就从算法工程师的算法水平开始聊聊。

最近两年，我一直跟IT公司里面的算法工程师们一起工作，自己也算一名算法工程师，也面试过各个级别的算法工程师。来了IT公司之后，我刚开始面临的一个很大的问题，短时间内很难看清楚申请人真实的算法水平。主要难点有两个：

大部分刚入职的同学几乎没有任何学术论文，所以我只能依靠前面几位同事对他／她的算法编程能力的考核。
对于一些从不知名IT公司过来的候选人，简历上都说自己参与了各种线上项目的开发，但是他们在这些项目中的作用到底是啥，根本不清楚。问题的复杂度和算法的效果也不清楚。

这两个难点就是短时间内，没有一个可信的标准来衡量对方的算法水平。

我在学界做了快20年的研究，培养了一批人才，一部分人去了学术界（NYU，UNC，Emory，UoT，Purdue，Yale，UoA，FSU等），另一部分人去了工业界（像Uber，DiDi，高盛等）。在我实验室的几年中，他们都是跟我一起研究某个应用场景内的一些有意思的问题，收集和/或处理相关数据，设计各种算法，与推导相关的理论。在学界中，我也面试了许多青年才俊们，主要看他们的推荐信，发表的文章，与面试的交谈和学术演讲。在这种情形下，高水平的文章/专著一直是在学界中找到好工作的必要条件。在顶刊/顶会发表文章的数目以及被引用的次数一般被认为是可信的标准，因为这些地方大部分审稿人的要求都是非常高的，标准基本上就两个:

这个问题本身有没有大的意义，这个意义可以是学术上的，科学上的或商业上的；
你的算法和理论能不能真正极大地解决该问题

我现在考察面试人的算法水平, 主要是基于面试人常用的算法来问如下几个基本问题：

相关模型会不会调参，有啥心得？
对该类算法理解的深度和广度如何？
为啥有时候某个算法不好用，为什么？
如果这个算法不好用，你能不能开发出更好的算法？

许多没有受过严格算法训练的同学们经常到第二个问题的时候就卡住了。对于中高阶的算法工程师，最好还要有高质量的学术论文/专著或被行业所广泛认可的产品，这些积累反映了他/她对一类问题的深度思考，这就是一种可信的硬性标准。相对应地，在Google的Deepmind工作过几年的同学，大家一般会认为其实力应该不错，因为Deepmind本身就代表了一个可信的软性标准。一个好的算法团队最好有许多有软硬实力的算法工程师，但问题是高效的数据产品开发到底需要什么样的算法工程师呢？

更进一步地，这几年我们接触了许多算法同学，天天跟他们一起工作，几乎每天都听他们聊各种模型（像X-learner，XG-boost，CNN，Transformer，GCN，U-net等）以及它们的各种技术指标（像AUC，F-score等），最后也说离线和在线的业务指标（像ROI，GMV等）。但是，我们几乎不可能把他们的算法都拿来跑跑，对所有的算法细节都把关，那我们如何保证数据产品开发的质量？

首先，在数据产品开发中，选取好的业务指标是保证数据产品质量最重要的标准，定好合理的业务指标是所有数据产品应用层实现技术落地的核心。

有时业务指标挺直接的，比如说跟人生安全相关的产品，降低事故率和死亡率可能是一个常用的业务指标。但是，许多跟用户生命周期管理相关的策略, 包括拉新、促活、留存、和召回等，评价这些策略好坏的业务指标就没有那么简单。许多公司都是以生命周期总价值（LTV）为公司的业务指标，就是公司从用户所有的互动中所得到的全部经济收益的总和。在个人的维度上就是“顾客终生价值”，指的是每个购买者在未来可能为企业带来的收益总和。如果我们进一步考虑用户对公司利润的贡献，它也可以分为新生期，成熟期、衰退期，沉默期，和再激活期，LTV也可以被进一步拆解为用户量、留存率、活跃度（DAU）、和每用户平均收入等核心的业务指标。另外一个最常用的指标是投资回报率，它的英文名为Return on Investment（ROI）= （税前利润/投资总额）x 100%, 它经常被用来衡量各种运营策略的效果和效率。对于运营策略来说，一个深层次的问题就是LTV和ROI哪个是更好的业务指标？因为篇幅的缘故，我们不在这里阐述这个问题，请注意以后的更新。

其次，在数据产品开发中，我们要考虑两类技术指标：算法的技术指标和模型的诊断统计量。大部分数据产品都是可以拆解为一系列分类和回归模块的有机组合。

算法的技术指标（https://zhuanlan.zhihu.com/p/84665209) 可以根据分类和回归的算法来分类。具体的，分类算法的常用技术指标包含精度、准确率（查准率）、召回率（查全率）、F得分、AUC （Area Under Curve）、Gini系数、增益图和 KS（Kolmogorov-Smirnov）等。比如，增益图广泛应用于目标定位问题，以在特定的活动中确定用户在哪个十分位数上，然而K-S是衡量正负例分布分离程度的指标。回归算法的常用技术指标包含平均绝对误差、均方误差、对数损失、均方根误差、决定系数和校正决定系数等等。
我们还要考虑模型的诊断统计量，因为算法的技术指标并不能完全反映模型核心假设的合理性。这里就是用统计学中一些模型诊断工具来找出数据中的异常点和强影响点，以刻画数据的分布，选择更好的损失函数，和增加模型的泛化性。
算法的技术指标一般都是宏观指标，然而模型的诊断工具大部分是给定模型下，有关数据点的一些微观指标。

有了这些准备，我们再谈谈在数据产品开发中技术指标和业务指标之间的关系。

1. 数据产品的模块拆解和开发

做好一个数据产品，另一个重要的是如何有效地把业务指标拆解成各个模块，找到一条清晰的解决思路，依此进行相关的数据建设，算法开发与系统优化。为了达到这点，有两个关键点：

对业务的深入理解，这个需要相关算法工程师长期在业务里面跌爬滚打，找到解决问题的关键点。
相关人员对各类算法的深度和广度的有效把控，能够把每个模块真正建设起来。
各个公司最需要的是既懂业务又懂算法技术的算法工程师，这种人才是数据产品开发的关键。

2. 模块的泛化性

在每个模块的开发中，我们一般收集一组/几组训练数据集，构建一组模型，用交叉验证法从算法的技术指标和诊断统计量得到反馈，选择模型，改进模型，直到达到一定的准确度。

模型的泛化性是指模型对新数据集的适应能力。模型在训练数据集上取得好的准确度并不能保证上线后模型的泛化性。
有一个论断就是如果测试集足够大，好的准确度就能保证好的模型的泛化性，其实这个论断不一定对。
保证模型的泛化性最关键的一件事情是进行高效的和有序的底层数据建设，并学到隐含在数据背后的因果关系，这样我们的模型对具有和训练集同意因果关系的数据也会适用。

3. 技术指标到业务指标的转化

一般来说，所有模块上取得好的技术指标不能自动地转化为好的业务指标，这个依赖于对业务指标的有效拆解。拆解好了，一些模块的技术指标做得差点对提升业务的指标影响可能不一定很大，所以做产品的过程中，我们一定把整个流程跑通。再找到一些关键模块来优化，但是在一定成本之下，大家还是都希望把每个模块的技术指标做到极致。这个问题是落地最难的点，需要更多的案例来剖析其中的深度。

最后，我们以阿尔法围棋这个数据产品为例. 它的业务指标就是下赢对手, 它被拆解成四个模块，形成一个完整的系统。