百度推荐排序技术的思考与实践 _百度推荐

本文将分享百度在推荐排序方面的思考与实践。在整个工业界的推广搜场景上，特征设计通常都是采用离散化的设计，需要保证两方面的效果，一方面是记忆，另一方面是泛化。特征都是通过哈希的方式做成 one hot 的离散化。一、背景首先来介绍一下百度综合信息流推荐的业务背景、数据背景，以及基本的算法策略。
1、百度综合信息流推荐

文章插图
百度的综合信息流包括手百 App 中搜索框的列表页以及沉浸页的形态，有着非常多的产品类型。从上图中可以看到，有类似于抖音的沉浸态的推荐，也有单列的推荐，以及类似于小红书笔记的双列推荐。交互形态也是多种多样的，可以在落地页上进行评论、点赞、收藏，也可以点进作者页中查看作者的相关信息并进行交互，当然也可以有负向的 feedback 等等。
2、数据背景从建模的角度上看，主要面对三方面的挑战：

文章插图

大规模。每天的展现量级超过了百亿级别，因此模型需要有天级别百亿的吞吐能力。每天的 DAU 过亿，这也决定了整个模型需要有高吞吐、高可扩展性的设计。对于排序模型来说，在线每秒钟有数亿次的计算，因此模型设计时不仅要考虑效果，同时也要考虑性能，需要做到很好的性能和效果的折中。用户交互形态以及场景的多样化，还要求模型可以预估多类型任务。
高要求。整个系统的响应时间要求非常高，端到端都是毫秒级的计算，超过了预定的时间，就会返回失败。这也造成了另一个问题，就是复杂结构上线困难。
马太效应强。从数据样本角度上来看，马太效应非常强，少量的头部活跃用户贡献了大多数的分发量，头部的热门资源也覆盖到了大多数的展现量。无论是用户侧还是资源侧，马太效应都是非常强的。因此，系统设计时就需要弱化马太效应，使得推荐更加公平。

3、基本算法策略

文章插图
在整个工业界的推广搜场景上，特征设计通常都是采用离散化的设计，需要保证两方面的效果，一方面是记忆，另一方面是泛化。特征都是通过哈希的方式做成 one hot 的离散化。对于头部用户需要有精细刻画，准确记忆。而对于占比更大的稀疏长尾，则需要很好地泛化。另外，对于用户的点击以及消费决策序列，session 是非常重要的。
模型设计需要平衡很大的头部，使整个数据呈现出 Beta distribution 的分布，需要平衡头部的准确以及长尾的泛化。由于特征设计已经做了这方面的考量，模型的设计也需要同时兼顾泛化以及准确。百度整个的推荐漏斗对性能要求是非常极致的，所以要考虑到架构跟策略的联合设计，需要考虑性能与效果的折中，另外也需要考虑平衡模型的高吞吐性以及精度。
架构的设计也要从性能和效果这两个维度来综合考量。一个模型算不动所有数千万的资源库，所以必须要做分层的设计，核心思想是分治法。当然各层之间是有关联的，所以会做多阶段的联训，来提升多阶段漏斗之间的效率。另外，还有弹性计算法，保证在资源几乎不变的情况下，上线非常复杂的模型。
上图中右侧的汉诺塔项目，在粗排这一层非常巧妙地实现了用户与资源的分离建模。还有 CTR3.0 联合训练，实现了多层多阶段的联训，比如精排，是整个系统中最复杂、最精致的模型，精度是相当高的，重排是在精排之上做 list wise 的建模，精排跟重排的关系是很紧密的，我们提出的基于这两个模型联训的方式，取得了非常好的线上效果。
接下来，将分别从特征、算法和架构三个角度进一步展开介绍。

二、特征1、用户-系统交互决策过程特征描述了用户与系统之间的交互决策过程。
下图中展示了用户-资源-场景-状态时空关系交互矩阵图。