看阿里 AliOS 神灯团队在推荐系统上的独门秘籍

AliOS

+8

AI影响因子

企业：阿里巴巴

操作：专访

内容：专访阿里 AliOS 神灯团队

阿拉丁神灯的故事想必大家都听过，对着神灯许下心愿，你的愿望就会实现。而今天，在阿里 AliOS 有一支神灯团队，他们希望能像阿拉丁神灯一样，让用户通过其服务获得满足。团队成员王智楠对雷锋网 AI 研习社说道，「我们希望让客户拥有一种想要什么服务就能得到什么服务的感觉，这是取名『神灯』的初衷。」

神灯项目团队主要负责 AliOS 端上智能与服务的算法研发，攻克方向是推荐领域。项目组共有八名成员，大家的背景也很多元，涉及统计、广告、NLP，甚至还有心理学。

目前，他们的算法主要应用于车机智能推荐系统，例如帮助客户预测线路、推荐周边街道、关联附近的停车场、介绍好吃的餐厅等。

其中，他们自研的多层 Stacking Model 极大提升了分类预测的准确率，已广泛应用于 AliOS 多项业务。值得一提的是，年初在 WSDM Cup 2018 挑战赛上，得益于这一模型，AliOS 神灯团队小组在比赛中表现优异，团队成员王智楠也受邀在会议 Workshop 上做了主题分享。

WSDM 被誉为信息检索领域最顶级的会议之一，会议的关注点为搜索、数据检索、数据挖掘、算法设计、算法分析、经济影响方面的实际且严谨的研究，以及对准确率和运行速度的深入实验探究。每届 WSDM 都会像 KDD 一样，举办一个数据挖掘类比赛。今年的比赛的出题方是流媒体音乐公司 KKBOX（与 Spotify、Apple Music 等类似），共有两个任务，一是用户流失预测，二是音乐个性化推荐，阿里团队在前一个任务上一举夺得亚军。

雷锋网(公众号：雷锋网) AI 研习社以此次比赛为契机，与王智楠展开讨论，了解到阿里神灯团队获胜的独门秘籍、经验教训以及多层 Stacking Model 的相关信息。

WSDM Cup 挑战赛

在 KKBOX 的用户流失预测任务中，参赛者需要根据主办方提供的数据，预测 2017 年 3 月订阅到期的用户中，哪些会流失。

谈及参加此次比赛的原因，王智楠对 AI 研习社说道，「算法团队需要经常关注数据挖掘类比赛，获取最新信息。得知这一比赛时，恰好神灯团队在做音乐推荐项目，我们就想拿 KKBOX 的数据练练手。另外，我此前参加过 WSDM 2017，对此次会议也有一定了解。」

这次比赛是一个比较典型的二分类问题。王智楠表示，二分类问题中，他们主要考虑两个方面：

• 一是特征，希望能将更多的信息融入进来；

• 二是模型，在单模型上，业内用的都差不多，这一阶段重点考虑融合。

主办方提供的数据有如下三类：

• 订单数据。2017 年 3 月之前两年的订单交易信息，包括用户 id、付款方式、购买的会员周期、价格、时间、是否是自动续订等。

• 用户听歌日志。2017 年 3 月之前两年的用户听歌日志，包括用户 id，日期，听歌数量、时长等。

• 用户人口统计学信息。截止 2017 年 3 月的用户信息，包括所在城市、年龄、性别、注册时间等。

在数据预处理阶段，他们主要碰到两类问题，一是脏数据，二是正负样本比例不均衡。

• 针对脏数据问题，例如年龄数值小于 0 或者大于 100，注册时间和支付金额中的极端异常值，他们处理的方式有根据分布将异常值转换为合理取值，删除无法解释且不包含重要信息的数据等。

• 对正负样本分布不均衡的问题，他们使用欠采样的方式对训练样本进行处理，分别尝试了 1：3，1：5，1：8 的正负样本配比，在最终模型中，根据交叉验证的结果选择了最优配比。

在特征工程阶段，他们做了很多数据分析工作，比如统计用户的注册方式、注册渠道，每个渠道的注册人数，是否过滤掉特别小的渠道等。

针对出题方给的三份数据，神灯团队起初对每份数据都进行了分析，大概一周之后，发现除了订单数据，听歌日志和用户人口统计学信息起的作用很小，这时候他们进行了策略上的调整——把听歌日志和用户人口统计学信息放在一边，集中精力处理订单数据。直到比赛的最后阶段，他们也没有特别花时间研究另外两个数据。

