阿拉丁神灯的故事想必大家都听过,对着神灯许下心愿,你的愿望就会实现。而今天,在阿里 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 系统,这些用户能优先体验到推荐算法带来的便利。
相关文章: