weighted—-LR的理解与推广
在YouTube团队推荐系统Rank阶段,DNN输出层使用了weighted—LR,这既是这篇论文的一大创新点,也是一大难点。在这里,重新梳理下该算法的思路与推导,并进行推广。
理解
先说下常见的逻辑回归(LR)模型。LR模型假设数据服从伯努利分布,当某件事情发生,认为其概率为p,则当其不发生,概率为1-p。
那么,其几率比(odds)为:
几率比(odds):指一个事件发生的概率与不发生概率的比值。
对其求对数,并将对数几率记为输入特征值的线性表达式,可得
那么有:
则概率可推出为函数的反函数,也就是函数了:
在短视频的CTR预估,一般的,点击发生的概率就是发生点击的视频个数/总共曝光的视频个数,假设发生点击的视频个数为M,总共曝光的视频个数为N,则为:
可得Odds为:
那么,如果我将正样本加上权重,会发生什么?
正样本权重的加入会让正样本发生的几率变成原来的倍,也就是说样本的Odds变成了下面的式子:
注意:这里的物理含有与之前的已经不同了,之前代表的是总共曝光的视频个数,这里代表的是总共曝光的视频的权重和,但这并不影响后面的推导。
YouTube推荐中,关键在于正样本权重的选择,它使用了观看时长作为权重,则由于在视频推荐场景中,用户打开一个视频的概率往往是一个很小的值,因此上式可以继续简化::
由于就是用户打开视频的概率,是观看时长,因此就是用户观看某视频的期望时长。这个的好处就是,当进行Serving时,由于我们只关注相对位置,不关注绝对值,我们只需要计算Odds即可,也就是只需要计算$ e{wTx}$,这样就转化成了根据观看某视频的期望时长进行排序。
那为什么不直接预测观看视频的期望时长呢?一个明显的好处就是,分类的问题一般都比回归问题易于求解,且预测准确率更高。另外,这里使用Weighted LR给我们的启示就是:具体算法一定要根据具体业务场景选择,深刻理解业务的通用性和特殊性,往往比技术更重要。
接下来的问题就是训练了,训练Weighted LR一般来说有两种办法:
- 将正样本按照weight做重复sampling,然后输入模型进行训练;
- 在训练的梯度下降过程中,通过改变梯度的weight来得到Weighted LR。
一般采用第二种方法,原因是减少了处理的样本数,减少了读样本时间和更新梯度的次数。
推广
在上面推导的过程中,一个很特殊的业务场景在于在视频推荐场景中,用户打开一个视频的概率往往是一个很小的值,所以进行了简化。那么,当我们的业务中,概率并不可以忽略,那么我们将如何优化呢?
在之前的场景中,负样本的权重为1,正样本的权重为,实际上Odds为:
上面是因为概率足够小,也就是相对很小,所以上面可以近似为:
当我们的场景中,概率(在推荐中即ctr)达到20%甚至更高,直接忽略近似会boost click,那么我们就要在分母项补上的值。显然,我们可以在负样本中随机采样的样本进行填充,即可达到我们的目的。
不得不说,YouTube的这篇推荐系统论文足够经典。每一个小点扩展开来都值得说道和推敲。另外,也说明了在实际落地中,业务理解的重要性。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· spring官宣接入deepseek,真的太香了~