天猫推荐算法团队的那些事儿

天猫技术部算法组是一个相对比较新的团队，刚刚成立一年，目前有 10 个算法工程师和 5 个开发工程师。这个团队所负责的内容是天猫上的数十个推荐产品，这些推荐产品帮助消费者找到他们喜欢的东西，将用户跟商品匹配的路径缩短。当然对天猫平台来说，推荐算法的价值在于提高转化率。从去年的双十一开始，天猫技术部推荐算法组第一次将推荐产品引入到了双十一大促活动当中。

2014 年，阿里巴巴集团举办了阿里巴巴大数据竞赛，大赛的规则、题目、比赛数据、评价标准与评审，都是由算法组负责。最近，InfoQ 中文站采访了这个团队的负责人张奇（得福），了解天猫推荐算法组的团队情况与工作内容。

嘉宾简介

张奇，花名得福，2010 年毕业于中国科学技术大学计算机系，信息检索方向博士。2010 年7 月加入阿里云计算， 搜索广告组，从事搜索广告算法研究，参与Yahoo 中国搜索中搜索广告的排序算法设计，负责了国内最大规模之一的，每天近40 亿网页浏览记录的挖掘、用户行为分析和User Profile 建模。2012 年3 月加入天猫产品技术部，推荐算法组，负责天猫推荐算法的改进和数十个推荐业务的优化，包括PC 推荐业务、无线推荐业务，建立起一套基于机器学习的推荐算法流程。

InfoQ：简单介绍一下天猫技术部推荐算法组的职责和团队分工？

得福：推荐算法和搜索、广告系统类似，很多模块之间都有上下游关系，如分析用户偏好兴趣，采集用户点击、购买行为，计算用户现在想买什么，比如想买连衣裙还是 t-shirt，连衣裙是日韩风格还是欧美风格。还有的组做排序，比如有一堆的商品，连衣裙，天猫有几十万款连衣裙，给用户看什么？这就需要先做品牌、价位的筛选，再有个性化排序，给每个商品计算分数，通过预测点击率、购买率，来给候选商品做重排序，这样选出 10 个、20 个商品给用户看。另外还有一些固定的物理属性，如用户的性别、收入水平等。每个模块都有上下游关系，不同的人做不同的系统。每个推荐流程都有用户行为分析、商品检索、个性化排序、返回前台的过程。

产品上来说有不同分工，我们这边也是 PM 制度：比如一共有 40~50 个推荐产品，如果有新的产品要开发，就需要 PM 来协调上下游的模块的同事一起去完成。PM 跟运营或 PD 沟通需求是什么，需要我们怎样支持，需求怎样拆解成现有的推荐算法能够支持的模块，然后安排各个模块的同学去开发，还要监控上线之后产品的效果，效果好或不好，有数据报表，不好有改进意见。每个产品都要有同学去负责。

整个推荐分商品推荐、品牌推荐、活动这三种，如果一个同事对某种类型比较熟悉了，跟对应的业务方也非常熟悉了，可能他就专门把这个类型的产品负责好。商品推荐比较广泛，推荐比较多，就要分给不同的同学。总体来说，这一块在系统上是横向的划分，业务上是纵向的划分。

InfoQ：你以前做的是阿里云搜索。搜索和推荐产品上从算法和产品的角度来看，差别大么？

得福：算法和产品都不太一样。算法方面，搜索是处理带有明确意图的 query，很多工作都基于对 query 的理解上面，包括 query 怎么分词，如何抽取有用的信息，包括品牌、商品型号、类目等，就是通过 query 的关键词抽取来反映用户意图，然后做查询、排序。推荐的话，用户不会输入 query，他们用自己的行为表达自己的兴趣。对我们来说这更困难，你要从非常多的行为里把用户的兴趣抽象出来，我们需要做很多用户意图理解的模块。这是两者在算法上最大的区别。

产品方面，搜索是一个通用系统，固定的产品形式就是有一个框。推荐的产品可以有很多变种，不同行业也不一样，比如服装可能是基于风格、搭配来推荐，书籍、音乐则是另外一种推荐方式，比如书籍要考虑话题、类别、知识水平，所以比搜索来说，产品形式会更加复杂。

InfoQ：验证新算法会有 AB 测试吧？怎么做的？

得福：我们的测试有两种，一种离线测试（线下测试），一种线上测试。一开始我们都做线上 AB test，你拿 5% 或 10% 的流量供测试，95% 或 90% 的流量作为基准，然后你可以做参数变动或算法调整。这是以前。后来我们考虑到，因为同时会有很多算法想要做测试，一方面流量有限，而且对天猫来说流量是非常值钱的，每个用户可能只有 20 分钟或者 30 分钟，所以一个算法如果未经验证就到线上做 AB，其实是很浪费流量的，对用户的体验也不好，5% 或 10% 的用户可能会使用一个非常差的版本。

