【推荐系统】YouTube推荐系统架构的十大工程问题

简介: 【推荐系统】YouTube推荐系统架构的十大工程问题

YouTube是世界上最大的创建、分享和发现视频内容的平台。YouTube的建议负责帮助超过10亿用户从不断增长的视频语料库中发现个性化内容。在本文中,我们将重点关注深度学习最近对YouTube视频推荐系统所产生的巨大影响。该图说明了在YouTube移动应用程序主页上的建议。从三个主要的角度来看,推荐YouTube上的视频是极具挑战性的:

  • 规模:许多现有的推荐算法被证明适用于小问题,但都不能在我们的规模上运行。高度专业化的分布式学习算法和高效的服务系统对于处理YouTube庞大的用户群和语料库至关重要。
  • 新鲜度:YouTube有一个非常动态的语料库,每秒可以上传很多小时的视频。推荐系统应该有足够的响应能力,以模拟新上传的内容以及用户所采取的最新行动。平衡新内容有了完善的视频,就可以从探索/开发的角度来理解。
  • 噪声:由于稀疏性和各种难以观察到的外部因素,在YouTube上的历史用户行为本质上难以预测。我们很少得到用户满意度的基本真相,而是建模有噪声的隐式反馈信号。此外,与内容相关联的元数据结构不佳,而没有一个定义良好的本体。我们的算法需要对我们的训练数据的这些特殊特征具有鲁棒性。

YouTube推荐系统架构如下:

  • Candidate Generation:这个部分相当于召回层,从几亿视频语料库中筛选出几百个候选视频
  • Ranking:这个部分对于海选出的几百个视频进行精排,加入更加细粒化的特征用于构建模型,进而找出评分最高的topN视频推荐给用户

Candidate Generation DNN模型

DNN输入层的特征总共分为3个部分:

  • embedde video watches:该特征为所有video的特征信息,这里为了将其统一输入模型进行了Embedding处理,然后使用平均池化Embedding
  • embedded search tokens:该特征使用户搜索词进行Embedding处理
  • 用户特征:包括用户的年龄、性别等粗粒化的特征信息

之后将这3部分的Embedding向量进行横向拼接,然后送入后面的MLP层,进行训练,这里YouTube是将预测作为多分类,分别对应几百万个视频的概率情况,也就是SoftMax。

Ranking DNN模型

DNN输入层的特征总共分为5个部分:

  • impression video ID:候选视频的特征信息,这里将其进行Embedding
  • watched video IDs:用户已经看过的视频的特征信息,将每个看过的视频进行平均化Embedding
  • language embedding:该特征是候选视频的语言和用户的语言的Embedding
  • time since last watch:用户上次看相似视频的时间
  • previous impressions:用户先前看过的候选视频

YouTube推荐模型架构的十大工程问题

这里是看了王喆老师的文章获得的感想,将其总结记录

1、文中把推荐问题转换成多分类问题,在next watch的场景下,每个video都会是一个分类,因此总共的分类将会有数百万之巨,这在使用softmax训练时无疑是非常低效的,这个问题YouTube是如何解决的?

YouTube团队进行了负采样并采用importance weighting的方法对采用进行calibration。

2、在candidate generation model的serving过程中,YouTube为什么不直接采用训练时的model进行预测,而是采用了一种最近邻搜索的方法?

由于在model serving过程中对几百万个候选集逐一跑一遍模型的时间开销显然太大了,因此在通过candidate generation model得到user 和 video的embedding之后,通过最近邻搜索的方法的效率高很多,只需要将用户和视频的Embedding存到内存即可。

3、Youtube的用户对新视频有偏好,那么在模型构建的过程中如何引入这个feature?

模型引入了“Example Age”这个特征,它代表着视频距离当前的发布时间间隔。

4、在对训练集的预处理过程中,YouTube没有采用原始的用户日志,而是对每个用户提取等数量的训练样本,这是为什么?

这是为了减少高度活跃用户对于loss的过度影响。

