正态分布函数大家都知道，不过正态分布函数的积分函数却没有初等形式。不过上面的链接给出了计算正态分布CDF的方法，思想很简单，就是泰勒展开到第6项。

您可能也喜欢：

高精度计算问题

一些关于AUC计算的资源

网络中顶点相似度的计算 node similarity measurement in network

关于推荐系统算法只占10%的讨论

Papers about Serendipity in Recommender Systems

无觅

如果大家写过代码的就可以知道，实际系统的代码是一个比较复杂的工程，我要实现一个算法，需要构造很多类，设计他们的继承关系，考虑代码的可读性和通用性。这样，我写一个程序，也许得很多源代码文件才能实现（当然很多刚写程序的人会把这些写到一个文件里，但这肯定不是好的设计）。于是乎，很多作者写书时就开始狂贴代码，这样显得书很厚，但打开都是代码，而真正有多少人去看了那些代码呢？至少我是不看的。

但是我们这本书不同，我们这本书是以算法为主，工程为辅的。所以这本书并不希望告诉大家应该怎么设计代码结构。我想很多有多年工程经验的人代码写的都很好。这本书的目的是像工程师介绍推荐算法，而如何将这些算法实现是工程师自己的事情。而书中代码的目的是为了让工程师更好的理解算法，因为毕竟很多时候代码是工程师能够够好理解的语言。

因此，本书的代码摒弃了工程实现的那些和算法无关的部分，目的是使每一行代码都和算法之间相关。这也是为什么选择python做为代码的原因。因为python语言能够更好的诠释算法，而不需要为读写文件，解析字符串写一堆和算法无关的东西。我看到很多书，贴了一堆代码，其中50%以上的行和算法是无关的，这不仅浪费读者的时间，也影响读者对算法的理解。

我希望读者能够真正读懂书中的代码，不是本着将代码抄一遍的态度来看书。如果你真正看懂了代码，你一定可以跑起来。但如果我给你贴一个能跑起来的，冗长无比的代码，你不一定能很容易的看懂。

但是，这本书有大量的实验结果，这些实验结果不是凭空掉下来的，这些实验结果一定都是通过一定代码跑出来的。如果有读者奔着将书中代码抄一下的态度，可以参考这些代码。这些代码将会打包在书发表时放在一个地方下载。

下面我给大家举一个例子，说明书中的代码和实际代码的区别。

比如我们要写一个推荐系统的算法，假设就是ItemCF吧，好的工程师都不会直接去写一个叫做ItemCF的类，我们应该先写一个基类：

class RecommenderSystem
{
}

然后这个基类定义了如何读数据集，如何解析文件，如何输出，等等

然后，我们再写一个ItemCF的类继承上面的类

class ItemCF : RecommenderSystem
{
}

这个类有个重要的函数BuildModel，给出了如何建模

class ItemCF : RecommenderSystem
{
void BuildModel(){…}
}

OK，我们的书上只会给出BuildModel这个函数怎么实现的，我不会告诉你应该怎么读文件，解析文件，输出结果。因此，你单单把这个函数拷贝到程序里当然是无法work的。但我们给出的这个函数一定都是从实际的代码中拷贝出来的，如果你实现了读写文件等等模块，把这个函数拷贝过去，一定是可以运行的。

您可能也喜欢：

《推荐系统实践》总结

《推荐系统实践》关于Latent Factor Model

各个领域著名的推荐系统

关于推荐系统算法只占10%的讨论

推荐系统和协同过滤面临的主要问题

无觅

写本书远远比想象的要困难，而且比写博士论文困难多了。因为博士论文你可以假设没多少人会看，而且看的人水平和自己相似。此外，博士论文也就100多页。目前这本书大概写了200页，内容倒是挺全面，方方面面，边边角角都涉及到了。不过都是蜻蜓点水，仅供入门之用。而且显得有点杂。

其实推荐系统很难成为一个独立的学科，因为他用到的知识是其他领域都会用到的，只是用在了推荐这个问题上而已。下面，以FAQ的形式总结一下书的体系和内容。

