内容简介:【51CTO.com原创稿件】 推荐系统的核心排序算法已经从传统的 LR、GBDT 等模型进化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和传统模型相结合的阶段。如何结合各个业务数据的特点,设计合适的深度推荐算法,同时设计合理的架构保证深度学习算法的稳定运行,成为企业在推动基于深度学习的推荐系统落地的难点。
【51CTO.com原创稿件】 推荐系统的核心 排序 算法已经从传统的 LR、GBDT 等模型进化到了 Deep&Wide、DeepFM、PNN 等若干深度模型和传统模型相结合的阶段。
如何结合各个业务数据的特点,设计合适的深度推荐算法,同时设计合理的架构保证深度学习算法的稳定运行,成为企业在推动基于深度学习的推荐系统落地的难点。
2018 年 11 月 30 日-12 月 1 日,由 51CTO 主办的 WOT 全球人工智能技术峰会在北京粤财 JW 万豪酒店隆重举行。
本次峰会以人工智能为主题,360 人工智能研究院的技术经理张康在推荐搜索专场与来宾分享"基于深度学习的推荐系统在 360 的应用"的主题演讲,为大家详细阐述在 360 的各种场景下,基于深度学习的推荐系统的各种应用。
本次分享分为如下两大部分:
- 推荐系统相关算法最新研究进展
- 深度推荐系统在 360 的应用实践
推荐系统相关算法最新研究进展
在介绍应用系统之前,首先让我们从抽象的层次上理解一下,在图像领域的相关概念。
上图是我们对推荐系统的一个分层与抽象。在顶层,我们可以理解为是一个函数。
其中 U 代表用户、I 代表需要推荐的商品、C 代表上下文、Y 则是我们需要优化的目标。
当然,不同的应用场景,Y 的取值会有一定的差异。如果我们的目标是点击率的话,那么 Y 的取值就是 0 和 1。
而如果我们要预估某个时长的话,那么 Y 的取值就变成了实数,它对应的就是某个回归问题。可见,根据不同的场景,定义好 Y 是至关重要的。
如果是从算法人员的角度出发,他们会认为定义 Y、和对 F 求解的优化是非常重要的。
而在业务方的那些做产品的人看来,U 的反馈则更为重要,如果出现用户投诉的话,那么该算法也就失败了。
另外,他们也会关注 I。由于 I 的背后实际上关联的是商家,那么同样要避免出现用户对于 I 的抱怨。可见,不同角色对于此公式的关注点是不相同的。
在上面抽象图的中间,我们一般会把顶层简单的数学公式拆分成三个不同的算法模块:
- 召回(Recall)
- 排序(Rank)
- 策略(或称重排序 Rerank)
目前市面上的一些工业领域和学术界的论文,大部分会重点研究和讨论 Rank,毕竟 Rank 是非常重要的。
而对于那些针对 Recall 和 Rerank 的技术而言,由于它们并不适合被抽象成为一个统一的理论架构,因此相关的论文也不多。后面我们会重点讨论有关召回部分的内容。
经历了上面两个抽象层次,图中的底层就需要让推荐系统服务于“线上”了。
它由五大关键部分所组成:
- ETL 对数据的清洗。不同于那些已经准备好了数据集的传统竞赛,我们面临的是在真实的线上场景中所产生的日志数据,它们不但“脏”,而且体量非常大。
因此,我们需要有一个对应的数据清洗场景,以缓解系统的处置压力。
- Server 模块。针对各种排序和召回的模型场景,我们需要提供实时的服务。
因此服务端不但需要具有高性能的计算能力,同时也需要我们的架构能够应对大规模的深度学习与计算。如有必要,还可能会用到 GPU 等硬件。
- Platform。这里主要是指深度学习或者机器学习的训练平台。在各种算法上线之后,随着在线学习的推进,其模型不可能一成不变。
有的它们需要被“日更”,甚至是以分钟为单位进行更新。因此我们需要有一个良好的深度学习平台提供支持。
- 测试。推荐系统在上线之后,需要被不断的迭代与优化,因此我们需要通过测试来查看效果。
在系统的起步阶段,用户数量迅速上升,而实验的整体数量则不多,因此我们很容易通过对百万级用户的切分,来开展与流量相关的实验。
但是随着业务的发展,用户数量不再呈爆发式增长,而我们每天又需要进行成百上千次实验,所以我们需要选用 A/B 测试的实验平台,以方便算法人员加速迭代的进程。
- 报表。之前在与业务方合作时,我们发现:他们几乎每个人都在通过自行编写简单脚本的方式获取所需的报表,因此其工作的重复度相当高。
然而,由于许多报表的计算都是简单算子的累加,如果我们拥有一个简单且统一的平台,就能够帮助大家获取常用的指标,进而加速整个系统的迭代。
从深度推荐系统的发展来看,最早出现的是传统 LR(线性回归)的机器学习。
之后,随着特征交叉需求的增多,出现了非线性回归和使用 FM 来实现二阶特征交叉。
近年来,随着深度学习在图像领域的广泛应用,如今大家也将它们引入到了推荐系统之中。
不过,相对于图像领域动辄一两百层的神经网络深度而言,推荐系统的深度只有四到六层。
如今各家“大厂”都能够提供诸如 FNN、DFM、以及 Google Wide&Deep 之类的算法,我们很难断言哪种模型更好。
因此大家在进行模型选取的时候,应当注意自己的系统偏好,保持与业务的强关联性。
上图借用的是阿里的 DIEN(Deep Interest Evolution Network),他们和我们现在的工作有着相似之处,特别是图中虚线框里的两个创新点。我会在后面进行着重分析。
平时,我们在阅读各种论文时,很容易产生一种错觉:那些作者为了突出自己的贡献,经常会着重描写模型上的创意,体现并抽象其核心的思想,让大家认为该部分的占比能达到 80%。
而实验部分都只是一些标准的数据集,经常一笔带过。实际上,他们在模型侧的工作量一般只有 20%,其他的 80% 则花在了做实验上。
具体说来,我们可以开展如下各种实验:
- 在拿到原始的线上日志数据之后,我们需要对它们做分析、统计和处理,以方便我们后期进行模型训练。
- 特征设计、交叉和服务,包括:是否要将特征值离散化,是否要放大时间窗口等。
- 模型选择,我们需要全面考虑计算的开销,甚至要考虑自己的平台上是否有 GPU,倘若没有,则不应选择过于复杂的模型。同时,我们也要根据核心算法,制定召回和仲裁策略。
- 最后是真正传统意义上的实验,包括离线评测、线上 A/B 和实验分析等,这些都会与前面的四项有所关联。
深度推荐系统在 360 的应用实践
下面,我们来讨论一下深度推荐系统在 360 中几个场景应用的落地。如图的三款应用在技术上呈由浅入深、由简单到复杂的递进关系。
场景一:App 推荐
360 手机助手,类似于应用市场。图中红框里显示的都是系统推荐的内容,包括:“今日热点”和“大家都在玩”等,这些都是与用户的个性化喜好相关的。我们直接从用户的下载和转化率,来判定系统推荐的效果。
套用前面提到的三个层次:
- 抽象定义层。由于我们做的是一个离线系统,因此我们对 C 考虑并不多,主要将重点放在了 U 和 I 上。该场景下的 U 属于亿级,而 I 只有万级,毕竟我们只需要在万级的 App 库里做推荐。
- 算法策略层。由于 I 的量级比较小,我们当时就“简单粗暴”地直接在这个万级用户库里做了用户匹配和推荐,而并没有执行召回策略。我们首先通过简单的算法做出了一个初版模型。
为了查看效果,我们通过迭代、优化和序列预测,来预测用户下一次会安装哪一种 App。而 Rank 和 Rerank 部分的逻辑,由于主要涉及到各种线上的业务逻辑,因此是由业务方来完成的。
- 架构层。它对应的是我们的天级离线中心,在特征上并不复杂,仅通过 Embedding 特征的运用就完成了。
上图是我们对于模型的逻辑进化路径。上图的左侧与 Google Wide&Deep 的思路是很相似的,只不过我们用的特征非常少。
上方蓝色部分是用户 App 序列的 ID 列表,我们使每个 App 都有一个特征向量,然后做若干层的 MLP,最后做分类,从而预测某个用户下一步可能安装的 App。
后来,随着与业务人员的交流,我们在模型中加入了用户的浏览历史、搜索历史、关键词特征、和 App 特征等元素,不过其本质上也都是行为的序列。
考虑到简单的 MLP 已不太适合,因此我们就尝试采用了 RNN 的方法进行数据建模,于是就有了如下图进化后的网络:
虽然该图的上层分类与前面类似,但是下面的 browse 却值得大家注意:当你把用户的搜索行为加到自己的特征里时,请注意调整时间序列,不然很容易会导致该搜索词变成了一个搜索系统。
即:你的本意是通过用户的搜索词,来反应他的兴趣,并预测他要下载的 App。
但是,如果不做处理的话,就可能导致你的系统只是在模拟某个线上的搜索。
上面这张图是将两个模型的不同结果进行了比较。它们分别对每个 App 的 Embedding 向量进行了可视化。我们将 App 的 Embedding 向量取出,并投影到二维图上。
我们根据 App 原来所隶属的大类,来判断经过模型学习后,如果能将大类拉得比较散的话,那么效果就会更好些。
可见,在左边 MLP 的中间,各种类型的交叠比较严重。而在我们换成了 RNN 模型之后,它们就显得分散了许多。我们籍此来直观地认为改进后的模型更好。
根据上面将 RNN 的效果与 MLP 的效果所进行的数据比较,我们可以看出:在 Top1 上的差异并不太大,仅提升了 1 个点。
当然,这可能对于线上系统的提升会反应得显著一些,但是对于我们的离线系统,提升反应就没那么明显了。这便是我们整个团队在推荐领域的第一次试水。
场景二:360 搜索和导航
有了前面 App 推荐的经验积累,我们尝试的第二个项目是“常搜词”。即:360 页面有自己的搜索和导航,而在搜索框的下方,我们会放置六到七个用户经常搜索、或者是时常用到的关键词。
如此,用户在打开导航时就能看到自己想看的东西,这不但减少了他们在操作上的复杂度,还提升了用户在使用上的满意度。
在该场景下,由于我们的导航每天都有好几亿次的 PV(Page View),因此使用该功能的用户有着千万级的体量,即 U 为千万级。
同时,为了定义“常搜词”,我们对 query(查询)进行了清洗,过滤掉了一些非常“长尾”的 query,只留下一些有实体字的、较为明确的 query。因此,此处的 I 就根据 query 的数量被设定为了百万级。
由于该业务本身已存在了较长时间,因此在算法策略上也已实现一些较为完善的召回(Recall),例如:
- 搜索词:是根据用户的搜索行为,召回一些新的关键词。
- URL:是根据用户浏览器里面的浏览记录,再输入一些关键词。
- 广告:是通过满足用户的兴趣匹配,精准地投放商业化的广告词。
- 百科:是判断用户可能感兴趣的知识,投放相应的百科词汇。
另外在 Rank 方面,我们着手将线上系统从以前简单的 LR+FTRL,升级并优化成为了 DNN 模型。
在架构上,由于该导航系统的特点是用户使用频次不高,而我们的推荐可能每天只会被早晚各用一次,因此我们的目标是天级离线更新。
其对应的特征部分,则主要是基于用户的搜索日志和浏览日志,来进行的一些统计特征的设定。
让我们来看看其中几个权重比较正向的特征,例如:
- week_freq_num 特征,描述了用户常搜词汇的概率分布,即:如果某个用户在过去一段时间窗口内成均匀的访问趋势,则说明这是经常性的需求。该特征比较重要。
- global_query_uv 特征,此类全网特征能够在一定程度上反映商品的质量。我们籍此在原有特征的基础上扩展到成千上万个。
在我们将模型调整成为 DNN 之后,系统的 AUC 从 7 提到 8。之后我们还增加了一些其他能够提升 AUC 的特征。
为了细粒度地分析 DNN 模型的召回策略在上线之后所产生的影响,我们拿它与传统的 LR+FTRL 模型进行了对比。
途中两处 CTR 较高,它们都与用户的搜索和浏览行为相关,并且能够真正反映他们的需求。
由于此类搜索、浏览和 MLP 的点击率本身就比较高,因此我们需要在此基础上有一个量的提升。
另外在上图中,虽然与个性化相关的广告部分略有提升,但是 ys_mid_hist 是有所下跌的。
通过分析,我们发现该模型当时在排序时,倾向于把策略后排,其导致的结果是:用户在界面上默认只能看到六个推荐词,而实际上其旁边有一个往下点的箭头,在被点击之后才会出现很多的词汇。
因此,如果某些推荐词汇被排到了第六名之后的话,那么它们被点击的可能性就非常小。这也说明了默认六个词的重要性。
同时,这也提示了我们:在做数据时,需要重点关注那些用户通过点击下拉按钮去访问的词汇,那些数据才更能够说明用户对某些词汇的强烈需要。总的说来,我们协助业务侧将 2017 年 Q1 的收入提升了 5%。
场景三:快视频
基于前面两个项目所积累的经验,我们全情地投入了第三个项目—快视频。其主要的业务形式是个性化的消息推送,与大家手机上的通知栏推送相类似。
但是,略有不同的是:我们并非每日都定时推送,而是会根据用户的反馈偏好,去调整推荐的数量、频率和时间。
同时,这对于将一些尚未养成每日到我们的 App 里观看视频的用户来说,能够起到一定“拉活”的作用。
在此,我们仍然套用前面的三个层次。在顶层,由于该 App 上线之后,视频库的规模和用户的数量都增长得非常迅速,因此 U 和 I 都具有千万级。
在召回策略上,图中列出了五种重要的召回。前三项分别是:语义、视觉和行为召回。我们统一地对它们进行了重点优化。
而在距离用户更近的 Rank 部分,我们通过收敛,采用了 LSTM + Attention 的模型。
前面介绍过的两个项目都仅仅是以天为单位进行更新,因此对算法人员的压力并不大,只需采用定时任务便可。
而在这个场景中,由于它是一个对用户进行实时在线推荐的系统,如果采用“天级更新”频率的话,会给用户带来较差的体验。
因此无论是对召回的数据流、模型的更新、还是在线的服务,我们都认真进行了架构设计。
我们来看看刚才提到的三个召回策略:行为、语义和视觉。在此,我们将它们统一到了 Embedding 框架之中,以便从视频的不同角度进行描述和特征表示,而不必关心后续有关设计域值、队列长度等问题。
通过执行统一的流程,我们能够更直观的体现出各种视频在特征领域下召回的根据。
例如图中黑体字是某个视频的 title(标题),明显,它是有关传授烹饪知识的召回:
- 就行为模型而言,它通过对用户行为序列的协同与分割,为每个视频分配各种特征向量。
其特点是:会产生一定的扩散效果。即,你会在上图中发现,该召回的前两个结果已经不再关注烹饪,而是扩散到了其他领域。只有第三个召回才是真正有关于烹饪的。
- 语义模型,重点关注的是视频标题的语义表示,通过语法和语义的相似性,此类召回能够抓住标题中关键性的动词与名词,然后进行相应的交叉和扩散等操作。
- 视觉模型,是通过抽取视频的特征,来实现召回。它与标题的语义关联性不强,就算标题与烹饪无关,只要在视频中大量出现食物的图像,便可以表示并召回。
由上可见,我们通过不同的 Embedding,就可以实现多样的召回策略。
下面我们重点介绍语义模型。我们所得到的输入数据是公司过往生成的查询、与搜索数据,或是其他的业务线积累的标签数据,例如由网页标题所抽象出来的简单标签。
这些标签既有自动生成的,也有通过人工修正和 rebind(重新连接)产生的。它们都具有一定的实际价值。
为了给每个 title 产生相应的表征,我们构建了一项任务:首先是对每个句子进行分词,以得到相应的字/词向量,然后通过 CNN 网络进行处理,最后对目标予以多分类、多标签,从而预测该标签准确性。
对于上述任务,我们除了尝试过 CNN 模型之外,还在不改变 task 的情况下试用了双向的 LSTM,即 bi-LSTM。接着,我们需要对该语义模型进行评测。
在此业务场景下,我们人工标出了几千个具有良好多样性的数据,并将其作为离线评测的指标,以此来检查通过语义模型召回标注数据的结果相关性。上图左侧的表格就是我们测试的结果。
我们在此比较了几种常见的语义建模的模型、及其对应的优化。表格的中间列是 Title2Tags,即通过标题来预测对应的标签。
至于右边列:Title2UnionTags,我们对应地发现到:如果只有单个标题,则语义往往会被遗漏。
如上图右侧的例子所示:无论是人工写的标题,还是自动生成的,如果我们将多个标签放到一块儿,句子中的语义则会更准确地被覆盖到。
另外我们后续对数据的清洗,也能够提升原句子的标签数量,进而大幅提升模型的整体效果。
上图是我们开篇引用过的阿里 DIEN,在其虚线框中有两个创新点,分别是 AUGRU(即 Attention 与 GRU 的合并)和辅助的 loss。
虽然 loss 对模型的提升效果非常明显,可惜我们在模型设计时,过于关注 Attention 的 layer 和下沉到用户序列上的特征,因此我们将来尚有改进的空间。
上图便是我们当时对不同排序模型的评测结果。
可见我们在系统架构的设计上,既有诸如到台服务、日志搜集、和报表等离线部分,又有实时的在线更新。
同时,我们也与业务方的在线系统保持着实时性的交互,以便他们按需获取推送的数据。另外在最上层,我们为业务方也提供了多种安全策略和分桶策略。
上图便是我们从 2017 年 11 月 1 日到 2018 年 1 月 31 日的 CTR 曲线。
虽然有某些“坑点”所导致的曲线波动,但是整体趋势还是向上的,特别是在我们更换了 Attention 模型之后,提升的幅度能够达到 10%,进而有效地帮助业务方实现了“拉活”和保持更多的活跃用户。
综上所述,我们基于深度学习的推荐系统就是根据上述三个层次,一步一步地通过迭代和优化发展起来的。
【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。