mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2026-05-10 19:54:28 +08:00
del
This commit is contained in:
73
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/127 | 数据科学家基础能力之概率统计.md
Normal file
73
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/127 | 数据科学家基础能力之概率统计.md
Normal file
@@ -0,0 +1,73 @@
|
||||
<audio id="audio" title="127 | 数据科学家基础能力之概率统计" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/86/c6/863bae37f215993eb8312f7f6c5883c6.mp3"></audio>
|
||||
|
||||
学习人工智能的工程师,甚至是在人工智能相关领域从业的数据科学家,往往都不重视概率统计知识的学习和培养。有人认为概率统计知识已经过时了,现在是拥抱复杂的机器学习模型的时候了。实际上,概率统计知识和数据科学家的日常工作,以及一个人工智能项目的正常运作都密切相关,**概率统计知识正在人工智能中发挥着越来越重要的作用**。
|
||||
|
||||
和机器学习一样,概率统计各个领域的知识以及研究成果浩如烟海。今天我就和你聊一聊,如何从这么繁多的信息中,掌握能够立即应用到实际问题中的概率统计知识,以及如何快速入手一些核心知识,并能触类旁通学习到更多的内容。
|
||||
|
||||
## 使用概率的语言
|
||||
|
||||
概率统计中的“概率”,对于学习和掌握人工智能的诸多方面都有着举足轻重的作用。这里面最重要的,恐怕要数概率论中各种分布的定义。初学者往往会觉得这部分内容过于枯燥乏味,实际上,**概率论中的各种分布就像是一门语言的基本单词,掌握了这些基本的“建模语言”单词,才能在机器学习的各个领域游刃有余**。
|
||||
|
||||
值得注意的是,目前火热的深度学习模型,以及在之前一段时间占领机器学习统治地位的概率图模型(Probabilistic Graphical Models),都依赖于概率分布作为这些框架的基本建模语言。因此,能够真正掌握这些分布就显得尤为重要。
|
||||
|
||||
对于分布的掌握其实可以很容易。只要对少量几个分布有一定的认识后,就能够很容易地扩展开来。首先,**当你遇到一个实际场景的时候,你要问自己的第一个问题是,这个场景是针对离散结果建模还是针对连续数值建模?**这是一个最重要的分支决策,让你选择正确的建模工具。
|
||||
|
||||
当面对离散结果的时候,最需要掌握的分布其实就是三个:
|
||||
|
||||
<li>
|
||||
伯努利分布
|
||||
</li>
|
||||
<li>
|
||||
多项分布
|
||||
</li>
|
||||
<li>
|
||||
泊松分布
|
||||
</li>
|
||||
|
||||
这三种分布是其他离散分布的重要基础。对于这三种分布,记忆其实也相对容易。比如,任何时候,如果你的场景是一个二元问题(例如用户是否点击,是否购买),伯努利分布都是最直接的选择。当你遇到的场景需要有多于两种选择的时候,那自然就用多项分布。另外,文本建模常常可以看做这样一个问题,那就是在特定语境下,如何从上千甚至上万的可能性中选择出最恰当的字词,因此多项分布也广泛应用在文本建模领域。泊松分布则常常用在对可数的整数进行建模,比如一些物品的总个数。
|
||||
|
||||
**了解应用场景和他们所对应的分布之间的联系,是掌握这些“语言”的重要环节**。当你面临的问题是连续数值的时候,绝大多数情况下,你需要掌握和理解正态分布,有时候称为高斯分布。正态分布的重要性是再怎么强调都不为过的。任何你可以想到的场景,几乎都可以用正态分布来建模。由于中心极限定理的存在,在大规模数据的情况下,很多其他分布都可以用正态分布来近似或者模拟。因此,**如果说学习概率知识中你只需要掌握一种分布的话,那无疑就是正态分布**。
|
||||
|
||||
在理解概率分布的过程中,还需要逐渐建立起关于“随机数”和“参数”的概念。衡量一个分布是离散还是连续,指的是它产生的“随机数”是离散还是连续,和这个分布的“参数”没有关系。比如伯努利分布是一个离散分布,但是伯努利分布的参数则是一个介于0和1之间的实数。理解这一点常常是初学者的障碍。另外,建立起参数的概念以后,所有的分布就有了模型(也就是分布本身)和参数的估计过程两个方面。这对理解机器学习中模型和算法的分离有很直接的帮助。
|
||||
|
||||
当理解了这些概率最基础的语言以后,下面需要做的就是,了解贝叶斯统计中,怎么针对概率分布定义先验概率,又怎么推导后验概率。
|
||||
|
||||
了解贝叶斯统计不是说一定要做比较困难的贝叶斯估计,而是说,怎么利用先验概率去对复杂的现实情况进行建模。比如说,针对用户是否购买某一件商品而言,这个问题可以用一个伯努利分布来建模。假如我们又想描述男性和女性可能先天上就对这个商品有不同的偏好,这个时候,我们就可以在伯努利分布的参数上做文章。也就是说,我们可以认为男性和女性拥有不同的参数,然而这两个参数都来自一个共同的先验概率分布(也可以认为是全部人群的购买偏好)。那么这个时候,我们就建立起了一个具有先验的模型来描述数据。这个思维过程是需要初学者去琢磨和掌握的。
|
||||
|
||||
## 假设检验
|
||||
|
||||
如果说概率基础是一般学习人工智能技术工程师和数据科学家的薄弱环节,假设检验往往就是被彻底遗忘的角落。我接触过的很多统计背景毕业的研究生甚至博士生,都不能对假设检验完全理解吃透。实际上,**假设检验是现实数据分析和数据产品得以演化的核心步骤**。
|
||||
|
||||
对于一款数据产品,特别是已经上线的产品来说,能够持续地做线上A/B测试,通过A/B测试检测重要的产品指标,从而指导产品迭代,已经成为产品成败的关键因素。这里面,通过A/B测试衡量产品指标,或多或少就是做某种形式的假设检验。
|
||||
|
||||
你期望提高产品性能,那么如何理解假设检验,选取合适的工具,理解P值等一系列细节就至关重要,这些细节决定了你辛辛苦苦使用的复杂人工智能模型算法是否有实际作用。
|
||||
|
||||
首先,我们要**熟悉假设检验的基本设定**。比如,我们往往把现在的系统情况(比方说用户的点击率、购买率等)当做零假设,或者通常叫做H0。然后把我们改进的系统情况或者算法产生的结果,叫做备择假设,或者叫做H1。
|
||||
|
||||
接下来,一个重要的步骤就是**检验目前的实验环境**,看是否满足一些标准检验的假设环境,比如T检验、Z检验等。这一步往往会困扰初学者甚至是有经验的数据科学家。一个非常粗略的窍门则是,因为中心极限定理的存在,Z检验通常是一个可以缺省使用的检验,也就是说,在绝大多数情况下,如果我们拥有大量数据可供使用,一般会选择Z检验。当然,对于初学者而言,最常规的也是最需要的就是掌握T检验和Z检验,然后会灵活使用。
|
||||
|
||||
在选择了需要的检验以后,就要**计算相应的统计量**。然后根据相应的统计量以及我们选好的检验,就可以得到一系列的数值,比如P值。然后利用P值以及我们预先设定的一个范围值,比如经常设置的0.95(或者说95%),我们往往就可以确定,H1是否在统计意义上和H0不同。如果H1代表着新算法、新模型,也就意味着新结果比老系统、老算法有可能要好。
|
||||
|
||||
需要你注意的是,这里说的是“有可能”,而不是“一定”、“确定”。从本质上来说,假设检验并不是金科玉律。假设检验本身就是一个统计推断的过程。我们在假设检验的流程中计算的,其实是统计量在H0假设下的分布中出现的可能性。可能性低,只能说,我们观测到的现象或者数值并不支持我们的H0,但这个流程并没有去验证这些现象或者数值是不是更加支持H1。
|
||||
|
||||
另外,即便“可能性”低,也并不代表绝对不出现。这也是初学者常常过度相信假设检验所带来的问题。**比较正确的对待假设检验的态度,就是把这个流程提供的结果当做工具,与更加复杂的决策过程结合起来,从而对目前的系统、目前的产品有一个综合的分析**。
|
||||
|
||||
值得注意的是,和假设检验有关联的一个概念“**置信区间**”往往也很容易被忽视。尽管初看没有太大作用,置信区间其实被广泛应用在推荐系统的“利用和探索”(Exploitation & Exploration)策略中。因此,明白置信区间的概念很有益处,对实际的计算有很大帮助。
|
||||
|
||||
## 因果推论
|
||||
|
||||
最后我想提一下**因果推论**(Causal Inference)。因果推论不是一般的统计教科书或者工程类学生接触到的统计教科书里的基本内容。然而最近几年,这个领域在机器学习界获得了越来越多的关注。对于学习机器学习前沿知识的朋友来说,了解因果推论十分必要。
|
||||
|
||||
同时,对于工程产品而言,并不是所有情况都能通过A/B测试来对一个希望测试的内容、模型、产品设计进行测试,并在一定时间内找到合理的结果。在很多情况下是不能进行测试的。因此,**如何在不能进行测试的情况下,还能通过数据研究得出期望的结果,这就是因果推论的核心价值**。基于此,越来越多的互联网公司开始关注这个技术。
|
||||
|
||||
对于多数人工智能工程师而言,因果推论所需要的场景其实无时无刻不陪伴着我们。一个常见的情况是,我们需要用数据来训练新的模型或者算法。这里面的数据采集自目前线上的系统,比如一个新闻推荐系统。然而,现在的线上系统是有一定偏差的,例如比较偏好推荐娱乐新闻。那么,这个偏差就会被记录到数据里,我们收集的数据就侧重于娱乐新闻。那么,**要想在一个有偏差的数据中,依然能够对模型和算法进行无偏差的训练和评测,就可以运用因果推论为机器学习带来的一系列工具**。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了掌握概率统计基础知识的一些核心思路。一起来回顾下要点:第一,学习概率分布的语言对于理解、甚至是创造新的机器学习模型和算法都有着重要作用。第二,假设检验是常常被人工智能工程师和数据科学家遗忘的知识。然而,它对我们做产品开发却至关重要。第三,因果推论是一个新兴的统计和机器学习结合的领域,希望你能有所了解。
|
||||
|
||||
最后,给你留一个思考题,我们之前说到假设检验约等于我们计算统计量在H0里发生的可能性,那么,为什么我们不直接计算在H1里发生的可能性呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
117
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/128 | 数据科学家基础能力之机器学习.md
Normal file
117
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/128 | 数据科学家基础能力之机器学习.md
Normal file
@@ -0,0 +1,117 @@
|
||||
<audio id="audio" title="128 | 数据科学家基础能力之机器学习" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/21/45/21fa142ed738f4230d66594dc3175b45.mp3"></audio>
|
||||
|
||||
想要成为合格的,或者更进一步成为优秀的人工智能工程师或数据科学家,机器学习的各种基础知识是必不可少的。然而,机器学习领域浩如烟海,各类教材和入门课程层出不穷。特别是机器学习基础需要不少的数学知识,这对于想进入这一领域的工程师而言,无疑是一个比较高的门槛。
|
||||
|
||||
今天,我来和你聊一聊如何学习和掌握机器学习基础知识,又如何通过核心的知识脉络快速掌握更多的机器学习算法和模型。
|
||||
|
||||
## 监督学习和无监督学习
|
||||
|
||||
要问机器学习主要能解决什么问题,抛开各式各样的机器学习流派和层出不穷的算法模型不谈,**机器学习主要解决的是两类问题:监督学习和无监督学习。掌握机器学习,主要就是学习这两类问题,掌握解决这两类问题的基本思路**。
|
||||
|
||||
什么是解决这两类问题的基本思路呢?基本思路,简而言之就是“套路”。放在这里的语境,那就是指:
|
||||
|
||||
<li>
|
||||
如何把现实场景中的问题抽象成相应的数学模型,并知道在这个抽象过程中,数学模型有怎样的假设。
|
||||
</li>
|
||||
<li>
|
||||
如何利用数学工具,对相应的数学模型参数进行求解。
|
||||
</li>
|
||||
<li>
|
||||
如何根据实际问题提出评估方案,对应用的数学模型进行评估,看是否解决了实际问题。
|
||||
</li>
|
||||
|
||||
这三步就是我们学习监督学习和无监督学习,乃至所有的机器学习算法的核心思路。机器学习中不同模型、不同算法都是围绕这三步来展开的,我们不妨把这个思路叫作“三步套路”。
|
||||
|
||||
那什么是监督学习呢?监督学习是指这么一个过程,我们通过外部的响应变量(Response Variable)来指导模型学习我们关心的任务,并达到我们需要的目的。这也就是“监督学习”中“监督”两字的由来。
|
||||
|
||||
也就是说,**监督学习的最终目标,是使模型可以更准确地对我们所需要的响应变量建模**。比如,我们希望通过一系列特征来预测某个地区的房屋销售价格,希望预测电影的票房,或者希望预测用户可能购买的商品。这里的“销售价格”、“电影票房”以及“可能购买的商品”都是监督学习中的响应变量。
|
||||
|
||||
那什么是无监督学习呢?通常情况下,无监督学习并没有明显的响应变量。**无监督学习的核心,往往是希望发现数据内部的潜在结构和规律,为我们进行下一步决断提供参考**。典型的无监督学习就是希望能够利用数据特征来把数据分组,机器学习语境下叫作“聚类”。
|
||||
|
||||
根据不同的应用场景,聚类又有很多变种,比如认为某一个数据点属于一个类别,或者认为某一个数据点同时属于好几个类别,只是属于每个类别的概率不同等等。
|
||||
|
||||
无监督学习的另外一个作用是为监督学习提供更加有力的特征。通常情况下,无监督学习能够挖掘出数据内部的结构,而这些结构可能会比我们提供的数据特征更能抓住数据的本质联系,因此监督学习中往往也需要无监督学习来进行辅助。
|
||||
|
||||
我们简要回顾了机器学习中两大类问题的定义。在学习这两大类模型和算法的时候,有这么一个技巧,就是要不断地回归到上面提到的基本思路上去,就是这个“三步套路”,反复用这三个方面来审视当前的模型。另外,我们也可以慢慢地体会到,任何新的模型或者算法的诞生,往往都是基于旧有的模型算法,在以上三个方面中的某一个或几个方向有所创新。
|
||||
|
||||
## 监督学习的基础
|
||||
|
||||
监督学习的基础是三类模型:
|
||||
|
||||
<li>
|
||||
线性模型
|
||||
</li>
|
||||
<li>
|
||||
决策树模型
|
||||
</li>
|
||||
<li>
|
||||
神经网络模型
|
||||
</li>
|
||||
|
||||
**掌握这三类模型就掌握了监督学习的主干**。利用监督学习来解决的问题,占所有机器学习或者人工智能任务的绝大多数。这里面,有90%甚至更多的监督学习问题,都可以用这三类模型得到比较好的解决。
|
||||
|
||||
这三类监督学习模型又可以细分为处理两类问题:
|
||||
|
||||
<li>
|
||||
分类问题
|
||||
</li>
|
||||
<li>
|
||||
回归问题
|
||||
</li>
|
||||
|
||||
**分类问题的核心是如何利用模型来判别一个数据点的类别**。这个类别一般是离散的,比如两类或者多类。**回归问题的核心则是利用模型来输出一个预测的数值**。这个数值一般是一个实数,是连续的。
|
||||
|
||||
有了这个基本的认识以后,我们利用前面的思路来看一下如何梳理监督学习的思路。这里用线性模型的回归问题来做例子。但整个思路可以推广到所有的监督学习模型。
|
||||
|
||||
**线性回归模型**(Linear Regression)是所有回归模型中最简单也是最核心的一个模型。我们依次来看上面所讲的“三步套路”。
|
||||
|
||||
首先第一步,我们需要回答的问题是,线性回归对现实场景是如何抽象的。顾名思义,线性回归认为现实场景中的响应变量(比如房价、比如票房)和数据特征之间存在线性关系。而线性回归的数学假设有两个部分:
|
||||
|
||||
<li>
|
||||
响应变量的预测值是数据特征的线性变换。这里的参数是一组系数。而预测值是系数和数据特征的线性组合。
|
||||
</li>
|
||||
<li>
|
||||
响应变量的预测值和真实值之间有一个误差。这个误差服从一个正态(高斯)分布,分布的期望值是0,方差是σ的平方。
|
||||
</li>
|
||||
|
||||
有了这样的假设以后。第二步就要看线性回归模型的参数是如何求解的。这里从历史上就衍生出了很多方法。比如在教科书中一般会介绍线性回归的解析解(Closed-form Solution)。线性回归的解析解虽然简单优美,但是在现实计算中一般不直接采用,因为需要对矩阵进行逆运算,而矩阵求逆运算量很大。解析解主要用于各种理论分析中。
|
||||
|
||||
线性回归的参数还可以用数值计算的办法,比如梯度下降(Gradient Descent)的方法求得近似结果。然而梯度下降需要对所有的数据点进行扫描。当数据量很多的时候,梯度下降会变得很慢。于是随机梯度下降(Stochastic Gradient Descent)算法就应运而生。随机梯度下降并不需要对所有的数据点扫描后才对参数进行更新,而可以对一部分数据,有时甚至是一个数据点进行更新。
|
||||
|
||||
从这里我们也可以看到,**对于同一个模型而言,可以用不同的算法来求解模型的参数。这是机器学习的一个核心特点**。
|
||||
|
||||
最后第三步,我们来看如何评估线性回归模型。由于线性回归是对问题的响应变量进行一个实数预测。那么,最简单的评估方式就是看这个预测值和真实值之间的绝对误差。如果对于每一个数据点我们都可以计算这么一个误差,那么对于所有的数据点而言,我们就可以计算一个平均误差。
|
||||
|
||||
上述对于线性回归的讨论可以扩展到监督学习的三类基本模型。这样你就可以很快掌握这些模型的特点和这些模型算法之间的联系。
|
||||
|
||||
## 无监督学习的基础
|
||||
|
||||
现实中绝大多数的应用场景并不需要无监督学习。然而无监督学习中很多有价值的思想非常值得初学者掌握。另外,**无监督学习,特别是深度学习支持下的无监督学习,是目前机器学习乃至深度学习的前沿研究方向**。所以从长远来看,了解无监督学习是非常必要的。
|
||||
|
||||
我们前面说到,无监督学习的主要目的就是挖掘出数据内在的联系。这里的根本问题是,不同的无监督学习方法对数据内部的结构有不同的假设。因此,无监督学习不同模型之间常常有很大的差别。在众多无监督学习模型中,聚类模型无疑是重要的代表。了解和熟悉聚类模型有助于我们了解数据的一些基本信息。
|
||||
|
||||
聚类模型也有很多种类。这里我们就用最常见的、非常重要的**K均值算法**(K-means),来看看如何通过前面讲过的“三步套路”来掌握其核心思路。
|
||||
|
||||
首先,K均值算法认为数据由K个类别组成。每个类别内部的数据相距比较近,而距离所有其他类别中的数据都比较遥远。这里面的数学假设,需要定义数据到一个类别的距离以及距离函数本身。在K均值算法中,数据到一个类别的距离被定义为到这个类别的平均点的距离。这也是K均值名字的由来。而距离函数则采用了欧几里得距离,来衡量两个数据点之间的远近。
|
||||
|
||||
直接求解K均值的目标函数是一个NP难(NP-hard)的问题。于是大多数现有的方法都是用迭代的贪心算法来求解。
|
||||
|
||||
一直以来,对聚类问题、对无监督学习任务的评估都是机器学习的一个难点。无监督学习没有一个真正的目标,或者是我们之前提到的响应变量,因此无法真正客观地衡量模型或者算法的好坏。
|
||||
|
||||
对于K均值算法而言,比较简单的衡量指标就是,看所有类别内部的数据点的平均距离和类别两两之间的所有点的平均距离的大小。如果聚类成功,则类别内部的数据点会相距较近,而类别两两之间的所有点的平均距离则比较远。
|
||||
|
||||
以上我们通过“三步套路”的三个方面讨论了K均值算法的核心思路,这种讨论方法也适用所有的聚类模型和算法。
|
||||
|
||||
## 小结
|
||||
|
||||
当你可以熟练使用我今天介绍的“三步套路”,去分析更多监督学习和无监督学习的模型算法以后,对于基础的内容,也就是教科书上经常讲到的内容,你就可以去看这些内容究竟是在讲解这三个方面的哪个方面。
|
||||
|
||||
**对于绝大多数模型来说,第一部分往往是最重要的,也就是说,这个模型究竟和现实问题的联系是什么**。第二部分,也就是模型的求解,取决于模型本身的复杂度和成熟度,现在很多模型往往都有现成的软件包提供求解过程。而第三部分,模型的评估则在现实生产中至关重要。**牢牢把握这三个方面,来对机器学习模型算法进行讨论,是成长为成熟数据科学家必不可少的过程**。
|
||||
|
||||
今天我为你讲了掌握机器学习基础知识的一些核心思路。一起来回顾下要点:第一,机器学习主要的任务有监督学习和无监督学习。这两种机器学习任务的很多模型和算法都可以用一个“三步套路”的思路来进行分析。第二,我们用线性回归作为例子探讨了如何用这个“三步套路”来分析监督学习的模型和算法。第三,我们用K均值聚类算法作为例子探讨了如何用“三步套路”来分析无监督学习的模型和算法。
|
||||
|
||||
最后,给你留一个思考题,在现实场景中,当你发现一个模型并没有很好地解决你的问题时,从这个“三步套路”的角度来看,究竟哪个方面最容易出问题?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/129 | 数据科学家基础能力之系统.md
Normal file
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/129 | 数据科学家基础能力之系统.md
Normal file
@@ -0,0 +1,67 @@
|
||||
<audio id="audio" title="129 | 数据科学家基础能力之系统" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/61/33/61aea0bd6c8ae12e1688c7767b8c2233.mp3"></audio>
|
||||
|
||||
对于初学人工智能的工程师或者数据科学家来说,在知识积累的过程中,“系统”往往是一个很容易被忽视的环节。特别是非计算机科学专业出身的朋友,一般都没有真正地建立过“系统”的概念,在今后从事人工智能的相关工作时,很可能会遇到一些障碍。
|
||||
|
||||
今天我想给你分享一下,作为人工智能工程师和数据科学家,需要建立的关于“系统”的最基本认知。这些认知能够帮助你把书本的理论知识和现实的应用场景快速结合起来。
|
||||
|
||||
## 理解管道(Pipeline)
|
||||
|
||||
在很多人工智能初学者的认知中,机器学习的流程是这样的。有一个已经准备好的数据集,这个数据集里面已经有了各种特征以及所对应的标签或者响应变量。这个时候,你需要做的就是利用这个数据集和一些现成的机器学习工具包,来训练一些机器学习模型。模型训练好以后,就可以计算一些已知的评估指标了,比如准确度、精度等等。
|
||||
|
||||
这是一般教科书和课程上介绍的标准机器学习流程,也是很多机器学习论文中的实验环境。遗憾的是,这个静态的流程并不适用于工业级的数据产品。
|
||||
|
||||
要支持工业级的人工智能产品,一个最基本的概念就是,**你需要搭建一个管道让你的环境是动态的、闭环的**。在英文的语言背景里,“管道”这个词很形象地说明了这个环境的特点。我们把数据想象成“管道”里的水,这里面的一个核心思想,就是数据从一个环节到下一个环节,源源不断。我们再把最终的产品,也就是这个管道的末端,和最开始的数据采集部分,也就是这个管道的开始端,结合起来思考,这就是一个闭合的环路。
|
||||
|
||||
**理解数据产品的核心,就要理解它是一个闭合环路**。几乎关于数据产品的一切难点、问题以及解决方案都可以从这个闭合环路中产生。从一个静态的机器学习流程到一个动态的管道似的闭合环路,这是一个质变,对整个环节上的所有步骤都有全新的要求。
|
||||
|
||||
我这里就拿数据集来举个例子。静态的流程中,我们不需要太过关注这个数据集的来源。甚至采集数据集的代码或者脚本都可以是一次性的,可以不具备重复使用的价值。但是这种情况在管道的环境中是不可能的。
|
||||
|
||||
在管道中,**采集数据的可靠性和可重复性是非常重要的步骤**,这就对采集数据所采用的代码有不一样的要求。这部分代码需要被反复检验,每一步都需要人工智能工程师和数据科学家进行检验。如果我们把这个例子扩展到数据管道的其他部分,就可以很清楚地看到,数据管道对于构建一个机器学习流程所带来的根本变化。
|
||||
|
||||
管道的另外一个重要特性是**自动化**,一个不能自动化的管道是不能被称为管道的。这里的自动化有两层意思,一层意思是指数据本身可以被自动采集、整理、分析,然后自动流入机器学习部分,有结果后自动输出并能被线上的系统使用;另一层意思是指,每一个环节本身都不需要人工干预,或者仅需极少数的人工,自身可以高可靠地运行。由此可见,管道的自动化对每个环节的技术选择和实现都有非常高的要求。
|
||||
|
||||
现代互联网公司中,每个团队,甚至成立专门的团队,一般都会针对机器学习管道开发工具平台,使管道的灵活度、自动化、可靠性有足够保障。对于初学者而言,尝试从管道的角度去理解问题,从整个系统的角度来认识产品开发过程,认识机器学习流程,才有可能设计出能真正满足线上需求的技术方案。
|
||||
|
||||
## 理解线上和线下的区别
|
||||
|
||||
了解了一个数据系统的闭合回路以后,很自然地,就会出现下一个问题,这也是一个核心的系统级问题,在这个管道中,哪些部分是在“线上”,哪些部分又在“线下”呢?
|
||||
|
||||
这里我们先来理清“线上”这个概念。“线上”往往是说,对于交互性很强的互联网产品(包括电商、搜索引擎、社交媒体等),从用户来到某一个页面,到我们为这个页面准备好所需内容(例如推荐的商品或者搜索的结果),这中间的响应时间对应的就是“线上”,这部分时间非常短暂,往往只有几百毫秒。如何在这几百毫秒的时间内进行复杂的运算就非常有讲究了。
|
||||
|
||||
“线下”的概念是相对于“线上”而言的。通常情况下,不能在这几百毫秒之内完成的运算,都是某种程度的“线下”运算。
|
||||
|
||||
**理解线上和线下的区别是初学者迈向工业级应用的又一个重要的步骤**。哪些计算可以放到线上,哪些可以放到线下,就成了种种机器学习架构的核心区别。
|
||||
|
||||
初学者还需要注意的一个问题是,线上和线下都是相对的概念。今天放在线下计算的某些部分,明天可能就会放到线上进行计算。所以,慢慢学会把握两者之间的转换之道,对于初学者进阶至关重要。
|
||||
|
||||
我这里举一个简单的线上和线下分割的例子。比方说,我们要构建一个检测垃圾邮件的系统。对于这样一个系统而言,哪些部分是线上,哪些部分是线下呢?
|
||||
|
||||
初看,我们在这里讨论的是一个比较容易的架构,但并不代表实现这个架构的难度也很小。在最简单的情况下,检测垃圾邮件需要一个二分分类器。如何训练这个分类器的参数就是一个关键。
|
||||
|
||||
假设我们训练一个逻辑回归二分分类器。那么,逻辑回归的参数,也就是一组线性系数究竟应该在什么环境中得到呢?很明显,训练一个逻辑回归肯定需要大量的训练数据。在有一定量(大于几千的垃圾邮件和非垃圾邮件)的训练数据时,训练逻辑回归的参数就不可能在几百毫秒内完成。在这样的思路下,训练逻辑回归就不得不放到线下来计算。一旦这个决定做出以后,一系列的模块就都必须放在线下计算了。
|
||||
|
||||
另外,数据的收集肯定也得放到线下,这样才能保证可以把训练数据传输到后面的管道模块中。还有特征的生成,至少是训练数据特征的生成,很自然地也就需要放在线下。
|
||||
|
||||
训练逻辑回归本身,刚才我们提到了,需要放在线下。而放在线下这个决定(从某种意义上来说,无所谓时间多了一点还是少了一点,总之无法满足几百毫秒的线上计算就需要放在线下),又可以让训练逻辑回归本身,采用更加复杂的二阶算法,使参数能够得到更好的收敛。
|
||||
|
||||
你可以看到,因为一个决定,带来了关于整个管道的一系列决定。而这些决定又影响了模型算法的选择,比如可以选用相对耗时的更复杂的算法。
|
||||
|
||||
那么在这个架构下,线上的部分是什么呢?首先,训练完一个模型之后,要想使用这个模型,我们必须把模型的参数存放到某个地方(也许是一个数据库或者是一个存储系统),线上的系统可以在几百毫秒的时间内马上得到这些参数。仅仅得到参数是不够的,还需要对当前的邮件进行判断。
|
||||
|
||||
这一步就有一些问题了。一种选择是,线上的部分拿到模型参数,然后实时动态产生这个邮件的特征,再实时计算出一个分数,并且判断是否是垃圾邮件。整个过程的这三个步骤需要在几百毫秒内进行完毕。
|
||||
|
||||
实际上,这里面的第二步往往比较耗时,甚至有的特征并不能在线上进行计算。比如,也许有一个特征需要查询这个邮件的来源是否可靠,这里就可能需要数据库操作,这一步也许就会非常耗时(在几百毫秒的场景中而言)。因此,动态产生特征,除非特征都非常简单,很有可能并不能完全在线上完成。
|
||||
|
||||
我们可以对框架进行简单的修改。所有的邮件首先输送到一个特征产生的模块中,这里并不是一个完全线上的环境,运算的需求可能超过几百毫秒,但总体只是几秒,最多十多秒。所有的特征产生以后,对邮件的判断也在这里完成,最终将邮件是否是垃圾邮件这个简单的选项保存下来。在线上的系统,也就是用户来到这个邮件系统界面的时候,我们只是从保存的结果中,直接读出一个标签,速度非常快。
|
||||
|
||||
如上,我们通过检测垃圾邮件系统的例子,分析了线上和线下的分割情况。现在来做一个思考,刚才描述的这个架构有什么问题吗?问题就是,线上的结果是一个事先计算好的结果,模型本身也是事先计算好的。因此,当有大量突发数据(比如一大批新的垃圾邮件)来临的时候,这个架构可能无法很快反应,更新模型。可见,如何理解线上和线下是一个需要慢慢琢磨的学习过程。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了数据科学家和人工智能工程师需要掌握的关于系统基础的两个核心概念。一起来回顾下要点:第一,现代数据流程不是一个静态的数据集,而是一个动态的闭环管道。 第二,理解什么计算可以放到线上,什么计算可以放到线下至关重要。
|
||||
|
||||
最后,给你留一个思考题,如果让你设计一个商品的推荐系统,哪些部分放到线下,哪些部分放到线上呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
85
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/130 | 数据科学家高阶能力之分析产品.md
Normal file
85
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/130 | 数据科学家高阶能力之分析产品.md
Normal file
@@ -0,0 +1,85 @@
|
||||
<audio id="audio" title="130 | 数据科学家高阶能力之分析产品" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/9e/6614f41882a14047255b5ae21064db9e.mp3"></audio>
|
||||
|
||||
人工智能工程师和数据科学家的主要工作是什么?很多人认为,他们的主要工作是利用复杂的机器学习模型和算法来解决产品中的难题。这样的认识既“对”也“不对”。“对”的地方是说,机器学习模型和算法的确是人工智能技术在产品上落地的核心步骤。“不对”的地方是说,这种认识往往片面地总结了人工智能从业人员的工作范畴。
|
||||
|
||||
实际上,要想真正地提出一个好的人工智能解决方案,分析产品的能力是必需的。从较高的层次来讲,就是分析一个产品目前遇到的难题是什么,为什么需要用人工智能技术去解决,哪些是可以用人工智能技术解决的,哪些不能。
|
||||
|
||||
今天,我就来分享一下,站在人工智能工程师和数据科学家的角度,我们如何理解并提升分析产品的能力,学会了解产品的需求。
|
||||
|
||||
## 产品需求的庖丁解牛
|
||||
|
||||
一个数据驱动的产品往往是一个复杂的复合体。这里面当然有很多数据、人工智能的元素,也有不少其他元素,比如设计、人机交互、商业规则、心理学等等。那么,如何在这么一个综合复杂的体系中找到人工智能技术的合适位置,以及技术究竟要扮演什么样的角色,其实是一个数据驱动型产品能否成功的核心问题。
|
||||
|
||||
想要对这个问题有一个比较全面的认识,我们首先需要回答这么一个问题,那就是人工智能技术到底能够给产品带来什么?
|
||||
|
||||
很多朋友可能觉得这个问题不言自明。人工智能技术难道不是解决产品的核心算法难题吗?
|
||||
|
||||
这种看法其实不够全面。**人工智能技术给产品带来的其实不仅是一些核心的模型和算法,更重要的是,带给产品一项根本性的能力:数据驱动的决策过程**。
|
||||
|
||||
什么叫作“数据驱动的决策过程”呢?我们还是要从人工智能技术的特点说起。
|
||||
|
||||
**人工智能技术的特点有两个方面:第一,数据驱动。第二,在不确定的因素下智能决策。**
|
||||
|
||||
## 数据驱动
|
||||
|
||||
我们先来谈谈第一个方面,数据驱动。这里其实是两个部分,“数据”和“驱动”。
|
||||
|
||||
一个产品要想利用人工智能,第一步,也是非常重要的一个步骤,就是要有“数据”的概念。什么是“数据”的概念?就是一个产品需要有数据收集的意识,并有数据收集的机制。然后,一个有“数据”的产品需要慢慢建立数据管道,并开始建立数据的检测系统。这些都是人工智能介入的先决条件和基础设施。
|
||||
|
||||
没有数据,没有流畅的数据链条,是无法构建一个健康的人工智能决策环境的。这一点说起来容易,要真正做到其实需要很扎实的技术基础。很多团队、很多产品最终无法利用人工智能技术的方方面面,一个关键原因就是在数据链条上出了各种问题。
|
||||
|
||||
有了数据以后,第二个环节就是“驱动”。也就是说,只有数据是不行的,还必须有一个意识,主动利用这些数据来驱动产品的发展,驱动产品方方面面的进化。这个步骤其实不仅是针对产品的决策人员,比如产品经理、项目负责人,也是针对这个产品的所有参与人员的。
|
||||
|
||||
参与产品的各方面人员,包括工程方面的、设计方面的、市场方面的,大家有没有意识,在有了数据链条之后,通过数据检测、数据分析不断加深对产品的认识,提出更好的想法。当产品遇到各种问题时,大家有没有一个意识,那就是先到数据中去找答案,先去看数据是不是出了什么问题,去理解数据中显示出来的内容。
|
||||
|
||||
**如果说数据驱动的第一部分是有关“硬件”的,是数据链条的技术以及实现,那么第二部分就是有关“软件”的,是项目人员的意识和责任。**
|
||||
|
||||
## 智能决策
|
||||
|
||||
当一个产品有了数据驱动的基础以后,下一步,就需要建立“智能决策”的理念。
|
||||
|
||||
“智能决策”是什么意思?
|
||||
|
||||
要想明白“智能决策”的意义,我们首先要来想一想“非智能决策”是什么样的。
|
||||
|
||||
很多传统的产品或者不是数据驱动的科技产品都是非智能决策的产物。非智能决策主要是指,不依靠数据,或者依靠很少量的数据,由产品经理或产品负责人人工地进行决策。注意,非智能决策并不一定无法带来好的产品。实际上,在历史的很长时间里,各行各业都是依靠非智能决策在进行演化。
|
||||
|
||||
非智能决策的一大特点是决策的主观性。通俗地讲,就是决策者依靠自我的认识,主观“拍板”决策关于产品的方方面面。因为没有一个系统的方法论,或者说是没有一整套机制给决策者相应的信息,来帮助决策者完成决策,非智能决策所带来的产品结果往往有很大的偶然性。
|
||||
|
||||
这种偶然性来自于决策者本人的各种能力,来自于执行者的能力。由于这样的偶然性和主观性,非智能决策的另外一个特点,或者说是结果,就是不可复制性。这是因为决策的方法和方式都不能动态地随着时间、随着数据的变化而变化。
|
||||
|
||||
非智能决策在什么时候会变得比较困难呢?数据量太大的时候,需要做选择的可能性太多的时候,需要做的选择本身复杂度变高的时候。这些特征也正是新时期下互联网产品或者人工智能产品的特点。因此,在将来非智能决策会越来越多地让位给智能决策。
|
||||
|
||||
简单来说,智能决策就是产品的决策者依据产品的特点,把一些复杂的、需要依靠大量数据、选择面太广的决策交给人工智能模型和算法,并且建立起一整套体系,利用人工智能手段依靠数据来对整个产品进行快速迭代。
|
||||
|
||||
如果给这种产品决策找一些典型的类比,就像现代搜索引擎技术,代替了传统的图书馆管理员的角色;现代的电子商务网站为用户推荐各类商品,代替了传统商店里的导购;智能自动驾驶汽车,代替了人类的手工驾驶。
|
||||
|
||||
**智能决策不仅仅是某一项任务的智能化,更重要的是一种理念的提升**。也就是说,一旦产品的决策中出现了有需要大量数据、有复杂选项的时候,作为产品的决策者就需要马上意识到,这部分决策任务应该逐渐从人转移到智能模型和算法上,依靠数据驱动流程来加快迭代。这一点是智能决策的关键。
|
||||
|
||||
我们可以接着之前的电子商务网站的例子来说明智能决策的理念。最开始的时候,也许这个网站只有一个简单的界面,可以根据用户的一些历史信息来推荐商店的商品。这个时候,智能决策的部分还仅限于推荐模块这一部分。紧接着,越来越多的用户开始使用这个网站,于是任务就变得越来越多,也越来越困难。
|
||||
|
||||
比如,如何设计下一版的网站界面?设计师、前端工程师、用户体验工程师、甚至产品经理都会有自己的看法。这个任务本身就很困难,怎么能让上百万的用户满意?怎么能体现出不同用户的不同选择偏好?怎么能体现出这个产品自身的美学价值?你看,这就是一个需要基于数据的复杂的决策任务。
|
||||
|
||||
很多团队能够意识到推荐模块需要智能决策,却意识不到“下一版的界面”问题可能也需要智能决策。其实,一旦一个问题变成智能决策问题,我们反而有章可循。
|
||||
|
||||
比如这个界面问题,所有人的意见、想法或者创意,依据一定的规则,可以用一些人工智能模型和算法来表达。然后通过现代的A/B在线测试手段,可以针对不同的人群展示不同的界面。随后通过数据链条来对测试进行监控和分析。
|
||||
|
||||
这时候,决策反而变得简单。因为我们不需要为数百万用户拿一个主意,而需要做的是为智能决策提供足够多的创意,然后由智能模型和算法以及实验流程来选择用户喜欢的界面。最后,下一版的网站,不只有一个界面,而是有几十甚至是几百种不同的界面,为百万千万的用户服务。
|
||||
|
||||
## 小结
|
||||
|
||||
我们之前提到了数据驱动,提到了智能决策。那么回到我们今天最开始的主题,作为人工智能工程师或者数据科学家的一个高阶技能,就是能够培养这样一种理念,对产品进行持续分析,检测产品是否遵循了数据驱动的理念,挖掘产品有哪些需求可以进行智能决策。
|
||||
|
||||
一旦有了这个分析产品的能力以后,我们可以发现人工智能技术将成为产品进化的驱动器和核心机制,而不仅仅是锦上添花的一种噱头。这就是对产品的一种完全革新式的思维。
|
||||
|
||||
同时,我这里需要指出的是,今天在这里提到的数据驱动也好、智能决策也好,你可以认为这些都不是什么新思想。但是,如何把这些思想真正地应用到产品实践中却是一件非常困难的事情。
|
||||
|
||||
另外一点需要注意的是,这些理念本身也不是教条,也是一个与时俱进的过程。并不是所有的产品在所有的阶段都需要做数据驱动,都需要做智能决策。我们之前提到了,有很多没有真正数据驱动的产品也依然获得了成功。所以,对产品的分析能力,其实需要你在产品的迭代过程中逐步提升。
|
||||
|
||||
今天我为你讲了数据科学家和人工智能工程师如何提升产品分析能力。一起来回顾下要点:第一,产品分析的能力其实就是对产品需求的一个分解,而分解之后的产品迭代很大程度上依赖于数据驱动和智能决策。 第二,我详细地阐述了什么是数据驱动,什么是智能决策,究竟怎样可以为产品带来这两项核心能力。
|
||||
|
||||
最后,给你留一个思考题,什么样的产品不太适合数据驱动和智能决策呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/131 | 数据科学家高阶能力之评估产品.md
Normal file
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/131 | 数据科学家高阶能力之评估产品.md
Normal file
@@ -0,0 +1,67 @@
|
||||
<audio id="audio" title="131 | 数据科学家高阶能力之评估产品" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d6/23/d663baed9f025d7f24f194d591ddc823.mp3"></audio>
|
||||
|
||||
“**如果你无法衡量它,你就无法改进它**。”(If you can’t measure it you can’t improve it.)这是一句你可能会经常听到的话,这句话也被应用到很多不同的场景中。那么,对于人工智能工程师和数据科学家来说,这句话其实是他们工作核心的核心。不管是模型和算法,还是产品迭代,都离不开“指标”和“评估”这两个方面。
|
||||
|
||||
评估一个产品的好坏,是一项说起来最容易但做起来最困难的工作。任何人,从用户到产品经理,对某一个产品都可能有自己的主观意见。然而对一个产品,特别是要面对成千上万用户的产品来说,依靠主观感觉是很难有一个完整、全面的评价的。同时,**有一个成熟的产品评价体系可以成为产品不断迭代的领航标**。
|
||||
|
||||
今天,我就来聊一聊如何评估一个数据驱动型产品,又如何从评估产品的角度来推动产品的迭代。我们需要建立层次化的评估体系,需要一个衡量产品好坏的框架。这个框架要从宏观到微观,能够对你的产品进行全方位的检测,并且这种检测能够帮助你更容易地进行决策。
|
||||
|
||||
## 产品的经济收益
|
||||
|
||||
你可能要问,是的,我们需要评估一个产品,但是如何找到衡量产品的这些指标呢?
|
||||
|
||||
比方说你要做一个社交网络的网站,怎么来制定检测指标呢?首先,你要问自己,我做这个社交网络的最终目的是什么?很明显,一个商业网站的终极目标是赚钱,也就是说,你最终的指标是你网站的经济收益。知道了这一点远远不够,你至少还需要思考两个问题。**第一,如何衡量你的经济收益;第二,你能否用经济收益来直接指导你的产品构建**。
|
||||
|
||||
我们先谈谈第一个问题。衡量经济收益看似简单其实不易。从比较大的维度上来说,你可以衡量总收入,你也可以衡量利润,你可以衡量收入的年增长率,还可以衡量季度增长率。从比较具体的维度来说,很多社交网站依靠广告收入,对广告收入的衡量本身就是一个非常复杂的问题。
|
||||
|
||||
总体来看,衡量经济收益,有两点值得你思考。其一,如何衡量你收入的现状。其二,如何衡量你收入的增长。今天,关于收入的指标我就不展开讨论了。
|
||||
|
||||
刚才讲的第二个问题就更加复杂。衡量经济收入的指标往往太过宏观,而且衡量起来有难度,因此用经济指标来指导产品的发展是很困难的。我刚才说了一些经济收益指标,比如年收入、年增长率、季度增长率,这些指标的衡量需要至少等待一个季度以上,甚至一年的时间。这些有时间间隔的指标,无法给产品的快速迭代带来很大的指导意义。
|
||||
|
||||
另一方面,很多产品并不直接产生经济结果。也就是说,经济收益是一个“副产品”。这个时候,如果我们只看经济收益,就无法真正指导我们构建更好的产品。比如,我刚才提到,对于一个社交网站来说,广告收入是一个“副产品”,绝大多数用户来到这个网站的主要目的不是点击广告。因此,仅仅衡量广告有可能让社交网络产品的迭代误入歧途。
|
||||
|
||||
## 层次化的评估体系
|
||||
|
||||
如果单从经济指标无法对产品有全面的指导作用,那怎么才能更加有效地建立评估体系呢?这里就引出下一个话题,那就是多层次的评估体系。
|
||||
|
||||
接下来,我就由低到高依次从五个层面来说明一下,这个层次化的评估到底是什么意思。
|
||||
|
||||
**最低层次的评估主要围绕着产品的最小组成单元**。比如我们刚才用的社交网络的例子,社交网络的各个页面上的模块就可以是最小的被评估的单元。
|
||||
|
||||
为什么要用这个概念呢?原因是这样的,每一个模块往往是产品的一个逻辑单元,一个最小的承载产品理念的单元。不管是工程团队还是产品团队的运作,基本上都是为这些模块而工作。因此,观察最小单元的效果对产品和工程团队都有直接的指导意义。如果团队目前对这个模块做了一些更改,那么最直接的效果就是这个模块的一些指标会发生变化。这是产品迭代的一个重要组成部分。
|
||||
|
||||
在这个层次,衡量模块的指标主要是模块的直接效果指标。比如,模块本身的点击率,模块本身的驻留时间,模块上一些其他的用户活跃指标等。这些都是最低层次的模块级别的指标,和产品、工程团队的运作有密切联系。
|
||||
|
||||
**第二个层次的指标是从单个模块上升到一个页面**。这个时候,就不仅需要理解单个模块的情况,还需要对整个页面上所有模块产生的功能群进行深入研究。在这个层次,产品功能群的思考可能会涉及到多个产品团队,也可能会出现模块间冲突的情况。
|
||||
|
||||
比如不少现代搜索引擎的搜索页面往往都有广告模块。长期的经验告诉我们,广告模块的效果和普通搜索模块的效果往往有相反关系的耦合。也就是说,普通搜索模块的效果提高了,广告模块的某些指标反而可能下降。反过来,广告模块的效果提高了,也很有可能是因为普通搜索模块的质量突然变差。因此,在有经验的产品团队面前,广告效果有意想不到的提高,可能并不意味着是件好事情。
|
||||
|
||||
第二个层次的指标比第一个层次变得复杂起来。不过这个层次的指标依然是可以直接测量的。比如页面的点击率,页面的驻留时间,页面上其他的用户指标等等。这些指标虽然可以直接测量,但是分析时需要对页面上的所有模块有全面了解。
|
||||
|
||||
前两个层次的指标主要是测量用户在某一个模块或者页面上的表现,核心是看产品的更改对用户的直接影响。而且,第一层次和第二层次的指标非常易于检测。通常情况下,如果页面和模块发生了什么问题,这些指标就能很快地反映出页面的情况。然后通过排查,我们就能快速发现问题,这也就是通常所说的,这些指标都比较“敏感”。
|
||||
|
||||
“敏感”指标的第一个好处是,这些指标具有非常强的指导意义,能够帮助产品团队快速认识问题并提出解决方案。“敏感”指标的第二个好处无疑就是,产品团队的绝大多数改动都能够比较容易地反应到这些指标上。因此,这是一个容易建立的、良性循环的指标体系。当然,仅有这两个层次的指标还是远远不够的,我们可以看到,这两个层次的指标和一个产品最终目标的衡量还有一定距离。
|
||||
|
||||
**第三个层次的指标,就从某一个模块、某一个页面上升到了用户这个层级,主要是检测用户在一个会话(Session)中的表现**。这个时候,用户往往在一个会话中,和多个模块、多个页面进行非常复杂的互动。在这个层次上,我们已经很难仅凭观测就能琢磨出用户在这个会话中是否真正感觉满意。这个时候,我们往往就需要建立用户模型(User Model),以及通过一些统计的方法建模,从而实现真正理解用户行为的目的。
|
||||
|
||||
举一个例子,如果我们构建一个电子商务网站,在一个用户会话中检测用户是否购买了一些商品,这些商品的总价值又是多少。这个监测指标有时候被称作GMV(Gross Merchandise Value),也就是通常所说的网站成交金额。GMV还是比较容易计算的,就是计算每个会话之后用户购买的商品价值,然后对所有会话的结果求和。但是要真正理解用户会话行为对GMV的影响,就是一个比较困难的任务了。
|
||||
|
||||
我们可以想象,即便是同一个用户,是否在一个会话中购买商品,这是一个非常复杂的决策过程。在一个会话中,用户可能会接触到搜索页面,可能会接触到各种推荐的模块,也可能会跳转某个商品的页面,还可能会跳转首页。并且,每个用户的用户轨迹不同,接触各个页面和模块的流程也是不一样的。可以肯定地说,任何一个流程中的每一个环节,都有可能对用户是否购买商品、以及购买多少价钱的商品有或多或少的影响。而如何来测量和建模这样的影响,就是第三层次指标的核心挑战。
|
||||
|
||||
**第四个层次的指标是从一个用户会话上升到多个用户会话**。这个时候,我们关心的是用户较长时间的体验问题。对于一些复杂的任务,用户需要多个会话才能完成。套用我们刚才举的电商GMV的例子,很多用户购买比较贵重或者是一些有特定需求的商品(比如婚纱)时,往往无法在一个用户会话中完成决策。
|
||||
|
||||
那么这种情况下,检测指标的复杂性又进一步提高。比如说,用户可能先在电商网站上搜索了关于婚纱的信息,但在这一次会话中并没有完成交易。用户之后可能又从其他途径了解了一些更多的信息,然后又重新到电商网站开始一个新的会话。在这个会话中,用户也许重点比较了好几个婚纱,然后决定购买其中一件。这个例子还是一个比较简单的情况了。
|
||||
|
||||
第三和第四层次的指标有两个特点。第一,相对于第一、第二层次的指标而言,这些指标已经不那么“敏感”了。也就是说,仅改变某一个模块甚至某一个页面,是很难在短时间内改变第三,特别是第四层次的指标的。从上面的例子可以看出,用户的购买行为是非常复杂的,仅仅因为提高了某个推荐模块,是不是就能让用户多买贵的东西,答案是不确定的。第二个特点就是,第三和第四层次的指标依然可以用传统的A/B测试来进行观测,只不过需要很仔细地设计实验。
|
||||
|
||||
**第五个层次的指标就是用户和产品的长期指标**。我们最开始提到的经济指标其实就是第五层次的指标。类似的指标还包括月活跃用户、年度活跃用户等等。这些指标有两个特点。第一,这些指标往往是产品的终极目标,一般极其难以撼动,特别是对于成熟的产品而言。第二个特点是,这些指标往往无法通过A/B测试进行衡量。也就是说,我们往往无法通过常规的实验就能够观测到这些长期指标的变化,这也是为什么这些指标被称为“长期”的原因。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了数据科学家和人工智能工程师如何评估产品的能力,这属于比较高阶的分析问题的能力。一起来回顾下要点:第一,我们如何来认识衡量产品经济收益这件事情。第二,我们很详细地阐述了什么是五个层次的评估体系,以及这个评估体系每个层次的特点。
|
||||
|
||||
最后,给你留一个思考题,如果第五个层次无法直接通过A/B测试进行观测,那我们如何在平时进行A/B测试的时候,就能确保是在优化第五个层次的指标,也就是我们产品的终极目标呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,73 @@
|
||||
<audio id="audio" title="132 | 数据科学家高阶能力之如何系统提升产品性能" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/17/41/1730e0b8be14f6fd206bc4b3541d4341.mp3"></audio>
|
||||
|
||||
人工智能工程师和数据科学家的一个核心任务,就是依靠人工智能、机器学习这样的工具来帮助产品不断提升品质,吸引更多用户,以实现既定的长期目标。这里有一个关键点,就是我们如何开发出一套方法论,让提升产品性能的过程可以“有章可循”,并成为一个系统性的流程。
|
||||
|
||||
初入门槛的工程师和数据科学家,容易把精力和眼光都集中在具体的算法模型上面。这固然是短期内的重要工作,但是,如何能够持续不断地为产品提供前进的动力,才是让人工智能技术有别于之前多次技术浪潮的根本因素。今天,我就来为你剖析一下,持续不断地、系统性提升产品性能的一些关键步骤。
|
||||
|
||||
## 优化长期目标
|
||||
|
||||
一个产品如果需要利用数据驱动的人工智能技术来提升品质,第一件事情一定不是专注于部署某一个模型或者算法。或者说,如果已经急迫地上线了第一个简单的算法,接下来最重要的事情一定是停下来,看一看我们是否已经弄明白,这个产品到底需要“优化”什么目标,是否有一个指标检测体系,来指导我们的优化过程。
|
||||
|
||||
**我们利用人工智能技术手段一定要优化产品的长期目标,这是系统性提升产品性能的一个关键**。乍一听这是一句废话,难道算法和模型还有不优化产品长期目标的时候?你心中一定有这样的疑问。其实,确定你所制定的技术方案一定能够优化产品的长期目标,是一件比较困难的事情。
|
||||
|
||||
设想一下这些例子。比如你为一个在线视频的网站设计推荐系统,你根据很多教科书上的推荐系统案例,优化某一个视频的评分(Rating),这是在优化这个产品的长期目标吗?
|
||||
|
||||
比如,你为一个电子商务网站设计搜索系统,你根据传统的信息检索以及搜索的案例,优化查询关键词和产品的相关度(Relevance),这是在优化这个产品的长期目标吗?
|
||||
|
||||
再比如,你为一个新闻网站设计新闻流系统,你根据产品的基本特点,希望提高新闻的点击率,是在优化这个产品的长期目标吗?
|
||||
|
||||
针对上面这些问题,答案或许都是——不确定。或者说,你正在优化的可能会、也可能不会对这个产品的长期目标有影响,这就需要我们建立一个系统性的方法论,来引导我们回答这个问题。
|
||||
|
||||
因此,知道我们是否在优化产品的长期目标需要一个前提,那就是我们必须要建立**产品的指标检测体系**。在专栏的上一期内容里,我们已经介绍了五个层次的产品评估体系。对于提升产品来说,建立这些层次是关键的一步。然而,要想真正系统性地提升产品,还有一个至关重要的步骤,那就是**打通这五个层次,建立一个立体的产品提升流程**,从而实现优化产品的长期目标。
|
||||
|
||||
我们先来简单回顾一下这五个层次的指标。从最高层次说起,**第五层次的指标主要是产品的长期指标**,比如季度利润的增长、年利润、月活跃人数等。这些指标和产品的最终目的息息相关,却非常难直接衡量,也就是这些指标对产品的一般变化不是很敏感。
|
||||
|
||||
**第四层次的指标主要是用户在多个会话的交互表现。第三层次的指标是指用户在单一会话的交互表现**。这两个层次的指标比较容易在A/B测试的范畴内测量。这些指标能比较宏观地检测一个产品的高维度表现,了解用户一般是如何和这个产品进行交互的。
|
||||
|
||||
**第二层次是页面层级的指标**,这个时候,我们观测到的基本上已经是产品团队可以直接控制的因素了。**第一个层次的指标是模块级别的指标**,这是产品团队直接运作的结果。
|
||||
|
||||
这五个层次的指标从宏观到微观,构成了一个检测的体系。如果我们要优化产品的长期目标,也就是说第五层次的指标,而我们能够直接掌握的产品决策,往往只能带来第一、第二层次指标的显著变化,这两者之间的差距如何来弥补呢?
|
||||
|
||||
我们前面举了好几个例子,比如视频推荐、产品搜索、新闻流产品等等。之前提到的技术方案大多数直接针对第一或者第二层次的指标,这些方案是不是能够对第五层次的指标奏效,其实是一个不确定的问题。
|
||||
|
||||
那么,问题的核心就变成了,**如何在只能运作第一或者第二层次指标的情况下,对第三、第四甚至五层次的指标有间接的控制和影响呢?**
|
||||
|
||||
## 建立层级指标之间的联系
|
||||
|
||||
上面我们提到了,要想持续地提高产品,最重要的就是要一直优化产品的长期目标。但是,如果我们只能控制产品的短期指标,如何才能优化产品的长期目标呢?
|
||||
|
||||
**答案其实很简单,就是我们必须在所有层级的指标之间建立联系**。这些联系因产品而异,但核心思想却是一致的。
|
||||
|
||||
回到之前的一个例子,那就是构建一个视频推荐系统。如果我们希望直接优化用户对视频的评分,就必需回答一个问题,能够给用户推荐打高分的视频,和产品的长期指标之间有什么联系?假设这里产品的长期指标是月活跃用户数目,那么问题就是,给用户推荐打高分的视频,和月活跃用户数目之间的联系是什么?
|
||||
|
||||
注意,这里说的建立联系不仅是**逻辑联系**,而且也是**数据链联系**。也就是说,我们不仅需要尽可能地在逻辑上理清,为什么推荐高分视频有利于帮助月活跃用户数的增长,还需要用数据来为这样的观点提供证据,这才是最重要的一个环节。
|
||||
|
||||
简单说来,我们可以这么做。首先,从所有的用户群体中找到用户样本。然后,通过数据来研究,用户的活跃程度和被推荐的视频评分之间的关系。从最高的维度上说,那就是建立一个**回归问题**,比如用户的月活跃程度作为响应变量,被推荐视频的评分用作一个特征变量。
|
||||
|
||||
当然,这个时候我们还可以引入其他的重要变量,比如性别、年龄组、地区等等,用来排除这些因素的干扰。直接研究这两者之间的关系一般来说是一个有难度的工作。比如你很可能并没有那么全面的数据,也有可能这两个变量都需要做一些变形,还可能负例太多(也就是说有大量的用户并没有因为评分的高低而改变他们的行为)等等。
|
||||
|
||||
如何具体地建立这个模型我今天先不讲,但有一点是可以肯定的,那就是这样做一个分析,可以很好地帮助你了解优化对象和长期目标之间的联系。
|
||||
|
||||
我们不仅需要了解第一层级和第五层级指标之间的关系,每一个层级之间的关系也是需要去研究的,这样才能更加全面地了解自己的产品。这一步就是把之前分散的五个层级打通的重要步骤,也就是如何建立一个立体体系的关键。
|
||||
|
||||
那么,如果出现了这样的情况,长期运作的第一层级指标和自己的长期目标没有联系,该怎么办呢?第一,**祝贺你,你进入了真实的产品运作环境**。从很多产品的长期运作经验来看,很多传统的指标特别是教科书上的指标,都和真实的长期指标有很弱的关系,甚至根本没有太大的联系。第二,**这会帮你早日抛弃错误的优化目标,转向更加正确的道路**。
|
||||
|
||||
寻找一个正确的第一、第二层级的指标,让这个指标和最后第五层次的长期目标之间有正向联系,就是能够持续不断地推动产品前进的一个重要动力。因为这个因素,产品团队才能够不断地试错,但不会失去大方向。
|
||||
|
||||
然而,说起来貌似很容易的事情,做起来其实是很困难的。我刚才说了,很可能有一些指标,看上去有一定的意义,但并不一定和长期目标有任何正相关。怎么才能找到恰当的指标呢?
|
||||
|
||||
一个简单的方法是**尽可能多地记录指标**,然后根据后期的实验数据和分析来确定指标之间的联系。回到刚才那个例子,就是说,我们对于一个视频网站,可以记录很多第一、第二层级的指标,有可能有上百上千个。然后我们根据数据,从这么些指标中,和最终的长期目标做回归分析,建立一些备选集。
|
||||
|
||||
这里需要数据、也需要经验。我们还可能发现,最终的长期目标和好多第一或者第二层级的指标都有关系,这也是很正常的。这就说明,优化长期目标是一件复杂的事情,很多短期目标和长期目标并不是只有简单的线性关系。
|
||||
|
||||
当确定好了第一、第二层级的指标后,那就可以开始用机器学习的手段,**把指标当做算法模型的目标函数**,从而重新设计算法,使其能够开始优化新的指标。这一步也需要很高的机器学习技巧和丰富的经验,因为并不是所有的指标,都能很容易地转换成机器学习可以优化的对象。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了,人工智能工程师和数据科学家的一个高阶能力技巧,如何才能不断提升产品的品质。一起来回顾下要点:第一,我们要专注产品的长期目标。第二,一定要建立产品短期目标和长期目标之间的关系,从而能够在直接优化短期目标的同时间接优化长期目标。
|
||||
|
||||
最后,给你留一个思考题,请你认真想一想,对于我们上面举例的推荐视频网站来说,有哪些第一或者第二层级的指标和用户的活跃程度有关呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
60
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/133 | 职场话题:当数据科学家遇见产品团队.md
Normal file
60
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/133 | 职场话题:当数据科学家遇见产品团队.md
Normal file
@@ -0,0 +1,60 @@
|
||||
<audio id="audio" title="133 | 职场话题:当数据科学家遇见产品团队" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/85/72/852c130f79531b2d4c00bd26d54bd072.mp3"></audio>
|
||||
|
||||
我们在之前的分享中已经聊了数据科学家应该具备的基本能力,主要是希望从机器学习、统计知识、系统知识等方面给你一个完整的基本知识框架。然后我们聊了一些数据科学家的高阶能力,主要是能够通过分析产品、建立产品的评估体系以及对产品的长短期目标进行建模来系统性地提升产品性能。
|
||||
|
||||
今天我们就把话题从数据科学家和人工智能算法工程师自身的修养和提升,扩展到一个更大的范围,那就是在职场中必然会遇到的发展和协作问题,我们来聊聊数据科学家和产品团队的关系这个话题。
|
||||
|
||||
作为数据科学家或者算法专家,不知道你有没有遇到过这样的场景:
|
||||
|
||||
- 你正在开发最新的推荐算法,产品经理找到你说,希望给在北京的女性用户推荐一款红色的高跟鞋;
|
||||
- 你正在研究如何使用最新的深度学习技术来提高搜索结果,产品的设计师告诉你,产品团队现在决定在近期做一个推广,需要在搜索结果上方展示一个很大的条幅,使得整个搜索页面往下移动了不少;
|
||||
<li>你正在给公司的广告系统设计新的模型,产品的营销人员告诉你,这周需要展示给用户的折扣信息,广告位从以前的6个变成了3个。<br />
|
||||
相信类似的场景你应该不陌生。这也就是我们今天要探讨的问题,数据科学家如何在一个更加广阔的环境中协作。</li>
|
||||
|
||||
## 数据科学家和产品团队的关系会出问题吗?
|
||||
|
||||
数据科学家和产品团队究竟有着怎样的关系呢?先理清楚这个问题,我们才能去探讨这样的关系会有怎样的互相依赖以及可能存在的问题。
|
||||
|
||||
在很多数据驱动的互联网公司,**产品团队**(Product Team)和**工程团队**(Engineering Team)往往是实施一个具体产品的两个关键的力量。
|
||||
|
||||
产品团队通常情况下是产品经理领军,拥有各类不同的产品负责人、设计师、UI设计师等人员对整个产品的设计、理念进行把关和掌控。
|
||||
|
||||
工程团队则主要是工程经理领军,各类架构师、算法工程师、前端工程师、数据库工程师等人员对整个产品的工程技术甚至运行维护进行把关和掌控。
|
||||
|
||||
在这个产品的图谱里,数据科学家所组成的“人工智能”团队有可能是独立于产品团队和工程团队的第三方力量,也可能是属于工程团队的一部分。这两种情况其实也略有不同。我们在这里就简化讨论一种情况,那就是数据科学家所在的团队和产品团队并不完全是一个团队的情况。
|
||||
|
||||
从大的格局来说,不管是什么团队,产品人员也好,工程师人员也好,都是为了产品的进步和提高出谋划策的,都是希望产品能够越做越好的。这一点毋容置疑。
|
||||
|
||||
然而,由于不同的团队分工以及各类人员不同的专业背景,在如何能够让产品做得越来越好这一点上可能就会存在不同的意见,甚至是严重分歧。设计人员可能认为产品下一步最大的可能性来自于更加简洁明亮的设计风格;产品营销人员可能认为用户应该会对下一场促销更感兴趣;工程师可能认为下一步需要整个团队重写一个重要框架代码,让页面渲染速度得到提升从而使得用户体验得到改善;数据科学家或者算法工程师正在考虑开发一个更加复杂的机器学习模型,来提升产品的智能响应;产品经理也许在想着如何做一个全新的手机界面,来体现一种新的用户生活体验。
|
||||
|
||||
这些想法也许都对产品有益,甚至都能让产品或多或少有所进步。但是,我们经常看到的是,不同背景的人员都对自己的专业很自信,有时候甚至是“过度"自信,从而只相信自己所处岗位所能发挥的作用。**从数据科学家这个角度来说,因为大数据、机器学习以及其他人工智能技术手段的不断进步,可能就会导致我们过分强调算法和模型对产品带来的影响,而忽略了产品是一个非常有机的整体**。
|
||||
|
||||
在这样的情况下,作为数据科学家或者人工智能工程师,往往会遇到我们今天开始提及的情景。**一方面你在做着自己认为能让产品有最大收益的事情,而另一方面,整个产品有机整体的各个部分都在运作着,有可能会“破坏”掉你所做过的或者正在做的努力**。如果这时候数据科学家以一种算法第一的心态看待产品,就会发现自己的工作非常难以展开,也会和产品的其他部门产生矛盾。
|
||||
|
||||
**另外一种情形是,产品经理或者产品部门对机器学习或人工智能抱有不切实际的幻想,认为这是解决一切问题的灵丹妙药**。于是所有和产品进步相关的想法都希望通过人工智能来得以实现,这无疑给数据科学家和工程师增加了很大的压力。
|
||||
|
||||
然而不管处在哪种场景中,我们都可以看到,数据科学作为一个技术工程范畴和其所从事的人,数据科学家,无疑都是在一个复杂的环境中对产品起着作用。**要想充分发挥出数据科学的作用,我们必须深入理解数据科学家和产品团队的关系,从而打造一个有机的产品团队生态体,使得处于各个职能的人员都能够在一个和谐竞争的状态下对产品有所贡献**。
|
||||
|
||||
## 如何把握数据科学家和产品团队的关系
|
||||
|
||||
既然我们聊到了数据科学家或者人工智能工程师和产品团队之间的微妙关系,那么,有没有什么方法能够让这种关系变得更加明朗,更有利于数据科学发挥出更大的作用呢?
|
||||
|
||||
首先有一点很重要,也是整个团队需要先明确的是,**数据科学、人工智能在现阶段来说,依然是大多数产品的“奢侈品”**。什么意思呢?也就是说,没有很多基础设施的建设,没有一些最基本的产品功能,没有最简单的数据链路,就不可能应用最基本的数据科学,也不可能对产品进行持续提高。正因为此,**数据科学家其实应该和产品经理建立好关系,从而能够从一开始就心系整个产品的发展,能够有一颗包容的心,为产品能够快速达到这个最基本的状态出谋划策,同时也要让整个产品时刻都处于这个状态**。
|
||||
|
||||
这里面涉及到一个“教育”和“再教育”的问题。不是所有的产品人员都对人工智能有所了解,也不是所有的产品人员对数据链条的概念都有所耳闻。比方说,产品的数据是通过前端的一段JavaScript代码进行数据传输的,而这段代码可能和某一个产品的界面设计有紧耦合。当设计人员“突然”对现在的设计进行了更改,满心希望这样的更改可以改进产品,哪知道这也许反而“破坏”了这段收集数据的代码,从而使得数据链条断裂,而机器学习的某些代码可能就无法正常运行,或者模型接收到的是垃圾数据。在传统的观念里,一位设计师,可能很难理解为什么自己的工作会和机器学习紧密结合。所以,**这就需要数据科学家和各个岗位的人员去交流、去沟通,让更多的人能够理解数据产品的涵义**。
|
||||
|
||||
其次,数据科学和人工智能让产品成为一个有机整体。**我们一定要去理解产品效果的复杂性和组合性**。比方说,在很多互联网产品中,通过经验我们经常能够发现,产品外观设计的改变,常常能够带来比纯算法改变好得多的效果提升,而很多营销手段又常常能够几倍地提高用户对产品的转化率,也使得产品的效果得以提升。当然了,这并不是说,夸大任何一方面就能够让产品有更大的提高。实际上,**产品的最优情况往往是各个方面的一个复杂的协调平衡状态**。因此,理解数据科学在整个大环境中的位置就十分重要。
|
||||
|
||||
最后还有一个可以去做的,那就是看如何利用人工智能和数据科学去帮助产品团队的其他人员,比如能否帮助设计师和前端找到更好的创意,能否帮助产品经理找到更好的产品迭代方法等等,**让人工智能和数据科学融入到整个产品完整的图谱中,要比提高单个算法更有意义**。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了人工智能工程师和数据科学家所面临的一个重要的职场话题,那就是如何把握和产品部门的其他人员的关系。
|
||||
|
||||
一起来回顾下要点:第一,我们简要剖析了数据科学家和产品团队之间可能产生问题的原因和一些经典的情况。第二,我们分析了要去更好地推动这个关系,有哪些需要注意的地方,有哪些可以做的事情。
|
||||
|
||||
最后,给你留一个思考题,如果营销人员告诉你一个他们的方案,但这会影响你所负责的产品算法的呈现,这个时候你会怎么做呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
<audio id="audio" title="134 | 职场话题:数据科学家应聘要具备哪些能力?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c4/3b/c43f49e14e06e8b6a9de8879d023823b.mp3"></audio>
|
||||
|
||||
周一,我们探讨了在公司内部,数据科学家和产品团队的其他职能人员在协作中都会遇到哪些问题,以及如何看待数据科学家或者人工智能工程师所做的算法性工作在一个产品发展中的位置。
|
||||
|
||||
那么,今天我们稍微换一个方向,来讨论数据科学家和算法工程师在应聘方面的问题。一起来看看,作为数据科学家,在面试一家公司时,究竟应该怎么准备,有哪些信息是需要了解的。
|
||||
|
||||
希望今天的内容对正在思考进入这个行业的年轻学者、工程师有所帮助,从大的方向上为你的应聘提供一些可借鉴的内容。
|
||||
|
||||
## 数据科学家应聘的“硬”实力
|
||||
|
||||
对于数据科学家或者人工智能工程师来说,最核心的竞争力无疑是他们对人工智能、机器学习等技术的知识积累以及融会贯通的能力。
|
||||
|
||||
我们之前的一系列分享中已经提到了这些“硬”实力的大范畴,这里我做一个简单的归纳。
|
||||
|
||||
- **首先,我们需要理解和掌握一些机器学习的基本概念和理论。**
|
||||
|
||||
**第一个重点无疑就是监督学习**。
|
||||
|
||||
什么是监督学习呢?监督学习就是指我们通过外部的响应变量(Response Variable)来指导模型学习我们关心的任务从而达到我们需要的目的这一过程。**监督学习中需要彻底掌握三个最基础的模型**,包括**线性回归**(Linear Regression)、**对数几率回归**(Logistic Regression)和**决策树**(Decision Trees)。
|
||||
|
||||
怎么理解我说的“彻底掌握”呢?这里的彻底掌握有三层含义。
|
||||
|
||||
**第一,需要了解这些模型的数学含义,能够理解这些模型的假设和解法**。比如,线性回归或者对数几率回归的目标函数是什么;写好了目标函数之后,如何求解最优解的过程。对于这些核心模型,必须能够做到完全没有差错地理解。
|
||||
|
||||
**第二,需要了解什么场景下使用这些模型是最合适的,以及怎样把一个实际问题转化成为这些模型的应用,如果不能直接转换还有什么差距**。
|
||||
|
||||
**第三,能不能写实际的代码或者伪代码来描述这些模型的算法,真正达到对这些算法的掌握**。
|
||||
|
||||
监督学习当然不限于这三个算法,但是这三个算法是绝大多数机器学习任务在工业界应用的起点,也是学习其他算法模型的支点,可以按照这个思路去了解更多的算法。在面试中,能够对这些基本算法的理解有扎实的基本功,这一点很重要。
|
||||
|
||||
**了解机器学习的第二个重点就是无监督学习**。
|
||||
|
||||
无监督学习并没有明显的响应变量,其核心往往是希望发现数据内部潜在的结构和规律,从而为我们进行下一步决断提供参考。
|
||||
|
||||
从面试角度来说,**“K均值算法”往往是考察数据科学家整个无监督学习能力的一个核心点**。因此,对于这个算法有必要认真学习,做到真正的、彻底的理解。
|
||||
|
||||
怎么学习呢?和前面我们提到的监督学习一样,也需要从编程实现和算法本身两个方面入手对K均值进行把握。在掌握了K均值之后,还可以进一步去了解一些**基于概率模型的聚类方法**,扩宽视野,比如“**高斯混合模型**”(Gaussian Mixture Model)。
|
||||
|
||||
- **其次,虽然机器学习和统计学习有不少的重合部分,但是对于合格的数据科学家和人工智能工程师来说,一些机器学习方向不太容易覆盖到的统计题目也是需要掌握的。**
|
||||
|
||||
**第一,我们必须去理解和掌握一些核心的概率分布,包括离散分布和连续分布**。这里的重点不仅仅是能够理解概念,而且是能够使用这些概率分布去描述一个真实的场景,并且能够去对这个场景进行抽象建模。
|
||||
|
||||
**第二,那就是要理解假设检验**。这往往是被数据科学家和算法工程师彻底遗忘的一个内容。我们要熟悉假设检验的基本设定和它们背后的假设,清楚这些假设在什么情况下可以使用,如果假设被违背了的话,又需要做哪些工作去弥补。
|
||||
|
||||
**第三,那就是去学习和理解因果推断**(Casual Inference)。这虽然不是经典的统计内容,但是近年来受到越来越多的关注。很多学者和工程师正在利用因果推断来研究机器学习模型所得结果的原因。
|
||||
|
||||
- **再次,还有一个很重要的“硬”技能,就是要对系统有一个基本了解。**
|
||||
|
||||
**第一,就是具备最基本的编程能力,对数据结构和基础算法有一定的掌握**。编程语言上,近年来,Python可以说受到了诸多数据相关从业人员的青睐。因为其语言的自身特点,相对于其他语言而言,比如C++或者Java,Python对于从业人员来说是降低了学习和掌握的难度。但另一方面,我们也要意识到,大多数人工智能产品是一个复杂的产品链路。整个链路上通常是需要对多个语言环境都有所了解的。因此,掌握Python,再学习一两个其他的语言,这时候选择Java或者C++,是十分必要的。另外,很多公司都采用大数据环境,比如Hadoop、Spark等来对数据进行整合和挖掘,了解这些技术对于应聘者来常常说是一个让用人单位觉得不错的“加分项”。
|
||||
|
||||
**第二,就是对于搭建一个人工智能系统(比如搜索系统、人脸识别系统、图像检索系统、推荐系统等)有最基本的认识**。机器学习算法能够真正应用到现实的产品中去,必须要依靠一个完整的系统链路,这里面有数据链路的设计、整体系统的架构、甚至前后端的衔接等多方面的知识。考察候选人这方面的能力是查看候选人能否把算法落地的一个最简单的方式。因此,从我们准备面试的角度来说,这部分的内容往往就是初学者需要花更多时间了解和进阶的地方。
|
||||
|
||||
## 数据科学家应聘的“软”实力
|
||||
|
||||
前面我们聊了数据科学家应聘的“硬”技能,下面,我们再来看看候选人还需要注意和培养哪些“软”技能。
|
||||
|
||||
**数据科学家的第一“软”技能就是如何把一个业务需求转化成机器学习设置的“翻译”能力**。
|
||||
|
||||
什么意思呢?和纯理论学习的情况有所不同,大多数真实的业务场景都是非常复杂的。当产品经理提到一个产品构思的时候,当设计人员想到一个业务创新的时候,没有人能够告诉你,作为一个数据科学家而言,这个问题是监督学习的问题还是无监督学习问题,这个问题是可以转换成一个分类问题还是一个回归问题。有时候,你会发现好像几条路都走得通。因此,如何能够从逻辑上,从这些不同的设置所依赖的假设上来对业务场景进行分析,就成了数据科学家必不可少的一个核心能力。
|
||||
|
||||
分析业务场景这个“软”技能的确非常依赖工作经验。这里不仅仅是一个机器学习问题的“翻译”,还需要对整个系统搭建有所了解,因为真正合适的场景“翻译”往往是机器学习的问题设置和系统局限性的一个平衡和结合。举一个例子,一个推荐系统需要在百毫秒级给一个用户进行推荐,那么相应的方案就必然有一个计算复杂度的限制。
|
||||
|
||||
因此,场景的“翻译”其实是考察数据科学家和人工智能工程师的一个非常重要的步骤,也是看候选人是否真正能够学以致用的有效手段。
|
||||
|
||||
说到这里,你是不是会有疑问:如果我没有相关的从业经验,那如何来锻炼这种“翻译”能力呢?
|
||||
|
||||
其实,现在丰富的互联网产品已经为我们提供了一个无形的平台。当你在现实中看到一个真实产品的时候,比如京东的产品搜索、科大讯飞的语音识别系统等等,你设想一下,如果你是设计者,如果你是需要实现这个产品功能的数据科学家,你会怎么做?
|
||||
|
||||
实际上,很多面试问题,都是面试官直接询问你对某一个现成产品的设计思路,比如谷歌的面试官可能会询问你如何设计一个搜索查询关键字拼写检查组件。这个方法一方面是帮助你“开脑洞”,另一方面也是一种非常好的思维锻炼。
|
||||
|
||||
**另外一个很重要的“软”技能就是数据科学家的沟通表达能力**。
|
||||
|
||||
这可能会让有一些人感到意外,因为大家也许认为数据科学家和人工智能工程师完全是技术岗位,并不需要与人打交道。其实,这个理解是片面的。就像刚才提到的,数据科学家的一个重要职责就是把现实的业务场景“翻译”成机器学习的设置,那么在这个过程中,会和业务人员、其他工程师、科学家进行高频的沟通和交流。如何把你的思路、方案清晰地表达给同事和团队成员是非常重要的职责。
|
||||
|
||||
实际上,数据科学家不仅在公司内部承载着的这样的沟通任务,我们往往还需要在社区中做演讲、参与讲座等活动,成为社区中的一份子,都离不开沟通表达能力的磨练。
|
||||
|
||||
如何锻炼沟通表达能力呢?这里,我给初学者一个简单而实用的方法,那就是用一两句话来总结你的方案。你尝试用一小段话,但是不夹带任何专业术语,把你的方案说给不懂机器学习的人听。这个训练方法可以让你反复思考,直到找到一个最简洁有力的表达。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了人工智能工程师和数据科学家的一个重要的职场话题,那就是作为数据科学家应聘时需具备的“硬”实力和“软”实力。
|
||||
|
||||
一起来回顾下要点:第一,我们讨论了机器学习、统计知识和系统这三大“硬”实力。第二,我们分析了场景翻译和沟通能力这两个“软”实力。
|
||||
|
||||
最后,给你留一个思考题,当下深度学习框架大行其道,那么对于应聘来说,你觉得了解和掌握各种深度学习框架会让你更有优势吗?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
63
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/135 | 职场话题:聊聊数据科学家的职场规划.md
Normal file
63
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/135 | 职场话题:聊聊数据科学家的职场规划.md
Normal file
@@ -0,0 +1,63 @@
|
||||
<audio id="audio" title="135 | 职场话题:聊聊数据科学家的职场规划" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/cd/3e8db35ab5ad7a20edc1460266e600cd.mp3"></audio>
|
||||
|
||||
今天,我们继续来聊数据科学家或者人工智能工程师的职场话题。我们更进一步,来聊聊数据科学家的职场规划。
|
||||
|
||||
当然,说到职场规划,这确实是一个非常宽泛的主题。我们今天要探讨的不是数据科学家“应该”怎么发展,而是说,**有哪些职业发展的“可能性”**,希望能够为你规划自己的职业生涯起到一个抛砖引玉的作用。
|
||||
|
||||
## 数据科学家的“垂直发展”
|
||||
|
||||
**数据科学家一个最直接的职场规划,就是在技术线上持续发展,逐渐成为一个技术专家**。目前,不同公司对数据科学家类型,这里包括研究科学家、算法专家、人工智能工程师等职位的职业生涯设置并没有完全统一的模式。但是,数据科学家类型的职位在技术线上大体有这么几个台阶可以发展。
|
||||
|
||||
- **第一个台阶是“初级数据科学家”**。
|
||||
|
||||
这个台阶对应很多公司入门级别的数据科学家,并且大概是对应博士生毕业直接入职,或者硕士生有2-3年工作经验后入职这样的情况。这个阶段的数据科学家,其主要职能是在一个比较大型的产品解决方案中,完成一个小的模块或者任务。当然,也可以是,在一个比较小型的产品解决方案中,完成较大的模块或者任务。
|
||||
|
||||
初级数据科学家对机器学习和人工智能的掌握程度主要集中于单独的算法。因为对业务需求接触不多,在如何利用模型和算法来对整个业务提供解决方案,也就是我们之前说的“翻译”业务的能力上,存在着比较大的挑战。这也是初级数据科学家在这个阶段最需要积累和进阶的部分。
|
||||
|
||||
- **下一个台阶就是“中级数据科学家”**。
|
||||
|
||||
这个台阶对应很多公司的“高级数据科学家”(Senior Data Scientist)、“主管数据科学家”(Staff Data Scientist)。一般来说,“初级数据科学家”有1-3年工作经验之后就有机会晋升到“高级数据科学家”,然后再有1-3年工作经验之后就有机会晋升到“主管数据科学家”。“主管数据科学家”平均应该有5年左右的从业经验。
|
||||
|
||||
对于这个台阶的数据科学家而言,已经可以承担一个比较大型的产品解决方案的绝大部分甚至全部的模块和任务。并且在团队内部,这个台阶的数据科学家已经可以指导绝大多数的初级数据科学家。同时,这个级别的数据科学家对公司的整个宏观产品线有了更多的认识,对业务需求的“翻译”能力有很大幅度的提升。在纯技术层面,“中级数据科学家”对于机器学习和人工智能算法模型的把握已经跳出了单独一个算法或者模型的层面,可以比较好地去把握一个方向,特别是有可能的新的研究方向。
|
||||
|
||||
- **最后一个台阶,我称之为“高级数据科学家”**。
|
||||
|
||||
这个台阶对应很多公司的“资深主管数据科学家”(Senior Staff Data Scientist)、“主任数据科学家”(Principal Data Scientist)以及其他更高的职位。一般来说,成为“中级数据科学家”后,再有1-3年的工作经验可以晋升到这个台阶。“高级数据科学家”平均应该有5-7年的从业经验。
|
||||
|
||||
对于这个台阶的数据科学家而言,基本上已经算是行业的专家,对某一个类型或者某几个类型的产品解决方案有深刻洞察。另外一个能力就是这个台阶的数据科学家相对比较容易举一反三,能够对新的产品或者新场景下的解决方案有相对快速和成熟的理解。在团队内部,这个台阶的数据科学家处于整个团队的核心的位置,对“中级数据科学家”和“初级数据科学家”都能够起到很好的指导作用。在纯技术层面,可以针对机器学习和人工智能过去20年的大部分算法融会贯通,能够带领团队对一系列新的研究方向有比较好的把握。
|
||||
|
||||
## 数据科学家的“升级发展”
|
||||
|
||||
**数据科学家的另外一种职场规划,其实也和众多工程师的规划类似,那就是转到“管理线”或者叫“技术管理”的岗位,特别是管理和数据科学、人工智能直接相关的团队**。
|
||||
|
||||
数据科学家对于管理职位的优势是,他们有着在这样团队中工作和运行的第一手经验和资料。这些也为数据科学家转到管理职位提供了一些先天的背景优势。
|
||||
|
||||
因为人工智能团队或者数据科学团队具有高度专业化和技术化的特点,没有相关技术背景的管理人员,会非常难以胜任这样的角色。主要表现在以下几个方面。
|
||||
|
||||
第一,这些团队往往意味着需要招聘、管理和拓展一个由硕士和博士背景为主体的团队,完全理解和体会这个人群的需求以及这种团队对于工程、技术等方面的独特需求,对于一般背景的技术管理人才来说可能会比较困难。
|
||||
|
||||
第二,这个技术管理职位往往需要和技术社区,特别是人工智能社区有一个积极的交互。完全没有相关技术背景,在这样的社区立足并且作为一个领导者得以发展,相对比较困难。
|
||||
|
||||
第三,当然还是在技术方案上,因为专业性过强,如果技术管理人员没有背景,就无法对方案进行评估,然后就变成了完全的“人事经理”(People Manager)。
|
||||
|
||||
**除了从人工智能团队管理岗位入手以外,数据科学家还可以挑战和人工智能有关的一些管理岗位,比如数据,或者有时候叫大数据部门**。这些部门和人工智能部门经常紧密合作,所以数据科学家也算是对这些部门耳濡目染,相对来说有着比较清晰的认识。
|
||||
|
||||
毋容置疑,数据科学家从纯技术岗位到管理岗位的转换过程中,肯定会面临不少困难。对于有志转岗的数据科学家来说,他们往往在纯技术岗位上工作得比较优秀,一些管理的机会自然出现,于是也就顺理成章地转了过去。然而,对于这些优秀的纯技术人员来说,比如“中级”或者“高级”数据科学家,真正的挑战在于,如何能够去领导一个团队去完成一个使命。一些优秀的数据科学家因为自身条件优异,往往存在大包大揽的情况,希望靠自己的能力做出比整个团队还要好的成绩,反而在管理岗上无法施展应有的水平。其实,如何做一个优秀的人工智能技术管理者,这还是一个非常有新意和挑战的话题,篇幅有限,今天就不展开了。
|
||||
|
||||
## 数据科学家的“跨界发展”
|
||||
|
||||
除了我们刚才说的在纯技术岗位的发展以及往管理职位发展以外,数据科学家其实还有**一些横向发展的机会**。
|
||||
|
||||
比如,最“无缝”发展的就是**在工程团队或者数据分析类团队之间进行转换**。因为数据科学家的工作性质,这两类团队的工作或多或少都已经包含在了数据科学家的日常工作中了。因此,数据科学家可以比较自然地转换到这些团队中。当然,这里还是需要对一些技能进行加强培训。
|
||||
|
||||
另外,**数据科学家其实比较适合转移到产品经理岗位**。在“中级数据科学家”之后,这些技术人员需要对业务、对整个产品有比较深入的理解,包括需求、数据、工程技术等,才能对一个产品提出比较合适和成熟的解决方案。另外,数据科学家还需要不断提升产品的质量水平,这里面其实就有不少产品经理的角色。因此,数据科学家算是具备成为一个产品经理的一些条件。不过,我们这里要指出的是,数据科学家的整个背景训练主要是以纯技术为主,特别是人工智能算法,因此转换到产品经理的时候,可能往往过分强调算法的力量,而忽视整个产品的其他方面。所以,即便是一个成熟的数据科学家依然需要一段时间的培养和培训,才能够转换到产品经理的角色。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了人工智能工程师和数据科学家的职场规划问题。一起来回顾下要点:第一,我们简单介绍了最为自然的一条发展途径,走纯技术的路子,数据科学家可以有怎样的一条道路向前发展。第二,我们分析了从技术岗位到管理岗位的一个转换,数据科学家又有什么优势。第三,我们简单讲了从数据科学家到其他类型职位一个转换的问题。
|
||||
|
||||
最后,给你留一个思考题,你有没有什么方法,可以知道自己比较适合什么样的职业发展规划呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
128
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/136 | 如何组建一个数据科学团队?.md
Normal file
128
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/136 | 如何组建一个数据科学团队?.md
Normal file
@@ -0,0 +1,128 @@
|
||||
<audio id="audio" title="136 | 如何组建一个数据科学团队?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/23/d8/237c57b621cf66dbda9766747f5b22d8.mp3"></audio>
|
||||
|
||||
数据科学团队眼下已经成了很多数据驱动型公司的标准配置,数据科学家也成了最“性感”的职业。不少公司都在想办法建立或扩展自己的数据科学团队,而究竟需要什么样的数据科学团队,成了很多公司在发展过程中都会遇到的棘手问题。
|
||||
|
||||
在目前的职业市场上,有各种背景、各种经历的人都自称为“数据科学家”。那么,如何从这个蓬勃发展,却鱼龙混杂的人才市场中找到合适的团队成员呢?今天我就来和你聊一聊作为一个工程团队的负责人,或者一家公司的CEO,该如何招聘并打造自己的数据科学团队。
|
||||
|
||||
## 数据分析还是算法模型
|
||||
|
||||
目前人才市场上大致有两类数据科学家,一类偏数据分析,一类偏算法模型。因为这两类人才的区别,不同公司乃至同一公司的不同数据科学团队就有了差别。在招聘之前你必须明白,这两类数据科学家的特质很难在同一个人身上体现出来。也就是说,你必须根据当前公司和团队的需求,来决定目前应该招聘更偏重数据分析,还是偏重算法模型的数据科学家。
|
||||
|
||||
先来说说偏重数据分析的数据科学家,他们可能来自于统计、数据分析等学科,也可能来自于很多需要数据分析的自然科学学科,比如实验物理、生物、计算化学等。作为团队的负责人,你需要重点考察候选人是否系统学习过数据分析的相关课程,是否具备数据分析的基本能力。下面我从理论知识和实际应用操作两个角度来和你介绍下考察要点。
|
||||
|
||||
从理论知识的角度来说,你需要考察候选人:
|
||||
|
||||
<li>
|
||||
是否对概率统计有基本的认知;
|
||||
</li>
|
||||
<li>
|
||||
是否能够使用基本的假设检验对数据进行分析;
|
||||
</li>
|
||||
<li>
|
||||
是否对高级的假设检验方法,比如非参数假设检验(Nonparametric Hypothesis Testing)有所了解,能否快速学习和查询到相关的方法;
|
||||
</li>
|
||||
<li>
|
||||
是否了解A/B实验,并基本了解实验设计;
|
||||
</li>
|
||||
<li>
|
||||
是否了解高级的因果推论(Causal Inference)工具,并能够使用简单的因果推论工具对实验数据进行分析;
|
||||
</li>
|
||||
<li>
|
||||
是否了解如何对时间序列下的数据进行合理分析。
|
||||
</li>
|
||||
|
||||
当然这些技能只是作为数据分析候选人的一些基本素质,具体还需要和领域知识相结合。
|
||||
|
||||
从实际应用操作的角度来说,你还需要考察候选人:
|
||||
|
||||
<li>
|
||||
是否熟悉一些基本的数据分析工具语言,比如R或者Python;
|
||||
</li>
|
||||
<li>
|
||||
是否对SQL有所了解;
|
||||
</li>
|
||||
<li>
|
||||
是否对Hadoop等大数据处理工具有所涉猎;
|
||||
</li>
|
||||
<li>
|
||||
是否了解一些基本的计算机算法。
|
||||
</li>
|
||||
|
||||
同样的,这些也是基础素质,还需要和具体的职位相结合,你才能考察候选人的综合情况。
|
||||
|
||||
接着我们来看偏重算法模型的数据科学家,他们主要来自于计算机科学、计算机工程、电气工程等工程方向。你需要重点考虑他们是否有基本的算法建模能力;是否系统地学习过算法、机器学习、统计分析等课程;是否在实际工作中,有系统的相关开发经历;对数据的认识,特别是对数据驱动型产品是否有基本的了解。下面我依次从理论知识和实际应用操作两个角度来谈谈具体的考察内容。
|
||||
|
||||
从理论知识的角度来说,你需要考察候选人:
|
||||
|
||||
<li>
|
||||
是否对概率统计有基本的认识;
|
||||
</li>
|
||||
<li>
|
||||
是否对传统的机器学习算法模型有所了解,包括分类、回归、聚类等;
|
||||
</li>
|
||||
<li>
|
||||
是否对概率图模型有所了解;
|
||||
</li>
|
||||
<li>
|
||||
是否对深度学习模型有所了解;
|
||||
</li>
|
||||
<li>
|
||||
是否对优化算法有所了解;
|
||||
</li>
|
||||
<li>
|
||||
是否有基本的计算机算法、数据结构、数据库、操作系统的知识;
|
||||
</li>
|
||||
<li>
|
||||
是否对某一些特定领域内的模型有所了解,包括但不限于信息检索、推荐系统、计算广告系统、计算机视觉、文本挖掘和分析、自然语言处理。
|
||||
</li>
|
||||
|
||||
这些,特别是第1项到第6项是候选人的基本素质。第7项是针对某一个具体的职位所需要的背景知识。
|
||||
|
||||
从实际应用操作角度来说,你需要考察候选人:
|
||||
|
||||
<li>
|
||||
是否可以使用某种计算机语言(比如Python、C++、Java、Scala)来实现一些机器学习算法;
|
||||
</li>
|
||||
<li>
|
||||
是否可以使用和扩展现有的机器学习工具(比如Scikit Learn、XGBoost、Vowpal Wabbit等);
|
||||
</li>
|
||||
<li>
|
||||
是否可以使用以Hadoop为基础的大数据工具(比如Hive、Pig、Spark等)来构建生产环境;
|
||||
</li>
|
||||
<li>
|
||||
是否对深度学习框架(比如TensorFlow、Caffe、MxNet、Torch等)有所了解。
|
||||
</li>
|
||||
|
||||
这里列出的也是一些基础素质,还需要和具体的职位相结合,来考察候选人的综合情况。
|
||||
|
||||
总体说来,如果你希望招聘的职位更偏重于理解现有数据,通过数据来对公司或团队的下一步决策有所帮助,那么这个职位就更偏向于数据分析。如果你希望通过算法和模型来改进你的产品,无疑你需要招聘一个算法模型方向的数据科学家。
|
||||
|
||||
## 小团队、大团队
|
||||
|
||||
不同的团队往往需要不同的数据科学家配置。即便是同一团队,在不同时期其实也需要不太一样的设置。我这里讲的是一些基本的团队设置理念,具体的团队还需要根据不同的领域有所调整。
|
||||
|
||||
总体说来,在团队比较小的时候,甚至是初创公司的团队,你需要具有“通才”性质的数据科学家,而在团队扩大、公司稳定以后,你需要各类“专才”性质的数据科学家。
|
||||
|
||||
团队比较小的时候,我们可能只需要招聘一两位数据科学家。这个时候的数据科学家必须同时承担数据分析和算法建模两个角色。有些情况下,这时候的数据科学家其实更偏向于“数据工程师”(Data Engineer)的角色,那就是和其他工程师一起搭建公司的数据平台,对数据的引入、整合、清理提供支持。
|
||||
|
||||
早期时候,因为公司内部基础设施的限制,数据科学家往往需要花费大部分时间在数据平台和通路的构建上。这时候,其实很难形成有效的数据分析和算法建模工作。从另外一个角度来说,在公司非常早期,也就是在数据平台还没有一个基本雏形的时候,招聘和建立数据科学团队是不现实的。当有了基础的数据平台时,和数据有关的工作一般就是计算一些简单的产品运行指标(Metrics)然后在仪表盘(Dashboard)里展现出来。能够达到这一阶段后,一个团队或者公司才具备了建立数据科学团队的最基本条件。
|
||||
|
||||
小团队所需要的“通才”数据科学家有两个内涵。第一,在初期,数据分析和算法建模都同样重要。甚至在有些情况下,数据分析有着更加急迫的需求(因为需要人为地对产品迭代进行决策)。这个时候,以数据分析为主导的数据科学家要能够对现在的产品需求有很强的理解,能和产品经理、其他工程师一起快速分析产品的问题,为产品迭代的决策提供数据支持。
|
||||
|
||||
第二,在初期,绝大多数产品所需要的算法和模型都并不复杂,甚至仅仅需要数据科学家部署最基本、最简单的算法。因此这个时候,即便有算法建模需求,也只需要数据科学家有比较广的知识就行,能够快速识别和实现最基本的模型。在这个阶段,对某一个方向有着深厚背景的“专才”往往并不能体现出优势。
|
||||
|
||||
当业务逐渐稳定并且扩展以后,团队也逐渐扩张,小团队的“通才”模式就慢慢不太适应组织的发展了。这个时候,我们需要针对目前的产品和业务招聘“专才”数据科学家。一般来说,我们需要有一部分数据科学家负责数据分析方面,需要另外一部分数据科学家负责算法和模型开发方面。这时候单个人往往已经不能胜任两方面的任务了。
|
||||
|
||||
从数据分析的方面讲,“专才”的模式需要我们更细地区分开两类数据科学家,一类是负责设计A/B实验、设计和分析产品指标的专项数据科学家,另一类是对各个产品领域进行长时间分析数据内涵(Insights)的数据科学家。
|
||||
|
||||
从算法建模的方面讲,“专才”模式往往就是针对不同的业务流程线,需要招聘单独的人才,比如针对图像处理的人才、针对搜索系统的人才、针对推荐系统的人才。这个时候,能否招聘到称职的领域专家,成了团队和产品能否持续良性发展下去的根本因素。这个阶段招聘需要注意的问题是,不要寄希望通过招聘“通才”来发现“专才”,因为从“通才”到“专才”的训练是需要很长时间的,这里面有短时间内不可逾越的鸿沟和难以积累起来的经验。所以,当公司和团队发展到一定规模的时候,分清形式进行“专才”招聘是必须要进行的任务目标。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你简单分析了如果要组建一个数据科学团队,你需要招聘什么样的数据科学家。一起回顾下内容要点:第一,偏数据分析和偏算法建模的两类数据科学家在技能背景方面有很大区别;第二,“通才”和“专才”在公司或团队的不同阶段承担着不同的角色。
|
||||
|
||||
最后,给你留一个思考题:如何在筛选候选人简历的时候,就能够比较准确地了解这位候选人的经历和能力更偏向数据分析还是偏向算法呢?另外,如果你想成为数据科学团队的一员,不妨对照今天我们聊的考察要点自测一下,看看接下来还需要在哪些方面继续努力,做好积累呢?
|
||||
|
||||
期待你给我留言,和我一起讨论!
|
||||
|
||||
|
||||
81
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/137 | 数据科学团队养成:电话面试指南.md
Normal file
81
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/137 | 数据科学团队养成:电话面试指南.md
Normal file
@@ -0,0 +1,81 @@
|
||||
<audio id="audio" title="137 | 数据科学团队养成:电话面试指南" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/0f/fd6c3978d8b13e72df87da569010220f.mp3"></audio>
|
||||
|
||||
眼下,数据科学或者人工智能团队已经成了很多数据驱动公司的标准配置团队,数据科学家或者人工智能工程师也成为了最“性感”的职业。不少公司都在想办法建立或者扩展自己的数据科学团队。那么,对于一个公司来说,究竟需要什么样的数据科学团队呢?这就成了很多公司在发展过程中都会遇到的棘手的问题。
|
||||
|
||||
我们在之前的一篇分享里已经剖析过,作为一个工程团队的负责人,你该如何招聘自己的数据科学家团队。在那篇分享里,我们探讨了目前人才市场上大致有两类数据科学家,一类偏数据分析,一类偏算法模型。并且我们详细探聊了聊这两类数据科学家所需的技能和在不同团队(比如大团队和小团队)中起到的作用。
|
||||
|
||||
今天,我们来聊一聊组建数据科学家团队所必不可少的一个步骤:电话面试。
|
||||
|
||||
## 筛选简历
|
||||
|
||||
在电话面试之前,有一个步骤是必不可少的,那就是筛选简历。因为人工智能和数据科学家的职业背景的原因,我来分享一下如何筛选具有博士学历,特别是计算机专业相关毕业生的简历。筛选简历的过程需要很细心,对于普通的博士毕业生,我们会快速看以下两个方面的信息。
|
||||
|
||||
**第一,候选人是否有高水平的论文发表**。关于论文发表,首先需要看的是论文档次,也就是论文是否发表在高质量的会议上或者高水平的期刊上。对于计算机专业的博士生来说,会议一般比期刊更重要。其次,我们也要看候选人的论文是专注一个问题或者一个小领域还是很多领域都有涉猎。同时,对于这些论文,要关注候选人是第几作者。然后,我们需要关注的是论文发表频率,看论文工作是否都是一年做出来的。最后,我们可以去看一看这些论文的引用数。一般来说,博士刚毕业不会有很高的论文引用量,但也不乏水平比较高的候选人,论文会有惊人的引用量。
|
||||
|
||||
**第二,我们需要看一看候选人是否有工业界实习经历,是研究实习还是工程实习**。这里面,我们可能关注的是实习的公司。而且,我们可以关注是否是同一家公司还是多个公司。如果是研究实习的话,我们还需要去看一看候选人是否有相应的论文发表。
|
||||
|
||||
在看了这两个因素之后,我们心中对于这个候选人就有一个很基本的认识。**在需要高标准的情况下,一个博士毕业生需要有3-4篇第一作者的高水平论文发表(在毕业的时候,引用数在70-100左右),然后有1-2次工业界实习经验**。
|
||||
|
||||
除了这两个硬指标以外,我们还会关注下面这些内容:
|
||||
|
||||
- 简历里是否有一些信息不完整的部分。比如有一些明显断档的经历,没有本科学校,没有说明博士生导师;
|
||||
- 会什么编程语言和开发工具。是否只熟悉Matlab或者R,是否有开源项目贡献;
|
||||
- 是否已经有审稿经验;
|
||||
- 是否已经有组织会议的经验。
|
||||
|
||||
所有这些因素都没有明显问题之后,我们已经定位到了比较靠谱的候选人(通常,只有少数人能够通过上面这轮简历筛选)。我们可以根据实际情况来调整在筛选简历这里的标准线从而让候选人能够和我们直接交流证明自己的实力。
|
||||
|
||||
这里再说几个比较细的准则:
|
||||
|
||||
- 博士生的论文中,非第一作者的一般不算数;
|
||||
- 已经发表的会议论文和同一内容的期刊文章算一篇;
|
||||
- 可以有非第一档次会议或者期刊的论文,但没有第一档次就很难说明问题;
|
||||
- 如果有单一作者的论文,是一个比较大的问题,电话面试的时候一定要问清楚原因;
|
||||
- 课程项目原则上也不算数(注意,这是对博士毕业生而言);
|
||||
- 简历是LaTex生成还是Word;
|
||||
- 毕业学校和GPA,一般不是很侧重要考虑的问题。
|
||||
|
||||
再说几个对于已经有工作经验的候选人的简历筛选要素:
|
||||
|
||||
- 如果有教职经验或者博士后经验,原则上是一个大问题,需要电话面试问清楚;
|
||||
- 一两年左右频繁换公司是一个大问题,需要电话面试问清楚。
|
||||
|
||||
这里要多说一句的是,上面这些标准是对计算机相关专业比较适用的准则。而对于数学、应用数学、统计、物理等专业的人来说,可能有些标准需要重新设定(比如发表论文的标准需要降低)。总之,这里说的是一些比较大的方向,不过在把握了这些原则之后,我们就可以安排少量的候选人电话面试了。
|
||||
|
||||
这里我们简单说一下对于硕士阶段的候选人的简历筛选。一般来说,硕士和博士有不同的培养目标,因此上面所说的很多标准和原则对硕士毕业生并没有完全的指导意义。**对于硕士毕业生来说,公司实习经验是很重要的**。不排除一些优秀的硕士毕业生已经有论文发表,因此这方面也可以降低一些标准来衡量。**对于硕士毕业生来说,学科项目可以作为一些参考**,不过因为大多数学科项目都没有真正的应用性,我们只能从一个侧面了解这个候选人可能具备的一些技能。
|
||||
|
||||
## 电话面试
|
||||
|
||||
筛简历的过程之后,就是电话面试了。电话面试的目的是要验证这个候选人是不是像简历里所说的那样有相应的经历。当然,有一些公司在电话面试的时候也会考察候选人解决问题的能力,这个内容也会经常出现在电话面试的安排中。对于科学家的职位,我们一般需要1-3轮电话面试,来了解下面这些信息:
|
||||
|
||||
- 了解候选人简历上的基本信息,如果对简历上的内容有疑点,需要在这个阶段问清楚;
|
||||
- 考察候选人是否具备基本的专业知识,并对相关领域有一定的见解,考察候选人是否有其他领域的知识;
|
||||
- 考察候选人是否有基本的专业相关的编写代码能力;
|
||||
- 初步感知候选人的表达能力。
|
||||
|
||||
在询问候选人简历信息的时候,以下这些内容是需要弄明白的:
|
||||
|
||||
- 对于候选人是第一作者的论文,候选人是否能够很清晰地说出这些论文所解决的问题及解决思路。在进一步的沟通里,候选人是否能够讲清楚模型细节甚至是公式细节。候选人能否把实验的目的、数据、比较算法讲清楚。当然,这需要面试官提前做好准备。同时,询问候选人其他作者在这篇论文中的贡献;
|
||||
- 对于候选人是非第一作者的论文,询问候选人在这个工作中起到了什么作用。看候选人是否诚实可信,也可以看出候选人的学术道德水平;
|
||||
- 对于单一作者的文章,需要候选人解释为什么这个工作没有合作人,博士生导师为什么不是合作者,这个论文的研究时间如何而来;
|
||||
- 对于有博士后经验或者教职经验的候选人,要询问候选人是否了解工业界研究和学术界研究的区别,如果以后有机会,是否还考虑学术界教职;
|
||||
- 对于有工作经验的候选人,要询问候选人反复换工作的原因,询问清楚候选人在项目里的具体贡献,候选人的职业规划,看职业规划和简历经历是否相吻合。对于在某一个公司待了很长时间没有升职的候选人,也需要询问一下为何在原公司里没有其他机会。
|
||||
|
||||
在考察候选人专业知识的时候,需要弄明白以下这些内容:
|
||||
|
||||
- 对于某一专业最基础的一些概念和知识,候选人是否能够清晰地讲解出来。这一条其实很多人很难做到,不少人能够做复杂的工作,却往往在最基础的内容上含混不清。而在一些跨领域的工作中,基础知识往往是一个科学家所能够依赖的,提供解决方案的最初的工具。所以,基础很重要;
|
||||
- 候选人是否能诚实地说明自己懂什么,不懂什么。在广泛的领域里,科学家应该有足够的自信说自己的专长是什么,自己的局限在哪里;
|
||||
- 候选人是否对跨领域知识一窍不通,还是略有知晓,界限在哪里;
|
||||
- 在考察编程水平方面,虽然很多公司已经有比较完备的方案考察软件工程师,但这些题目和考察目的其实不太适合科学家,这需要公司专门针对科学家制定一些考察题目。
|
||||
|
||||
在上述考察候选人各个方面的过程中,一个贯穿始终的主题就是要看候选人是不是能和面试人员进行有效的沟通。当然,也要考虑到,有人可能不太适应电话面试,而在面对面的交流时则毫无问题。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我们分析了组建一个数据科学或者人工智能工程师团队,你需要招聘什么样的数据科学家。我们重点讲了讲如何筛选博士阶段候选人的简历以及电话面试的问题,我们是从招聘的角度来讲这个问题,那么从应聘的角度来看,也希望能给你一些启发和借鉴。
|
||||
|
||||
最后,给你留一个思考题,如果一个候选人并没有什么论文,但是有多年的企业经验,如何来衡量这样的候选人呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
<audio id="audio" title="138 | 数据科学团队养成:Onsite面试面面观" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8c/30/8c719f6840f6911a09e140b294b09630.mp3"></audio>
|
||||
|
||||
本周我们来聊数据科学或者人工智能团队的招聘话题。周一的分享里,我们聊了聊组建数据科学家团队所必不可少的两个步骤,筛选简历和电话面试。我们着重从招聘博士毕业生的角度对这两个环节进行了剖析,梳理了如何看简历,以及在电话面试时需要考察哪些内容。
|
||||
|
||||
今天,我们来聊一聊电话面试后面的一个环节,也就是邀请候选人到公司面试,俗称Onsite面试。
|
||||
|
||||
## 从电话面试到Onsite面试
|
||||
|
||||
电话面试之后,如何判断是否要邀请候选人到公司来面试呢?一般来说,有这么两种情况是需要邀请候选人到公司来面试的,从而进一步判断候选人的水平。
|
||||
|
||||
第一,候选人的简历以及其在电话面试中表现的水平很高,的确是公司需要的人才。这样的候选人进入Onsite面试的通道是水到渠成的,要加快速度实施公司招聘流水线的后面步骤。对于这样的候选人来说,Onsite面试主要是要考察候选人有没有其他特殊情况,导致其无法胜任工作。
|
||||
|
||||
第二,候选人的简历或电话面试中的表现存在争议。可能在好几轮的电话面试中,候选人在其中有些轮的表现要明显好于其他轮;或者候选人得到了很多好评,但是也有一些比较负面的评价。这个时候,我们采取不“一棒子打死”的态度,往往希望能够邀请候选人到公司来仔细考察。
|
||||
|
||||
## Onsite面试
|
||||
|
||||
在经历了简历筛选和电话面试的流程之后,我们已经对候选人有了一个初步的了解:他(她)的背景、熟悉以及不熟悉的领域、编程能力和沟通能力。对于各方面都表现不错的候选人,我们一般就会安排到公司来进行现场面试。对于科学家岗位,现场面试一般包括下面这些环节:
|
||||
|
||||
- 一场一个小时左右的学术报告会;
|
||||
- 和招聘经理讨论可能的项目方向;
|
||||
- 和其他科学家、工程师讨论技术和研究问题;
|
||||
- 在白板上展示基本的编程开发能力;
|
||||
- 和人事讨论职位的其他问题。
|
||||
|
||||
**学术报告会是考察候选人学术水平的一个非常重要的环节**。因为简历和电话面试都无法系统地看出候选人的整个学术生涯的特征,比如是偏理论还是偏应用?是蜻蜓点水似的研究,还是专注某几个问题?这样我们能够看到候选人的整个学术生涯的清晰明确的线条。
|
||||
|
||||
同时,报告会还是观察候选人语言能力的好机会,看候选人是否有较强的语言组织能力,能够清晰地表达自己。这一点之所以关键是因为有一些候选人连自己的工作都讲不清楚。
|
||||
|
||||
另外一个需要考察的就是,看候选人能否在公开场合接受各种质疑和对自己工作的挑战,包括候选人是否能够承认自己工作的局限和不足,是否能够礼貌且“一语中的”(To-The-Point)地回答技术问题。
|
||||
|
||||
和招聘经理讨论可能的项目方向,很多候选人显得很随意,觉得这就是闲聊。其实这也是考察候选人的一个很重要的机会。
|
||||
|
||||
首先,招聘经理可以说一些公司的产品或是项目,看看候选人是否有兴趣,是否能够通过一些简单的产品介绍,问出一些有科学价值的问题。**会问问题,其实是一个非常重要的技能**。
|
||||
|
||||
招聘经理也可以稍微深入地讨论一两个产品具体的现实问题,看候选人能否快速说出一些解决方案或者是一些思路。在整个谈话中,可以体会出候选人是否只有学术的经验而没有任何产品和产业的“感觉”(Sense)。有一些候选人在这个阶段会显得没法把谈话进行下去,完全是倾听问不出任何问题。这就需要招聘经理仔细控制谈话,来看候选人是否对新事物有好奇心,是否能够跟上思路,是否对新领域新问题有快速的思考。
|
||||
|
||||
和参加面试的科学家以及工程师讨论研究问题,主要考察的是候选人在一个类似工作的环境里能否“半”独立地完成科研解决方案的设计和实现。为什么说“半”独立,是因为这个环节里,沟通也是很重要的,很多条件、约束和限制都需要候选人和面试人员进行有效沟通来理解清楚。因此,候选人面对的并不完全是“应用题”似的独立解决问题的场景。
|
||||
|
||||
通常的形式是,**面试人员针对某个具体的问题,询问候选人如何提供一个有效的科学解决方案**。这里面需要注意下面这些环节。
|
||||
|
||||
1.候选人能否问出有效的问题,这些问题是不是在帮助候选人自己减少问题的不确定性,帮助候选人自己寻找答案,还是漫无目的地问各种问题。
|
||||
|
||||
2.候选人是不是不假思索地就提供一些思路,然后也没有认真思考,又反反复复更换思路。这是候选人没有系统思维能力的一个体现。
|
||||
|
||||
3.候选人的整体思维模式是怎样的?
|
||||
|
||||
一般说来,有两种思维模式。第一种是先提出一个可能的多步骤解决方案,然后看是否能够简化步骤,再看能否提出比较规范的数学模型;第二种思维模式是先提出比较完整的数学模型,然后根据实际情况简化,提出更加快速的算法。
|
||||
|
||||
这两种思维模式都是行之有效的思维方式。但是也有候选人在两者之间踌躇,一方面提不出基本的解决方案,一方面也写不出完整的数学模型来。
|
||||
|
||||
4.候选人能否在提出基本方案或者是数学模型之后,用自己掌握的方法把问题的细节算法写出来,并且能够分析算法的各方面特征。这考察的是候选人解决问题的连贯性和独立性。有一些候选人的确能够写出漂亮的数学模型,但是很可能完全没办法把模型算法化,写出来的程序惨不忍睹。
|
||||
|
||||
5.还有一个需要考察的维度就是,候选人遇到领域之外的问题,是如何思考的。有的候选人就彻底懵了,完全不能理性地提出方案。而有的候选人则会小心翼翼地利用基础知识,尝试解决问题,或者是把新领域的问题转化成自己熟悉的问题。
|
||||
|
||||
值得注意的是,在这个环节中表现不好的候选人,不管过去在论文、学校方面有多么优秀的经历,都要打一个大问号。事实证明,在这个阶段不那么令人满意的候选人,在现实工作中往往也很难胜任实际的工作。
|
||||
|
||||
**对于有经验的候选人,除了重点考察能否提出优秀的解决方案外,还可以看候选人是否具有“全局观”**,比如对这些问题的考量:如何设计更加有效的数据通路,没有数据怎么办,上线以后系统表现不好怎么办等。
|
||||
|
||||
**对候选人在白板上进行基本的编程能力的测试,是整个Onsite考察中的另外一个核心内容**。总的说来,数据科学家或者人工智能工程师的编程能力需要和普通工程师的基本相当,有些时候甚至要更高。这里面,除了考察基本的算法问题以外,还需要考察能否对普通的机器学习算法进行编程,也就是说,看候选人是否真正能够把模型或者一些算法用程序实现出来。关于候选人的编程能力问题,这是一个单独的话题,今天我们就不在这里展开了。
|
||||
|
||||
有一点需要留意观察,候选人的表现是否在有压力或者劳累(毕竟一天的现场面试是很累的)的情况下有重大波动。优秀的候选人能够通过沟通来缓解自己的压力。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我们讨论了Onsite面试,总结一下要点:第一,我们讲了如何决定一个候选人可以从电话面试过度到Onsite面试;第二,我们详细梳理了Onsite面试方方面面的问题。希望这些内容能给你一些启发和借鉴。
|
||||
|
||||
最后,给你留一个思考题,Onsite面试之后,如何来决定是否录用这个候选人呢?是不是需要所有的人都赞同? 如果不是所有人都赞同,怎么综合意见做出最后的决定呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
<audio id="audio" title="139 | 成为“香饽饽”的数据科学家,如何衡量他们的工作呢?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9a/1d/9a16fff10288a0ee8b6436554d44d91d.mp3"></audio>
|
||||
|
||||
本周我们聊了在构建一个数据科学家团队时,从筛选简历入手到电话面试,再到Onsite面试这一系列的流程。从无到有,建立一个数据科学家或者人工智能团队的确是一件煞费苦心的事情。
|
||||
|
||||
那么今天,我们来聊一聊数据科学家团队管理的下一个重要的步骤,那就是**如何来衡量数据科学家或者人工智能工程师在团队中的业绩,有时候也被称为是绩效评定**(Performance Review)。绩效评定的种种规则必须在团队建立的初期就明确,否则就会出现一些不定因素,对于招聘、培训以及留住人才都有着不可估量的影响。
|
||||
|
||||
## 数据科学家的价值
|
||||
|
||||
如何对数据科学家团队进行绩效评定呢?这个问题的核心其实是要回答,数据科学家或者人工智能工程师究竟应该(以及实际)为你的公司或者组织带来什么核心价值?只有梳理清楚这个核心问题,才能真正建立起衡量数据科学家团队的价值体系,从而达到为公司和组织赋能的目的。
|
||||
|
||||
那么,数据科学家团队或者人工智能工程师团队应该为企业或组织带来什么样的价值呢?
|
||||
|
||||
对于这类相对来说比较抽象的问题,其实很难有一个标准答案。每一个组织或者公司都有自己一套衡量价值的方式。这里我们并不追求一个统一的答案,而是希望能够为这个问题提供一些参考。
|
||||
|
||||
关于这个问题,在我们前面的一些分享中,其实已经提到过,那就是**数据科学团队最重要的一部分价值来自于为企业或者团队引入数据驱动的决策过程**,这是数据科学团队或者人工智能团队的一个核心价值。很多企业或者组织,在没有这些团队之前是无法真正做到数据驱动、持续决策的。
|
||||
|
||||
也就是说,**“数据驱动”和“持续决策”这两点可以看作是数据科学家团队的主要价值体现**。那么,怎么衡量数据科学家团队这个问题,也就变成了如何来衡量这些团队在围绕这两方面的工作中做得怎么样。
|
||||
|
||||
注意,我在这里其实并没有明确提及数据科学团队和人工智能团队对产品直接带来的效果,比如点击率升高了多少,用户存留增加了多少,什么产品又上线了等等。主要是出于以下两点考虑。
|
||||
|
||||
第一,每一个公司、每一个组织甚至是每一个产品在这些价值上都有不一样的需求,没有一个统一的模式。
|
||||
|
||||
第二,如果数据科学团队为组织建立起了数据驱动的持续决策过程,那么很多产品级别的性能提高或者核心功能的实现就会成为顺理成章、水到渠成的结果。相反,如果仅仅强调某一个产品性能的提升或者某一个单点技术的突破,很可能无法真正建立有效的人工智能团队,并且团队的“战斗力”也无法真正得到最大程度的发挥。
|
||||
|
||||
## 数据科学家团队的评价误区
|
||||
|
||||
刚才我们从一个比较大的概念上做了一个讨论,看数据科学家团队的价值应该如何来评价。但在实际操作中,往往存在两种比较明显的误区。
|
||||
|
||||
**第一种误区是“唯技术论”**。那就是觉得人工智能团队能够快速帮助公司、组织甚至是项目很快打开突破口,希望人工智能技术能够给公司业务带来突破性的发展,从而对人工智能团队有过高的预期。
|
||||
|
||||
在这种思路的指导下,在前期往往可能有一个比较大的热情,能够招聘到不少的人才或者能够拉起团队开始一些不错的项目。但很快,由于急功近利的心态和不切合实际的需求,常常又让人工智能团队身陷绝境。而这个时候,最容易产生的一种情绪是走另外一个极端,那就是从“唯技术论”到“技术无用论”。在这样的背景下,产品遇到的任何困难、任何失败都有可能归因到人工智能团队上。
|
||||
|
||||
**第二种误区是对人工智能团队或者数据科学家团队心存怀疑,本质上觉得这些团队都无法真正能够帮助到团队**。因此从一开始就不信任这些团队,蹑手蹑脚,在政策和发展上限制这些团队。由于这种不信任,使得人工智能团队不能真正发挥作用,因此催生了进一步的不信任,恶性循环,最终得出这样的结论,“人工智能是花瓶,没有用”。
|
||||
|
||||
这两种误区的核心其实是一种行为,那就是忽略了**人工智能团队需要一个“生态环境”**。什么生态环境?比如产品部门、数据部门以及其他的工程部门,必须协调发展。
|
||||
|
||||
绝大多数数据科学团队和人工智能团队都需要依赖一个比较强有力的数据部门的支持。同时,产品上,如果人工智能的算法或者模型并不能和产品有机结合,那无论如何,都是无法真正帮助产品,为产品赋能的。我们之前也提过,其实在很多时候,人工智能都是锦上添花的部分,而产品的整体呈现才是最为重要、做需要认真思考的问题。
|
||||
|
||||
## 数据科学家的评定
|
||||
|
||||
有了前面这些思路作为基础,我们现在来看一看数据科学家的评定的问题。
|
||||
|
||||
**第一,对于数据科学家或者人工智能工程师来说,我们需要看他们是否对于建立、完善、和推动“数据驱动的持续决策”这一长期任务有不间断的贡献。**
|
||||
|
||||
具体来说,那就是数据科学家或者工程师是不是在帮助建立和推动数据驱动的链路,是不是在思考如何能够更快、更好地解决数据的问题。这里的数据包括获取数据、整理数据、分析数据以及利用数据的整个流程。我们的数据科学家或者人工智能工程师应该持续在这几个方面有所贡献。
|
||||
|
||||
你可能会有疑问,这不是数据工程师的责任吗?没错,这确实是数据工程师的职责。但是,如果我们的科学家并不清楚数据的情况,并不了解如何进一步推动数据链路的进步,那产品线将来肯定会出问题。
|
||||
|
||||
同理,数据科学家也需要在帮助“持续决策”上不断做出贡献。这里主要指的是实验的平台,以及围绕着实验平台进行决策的工具,比如图表,比如更加复杂的假设检验工具,比如因果推断的工具等等。数据科学家和人工智能工程师必须要具备这样的敏感度。
|
||||
|
||||
**第二,那就是考察数据科学家和人工智能工程师本身的职责和专长,针对某一个产品能否提出切实可行的机器学习解决方案,能否和产品部门以及其他工程部门一起,让解决方案落地。**
|
||||
|
||||
这一点检验的就是解决方案的落地能力。当然,这里不仅仅依赖于解决方案本身,还依赖于其他的因素,比如数据,比如产品。这里面有一部分是第一点的内容,主要是评定数据科学家或者人工智能工程师对于跨部门合作以及共同构建一个人工智能生态系统的能力。这一条的重点是评定在一个较小范围内落地解决方案的能力。
|
||||
|
||||
**第三,那就是数据科学家和人工智能工程师必须能够不断提高自我修养,能够持续学习不断进步。**
|
||||
|
||||
这一点,可能是在所有的工程团队和产品团队里面都比较突出的。虽然所有的团队都需要不断进步,然而人工智能这个领域实在是变化太快。因此,在这个方面,人工智能相关的工作都必须要有比较不一样的评价标准。
|
||||
|
||||
在一些企业中,数据科学家的持续学习主要体现为参加会议、发表论文、参与学术讨论、发表开源软件等形式。如果在一些初创公司或者是暂时没有这些能力的组织中,我们也要思考如何来评价员工是不是在积极地持续学习。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我们分析了组建一个数据科学家或人工智能团队后,你怎样来认识这个团队的价值,怎么来评价员工的工作。
|
||||
|
||||
简单地做个总结:第一,我们讲了数据科学家团队对于推动“数据驱动持续决策”这一目标的作用;第二,我们梳理了面对人工智能团队上可能存在的两个误区;第三,我们简单聊了聊如何在大的方面来评定数据科学家的工作。希望这些内容能给你带来一些启发和借鉴。
|
||||
|
||||
最后,给你留一个思考题,需不需要把人工智能团队的工作和企业的KPI挂钩?如果需要,该怎么挂;如果你觉得不需要,又是什么理由呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
<audio id="audio" title="140 | 人工智能领域知识体系更新周期只有5~6年,数据科学家如何培养?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8f/48/8f20f5f8c55be6354c036e25cac96848.mp3"></audio>
|
||||
|
||||
在上一期的分享里,我们聊了数据科学家团队管理的一个重要步骤,那就是如何来衡量数据科学家或者人工智能工程师在团队中的业绩,我们重点讲了如何看待数据科学家团队的价值和数据科学家评定的一些误区。
|
||||
|
||||
今天,我们来聊另一个数据科学家团队的高级话题,那就是数据科学家的培养的问题。
|
||||
|
||||
## 为什么要培养数据科学家
|
||||
|
||||
为什么要培养数据科学家?这个问题看上似乎是显而易见的,但实际上,如果不了解数据科学家或者人工智能团队的一个重要性质,你很可能无法很好地运营这样一个团队。究竟是什么性质这么重要呢?那就是数据科学家或者人工智能工程师有强烈的持续学习和不断更新自我的需要,这是数据科学家培养的一个非常重要的理念。
|
||||
|
||||
那么,数据科学家为什么需要不断学习?简单来说,是因为数据科学家所需要的技能和知识处在一个快速变化的环境中。如果数据科学家不能对这些快速变化的技能和知识加以学习,就很可能被迅速淘汰。
|
||||
|
||||
我们这里所说的技能有**知识性的技能**也有实际的**工具性质的技能**。
|
||||
|
||||
从知识性的来看,机器学习和人工智能技术每隔一段时间就会有一些重要的发展,了解和掌握这些更新的技术需要一定的门槛。因此,持续学习是为了能够迈过这些门槛。从过去的经验来看,每一次这样的重要发展所带来的新门槛都不可避免地让一些工程师和数据科学家落伍。
|
||||
|
||||
比如,在过去不到20年的时间里,机器学习就经历了“支持向量机”(Support Vector Machine)、“概率图模型”(Probabilistic Graphical Model)以及“深度学习”(Deep Learning)这三股大的思潮。**也就是平均5~6年,数据科学家和人工智能工程师就需要面对一些完全不同的建模思想和工具**。更不要说,在这些大的思潮之下,每年出现的新模型也是层数不穷。这还没有提及应用的领域,比如推荐系统、搜索、广告系统、计算机视觉、自然语言处理等等。如果不能在这些领域知识的快速变化中取得主动,很可能就无法胜任未来的工作。
|
||||
|
||||
在实际工具技能层面则更是日新月异。比如近日如火如荼的深度学习框架TensorFlow仅有3年多的历史,五六年前还根本就不存在。而如今借助机器学习迅速崛起的编程语言Python在五六年前也没有近日的火爆。而在支持向量机年代非常受欢迎的LibSVM和SVMLight工具,可能今天已经很少听到。知识框架的变化相比,工具技能层面的变化更加琐碎,更加细节,这也为人工智能科学家提出了更高的挑战。
|
||||
|
||||
那么,在知识结构和工具技能都快速变化的情况下,团队的负责人就需要针对这样的特点进行有远见的管理安排。
|
||||
|
||||
**第一,需要为学习这些技能和知识提供时间**。任何数据科学家现有的知识体系都不能保证永不过时。事实上,就像我们刚才提到的,现在每5~6年就有一个比较大的知识体系更新,这个更新速度在未来还有可能会更快。那么,花费了非常大的代价招聘来的整个团队就有可能面临着短时间内过时的危机,所以,要能够利用平时的时间,把持续学习的内容安排进团队的日常运作中,可以有效降低团队遭遇知识鸿沟(Gap)的风险。
|
||||
|
||||
**第二,需要团队里的资深数据科学家能够战略性的挖掘接下来有可能进入主流视野的技术,从而早作准备**。尽管这可能显得有一点过于超前,但是对于大多数的互联网或者高科技企业来说,技术实力上的领先无疑是最强大的生产力。因此,在日常的安排中,如果在团队人手富裕的情况下,能够有一些数据科学家专注比较“面向未来”的技术,从而为今后的技术积累以及整个团队的“技术纵深”打下基础。
|
||||
|
||||
其实,谷歌的DeepMind或者Facebook的人工智能研究院都有着这样的性质。这些机构研发的技术未必能够马上应用到这些公司的主流产品上,但是这些技术有可能让这些公司或者团队能够在未来3~5年内有一个比较舒适的纵深,这些公司的其他团队需要做的,就是沿着这个纵深前进。
|
||||
|
||||
除了从一个团队以及数据科学家本身的不断更新换代的这个思路来看待培训以外,还有一个方面,那就是绝大多数公司和团队的数据科学家都不可能是在招聘的时候就已经是最一流的数据科学家或者人工智能工程师了。
|
||||
|
||||
你往往只能招聘到博士毕业生、硕士毕业生。他们的知识面和技能在刚进入公司的时候还非常稚嫩。对于一些博士毕业生而言,以前做的一些研究都是在一个非常窄的领域,还没有形成一个完整的体系。对于一些硕士毕业生而言,很可能完全没有真正接触过现实的问题,之前的学习主要是课堂项目。因此,**对于团队中的年轻成员,学习和培养就成为了一个非常必要的环节,让他们能够真正融入到工业级人工智能解决方案的研究和部署中**。
|
||||
|
||||
## 全方位的培养计划
|
||||
|
||||
刚才我们简单聊了聊从技术层面培养数据科学家的一个思路。其实,我们之前反复强调的一个思想就是,**人工智能团队并不是单独存在的**。一个能够真正运转并且能够为公司或者组织带来价值的人工智能团队一定是整个组织中的一个有机部分,并且能够为公司和组织带来数据驱动的持续决策的能力。因此,在这样的一个目标下,数据科学家的培养不应该仅仅是技术层面上的,还应该是更加**全方位**的。
|
||||
|
||||
如果说简单一点,对于一个数据科学家的全方位培养中,很重要的一条,那就是**团队协作的能力,特别是跨团队的组织、协调和沟通的能力**。我们在之前的分享中已经提到过,数据科学家的工作需要和数据工程、设计师、前端工程师、后端工程师、产品经理等角色的人员打交道。而在这个过程中,任何一个环节的沟通出了问题,都有可能造成项目的失败。因此,**有没有聆听的能力、有没有表达的能力、有没有了解需求的能力、有没有分清主次的能力等等,这些软实力就成为了数据科学家培养计划中的一个重点**。
|
||||
|
||||
从过程上来说,一个新入职的数据科学家的核心目标还是从技术上慢慢从学生或者初级工程师逐渐成熟起来。最开始,年轻的数据科学家应该“多听”、“多看”、“多想”,但“少发表意见”。从和资深的员工一起参与项目开始,逐渐学习怎么和其他的部门一起工作,甚至从熟悉其他部门的词汇、语言入手。
|
||||
|
||||
最后,我想说的是,除了团队之间的沟通能力以外,**数据科学家上台演讲的能力也很重要**。能够把自己的解决方案说清楚,能够用通俗的语言来解释复杂的问题,能够不使用数学符号依然可以把解决方案的主要思想梳理明白并且能够传递出足够多的信息,这些都是数据科学家进阶必不可少的技能。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我们分析了数据科学家或者人工智能工程师团队的培养问题。进行一个简单的总结:第一,我们讲了数据科学家为什么需要培养。在主要的技术技能培养的道路上,有什么样的情况;第二,我们详细梳理了数据科学家全方位培养中的重点是什么。希望这些内容能给你一些启发和借鉴。
|
||||
|
||||
最后,给你留一个思考题,怎么能够把数据科学家的持续学习纳入绩效考核呢?或者到底应不应该纳入考核?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
<audio id="audio" title="141 | 数据科学家团队组织架构:水平还是垂直,这是个问题" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/36/b8/360ad82b303465b1a28b0ee9f646a3b8.mp3"></audio>
|
||||
|
||||
周一我们聊了数据科学家培养的话题,我们分析了数据科学家培养的重要性,要从技术的提高和整体的团队协作几个角度来进行培养。
|
||||
|
||||
今天我们来讨论数据科学家团队高级话题中的最后一个,也是非常现实的一个问题,那就是对于一个组织来说,究竟应该形成怎样的组织架构呢?是选择一个集中式的数据科学家团队或者叫**水平式的组织架构**?还是成立一个分散式的、每个产品部门都有数据科学家的**垂直式的组织架构**呢?对于很多公司或组织来说,在构建一个数据科学家团队的时候都会遇到这个棘手的问题。
|
||||
|
||||
## 水平架构的数据科学家团队
|
||||
|
||||
什么是水平架构的数据科学家团队呢?简单来说,那就是一个公司或者组织的所有数据科学家都在一个团队中,有一个统一架构管理,比如一个数据科学家总监或者一个首席科学家。这个团队负责和公司所有的其他团队合作,提供数据科学以及人工智能解决方案。
|
||||
|
||||
例如大家熟悉的微软研究院、谷歌DeepMind、雅虎研究院、IBM研究院、Facebook人工智能研究院都是水平架构团队的卓越代表。
|
||||
|
||||
水平架构的团队有哪些好处呢?
|
||||
|
||||
**第一,便于管理**。这些团队有统一的招聘标准、业绩评价标准、员工晋升标准和内部的运作模式。这些管理体系的建立是需要时间和经验的。统一的管理常常意味着高效,大家对这些管理上的细节有统一的认识,因此整个团队对内管理上能够更加方便快捷。对于希望快速发展壮大的一些组织来说,这一点尤为重要。
|
||||
|
||||
关于这一点,很多管理者其实并没有完全理解,难免出现因多个相似团队存在而造成一些不必要的内耗。比如说,如果一个组织内部在没有协调的情况下出现了两个人工智能团队,而这两个团队各自有一套招聘方法、人员评定的方法以及项目管理的模式。如果没有足够重视,那很快就会演变为激烈的摩擦,从而无法让团队真正有效地运行。在很多公司的发展中都有这样的例子,因为有多个类似的人工智能团队而无法集中资源。
|
||||
|
||||
**第二,品牌效益**。刚才提到的类似微软研究院、雅虎研究院以及IBM研究院都是卓越的品牌。一个组织一旦形成了品牌,那就可以相对比较容易地收获一些**品牌红利**,比如说招聘的便利。很多年轻的研究员或者硕博毕业生的首选都还是进入知名的机构或者团队。甚至有很多时候,年轻的工程师或者科学家都希望追随某一位在这些组织获得成功的学者或者前辈,于是就考虑加入这些团队。还有一些优势比如**在社区里的话语权效应**,典型的例子就是谷歌的TensorFlow框架,这个框架就是凭借着谷歌以及DeepMind的品牌优势,从而能够在众多深度学习框架中后发制人,迅猛发展。
|
||||
|
||||
**第三,团队对外协作变得更加清晰简单**。这里主要是说和公司其他部门之间的协作会变得更加明了。试想公司现在有一个新的产品部门,希望能够利用人工智能的一些技术来构建自己的产品,那么如果公司内部有三个不同的人工智能团队,有几套差不多的系统框架,对于这个新的产品部门来说,该如何选择合作呢?这势必又会引发我们刚才提到的团队之间恶性竞争的问题。
|
||||
|
||||
## 垂直架构的数据科学家团队
|
||||
|
||||
刚才我们主要分析了水平架构团队的一些优势,中间提到了垂直架构团队的一些问题。那是不是垂直架构的团队就没有任何优势了呢?
|
||||
|
||||
凡事肯定都有正反两面。
|
||||
|
||||
**垂直架构的团队往往是从不同产品线的需求中慢慢演变而来的**。举个例子,在类似Facebook、谷歌、雅虎等公司的内部,搜索、推荐以及广告部门往往由于各自的需求不同,在历史的进程中,都分别组建了自己的具有人工智能性质的团队。这些团队在发展过中,也都形成了一些自己的软件框架以及成熟的算法模型。由于这些产品线细节的复杂性,对于很大的公司来说,这些差异性所带来的麻烦就需要不同的团队来支持。同时,因为有不同的团队来做人工智能的研发,从整个公司的层面来看,公司会更加“坚韧”,也更容易有不同的创新点。
|
||||
|
||||
如果仅有一个集中的水平团队来支持公司所有的产品线,随着公司产品的增多,这个水平团队的任务将会越来越重。并且,这个水平团队将不可避免地开始选择那些这个团队认为更加重要的功能加以支持,这必然就难以满足所有团队的需求,正所谓“众口难调”。这个情况下,也就给了其他团队一定的“借口”开始发展自己的人工智能团队。**这其实也是很多公司里,不同人工智能团队发展的一个轨迹**。在某种程度上,这种情况也是“解放”了这个水平团队所承担的重负,让每个产品团队最终能够有比较完整的自主权来发展。
|
||||
|
||||
**垂直发展模式是大多数公司发展到一定程度所经历的现实阶段,也是超大型公司规避技术风险的一种方式,即不同的团队之间互为“备份”,整个公司的发展存在合适的内部竞争。**
|
||||
|
||||
## 混合组织架构
|
||||
|
||||
其实你可以想到,在水平结构和垂直架构之间,存在着一种混合的模式。这种混合的模式往往是希望能够汲取水平架构和垂直架构两者之间的优点,从而能够更大地发挥效益。
|
||||
|
||||
举例来说,谷歌存在DeepMind这样的水平架构人工智能团队,但同时各个产品组也有不少人工智能研发人员。这样,垂直的架构分布在各个产品组,能够保证产品线的正常运作以及不断推陈出新,又能够保证有DeepMind这样的相对比较独立的机构拥有较高辨识度,形成一个比较完整的实体可以进行更多的创新和尝试,而且也能够有一个清晰的品牌吸引人才。类似的情况还有Facebook的人工智能研究院和其他工程产品线内的人工智能团队的关系。简言之,就是**希望用一个较小的、更加核心、更加精英化的水平团队以及各个产品线中的垂直团队一起相互作用**。
|
||||
|
||||
当然,从管理的层面而言,这样两者都需要的混合模式对公司的领导智慧和协调能力都是极大的考验。事实上,你可以发现,在上述的区分中,产品团队中的人工智能研发人员和这个更加精英的水平架构的人工智能团队之间可能会产生不信任的摩擦。举例来说,理想状态下,这个核心的团队应该做一些更加超前的创新和思考,而产品的团队做一些更加“接地气”的项目。但是,有的时候产品团队中也会有工程师或者科学家的能力其实不错,也能做超前的研究和创新。慢慢地,就会让人觉得这个核心的研发团队的名声和实际在公司内部的影响力“名不副实”。
|
||||
|
||||
在混合模式下,我们现在还不能说业界已经有一个成熟的模型可以供大家参考了。很多在尝试的公司也在水平和垂直的架构中互相摇摆。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我们分析了如果要组建一个数据科学家或者人工智能团队,你需要建立的是水平架构的组织还是垂直架构的组织。
|
||||
|
||||
我们来进行一个简单的总结:第一,我们讲了什么是水平架构的团队组织,这样的组织有什么优势;第二,我们详细梳理了一下垂直架构组织的由来,并且帮助你理解这种组织架构的现实原因和在大型公司中的好处;第三,我们简单谈了谈对混合架构的摸索。希望这些内容能给你一些启发和借鉴。
|
||||
|
||||
最后,给你留一个思考题,对于一个初创公司来说,如果希望建立人工智能团队,应该选取什么样的架构呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
79
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/142 | 数据科学家必备套路之一:搜索套路.md
Normal file
79
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/142 | 数据科学家必备套路之一:搜索套路.md
Normal file
@@ -0,0 +1,79 @@
|
||||
<audio id="audio" title="142 | 数据科学家必备套路之一:搜索套路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/71/84/71b54699ffbf6068205aa49d37b7ec84.mp3"></audio>
|
||||
|
||||
到目前为止,我们已经完整地介绍了搜索、推荐和广告的主流技术,为你呈现了这些产品技术方向的整个生态系统。在这些系列的分享里,我们重点介绍了这些技术方向的基本模型,然后花了不少篇幅讲如何评测模型的好坏,包括如何进行线下评测以及线上评测。同时,我们从传统的经典模型讲到最近几年利用深度学习对这些技术方向的提升,帮助你理顺了这些技术发展的脉络。
|
||||
|
||||
尽管我们已经在之前的文章中分享了这些技术的方方面面,但是对于很多经验较少的数据科学家或者人工智能工程师来说,依然会感到无法得心应手地把这些模型和知识给应用到真实场景中。
|
||||
|
||||
其实,出现这种情况一方面是个人经验积累的原因,毕竟从初学者到能够熟练应用各种模型工具应对实际产品的需要,是一个长时间磨炼的结果;然而另一方面,也是因为搜索、推荐和广告这些产品场景其实是有一些套路,在没有接触到这些套路的时候往往会觉得不得要领,而在慢慢熟悉了这些套路之后,进步也就会慢慢加快。
|
||||
|
||||
那么,在接下来的三篇文章里,我就有针对性地来分享在这三个领域里的一些常见套路。今天,我们首先从搜索产品套路说起。
|
||||
|
||||
## 多轮打分套路
|
||||
|
||||
我们前面已经介绍过多轮打分的系统架构了。**当我们想要构建任何一个搜索引擎时,都应该立刻想到多轮打分这个架构**,这是一个基本套路。
|
||||
|
||||
我们先来回顾一下多轮打分最基本的模式:针对一个搜索关键词,我们首先从索引中找到第一批,也是数目相对比较多的相关文档,这就是第一轮打分;然后,我们再根据一个相对比较复杂的模型,对剩余的文档进行打分排序,这是第二轮打分。
|
||||
|
||||
很多时候,两轮打分就已经能够满足需求了,可以直接给用户返回结果集。当然了,我们也常常加入第三轮打分,这个时候经常是实现一个商业逻辑层,可以针对最后的搜索结构加上一些商业规则。
|
||||
|
||||
多轮打分这个套路之所以关键,是因为它其实影响了一系列的技术决定。
|
||||
|
||||
首先,只有第一轮是直接作用在索引上的。这一轮往往可以并行化,并且不需要太多考虑文档之间的顺序。
|
||||
|
||||
我来举个例子说明。在一个大型搜索引擎的架构下,假设我们有一亿个文档,每五百万个文档存放在一个数据节点上。如果我们有一个关键词是“人工智能”,那么就要到这20个数据节点上分别查找包含这个关键词的文档。当我们把所有的文档汇集起来以后,排序取出前1000个文档,这个时候就进入第二轮。最简单的第二轮打分是在一个计算节点上进行的,而且这个时候我们只针对1000个文档进行打分,对计算时间的要求就大幅度降低了。那么,在这样的情况下,第二轮打分使用的模型可以是比较复杂的模型。后面每一轮打分所针对的文档往往是越来越少,因此模型的复杂度可以越来越高。
|
||||
|
||||
从解决问题的角度上来说,**第一轮在索引上的打分,是要解决“召回”(Recall)的问题**。这一步有可能是从非常多甚至是成千上万的文档中返回几百到几千不等的文档,因此一旦一些文档没有在这一轮中被返回,就无法在后面的轮数中被重新筛选出来。所以,我们要理清这么一个思路,那就是如果你认定系统有“召回”的问题,也就是说,本该搜出来的东西,完全搜索不出来,那肯定是在第一轮打分就出了问题。**第二轮以后的打分解决的就是“精度”(Precision)的问题**。
|
||||
|
||||
同时,我们可以看到,什么时候解决“召回”问题,什么时候解决“精度”问题,这其实是**取决于具体的业务场景**。
|
||||
|
||||
对于“精度”非常看重的搜索场景,比如说网页的信息类关键词,例如“特朗普”、“比尔盖茨”,人们往往只关注前10位,甚至是前3位的搜索结果。那么很明显,我们可以先有一个比较简单的第一轮架构,比如就是文字匹配,而把功夫都下在第二轮以后的打分上。
|
||||
|
||||
而对于“召回”比较看重场景,比如说法律文档搜索,那必须要做好的就是第一轮的打分,这个时候可能需要采用简单的文字直接匹配和语义的模糊匹配。
|
||||
|
||||
## 高频和长尾的套路
|
||||
|
||||
刚开始接触搜索产品的朋友往往会有一个困惑,那就是不知道该如何提升一个搜索产品,有一种无从下手的感觉。那么,对于搜索产品的提高有没有什么套路可言呢?
|
||||
|
||||
一个比较基本的套路,就是**把搜索关键词按照某种频率或者是流量分为“高频关键词”和“长尾关键词”**,从而为这两类不同的关键词设计排序算法。
|
||||
|
||||
为什么要把关键词按照频率分开呢?我来介绍一下最主要的思路。
|
||||
|
||||
对于很多搜索网站来说,一些高频的关键词往往占据了相对来说比较大的流量,而很多长尾的关键词,也就是仅仅出现过几次的关键词则并没有太多人搜。因此,如果我们先解决了高频的关键词,也就解决了大部分的搜索问题,从而可以把精力留下来慢慢解决低频的长尾关键词。
|
||||
|
||||
而实际上,高频关键词因为有足够多的数据量,反而往往比较容易得以解决,而低频关键词,因为数据的匮乏,往往需要更多的精力和时间。所以说,从投资回报的角度来看,我们也需要做区分,首先来解决高频的搜索关键词。
|
||||
|
||||
刚才我们提到了高频关键词的一个特点,就是有足够多的用户数据。那么,这里有一种非常简单的思路,或者说是在没有较好模型的时候可以首先使用的一种方法,那就是**每天记录下高频关键词文档的用户点击数据**。然后我们可以直接按照**点击率**,或者是文档的**转换率**排序,并且把这个排序存在某种存储中。当用户在这一天搜索这些高频关键词的时候,我们甚至可以直接从存储中调出事先算好的排序结果。
|
||||
|
||||
更加极端的做法,就是**手工对高频词进行更频繁的标注**,这种做法往往也是非常有效的。例如我们刚才说的“特朗普”的例子,我们可以手工标注好前10名的结果,然后存下来。只需要每几天更新一下这个标注,我们甚至不需要使用任何模型就可以提供非常高质量的搜索结果。
|
||||
|
||||
当然,使用这种方法,显然无法对几百万的搜索关键词都这么一一处理。不过,我们这里针对的主要是高频关键词,所以,即便是针对最高频的1千个关键词进行手工标注,也会对整体的搜索效果有非常明显的提升。
|
||||
|
||||
相反,长尾的关键词往往需要花比较多的心思。对于长尾来说,我们还可以细分。比如对于有一定数据量的关键词,我们可以尝试**针对这些关键词单独训练一个模型**。之所以要单独训练一个模型,原因也很简单,如果针对所有的关键词只有一个模型的话,高频的关键词因为流量大,往往就会让模型偏重于去解释高频的信息,而忽略了这些中低频的关键词的作用。
|
||||
|
||||
因此,先把**高频词**单独处理了,然后就可以针对依然可以训练的**中频关键词**再选取一个单独的模型。而针对非常**低频的关键词**,我们往往需要借助其他的方法来挖掘这些关键词的信息,例如利用同类的其他关键词的数据,或者利用外界的知识库、知识图谱的信息等。
|
||||
|
||||
## 三大模型套路
|
||||
|
||||
除了分开处理高频和长尾关键词以外,搜索模型的提升还有一个非常简单的“三大模型套路”。
|
||||
|
||||
我们构建一个搜索引擎,从最原始的简单系统,慢慢到比较复杂的以至于到后期非常复杂的系统,从模型上来说要跨越三个台阶。在这里我们主要是针对第二轮的打分系统来进行讨论。
|
||||
|
||||
**第一个台阶是使用线性模型**。当我们设置好了最基本的第一轮打分系统以后,首先要做好的是能够利用线性模型对文档进行排序。这一步其实往往是**搜索系统从“无人工智能”到“有人工智能”的第一步**。这一步对搜索效果性能的提升可能会有10%~20%。
|
||||
|
||||
**第二个台阶是使用配对法线性模型**。一般来说,这一步搜索效果会有2%~5%的提升。
|
||||
|
||||
**第三个台阶是使用树模型,特别是GBDT模型**。这一步搜效果的提升和第二步相似,约有2%~5%的提升。然而,要从第二个台阶到达这个步骤,模型的特性可能会发生不小的变化。这一个台阶可以算是一个比较困难的台阶。
|
||||
|
||||
**从工程研发的角度来说,可以采用一年一个台阶的做法**。在已经穷尽了当前台阶所有可能用到的特性以后,再进入到下一个台阶,也就是说要尽可能地“榨干”当前台阶模型效果的“养分”。
|
||||
|
||||
## 总结
|
||||
|
||||
今天我为你介绍了做搜索产品的几个套路。
|
||||
|
||||
一起来回顾下要点:第一,我们回顾和总结了多轮打分系统的架构套路;第二,我们介绍了区分高频关键词和长尾关键词的套路;第三,我们简单讨论了“三大模型套路”,跨越三个台阶,逐步提升搜索效果。
|
||||
|
||||
最后,给你留一个思考题,为什么不鼓励直接采用深度学习模型呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
71
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/143 | 数据科学家必备套路之二:推荐套路.md
Normal file
71
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/143 | 数据科学家必备套路之二:推荐套路.md
Normal file
@@ -0,0 +1,71 @@
|
||||
<audio id="audio" title="143 | 数据科学家必备套路之二:推荐套路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5d/6b/5dd80a287da06774b3b260b5e804476b.mp3"></audio>
|
||||
|
||||
在上一期的分享里我们讨论了做搜索产品的套路,给你介绍了多轮打分、高频和长尾以及三大模型套路。你有没有感受到这些高于某一个具体模型的套路的重要性呢?
|
||||
|
||||
今天,我们来看看推荐的一些套路。
|
||||
|
||||
## 多轮打分套路
|
||||
|
||||
上一篇我们提到,想要构建一个搜索引擎,应该立刻想到基于多轮打分的架构,有这个意识就是一个基本套路。
|
||||
|
||||
其实这个套路对于推荐,也是适用的。
|
||||
|
||||
**把推荐问题构建成一个多轮打分的“类搜索”问题**,其实是推荐在工业界应用的一个非常重要的套路。
|
||||
|
||||
这个思路的好处是把搜索和推荐问题给归一化了。也就是说,我们可以依靠同样一套软件架构来解决两大类相似的问题。**搜索是有关键词的推荐,而推荐则是无关键词的搜索**。虽然这是一种相对比较简化的看待这两种问题的方式,但是统一的架构在工程上面可以带来非常多的好处,比如重复构建相似的特征工程的流水线,以及更重要的如何优化索引等工程,这些都可以很快地应用在搜索和推荐这两个重要的场景上。
|
||||
|
||||
当然,在工程以外还有其他好处。在学术界,关于推荐系统搭建的方法往往是一种独立的模型,然后搜索系统又是另外一种独立的模型。这些模型之间缺乏能够系统性联系起来的纽带。**把推荐问题看成是多轮打分的搜索问题**之后,我们就找到了一种简单又自然的方法,能够把很多不同类型的推荐模型给整合到一起。
|
||||
|
||||
比如,很多之前我们介绍过的推荐模型就可以担任第一轮打分,也就是我们常说的“**候选集选择**”(Candidate Selection)这一组件的角色。像协同过滤模型,就可以是我们为每一个用户或者每一个物品产生最终推荐物品的一个候选集合。
|
||||
|
||||
在搜索里,我们是利用索引以及简单的检索方法,从海量的文档中找到几百或者几千个初步相关的文档,然后再根据第二轮的复杂模型来重排序。那么在推荐里,我们其实就可以利用各种不同的协同过滤、矩阵分解等模型来达到第一步的筛选功能。
|
||||
|
||||
而对于第二轮打分,我们就完全可以依赖基于特性的排序学习模型来学习推荐的结果。这种方式其实是极大地利用各种搜索算法,特别是排序学习的进步,来提升推荐的效果。
|
||||
|
||||
是否把推荐问题看成是多轮打分的搜索问题,是区别工业界和学术界推荐模型的一个重要标志。
|
||||
|
||||
## 高频用户和低频用户套路
|
||||
|
||||
既然我们提到了把推荐问题看成是某种意义上的搜索问题,那么,根据用户行为的频率来进行不同的推荐策略,其实就是一个顺理成章的套路了。
|
||||
|
||||
这个套路的思路和搜索类似。对于高频用户而言,我们有足够多的数据,所以往往可以学习到一个比较好的模型。而且,对于真正的高频用户来说,提高推荐的质量往往需要个性化,也就是说,我们需要更多地利用这些高频用户他们自己的数据,来提供推荐结果。
|
||||
|
||||
一般来说,针对高频用户的个性化推荐有两种比较常见的方法。
|
||||
|
||||
一种方法就是**构造更多的高频用户的特性**。比如,有一个用户点击了某一个物品的信息,或者这个用户购买了某一个物品,这些特性都有助于我们的模型学习到关于这个用户的具体喜好。
|
||||
|
||||
另外一种比较常见的方法是**为这些高频用户单独构建模型**。这个方法其实主要是针对第二轮打分的模型而言的。一般来说,一个比较简单直观的方法是把所有用户的数据收集起来,然后训练一个全局的第二轮打分模型。这样做的好处当然是可以利用所有的数据,并且学习出来的模型往往也比较稳定。但是,一个全局的模型往往并不能为某一个用户提供最优的推荐结果,这一点其实很容易理解,因为一个全局的模型往往是某种“平均结果”。所以,我们可以根据用户的数据来为这些高频用户“定制模型”。
|
||||
|
||||
说了针对高频用户的一些思路以后,我们来看看针对低频用户的一些套路。
|
||||
|
||||
当我们需要为低频用户进行推荐的时候,因为数据缺乏的关系,这时候的选择就不太多了。一个普遍使用的方法,是**对低频用户进行分组**。这种分组一般来说是根据用户的人口信息,例如年龄、性别和地理位置。分组之后,我们把这些组别中的用户信息整合起来,统一建立这些组别的模型。
|
||||
|
||||
还有一个比较普遍方法,是**给低频用户推荐流行的信息**。这里的假设是,流行信息之所以是流行的,就是因为这些信息本身可能就有较高的点击率、驻留时间和购买率,因此在不清楚这些低频用户喜好的情况下,推荐这些内容其实是相对比较合理、也是保险的。
|
||||
|
||||
## 批量和实时套路
|
||||
|
||||
这个“批量和实时”套路其实和多轮打分以及高频、低频用户都有一些关联,但是有时说的是不太一样的事情。
|
||||
|
||||
在设计推荐系统架构的时候,我们刚才讲了多轮打分的思路,那是不是每一个用户到我们的网站或者服务时,系统都需要从第一轮开始一直到最后一轮,完全重新生成一个用户的所有推荐结果?
|
||||
|
||||
其实,我们可以这么想一想,如果一些用户,特别是低频用户,每周仅仅光顾几次我们的网站或服务,甚至每个月才光顾一次,我们并不需要针对这些用户来实时更新推荐结果,而可以按照一定的频率,例如每天一次或者每周一次提前生成好所有这些用户的推荐结果,然后存储到某一个地方。等用户访问网站时,我们就可以直接从存储中调出已经生成好的推荐结果。
|
||||
|
||||
其实这个思路不仅仅用于低频用户,高频用户也可以采用这样的方式。不过,更新推荐结果的频率可能就不是每天或者每周,而应该是每几个小时、每几十分钟甚至是更短的时间。
|
||||
|
||||
对于很多应用来说,推荐的结果其实并不需要是实时的。即便是在很多看似需要实时的应用上,我们依然**可以用很多的批量计算来达到推荐的目的**。
|
||||
|
||||
举个例子,在很多移动场景中,我们可以为一个用户生成一个基本的推荐结果,一两百个物品,然后从服务器端推送到用户的手机上。当用户在手机上产生了新的行为之后,我们可以根据这些行为对用户已经在手机上的这个集合进行模型的微调,然后重新排序。这里用户看到的可能是感觉上已经有更新的推荐结果,但**这种实时的效果其实是建立在批量预处理上的**。
|
||||
|
||||
**能够理解什么时候需要利用批量的计算结果,什么时候需要实时的计算结果,是处理好推荐问题的一个关键套路。**
|
||||
|
||||
## 总结
|
||||
|
||||
今天我为你介绍了做推荐产品的几个套路。
|
||||
|
||||
一起来回顾下要点:第一,把推荐问题看成一个多轮打分的“类搜索”问题,是推荐在工业界应用的一个重要套路;第二,对高频用户进行个性化推荐有两种常用的思路,包括构造更多的特性和定制建模;针对低频用户的推荐套路也有两个,一个是分组一个是推荐流行的信息;第三,我们聊了批量处理和实时处理的套路,关键是判断在什么场景下使用哪种套路。
|
||||
|
||||
最后,给你留一个思考题,从多轮打分系统的架构看,推荐和搜索又有哪些区别需要注意呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/144 | 数据科学家必备套路之三:广告套路.md
Normal file
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/144 | 数据科学家必备套路之三:广告套路.md
Normal file
@@ -0,0 +1,67 @@
|
||||
<audio id="audio" title="144 | 数据科学家必备套路之三:广告套路" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6d/4b/6d10fedebc07c11887610c8b8750c04b.mp3"></audio>
|
||||
|
||||
讲完了搜索产品和推荐系统的套路,今天我们继续来看数据科学家应该掌握的广告产品的一些套路。
|
||||
|
||||
## 利用搜索和推荐的套路
|
||||
|
||||
前面我们讲过两种普遍使用的互联网广告模式,搜索广告和展示广告。对于搜索广告而言,一个基本套路就是尽量利用现有的搜索系统来推送广告。而对于展示广告而言,一个基本套路就是尽量利用现有的推荐系统来推送广告。
|
||||
|
||||
我们在介绍推荐套路时提过,推荐系统和搜索系统的很多方面其实都有重叠,所以做好一套搜索系统是非常有必要的,几乎所有的广告应用其实最终也可以在搜索系统的架构上搭建。因此,我们可以说,**搜索系统是很多现代人工智能系统应用的一个核心技术组件**。
|
||||
|
||||
具体来说,广告其实也和一般的文档一样,首先利用搜索引擎的索引把这些广告都存储起来。对于搜索广告来说,利用关键词的倒排索引,可以轻松地找到相关的广告,这和找到相关文档的原理其实是一样的。
|
||||
|
||||
当然,我们前面也提到过,广告的排序和普通文档有一个不一样的地方,那就是竞价。因此,在从索引中提取广告的时候,我们必须要去思考一个问题,如何让广告竞价的赢家能够从索引中被提取出来?
|
||||
|
||||
我们知道,广告的竞价常常是以点击率和出价的乘积来作为排序的依据。这就会有一个问题,如果我们从索引中提取广告的时候,仅仅看哪些广告从关键词的角度是相关的,而忽略了点击率和出价,那么,最后提取出来的广告很有可能不是真正能够赢得竞价的广告。
|
||||
|
||||
如何来对这个问题进行修正呢?一种做法是在索引里面增加点击率信息。也就是针对每一个关键词,我们不是按照文本的相关度去索引最相关的文档,而是按照点击率去索引点击率最高的一系列文档。
|
||||
|
||||
那么,当需要针对某一个关键词提取广告的时候,我们就直接从这个关键词所对应的索引中提取点击率最高的几个广告。这个时候,我们再从某一个存储出价的数据库中读取这些广告的出价,并且进行竞价排序。
|
||||
|
||||
从这个流程我们可以看出,最终的竞价排名很可能并不是完全依赖点击率和出价的乘积,而是在点击率先有了一定的保证下的这个乘积的排序。这种有保障的点击率常常被叫做“**质量值**”(Quality Score),用来描述这些广告的点击率高于一个设定的阈值。
|
||||
|
||||
接下来,我们来看广告提取的另外一个重要的要求,就是需要满足广告投放的业务逻辑。比如,有一个广告的投放要求是针对男性,现在有一个女性用户,那么,我们就不应该针对这个用户显示这个广告,而不管这个广告的点击率和出价信息是怎样的。
|
||||
|
||||
如何实现这样的效果呢?我们依然可以利用索引。在索引中,我们插入广告的各种投放条件作为被索引的对象,然后把在这个投放条件下的各种广告作为文本。这样,我们就可以提取满足任意投放条件的广告了。
|
||||
|
||||
针对这些投放条件的组合,例如投放条件是“女性、在北京”,我们可以认为是**在索引上进行“且”操作**,也就是提取出同时满足两个关键词的操作。事实上,针对任意一个关键词的广告,我们都是进行了多个“且”操作。例如,针对“可乐”这个关键词,我们可能是需要提取这个关键词点击率最高的100个广告(如果有那么多的话),并且这些广告的投放条件都满足“女性、在北京”。当提取出了这些广告之后再进行竞价排名。
|
||||
|
||||
当然,在这样的架构下,我们就需要**对索引有快速更新的能力**,例如某一个广告的点击率或者投放条件都有可能发生变化。
|
||||
|
||||
## 层次建模套路
|
||||
|
||||
对于广告系统的建模有一个基本的套路,那就是**层次建模**(Hierarchical Modeling)。什么是层次建模呢?在广告的生态系统中,至少有广告商、广告推广计划、单一广告这三个层次的实体。提高广告投放精准度的一个核心问题,就是如何能够对这这三种实体进行有效建模。
|
||||
|
||||
当我们对当前的广告商一无所知的时候,需要看一看过去有没有其他类似的广告商在平台投放过广告,如果有,那么能否借鉴那些过去的数据。当这个广告商开始投放广告以后,我们就可以积累数据,慢慢就能够增强对这个广告商的建模能力。
|
||||
|
||||
类似的,当我们计划推出某一个广告推广计划的时候,我们先看一看同一个广告商有没有类似的推广计划,或者看一看其他类似的广告商有没有相近的推广计划。当某一个广告开始运行的时候,我们看一看同一个推广计划下其他广告的表现,或者是同一个广告商下其他广告的表现。
|
||||
|
||||
**层次建模的一个重要的特点就是利用可以利用的一切其他信息来进行建模**。在计算广告中,经过验证,层级信息往往是最有用的特性。
|
||||
|
||||
## 具体和泛化的套路
|
||||
|
||||
这个套路其实并不是完全针对广告的。就像我们之前所说的广告、搜索和推荐之间的关系,这个套路其实也可以应用在搜索中。
|
||||
|
||||
前几年,Google的工程师发现,如果仅仅利用深度学习模型来学习抽象的特性,从而寄希望模型的性能得以提升,这种方法也许可以很好地解决计算机视觉的一些问题,但是对于搜索、广告和推荐的效果则并不好。
|
||||
|
||||
下面我们聊聊工程师们发现的这里面的原因[1]。
|
||||
|
||||
一个好的模型必须具备两种能力。第一,能够**对具体的关键词进行匹配**。比如,我需要匹配“可口可乐”,那么任何与“百事可乐”相关的广告其实都是不能显示的。这就要求模型中针对每一个具体的关键词能够进行**字对字的匹配**,而不是模糊匹配。第二,那就是**具有泛化能力**。比如,我们要去对“可口可乐”在2018年的广告推广进行建模,模型就能够借鉴“可口可乐”在2017年的推广数据,以及借鉴“可口可乐”公司其他推广的数据。这里面的借鉴能力其实就是模型的泛化能力。
|
||||
|
||||
由此,我们可以得到一个好模型的重要套路:**一个好的模型既要能够精确记忆某一种关键词,又要能够在广告层次上进行泛化**。
|
||||
|
||||
## 总结
|
||||
|
||||
今天我为你介绍了做广告产品的几个套路。
|
||||
|
||||
一起来回顾下要点:第一,搜索系统是很多现代人工智能系统应用的一个核心技术组件,广告系统也可以借鉴搜索系统的套路;第二,广告生态中层次建模的套路,就是利用可以利用的一切其他信息来进行建模;第三,一个好模型的套路,关键是模型的具体能力和泛化能力并存。
|
||||
|
||||
最后,给你留一个思考题,为什么在计算机视觉中,对于具体匹配的要求没有那么高呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
**参考文献**
|
||||
|
||||
1. Heng-Tze Cheng, Levent Koc, Jeremiah Harmsen, Tal Shaked, Tushar Chandra, Hrishi Aradhye, Glen Anderson, Greg Corrado, Wei Chai, Mustafa Ispir, Rohan Anil, Zakaria Haque, Lichan Hong, Vihan Jain, Xiaobing Liu, and Hemal Shah. **Wide & Deep Learning for Recommender Systems**. Proceedings of the 1st Workshop on Deep Learning for Recommender Systems (DLRS 2016). ACM, New York, NY, USA, 7-10, 2016.
|
||||
|
||||
|
||||
57
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/145 | 如何做好人工智能项目的管理?.md
Normal file
57
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/145 | 如何做好人工智能项目的管理?.md
Normal file
@@ -0,0 +1,57 @@
|
||||
<audio id="audio" title="145 | 如何做好人工智能项目的管理?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a0/83/a06e8f0f932235b620a4f6120582f983.mp3"></audio>
|
||||
|
||||
关于数据科学团队养成这个主题,在之前的分享中,我们已经聊了数据科学团队招聘以及一些高级话题,主要是围绕如何组建一个高效的团队,包括数据科学家的绩效评定、培养以及如何构建水平和垂直的组织架构这些内容。
|
||||
|
||||
在接下来的几篇分享里,我们重新回到数据科学团队的本源,来看一看数据科学团队在整个公司的位置,以及在数据科学团队的发展和运行中,又有哪些至关重要的环节。
|
||||
|
||||
今天我们就来聊一聊运行数据科学团队里面的一个核心问题,就是如何针对人工智能项目进行管理,从而保证团队运行的项目能够顺利完成,同时能够真正帮助企业利用人工智能技术来推动产品的发展。
|
||||
|
||||
一说到项目管理,很多成熟的工程师或者项目经理可能会不以为然,觉得不需要对人工智能项目进行额外的关注。但是在实际工作中,如何运作数据科学项目关系到整个产品的推进,甚至可能对公司的发展都会有不小的影响。
|
||||
|
||||
那么,通常情况下,针对人工智能项目会有哪些项目管理的模式呢?我们先来看看两种极端模式。
|
||||
|
||||
## 把人工智能项目当作“研究项目”
|
||||
|
||||
第一种模式是把人工智能项目完全当作是研究项目。很多从学术界转到工业界的研究人员和工程师,在处理人工智能项目时就很容易陷入这种状态。那么研究项目有哪些特点,或者说,如果我们把人工智能项目完全当作是研究项目,会带来什么问题呢?
|
||||
|
||||
首先,在很多状态下,**研究项目并没有特别明确的目标**。有些项目看似是利用一个现成的方法来解决一个实际问题,但是做了一阵子才发现问题的定义并不清晰,而那个现成的方法可能需要重新修改,才能在新的问题上使用。而且,修改这个方法也许还需要进行一些理论推导,即便做了所有这些步骤以后,依然没有人可以保证这个方法对新的问题一定有效。
|
||||
|
||||
也就是说,研究项目的每一个步骤都充满了不确定性。**这种过程和结果的不确定性,可以说是研究项目最大的特点**。不确定的特点带来的结果,往往就是不太好控制整个研究项目的范围。
|
||||
|
||||
举一个例子,如果我们要针对一组图像构建一个分类器。这个项目其实可大可小,可快可慢。如果我们直接用现成的模型,然后利用迁移学习的办法,不去重新训练模型,仅仅是把模型直接应用到新数据上,那快则一天,慢则一个星期,可能就完成了这个任务。
|
||||
|
||||
然而,这么做对分类精度是没有任何保证的。我们可能会发现分类器的精度比我们想象的要低得多。那么,这个时候就会达到一个比较危险的时刻。原始项目范围内需要做的任务都已经完成了,但是没有达到效果,后面可以做的事情,范围可能就会非常大,也没人能说得清楚,做了这些额外的任务之后,是不是一定能提高分类器的精度。
|
||||
|
||||
因此,把人工智能项目完全看作研究项目的弊端就很明显了,我们无法很好地把握整个项目的周期,特别是完成时间。同时,种种的不确定还可能造成项目范围的不可控。显然,这种局面是工程项目中最不愿意看到的。
|
||||
|
||||
## 把人工智能项目当作“软件工程项目”
|
||||
|
||||
另外一个人工智能项目管理的极端模式,就是完全按照软件工程的模式来进行管理。我们这里不讨论具体的软件工程管理方法,我们仅从宏观上来讨论软件工程管理模式对于人工智能项目管理的弊端。
|
||||
|
||||
软件工程管理的一个核心思想,就是能够**把一个大的任务拆分成一些细节的任务,然后假设如果能够完成小的细节任务,那么大的项目也就能顺利完成**。同时,软件工程管理还有一个重要的假设,那就是**工程的绝大多数步骤都是确定的,没有过多的变数**。
|
||||
|
||||
遗憾的是,正如我们刚才提到的,人工智能项目的一个特征,就是不确定性。因此,**按照软件工程进行管理,就容易做一些看似有意义,但其实对工程进展并没有真正帮助的任务**。这些任务往往是数据科学家或者工程师凭空制造出的,目的就是为了符合软件工程的管理流程。过于细节的任务划分,往往就会把整个项目真正的目标给迷失掉,从而无法针对是否达到目标很好地进行控制。
|
||||
|
||||
回到上面那个图像分类器项目的例子,如果我们采用纯粹的软件工程管理方式,那步骤很可能是这样的:需要先写一个计划书,再对数据进行描述,然后找责任相关方来探讨是否需要重新训练模型等等。这些步骤耗费了大量时间,但是对于能否构造出高精度的分类器并没有帮助。
|
||||
|
||||
## 人工智能项目的管理
|
||||
|
||||
那到底该如何来管理人工智能项目呢?人工智能还处于发展的初期,目前其实并没有一个完全成型的项目管理方法论和一个放之四海而皆准的框架。不过,通过刚才对两种极端情况的讨论,相信我们可以在真实的项目管理过程中想出一些办法。
|
||||
|
||||
**首先,我们需要有一个迭代的思路**。迭代思路是为了能够有效地**管理项目的范围**。还是回到我们所说的图像分类器项目,如果我们利用迭代的思路来进行项目管理,就不会把一个绝对的模型精度当作是项目的唯一目标,而把提高精度当作目标,但事先不会针对精度有过分苛责的追求,那么每一天每一周需要做的工作就相对比较容易可控。
|
||||
|
||||
**其次,我们需要分清楚项目中哪些部分是相对可控的,而哪些部分是比较不容易控制的**。当一个模型被训练出来后,要把这个训练流程形成一个**每天可以更新的工作流**(Workflow),这个任务是相对比较可控的。可控的部分我们就可以利用软件工程的项目管理方法了,来对这些任务进行细分。那不可控的任务呢?比如希望提高当前模型的精度,或者是数据量大了十倍以上,依然希望能够进行操作等等。针对这些任务都没有直接的答案,寻找解决方法的过程充满了不确定性,那就无法真正利用软件工程的项目手段了。
|
||||
|
||||
**最后,是人工智能工程项目管理的一个“小窍门”,那就是设置完整的“交工日期”**(Deadline)。不同的交工日期往往意味着完全不同的解决方案,甚至这些解决方案之间会有非常大的精度区别。我们的交工日期要建立在迭代思想上,这样就能保证我们的项目在每一个交工日期都有一个成型的结果。如果模型的精度还有提升的空间,我们就可以依赖下一次迭代去完成精度的提高。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了数据科学团队的一个核心问题,那就是如何针对人工智能项目进行管理。
|
||||
|
||||
一起来回顾下要点:第一,我简单介绍了什么是人工智能项目管理;第二,我们分析了两种极端的项目管理模式以及各自的弊端;第三,我们讨论了如何利用两种极端模式来寻求中间路线的办法。
|
||||
|
||||
最后,给你留一个思考题,你自己的经验里,人工智能项目在运行过程中,哪些步骤或者说是流程是最消耗时间的?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/146 | 数据科学团队必备的工程流程三部曲.md
Normal file
67
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/146 | 数据科学团队必备的工程流程三部曲.md
Normal file
@@ -0,0 +1,67 @@
|
||||
<audio id="audio" title="146 | 数据科学团队必备的工程流程三部曲" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/66/44/66d2bfaeae67635217a54b00e73edb44.mp3"></audio>
|
||||
|
||||
今天,我们继续来聊一聊数据科学团队的一些基础构建思路,讨论一些日常的在“工程流程”方面所需要注意的问题。和我们上一次分享的项目管理不一样,工程流程没有很多可以直接借鉴的经验,需要从业人员进行更多的思考和创新。
|
||||
|
||||
## 什么是工程流程
|
||||
|
||||
我们首先来看一看什么是“工程流程”。一般来说,工程流程指的是我们有什么制度或者说是策略来保障所做的项目能够达到一定的质量标准。
|
||||
|
||||
那工程流程和项目管理流程有什么区别呢?我们说,项目管理流程是从宏观上把握项目的进展,而工程流程则主要是**在微观上**,定义和掌控具体的每一个步骤上的输入、输出和过程。从另外一个角度来说,这两者之间并不存在一个必然的关联关系,一个项目在细节的工程流程上成功与否和一个项目自身的最终成功与否,并不能完全划等号。
|
||||
|
||||
你是不是有疑问,既然如此,那我们为什么还要关注工程流程呢?原因是虽然一个好的工程流程并不一定带来项目的成功,但是可以增加成功的可能性或者说是概率。同时,一个好的工程流程可以帮助一个团队在日常的运作中减少问题的发生,从而能够达到事半功倍的效果。
|
||||
|
||||
那么,工程流程究竟包含哪些方面呢?
|
||||
|
||||
我们在今天的分享里讲三个方面。第一,代码管理的流程;第二,开发部署环境的流程;第三,数据管理的流程。这三个流程可以说是涵盖了一个人工智能项目发展和成功所必不可少的三个重要方面。
|
||||
|
||||
## 代码管理流程
|
||||
|
||||
人工智能项目一个很重要的环节就是开发代码。然而,因为数据科学、人工智能项目的一些特殊性,从业人员对于代码的管理普遍存在不够重视的情况。
|
||||
|
||||
我们在上一期的分享里提到过,数据科学和人工智能的很多项目,往往会被当作学术界的研究项目来进行开发。如果是研究项目,代码开发有哪些特点呢?我简单归纳了两大特点。第一,代码的主要目的是完成学术文章发表所需要的实验结果;第二,在绝大多数情况下,代码很容易变成无人维护和不能继续更新的情况。如果是当作研究项目来开发,那研究人员很可能并不在意代码的可读性、可维护性以及可扩展性等软件工程非常重视的方面,那么这样开发出来的代码就无法真正扩展为一个大型项目的代码库。
|
||||
|
||||
那么,对于一个人工智能项目的代码管理,我们需要去关注哪些因素呢?
|
||||
|
||||
第一,**所有的代码一定要保存在代码版本管理工具中**(而不是某一个数据科学家或者工程师自己的电脑上),这也是一个先决条件。在当今的软件开发的工具中,Git(或者是企业级的GitHub)已经成为了一个标准的工具,用于代码版本管理、追踪和分享。任何项目以及任何人只要开始进行开发,都需要把所有的代码,包括核心的文档存放在代码版本管理工具中。这保证了代码能够被追踪并得到及时的备份。
|
||||
|
||||
第二,**如果我们利用Git或者类似的代码版本管理工具,代码的开发一定要尽量遵循这个版本管理工具所提倡的某种流程**。比如,我们有两个工程师在同一个项目中一起工作,在这样的情况下,大部分的代码版本管理工具都可以允许这两个工程师在不同的“分支”(Branch)进行开发。这两个分支和项目当前的“主分支”(Master)又不同,因此,项目目前代码的运行不会受到这两个分支的影响,而这两个分支之间也不会互相影响。尽管进行分支开发已经算是软件开发的一个标准流程了,但是在人工智能项目中,依然有很多开发人员不遵循这个方法来进行代码不同开发进度之间的隔离。
|
||||
|
||||
## 开发部署环境流程
|
||||
|
||||
了解了代码版本管理的重要性之后,我们来看一看开发环境流程的控制。
|
||||
|
||||
从代码到可以被运行和部署的软件包,成为一个大型互联网产品或者人工智能产品中的一个组成部分,往往还有很多路要走。
|
||||
|
||||
首先,开发部署环境中一个重要的组成就是**流畅的从代码到部署软件包的“直通流程”**。目前在软件开发领域,有诸如“持续集成”(CI,Continuous Integration)和“持续交付”(CD,Continuous Delivery)这样的方法,来帮助工程师能够相对方便地对代码进行包装和部署。我们在这里并不去展开讨论CI/CD的内涵,但是要意识到,对于人工智能项目,我们也需要有能够流畅部署的思想。
|
||||
|
||||
那么,具体来说,哪个部分需要有流畅部署的思想呢?如果我们从大的角度来看,一个数据科学项目最需要动态更新的部分,往往是**模型的产生**,也就是说我们希望能够用最新的数据来训练和测试模型,让模型能够考虑到最新的用户行为。因此,就可以说,只要是对模型的产生流程有影响的步骤,都需要能够达到流畅部署。假如我们更新了模型产生的代码,这些代码必须能够快速地反应到生产系统中。
|
||||
|
||||
除了快速和持续部署,人工智能项目的另外一个重要需求就是**可以对代码的不同分支进行测试和运行**。也就是说,我们不仅仅需要能对“主分支”(Master)进行部署,还需要能够对不同的其他分支进行部署,从而能够无缝运行这些不同的分支。
|
||||
|
||||
这一点我们在开发环境中往往很容易忽视。举个例子,人工智能项目需要做大量的A/B测试,而这些测试中的“控制组”(Control)和“待遇组”(Treatment),往往就对应着代码中不同分支的开发成果。因此,在我们不清楚“待遇组”所对应的代码是不是能够真正带来好处之前,最好不要把这个分支和主分支进行合并。我们首先需要在线测试这个分支的效果,这就带来了运行不同分支的一个需求。
|
||||
|
||||
## 数据管理流程
|
||||
|
||||
最后我们来简单聊一聊数据管理流程。这也是从事数据科学项目我们最容易忽视的一个部分。
|
||||
|
||||
对于绝大多数的人工智能产品来说,**代码,也就是项目的业务逻辑,是和数据是密不可分的**。从某种意义上说,**我们应该把对数据的关注程度排在第一位**。因为即便有正确的代码,如果数据出现偏差,有时候哪怕是一点点小的偏差,都有可能对最后的结果(例如模型)产生重大的影响。因此,我们需要不断地强调数据质量的重要性。
|
||||
|
||||
那么,对于一个项目的数据管理,又有哪些方面需要注意呢?
|
||||
|
||||
**在绝大多数的项目或者是产品中,数据的产生者、数据的运营者以及数据的使用者往往是不同的团队,这是数据管理的最大挑战**。这种角色上的差别往往导致了对于数据质量的忽视。
|
||||
|
||||
举一个例子,如果数据的产生者是一个产品团队,在最近的一次软件更新中,一个工程师把旧代码中对数据进行追踪的部分主观臆断地删除了一些字段,或者是为了变量名好看,更改了字段的名字。如果这个更新没有通知数据的运营者或者是使用者,这往往会带来什么后果呢?后果是下游整个软件线的流程中,数据可能发生重大变化。严重的时候,这样的问题会导致模型发生完全异常,产生不可控的后果。
|
||||
|
||||
因此,**从“端到端”的思维来考虑数据链路是非常有必要的**。在数据的产生、运行和使用的链条上,所有的用户必须达成某种数据的API,或者说是“共识”。任何对于数据的改变都需要在满足这种共识的基础上来沟通和进行。同时,数据的检测也是非常重要的,否则就是“垃圾进入导致垃圾输出”。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了数据科学团队的另外一个核心问题,那就是如何对工程流程进行管理。
|
||||
|
||||
一起来回顾下要点:第一,我们简单介绍了什么是人工智能项目的工程流程,以及这个概念和项目管理流程的区别;第二,我们分析了人工智能项目工程流程的三个主要方面,包括代码管理的要素,如何开发和部署环境,以及数据管理的要素。
|
||||
|
||||
最后,给你留一个思考题,除了我们所提及的工程流程的这三个方面,你还能想到什么其他的方面,在工程流程中也是至关重要的,需要我们在开发中注意呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
65
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/147 | 数据科学团队怎么选择产品和项目?.md
Normal file
65
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/147 | 数据科学团队怎么选择产品和项目?.md
Normal file
@@ -0,0 +1,65 @@
|
||||
<audio id="audio" title="147 | 数据科学团队怎么选择产品和项目?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/52/de/522fd1d34f50a83f06afc81354f2b8de.mp3"></audio>
|
||||
|
||||
上一期内容,我们聊了聊数据科学团队在工程流程方面所需要注意的三大问题,分别是代码管理流程,开发部署环境流程和数据管理流程。
|
||||
|
||||
今天,我们来继续讨论数据科学团队发展这个话题,来看另外两个关键问题:如何选择合作产品以及如何选择项目。
|
||||
|
||||
## 如何选择合作产品
|
||||
|
||||
选择什么样的产品进行合作,对于一个数据科学或者人工智能团队的发展来说,是一个非常重要的问题,是决定工作能否事半功倍的关键步骤。
|
||||
|
||||
作为工程技术团队,很多数据科学或者人工智能团队都需要支持多个产品,或者说是有机会选择产品。一个稳定的产品往往可以让一个人工智能团队得到快速健康的发展,并且能够逐渐形成良性循环,发展到可以支持更多的产品。
|
||||
|
||||
那么,什么样的产品是值得合作的产品呢?
|
||||
|
||||
我先来说一类需要谨慎合作的产品,那就是全新的产品方向。对于全新的产品来说,公司之前在这个方向没有太多的产品积累,也可能完全没有技术积累。对于这一类项目,我们需要格外小心,特别是当你的团队还在发展的初期。
|
||||
|
||||
新产品有一个特点,那就是极大的**不确定性**。产品范围、需求和时间一般都是不确定的,这些都是一个稳定项目的天敌。另外,还有一个比较棘手的问题,那就是新的产品方向,特别是公司以前从来没有研发过的项目,往往**缺乏数据**。对于机器学习来说,数据匮乏就是“巧妇难为无米之炊”了。
|
||||
|
||||
然而从另外一个角度来说,新的产品方向往往又能得到公司高层的重视。毕竟新产品往往是公司“新的赌注”(New Bet),所以很多时候也能够得到不少团队的支持和资源的倾斜。
|
||||
|
||||
那么,在这种情况下,如果你是数据科学团队的负责人,你就要对这个新产品的利弊有一个充分的认识。如果你的团队已经相对比较成熟,有好几个稳定的产品支持,还有一些剩余的资源可以分配,那么接受一个全新的产品也不失为一种尝试,虽然有一定的风险。最坏的情况是这个产品方向完全失败,但是不会对团队产生致命的影响。
|
||||
|
||||
了解了这种风险比较高的产品之后,我们来看一看什么类型的产品更值得一个人工智能团队来合作。总结来说,这样的产品一般需要满足以下两个方面。
|
||||
|
||||
**第一,看方向,这个产品最终是需要数据来驱动的**。如果一个产品最终会产生大量的数据,而且这些数据能够表征这个产品方方面面的发展,那么,针对这样的项目,人工智能可以起到巨大的推动作用。
|
||||
|
||||
**第二,看地位,这个产品是公司的核心发展项目**。这一点看似容易识别,但是在一个相对比较大的公司里,有时候反而并不那么容易识别。那怎么判断呢?介绍一个相对比较简单的方法,就是看一个产品是否和公司的利润或者说是公司的核心用户数据有关系。因为从公司的层面看,一个团队的投资回报率很关键,很多时候会以此来决定是否继续支持这个团队的发展。
|
||||
|
||||
举个例子,有这么一个产品,虽然不直接产生公司的利润,但是能够帮助公司增长用户,那这个项目也可以算是公司的核心项目。**能够支持公司的核心项目,是人工智能团队稳定快速成长的基石**。
|
||||
|
||||
## 如何选择项目
|
||||
|
||||
选择好了合作的产品之后,一个产品的迭代过程中还会产生很多不同的项目。是不是这些项目都值得做呢?接下来我们就来看一看究竟应该选择什么样的项目来做。
|
||||
|
||||
关于项目的选择,我们先有这样一个共识。在团队和产品发展的不同时期,对于如何选择项目应该有不同的考虑。
|
||||
|
||||
在这里,有一种思维模式可以帮助我们来对不同的项目进行筛选,那就是“**投资组合**”(Portfolio)的思维。通俗地讲,投资组合思维的核心就是“不能把所有的鸡蛋都放在一个篮子里”。
|
||||
|
||||
简单来说,我们可以利用四象限法,把不同的项目分为“高投入、高回报”、“低投入、高回报”、“高投入、低回报”和“低投入、低回报”这四种类型。那么,针对这四种不同的类型,我们就需要利用投资组合的思路来选择项目。
|
||||
|
||||
从理论上来说,我们希望所有的项目都是“低投入、高回报”的,肯定不希望项目是“高投入、低回报”。那么,从表面上看,对于项目的选择,我们其实并没有太多可以争议的地方。但是,实际的情况是,对于绝大多数项目来说,我们并不知道这个项目属于什么类型,最好的情况也无非是对项目有一个估计,而这种估计很有可能会和真实情况相差甚远。
|
||||
|
||||
因此,对于投资组合的思路来说,这不仅仅是一种对于投入和回报的估计,还包括对于不同类型项目的选择。这里呢,我就讲一些在以往工作中积累的项目选择经验。
|
||||
|
||||
一般来说,**对于一个人工智能项目来说,特征工程(Feature Engineering)都是属于“高回报”的项目**。对于大多数的类似项目来说,特征工程往往能够针对项目带来本质上的提升。寻找到好的特征是一个项目能够持续成功的重要途径。
|
||||
|
||||
在“高回报”的情况下,我们需要考虑的是,这个项目是“高投入”的?还是“低投入”的?如何评价一个特征工程项目的投入成本呢?我们问以下三个问题。这个项目可以基于现在的数据链路(Pipeline)来做吗?是否只是计算一些数据的简单统计量?是否只是把每天不同的统计量做一些叠加?如果三个问题的答案都是“是”,那么这种类型的特征工程项目就属于“低投入”。
|
||||
|
||||
在一个产品的早期,应该尽量尝试这样的项目,快速发现有用的,特别是那些能够让产品的效果得到迅速提升的特性。而且,因为特征工程“高回报”的特点,在产品迭代的任何一个时期,我们其实都可以关注某一部分的特征工程项目。只是说,也许在产品的初期,找到一系列特征,或者说挖掘出一系列有效的特征,往往会非常容易;但是在产品的中后期,难度就要大一些。
|
||||
|
||||
我介绍的另一个经验可能和你想象的不太一样,**对于核心算法(例如搜索、推荐、广告)的改进,比如改进排序算法属于“高投入”的项目**。这类改进算法项目的一个明显特点,就是往往需要有较长时间的研发周期。而且,这类项目的升级换代往往需要“基础设施”(Infrastructure)或者平台级别的变化。也就是说,这类项目的投入比较大,周期比较长。
|
||||
|
||||
当然了,这类项目的回报如何,其实并不是特别容易估算的。例如,我们在特征不变的情况下,从线性模型更改到树模型,可能会有5%~10%的性能提升。但是更改到树模型之后,也许我们还能够加入更多适应于树模型的特性,带来后面的10%~20%的提升。因此,如果考虑到一个回报的系列性效果,算法的更改升级还是应该引起我们足够的重视的。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你讲了数据科学团队的两个核心问题,那就是如何选择产品以及如何选择项目。
|
||||
|
||||
一起来回顾下要点:第一,我们聊了聊产品的选择,尽量对新产品持谨慎态度,同时尽量支持并开发公司的核心产品;第二,我们分析了如何选择项目,重点是对四种类型的项目进行一个探讨。
|
||||
|
||||
最后,给你留一个思考题,如果我们希望从树模型升级到“深度模型”,这种项目属于我们介绍的四种类型项目中的哪一类呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
97
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/148 | 曾经辉煌的雅虎研究院.md
Normal file
97
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/148 | 曾经辉煌的雅虎研究院.md
Normal file
@@ -0,0 +1,97 @@
|
||||
<audio id="audio" title="148 | 曾经辉煌的雅虎研究院" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1b/36/1bf4d2d9b00089df75bc0243ce92e636.mp3"></audio>
|
||||
|
||||
雅虎是最早成功的互联网公司之一,也是最早意识到需要把基础研究,特别是机器学习以及人工智能研究,应用到实际产品中的公司。雅虎从很早就开始招聘和培养研究型人才,雅虎研究院就是在这个过程中应运而生的。
|
||||
|
||||
今天我就来说一说雅虎研究院的历史,以及过去十多年间取得的成就,聊一聊如何通过引进高级人才,迅速构建起一支世界级的研发团队。当然,也会聊一聊研究院的衰落。高级研发机构对于企业而言往往是锦上添花的事情,在整个公司产品和视野都欠缺的情况下,也往往避免不了最后衰败的结局。
|
||||
|
||||
## 雅虎研究院的创立
|
||||
|
||||
雅虎研究院的故事要从一个叫乌萨马·菲亚德(Usama Fayyad)的人说起。乌萨马出生在北非突尼斯的迦太基(Carthage),早年在突尼斯以及其他地中海沿岸国家度过,包括中东、非洲以及南欧的一些国家。高中时期在约旦的安曼生活,后来在美国密歇根大学度过了他的本科(1984年)、硕士(1986年)以及博士(1991年)生涯。毕业之后,乌萨马来到了美国加州南部隶属于美国国家航空航天局(NASA)的喷气推进实验室(Jet Propulsion Laboratory)工作,一直到1996年。之后加入微软研究院,从事数据挖掘的研究工作。
|
||||
|
||||
早在1994年,乌萨马就和拉马萨米(Ramasamy Uthurusamy)一起组织了最后一届KDD研讨班,然后在1995年,他们把这个研讨班升级成了会议,并在加拿大蒙特利尔举办了第一届KDD大会(First International Conference on Knowledge Discovery in Data)。从此,KDD大会成了数据挖掘、数据科学以及应用机器学习的顶级会议。
|
||||
|
||||
1996年,乌萨马又创办了一本叫《数据挖掘和知识发现》(Data Mining and Knowledge Discovery)的学术期刊,并亲自担任主编。这本期刊也渐渐成了数据挖掘领域主要的学术期刊之一。乌萨马本人可以说在20世纪90年代中期,就已经开始成为数据挖掘领域重要的领军人物。
|
||||
|
||||
进入21世纪,乌萨马先是在2000年创立了一家叫Audience Science的数据挖掘公司并担任CEO,然后又在2003年创立了一家叫DMX Group的数据挖掘咨询公司,后者于2004年被雅虎收购。不久后,他成为雅虎的执行副总裁以及首席数据官(Chief Data Officer),这也是互联网历史上的第一位首席数据官。
|
||||
|
||||
因为雅虎在搜索以及广告业务上的扩展,乌萨马意识到应该成立一个类似于微软研究院,但更偏向于互联网业务的研究组织,这个想法得到了公司CEO杨致远的支持。乌萨马当时的首要任务是为研究院物色一位院长。
|
||||
|
||||
经过一段时间的寻找,他成功邀请到普拉巴卡·拉加万(Prabhakar Raghavan)来担纲。今天回头来看,普拉巴卡无疑成功地引领了雅虎研究院,并让其一度成为人人向往的互联网研究机构。当然,这跟普拉巴卡本人的经历也密切相关。
|
||||
|
||||
首先,他本人就是知名的学者,参与撰写的经典教科书《随机算法》(Randomized Algorithms)和《信息检索导论》(Introduction to Information Retrieval)在学术界享有盛誉。他还是ACM、IEEE的院士,也是美国工程院院士,这为他招纳学术界权威人士和博士生提供了便捷。加入雅虎之前,他已经在IBM研究院以及Verity任职多年,IBM的从业经历更是让他对企业文化和工业界的研究机构有了很深的了解。
|
||||
|
||||
2005年7月,雅虎研究院正式成立,普拉巴卡担任研究院负责人,向乌萨马汇报。2008年,雅虎研究院与之前就在搜索与广告事业部存在的应用科学部门合并。在卡罗尔·巴茨(Carol Bartz)任职CEO期间,普拉巴卡直接给她汇报,并且普拉巴卡还曾担任首席战略官。
|
||||
|
||||
## 雅虎研究院的蓬勃发展和辉煌
|
||||
|
||||
雅虎研究院组建之后,首要任务当然就是吸引工业界和学术界的知名学者,从而能够组建一个有效的团队。普拉巴卡利用他个人和乌萨马的声望,很快就做到了这点。
|
||||
|
||||
比如,之前和普拉巴卡在IBM共事的安德鲁·汤姆金斯(Andrew Tomkins)加入团队,担任负责搜索的首席科学家以及搜索方面的副总裁(安德鲁后于2009年之后加入谷歌担任工程总监)。 再比如,曾和普拉巴卡在IBM共事的安德烈·布罗德(Andrei Broder)2005年加入团队,担任负责计算广告方面的副总裁。
|
||||
|
||||
安德烈本人大有名头。他在斯坦福大学攻读博士期间师从图灵奖得主高德纳(Donald Knuth),然后在曾经名噪一时的第一代搜索引擎公司AltaVista担任首席科学家,之后加入位于纽约的IBM研究院组建企业级搜索平台。和普拉巴卡一样,安德烈也是ACM和IEEE的双料院士。2012年安德烈加入谷歌,担任杰出科学家 (Distinguished Scientist)。
|
||||
|
||||
我们这里简单列举一些曾经在雅虎研究院工作过的知名学者,我们便可一览其盛况:
|
||||
|
||||
<li>
|
||||
Ronald J. Brachman:哈佛大学计算机科学博士,加入雅虎研究院之前长期于贝尔实验室工作,曾担任贝尔实验室人工智能研究部的负责人。1996年之后担任AT&T实验室通信服务研究中心副总裁。2005年加入雅虎研究院协助普拉巴卡进行管理,并于2012年到2016年间担任雅虎研究院首席科学家以及负责人。Ronald曾任AAAI主席。2016年之后担任纽约康奈尔科技大学的Jacobs Technion-Cornell研究院院长。
|
||||
</li>
|
||||
<li>
|
||||
Yoelle Maarek:以色列理工大学计算机科学博士,加入雅虎研究院之前曾任IBM研究院的杰出工程师和谷歌的工程总监。历任雅虎研究院以色列分部的负责人、高级研究总监,并在2016年Ronald离开之后任雅虎研究院的负责人。
|
||||
</li>
|
||||
<li>
|
||||
Jan Pedersen:斯坦福大学统计学博士。2002年加入AltaVista担任首席科学家(在安德烈之后)。2003年加入雅虎研究院担任搜索和广告方面的首席科学家(在安德鲁·汤姆金斯之前)。2009年加入微软,担任Bing核心搜索部门(Core Search)的首席科学家。2017年加入Twitter,担任数据科学副总裁。
|
||||
</li>
|
||||
<li>
|
||||
Ben Shahshahani:普渡大学电气工程博士。曾在Nuance Communications担任工程总监。2005年加入雅虎研究院,之后历任负责搜索广告的高级总监以及搜索与媒体科学组的副总裁。2012年加入谷歌任工程总监。2014年回到雅虎,任广告科学方面副总裁。
|
||||
</li>
|
||||
<li>
|
||||
Ricardo Baeza-Yates:滑铁卢大学计算机科学博士,ACM和IEEE双料院士,信息检索和搜索方面的权威,著有《现代信息检索》( Modern Information Retrieval)一书。他在雅虎研究院担任拉美和欧洲分部的副总裁直至2016年,也是智利科学院以及工程院的院士。
|
||||
</li>
|
||||
<li>
|
||||
Ravi Kumar:康奈尔计算机科学博士,加入雅虎研究院之前在IBM 研究院从事数据挖掘算法的研究。2005年加入研究院之后担任首席研究科学家。2012年加入谷歌担任高级主任研究科学家(Senior Staff Research Scientist)。他的论文引用数达3万次以上。
|
||||
</li>
|
||||
<li>
|
||||
Evgeniy Gabrilovich:以色列理工大学博士,在雅虎研究院担任首席研究科学家,并且担任自然语言处理方向研究的负责人。2012年加入谷歌担任高级主任研究科学家。2012年当选ACM杰出科学家(ACM Distinguished Scientist)。
|
||||
</li>
|
||||
<li>
|
||||
Deepak Agarwal:康涅狄格大学(University of Connecticut)统计学博士,加入雅虎研究院之前在AT&T担任高级研究科学家一职。2006年加入雅虎研究院担任首席研究科学家,主要研究推荐系统相关的内容。2012年加入LinkedIn,担任人工智能和机器学习方面的副总裁。
|
||||
</li>
|
||||
<li>
|
||||
Alexander Smola:柏林理工大学计算机科学博士,加入雅虎研究院之前任澳大利亚国立大学教授。2008年加入雅虎研究院后任首席研究科学家(Principal Research Scientist)。2013年加入卡内基梅隆大学任教授一职。2016年加入亚马逊担任机器学习方面的总监。他的论文引用数达8万次以上。
|
||||
</li>
|
||||
<li>
|
||||
Jianchang (JC) Mao:密歇根州立大学计算机科学博士,加入雅虎研究院之前曾在IBM 研究院任职,还曾担任Verity的首席软件架构师。2004年加入雅虎之后任广告科学方面副总裁。2012年加入微软之后,先后担任Bing的多个职务并于2016年被提升为公司副总裁。他的论文引用数达1万次以上。
|
||||
</li>
|
||||
<li>
|
||||
Raghu Ramakrishnan:德克萨斯大学奥斯汀分校计算机科学博士,加入雅虎研究院之前担任威斯康星大学教授。2006年加入雅虎研究院之后任云计算方面的副总裁。2012年加入微软之后一直担任CTO,负责云计算领域。他的论文引用数达3万次以上。
|
||||
</li>
|
||||
|
||||
当然,在雅虎研究院工作过的知名人士还有很多,这里无法一一列举。不过我们可以看出,不少人在离开雅虎之后,依然在业界发挥着不小的作用。
|
||||
|
||||
**除了招揽到一批优秀人才,雅虎研究院也发表了一系列有价值的研究成果,在很短的时间内建立了学术研究上的威望**。在10年间,据不完全统计,雅虎研究院的学者获得过两次信息检索顶级会议ACM SIGIR的最佳论文、3次数据科学和数据挖掘顶级会议ACM KDD 的最佳论文、两次机器学习顶级会议ICML的最佳论文、两次推荐系统顶级会议ACM RecSys的最佳论文、两次信息检索以及网络信息挖掘的权威会议ACM WSDM的最佳论文、两次信息检索和数据库领域顶级论文ACM CIKM最佳论文以及一系列有影响力的最佳论文奖项,涵盖了搜索、广告、推荐系统、数据挖掘、机器学习、人机交互等诸多方面,为互联网研究和发展做出了重大贡献。
|
||||
|
||||
可以说在非常短的时间内,雅虎研究院就用卓越的研究成果向世人证明了这个团队和组织的实力。曾经在某一段时期内,世界各国的优秀研究人员和博士毕业生都希望跻身雅虎研究院的研发队列。
|
||||
|
||||
## 雅虎研究院逐渐成为历史
|
||||
|
||||
2012年是雅虎历史上格外动荡的一年。先是公司CEO卡罗尔·巴茨在上一年的9月份被董事会解雇;然后经历了短暂的临时CEO——蒂姆·莫尔斯(Tim Morse);之后新CEO斯科特·汤普森(Scott Thompson)在1月上任,5月份就因学历造假丑闻离职;罗斯·莱文索恩(Ross Levinsohn)之后担任公司临时CEO直至7月。然后,玛丽莎·梅耶尔(Marissa Mayer)加入公司担任CEO。短短不到一年的时间里,共有5个人担当了CEO的职位。
|
||||
|
||||
在这个过程中,普拉巴卡离职并加入谷歌,很多之前追随他的人也先后加入谷歌。普拉巴卡离开后,罗纳德·布拉赫曼(Ronald J. Brachman)接过了研究院领导人的位置,并在2012到2016的4年间为玛丽莎重新招募了超过100名博士科学家。
|
||||
|
||||
2016年2月,雅虎宣布研究院不再作为一个独立实体而存在,罗纳德离职,所有研究人员被分散到各个工程部门,依然保留雅虎研究院的对外旗号,耶艾尔·玛瑞克(Yoelle Maarek)担任负责人。2017年雅虎和Verizon合并,雅虎作为一个独立的公司成为历史。
|
||||
|
||||
雅虎研究院逐渐淡出历史舞台,这固然有公司高层频繁更换的原因,也有一些更加深层次的原因。研究院的成果往往都需要一定时间才能直接在产品中体现出来,因此,虽然在技术上研究院能够帮助公司提升水平,但是实际产品的效果未必就一定能够受到用户的青睐。
|
||||
|
||||
例如,研究院曾经投入了大量人力物力,利用机器学习来提高搜索引擎的搜索品质。可以说,雅虎是最早将人工智能和机器学习技术大规模应用在搜索引擎上的公司。但是搜索引擎的好坏很多时候是一个产品、技术、设计的综合体现,雅虎研究院研发的算法并没有在产品的综合表现中挣得额外加分。
|
||||
|
||||
相似的例子还包括雅虎研究院在早期就投入了很多力量研发广告平台,甚至包括安德烈·布罗德本人到斯坦福大学开设了世界历史上第一门计算广告学的课程。然而,雅虎整个平台的产品都在下滑,因此广告平台受到了额外的压力。虽然研究院的科学家们在算法和模型上做出了很多创新,也在一定时间内带来了不小的收益,但都无法改变整个公司产品线运营不佳的情况。于是,**雅虎研究院的成果在雅虎整体业绩不理想、公司产品缺乏想象力的大背景下显得杯水车薪,并不能从整体上扭转公司的颓势**。在公司进入动荡之后,研究院对于高层领导来说,往往也就不是公司的重点发展对象了,研究院的瓦解也就成了必然。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你分析了雅虎研究院的兴衰。一起回顾下要点:首先,雅虎研究院曾通过引进高级人才的方式,迅速构建起了一支世界级的研发团队,并发表了一系列有价值的研究成果,建立起在学术研究上的威望,创造了研究院曾经的辉煌;其次,因高层变动以及一些深层次的问题,雅虎研究院没有摆脱最后衰落的结局,一切辉煌终成历史。
|
||||
|
||||
最后,给你留一个思考题:到底什么样的**企业环境**能够最好地发挥研究院的成果,又是怎样的**研发流程**能够使研究院成为公司新动力的源泉?雅虎研究院在当年并没有找到答案。不知道随着最近一批互联网新贵纷纷成立人工智能研发团队的契机,大家是否能够找到更好的研究院运作模式。
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
59
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/149 | 微软研究院:工业界研究机构的楷模.md
Normal file
59
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/149 | 微软研究院:工业界研究机构的楷模.md
Normal file
@@ -0,0 +1,59 @@
|
||||
<audio id="audio" title="149 | 微软研究院:工业界研究机构的楷模" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bb/b6/bb015bf9d08232ef406ffc223ad1e4b6.mp3"></audio>
|
||||
|
||||
随着人工智能的兴起,各大公司纷纷建立起自己的研发团队,来对这一重要技术领域进行探索。一些有一定规模的公司还会成立更加精英的“研究院”或者“实验室”,吸引业界顶尖人才到自己的公司进行基础的和前沿的研发工作。
|
||||
|
||||
那如何来组建这样的机构呢?有没有可以参考的类似机构呢?答案是有这样一个机构,甚至很多公司会不惜重金去聘请这个机构的研究和管理人才。今天我们就来聊聊这个机构,那就是“**微软研究院**”。
|
||||
|
||||
微软研究院自1991年成立以来,已经走过了接近40年的岁月。依托于微软这个软件时代的巨头,微软研究院也和微软公司一起经历了从软件时代到互联网时代、到移动时代、再到人工智能时代的重大变迁,见证了这几个时代中前沿科技对公司的影响。
|
||||
|
||||
微软研究院的历史有多辉煌呢?至少有五位图灵奖得主曾经在微软研究院工作过,包括发明了“霍尔逻辑”和快速排序的托尼·霍尔(Tony Hoare)爵士、在数据库领域有卓越贡献的吉米·格雷(Jim Gray)、个人计算的先驱巴特勒·兰普森(Butler Lampson)、个人电脑的先驱查尔斯·萨克尔(Charles P. Thacker)和在分布式算法方面有突出贡献并发明了LaTeX排版语言的莱斯利·兰波特(Leslie Lamport)。研究院里的美国科学院院士、工程院院士、IEEE院士以及其他各类最高学术成就获得者,可以说是数不胜数。更别提发表了2万多篇论文,每年都有各种激动人心的项目的研发。从很多角度来看,**微软研究院都堪称工业界研究机构的模板**。
|
||||
|
||||
接下来我们就一起来梳理一下微软研究院这个具有传奇色彩研究机构的传奇故事。
|
||||
|
||||
## 微软研究院的成立
|
||||
|
||||
虽然微软研究院在工业界研究机构中有着显赫的地位,但是其最早的发展则鲜为人知。我们了解微软研究院成立的早期历史,也是为了体会一下缔造者们的思想和视野,以及他们是如何一步一步地把一个小的团队发展成为了工业界的典范的。
|
||||
|
||||
先介绍第一个关键人物,他的名字叫内森·米尔沃德(Nathan Myhrvold)。1996年,他成为了微软历史上首位首席科技官(CTO)。米尔沃德说服了比尔盖茨等微软高层来建立一个研究性质的机构。这个决定其实让很多人都感到出乎意料,那米尔沃德是怎么想的呢?
|
||||
|
||||
他认为,微软之前的成功是把大型计算机的一些经验移植到了当时方兴未艾的小型计算机,也就是个人电脑上。这样把现成经验进行产品转换的思路迟早会让微软黔驴技穷,应该及早着眼于一条能够“持续造血”的路,所以微软需要有一个长期专注基础研究的部门。
|
||||
|
||||
米尔沃德不仅仅只是提出了这样一个洞见,他还为基础研究的一些特性拟定了基调。首先,基础研究或者说是更高级的研发工作和产品开发有本质的区别。其次,有时候基础研究并不一定能给母公司带来足够的好处,但这种失败率其实和普通的产品研发也很类似,因此没有必要因为基础研究的一些失败而过分敏感。
|
||||
|
||||
同时,米尔沃德对基础研究能够给公司带来什么样的好处也做了深刻思考,他总结了三点:第一,基础研究能够让公司在时间上获得接触到最新科技的优势;第二,能够帮助公司更广泛地接触先进技术;第三,能够给公司带来知识财产,比如专利等。
|
||||
|
||||
当这个在微软建研究机构的想法得到认同后,米尔沃德希望为这个新的研究部门找一个领军人,他想到了理查德·拉希德(Richard Rashid),这是我们要介绍的第二个关键人物。
|
||||
|
||||
拉希德于1974年从斯坦福大学毕业,获得数学和比较文学的学士学位。1980年,他在罗杰斯特大学(University of Rochester)获得计算机科学博士学位,然后成为了卡内基梅隆大学计算机系的一名教授。在担任教授期间,他在计算机系统、网络系统、人工智能以及编程语言等诸多领域发表了众多论文。除了论文之外,他比较有影响的工作还包括一款叫作“Mach”的计算机操作系统微内核。
|
||||
|
||||
米尔沃德通过共同的好友找到拉希德,那已经是1991年夏天的事情了。拉希德的第一反应是觉得这是一个玩笑。1991年,微软还不是今天这样的大公司。一家规模并不大的公司要成立一个研究机构让人感觉不太现实。
|
||||
|
||||
拉希德和家人被邀请到微软访问,和比尔盖茨以及其他微软的管理高层见了面。他原以为微软的人并不明白建立一个研究部门要干什么,也不一定真心希望有这么一个研究机构。所以,当发现比尔盖茨非常支持并且非常真诚地理解建立研究机构的需求时,拉希德还是相当吃惊的。然而,即便如此,他还是拒绝了这个邀约,因为他当时觉得对这个职位并不感兴趣。
|
||||
|
||||
米尔沃德也没放弃,在接下去的一段时间,他把拉希德的电话打烂了。恰好在这个时候,拉希德也迎来了他职业生涯的一个选择关口,卡内基梅隆大学希望他出任计算机学院的院长。这样,他就需要在两份工作邀约之间做一个抉择。
|
||||
|
||||
时间到了1991年的8月31日,拉希德决定出任微软研究院的院长。从1991年到2013年,拉希德都是微软研究院的领导人。这个研究机构在他带领下的20多年时间里发生了惊天动地的变化。
|
||||
|
||||
## 微软研究院模式
|
||||
|
||||
刚刚我们回忆了微软研究院历史中最初的一个片段。但是从这个片段中,我们其实已经体会到了这个组织之所以成功的一些因素,这些因素是在最开始就深深根植到了组织的架构中的。
|
||||
|
||||
**第一个要素是研究院的领导人一定要有深厚的研究背景**。成立研究院的时候,米尔沃德第一时间想到的是到学术界找到一个学术权威。实践告诉我们,正是拉希德的加入,让微软研究院在招收顶级人才方面有着无与伦比的优势。当然,是不是任何一个学术大家都胜任这样的工作呢?这是另外一个值得我们思考的问题。
|
||||
|
||||
具体来说,拉希德带来的优势有哪些呢?一方面,他可以借助曾经是卡内基梅隆大学教授这个身份从学校吸引人才;另一方面,他在学术界的朋友也会因此加入。实际上,拉希德决定加入微软研究院后,第一个电话就打给了他在IBM研究院的一个好友,邀请他加入微软。而拉希德卸任之后接手微软研究院的彼得·李(Peter Lee)也曾经是卡内基梅隆大学计算机系的主任。
|
||||
|
||||
由此看来,虽然米尔沃德在一开始颇费了一番工夫才把拉希德纳入微软,但是后续的招聘工作就相对顺利起来。类似地,李开复到北京建立微软亚洲研究院,基本上也是一样的思路。
|
||||
|
||||
**第二个要素就是研究院这样的部门必须要有公司最高层的一致支持**。这种支持还必须是一种真诚的支持。试想没有米尔沃德和比尔盖茨以及微软高层和拉希德的真挚交流,拉希德不可能选择加入微软研究院,那这个机构是否还存在可能就是另外一番光景了。微软高层对研究院的支持不是一朝一夕,而是30多年来一直如此。并且在最近的人工智能浪潮下,这种支持只增不减,这也是这个机构能够成功的一个重要因素。
|
||||
|
||||
**第三个要素也就是公司的高层一定要明确研究院究竟会对公司造成什么样的影响,或者说,要对研究院的产出有一个合理预期**。从这一点来说,微软的早期领导人非常明确地认识到基础研究和一般的产品开发是有区别的,并且对基础研究的失败率有一个完整的理解。这一点是非常惊人的。对于1991年的微软,就能有这样一种非常不容易的状态,并且还能够一致保持这样状态,这也许就是这个机构和这家公司几经沉浮依然茁壮发展的秘诀。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我和你一起简单回顾了微软研究院早期的一些不为人知的历史,并归纳了微软研究院成功的三个要素。
|
||||
|
||||
最后,给你留一个思考题,微软最近又在研究院的基础上成立了一个全新的AI部门,你觉得原因是什么?这个部门和研究院是不是有重叠呢?
|
||||
|
||||
欢迎你给我留言,和我一起讨论。
|
||||
|
||||
|
||||
68
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/150 | 聊一聊谷歌特立独行的混合型研究.md
Normal file
68
极客时间专栏/geek/AI技术内参/数据科学家与数据科学团队养成/150 | 聊一聊谷歌特立独行的混合型研究.md
Normal file
@@ -0,0 +1,68 @@
|
||||
<audio id="audio" title="150 | 聊一聊谷歌特立独行的混合型研究" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ab/a9/ab307340e007c724f4635610be175fa9.mp3"></audio>
|
||||
|
||||
上一讲我们介绍了微软研究院发展早期的一段故事,一起讨论了为什么说微软研究院是工业界研究院的楷模。
|
||||
|
||||
今天我们来看另外一种“**混合型**”的工业界研究机构模式,聊一聊**谷歌研究院**,一起来讨论这种模式是不是更加适合互联网企业的需求。
|
||||
|
||||
## 研究背景起家的谷歌
|
||||
|
||||
谷歌的创立比微软晚了将近20年,但两个公司有一些相似的地方,其中之一就是创始人都是中断了学业,投身到创业的浪潮中。不过拉里·佩奇(Larry Page)和谢尔盖·布林(Sergey Brin)当时是在攻读博士学位,关于如何进行网页搜索的最初想法,是从他们的博士研究课题衍生出来的[1]。由此可见,谷歌从一开始就和研究类项目有着千丝万缕的联系。
|
||||
|
||||
佩奇和布林的论文发表在1998年的国际万维网(WWW)大会上。这篇论文介绍了PageRank算法,在当时这简直就是一个石破天惊的算法。那它和当时其他搜索引擎的关键技术相比,独特之处在哪里呢?计算网页的相关度或者说是重要度完全不依赖文本信息,而仅仅依靠由网页之间关系组成的图,而且能够得到一种非常稳定的排序。或许就是因为这个独特的算法让两个斯坦福大学的年轻人放弃了继续攻读博士学位的想法,转身在硅谷找了一个车库,从而演绎了一个传奇的创业故事。
|
||||
|
||||
或许就是因为创始人的背景,我们可以看到谷歌对学术界的最新研究成果有一种特殊的青睐,在谷歌发展的路上,屡屡上演收购案例,收购的很多公司都是因为有一些研究成果而成立的小公司。
|
||||
|
||||
举几个例子。同样来自斯坦福的博士毕业生塔哈尔·哈维利瓦拉(Taher H. Haveliwala),改进了PageRank算法[2],他创办的公司在2003年的时候被谷歌收购。2010年,达蒙·霍洛维兹(Damon Horowitz)和瑟潘达·卡姆瓦尔(Sepandar D. Kamvar)在当年的国际万维网大会上发表了一篇“社交搜索”(Social Search)的论文,论文标题都跟佩奇和布林当年发表的PageRank论文有异曲同工之妙。两个作者所在的公司很快就被谷歌收购了。最近的例子就是我们都熟知的杰弗里·辛顿(Geoffrey Hinton)所创立的公司以及位于英国的DeepMind公司,也都是因为在深度学习方面的重要贡献被谷歌先后收购。
|
||||
|
||||
## 混合型工业界研究
|
||||
|
||||
尽管谷歌对于学术研究有一种天然的亲近,然而在很长一段时间里,谷歌其实并没有真正成立完全独立的基础研究部门。所以很多学术圈的研究人员,还有工业界的研究同仁,都对谷歌产生了一种误解。
|
||||
|
||||
2012年的时候,谷歌的研发总监彼得·诺维格(Peter Norvig)发表了一篇文章[4]来介绍谷歌的研究模式。
|
||||
|
||||
谷歌的研究模式到底是怎样的呢?简单来说,就是**让研究和产品的研发紧密结合起来,而不完全建立独立运行的研究院**。当然,这个模式在收购了DeepMind之后算是被打破了。但是在谷歌20年的发展历史上,**混合型研究一直是谷歌研发的主流**。
|
||||
|
||||
诺维格在文章中解释道,谷歌研究工作的一大重要目的就是**为终端用户带来重要的和实际的好处**。很明显,这一目的和纯粹的学术研究有很大的距离。我们来看微软研究院和雅虎研究院,它们的重要贡献指标就是学术论文发表的质量和数量。
|
||||
|
||||
我们再具体来看看这两种道路的差异。
|
||||
|
||||
传统的学术研究是这样的:研究人员首先构想一个学术课题,然后在一种比较受限的环境中对这个课题进行研究。这里说的受限的环境,往往是指数据并不是全量数据,而是采样过后的数据,这些数据能够在学者们的笔记本或者小型集群中进行计算。甚至在有的情况下,研究人员会使用完全虚拟的数据。另外,在这种受限的环境中进行研究还会带来这样一个问题,由于开发的代码和软件不需要重复使用,也不需要开发生产环境的代码,所以这些代码质量都相对较低。
|
||||
|
||||
那谷歌的研究工作是怎样做的呢?**谷歌研究要求从一开始就使用生产环境来编写代码**。这些代码和普通的产品代码没有区别,也使用和一般产品线代码相同的数据、相同的流程。这样,一旦有了研究成果就可以无缝接入现在的产品线中。这样的要求对于研究者来说,其实是拔高了研究的难度,但是对于研究成果和产品对接来说就将困难降低到了最小。
|
||||
|
||||
总结一下,**让工程和研究结合在一起,并且有意模糊这两者的区别,就是谷歌混合型研究的核心思想**。工程师和科学家在同样的项目中工作,大家都面临同样的限制,这样就可以让研究的课题不至于完全天马行空,而是能够落到实处。
|
||||
|
||||
## 混合型研究的思考
|
||||
|
||||
我们上面介绍了谷歌的研究背景以及基于此慢慢形成的混合型研究模式。为什么这条道路在谷歌就能够落地实施呢?我想这里面有一个非常重要的先决条件,这是诺维格的文章里没有提到的,那就是大量高素质人才的涌入。
|
||||
|
||||
在这些人才中,博士生比比皆是,甚至有很多教授。所以,谷歌的工程团队中有很多博士生担任着普通工程师的角色。说得通俗一点,谷歌用博士生在干硕士生甚至是本科生就可以胜任的工作。一个团队中的工程师和科学家并没有本质的区别,这才使得任何一个科研想法都可以很容易地在工程层面得以实现。
|
||||
|
||||
由此我们可以看到,从某种意义上来说,谷歌其实并不需要单独的研究机构,自己工程团队的水平就已经非常出色了。我们从TensorFlow、语言翻译等知名项目就可以看出来,这些项目都是工程团队达到了很高的研究水平。
|
||||
|
||||
当然,在这种模式下,谷歌的基础研究其实是受限的。在收购了DeepMind后,谷歌也开始依靠这样单独的研发机构来推动和产品结合得不那么紧密的研究方向。
|
||||
|
||||
## 小结
|
||||
|
||||
今天我为你介绍了谷歌与众不同的混合型研究模式。这种模式对工程团队的水平要求比较高,如果没有高水平的工程团队,研究人员和工程师就会产生隔阂,沟通不畅,研发就会有问题。从这个角度来看,建立单独的研究机构或许更能实现很多公司的初衷。
|
||||
|
||||
讲到这里,如果我们要借鉴谷歌的这种混合型模式,你觉得挑战是什么?如果有了高水平工程团队这一保障后,你觉得想要成功还有什么挑战?
|
||||
|
||||
欢迎你给我留言,我们一起讨论。
|
||||
|
||||
**参考文献**
|
||||
|
||||
<li>
|
||||
Sergey Brin and Lawrence Page. The anatomy of a large-scale hypertextual Web search engine. Proceedings of the seventh international conference on World Wide Web 7 (WWW7), Philip H. Enslow, Jr. and Allen Ellis (Eds.). Elsevier Science Publishers B. V., Amsterdam, The Netherlands, The Netherlands, 107-117, 1998.
|
||||
</li>
|
||||
<li>
|
||||
Taher H. Haveliwala. Topic-sensitive PageRank. Proceedings of the 11th international conference on World Wide Web (WWW '02). ACM, New York, NY, USA, 517-526, 2002.
|
||||
</li>
|
||||
<li>
|
||||
Damon Horowitz and Sepandar D. Kamvar. The anatomy of a large-scale social search engine. Proceedings of the 19th international conference on World wide web (WWW '10). ACM, New York, NY, USA, 431-440, 2010.
|
||||
</li>
|
||||
<li>
|
||||
Alfred Spector, Peter Norvig, and Slav Petrov. Google’s hybrid approach to research. Commun. ACM 55, 7 (July 2012), 34-37, 2012.
|
||||
</li>
|
||||
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
|
||||
今天,我准备了24张知识卡,和你一起复盘数据科学家养成和数据科学团队的养成这两个模块。在这两个模块里,我们一共讨论了8个话题,从方方面面分享了数据科学家所需具备的技能;也从组建一个团队的角度出发,让你更了解自己在团队中的角色;最后,我们还聊了雅虎研究院等知名团队,帮你拓展视野。
|
||||
|
||||
提示:点击知识卡跳转到你最想看的那篇文章,温故而知新。
|
||||
|
||||
## 数据科学家基础能力
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/77/ac/77d37005073f805e73268446179428ac.jpg" alt="" />](https://time.geekbang.org/column/article/308)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/d0/de/d0d025f6b77fb6aeebcf57e7e97a02de.jpg" alt="" />](https://time.geekbang.org/column/article/311)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/b1/ec/b138ca051e5f0d29727d062892c617ec.jpg" alt="" />](https://time.geekbang.org/column/article/316)
|
||||
|
||||
## 数据科学家高阶能力
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/35/5d/35d8e298059c06428012c2a3ce725e5d.jpg" alt="" />](https://time.geekbang.org/column/article/382)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/79/29/7995ddec3b3e68ed5afb66989868af29.jpg" alt="" />](https://time.geekbang.org/column/article/385)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/7a/e6/7a2b68019dc09fd52321e614e3bf90e6.jpg" alt="" />](https://time.geekbang.org/column/article/388)
|
||||
|
||||
## 数据科学家职场话题
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/62/d9/62fcfe490d4662d5c1098b17639d63d9.jpg" alt="" />](https://time.geekbang.org/column/article/2504)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/1e/a7/1ed45672efb5e31ff5d17286e76566a7.jpg" alt="" />](https://time.geekbang.org/column/article/2565)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/b6/66/b67542b632fe4f1c74e08f25bc009b66.jpg" alt="" />](https://time.geekbang.org/column/article/2625)
|
||||
|
||||
## 数据科学家套路
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/f8/9c/f8b466ed45fe7fbf75f212963a4fe39c.jpg" alt="" />](https://time.geekbang.org/column/article/10801)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/cf/eb/cf35a602d9f2098a811d84b967fe82eb.jpg" alt="" />](https://time.geekbang.org/column/article/10972)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/13/92/1346bc162e74628b092a17a68ccc5d92.jpg" alt="" />](https://time.geekbang.org/column/article/11307)
|
||||
|
||||
## 数据科学团队基础
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/59/8a/59dd0b56af51be5fc0d555bcb917e88a.jpg" alt="" />](https://time.geekbang.org/column/article/13471)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/2d/06/2d2d84f857385eca986259266baa9f06.jpg" alt="" />](https://time.geekbang.org/column/article/13665)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/69/9c/6937b4105045252168b7f17911aaf69c.jpg" alt="" />](https://time.geekbang.org/column/article/13816)
|
||||
|
||||
## 数据科学团队招聘
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/6c/0c/6cae27e473c86e9f92a3c2552a22a80c.jpg" alt="" />](https://time.geekbang.org/column/article/3261)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/86/34/8603206014689249a8062387d84c7e34.jpg" alt="" />](https://time.geekbang.org/column/article/3361)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/ab/ae/ab015415d9b2b5ab2a448e2e5eae02ae.jpg" alt="" />](https://time.geekbang.org/column/article/3614)
|
||||
|
||||
## 数据科学团队高级话题
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/f5/f3/f5d35ee1d6aeb18c6a252db42215faf3.jpg" alt="" />](https://time.geekbang.org/column/article/156)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/a1/e3/a11e61cf408dd59e11f7e8f2a407a7e3.jpg" alt="" />](https://time.geekbang.org/column/article/3744)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/bd/fd/bd16eef4d26c147ee731eb50d5d604fd.jpg" alt="" />](https://time.geekbang.org/column/article/3909)
|
||||
|
||||
## 著名数据科学人工智能团队漫谈
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/00/ad/00d19818186b073dab6b0a248b24a8ad.jpg" alt="" />](https://time.geekbang.org/column/article/379)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/8b/60/8b808afc90cad6fd25f6280ef180ef60.jpg" alt="" />](https://time.geekbang.org/column/article/40617)
|
||||
|
||||
[<img src="https://static001.geekbang.org/resource/image/30/50/30336b4409f71aef67c710bafd5f0e50.jpg" alt="" />](https://time.geekbang.org/column/article/40765)
|
||||
|
||||
## 积跬步以至千里
|
||||
|
||||
最后,恭喜你学完了这个模块的所有内容。不管你是一名数据科学或人工智能的初学者,还是已经积累很多宝贵的经验,亦或要组建自己的数据科学或人工智能团队,都希望这一模块的内容对你有所帮助和启发。
|
||||
|
||||
学无止境,选择了人工智能这条路,就意味着我们选择了一种生活方式。今天就让我们以几句诗结尾,作者是我很喜欢的美国诗人罗伯特·弗罗斯特(Robet Frost)。
|
||||
|
||||
Two roads diverged in a wood, and I—
|
||||
|
||||
I took the one less traveled by,
|
||||
|
||||
And that has made all the difference.
|
||||
|
||||
树林中分出两条路,而我——
|
||||
|
||||
我选择了那条少有人走的路,
|
||||
|
||||
从此一切与众不同。
|
||||
|
||||
欢迎你给我留言,和我一起交流讨论。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user