问题：本书的定位是？
回答：本书注重广度，忽略深度。考虑到这是国内第一本同类型的书，所以还是以入门为主。其实更重要的原因是考虑到自身的限制，个人对理论问题不是特别了解，所以怕写错了贻笑大方。而且，深入的问题可以从书中找到相关论文进行深入研究，所以本书主要起介绍作用。

问题：书里面有代码吗？
回答：有，虽然我号称书里面的代码都是Python，不过经Python高手反应，说写的不像Python。不过，书里面的代码主要是作为一种沟通语言存在，起到解释公式的作用。所以书中的代码比较注重可读性，效率什么的考虑不多。不过，书中有大量的实验，这些实验是通过另外一套注重效率的代码实现的，当然这些代码的可读性就差一点。所以，希望大家把书中的代码当成伪码，其实很多书里面印的代码我都没有实际运行过（关于这句话如何理解，可以参考这篇blog http://xlvector.net/blog/?p=837，这句话更多说的是这些代码是从实际代码中精炼出来的，他不是运行版本，但胜似运行版本，嘿嘿)。在书上的代码之外，我会提供一个真实的可以运行的代码，估计会放在诸如google code这种地方。

问题：Top-N推荐和评分预测问题，更侧重于哪个？
回答：侧重于Top-N推荐，整个书用了8章讲Top-N推荐，1章讲评分预测。这似乎和这两个问题在学术界的论文数量是颠倒的，不过个人认为TopN推荐更符合实际，而且从来Hulu的近两年的实践看，几乎没有用到评分预测的技术。但是，评分预测问题作为Netflix Prize的著名问题，不说又不好。所以在最后一章介绍了这个问题的著名算法。

问题：本书是不是充满了公式？
回答：我没办法做到霍金那样一本书只有一个E=mc^2的公式。所以这本书主要采用三种语言和读者交流。第一种当然是中文，希望通过例子说清楚一个算法。第二种是公式，对于搞研究的朋友这这个可能很直接。第三种是代码，主要是为软件工程师考虑，他们容易看懂。

之前公开过一个粗略的目录，这里给出一个目前详细的目录，大家应该能够看出大概。不过这个目录还要大改，不过现在可以凑和看看。

