YouTube视频推荐系统

[免责说明：本文是翻译文章，原文链接见文末。本文翻译并未按照原文逐字翻译，而是在我理解的基础上做了修改，中括号内文字是本人自行添加。本文翻译是在Google翻译的基础上做了增删，望包涵。]

[文章说明：我最近在作视频推荐方面的工作，查询资料时偶尔看到这篇paper。很多博客说的比较含糊，本着细节决定成败的理念，抽时间翻译了它，作为自己的参考。]

[文章大意：这篇paper概述了2010年的youbube视频推荐系统。系统主要使用基于物品的协同过滤方法进行视频推荐。它计算相似物品的方法是基于物品关联规则来做的，用的数据是用户的播放行为。本文让我学到的是搜索相似物品的方式，它依据工程实践的经验，将原本的一层搜索，变成了n层搜索相似物品。]

YouTube视频推荐系统(2010)

JamesDavidson, Benjamin Liebald, Junning Liu, Palash Nandy, Taylor VanVleet all in Google Inc

摘要

本文讨论YouTube使用的视频推荐系统。系统会依据用户在网站上的活动推荐个性化的视频集合。本文讨论了我们遇到的特殊挑战和解决方法。同时，我们还提供了关于用来测试和调整新算法的实验平台的细节信息，也会论述在这些实验中的发现。

1.概要

在今天到处都是网络信息的环境里，个性化推荐是一种信息提取和内容挖掘的关键方法。结合直接的搜索方式和浏览，它们[应该是指搜索，浏览，推荐这三种方式]使得面对海量信息的用户可以高效、满意地浏览网络信息。YouTube上有大量的用户上传内容，在个性化上面对很多困难。

YouTube成立于2005年2月，迅速发展成为全球最受欢迎的视频网站。用户来到YouTube发现，观看和分享原创视频。YouTube为人们提供了一个论坛，让人们可以在全球范围内参与视频内容，并作为内容创作者的发布平台。每天，数百万用户在数百万视频中进行了超过10亿次视频播放，而用户每分钟上传到YouTube的视频超过24小时。

本文介绍YouTube视频推荐系统，它基于用户在YouTube的历史活动，给登录用户提供个性化视频集合。（非登录用户也可以使用受限的个性化推荐，本文只讨论针对登录用户的个性化。）

1.1目标

用户来YouTube的目的可以划分成三种：

1是观看在其他地方发现的视频（直接搜索类型）

2是寻找某一主题的视频

3是浏览来发现自己有趣的视频。推荐系统主要针对最后一种没有目的用户。

系统的目标是为用户提供和他们的兴趣相关的视频。为了好玩和参与度，这些内容必须定期更新并反应用户最近在网站上的活动。这么做也是为了突出网站的内容。

在目前的形式下，我们的推荐系统是一个顶级的N推荐器，而不是预测器。YouTube推荐的另一个主要目标是维护用户隐私并明确控制我们的后端系统所暴露的个性化用户数据。我们在第2.5节讨论我们如何达到这个目标。

1.2挑战

在进行个性化视频推荐的过程中遇到很多挑战，其中一个是很多用户上传的视频没有或者具有很少描述信息。视频的数量大致与用户数量是一个量级。另外YouTube的视频大部分是短视频（十几分钟），导致用户的交互很短暂，并且有大量的噪音数据。

这是netfix或者amzon不同的情况。此外，YouTube上很多有趣的视频的周期都很短（从上传到很火），我们需要持续推荐新鲜的视频。

2.系统设计

系统的设计是受如下目标驱动的：我们计划推荐出合理又新鲜的视频，并且还要和用户最近的活动相关。另外，我们认为让用户理解为什么会推出这些视频很重要。

我们把用户的个人活动（观看、收藏、喜欢）作为种子，并且把共同观看行为作为基础构建由视频作为结点的图，根据种子在图中的扩展组成推荐的视频集合。集合中的视频然后依靠最新和多样性等原则进行排序。