5、YouTube为什么不采取类似RNN的Sequence model,而是完全摒弃了用户观看历史的时序特征,把用户最近的浏览历史等同看待,这不会损失有效信息吗?

会导致模型过度拟合上个时间段的数据,如果一个用户刚刚点开某个领域的视频,会导致模型过度推荐这个领域的视频给用户造成不好的体验感。

6、在处理测试集的时候,YouTube为什么不采用经典的随机留一法(random holdout),而是一定要把用户最近的一次观看行为作为测试集?

主要是为了避免引入future information,产生与事实不符的数据穿越。

7、在确定优化目标的时候,YouTube为什么不采用经典的CTR,或者播放率(Play Rate),而是采用了每次曝光预期播放时间(expected watch time per impression)作为优化目标?

因为 watch time更能反应用户的真实兴趣,从商业模型角度出发,因为watch time越长,YouTube获得的广告收益越多。而且增加用户的watch time也更符合一个视频网站的长期利益和用户粘性。

8、在进行video embedding的时候,为什么要直接把大量长尾的video直接用0向量代替?

把大量长尾的video截断掉,主要还是为了节省online serving中宝贵的内存资源。

9、针对某些特征,比如#previous impressions,为什么要进行开方和平方处理后,当作三个特征输入模型?

这是为了引入非线性特征,提高模型的拟合能力。

10、为什么ranking model不采用经典的logistic regression当作输出层,而是采用了weighted logistic regression?

我们已经知道模型采用了expected watch time per impression作为优化目标,所以如果简单使用LR就无法引入正样本的watch time信息。因此采用weighted LR,将watch time作为正样本的weight,在线上serving中使用e(Wx+b)做预测可以直接得到expected watch time的近似,完美。

参考文章

王喆-YouTube推荐系统


目录
相关文章
|
7月前
|
SpringCloudAlibaba Java 网络架构
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(二)Rest微服务工程搭建
175 0
|
7月前
|
机器学习/深度学习 搜索推荐 算法
深度学习推荐系统架构、Sparrow RecSys项目及深度学习基础知识
深度学习推荐系统架构、Sparrow RecSys项目及深度学习基础知识
236 0
|
7月前
|
SQL 分布式计算 搜索推荐
【推荐系统】推荐业务架构介绍(一)
【推荐系统】推荐业务架构介绍(一)
239 0
|
存储 监控 搜索推荐
【业务架构】业务驱动的推荐系统相关技术总结
【业务架构】业务驱动的推荐系统相关技术总结
121 0
|
7月前
|
机器学习/深度学习 搜索推荐 算法
优秀的推荐系统架构与应用:从YouTube到Pinterest、Flink和阿里巴巴
优秀的推荐系统架构与应用:从YouTube到Pinterest、Flink和阿里巴巴
209 0
|
存储 人工智能 架构师
ChatGPT 与软件架构 (4) - 架构师提示工程指南
ChatGPT 与软件架构 (4) - 架构师提示工程指南
145 0
|
2月前
|
缓存 前端开发 JavaScript
前端的全栈之路Meteor篇(二):容器化开发环境下的meteor工程架构解析
本文详细介绍了使用Docker创建Meteor项目的准备工作与步骤,解析了容器化Meteor项目的目录结构,包括工程准备、环境配置、容器启动及项目架构分析。提供了最佳实践建议,适合初学者参考学习。项目代码已托管至GitCode,方便读者实践与交流。
|
7月前
|
存储 运维 关系型数据库
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
2024年最全ceph的功能组件和架构概述(2),Linux运维工程面试问题
|
3月前
|
负载均衡 数据库 开发工具
|
4月前
|
安全 IDE Java
从0到1探索淘宝短视频流的架构再设计和工程重构
随着视频流业务的发展,业务的复杂性越来越高,视频流老工程在架构设计、代码质量、工程能力等方面的问题也逐渐凸显。本次重构是一次对大型业务工程进行架构再设计和重构的探索,本文是对这次探索的一次梳理与总结。