透过腾讯张潼离职事件，看AI研究院如何才算成功？
作者 | 洪亮劼
编辑 | 琥珀
【AI科技大本营导读】近日腾讯 AI Lab 第一负责人张潼博士的离职事件，让不少圈内人士对企业 AI 研究院/实验室的定位、落地能力等问题进行了深刻思考和讨论。据最新消息，张潼未来将回到学界，继续 AI 领域的学术研究；腾讯 AI Lab 继续在前沿技术与研究上的探索。
这不禁让人回想起 2017 年 3 月人工智能和机器学习领域著名科学家吴恩达离开百度时的情景。吴恩达加入百度三年，期间担任百度首席科学家，负责百度研究院的领导工作，其中就包括名噪一时的“百度大脑”计划。作为百度曾经的二号人物，当年中国科技界重要的外援，不少机器学习爱好者的入门导师，吴恩达离职的消息让人慨叹……
从学术到业务，二者不同，一个指标是发论文，一个指标是业务线上的落地情况。在国内，从百度深度学习实验室、阿里巴巴达摩院，再到腾讯 AI Lab、优图实验室，华为诺亚方舟实验室等，各大互联网公司现都在构建、不断调整内部的前沿技术相关的研究机构。那么，究竟什么样的人适合领导企业的研究机构？企业又该赋予该研究机构怎样的属性和使命呢？
本文摘自 2017 年 4 月 9 日洪亮劼的博客《论互联网公司和研究院》一文。洪亮劼，Etsy 数据科学主管、前雅虎研究院高级研发经理，长期从事机器学习、大数据分析、个性化系统架构的研究。
正文：
随着吴恩达离开百度研究院，关于互联网公司设立研究院的话题又被推到了风口浪尖。一时间，大家对互联网公司到底该不该设立研究院、研究院在公司内部又该起到怎样的作用、怎么能够设置一个有效的研究院架构、怎么来衡量研究院是否成功等问题展开了激烈的讨论。我打算在这篇专栏文章里，以本人在雅虎研究院的经历为基础，来剖析一下现代高科技企业尤其是互联网公司如何设置一个成功的研究院，研究院究竟该如何运作。这篇文章是在公开领域少有的论述研究院的系统性文章，值得大家精读。
什么是研究院？
在我们讨论其他话题之前，我们首先来看看目前互联网公司的各种研究院有什么特征。怎样的团队就算是一个「研究院类型」的团队（因为有一些公司并不直接单独称这些团队为「研究院」）。我们这里总结下面这么一些特征:
▌特征一：以博士为核心组成的团队
大多数研究院的核心人员，甚至是全部研发人员都具有博士或以上（含博士后、有教职经验）研究经历。这个特征是因为很多研究院需要解决的问题或者研究的方向是产业的前沿，的确需要有掌握高级知识的人才进行研发工作。然而这个特征也直接导致了很多其他问题，那就是一个以博士为核心组成的团队和其他团队来比较，有一些其他团队所不具备的特点，为管理工作带来了额外的挑战。
比如，很多博士习惯做长期项目（三个月以上甚至更长）。这些研发人员很不习惯更换项目，而且博士对于项目就像是研究课题，有个人的归属感和荣誉观，这是好事也是坏事。再比如，博士希望有比较长期的职业规划，对于自己的研究方向希望能够有所延续，能够参加学术会议，能够发表论文。这些需求都是其他一般的研发团队一般不具有的。如果一个研究院的管理层不能正视这些需求，则很难形成一个有很强创新力和执行力的团队。
▌特征二：相对比较独立的运作环境
尽管我们后面要提到，很多研究院都和产品部门有或多或少的联系，有时候甚至和产品部门有密切的合作，但绝大多数研究院，都需要有一个相对比较独立的运作环境。
比如，研究院是一个独立的团队，有自己部门的领导（而不是工程部门的兼任），有自己部门的单独预算，有自己部门的 Key Performance Indicator（KPI)，有自己部门的组织结构和运作模式等等。这些都是建立一个研究院独立的形象。而且，也由于我们刚才提到的第一个特征，也就是研究院以博士为核心的特点，一个相对独立的运作环境有助于管理这一个可能和公司其他部门组成结构非常不一样的人群（因为这个人群的需求可能很不一样）。
▌特征三：研究院不是产品部门
绝大多数研究院作为一个独立的运行实体都不直接掌管（Ownership）产品线。研究院可以作为产品部门的协作单位，但大多数成熟的研究院均不直接运作产品线。一个简单的原因是，产品线的研发和运作与研究院的目标是不完全一致的。那么这一点特征，可能会带来研究院在管理和定位上出现问题。我们下面会提到研究院的目标中就要来分析一下，在不掌管产品线的情况下，研究院如何能够保持其在公司内的影响力。
上面三个特征只是研究院诸多特征中的代表。然而我们已经可以看出，研究院在现代互联网公司中的一个比较特殊的地位：人员构成、运作模式、需要为产品做贡献但又不是产品部门。正是因为有这些特点，成功运行一个研究院对于现代高科技企业来说，是一个巨大的管理挑战。
研究院的目标
什么样的公司需要研究院呢？要回答这个问题，我们必须要来看，什么样的产品需要研究院的支持。有两类产品很适合搭配研究院：
比较成熟的产品
和公司现在产品线没有太大关系的前沿产品，有时候也叫「打月亮」（Moonshot）产品。
我们先来说说为什么「比较成熟的产品」适合搭配研究院。成熟的产品，已经有了比较成熟的数据链条（Data Pipeline)，能够使得基于数据（Data-Driven) 的研究工作有了可能性。而目前几乎所有的前沿研究，包括机器学习（Machine Learning)、人工智能（Artificial Intelligence）、数据科学（Data Science）等都无一例外非常强烈依赖于大量的数据。没有数据，绝大多数这类研究都没法进行。早期的产品并不具备这样的条件。
比如，产品部门需要推出一款新的手机应用（App），而如何这个应用有比较多的功能之前并没有在公司其他产品中存在过，那么研究部门很难进行基于数据的研究工作。成熟的产品，也有相对比较成熟的衡量指标（Metrics）。这一点对于数据驱动的研究来说额外重要。因为有了衡量指标，就能够围绕这个指标展开特定的研究工作，设计相应的模型和算法，提出合理的优化解决方案。比如，当前的产品是搜索引擎，那么研究院就可以针对搜索引擎的成功衡量指标进行建模，更新搜索排序算法等等。早期的产品一般也没有固定、和合理的衡量指标，这会让大多数的研究工作一筹莫展。当然，研究院可以帮助产品部门建立衡量指标。不过这也是一个需要一定时间的过程。在这个过程结束前，其他的研究工作很难进行。
我们再来说说为什么和现有产品线没有太大关系的前沿产品也是比较适合搭配研究院的原因。我们刚才提到研究院的特点的时候说到，绝大多数研究院都是相对比较独立运行的团队或者机构。这个特点就非常利于研发前沿产品。前沿产品因为其高失败率的特点并不适合普通的已经有成熟产品运维压力的产品部门进行研发。
同时，前沿产品的「前沿」特点也使得研究院成为这种类型产品研发当仍不让的选择。另外，前沿产品一般并没有一个特定的产品公布时间表。这和前面所说的「非成熟」或者早期产品不一样。早期产品，尽管没有数据，没有成功指标，但往往有惊人的产品公布时间表，产品上线压力很大。而前沿产品，虽然也没有数据，也没有成功指标，但一般没有上线压力。这也就给了研究院自由空间去收集数据（比如 Google 的无人驾驶车），定义成功指标，进行迭代。当然，从这个角度来看，这也直接导致了，前沿产品的研发周期非常长，而且也很难去定义其上线的时间，于是成为其失败率高的部分原因。
在我们了解了什么样的产品比较容易搭配研究院以后，我们再回到最开始的那个问题，「什么样的公司需要研究院」。如果一个公司的产品线相对还不稳定，很多产品处于快速迭代的状态下，这个时候，这样的公司其实并不太适合建立研究院。因为绝大多数产品线都没法真正「享受」到研究院的成果。如果一个公司并没有足够稳定的内部环境和财务基础，那么这个公司也就没有研发前沿产品的基础。那自然这样的情况下，配置一个以研发前沿产品为导向的研究院就更加显得没有必要。基于这样两个原因，绝对多数的初创公司，或者其实说，在上市前的初创公司都并不真正具备配置研究院的内外部环境。只有相对比较稳定的公司才有对研究院真正的需求。
值得注意的是，我们也可以从这里关于研究院和产品线的讨论引申得到这么一个结论。因为研究院最大的功效是在对成熟产品的优化和改进上，以及对前沿产品的研发上，要想依赖研究院对一个公司的商业模式进行创新，或者寄希望研究院对快速迭代的产品产生贡献使得公司进入高速增长期都是不可能完成的任务。这些不切合实际的初衷往往给研究院的定位和发展带来困境。
从另一个角度来说，那就是研究院可能对公司的长期商业运行可能会有比较大的影响（比如一些前沿产品如何研发成功），但在中短期来看，影响是相对比较有限的、是渐进式（Incremental）的（主要来自于对成熟产品的优化）。
研究院的架构和运行
在我们了解了什么样的产品需要研究院，什么样的公司需要配备研究院以后，我们现在就来探讨一下研究院的架构问题。
我们上面提到了研究院在公司内部需要有一定的独立性。但是，现代高科技公司，毕竟从根本上来说还是追逐利润的企业，如何来确保研究院能够从长期上是符合公司发展的利益呢？这一点，是研究院生存的根本。
从历史上来说，早期研究院很多都是这么一种运作模式：
研究院的科学家针对某个技术难题（这个技术难题有可能是来自产品工程部门，也有可能是研究院的科学家自己发现）找到了一种解决方案，形成一个研究成果。
根据不同的研究院的情况，科学家可能会选择发表研究成果，形成论文，或者是申请形成专利。
科学家根据这个研究成果做出一个解决方案的原型（Prototype）。
研究院团队根据解决方案的原型，到产品工程部门进行游说。产品工程部门根据自身的需求和产品周期，决定是否要把目前的原型重新在工程中实现，从而在下一代产品中使用上这个新成果。
产品工程团队和科学家一起把原型在工程代码中重新实现。
这个模式看似有一定道理，但也存在一些非常关键的问题。
首先，第（1）步中就直接存在可能导致第（4）和第（5）没法发生的诱因。我们假设研究院的科学家拿到的技术难题是来自产品工程部门的。从现代产品的角度来说，一般的产品工程迭代都非常快。现在的技术难题可能几个星期后就有了能够解决 80% 问题的解决方案。也就是说，研究院拿到的技术难题有可能是有时效性的。这并不代表这些技术难题随着时间都有可能被解决，而是说，随着时间进程，很多技术难题可以出现多种解决方案。科学家能够找到的比较完美的解决方案（姑且假设能够 100% 解决问题）需要（2）-（5）这些步骤进入产品，这必然导致产品部门必须在科学家方案推出之前找到可以运行但很粗犷的方案。
然而这种方案一旦进入产品，就会成为日后科学家的完美方案进驻的强大阻力。因为产品工程部门会觉得，在产品已经进一步迭代的情况下，是不是有精力和时间去改进一个已经可以运行的方案为更加完美的方案，其实是一个很棘手的问题。这也就会导致步骤（4）常常非常政治化（Political），成为各个团队扯皮的重要原因。刚才说的，还只是假设研究院的科学家拿到的技术难题是来自产品部门的，还有很多情况是，科学家或者研究院自身认为某些技术难题需要得到解决。这样发展出来的研究成果或者产品原型往往就更加难以通过第（4）和第（5）步得到产品化。
因为第（4）和第（5）步的不确定性，很多研究院在发展过程中，往往把第（2）和第（3）步作为绩效评定的重要结果。这也就导致了很多研究院的成果只能完成第（1）步到第（3）步这个流程。而第（4）步成为了研究院成果产品化的不可逾越的鸿沟。
那么如何运作研究院能够跨过这个鸿沟呢？
雅虎研究院在过去 10 年的时间里对这个问题有着不错的实践经验。这里的核心问题就是如何把研究院的目标和一般产品工程团队的目标统一起来，使得大家对于产品的开发和运作是同步的。我们这里要提到这么一个概念，那就是「共享目标」。什么意思呢？那就是研究院和产品工程团队虽然从行政上隶属不同的部门，但在项目开发上，两个团队必须组成一个「虚拟团队」，有统一的领导和统一的进程管理，并且执行统一的、共享的目标。研究院和产品工程团队只是在这么一个共享的、统一的目标下分工不一样，责任不同而已。
具体说来，以笔者参与过的雅虎首页推荐系统为例。
产品工程团队每个季度都会和研究院的研究团队一起指定目标。这个目标是一个 综合性目标，有产品的部分（比如提高多少用户访问、提高多少用户点击），有纯工程的部分（比如如何加快代码部署），有研究的部分（比如应该采用什么模型来达到用户访问的提高、比如应该怎么加快模型的训练速度）。那么，「虚拟团队」就会根据这个综合性的目标来分配资源，确保整个团队的工作量和各个方面的目标达到一个不错的平衡。目标共享以后，研究院的研究周期得到了明确，也就是每个季度。同时，研究院的「成果落地」得到了保证，那就是直接和产品对接，每一个季度都需要「上线」。这种模式下的研究院团队，也不会去做「天马行空」的项目，而是仅仅围绕产品工程，做很多「增量式」的创新工作。
「共享目标」对于雅虎的很多产品决策过程以及运作过程产生了深远的影响。首先，那就是采用「共享目标」架构的产品全责更加清晰，工程负责什么，研究院负责什么，设计师负责什么，每个季度这几个方面一目了然。另一个非常显著的改变，那就是这些产品第一次把 AI（这也就是研究院往往负责的部分）、工程以及设计三个方面作为一个产品每个季度推进的三个主要方面。也就是让 AI 成为了产品的目标的一类公民。
那么，「共享目标」是不是就解决了研究院的运作问题了呢？答案是，不完全是。首先，「共享目标」听上去容易，但在实际运作中难度其实还是很大。这里面最重要的是信任问题。从公司结构上来说，产品工程团队往往对产品有「所有权」（Ownership），自然希望能够对产品的方方面面有所把握。然而在「共享目标」的框架下，实质上发生的则是，研究院对于产品的部分方面有了一定的决策权和执行权，这势必需要产品工程团队的领导和人员对于这方面有足够的认识和预期。实际上，从另外一种角度来说，这种「共享目标」其实就是产品工程部门把部分产品开发方面长期外包给了研究院的团队。雅虎的产品工程团队能够和研究院针对某些产品这么做，是因为研究院长期以来能够对这些产品持续做出不俗的贡献，赢得了信任。但并不是所有的产品都能够在这样的框架下运作。
同时，因为和产品工程达成「共享目标」，这势必也就造成了研究院的研究目标和成果相对比较「短视化」，常常迎合了产品周期。这也就呼应了我们之前提到的，比较适应研究院的一类产品，那就是成熟产品。实际上，「共享目标」的模式很好的契合了成熟产品的迭代。
对于前沿产品来说，这样的架构显然不太适用。因为这个时候产品和工程组可能都还不存在。对于这样的项目来说，最好以研究院的科学家为核心，然后辅以工程师作为支持。从某种意义上来说，这依然是一种「共享目标」，不过则是之前谈到的相反的结构。
研究院的成功
之前已经讨论了研究院的架构和运作，那么，我们怎么能够保证研究院的成功呢？我们这里谈两个比较显著的问题。
第一个方面那就是研究院需要怎么样的领导。
这个问题看似很简单，其实需要相当认真的思考。因为研究院需要负责招聘大量的博士层次的候选人。因此一个有声望的、在学术圈有一定地位的人担任研究院的领导势必会对招聘起到很大的帮助作用。同时，因为对于具有博士文凭的研究人员的背景更加熟悉，有学术背景的领导往往更加能够制定人性化的管理方案，让这些博士觉得能够放心工作（比如对于参加学术会议的鼓励，比如对于发表论人的支持等等）。相反，如果这个领导只有工程背景或者是产品背景，即便是以前公司内部的高管，因为背景的差异，除了在招聘方面可能会遇到困难以外，在日常的管理上也可能无法往往都很难胜任研究院领军人这个职务。
然而这方面的反面，则是从学术圈里直接挖来一些知名教授，来领导研究院。这里面有一些公司希望能够通过教授名气来吸引眼球的目的，而另一方面，也是希望知名教授能够带来招聘上的便利。不过，这样的行为往往忽视了这些知名教授在学术圈的日常运作和公司运作的巨大区别。就算是知名教授，不少人也很难直接管理超过十个学生，而在大公司，特别是研究院这个级别的组织中，管理超过几十人甚至上百人，并且有可能管理其他的中层领导，那么丝毫没有经验的人往往没法胜任这样的复杂协作分工管理。同时，没有公司经验的教授也往往无法在很短时间内领会到现代企业文化（比如晋升、比如公司政治、比如资源协调），能够为自己的团队在众多的团队的合作与竞争中谋取相应的利益。
因此，比较合适的研究院的领导是至少有一定工业界经验，但可能早年在学术圈或者学校任职的优秀科技管理者。比如雅虎研究院的第一任领导 Prabhakar Raghavan，就是这样一位人物。首先本人就是知名的学者，出版过知名教科书《Randomized Algorithms》和《Introduction to Information Retrieval》，并且是 ACM，IEEE 的院士，也是美国工程院院士。同时，其在加入雅虎之前，已经在 IBM 研究院以及 Verity 任职多年，特别是 IBM 的经历，让他对企业文化和工业界的研究机构有了很深的了解。可以说 Prabhakar 到雅虎之后很快就能建立起一个非常有效的团队，吸引了一大批的知名学者诸如 Andrei Broder、Ricardo Baeza-Yates、Alex Smola 等的加入，这和 Prabhakar 本人的背景可以说息息相关。同时，我们之前提到的关于研究院的运作规律，这其中有很多都是 Prabhakar 总结了他在多个组织的任职经验以后，在雅虎慢慢发展成熟起来的。
第二个问题就是公司上下一定要对研究院究竟能给公司带来什么样的价值有一个清晰的判断。
从我们刚才的一系列论述来看，研究院虽然在很多产品的研发中占有举足轻重的地位，但总体说来在公司是还是一个合作者的角色，是一个锦上添花，而非雪中送炭的角色。从这一点说来，整个公司的管理者和运行者要十分清楚。不过我们也要防止把研究院的价值庸俗化或者完全以产品成果为唯一的衡量标准。比如 Google 收购了位于伦敦的 DeepMind 团队来做深度学习的研究工作。DeepMind 最近几年的研究成果，外加炒作的沸沸扬扬的 AlphaGo 究竟直接为 Google 的线上产品带来了多大收益恐怕很难直接衡量。但是 DeepMind 引领的这股深度学习的风潮，让 Google 在吸引这方面的人才这一方面则形成了巨大优势。这部分为 Google 节约的公关广告成本或者招聘陈本应该很容易就能覆盖对 DeepMind 的运营陈本。
同时，DeepMind 的成果，虽然很多不能直接应用到 Google 的现有产品上，但是 Google 的领导人借着这股风潮，让公司更多的工程师和产品人员开始深度介入深度学习领域，在内部进行了很多培训和推广工作，也是利用 DeepMind 这个研究团队来达到了原本不容易达到的目的。当然，从长远来看，研究院还是需要从产品和视角（Vision）上为公司带来价值，而且这些价值是普通研发团队所不能带来的。
总结
我们在这篇文章里详细讨论了什么样的互联网公司需要研究院，研究院又适合在什么样的产品线上发挥作用。我们还在这篇文章中深入剖析了研究院的研发团队如何和一般的产品工程团队合作，能够为现在成熟的产品线或者是前沿的产品的研发提供有力的支援。最后我们谈了一下制约研究院成功的两个关键的因素。本篇文章是第一篇比较完整得系统性阐述互联网公司以及研究院制度的文章，希望能够起到抛砖引玉的作用，让大家更加深入思考如何让研究机构在现代企业，特别是高新技术企业中生根发芽。
原文链接：http://column.hongliangjie.com/管理/2017/04/09/research-labs/
（*本文仅代表作者独立观点，转载请联系原作者）
公开课预告
◆
全双工语音
◆
本期课程中，微软小冰全球首席架构师及研发总监周力博士将介绍微软小冰在全双工语音对话方面的最新成果，及其在智能硬件上的应用和未来将面临的更多技术产品挑战。
推荐阅读