所以渐渐就开发了一套离线评测方法，不需要线上流量就能测试：它用以前的日志去模拟现在的行为，相当于把日志作为模型的输入，看不同版本的算法在日志上跑的结果怎么样，来判断这个东西放到线上后大概的效果。这种系统不会 100% 准确，离线结果 A 比 B 好 10% 并不表示在线上也是 10%，但一般如果离线显示 A 比 B 好，那到线上 A 一般也会比 B 好，好多少不一定。我们用离线方法就可以淘汰很多不太靠谱的算法——A 如果比 B 明显要差，我们就可以去掉。只有 A 比 B 好，我们才拿到线上测，保证流量能够被充分利用。另一个好处是，离线测试十分快速，因为处理日志跑起来是很快的，可能十几分钟就跑完了很大的用户量，而线上一方面流量少——不可能切换太多过来，同时你需要看很多天，效果才能稳定下来，可能需要一到两周才能看出效果。

所以这两个方法现在我们同时在用，互相补充。

InfoQ：天猫算法跟产品相关性比较大，会有很多跟产品的沟通。而你们也在产品开发更下一个层面。跟 PM、PD、运营的沟通模式是怎样的？

得福：PD 是我们的需求方。PD 冲在最前面，跟业务靠的比较近，甚至会跟业务绑在一起。PD 去了解业务的需求，然后提前跟我们交流需求是否合理，如果合理且我们能接受开发量，就回去写 PRD、MRD 这种文档。这可能会涉及很多个开发团队，就要把开发团队的工作量、时间都安排好，最终确定一个上线时间。

一般 PD 会先写 MRD，证明该产品需求是合理的。再写 PRD，对产品进行详细的功能描述，分哪些模块，谁来开发，都要涉及。最后会有 PRD 评测，所有相关方都会到，如果有意见会让 PD 去改。如果大家觉得 OK，PD 需要指定 PM 和最终上线时间，如每个团队在哪些时间点要提供哪些接口出来，测试时间等等。

InfoQ：你们在去年完成了多少项目？

得福：我们不是按照项目的个数来算工作量。我们总体的评价是，通过推荐帮天猫带来多少成交，这是我们最重要的指标。这些指标的实现过程有很多小项目累加，包括新项目的开发和老项目的优化，目的都是提高转化率，不会拆的那么细。

其他具体的方向也有一些，比如无线的产品创新做的如何，或者大赛的支持等等。

InfoQ：你在去年最值得分享的成就是什么？

得福：双十一。去年是我们第一次在双十一尝试这种千人千面的推荐方式，而不是纯卖场的方式，我们是第一次做这种尝试，也突破了很多阻力。当时开发非常辛苦，也不是很高科技，很多跟运营一起的工作，数据都是 excel 来传递，自动化系统都没有准备好，因为系统没有打通，所以很多人肉的工作，非常痛苦。那段时间加班很多，容易出错，很多时间用来做协调的工作，不过最后效果还是很好的，转化率比原来那种卖场方式能提高 10%~20% 左右，给业务带来比较多的价值。

InfoQ：转化率是对整个团队的考评。对于每个人的考评，你们是怎么做的？

得福：我们对工程师个人的考评主要分三个部分：1、业务推动，比如承接了哪些新产品开发，在过程中起了什么作用，是 PM、模块开发还是数据报表开发等。如果作为 PM，对推动业务做了什么，比如老业务上去可能效果并不好，你是否通过一些主动的行为——如改变产品形式——来把它的效果提升。这是很大一块。2、技术工作，如你在这段时间有没有算法方面的创新？数据结果有没有做产品化、工具化，把之前做的工作总结、凝练、抽象出来，让别的同学也可以去用？3、团队贡献，如你是否做了一些对其他同学支持、分享的工作。这个跟前面两个也有关系，相当于是从前两个部分中抽取出跟团队支持相关的内容来进行评估。

InfoQ：任务的分配是指派的，还是大家可以自己选择感兴趣的方向？

得福：一开始肯定是指派的任务。到你熟悉整个业务了，或者对某个方向掌握非常好了，就会放手让这个同学去做某一块的业务，不需要 team leader 去管。一般可能需要半年时间。

InfoQ：你们的团队招聘主要是什么渠道？

得福：我们的社招不多，应届生和转岗比较多。对应届生，如果是研究生，我们要求他要么是工程能力很好，项目的深度、广度掌握的比较好，跟我们的方向比较一致，要么是研究做的比较好，论文质量高。社招的话，因为他有经验了，我们主要要求他的经验跟我们的方向比较一致，同时他在之前公司做的结果比较好，做成功过一些项目，对项目细节和全局都能掌握的比较好，算法能力也比较好。我们对社招的要求比较高，名额也紧张，通过率比较低。

InfoQ：对这次的天猫天池算法大赛有什么期待？

得福：其实我们以前没想过这个比赛会做的这么大，原来我们只是觉得好玩就行了，在小圈子里面有兴趣的同学来一起玩，加强算法交流，也没有想限制在学生的范围，而是希望其他公司的同学也可以来一起玩，通过这个比赛加强交流，也认识认识其他公司的团队。

后来这个比赛做大了，做到集团层面了，整个集团层面可能希望有一些校招的效果，对我们来说也是更好的事情。如果有很好的学生愿意过来，我们当然非常高兴。不过我们更希望大家更纯粹的在这个平台上进行比赛。