「专访」Kegokang：往深的钻、广的看，才能更近一步

编者按：Kegokang(康战辉) ，2011年加入腾讯，自毕业以来一直从事与搜索、数据挖掘、广告等业务相关的算法优化工作，目前任职于AI 平台部搜索业务中心，自评要不断保持自我学习，具有敢于超越的勇气，才能朝某一领域的专家精进。

在本次《TEG通用大课堂 - 技术人生》栏目对Kego2小时的专访中，Kego时常 “自带主持”节奏，让现场氛围非常活跃，对待每个问题都会很开放的给予详尽的解答。他的“好学”，“对技术不断钻研、勇于反思”以及“工程思想的精彩诠释”给大家留下了深刻的印象。

01 - 目前AI平台部搜索技术对公司哪些产品有提供支持/服务的？

Kego：

主要有微信搜索，应用宝APP市场的分发和商业广告，还有QQ音乐，腾讯视频等搜索，是通过数据挖掘跟业务方有新的结合，因为现在的search都是以search加推荐的方式来应用，这是外面目前看的到的产品，还有跟其他部门新产品合作，关于一些问答，智能音箱之类的。

02 - 你对Pattern的具体理解是？

Kego：

我的理解应该是一个所谓的特征里面的强特征，是可以直接拿来就work的，在不同的业务不同的场景是不一样的，可以认为是一些所谓的规则，或者规则、经验的泛化，这个泛化是比较精准的、高质量、比较头部的，就像很多时候我们人类的经验。通常我们用if else能cover70%的问题，还有30%cover不住的情况太多了，就像一棵树一样，不论树多大，开始从根节点分得话不管是人分还是机器分问题都不太大，但再往下树枝分岔越来越多，要参考的特征也越来越细，需要用一些机器的方式，例如可基于统计/概率模型去做，做完之后可以解决80%的问题，还有20%的问题由于它的语义特征不能通过特征工程有效抽象出，现有数据模型就cover不住了，可以考虑用神经网络去学习这些隐含的中高层语义特征，这样神经网络模型又可以解决10%，也就差不多将近90%的问题能解决掉，剩下10%可能还是解决不了，需要通过整个系统里的其他模块来兜住。

拿同义词举例，同义词的挖掘准确率不论怎么做可能只做到80%-85%，做不到90%没关系，因为是一个大系统，同义词这个模块解决的不够好，可以通过其他模块来弥补。做一个系统，策略，算法，基础研究都相当于织网，把网织的越密，漏下要解决的大CASE就越少，可以通过很多角度解决互补，因为做基础研究是基于数学，基于概率，基于统计去做，不可能做到100%，因为它不是一个功能系统，只是一个大概率的问题，一定会By case 基础研究跟工程其实是很难分开的，如果把基础研究细化到比较小的力度，例如：处理一个特征、处理一个数据，就是一个工程问题。再往大走尤其是往精细化方向努力，会发现需要很多工程思路和方法。比如：要有头部思想，首先分析问题的占比是怎样，头部问题解决完再到后面长尾问题，这个解决就要有工程化思路，建立一些工程化的系统机制，就是所谓的运营。不断了解做这件事对线上系统的影响，哪些变好，哪些变坏，整体情况是否可控，因为需要再进一步优化。头部问题土方法也能解决50%、60%，好点的方法解决80%，不管怎样都是在解决问题。往后走就不一样了，可能新引进一些东西帮助解决了一部分问题，但同时另一部分出问题了。所以要把监控，无论是线上运营监控，case监控跟运营结合起来，不仅出系统运营状况的一些宏观层面指标，还要精细化监控到每一个策略，每一个topic，每一个优化的方向本身在一个模块上到底是由哪个东西起作用的，哪个起的好作用，哪个起的坏作用，为什么。运营分析要和质量、基础结合起来，跟运营同事一起看，制定哪些指标有利于再精细化调系统。这个说起来都知道，做起来很难，因为这里面分的很细，宏观层面的技术指标，每个人都会提出123列出来，但是深入到系统的细节，目前运营状况是不是健康，每做一次发布是不是OK，线上的用户行为有没有发生什么变化，给出这些指标不但是看到，还要让基础技术人员帮助不断的优化，所以执行起来是比较难的。况且系统大了之后还会有一些打架现象，定期的系统梳理是必不可少的。所以我们很多人说基础研究是一个非常长期的事情，因为它是不断迭代的，尤其是到后面又要注重工程化思维去做，基础研究就是抠细节，这个是我自己工作这么多年，尤其是做一个大系统，做一个长期项目里自己总结比较重要的一点。大家也可以体会一下自己在工作中有没有遇到类似的问题以及思考角度。

