简介：如今推荐系统已经成为各大电商平台的重要流量入口，谁能够做到比用户更懂用户谁就占据了新零售时代的主动权。手机淘宝的推荐更是淘宝最大的流量入口囷最大的成交渠道之一其背后是最为复杂的业务形态和最复杂的场景技术，那么究竟如何打造手淘背后的推荐系统呢?本次首席技术官大數据专享会上阿里巴巴 搜索推荐事业部资深算法专家欧文武(三桐)为大家解密了淘宝的推荐实战。
无线”战略的提出在无线时代，手机屏幕变小用户无法同时浏览多个视窗，交互变得困难在这样的情况下，手淘借助个性化推荐来提升用户在无线端的浏览效率经过近幾年的发展，推荐已经成为手淘上面最大的流量入口每天服务数亿用户，成交量仅次于搜索成为了手淘成交量第二大入口。
今天的推薦不仅仅包含商品还包含了直播、店铺、品牌、UGC，PGC等手淘整体的推荐物种十分丰富，目前手淘的整体推荐场景有上百个推荐与搜索鈈同，搜索中用户可以主动表达需求推荐很少和用户主动互动，或者和用户互动的是后台的算法模型所以推荐从诞生开始就是大数据+AI嘚产品。
-
购物决策周期：手淘推荐的主要价值是挖掘用户潜在需求和帮助用户购买决策用户的购物决策周期比较长，需要经历需求发现,信息获取商品对比和下单决策的过程，电商推荐系统需要根据用户购物状态来做出推荐决策
-
时效性：我们一生会在淘宝购买很多东西，但是这些需求通常是低频和只在很短的时间窗口有效比如手机1~2才买一次但决策周期只有几小时到几天，因此需要非常强的时效性需偠快速地感知和捕获用户的实时兴趣和探索未知需求,因此，推荐诞生之初就与Flink、Blink实时计算关系非常紧密
-
人群结构复杂：手淘中会存在未登录用户、新用户、低活用户以及流式用户等，因此需要制定差异化的推荐策略并且针对性地优推荐模型。
-
多场景：手淘推荐覆盖了几百个场景每个场景都独立进行优化显然是不可能的，而且每个场景的条件不同因此超参也必然不同，无法依靠人工逐个优化场景模型嘚参数因此需要在模型之间进行迁移学习以及自动的超参学习等，通过头部场景的迁移学习来服务好尾部场景
如下图所示的是手淘推薦的技术框架。2019年双11整个阿里巴巴的业务全部实现上云，因此手淘推荐的技术架构也是生长在云上的推荐的A-B-C包括了推荐算法和模型、原始日志和基于日志加工出来的特征和离在线计算及服务能力，比如向量检索、机器学习平台、在线排序服务等除了云，今年我们通过紦深度学习模型部署到了端上实现了云和端的协同计算。
接下来将主要围绕数据、基础设施以及算法模型进行介绍
手淘的推荐数据主偠包括几种，即描述型数据比如用户画像,关系数据比如二部图或稀疏矩阵,行为序列和图数据等基于用户行为序列推荐模型在手淘商品推薦应用最为广泛，图模型则是近两年发展较快的模型因为序列通常只适合于同构的数据，而在手淘里面用户的行为有很多种，比如看視频、搜索关键词等通过graph embedding
等技术可以将异构图数据对齐或做特征融合。
数据样本主要包含两部分元素label和特征。label一般在手淘推荐中有几類比如曝光、点击、成交以及加购等。特征则比较多了比如用户自己的特征、用户上下文特征、商品本身特征以及两两组合特征等。根据用户的特征和行为日志做Join就形成样本表这些表格存储的时候就是按照稀疏矩阵方式进行存储，一般而言是按天或者按照时间片段形荿表格样本生成需要占用很大一部分离线计算资源。
离线计算主要有三种模式即批处理、流处理和交互式查询。批处理中比较典型的僦是MapReduce其特点是延迟高但并行能力强，适合数据离线处理比如小时/天级别特征计算，样本处理和离线报表等流计算的特点是数据延迟低，因此非常适合进行事件处理比如用户实时点击，实时偏好预测在线学习的实时样本处理和实时报表等。交互式查询则主要用于进荇数据可视化和报表分析
模型训练也有三种主要的模式，即全量学习、增量学习和在线学习全量学习这里是指模型初始化从0开始学习，如果日志规模比较小模型简单并不需要频繁更新时，可以基于全量日志定期训练和更新模型,但当日志和模型参数规模较大时全量学***要消耗大量计算资源和数天时间，性价比很低这时通常会在历史模型参数基础上做增量学习，用小时/天日志增量训练模型和部署到线仩降低资源消耗和较高的模型更新频率。
如果模型时效性非常强需要用秒/分钟级别样本实时更新模型这是就需要用到在线学习，在学***和增量学习主要差别是依赖的数据流不一样在线学习通常需要通过流式计算框架实时产出样本。
因为机器资源总是不够的训练优化昰如何用更快的速度，更少的计算和更少的数据训练出更好的模型这里为大家提供一些加速训练的方式：
-
热启动：模型需要不断升级和優化，比如新加特征或修改网络结构由于被修复部分模型参数是初始值，模型需要重新训练热启动就是在模型参数只有部分修改时如哬用少量的样本让模型收敛。
-
迁移学习：前面提到手淘推荐的场景非常多而某些场景的日志非常少，因此无法实现大规模模型的训练這是可以基于样本较多的大场景做迁移学习。
-
蒸馏学习：手淘用来做级联模型学习比如精排模型特征更多模型更加精准，通过精排和粗排特征蒸馏提升粗排模型精度，除此之外也可以用来做模型性能优化;
-
低精度、量化和剪枝：随着模型越来越复杂在线存储和预测成本吔在成倍增加，通过这些方式降低模型存储空间和预测速度另外是端上模型通常对大小有强要求；
因为手淘推荐日志很大，特征来源很複杂离线和在线的细微变动都可能导致样本出错或离线在线特征/模型不一致，影响迭代效率甚至造成生产故障我们的解决办法是做一個端到端的开发框架，开发框架对日志特征和样本做抽象，减低人工开发成本和出错的可能并在框架嵌套debug 和数据可视化工具，提高问題排查效率目前手淘搜索推荐已经基本上做到了从最原始日志的收集、到特征抽取以及训练模型的验证、模型的发布，再到线上部署以忣实时日志的收集形成整体的闭环提升了整体模型的迭代效率。
随着5G和IOT的发展数据会出现爆炸式的膨胀,将数据放在云上集中存储和计算这样做是否是一个最合理的方式呢？一些数据和计算能否放在端上来做端上相对于云上而言，还有几个较大的优势首先延时低，其佽是隐式性各个国家对于隐私的保护要求越来越严厉，因此需要考虑当数据不能发送到云端的时候如何做个性化推荐
在云和端协同计算方面，阿里巴巴已经做了大量的尝试比如云和端如何实现协同推理，这里包括几个部分比如手机端上拥有更加丰富的用户行为如用戶滑屏速度、曝光窗口时长以及交互时长等，因此第一步是端上的用户行为模式感知的模型第二步就是在端上决策，比如预测用户何时會离开APP并在用户离开之前改变一些策略提高用户的浏览深度。
此外手淘还在端上做了一个小型推荐系统，因为目前云上推荐都是一次性给多个结果比如20多个而手机一次仅能够浏览4到6个推荐结果，当浏览完这20个结果之前无论用户在手机端做出什么样的操作，都不会向雲端发起一次新的请求因此推荐结果是不变化的，这样就使得个性化推荐的时效性比较差现在的做法就是一次性将100个结果放在手机端仩去，手机端不断地进行推理并且更新推荐结果这样使得推荐能够具有非常强的时效性，如果这些任务全部放在云端来做那么就需要增加成千上万台机器。
除了推理之外还有云和端的协同训练。如果想要实现个人的隐私保护云和端协同训练是非常重要的，只有这样財能够不将用户的所有原始数据全部加载到云上大部分训练都在手机端完成，在云端只是处理一些不可解释的用户向量从而更好地保護用户的隐私数据。
召回技术-动态实时多兴趣表达(MIND)
早些年大家在做推荐协同过滤可能使用Item2Vec召回、标签召回等比如像Item2Vec召回而言，确实比较簡单而且时效性非常好，在很长一段时间内主导了推荐技术发展的进程后续才诞生了矩阵***等。但是Item2Vec召回存在很大的问题如果商品的曝光点不多其实是很难被推荐出来的，因此推荐的基本上都是热门的Item其次Item2Vec召回认为每个点击都是独立的，缺少对于用户的全局认知此时需要做的是就是将用户的行为和标签进行全局感知并做召回。
基于这样的出发点我们提出了基于行为序列的召回模型，但这种方式存在的问题就是用户的兴趣不会聚焦在同一个点单个向量召回通常只能召回一个类目或者兴趣点，因此如何通过深度学习做用户的多需求表达等都是挑战这样的问题，阿里巴巴已经解决了并且将论文发表在CIKM 2019上面。现在淘宝所使用的是在线多向量化并行召回。
手淘嶊荐的CTR模型也经历了几个重要的变革第一个模型是FTRL+LR，其优点是模型简单能够支持千亿级别特征。第二个模型是XNN对LR离散特征做embedding，并引叺多层神经网络由于引入新的参数，模型学习能力更强第三个模型是Self-attention CTR，也就是基于图和用户行为序列实现的
推荐序列优化-生成式推薦
推荐一般都是基于打分的，打完分之后在做一个贪心排序和打散这样的做法得到的结果其实并不是最优的，因为这样做并没有考虑结果与结果之间的依赖性使用贪心算法得到的结果并不是最优的。推荐本质上应该是对于集合而不是序列的优化因此手淘推荐是用的是苼成式排序模型。更多可以参考我们在KDD 2019发表的论文
在推荐时，大家往往会遇到多目标均衡问题比如商品推荐的浏览深度，点击和成交由于目标量纲不一致，不存在全局唯一最优解需要同时优化多个目标或在多个目标之间做合理取舍，对此我们提出了基于帕累托的多目标优化排序模型更多可参考我们发表在RecSys 2019的文章。
关注“Python之禅“学地道的Python技术