第一章 什么是好的推荐系统 5
第1节 什么是推荐系统 6
第2节 个性化推荐系统的应用 8
2.1 电子商务 9
2.2 电影和视频网站 12
2.3 个性化音乐电台 14
2.4 社会网络 17
2.5 个性化阅读 19
2.6 基于位置的服务 20
2.7 个性化邮件 21
2.8 个性化广告 22
第3节 推荐系统的评测 23
3.1 推荐系统实验方法 25
3.2 评测指标 26
第二章 如何解决推荐系统冷启动问题 37
第1节 冷启动问题简介 37
第2节 利用用户注册信息 38
第3节 选择合适的物品启动用户的兴趣 44
第4节 利用物品的内容信息 48
第5节 发挥专家的作用 51
第6节 总结 53
第三章 如何利用用户行为数据 54
第1节 用户行为数据简介 55
1.1 用户行为的分类 55
1.2 用户行为分析 57
1.3 实验设计和算法评测 60
1.4 基于用户的协同过滤算法 63
1.5 基于物品的协同过滤算法 68
1.6 UserCF和ItemCF的综合比较 76
1.7 融合UserCF和ItemCF算法 80
第2节 隐语义模型 81
2.1 基于LFM的实际系统的例子 87
2.2 LFM和基于邻域的方法的比较 87
第3节 基于图的模型 88
3.1 用户行为数据的二分图表示 88
3.2 基于图的推荐算法 89
第四章 如何利用物品的内容信息 92
第1节 简介 92
第2节 文本关键词的抽取 93
第3节 基于物品的内容过滤算法 93
第五章 如何利用用户标签数据 94
第1节 UGC标签系统的代表应用 95
1.1 Delicious 95
1.2 CiteULike 96
1.3 Lastfm 96
1.4 豆瓣 97
1.5 Hulu 97
第2节 标签系统中的推荐问题 98
2.1 用户为什么要标注 98
2.2 用户如何打标签 99
2.3 用户打什么样的标签 100
第3节 基于标签的推荐系统 101
3.1 实验设置 102
3.2 一个最简单的算法 105
3.3 算法的改进 106
3.4 基于图的推荐算法 109
3.5 基于标签的推荐解释 114
第4节 给用户推荐标签 115
4.1 为什么要给用户推荐标签 115
4.2 如何给用户推荐标签 115
4.3 实验设置 117
4.4 基于图的标签推荐算法 118
第5节 总结 119
第六章 如何利用上下文信息 120
第1节 上下文推荐系统简介 120
第2节 时间上下文信息 121
2.1 时间效应简介 121
2.2 时间效应举例 122
2.3 系统时间特性的分析 123
2.4 推荐算法的时间多样性 125
2.5 时间上下文推荐算法 127
2.6 时间段图模型 131
2.7 离线实验 133
第3节 地点上下文信息 138
3.1 地点上下文简介 138
3.2 基于位置的推荐算法 139
第七章 如何利用社会网络数据 142
第1节 简介 143
第2节 获取社会网络数据的途径 144
2.1 电子邮件 144
2.2 用户登录信息 145
2.3 用户的位置数据 145
2.4 论坛和讨论组 145
2.5 即时聊天工具 145
2.6 社交网站 146
第3节 社会网络数据简介 147
第4节 基于社会网络的推荐 148
4.1 简介 148
4.2 基于邻域的社会化推荐算法 150
4.3 基于图的社会化推荐算法 150
4.4 实际系统中的社会化推荐算法 152
4.5 社会化推荐系统和协同过滤推荐系统 153
第5节 给用户推荐好友 154
5.1 基于内容的匹配 156
5.2 基于共同兴趣的好友推荐 156
5.3 基于社会网络图的好友推荐 156
第八章 实际推荐系统的例子 159
第1节 外围架构 159
1.1 数据收集和存储 160
第2节 在线推荐系统架构图 161
2.1 推荐系统由多个推荐引擎构成 162
2.2 推荐引擎的架构 163
第3节 离线推荐模块设计 167
3.1 特征物品相关表 167
第九章 评分预测问题 168
第1节 问题简介 168
第2节 离线实验方法 168
第3节 评分预测问题算法 169
3.1 平均值 169
3.2 基于邻域的方法 170
3.3 隐语义模型/矩阵分解模型 171
3.4 加入时间信息 177
3.5 模型融合 177
第十章 总结 179

您可能也喜欢：

《推荐系统实践》关于Latent Factor Model

推荐系统实践样章部分公布

关于《推荐系统实践》一书代码的说明

一个现实中的推荐系统

Twitter的用户推荐系统

无觅

本来这本书不准备在实践部分讲这个算法，而只准备在后面介绍学术界研究热点的时候讲这个算法。但后来发现，如果不讲，显得实践部分都是些加减乘除的小把戏，没啥技术含量啊。于是我还是将如何在非评分数据上做LFM放到了实践的部分，当然这方面的相关论文还非常少。不过我觉得LFM在实践部分还是有其前景的。

具体怎么做，先卖个关子不忙说。先公布一个实验结果吧。我们知道，LFM有一个副产品是对物品自动聚类，我今天写书的时候在MovieLens数据集上试了一把，发现效果不错，先公布出来。

您可能也喜欢：

推荐中的graph model

clustering items and users by latent factors?

关于《推荐系统实践》一书代码的说明

用Topic组织你的兴趣

《推荐系统实践》总结

无觅

样章很奇怪，是书的中间一章，关于标签推荐的。之所以选这章作为样章，是因为这一章内容相对独立，而且内容不是很多，比较容易写出来。这次样章分批公布，这次公布的是这一章的前言部分，也就是经常被和我一样的广大民工同志们称为废话的一部分。这一章的剩余部分会在未来的几周陆续公布。不过样章中有些实验结果尚未公布，只讨论了方法，结果要等正式出版时公布，留点悬念。