03 - Kego有提到工作中抠细节，这些细节一般来自于现网问题，是平时踩坑的经验总结还是来自于什么？

Kego：

现网问题是一方面，还有我们每一个技术人员也是用户，可以从你的体验去考虑哪里会有问题，因为公司做的大部分是TO C的业务，当然你的体验代表不了大多数的，还要用到一些用户反馈以及现网用户行为数据，可以帮你梳理哪些问题目前是线上的头部问题。

另一方面就是去跟进最新的paper，因为现在基础研究方向很多东西慢慢越做越细，很多发paper解决的都是一个个小问题，定期看这些paper，比较重要的去复现，可以去研究学习一些好的idea。基础研究很多时候是一个综合体验的，尤其TO C产品很多是先有一个好的技术idea，然后有一个好的产品形态来引申出来这么一个新问题。了解了这些好的idea，才有利于把产品形态找到一个好的落地场景。因为基础研究可能跟工程不太一样，很多东西很难说所谓的需求驱动，很多时候这个落地场景产品是搞不定的，因为他不懂技术以及背后的东西，所以其实很多时候我们要发挥技术优势去影响产品也是很重要的，跟业务团队去探讨有可能有哪些好的落地场景。 过去做产品可能更多的是关注对人性的理解，考虑的是feature，不同的功能，体验，用户交互，设计出很多产品。现在随着AI技术的突破发展，大家都意识到再往下走，要有一些技术方面的革新，提出一些新东西，真的创造一些用户可能不知道自己想要什么的东西，真的去映射出一个产品形态。这就需要做技术的同事主动思考，发挥大家的想象，这个技术可以做什么事情，可能就会出来一些全新的产品。

04 - 前面有提到解决问题的工程化思想，现实中有些back case如果不和业务有深入的接触，是不能够察觉到里面有这种现象的。我从业务部门转岗到TEG，也会发现有些back case从上游到我们这边来，很多时候我们会回复说这个模型很难改的，要很长时间，差不多这层意思先顶过去让业务部门自己去看一下自己怎么去解决，Kego怎么看待这样的问题？

Kego：

作为基础研究同事跟业务合作，态度层面首先不应该去推诿，一定要去分析问题应该在哪里解决会比较合适，是我们的问题就是我们的问题，不要给业务传达出一个信息所有的东西都以变更很麻烦，动起来很复杂的理由不去解决。这样长此以往跟业务之间就会产生隔阂，他会觉得你做的不够专业，什么问题都往前面去扔，虽然我们确实也有苦衷，存在所谓的发布慢，大家角度不同的问题。