最终，他们使用两层 Stacking Model，第一层采用逻辑回归、随机森林、XGBoost 算法，第二层又采用 XGBoost 算法把第一层的结果融合，在最后取得第二名。

在此次比赛中，他们也有一套方法论：「我们内部有一个称为 MVM（minimum variable model）——最简可用模型的策略，即先上线一个最小的模型，之后通过每次提交结果获得反馈，再不断修改原来的模型。」

目前，AliOS 神灯团队已经在利用深度学习做推荐系统，但在比赛中并没有使用这一方法，王智楠表示，这次的场景不太适合利用深度学习，更加适合传统特征工程的构造方式。他说道，「比赛时，主办方提供的数据都是经过加工的数据，比如用户听歌日志，主办方已经把这个数据整理到某人每天听了多少歌的粒度，这种细粒化的数据导致不太适合用深度学习方法解决。而我们平时利用深度学习做推荐可以从最原始的数据开始，将这些数据直接输入到模型里，得到一个处理过的向量值。」

细节分享

比赛并非一帆风顺，王智楠表示，中途出现了戏剧性的情况：比赛开始没多久，由于出题方的失误——在验证数据阶段没有对用户的结果进行随机打断，导致很多选手的比赛得分接近于满分。「期间中断了大概两到三周，后来主办方又公布了一批新的数据，大家得以重回到比赛中。」因为这一问题，他们之后再重新修改模型时，状态不如之前，因此花了一段时间进行调整与追赶。

此外，分析了冠军和其他选手的方案，他总结出两方面的教训。

• 第一是时间管控与模型调试。王智楠表示，他们在最后两周留的时间太紧张了，导致没有足够的时间调整线上模型超参。「其他参赛团队可能会这么尝试——每周把参数上调一个点，然后观察线上分数的变化情况。此外，如果我们能够在前面阶段将速度放快，就可以为比赛后期预留更多时间，把参数调的更好一点。」

• 第二是特征处理和数据分析。他在这里重点提到冠军的方案。王智楠对雷锋网 AI 研习社说道，从模型上对比他们与冠军的方案，神灯团队更占优势，但冠军在特征工程上做得比他们更加细致。他以日期为例，对于这一参数，他们会将其转化成一个数值来构造特征，但冠军还会把日期转化成 one-hot 特征。「有一些日期，比如是否月底，其实还是具有一些信息量的，但是当时我们没有考虑到这个问题。不单是这次比赛，在做其他比赛和业务的时候，也需要这么细致的考虑。」

他们团队主要是进行推荐算法的设计，之前也有相关的经验积累，那么，在工作中的算法是否能直接应用于此次比赛呢？

王智楠表示，参加比赛和实际业务场景还是存在极大差异。「比赛时可以不用考虑计算成本、线上服务，效率问题。但在实际场景下，如果模型做得太过复杂，后台计算就会特别复杂，时间可能会特别长，用户体验就不那么美好了。例如用户想要一个推荐服务，请求之后，1 秒钟都没有回复，这就存在极大问题。」

多层 Stacking Model

其实除了此次比赛，AliOS 的推荐算法团队还在多项国际大赛上获得优胜，例如 2015 ACM RecSys Challenge 亚军，2016 ACM RecSys Challenge 冠军，2016 KDD CUP Phase1 第二名。此外，他们团队在阿里天池的天猫推荐大赛、LBS 推荐大赛等多个内部赛上都曾获得奖项。

而这次比赛中使用的多层 Stacking model，也是源于 2016 年 KDD Cup。当时在比赛中为了提升效果，他们不断搜集资料，研究出这一模型。后来，他们尝试在线上使用这一方法，发现提升显著，于是有了这一模型的完备方案以及大规模应用。

他坦诚表示，虽然这一模型可以极大提升预测准确率，但目前也存在一个问题——线上消耗资源量比较大。「以前可能只用训练一个模型，但现在用两层 Stacking Model 就要多训练 4 个模型。」不过相较该模型带来的优势，资源的消耗相对来说变得不那么重要：「对于一些场景，比如广告场景，虽然资源消耗多，但性价比相对来说比较高。」

目前，他们也在研究如何用最少的资源来训练模型。

谈到该算法的实际应用，王智楠说道，现在主要还是集中在 AliOS 系统互联网汽车的音乐推荐上。目前，上汽集团大概有 50 万辆互联网汽车上装载 AliOS 系统，这些用户能优先体验到推荐算法带来的便利。

相关文章：

阿里巴巴WSDM Cup 2018夺得第二名，获奖论文全解读

。