召回粗排精排-级联漏斗（下）

阳光穿透心脏的1/2处 2022-09-15 12:37 137阅读 0赞

![38796dec65489781fe835c689031ba23.png][]

> > > > 文 | 水哥  
> > > > 源 | 知乎

## saying ##

> 召回区分主路和旁路，主路的作用是个性化+向上管理，而旁路的作用是查缺补漏。  
> 推荐系统的前几个操作可能就决定了整个系统的走向，在初期一定要三思而后行。  
> 做自媒体，打广告，漏斗的入口有多大很重要。美妆，游戏，篮球入口都非常大，做刷题的自媒体会把自己饿死（说的就是我自己）。

召回这里稍微有些复杂，因为召回是多路的。首先我们要解释主路和旁路的差别，主路的意义和粗排类似，可以看作是一个入口更大，但模型更加简单的粗排。主路的意义是为粗排分担压力。但是旁路却不是这样的，旁路出现的时机往往是当主路存在某种机制上的问题，而单靠现在的这个模型很难解决的时候。举个例子，主路召回学的不错，但是它可能由于某种原因，特别讨厌影视剧片段这一类内容，导致了这类视频无法上升到粗排上。那这样的话整个系统推不出影视剧片段就是一个问题。从多路召回的角度来讲，我们可能需要单加一路专门召回影视剧的，并且规定：主路召回只能出3000个，这一路新加的固定出500个，两边合并起来进入到粗排中去。这个栗子，是出现旁路的一个动机。这个过程我们可以用下图来表示：

![705c464964c0eb65d8b8e4d087833a3c.png][]

在上面的图中，梯形的大小表示透出率的大小。

## 典型的召回都有哪些？ ##

第一种召回，是非个性化的。比如对于新用户，我们要确保用最高质量的视频把他们留住，那么我们可以划一个“精品池”出来，根据他们的某种热度排序，作为一路召回。做法就是新用户的每次请求我们都把这些精品池的内容当做结果送给粗排。这样的召回做起来最容易，用sql就可以搞定。

第二种召回，是i2i，i指的是item，严格意义上应该叫u2i2i。指的是用用户的历史item，来找相似的item。比如说我们把用户过去点过赞的视频拿出来，去找画面上，BGM上，或者用户行为结构上相似的视频。等于说我们就认为用户还会喜欢看同样类型的视频。这种召回，既可以从内容上建立相似关系（利用深度学习），也可以用现在比较火的graph来构建关系。这种召回负担也比较小，图像上谁和谁相似完全可以离线计算，甚至都不会随着时间变化。

第三种召回是u2i，即纯粹从user和item的关系出发。我们所说的双塔就是一个典型的u2i。在用户请求过来的时候，计算出user的embedding，然后去一个实现存好的item embedding的空间，寻找最相似的一批拿出来。由于要实时计算user特征，它的负担要大于前面两者，但这种召回个性化程度最高，实践中效果也是非常好的。

## 召回的学习目标 ##

一般来说，个性化程度最高的双塔，都会成为主路。它的学习目标，可以类比粗排和精排的关系去学习召回和粗排的关系。而基于graph或者图像相似度的召回，则有各自自己的学习目标。

## 召回的评估方式 ##

主路召回，我们可以采用粗排的方式，以粗排的序计算NDCG，或者TopN重叠率。但是旁路召回在线下是比较难以评估的。如果采用一样的方式评估旁路，那旁路的作用岂不是和主路差不多？那旁路存在的意义是啥呢？不如把改进点加到主路里面去好了。在实际中，旁路召回虽然线下也会计算自己的AUC，NDCG等指标。但是往往都是只做一个参考，还是要靠线上实验来验证这路召回是不是有用。

在线上，除了AB需要看效果以外，有一个指标是召回需要注意的：**透出率**，**指的是最终展示的结果中，有多少比例是由这一路召回提供的**。如果我们新建了一路召回，他的透出率能达到30%，AB效果也比较好，那我们可以说这一路召回补充了原有系统的一些不足。反过来，如果你的透出率只有1点几，2点几，那不管AB是涨是跌，我都很难相信结果和这一路召回有关系，似乎也没有新加的必要。

## 多路的结果如何融合？ ##

多个召回之间的结果综合的时候，要进行去重，可能有多个路返回了用样的item，这时候要去掉冗余的部分。但是，去重的步骤比较是需要经过设计的。有以下几种方法来进行融合：

*  先来先到：按照人为设计，或者业务经验来制定一个顺序，先取哪一路，再取哪一路。后面取得时候如果结果前面已经有了，就要去掉。
 *  按照每一路打分平均：比如第一路输出A=0.6，B=0.4，第二路输出B=0.6，C=0.4，那么由于B出现了两次，B就需要平均一下，最后得到，A=0.6，B=0.5，C=0.4
 *  投票：和上面的例子类似，但是B出现了两次。我们认为B获得了两个方面的认可，因此它的排序是最靠前的。

注意上面的item最后留下的是哪一路的，透出率就算在谁头上。

## 召回的问题 ##

假设我们有三路召回ABC，在我们这个时空，业务部署的顺序是A-B-C；在另一个平行时空，业务的部署顺序是C-B-A。问：其他变量都不变的情况下，最终业务的收益是一样的吗？