其次做基础研究同事的要对业务充分理解，这种理解甚至需要比很多产品都要强。因为很多时候产品是感性的，并没有讲出为什么要这么做，需要我们去推他，实现他背后的为什么。以做一个新闻检索系统为例，比较典型的做法是把网上所有的新闻网页都抓回来，然后搜新闻当中出的，但新闻的网页质量是参差不齐的，可能会搜出一些垃圾出来，而业务来的产品定位是想做一个高质量的，在高质量基础上再去覆盖尽量多的用户的新闻请求。实际情况是业务有这样感性的sense却未必讲出来，他可能直接说要加白名单，就出这一百个主流站点的，很多时候研发同事要去理解为什么只要这一百多个站点，如果这一百站点cover不住怎么办，这时候你要帮业务去明确他的核心痛点是什么，因为白名单只能cover头部需求，中长尾的东西就满足不了了。如果抓住解决问题的目标应该是要有高质量的东西，也要有尽量全的覆盖这个点去想办法，比如可能那一百个站点可能只能覆盖70%的新闻，30%的新闻这一百个站点覆盖不到的，在技术层面我们就把30%那些站点新闻所需要的新闻词，定向去抓他的网页，让这些网页只出这些词，这样这个站点的构成是由一百个站点所有的新闻索引去慢爬加上30%的没有覆盖词的定向的抓网页，这个集合一方面覆盖70%的词是可以出高质量的，另外30%的词也是可以出的。然后因为这30%的词代表的网页可能质量不一定可控，可以保证有新闻热点的、新闻需求的词才会出，其他就不会出，这个才是我们真正在做的时候的方案。而最初产品人员的方案可能是那一百个站点先增加，哪天网页不行了再去删掉，两个方案是不一样的，这就是我们说要帮业务领会他深层次想要什么，要深入的理解他背后的东西，这是第一层面。 另一个层面是业务同事不论业务产品、业务开发人员与我们基础研究同事之间如何协作的问题，出问题大家怎么去解决。其实TEG很多部门都是这么做的，合作一个业务产品都分层，各自做各自擅长的，我们就做我们基础的东西，不论技术的CTR预估，技术的推荐模型还是search里面大家关心的基础质量，基础的垃圾识别，有些垃圾不论所有的产品都一样的，比如色情的、反动的大家都一样需要打压，但是有一些是视乎产品策略不同大家理解不一样的东西可能就放到业务里边去做。 所以首先大家分层自己应该关注的问题，慢慢把分层磨合清楚之后，再遇到问题时先明确这个问题属于哪种问题，大家一起分析考虑应该放到哪里去解决比较好，这其中要考虑解决问题的成本，产品的迭代节奏等问题。如果问题还比较小还不凸显， case还不够典型，在我们认为还不值得要对模型有大的变更，建议可以在前端让业务先解决。但是我们要明确这个东西本身后台应该可以做什么，正常解决方案是什么，当前方案是什么，同时兼顾中长期方案怎么解决，或者我们在我们的最外面那一层解决掉。因为所有的系统就像金字塔，越往下越重，这个重是指逻辑上的重，越往下层变更速度就会越慢。 对于问题还是要有详细记录，要系统性的收集，例如2-3个月双方定期review一次，2-3个月发布一次，就可以选择在某个发布时机把这个问题合并进去，合并之后就相当于织了两层网解决一个问题。后面当慢慢发现前端越来越重了，有些东西就可以去掉了，如果不去掉，长期下去随着同事的工作变动，有些问题可能就成坑了，这个时候也需要要求业务去迭代。所以每过一段时间，大家应该要去梳理哪些问题在前端可以去掉，后面已经兜住了，这种解决问题的思路是循环往复的。不同时期我们关注解决典型问题，显著问题，彻底解决一些根源性的问题，可能会比较慢，业务是聚焦在短期的快速的解决方案，虽然两套解决方案大家的迭代周期不太一样，但最终都是要把问题重新梳理的，这是跟业务协作能够让大家能取得长期的信任与合作所必备的。一直以来TEG跟其他BG合作不是说产品推上线了就结束了，像我们跟一些业务同样一个产品都合作有三四年了，会因为不断的合作有比较好的效果，后续还会有一些新的合作机会，这也是自己跟业务这么长时间合作的一个体会。

05 - 如何看待现在很多机器学习的“调参”工程师？就是做基础研究同事拿了一些线上的模型往现有的业务上去套，然后调一些参数。