此外，我一开始写这本书的时候很多人都怕写的很晦涩难懂，不过这次我好像矫枉过正，写的过于简单了。同志们多批评。

目前我主要在集中写这一章的前一章，即如何利用隐反馈数据，主要包括neighborhood-based, latent factor model和 graph。

您可能也喜欢：

《推荐系统实践》总结

《推荐系统实践》关于Latent Factor Model

关于《推荐系统实践》一书代码的说明

Aardvark 专家推荐式的问答系统

一个现实中的推荐系统

无觅

于是，我把之前爬下来的google reader数据分析了一下，做了一个工具： http://www.reculike.com/reader.php

打开这个工具，首先看到的是google reader里最热门的feed，你可以选择你喜欢的进行订阅，当选择完一页后，可以点击刷新按钮，他会根据你之前的选择生成新的一屏的个性化的feeds推荐，你可以继续选，每次不满意，就刷新一下。

所有的用户行为都纪录在cookie中，当你想换个兴趣重新找feed的时候，可以点击重置按钮清空之前的历史行为纪录。选完feed后，可以点击生成rss按钮，他会生成一个rss，这个rss包含了所有你之前选的feed的文章的最新100条纪录，你可以在google dreader订阅这个feed。

不过因为服务器性能很土憋，不能保证你订阅的feed的文章实时更新，所以你也可以把找到的feed自己一个个加到阅读器里。

比如下面是一个我选择的技术feed的合并feed
http://www.reculike.com/site/reader/myfeed.php?uid=21

您可能也喜欢：

Google Reader在左侧显示feed推荐

社会舆论和用户个性的两难选择

多个用户共用一个id？

ItemCF的三个优化方法

推荐系统时效性的一条有趣的曲线

无觅

This article is written by zhenghua, lihang and me. Haha

As the Internet gets more and more popular, information overload poses an important challenge for a lot of online services. With all of the information pouring out from the web, users can be overwhelmed and confused as to what, exactly, they should be paying attention.

A recommendation system provides a solution when a lot of useful content becomes too much of a good thing. A recommendation engine can help users discover information of interest by analyzing historical behaviors. More and more online companies — including Netflix, Google, Facebook, and many others — are integrating a recommendation system into their services to help users discover and select information that may be of particular interest to them.

With literally tens of thousands of hours of premium video content, Hulu users are also prone to content overload. Given the wide variety of content available on the service at any one time, it may be difficult for Hulu users to discover new video that best matches their historic interests. So the first goal of Hulu’s recommendation system is to help users find content which will be of interest to them.

In addition to users, Hulu’s recommendation system should also help content owners promote their video. Part of our mission is to deliver a service that users, advertisers, and content owners all unabashedly love. We have many different content partners, and we understand that these content partners want to more Hulu users to watch their videos — especially when new videos are released. By using personal recommendation instead of more traditional recommendation systems, we can promote video content more effectively since we will promote directly to users who are likely to enjoy the content we are recommending.

Data Characteristics

Before explaining the design of our recommendation system, we wanted to explain some parameters within our data.

Since a lot of our content is comprised of episodes or clips within a show, we have decided to recommend shows to users instead of individual videos. Shows are a good method of organization, and videos in the same show are usually very closely related.

Our content can be mainly divided into two parts: on-air shows and library shows. On-air shows are highly important since more than half of our streaming comes from them.

Although on-air shows occupy a large part of our content, they are touched by a seasonal effect. During summer months, most of on-air shows do not air, causing on-air show streaming to decrease. Furthermore, there are fewer shows aired during weekends, thus the streaming of library shows will increase. Keeping this information in mind we can design the recommendation system to recommend more library shows to users during the weekend or summer months, as an example.

