本文详述了YouTube早期的视频推荐系统，探讨了在海量数据、用户行为噪声和视频短暂生命周期等挑战下，如何构建召回、精排和展示机制。召回阶段采用规则基础方法，精排阶段建立线性函数评估视频质量，最终通过展示策略确保多样性。该系统上线后显著提升了CTR，至今其框架仍具指导意义。
1. 文章简介
这篇文章是一篇经典老文了，10年的，大约算是推荐系统的开山文章之一了，以至于到了现在，里面用到的技术现在除非是冷启动的时候，否则个人感觉已经基本没怎么听说了。
不过经典之所以为经典还是在于其提出的问题到现在还是推荐系统里面的核心问题，各种文章各种技术事实上也就是针对这些问题进行的优化，所以读读经典无论何时感觉都还是有意义的。
2. 问题 & 难点描述
这篇文章针对的问题在于youtube视频网站的用户推荐。也就是说，目标在于给每一个用户推荐出和他们兴趣相贴合的高质量视频。
因此这里也就会出现几个问题：
- 推荐质量层面：
- 如何来描述一个视频，尤其在视频的meta信息比较差的情况下，如何准确地表述一个视频的特征信息；
- 如何来描述一个用户的兴趣特征信息，尤其当用户的行为信息充满噪声的情况下；
- 系统实现层面：
- 视频数据库总量极大，如何做到快速的检索；
- 视频的生存周期较短，需要高速的进行迭代；
某种意义上来说，做新闻推荐的同学大概对于这些问题会更有感触一点，不过我理解新闻较之视频可能还会更好一点，因为毕竟新闻而言无论是标题、内容来说都会更优质一点。
3. 系统架构
youtube视频的推荐系统架构我理解主要和现在的推荐系统架构差不多，也是数据表配合一个推荐系统，前者用于存储信息，后者则是一个线上服务，从数据表中读取数据然后处理成推荐视频信息进行展示。
1. 数据表
要构建一个推荐系统显然需要对应数据表来储存用户行为信息以及全部的视频信息，然后每一次用户行为都会触发系统写入日志，然后更新用户行为信息表格。
而推荐系统则是从这两张表格当中读取信息然后进行视频召回。
2. 推荐系统
推荐系统的架构方面，和现在的推荐系统依然是基本完全一致的，都包含三层框架，召回，精排，以及最后的展示阶段。
1. 召回
召回阶段的功能在于说从全体的视频样品当中初筛出和用户相关的视频，从而大幅缩减候选视频的数量量级。
具体方法当然可以有很多了，而这里，youtube则是使用了一个非常简单的rule based的召回方法，即他直接通过所有用户的点击行为来计算两个视频之间的相关度，然后以用户的点击视频作为种子，召回和他看过的视频相似度最高的视频，当然，为了增加多样性，这里他们重复召回了多轮并保留了所有的结果。
当然，现在召回方面基本都在用模型了，这个方法本身感觉应该是很少有人在用了……
2. 精排
精排阶段的目标在于对于召回的视频进行一个打分排序，从而令高质量的视频能够获得更高的展示优先顺位。
具体如何表述视频的高质量则是包括以下三个角度：
- 视频本身的质量；
- 视频与用户的关联性；
- 视频与当前已展示视频之间的多样性；
youtube在这篇文献当中同样只是建立了一个线性函数进行打分评估，现在也基本都换成模型了，但是这套框架本身还是在的。
3. 展示
最后就是实际的视频展示阶段，由于展示视频事实上总量并不多，因此他事实上只是上述精排结果的一个子集，因此，这里就会根据一套规则系统来进行视频选择然后进行展示，确保展示视频在不同次展示之间的多样性（cross session diverity），以及单次展示当中视频的多样性（within session diversity）。
4. 评估 & 效果
而关于推荐系统的效果评估，文中则是主要通过上线AB测试之后比较CTR以及Long CTR，后者与前者的区别在于只保留了观看时长超过了一定阈值的观看结果进行统计。
整体而言，这套推荐系统上线之后贡献了youtube当中当时60%的点击，然后在baseline的基础上提升了一倍以上的ctr。
5. 结论 & 思考
结论而言，这篇文章当中提出的方法到目前位置基本已经都过时了，目前基本感觉就是模型一统天下，不过这套框架以及评测方式却是依然保留了下来，任何做推荐的朋友大概都绕不开这套东西，不得不说，google到底还是厉害……
扫一扫
965
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