Kego：

这个事情本身很正常，过去我们用一些语言去写代码写系统，现在变成不写系统就得到一些模型参数，而且不论现在有多么好用的平台号称可以自动调优，自动调参，其实很多上面还是需要人，需要我们有经验的工程师去调的，这种岗位和这种工作形态来讲，很长一段时间都不会说这个事情是多余的，是需要有很多同事去做的。

但基础研究方向的同事对自己的要求不能仅限于此。很多计算机的算法model，最基本的来说很多业务场景能不能用这个model？是不是这一类问题？从我的角度这个不是靠试的。日常答辩的时候也会出现很多这样的情况，比如说我用了1、2、3三个model，我发现3比较好，1、2不行，我经常会问为什么？你为什么要试1、2，1、2明显就不行。就是说你是试出来的，经验主义。很多时候1，2，3，3个model你就不应该试1、2，1、2不适用这个场景，不是说你试出来1、2不对，所以1、2不行，是应该1、2就不对，不能拿1、2来用，就是因为你没有明白这个模型是解决什么问题的，你的业务场景本身抽象到去学习目前到底是分类问题还是一个回归问题是不一样的，如果明明是个回归问题，非拿分类去解决，实际上就是错的，得到效果不好是应该的，不是做出来不好所以不好，这是一个比较明显的问题，当然也不排除有一些更复杂的问题，实际上是很难去有效抽象的，尤其是一些流程会比较复杂，很难抽象出一个model或者几个model，这时候确实有一些试的成份。比如都是分类问题，到底是把它看成一个概率模型，看成一个最大商模型好呢，还是把它看成其他的比如算一个先验概率或者贝叶斯概率好呢，在这个层面有可能是要去试的。 但试完之后要问为什么最大商好或者为什么贝叶斯好，就要反思，就是不同力度，从大的层面要搞明白是什么问题，在小的层面用哪个算法，很多时候虽然经验丰富，但实际问题比较复杂，其实是很难搞清楚数据的分布情况，这种情况是要去试的。当然更好的方法是在这个模型之前去看一看它的数据分布，因为有一些通过经验是可以判断出来的，有一些它的条件不独立，用条件独立的模型去解决它是不对的，那种假设是不存在的，有些时候是不知道它的条件独立不独立，也不知道把它看成一个概率模型，看成一个最大商好，还是就拿EM去做，这个时候就要去试，试完之后要根据数据的表现去分析思考为什么。这是做基础研究方向的同事，尤其在解决一些具体的实际问题要用机器学习模型的时候，需要大家去提高的。 再往上拔的话，要真正深入到模型内部说原理说推导。因为很多时候说一些假设推导，你所用的工具里面是不会告诉你的，需要去推导它，知道数学原理在哪里才能知道它有这种假设，这个里面做了简化处理，这个地方不行，又加了RE正则或者R2正则，它这里是有要求的。比如说我们做那个SGD那个东西,后来它们又做了很多很多的变种，它里面是有很多假设的，这里面只假设一阶可导或二阶可导，它没有三阶可导，不假设三阶可导，如果你的问题是复杂问题，需要三阶可导才能解决的，这时候要根据实际问题去了解它里面有这个东西，它为什么只做二级可导，因为大部分的函数拟合，二级可导已经足够，很少用到三级可导。除非特别特别复杂的高维空间可能才会用到三级可导假设，这个地方就涉及到要去读懂里面的原理，这个是往深了走，往宽了走没有任何一个系统是一个端对端model可以解决的，从大系统到小系统，哪怕是一个明确的问题很多时候都是需要多个模型去semble出来 。 现在看到每年的各种各样学术界、工业界数据挖掘、分析领域的这种比赛，五年以前，这些比赛中特征工程团队能够获胜，最近几年变了，特征工程不行，要ensemble，model要集成，多个model融合，这是现在的潮流，大家都往这个方向走。但像facebook、amazon、Google这些顶尖公司已经不热衷这些比赛了，大家发现都是在玩模型的ensemble，没有什么创新了，慢慢变成大家有一种套路。但不管怎样，它真正在实际工作中work，所以我们就需要去考虑，哪怕一个具体问题很多时候都不是端对端的，都要把问题细化，要多种问题去考虑，要出来互补的方案，这样才能使得你的系统做出最好的结果。这里面往深了说要去懂得数学原理，再往深一步，我们最希望很多种模型真正在做的时候，要去了解里面的场景，有些推导，要根据实际问题设计出一些自己的模型。这个模型的思想是一个最大数模型的思想，但是lost function不一样，它的模型本身就是一个CRF或者一个深度学习，最后它会做一个sigmoid，这里面不论怎么做的lost function，还是各种gate这种设计，这个设计很多时候是需要真正做基础研究的一个好的工程师要具备的能力，要去设计适用自己场景的函数，这是最本质的，你能设计函数，设计自己的function，甚至能在一些训练优化算法上面有一些自己的创新，你也发可以发paper。 很多时候你会发现一些paper，它很可能就是一个传统上的model，把lost function改了，把优化算法提升了就可以发表。这个就是真正从方法论上有创新，虽然还不是公司现在想打造的创新，但实际上我们大多数时候所说的创新也就是在这个层面上的。毕竟计算机方面虽然还比较新，但是很多坑也被别人挖的差不多了，甚至有些老坑重新拿出来挖，像深度学习就是这样，你说完全挖一个新东西其实是可遇不可求的。所以做基础研究的同事要突破这个技术调参的过程，一步步往上走，这个基本能力肯定是要具有，就像现在去写一个demo，还是写一个高并发服务，只是不同的程序要求，但是都要从头开始做，往上走这个阶段也是必不可少的，但是大家要有意愿有机会有余力逐步的往深的钻，往广的看，培养更加有系统的发展思维，才能朝某一领域的专家精进。