从工程的角度来看，我们计划系统的每个模块应该是相互解藕的，并且做到单独调试。鉴于我们的系统是更大的YouTube生态系统的一部分，建议还需要对故障具有恢复能力，并在出现部分故障时适度降级。因此，我们力求将整个系统的复杂性降至最低。

2.1输入数据

在产生个性化视频时，我们考虑如下数据源：1）视频内容信息，比如视频的标题、描述等等；2）用户活动数据，这些又分为显式活动数据和隐式活动数据。显式数据包括给视频打分、喜欢或者收藏视频，或增加描述或者上传视频。隐式数据包括用户的播放行为，交互行为，观看视频的时长等。

以上各种情况下，我们都需要处理噪音数据。比如视频描述信息可能不存在，不完整或者过时或者不正确。用户行为数据只是捕获一个描述用户在本站活动的分数，不直接表现用户的参与和喜好。事实上，在整体活动中，用户观看了一个视频并不能概括出他喜欢它。视频的长度和用户参与的程度都明显影响信息的质量[推荐要先注重准确度，然后是多样性]。另外，用户的隐式行为数据可能是没有同步的，并且也可能是不完整的。[这个需要软件进行上报用户的行为，可能上报错误，也可能没有上报]。用户可能在我们收到他观看一个长视频的行为上报之前就关闭了浏览器。

2.2相似视频

推荐系统中一个重要的部分是构建一个视频的相似视频集合。在本文我们定义v的相似视频是用户观看视频v后有很大可能接着观看的视频。为了计算这种关联关系，我们使用经典的关联规则挖掘技术。考虑用户观看活动在本站的周期。在给定的周期内（比如24小时），我们计算两个视频在一个周期内被共同观看的频率，定义是两个视频在一个周期内被共同观看的次数。我们定义以视频vi为基础视频，视频vj的关联度如下：

其中ci和cj代表在所有的用户周期内视频vi和vj分别出现的次数。f是一个规范化函数，目的是将vi和vj的全局流行度考虑在内。一个最简单的规范化函数是，其他的规范化函数也是可行的。当我们使用这个公式时，ci对于所有的候选视频都是相同的，我们可以不考虑。规范化的结果只和候选视频的全局流行度相关[即vj和vi视频同时出现的次数在vj出现次数总和中的占比]，这是为了帮助不流行的视频提高权重。

接着我们将topN个视频作为vi的关联视频，排序依据关联度r。两个我们还设定了r的最小值界限。因为有的视频对，共同出现的次数太少，不能使用这个方法计算关联度。

注意，这里只是简单做了描述。事实上，还有许多问题需要解决，比如观看行为中的噪音数据等。而且除了共同观看这个数据，还有其他数据可以利用，如视频观看的时间戳和顺序，视频的描述信息等。

利用计算出的关联视频，可以制作有向图。对每个关联视频对(vi,vj)，存在一条边从vi到vj并且权重是关联度。

2.3产生候选推荐视频

为了计算推荐视频，我们将用户的历史活动和关联视频结合在一起。这些历史活动数据包括观看的视频（通常有个阈值限制），也包括喜欢，点赞，收藏，加入播放列表等行为。我们把这些活动中的视频称为种子视频。

为了给种子视频集合S计算候选视频，我们沿着关联视频组成的有向图的边进行扩展。对于S中的视频vi，我们获取它的关联视频Ri。我们将关联视频的并集记为C1

在很多情况下，C1计算出的集合是足够多，足够多样的，可以推荐有趣的视频。但是实践上，我们发现任何集合的视频计算出的关联视频都很狭窄，往往那些和种子视频很相似的视频得到很高的权重。这样会导致很狭窄的推荐，虽然达到了推荐和用户兴趣相关的视频的目的，但是没有做到给用户推荐新视频的目标。

为了拓宽推荐的视频的范围，我们在关联图上使用受限的传递闭包拓展拓宽候选集。定义Cn为S中任意视频vi能够在n步内到达的视频的集合。

最终的推荐集合是：

由于关联图的高平衡因素，我们发现通过短距离的扩展（n比较小），即使对于S比较小的用户，也能很大扩展候选集合的多样性。我们可以追踪相似视频，给用户解释为什么推荐这些视频。