我个人的理解是，几乎不会一样。**先部署的召回会影响整个系统，后来的不管是什么方案，都要在不利于自己的情况下“客场作战”**。举一个极端的例子，A是一个特别喜欢土味视频的召回，我们第一版实现的是它。结果A上线以后，不喜欢土味视频的用户全都跑路了。在迭代的过程中我们就会想，唉是不是我们也可以加一路B来专门召回高雅类型视频啊。这时候上线一做，并没有正向，因为喜欢高雅的用户已经没了。这就是部署顺序给整个系统带来后效性的一个极端例子。如果我们一开始换一种做法，先上一路中规中矩的召回C，然后把AB当做补充的旁路加进来，效果是有可能更好的。

因此在最初的时候的操作一定要小心。否则会对算法同学带来很大的后续负担，比如上面这个例子，有一天领导说哎我们现在不够高雅你来搞一个，那你就只能为初期的不正确决定买单了。这个问题并不是说粗排，精排就不会出现。而是在实践中召回这里更容易出现。因为召回的某些方法实现很快，同学很可能一看有收益就推上去了。

## 入口的规模至关重要 ##

前面讲的漏斗都是针对于item筛选这个角度。从生产者的角度也存在这么一个漏斗：

![b5cfa72765a7c4672e4a000ec52b9315.png][]

一开始是吸引所面向的人群，然后一部分人会点击，点击的人中，一部分人会转化，可能后面会有深度转化等等。最终目的是广告主的获益。这里要说明一下，深度转化是相对于某些行业才有的，比如说电商里面转化了就是购买行为发生了，那已经获利了就不需要后面环节了。而对于游戏，转化一般指的是下载，用户后续氪金了叫深度转化，对于游戏行业这个时候才算获利。

这个漏斗中有两个因素决定最终获利的大小，**一个是入口的规模，一个是梯形的斜率**。其实在图中，梯形的斜率就可以表示点击率和转化率的大小。如果你的产品很好，这两个指标很高，那留下来的就更多，越能获利。

但是点击率转化率这些东西很难优化（虽然大品牌都有专门的团队来负责）。更多的生产者选择了更简单的那个变量：**赛道决定的漏斗入口大小**。

我们可以以现在这个专栏做一个例子：一般来说，评论是一个很稀疏的行为，假设每10个点赞有1个评论（这样评论率就是10%，这已经是一个非常高的比例了），每10个浏览有1个点赞。我们现在这个专栏的文章，想要获得100个评论，就至少需要10000个对推荐系统感兴趣的读者，这可能都要把知乎上和推荐相关的读者一网打尽了。这就是门槛很高，导致的漏斗的入口很小。但是如果面向的对象是所有学生，那入口就会大很多。

所以这就形成了自媒体的一个现象：选择低门槛。我们可以发现自媒体，往往选择美妆，篮球这样的领域进行创作。因为漏斗的入口足够大，哪个女生不想好看呢？看看篮球又不需要上场去打，也不需要什么思考，门槛也很低。入口足够大，才能保证在链路的最后还有人剩下来。链路的最后往往可能是恰饭，比如说球的可以给球鞋做广告之类的。

## 最后留两道思考题 ##

**第一**

为什么我们需要多路召回，而不是一个主路就把所有的情况都涵盖了？

**第二**

> 刷单，指的是店家付款请人假扮顾客，用以假乱真的购物方式提高网店的排名和销量获取销量及好评吸引顾客。刷单，一般是由卖家提供购买费用，帮指定的网店卖家购买商品提高销量和信用度，并填写虚假好评的行为。通过这种方式，网店可以获得较好的搜索排名……  
> \--来自《百度百科》

1.  为什么刷单对商家有利可图？
2.  它符合我们这两讲中的哪一条性质？
3.  刷单这种手段是否可以检测出来？涉及到哪一类算法？

想到答案的同学可以写在评论里，我们在下一讲的开头会先分析一下这两个问题。

## 下期预告 ##

推荐系统全链路（4）：打压保送重排-模型之外

## 往期回顾 ##

1.[召回 粗排 精排，如何各司其职？][Link 1]

2.[拍不完的脑袋：推荐系统打压保送重排策略][Link 2]

3.[简单复读机LR如何成为推荐系统精排之锋？][LR]

4.[召回粗排精排-级联漏斗（上）][-]

> > ![5be5f82c415b1b97d666ff9ee6c5444d.png][]后台回复关键词【**入群**】
> > 
> > **加入卖萌屋NLP/IR/Rec与求职讨论群**
> > 
> > 后台回复关键词【**顶会**】
> > 
> > **获取ACL、CIKM等各大顶会论文集！**
> > 
> > ![5c130ecd5954f8dd111a31c688e36bdc.gif][]

[38796dec65489781fe835c689031ba23.png]: /images/20220828/c9289bdb030c409bb9c4f74ca77bda4e.png
[705c464964c0eb65d8b8e4d087833a3c.png]: /images/20220828/326ab91f13184f59aab15da0a6b3aa2c.png
[b5cfa72765a7c4672e4a000ec52b9315.png]: /images/20220828/9ccaa0287f7a4531bf00048763ec2a23.png
[Link 1]: https://blog.csdn.net/xixiaoyaoww/article/details/120681737
[Link 2]: https://blog.csdn.net/xixiaoyaoww/article/details/120520709
[LR]: https://blog.csdn.net/xixiaoyaoww/article/details/120278941
[-]: https://blog.csdn.net/weixin_38753262/article/details/114362164
[5be5f82c415b1b97d666ff9ee6c5444d.png]: /images/20220828/a3f7e8ea6dab48f4ac893aefbbd652a7.png
[5c130ecd5954f8dd111a31c688e36bdc.gif]: /images/20220828/bbf5d5aa22b249f1b11c51e11e88b556.png