06 - Kego从业很多年会不会有这种一直学不完的感觉，不知道你的感受是怎样的，你怎样规划自己的学习计划？

Kego：

每个人的情况可能不太一样，分享我的学习方法供大家参考。首先学习要专注，要比较早的发现喜欢做哪一方面的工作，适合做哪一方面工作，然后在此基础之上还要分两种，一种是现在倡导的碎片化学习时间，一般是晚上，花两三个小时可以用来总结总结，看一看问题，学习学习也挺不错的，我们每个人都是从毕业生过来的，刚开始毕业一两年，很多人7×12做不到，但是6×12应该是做得到的，我刚毕业一两年，可能每周六不一定都在公司，但是肯定是在学习的。 第二种是利用一些宽松的、稍微长一些时间段进行系统化的学习。相信每个项目的不论多忙也会有一段时间相对空闲，这段时间可以好好安排。比如说学习NLP方向，我会先画出来NLP方向有哪些领域，从底层的力度，词的力度，短句的力度，篇段的力度，句子的力度、文章的力度还有多文档的力度，这些不同力度会涉及到哪些技术，词力度可能有一些分词，词性标注，然后到句子的一些所谓的名词短语的挖掘、识别，包括命名实体识别，往上会涉及到语言模型，像句子力度怎么识别出一些所谓的话题句，话题追踪，舆情分析，再往上走文本方面有自动文摘，有篇章的翻译，多文档方面就更多了，我们有很多系统级的东西都是多文档层面的，search、推荐，这些都是属于应用了。当你形成这么一个知识全景图，就可以针对每个层面去系统性的学习。 我在进入NLP领域的时候，通常喜欢通过读某方面的书来系统化学习，个人觉得博客不够系统，例如：NLP领域大家读的最多的《统计自然语言处理》，我读了很多遍，每一遍读的时候都还有新的收获，会发现前面自己都有没有弄懂的或者想偏了的，建议这种经典的教材这种教材要去系统性的学习，要读多遍，再比如《数据挖掘》、《机器学习》那几本书也建议好好读一下。我们做基础研究的，同时也是程序员，开发能力是最基本要具备的，还有很多编程语言的经典书籍也是需要去认真学习的，这些书籍对于每个程序员来讲都不是只读一遍能够真正领悟到，要愿意要敢于不断的拿起来去读，这是开发方面的基本功。 经典书读完之后可能要面临很多实际问题，就要去调研paper。比如说要做信息检索，先撇开工程那些，train model应该怎么做呢，原版书里面的这一套东西比较系统但是相对也比较老，可能是十年以前的。最近十年的东西是在很多Paper里面review，你可以去search，“information retrieval review”。很多时候需要去调研，调研要有个方向，首先我们要看综述，因为很多review可能是近期一些大神写的，就是那些终身成就奖的人去写的，一般他会把近十年比较成功的一些方法论写到review，这个是比刚才教材里内容相对新一点。Review之后你就会发现这个方向有那么1，2，3，4种做法，把做法都搞明白了，就可以去试验一个系统，假如这个系统是新系统，前人没有积累，那不妨拿一些Review里面相对最好的方法去实现一个base系统，base系统最好是建立在一个经典的大家共同认可的方案上去做，先不要去做那些看起来花里胡哨的东西，因为看起来特别新的方案实际上不一定是work 的，新方案没有进入review，很多时候其实是锦上添花的，只能解决一些小问题，能够进入review的应该都是主干的，有一个比较长的脉络，然后在review里面能找出一些比较有效的方案去做一个base系统，这也是我们经常指导下面新同事做一个新的方向的做法。 做出base系统之后，在此基础之上要有base line。对于一个系统来讲，没有base line没有对比的话，是很难说清楚到底是好还是不好。除非是做0.1版，公司从来没做过业界也没做过，没有对比，那你说做的好就是做得好，但实际不是这样的，从大部分方向来讲，基本上没有碰到业界完全没有人做的，所以首先要产生出base，有了base之后就要去调研最新的方案，比较幸运的时候可能调研到很多新的方案跟你的场景是很适用的，那就可以拿过来复现他的方法。但实际工作中来讲的话，很多时候是不行的。他的场景、解决的问题，跟你的是有差异性的。当然我这里讲我们在做的时候还是要看主流，有很多新的方法在print paper里发了很多方案，其实并没有同行评审过这些东西，它的质量是不可保证的，花了很多时间搞这个东西，发现复现不了或者不对，就会浪费大量的时间，所以要去看经典的paper，尤其是顶会发布的。 NLP领域很多顶会发布的都是英文的，一个语言不会因为是中文或者是英文而在许多的议题上有太大的差别。其实在英文里面很多所谓NLP的任务跟中文是对等的，只是说中文有一些特有的东西，但基本上都是适用的。像NLP领域公认的顶会ACL，每个领域的顶会不会太多，要去找到这一领域里面最好的或者最新的东西，最新是最近三年都是有效的。去找到跟你的问题有类似性或者有可借鉴性，因为很多paper写的时候也有所顾忌，很多东西也是不会写出来，所以很多时候要去摸索，实践的。不是看到这个方法你去复现一下就能行的，实际上是不行的，首先可能问题场景不一样，再则对方不会把一些特别底层的东西放出来，很多东西也是摸索出来的。就像Google那著名的三大论文MapReduce/GFS/BigTable发出来之后，到目前为止国内也没有哪一家说能够完全做出来跟谷歌的那套系统PK、媲美的。就是因为很多东西需要在实践中摸索，光看那几篇paper只是一个原型而已。小结一下，这里面要去系统性的学习，一个新问题要去看paper review，要尽快出base，要调研新方向，新的方向要去看顶会的英文paper，建议中文的paper就不要看了，除了一些特别的比如说分词可能要看一下，因为中文的东西老外没人研究中文分词。