2.4重排序

我们使用不同的数据进行排序。不同的数据对应排序的不同阶段。1:视频的质量，2:用户的特殊性，3:多样性。

视频的质量因素是指不管哪些用户都会让他喜欢的因素。包括视频的观看次数，视频的评分，评论，收藏，分享和上传时间。[就像计算视频的热度。]

用户的特殊性，是为了抬高满足用户特殊兴趣的视频。为了达到这个目的我们考虑种子视频在用户观看历史中的属性，比如说观看时间，观看时长。

把这些数据线性组合起来，我们就得到来一个排好序的视频候选集列表。因为我们只展示一部分视频（大概4到60个），所以我们必须从列表中选出子集。不是选取最相关的视频，我们希望在相关性和多样性中取得平衡。由于用户通常在不同的时间有不同的兴趣，所以我们会移除相互很相似的视频来增加多样性。一个简单的方法是限制一个种子视频在候选集中能够关联到视频的数目。或者限制来自同一个频道或上传者的视频在候选集中的数目。更多基于主题聚类和内容挖掘的方法也是可以的。

推荐的介绍是整体用户体验的重要组成部分。

有一些值得注意的功能：首先，所有推荐的视频都会显示一个缩略图及其（可能截短的）标题，以及有关视频年龄和流行度的信息。这与主页上的其他部分类似，并帮助用户迅速决定他们是否对视频感兴趣。此外，我们添加一个解释，指向触发推荐的种子视频的链接。最后，我们让用户控制他们希望在首页上看到的推荐位置和推荐数量。

如第2.4节所述，我们计算排序的推荐列表，但仅在服务时间显示子集。这使我们能够在用户每次回到网站时提供新的和以前未曾见过的建议，即使基础建议尚未重新计算。

我们选择面向批处理的预计算方法，而不是按需计算推荐。这具有允许建议生成阶段使用大量CPU资源访问大量数据的优点，同时允许提供的预先生成的建议的延迟极低。这种方法最大的缺点是在生成和提供特定推荐数据集之间的延迟。我们通过流水线化建议生成来减轻这一点，每天更新数据集数次。

YouTube推荐系统的实际实施可以分为三个主要部分：1）数据收集，2）推荐产生和3）推荐服务。 先前在第2.1节中提到的原始数据信号最初存放在YouTube的日志中。这些日志被处理，信号提取，然后存储在每个用户的基础上Bigtable。我们目前处理数百万用户和数百亿活动事件，总数据量为几太字节。建议是通过一系列MapReduces计算生成的，这些计算遍历用户/视频图形来积累和评分建议，如第2节所述。生成的数据集大小相对较小（大小为千兆字节），并且可以通过简化的只读Bigtable服务器轻松提供给YouTube的Web服务器;完成推荐请求的时间主要由网络传输时间决定。

3.实验

在我们的生产系统中，我们通过A/B测试[5]使用实时评估作为评估推荐系统性能的主要方法。在这种方法中，实时流量被转移到不同的组中，其中一组作为控制或基线，另一组暴露于新的特征，数据或UI。然后通过一组预定义的度量将两个组相互比较，并可能交换另一段时间以消除其他因素。这种方法的优点是评估发生在实际网站UI的上下文中。也可以并行运行多个实验并快速获得所有这些实验的反馈。缺点是并不是所有的实验都有可用于比较的合理控制，用户组必须有足够的流量来实现及时地评估文体学意义的结果并评估主观目标仅限于解释一组相对较少的预定义指标。

为了评估推荐质量，我们使用了不同指标的组合。我们考虑的主要指标包括点击率（CTR），较长的点击率（只计算导致观看视频的很大一部分的点击次数），会话长度，第一次长时间观看的时间以及推荐覆盖率（带着推荐的用户）。我们使用这些指标来追踪在持续的基础上评估系统的性能，以及评估实时流量的系统变化。

Ref:http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.434.9301&rep=rep1&type=pdf