weighted—-LR的理解与推广

在YouTube团队推荐系统Rank阶段,DNN输出层使用了weighted—LR,这既是这篇论文的一大创新点,也是一大难点。在这里,重新梳理下该算法的思路与推导,并进行推广。

理解

先说下常见的逻辑回归(LR)模型。LR模型假设数据服从伯努利分布,当某件事情发生,认为其概率为p,则当其不发生,概率为1-p。
那么,其几率比(odds)为:

odds=p1p

几率比(odds):指一个事件发生的概率与不发生概率的比值。

对其求对数,并将对数几率记为输入特征值的线性表达式,可得

logit(p1p)=wTx

那么有:

Odds=ewTx

则概率p可推出为logit函数的反函数,也就是sigmoid函数了:

ϕ(x)=11+ewTx

在短视频的CTR预估,一般的,点击发生的概率就是发生点击的视频个数/总共曝光的视频个数,假设发生点击的视频个数为M,总共曝光的视频个数为N,则p为:

p=MN

可得Odds为:

Odds=MNNMN=M/N1M/N

那么,如果我将正样本加上权重wi,会发生什么?
正样本权重w的加入会让正样本发生的几率变成原来的w倍,也就是说样本i的Odds变成了下面的式子:

Odds(i)=wiM/N1wiM/N=wip1wip

注意:这里N的物理含有与之前的N已经不同了,之前代表的是总共曝光的视频个数,这里代表的是总共曝光的视频的权重和,但这并不影响后面的推导。

YouTube推荐中,关键在于正样本权重的选择,它使用了观看时长Ti作为权重,则由于在视频推荐场景中,用户打开一个视频的概率p往往是一个很小的值,因此上式可以继续简化::

Odds(i)=wip=tip=E(Ti)

由于p就是用户打开视频的概率,Ti是观看时长,因此Tip就是用户观看某视频的期望时长。这个的好处就是,当进行Serving时,由于我们只关注相对位置,不关注绝对值,我们只需要计算Odds即可,也就是只需要计算$ e{wTx}$,这样就转化成了根据观看某视频的期望时长进行排序。

那为什么不直接预测观看视频的期望时长呢?一个明显的好处就是,分类的问题一般都比回归问题易于求解,且预测准确率更高。另外,这里使用Weighted LR给我们的启示就是:具体算法一定要根据具体业务场景选择,深刻理解业务的通用性和特殊性,往往比技术更重要。

接下来的问题就是训练了,训练Weighted LR一般来说有两种办法:

  • 将正样本按照weight做重复sampling,然后输入模型进行训练;
  • 在训练的梯度下降过程中,通过改变梯度的weight来得到Weighted LR。

一般采用第二种方法,原因是减少了处理的样本数,减少了读样本时间和更新梯度的次数。

推广

在上面推导的过程中,一个很特殊的业务场景在于在视频推荐场景中,用户打开一个视频的概率p往往是一个很小的值,所以进行了简化。那么,当我们的业务中,概率p并不可以忽略,那么我们将如何优化呢?
在之前的场景中,负样本的权重为1,正样本的权重为wi,实际上Odds为:

Odds(i)=iwiMi/NiNegi/N=i=1Nposwii=1Nneg1=i=1NposwiNneg

上面是因为p概率足够小,也就是Npos相对Nneg很小,所以上面可以近似为:

i=1NposwiNneg=i=1NposwiNneg+Npos=i=1NposwiN

当我们的场景中,概率p(在推荐中即ctr)达到20%甚至更高,直接忽略近似会boost click,那么我们就要在分母项补上Npos的值。显然,我们可以在负样本中随机采样Npos的样本进行填充,即可达到我们的目的。

不得不说,YouTube的这篇推荐系统论文足够经典。每一个小点扩展开来都值得说道和推敲。另外,也说明了在实际落地中,业务理解的重要性。

参考:
揭开YouTube深度推荐系统模型Serving之谜

posted @   Jamest  阅读(6448)  评论(0编辑  收藏  举报
编辑推荐:
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· spring官宣接入deepseek,真的太香了~
点击右上角即可分享
微信分享提示