【.com原创文章】推荐系统核心排名算法从传统的LR、GBDT等模型进化到Deep&Wide、DeepFM、PNN等深度模型和传统模型相结合的阶段。如何根据各业务数据的特点，设计出适合的深度推荐算法，同时设计合理的架构，保证深度学习算法的稳定运行，成为企业推进落地的难点。基于深度学习的推荐系统。2018年11月30日至12月1日，由WOT主办的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数据清洗。与已经准备好数据集的传统比赛不同，我们面对的是真实线上场景中产生的日志数据，不仅“脏”而且体量非常大。因此，我们需要相应的数据清洗场景来缓解系统的处理压力。服务器模块。针对各种分拣召回模型场景，我们需要提供实时服务。所以服务器不仅需要具备高性能的计算能力，还需要我们的架构能够处理大规模的深度学习和计算。如果需要，也可以使用诸如GPU之类的硬件。平台。这主要是指深度学习或机器学习的训练平台。各种算法上线后，随着在线学习的推进，其模型不能一成不变。其中一些需要“每日”更新，甚至需要几分钟才能更新。因此，我们需要有一个好的深度学习平台来提供支持。测试。推荐系统上线后，需要不断迭代优化，所以我们需要测试看看效果。在系统初期，用户数量增长较快，但总体实验数量并不多，因此我们很容易通过对Top用户进行细分来进行流量相关的实验。但是随着业务的发展，用户数量不再爆发式增长，我们每天需要进行上百次实验，所以我们需要选择一个实验平台进行A/B测试，方便算法人员提速迭代过程。报告。我们之前和业务方合作的时候发现，几乎每个人都是通过自己编写简单的脚本来获取需要的报表，所以他们的工作重复度很高。但是，由于很多报表的计算都是简单算子的积累，如果我们有一个简单统一的平台，就可以帮助大家获取常用的指标，从而加速整个系统的迭代。从深度推荐系统的发展来看，最早出现的是传统的LR（线性回归）机器学习。后来随着对特征交叉的需求增加，出现了非线性回归和利用FM实现二阶特征交叉。近年来，随着深度学习在图像领域的广泛应用，现在也被引入到推荐系统中。但是相比于图像领域一两百层的神经网络深度，推荐系统的深度只有四六层。现在各种“大厂”都能提供FNN、DFM、GoogleWide&Deep等算法，我们很难说哪个模型更好。因此，大家在选型的时候，要注意自己的系统偏好，与业务保持很强的关联性。上图借用了阿里的DIEN（DeepInterestEvolutionNetwork）。它们与我们目前的工作相似，尤其是图中虚线框内的两项创新。后面我会重点分析。通常，我们在阅读各种论文时，很容易产生一种错觉：那些作者为了突出自己的贡献，往往着重描述模型的创造性，体现和提炼自己的核心思想，以至于大家认为所占比例这部分是可以达到80%。实验部分只是一些标准的数据集，经常被一笔带过。事实上，他们在模型端的工作量一般只有20%，另外80%都花在了实验上。具体来说，我们可以进行如下各种实验：在获取原始在线日志数据后，我们需要对其进行分析、统计和处理，以方便我们后期的模型训练。特征设计、交集和服务，包括：是否离散化特征值，是否扩大时间窗口等。对于模型选择，我们需要充分考虑计算开销，甚至考虑我们平台上是否有GPU。如果不是，我们不应该选择过于复杂的模型。同时，还要根据核心算法制定召回和仲裁策略。***是传统意义上的真实实验，包括离线评估、在线A/B和实验分析等，会和前面四项相关。深度推荐系统在360中的应用实践下面，我们就在360中探讨一下深度推荐系统在几个场景中的应用。图中三个应用在技术上是一种由浅入深、由简单到复杂的递进关系。场景一：应用推荐360手机助手，类似应用市场。图中红色方框显示的是系统推荐的内容，包括：“今日热点”、“大家都在玩”等，这些都与用户的个性化喜好有关。我们直接从用户的下载量和转化率来判断系统推荐的效果。应用前面提到的三个层次：抽象定义层。由于我们做的是离线系统，所以不怎么考虑C，主要关注U和I。在这个场景下，U属于1亿级，而I只有10000级。毕竟我们只需要在万级的应用库中进行推荐即可。算法策略层。由于I的量级比较小，我们直接在这个万级用户数据库中“简单粗暴”的进行了用户匹配和推荐，并没有实施召回策略。我们首先通过简单的算法制作了模型的第一个版本。为了看到效果，我们使用迭代、优化和序列预测来预测用户下次会安装哪个应用。Rank和Rerank的逻辑主要由业务方完成，因为主要涉及线上各种业务逻辑。架构层。对应我们天级的离线中心，在特征上并不复杂，仅通过使用Embedding特征完成。上图是我们对模型的逻辑演化路径。上图左边和GoogleWide&Deep的思路很像，只是我们用的特征很少。上图蓝色部分是用户App序列的ID列表。我们让每个App都有一个特征向量，然后做几层MLP，最后分类，从而预测用户接下来可能安装的App。后来跟业务人员沟通，我们在模型中加入了用户的浏览历史、搜索历史、关键词特征、App特征等元素，但本质上都是行为序列。考虑到简单的MLP不适合，我们尝试使用RNN的方法进行数据建模，所以得到了如下图所示的演进网络：虽然图中的上层分类与上图类似，但是浏览下面是值得大家注意的：当你将用户的搜索行为添加到你自己的特征中时，请注意调整时间序列，否则容易导致搜索词成为搜索系统。即：你的初衷是通过用户的搜索词反映用户的兴趣，预测他会下载的app。但是，如果你不去处理它，可能会导致你的系统只模拟某一行的搜索。上图比较了两种模型的不同结果。他们分别可视化每个应用程序的嵌入向量。我们取出App的Embedding向量，投影到一个二维图上。我们根据app原来所属的大类进行判断，经过模型学习后，如果能把大类打散，效果会更好。可以看出，在左边的MLP中间，各种类型的重叠比较严重。而在我们切换到RNN模型之后，它们看起来更加分散。我们以此直观地认为改进后的模型更好。根据上面RNN的效果和MLP的效果数据对比，我们可以看出Top1的差别并不算太大，仅仅提升了1个点。当然，这对于线上系统的提升可能更明显，但是对于我们的线下系统来说，提升的反应就没有那么明显了。这是我们整个团队在推荐领域的第一次测试。场景二：360搜索导航有了之前APP推荐积累的经验，我们尝试的第二项是“热搜词”。即：360页面有自己的搜索和导航，在搜索框下方，我们会放置六到七个用户经常搜索或经常使用的关键词。这样一来，用户打开导航就可以看到自己想看的内容，不仅降低了操作的复杂度，也提高了用户的使用满意度。在这个场景下，由于我们的导航每天都有上亿的PV（PageViews），所以使用这个功能的用户量是最高的，也就是U是最高的。同时，为了定义“经常搜索的词”，我们清洗了query（查询），过滤掉一些非常“长尾”的query，只留下一些明确的有实体词的query。因此，我这里设置为***根据查询次数。由于业务本身已经存在很长时间，所以在算法策略中实现了一些比较完善的召回（Recall），例如：Searchterms：根据用户的搜索行为召回一些新的关键词。URL：是根据用户在浏览器中的浏览记录，然后输入一些关键字。广告：通过满足用户的兴趣匹配，精准投放商业广告。百科：就是判断用户可能感兴趣的知识，放上相应的百科词汇。另外在Rank方面，我们开始对线上系统进行升级优化，从之前简单的LR+FTRL到DNN模型。在架构上，由于导航系统的特点是用户使用频率不高，而我们的推荐可能每天只在早晚使用一次，所以我们的目标是每天线下更新。对应的特征部分主要是根据用户的搜索日志和浏览日志设置一些统计特征。我们来看一些权重为正的特征，比如：week_freq_num特征，它描述了用户频繁搜索词的概率分布，即如果一个用户在过去一段时间内有统一的访问趋势，则它表示这是常规要求。这个功能比较重要。global_query_uv特征，这种全网特征可以在一定程度上反映商品的质量。我们用它来将原来的特征扩展到数万个。在我们将模型调整为DNN后，系统的AUC从7提高到8。然后我们添加了一些其他可以提高AUC的功能。为了细粒度分析DNN模型上线后召回策略的影响，我们将其与传统的LR+FTRL模型进行对比。途中有两个点击率高的地方，都与用户的搜索浏览行为有关，能够真正反映用户的需求。由于此类搜索、浏览和MLP的点击率本来就很高，因此我们需要在此基础上增加流量。另外，在上图中，虽然与个性化相关的广告部分略有增加，但ys_mid_hist有所减少。通过分析，我们发现模型在排序时，倾向于将策略放在后排。结果就是用户在界面上默认只能看到六个推荐词，但实际上旁边有一个向下点击。箭头，点击后会出现很多字。因此，如果一些推荐词排在第六位之后，那么它们被点击的可能性很小。这也说明了默认六个字的重要性。同时，这也提醒我们：在做数据的时候，需要关注用户通过点击下拉按钮访问的词汇。只有这些数据才能更好地说明用户对某些词汇的强烈需求。总体而言，我们在2017年Q1帮助业务方增加了5%的收入。场景三：快视频在前面两个项目积累的经验基础上，我们投入了第三个项目——快视频。它的主要业务形式是个性化消息推送，类似于手机上的通知栏推送。不过有一点点不同：我们并不是每天定时推送，而是根据用户反馈的喜好调整推荐的次数、频率和时间。同时，对于一些还没有养成每天在我们App看视频习惯的用户来说，可以起到一定的“拉活”作用。在这里，我们仍然应用前面的三个级别。在顶层，由于视频库的规模和用户数量自App推出以来增长非常迅速，所以我和U都有***。在召回策略方面，图中列出了五个重要的召回。前三项是：语义、视觉和行为回忆。我们专注于统一优化它们。在离用户较近的Rank部分，我们通过收敛采用了LSTM+Attention模型。上面介绍的两个项目只是每日更新，所以算法人员压力不大，只需要定时任务即可。在这种场景下，由于是用户实时在线推荐系统，如果采用“日级更新”的频率，会给用户带来较差的体验。因此，无论是召回数据流，模型的更新，还是在线服务，我们都精心设计了架构。让我们看看刚才提到的三种回忆策略：行为的、语义的和视觉的。在这里，我们将它们统一到Embedding框架中，从而对视频的不同角度进行描述和特征表示，而无需关心后续的设计阈值和队列长度等问题。通过实现统一的流程，我们可以更直观地反映特征域中各种视频的召回依据。比如图中加粗的字体就是某个视频的标题。很明显，这是关于传授烹饪知识的回忆：就行为模型而言，它分配了各种特征向量。其特点是：会产生一定的扩散作用。也就是说，您会在上图中注意到，此次召回的前两个结果已经从烹饪领域转移到了其他领域。只有第三次召回真正与烹饪有关。语义模型侧重于视频标题的语义表示。通过语法和语义的相似性，这种回忆可以捕捉到标题中的关键动词和名词，然后进行相应的交叉和扩散操作。视觉模型通过提取视频的特征来实现召回。它与标题没有很强的语义联系。即使标题与烹饪无关，但只要视频中有大量的食物图像，就可以对其进行表征和回忆。从上面可以看出，我们可以通过不同的Embeddings来实现各种召回策略。下面我们重点介绍语义模型。我们得到的输入数据是公司过去产生的查询和搜索数据，或者其他业务线积累的标签数据，比如从网页标题中抽象出来的简单标签。这些标签要么自动生成，要么手动更正并重新绑定（重新连接）。它们都有一定的实用价值。为了给每个标题生成对应的表示，我们构建了一个任务：首先对每个句子进行切分，得到对应的词/词向量，然后通过CNN网络进行处理，最后对目标进行多分类、多分类标签，从而预测标签的准确性。对于以上任务，除了尝试CNN模型外，我们还尝试了一种双向LSTM，即bi-LSTM，不改变任务。接下来，我们需要评估语义模型。在这个业务场景中，我们手动标记了数千条多样性较好的数据，并将其作为离线评估的指标，通过语义模型检查召回标记数据的结果的相关性。上图左边的表格就是我们测试的结果。在这里，我们比较了几种常见的语义建模模型及其相应的优化。表格中间一列是Title2Tags，通过title预测对应的label。至于右边的列：Title2UnionTags，我们相应地发现，如果只有一个标题，往往会遗漏语义。如上图右边的例子所示：无论是人为编写的标题还是自动生成的标题，如果我们将多个标签放在一起，句子中的语义会被更准确地覆盖。另外，我们后续对数据的清洗也可以增加原句中的标签数量，从而大大提升模型的整体效果。上图就是我们开头引用的AliDIEN。它的虚线框内有两个创新点，分别是AUGRU（即Attention和GRU的结合）和auxiliaryloss。虽然loss对模型的提升效果非常明显，但遗憾的是我们在设计模型时过于关注Attention层和下沉到用户序列的特性，所以我们在未来。上图是我们当时对不同排序模型的评估结果。可以看出，在我们的系统架构设计中，不仅有平台服务、日志采集、报表等离线部分，还有实时在线更新。同时，我们也与业务方在线系统保持实时交互，以便他们按需获取推送的数据。此外，在顶层，我们还为业务端提供了多种安全策略和分桶策略。上图是我们从2017年11月1日到2018年1月31日的CTR曲线，虽然有一些“坑点”引起的曲线波动，但总体还是向上的趋势，尤其是我们更换了Attention模型之后，涨幅可以达到10%，有效帮助业务方实现“拉活”，维系更多活跃用户。综上所述，我们基于深度学习的推荐系统就是按照以上三个层次，通过迭代和优化，一步步发展起来的。【原创稿件，合作网站转载请注明原作者和出处为.com】