The key data that drives most recommendation systems is user behavior data. There are two main types of user behavior data: implicit user feedback data and explicit user feedback data. Explicit user feedback data primarily includes user voting data. Implicit feedback data includes information on users watching, browsing, searching, etc. Explicit feedback data can show a user’s preference on a show explicitly, but implicit feedback data cannot. For example, if a user gives a 5-star rating to a show, we know that this user likes the show very much. But if a user only watches a video from a show page or searches for a show, we don’t know whether this user likes the show.

As the quantity of implicit data at Hulu far outweighs the amount of explicit feedback, our system should be designed primarily to work with implicit feedback data.

Architecture

There are many different types of recommendation algorithms, and perhaps the most famous algorithm is collaborative filtering (CF). CF relies on user behavior data, and its main idea is to predict user preferences by analyzing their behaviors. There are two types of CF methods: user-based CF (UserCF) and item-based CF (ItemCF). UserCF assumes that a user will prefer items which are liked by other users who have similar preferences to that user. ItemCF assumes that a user will prefer items similar to the assets he or she preferred previously. ItemCF is widely used by many others (for example, Amazon and Netflix), as it has two main advantages. Firstly, it is suitable for sites where there are a lot more users than items. This allows ItemCF to easily explain recommendations given users’ historical behaviors. For example, if you have watched “Family Guy” on Hulu, we will recommend “American Dad” to you and tell you that we recommend this because you have watched “Family Guy”. So we use ItemCF as our basic recommendation algorithm in Hulu.

On-line Architecture

Figure 1 shows our on-line architecture of the recommendation system. This system contains 5 main modules:

1. User profile builder: When a user first comes into the recommendation system, we will first build a profile for them. The profile includes the user’s historical behaviors and topics, and these are generated from their old behaviors. Users can have many different types of behaviors. For example, they can watch videos, add shows to favorites, search for videos and vote on videos and shows. All these behaviors are all considered by our system and, after extracting all these behaviors, we use a topic model which is trained offline to generate users’ preference on topics.
2. Recommendation Core: After generating the list of user’s historical preferences on shows and topics, we put all of those similar shows into raw recommendations.
3. Filtering: For some pretty obvious reasons, raw recommendation results cannot be presented to users directly. We need to filter out shows the user has already seen or engaged with, so we can increase the recommendations shows a little more precise.
4. Ranking: The ranking module will re-rank raw recommendations to make them better fit users preferences. First, we’ll make recommendation more diverse. Then we’ll increase novelty of recommendations so that users will find shows they like, but have never seen before.
5. Explanation:Explanation is one of the most important components of every recommendation system. The explanation module generates some reasoning for every recommendation result using the user’s historical behaviors. For example, we will recommend “American Dad” to a user who had previously watched “Family Guy.” The explanation will say, “We recommend ‘American Dad’ to you because you have watched ‘Family Guy’”.
   Figure 1 : Architecture for Hulu 

   Off-line Architecture

   In the above on-line architecture, some components rely on offline resources, such as the topic model, related model, feedback model, etc. The off-line system is also an important part of our recommendation system. Our off-line system has these main components:

   1. Data Center: The data center contains all user behavior data in Hulu. Some of them are stored in Hadoop clusters and some of them are stored in a relational database.
   2. Related Table Generator: The related table is an important resource for on-line recommendation. We use two main types of related table: one that’s based on collaborative filtering (which we’ll call CF), and another based on content. In CF, show A and show B will have high similarity if users who like show A also like show B. With content filtering, we use content information including title, description, channel, company, actor/actress, and tags.
   3. Topic Model: A topic is represented by a group of shows that have similar content. Topics are thus larger in scope than shows, but they’re still smaller than channels. Our topics are learned by LDA, which is a popular topic model in machine learning.
   4. Feedback Analyzer: Feedback specifically means users’ reactions to recommendation results. Using user feedback can improve recommendation quality. For example, say a show is recommended to many users, but most of them do not click this show. In that case, we’ll decrease the rank of this show. Users will also have different types of behavior, so we’ll use all these behaviors in developing the recommendations. However, some users may prefer recommendations to come from their prior watch history, and some users may prefer their recommendations to come from their voting behavior. All these effects can be modeled offline by analyzing users’ feedback on their recommendations.
   5. Report Generator: Evaluation is most important part of the recommendation system. The report generator will generate a report including multiple metrics every day to show the quality of recommendations. At Hulu we monitor metrics including CTR, conversion ratio, etc.

    

   Figure 2 : Architecture for Hulu 

    

   Algorithms

   So far, we’ve given a brief overview of our recommendation architecture. From previous discussion, we can see that Hulu’s recommendation system is primarily based on ItemCF. We’ve added many improvements on top of the ItemCF algorithm, too, in order to make it generate better recommendations. To test these improvements, we’ve performed many A/B tests on different algorithms. In following sections, we’ll introduce some of these algorithms and the experiment results.

   Item-based Collaborative Filtering

   Item-based Collaborative Filtering (ItemCF) is the basis of all our algorithms. In ItemCF, let N(u) be a set of items user u has preferred previously. User u’s preference on item j (j is not in N(u)) can then be measured by:

   p(u,i) = \sum_{j \in N(u)} r(u,j) s(i,j)

   Here, r(u,i) is the preference weight of user u on show i, and s(i,j) is the similarity between show i and show j. In CF, the similarity between two shows is calculated by user behavior data on these two shows. Let N(i) be a set of users who watched show i and N(j) be a set of users who watched show j. Then, the similarity s(i,j) between show i and show j is calculated by following formula:

   In this definition, show i will be highly relevant to show j if most users who watch show i will also watch show j. However, this definition will have the “Harry Potter problem,” which means that every show will have high relevance with popular shows.

   Recent Behavior

   The first lesson we learned from A/B testing is that recommendations should fit users’ recent preference and that users’ recent behavior is more important than their older, historical behaviors. So, in our engine, we will put more weight on users’ recent behaviors. In our system, CTR of recommendations that originate from users’ recent watch behavior is 1.8 times higher than CTR of recommendations originating from users’ old watch behavior.

    

   

    

   Novelty

   Just because a recommendation system can accurately predict user behavior does not mean it produces a show that you want to recommend to an active user. For example, “Family Guy” is a very popular show on Hulu, and thus most users have watched at least some episodes from this show. These  users do not need us to recommend this show to them — the show is popular enough that users will decide whether or not to watch it by themselves.

   Thus, novelty is also an important metric to evaluate recommendations. The first way we think can increase novelty is by revising ItemCF algorithm:

   1. First, we will decrease weight of popular shows that users have watched before.
   2. Then, we’ll put more weight on shows that are not only similar to shows the active user watched before, but also less popular than shows the active user watched before.

   Explanation-based Diversity

   Most users have diverse preferences, so the recommendation should also meet their diverse interests. In our system, we use explanations to diversify our recommendations. We think a diverse recommendation means most of the recommendation shows have different explanations.

   We have performed an A/B test to show the usefulness of diversification (shown in the above figure). The results of the experiment show that, for active users who had previously watched 10 or more shows, diversification can increase recommendation CTR significantly.

   Temporal Diversity

   A good recommendation system should not generate static recommendations. Users want to see new suggestions every time they visit the recommendation system. If a user has new behaviors, she will find her recommendations have changed because we have put more weight on the user’s recent behaviors. But if a user has no new behaviors, we also need to change our recommendations. We use three methods to keep temporal diversity of our system:

   1. First, we’ll recommend recently-added shows to users. Many new shows are added to Hulu every day, and we will suggest these shows to users who will like them. Thus, users will see fresh ideas for shows to watch when new ones are added.
   2. Second, we will randomize our recommendations. Randomization is the simplest way to keep recommendations fresh.
   3. Finally, we’ll decrease rank of recommendations which users have seen many times. This is called implicit feedback, and data show that CTR is increased by 10% after using this method.

   Performance of Hulu’s Recommendation Hub

   The recommendation hub is a personal recommendation page for every user. On this page users will see 6 carousels. The top carousel is “top recommendations”, which includes shows that we think users will prefer very much. After top recommendations, there are three carousels for three genres. These three genres are selected by analyzing users’ historical preferences. The next carousel is bookmarks, which include shows that users have indicated they’d like to watch later. The last carousel is filled with shows that the user has already rated. This carousel is designed to collect more explicit feedback from users.

   

   We have performed an A/B test to compare our recommendation algorithms with two simple recommendation algorithms: Most Popular (which recommends the most popular shows to every user) and Highest Rated (which recommends highly-rated shows to every user). As shown in the above figure, experiment results show that the CTR of our algorithm is much higher than both simple methods.

   Lessons

   Every user behavior can reflect user preferences.

   In our system, we use a slew of user behaviors to come up with our recommendations. We’ve calculated the CTR of recommendations originating from different types of behaviors. As shown in Figure 3, we can see that recommendations from every type of behavior can generate recommendations that will be clicked by users.

   Figure 3 : CTR of recommendations come from different types of behaviors 

   Explicit Feedback data is more important than implicit feedback data

   As shown in Figure 3, CTR of recommendations that originate from users’ historically loved (vote 5 stars on shows) and liked (vote 4 stars on shows) behaviors is higher than CTR of recommendations that come from users’ historical subscribe/watch/search behavior. So although the size our explicit feedback data is much smaller than implicit feedback data, they’re much more important.

   Recent behaviors are much more important than old behaviors

   Novelty, Diversity, and offline Accuracy are all important factors

   Most researchers focus on improving offline accuracy, such as RMSE, precision/recall. However, recommendation systems that can accurately predict user behavior alone may not be a good enough for practical use. A good recommendation system should consider multiple factors together. In our system, after considering novelty and diversity, the CTR has improved by more than 10%.

   Based on the paper “Recommendation System at Hulu” by Liang Xiang, Hua Zheng and Hang Li.
   Hua Zheng is the senior lead developer in charge of the Hulu content recommendation and behavior targeting systems.
   Dr. Xiang and Dr. Li, associate researchers, are working together on the recommendation system, helping users discover and enjoy relevant premium videos.

