深度学习推荐系统实战_15_11_召回层如何快速又准确地筛选掉不相关物品
你好，我是王哲啊，今天我们来一起学习推荐系统中非常重要的一个模块召回层。
那为了弄清召回层是什么？我们先来试着解决一个问题吧。
题目是这样的，如果你是一名快手的推荐工程师，你的任务呢是从五百万个候选视频中为一名用户推荐十个他最喜欢的视频，你会怎么做呢？我想最直接暴力的做法呀，就是给这五百万个短视频挨个打分，然后排序，最后取出里面得分最高的十个推荐给用户。
啊，如果这个打分的算法非常靠谱的话，我们肯定能够选出用户最感兴趣的十个视频。
但是这个过程中会涉及一个非常棘手的工程问题。
那就是如果我们利用比较复杂的推荐模型，特别是深度学习推荐模型，对五百万个短视频挨个打分。
这个过程会非常消耗计算资源。
而且你还要知道，这还只是我们计算了一个用户的推荐结果。
在工业级的线上服务中，每秒可是有几十万甚至上百万的用户。
同时请求服务器逐个候选视频打分，产生的计算量是任何集群都承受不了的那在物品候选集非常大的时候，我们怎么才能又快又准的筛选掉不相关物品来节约排序时消耗的计算资源呢？这其实就是召回层的作用。
所以今天啊我们就从三个召回层的技术方案入手，带你一起来解决这个问题。
在前面的课程中啊，我也提到过学习推荐系统的一个主要原则，那就是深入细节，不忘整体。
对于召回层，我们也应该清楚搭载推荐系统架构中的位置。
从技术架构的角度来说，召回层处于推荐系统的线上服务模块之中。
推荐服务器从数据库或者内存中拿到所有候选集以后，会依次经过召回层、排序层再排序层，才能够产生用户最终看到的推荐列表。
既然线上服务需要这么多层，才能产生最终的结果。
不同层之间的功能又有什么区别呢？其实啊从这节课刚开始的问题出发，你应该已经对召回层和排序层的功能特点有了一个初步的认识。
召回层就是要快速准确的过滤出相关物品，缩小候选集。
而排序层是以提升推荐效果为最终目标做出精准的排序。
再详细一点说，我们可以从候选其规模、模型、复杂性程度、特征、数量、处理速度、排序、精度等几个角度来对比召回层和排序层的特点。
大家可以参考文稿中的表格。
这里有一点我们要注意，在我们设计召回层的时候，计算速度和召回率其实是两个矛盾的指标。
怎么理解呢？啊，比如说为了提高计算速度，我们要让召回策略尽量简单，而为了提高召回率或者说召回精度，这又要求召回策略不能过于简单，否则召回的物品就没办法满足排序模型的要求了。
推荐工程师们啊，就是在这样矛盾的过程中做出新的尝试，推动着召回层的技术方案不断向前发展。
接下来我们就详细来说说这发展过程中三个主要的召回方法。
为了让你更准确的理解这些方法，我把基于raxis的代码也写在了文稿里。
你可以在了解方法之后，好好看一下他们的实现。
不知道你有没有发现，我今天总提到一个字快，那我们先来思考一下，怎么才能让召回层快起来呢？我们知道排序层慢的原因是模型复杂，算法计算量大。
那我们能不能反其道而行之，用一些简单直观的策略来实现召回层呢？当然是可以的。
这个呀就是所谓的单策略召回。
单策略召回指的是通过制定一条规则，或者利用一个简单模型来快速召回可能的相关物品。
这里的规则其实就是用户可能感兴趣的物品的特点。
我们拿spiracxx里面的电影推荐。
举个例子，在推荐电影的时候，我们首先要想到用户可能会喜欢什么电影。
按照经验来说，很有可能是这三类大众口碑好的近期非常火热的，以及跟我之前喜欢的电影风格。
类似的基于其中的任何一个特点，我们都可以快速实现一个单策略召回层。
比如说在spell rex中，我就制定了这样一条召回策略。
如果用户对电影a的评分较高，比如说超过四分，那我们就把和a风格相同的，而且平均分在前五十的定义召回，把它们放到排序候选，激励单策略召回非常简单，直观。
也正因为简单，所以它的计算速度非常快，不过它也有一个缺点。
我想你应该也发现了，就是它有很强的局限性。
因为大多数时候用户的兴趣是非常多元的，他们不仅喜欢自己感兴趣的电影，也喜欢热门的。
当然很多时候也喜欢新上映的，这时候单一策略就难以满足用户的潜在需求了。
那有没有更全面的召回策略呢？针对这个问题，多路召回方法就应运而生了。
所谓多路召回策略，就是指我们采用不同的策略特征或者简单模型，分别召回一部分候选集。
然后把候选集混合在一起，供后续排序模型使用的策略。
其中各简单策略保证候选集的快速召回，从不同角度设计的策略又能保证召回率接近理想的状态，不至于损伤排序效果。
包以多路召回策略是在计算速度和召回率之间进行权衡的结果。
啊，这里我们还是以电影推荐为例来进一步的解释。
你可以看我在文稿中给出的电影推荐中常用的多路召回策略，包括热门电影风格类型，高分评价、最新上映朋友喜欢等等。
除此之外，我们也可以把一些推断速度比较快的简单模型，包括逻辑回归、写通过率等等。
生成的推荐结果放入到多路召回层中，形成综合性更好的候选集。
具体的操作过程就是我们分别执行这些策略，让每个策略选取top cake物品，最后混合多个top k物品，就形成最终的多路召回候选集了。
在spark access中，我们就实现了由风格类型高分评价最新上映这三路召回策略组成的多路召回方法。
具体代码你可以看一下文稿。
那在实现的过程中，为了进一步优化召回效率，我们还可以通过多线程并行，建立标签特征索引，建立常用召回以及缓存等方法来进一步完善。
不过，多路召回策略虽然能够比较全面的照顾到不同的召回方法，但也存在着一些缺点。
比如，在确定每一路的召回物品数量的时候，总是需要大量人工参与和调整，具体的值也需要经过大量的线上AB test来决定。
此外，因为策略之间的信息和数据是割裂的，所以也很难综合考虑不同策略对一个物品的影响。
那是否存在一个综合性强且计算速度也能满足需求的召回方法呢？这就要提到我们前面讲过的多种离线生成物品embedding的方案，一实面利用物品和用户embedding相似性来构建召回层是深度学习推荐系统中非常经典的技术方案。
我们可以把它的优势总结为三个方面，一方面，多路召回中使用的兴趣标签、热门度、流行趋势、物品属性等信息，都可以作为embedding方法中的附加信息一合进最终的embedding向量中。
因此啊在利用embedding召回的过程中，我们就相当于考虑到了多路召回的多种策略。
另一方面，embedding召回的评分具有连续性。
我们知道，多路召回中不同召回策略产生的相似度热度等分值不具备可比性。
所以我们没办法根据这些来决定每个召回策略放回候选集的大小，但是embedding召回却可以把embedding间的相似度作为唯一的判断标准。
因此，它可以随意限定召回的候选集大小。
最后，在线上服务的过程中，embedding相似性的计算也相对简单和直接通过简单的点击或余弦相似度的运算，就能够得到像似得分，让线上的找回方法变得很方便。
那在spire recess中，我们也实现了基于embedding的召回方法。
我把具体的代码放在了文稿里，你可以参考一下这里，我可以简单梳理一下整体的思路。
总的来说，我们通过三步生成了最终的候选集。
第一步，我们获取用户的embedding.第二步，获取所有物品的候选集，并且逐一获取物品的embedding,计算物品embedding和用户embedding的相似度。
啊，第三步，我们根据相似度的排序，返回规定大小的候选集在这三步之中，最主要的时间开销在第二步。
虽然它的时间复杂度是线性的，但当物品集过大的时候，线性运算也可能造成很大的时间内容好，有没有什么方法能够进一步的缩小embedding召回层的运算时间呢？啊，这个问题我们留到下节课来进行进一步的讨论。
好了，今天的内容讲完了，我们来总结一下你要掌握的重点内容。
今天，我们一起讨论了推荐系统中召回层的功能特点和实现方法，并且重点讲解了单策略、召回、重路内容以及深度学习。
推荐系统中常用的embedding召回。
为了方便你对比它们之间的技术特点，我总结了一张表格，放在了文稿里，你可以去看一看。
那总的来说，关于召回层，我总结了一个特点的时间方案。
那特点就是召回层的功能特点，它要快速、准确的过滤出相关物品，缩小候选集。
啊，三个方案指的是实现召回层的三个技术方案，简单快速的单策略召回啊，业界主流的多度召回，深度学习推荐系统中最常用的embedding召回。
这三种方法基本囊括了现在业界推荐系统的主流召回方法。
希望通过这节课的学习，你能掌握这一关键模块的实现方法。
相信你也一定发现了召回层技术的发展是循序渐进的。
因此我希望你不仅能够学会应用他们，更能够站在前人的技术基础上进一步推进它的发展。
这也是工程师这份职业最大的魅力。
最后我们来看两道思考题啊，第一道是你能根据我今天讲的内容，在spiral access中实现一个多线程版本的多路召回策略吗？啊，第二道啊，你觉得对于embedding召回来说，我们怎么做才能提升计算embedding相似度的速度？好了，欢迎把你的思考和答案写在留言区。
如果有收获，我也希望你能把这节课分享给你的朋友们，我们下节课见。