您可能也喜欢：

ICML 2010 and Yahoo! Learning to Rank Workshop

中国地质馆

Youtube Topic搜索的体验

N-最短路径分词算法

Papers about Serendipity in Recommender Systems

无觅

长尾理论一书的作者虽然没有对推荐系统的作用做出估计，但估计了长尾内容对Amazon销售额的贡献比例。Anderson对这个数字做过两次估计。第一次是和MIT的研究团队一起估计出57%的销售来自长尾。这个数字的基础是Amazon曾经公布过在2001年到2003年排名前100000的商品占了39.2%的销售额。但在后来的更精确的估计中他提出这个比例应该在25%到36%之间。

Amazon的前科学家Greg Linden在他们的blog中也讨论了推荐系统在Amazon中的作用，他提到在他离开时，推荐系统对Amazon的贡献额在20%左右：

Personalization was responsible for well more than 20% of sales when I left Amazon in 2002.

此外，Amazon的一位科学家曾经在斯坦福讲推荐系统的课，一位听了他的课的同学在自己的blog里提到20% – 30% 的销售额来自于推荐系统。

从上面的考据可以基本判定，推荐系统对Amazon的销售额的贡献在20%到30%之间。

更新 ：

9月21号Greg Linden又发表了一篇blog提到了这个问题，里面给出的数字是35%。然后他引用的是这篇文章。这篇文章中有下面一段话：

Amazon says 35 percent of product sales result from recommendations.

不过文章并没有给出这句话的来源。而评论里也有群众提到了这个问题：

Nice write-up, Matt. From where did you get “Amazon says 35 percent of product sales result from recommendations”?

所以，20%到30%应该还是差不多靠谱的数字。但这个数字还是很高了。

您可能也喜欢：

Aardvark 专家推荐式的问答系统

一个现实中的推荐系统

推荐系统时效性的一条有趣的曲线

CiteULike的推荐系统

《推荐系统实践》关于Latent Factor Model

无觅