在 StumbleUpon 身上有一段儿传奇的经历。2007年5月，eBay 花了 75 个 million 的美刀把 StumbleUpon 收入囊中，而且据说当时 Google 对它也很有兴趣。但在归入 eBay 旗下之后，StumbleUpon 并没有取得预期的更大的发展，反而星光暗淡停滞不前了。其实这倒也没什么，要知道绝大多数类似的收购案例都是差不多的结局。但令人意外的是，差不多一年半以后，StumbleUpon 的两位创始人 Garrett Camp 与 Geoff Smith 又把它从 eBay 手里买了回来！算是拯救自己的孩子于水火了。无独有偶，据报道，eBay 刚刚把它2005年收购的 Skype 又给卖了出去。eBay 不好好搞自己的拍卖，当起了高科技二道贩子，让人无语啊。

好了，言归正传，说说 StumbleUpon 的算法吧。毋庸置疑，算法绝对是 StumbleUpon 的 top secret，外人是不可能知道确切情况的。所以我这里给出的，只是某位高人经过不断实验得到的推测。

具体的推理过程大家可以看那篇 blog，我这里直接给出结果：用来衡量一篇文章在 StumbleUpon 系统内得分的公式。假设 stumbler a 提交了一篇文章 d，d 属于 domain D。

这里面最重要的一个参数，就是 A -“stumbler audience”。stumbler 指的就是使用 StumbleUpon 的用户，所以顾名思义，stumbler audience 大概说的就是一个 stumbler 在 StumbleUpon 系统内的权重，它由下面三个主要因素构成，

• Number of fans
• Number of thumbs up and down you have given
• Stumble thumb bonus – increase to score based on number of thumbs received on a page.

这个公式的大意可以理解为，文章 d 的权重，等于最初的提交者贡献的得分，加上后续 stumble up 用户贡献的得分，再减去后续 stumble down 用户带来的负面影响。
公式具体的解释如下，
1）第一个加号之前的部分，表示 a 的权重，除以 a 在 domain D 内总共提交的文章数。
2）第一个求和部分，表示后续的 stumble up 用户做出的总体贡献。alpha 是 stumble up 操作的调和参数。gamma 表示“organic bonus”，是一个预设值，是对使用了 StumbleUpon Toolbar 的额外加分。delta 表示“nonfriend”惩罚因子，用来减弱无/少 friends 用户的影响力。
3）第二个求和部分与前面这个类似，表示后续的 stumble down 用户对总体得分造成的影响。
5）N，比较奇怪，高人文章里说是一个随机数，不过我没太搞明白为什么要加这么一个参数。

不知道是高人的英文写作水平有问题，还是我的英文阅读能力不行，反正高人的这篇文章看起来非常晦涩，如果我这里的理解有什么问题的话，大家一定帮忙指出来。

延伸阅读：Social Media排序算法的四种模式，旁观者 – 郑昀

最后插一句，汪峰的新专辑《信仰在空中飘摇》，非常之好听，强烈推荐！

Y Combinator 只关注于最早期的创业团队，在创业团队的起步阶段介入并提供相应的帮助。Y Combinator 会定期举行 Funding Application 的活动，接受创业团队提交的项目资料。项目如果评审通过的话，Y Combinator 会提供一种“$5000 + $5000n”模式的投资，其中 n 指的是愿意参与此项目投资的 Y Combinator 合伙人的人数。比如，如果有 2 个合伙人愿意投资，那么最终的投资额度是 $15000；如果有 3 个的话就是 $20000。作为回报，Y Combinator 将占有创业团队 2% 到 10% 的股份，通常是 6%。钱虽然不多，但在现今创业公司大量使用 open source，AWS 或者 GAE 的情况下，这些钱也确实够展开工作了。

据说 Y Combinator 已经累计投资了 80 多个创业项目，除 reddit 之外，我还算熟悉的另外一个是 Scribd ——“YouTube for Documents”。Y Combinator 最初总共为 Scribd 提供了 $12000 的投资。Scribd 在 2007 年 5 月正式上线，随即就是飞速地增长，上线一个月之后就完成了 $3.5 million 的 A 轮融资，2008 年 12 月又完成了 $9 million 的 B 轮融资，发展得很是不错。一个有意思的事情，Scribd 有一个超级 NB 的用户，Barack Obama，对，现任美国总统！

在 Y Combinator 的合伙人中，我个人比较关注的是 Paul Graham。他写过一篇流传很广的文章，How to Start a Startup。Paul 在 Anti Spam 方面颇有造诣，以前我在研究相关问题时，从他这里学到了很多东西。Paul 是 Lisp 的大牛，另外还是 Arc 语言的设计者，Hacker News 应该就是用 Arc 语言开发的。Paul 始终称自己是一名 programmer，相比于当前乌泱乌泱的架构师，很是洒脱。

下面言归正传，看看 Hacker News 使用了怎么样的算法。

Hacker News 所使用的公式非常简单，

    (p – 1) / (t + 2)^1.5

其中，
1）p 表示文章得到的投票数，之所以要使用 (p – 1)，应该是想去掉文章提交者的那一票。
2）(t + 2)^1.5， 这个是时间因子。t 表示当前时间与文章提交时间间隔的小时数。但为什么要加 2 之后再取 1.5 的幂，似乎就没什么道理可言了，也许是个 trial-and-error 的结果吧。

总体来讲，Hacker News 的公式不像 reddit 设计的那么巧妙。但是与 reddit 相比，Hacker News 的用户群比较集中，提交的文章更 Focus，质量也相对更高一些，因此实际的效果并不差。其实某些时候，解决问题就是这样，够用就好。

FP-Growth 算法的核心是 FP-Tree（Frequent Pattern Tree，频繁模式树）的构建，这个特殊的数据结构，是 FP-Growth 算法与 Apriori 算法相比，性能显著提高的原因所在。不过，仔细分析一下 FP-Tree 的实现，可以发现它与字符串处理算法中常用的 Prefix Tree 算法，有着异曲同工之妙。FP-Tree 通过合并一些重复路径，实现了数据的压缩，从而使得将频繁项集加载到内存中成为可能。之后以树遍历的操作，替代了 Apriori 算法中最耗费时间的事务记录遍历，从而大大提高了运算效率。详细的理论讲解可以阅读上面的论文，我这里还是把其中的例子翻译一下。

某数据库 DB 里有 5 条事务记录，取最小支持度（min support threshold）为 3，则生成 FP-Tree 的过程如下：

1、扫描一遍数据库，获取所有频繁项，删除频率小于最小支持度的项。在此操作的过程中，还可以得到每个项的出现频率，供后续步骤使用。这一步完成之后，我们得到以下频繁项， { (c:4), (f:4), (a:3), (b:3), (m:3), (p:3) }，“:”之后的数字表示对应项的出现频率。这个结果是排好顺序的，首先按照频率从达到小排序，再按照字母顺序排序。需要注意的是这里的排序非常重要，之后每个事务中的项都要按照这个顺序进行排列，这个是有效合并重复路径的前提。

处理之后的数据库记录为：

2、第二次扫描数据库，在第一次处理完成的结果基础上，构建 FP-Tree。

经过两遍数据库扫描，完成了 FP-Tree 的构建。在此例中，c 点为整个 FP-Tree 的唯一根节点，但其实多数情况下，根节点并不是唯一的，即有多棵子树。因此，为了方便树结构的遍历，可以人为添加一个超级根节点，通常标记为 root<null>。参照下图，可以更清楚的理解整个过程。

得到了 FP-Tree 树之后，再遍历整棵树获取满足一定置信度的关联规则，就比较简单了。具体的理论证明，以及与 Apriori 算法的 performance 对比，论文里讲得非常清楚，有兴趣的朋友可以看一下。

关联规则算法系列文章
1）关联规则介绍
2）Apriori 算法
3）FP-Growth 算法，这篇文章和上一篇隔得时间有些长了

来源：google china blog
作者：吴军，http://www.cs.jhu.edu/~junwu/。

数学之美 一 统计语言模型
数学之美 二 谈谈中文分词
数学之美 三 隐含马尔可夫模型在语言处理中的应用
数学之美 四 怎样度量信息?
数学之美 五 简单之美：布尔代数和搜索引擎的索引
数学之美 六 图论和网络爬虫 (Web Crawlers)
数学之美 七 信息论在信息处理中的应用
数学之美 八 贾里尼克的故事和现代语言处理
数学之美 九 如何确定网页和查询的相关性
数学之美 十 有限状态机和地址识别
数学之美 十一 Google 阿卡 47 的制造者阿米特.辛格博士
数学之美 十二 余弦定理和新闻的分类
数学之美 十三 信息指纹及其应用
数学之美 十四 谈谈数学模型的重要性
数学之美 十五 繁与简 自然语言处理的几位精英
数学之美 十六（上）不要把所有的鸡蛋放在一个篮子里 最大熵模型
数学之美 十六（下）不要把所有的鸡蛋放在一个篮子里 最大熵模型
数学之美 十七 闪光的不一定是金子 谈谈搜索引擎作弊问题(Search Engine Anti-SPAM)
数学之美 十八 矩阵运算和文本处理中的分类问题
数学之美 十九 马尔可夫链的扩展 贝叶斯网络 (Bayesian Networks)
数学之美 二十 自然语言处理的教父 马库斯
数学之美 二十一 布隆过滤器（Bloom Filter）
数学之美 二十二 由电视剧《暗算》所想到的 — 谈谈密码学的数学原理

还有一点感谢谷歌，就是这个改自黑板报的主题。^_^

Apriori 是一种广度优先算法，通过多次扫描数据库来获取支持度大于最小支持度的频繁项集。它的理论基础是频繁项集的两个单调性原则：频繁项集的任一子集一定是频繁的；非频繁项集的任一超集一定是非频繁的。晦涩的理论我这里就不多写了，有兴趣的可以去看论文。我把里面的例子给翻译一下，图文并茂，简明易懂。
某数据库 DB 里有 4 条事务记录，取最小支持度（min support）为 0.5，则计算频繁项集的过程如下：

TID Items 100 A, C, D 200 B, C, E 300 A, B, C, E 400 B, E	扫描DB	Itemset Support {A} 2 (0.5) {B} 3 (0.75) {C} 3 (0.75) {D} 1 (0.25) {E} 3 (0.75)	取满足 最小支持度 项集	Itemset Support {A} 2 {B} 3 {C} 3 {E} 3
Itemset {A, B} {A, C} {A, E} {B, C} {B, E} {C, E}	扫描DB	Itemset Support {A, B} 1 (0.25) {A, C} 2 (0.5) {A, E} 1 (0.25) {B, C} 2 (0.5) {B, E} 3 (0.75) {C, E} 2 (0.5)	取满足 最小支持度 项集	Itemset Support {A, C} 2 {B, C} 2 {B, E} 3 {C, E} 2
Itemset {A, B, C} {A, B, E} {A, C, E} {B, C, E}	扫描DB	Itemset Support {A, B, C} 1 (0.25) {A, B, E} 1 (0.25) {A, C, E} 1 (0.35) {B, C, E} 2 (0.5)	取满足 最小支持度 项集	Itemset Support {B, C, E} 2 (0.5)

如上可以看出，在海量数据的情况下，Apriori 算法的运算过程有 2 个问题：

1. 需要多次扫描数据库，时间成本很高；
2. 运算过程中需要产生大量的候选集，空间成本也非常高。

针对 Apriori 算法所做的改进也基本上是围绕着解决这两个问题进行的，如在扫描DB前首先进行以便事务合并和压缩，数据分区或抽样等。

Weka 里有 Apriori 算法的 Java 实现，非常值得一看。

貌似 wikipedia 已经解封了，呵呵！

预报：关联规则(3)，关于 FP-Growth 算法。

就拿刚上线的“蚂蚁”来说吧，打开《引爆流行》的页面，稍微滚动两下鼠标，你就可以看到这个了——“喜欢此宝贝的会员还喜欢”。豆瓣上也有类似的形式，还看《引爆流行》，豆瓣的是——“喜欢引爆流行的人也喜欢”。是不是很像？但别被形式迷惑了，这两个用的是完全不同的技术实现。豆瓣的之前我说过了，他是
Item-Based
方法；蚂蚁的这个应该就是关联规则方法了。当然我是猜的，不过也不是乱猜。有兴趣的可以刷刷上面那两个《引爆流行》的页面，看一下两个推荐区域的内容会有什么不同。

关联规则起源于数据挖掘领域，人们用它来发现大量数据中项集之间（有趣/有用）的关联。它本身是数据挖掘领域中一个重要的研究课题，近些年来更是由于被业界广泛应用而倍受重视。Rakesh
Agrawal 是关联规则领域的大牛，他于 1993 年发表的一篇
paper，《Mining
Association Rules between Sets of Items in Large Databases》，是被引用最多的一篇大作。不过让
google fans 们失望的是，他目前就职于 microsoft 的搜索实验室！^_^

关联规则的最典型例子就是购物篮分析。在一家超市里，有一个有趣的现象：尿布和啤酒赫然摆在一起出售。但是这个奇怪的举措却使尿布和啤酒的销量双双增加了。这不是一个笑话，而是发生在美国沃尔玛连锁店超市的真实案例，并一直为商家所津津乐道。原来，美国的妇女们经常会嘱咐她们的丈夫下班以后要为孩子买尿布。而丈夫在买完尿布之后又要顺手买回自己爱喝的啤酒，因此啤酒和尿布在一起购买的机会还是很多的。这个故事听起来是不是很酷？没错，这就是技术的力量！

但是，和任何其他经典的故事一样——这事儿听起来带劲儿，做起来很难！真正做过关联规则挖掘的人，一定都有这样的体会：想从浩瀚的记录集里，挖掘一条带劲儿的关联规则出来，简直太难了。（什么，你问有多难？请参照朱广沪~~~）

对于挖掘得到的关联规则，都会制定一些指标来衡量它们的有效程度，最经典的包括，支持度和置信度。简单来讲，

1. 支持度是指，商品A、商品B在全部销售订单中所占的比例。
2. 置信度是指，购买商品A并且同时购买了商品B的订单，在所有包含商品A的订单中所占的比例。

当然，这里的商品和订单是个泛化的概念，具体指代是的什么，就得具体问题具体分析了。

1. 易于实现和维护：普通工程师可以轻松解释所有的聚合数据，并且算法易于实现和测试。
2. 运行时可更新的：新增一个评分项，应该对预测结果即时产生影响。
3. 高效率的查询响应：快速的执行查询，可能需要付出更多的空间占用作为代价。
4. 对初次访问者要求少：对于一个评分项目很少的用户，也应该可以获得有效的推荐。
5. 合理的准确性：与最准确的方法相比，此方法应该是有竞争力的，准确性方面的微小增长不能以简单性和扩展性的大量牺牲为代价。

使用这个图可以简明扼要的说明一下 Slope One 算法。

1. User A 给 Item I 打分为 1；给 Item J 打分为 1.5。
2. Uesr B 给 Item I 打分为 2。
3. 问题是：User B 给 Item J 打分为多少？
4. 使用 Slope One 算法，答案是：2.5，2+(1.5-1)=2.5。

是不是非常简单？！Slope One 算法就是这么简单，而且它居然还相当有效！详细的试验分析可以看这里“Slope One Predictors for Online Rating-Based Collaborative Filtering”。

喜欢 Python 的朋友可以看这篇 Blog，“tutorial about how to implement Slope One in Python”，非常详细的介绍了 Slope One 算法在 Python 下的实现步骤。当然了，这只是一个非常简单的实现，你可以使用 MovieLens 或者 EachMovie 的数据集进行一些简单地试验。但如果真正要把它投入到商业环境，还有许多其他的工作必须做好。

我正在使用 Python 实现一个推荐算法模块集，其中也实现了 Slope One 算法，但现在还比较简陋，不太适合开源，等完善一些之后，我会把它开源出来，和大家共享。

GroupLens 研究小组的 Sarwar 教授等人，于2001年5月在香港召开的第 10 届 WWW 大会上，发表了题为《Item-based Collaborative Filtering Recommendation Algorithms》的 paper[1]。现在看来，这篇 paper 在 Item-based Collaborative Filtering 方面是影响最广的，被引用的次数也最多，基本上见 Item-based 必见此文。在 2000 的时候，同是上文作者之一的 Karypis 曾经完成了《Evaluation of Item-based Top-N Recommendation Algorithms》，但它仅作为明尼苏达计算机系的一篇 Technical Report 进行了发表，可以看作是 paper[1] 的工作基础。

但实际上，早在 1998 年，Amazon 就已经开发出了自己的 Item-based 推荐系统，并投入了使用。同年，当时 Amazon 推荐系统的设计师、现在 Findory 的创始人 Greg，连同 Jacobi 和 Benson，使用“Collaborative Recommendations Using Item-to-Item Similarity Mappings”的名字对该项技术申请了专利。但该专利直到 2001 年才正式通过！并且在 Sarwar 等人的 paper[1] 里，并没有标明引用了此专利的内容。Greg 在自己的 blog 上专门撰文说明了此事 [1] [2]，并得到了 Economist 编辑 Tom Standage 的承认。在 2003 年，Greg 发表了题为《Amazon.com Recommendations: Item-to-Item Collaborative Filtering》的 paper，对 1998 年的专利内容进行了详细的说明。

这是一段挺有意思的事情。但更能引起我兴趣的，是这项已经被实践证明确实行之有效的技术——Item-based (or item-to-item) collaborative filtering ！

Item-based 方法也有一个基本的假设：能够引起用户兴趣的项，必定与其之前评分高的项相似。这个假设也是与我们日常生活中的行为相一致的，基本上喜欢《长尾理论》的人，都会去看《世界是平的》，不知道你怎么想，反正豆瓣就是这么认为的。

同 User-based 方法类似，Item-based 方法需要同样的三个步骤：1）得到User-item的评分数据；2）针对项的最近邻搜索，即对项进行相似度计算；3）产生推荐。但相对于 User-based 方法，Item-based 方法最大的改进是提高了协同过滤方法的扩展性及性能。

从上一篇中可以看到，在 User-based 方法中，随着用户数量的不断增多，在大数量级的用户范围内进行“最近邻搜索”会成为整个算法的瓶颈。Item-based 方法通过计算项之间的相似性来代替用户之间的相似性。对于项来讲，它们之间的相似性要稳定很多，因此可以离线完成工作量最大的相似性计算步骤，从而大大降低了在线计算量，提高推荐效率。

在 Item-based 方法中，要对 A 和 B 进行项相似性计算，通常分为两步：1）找出同时对 A 和 B 打过分的组合；2）对这些组合进行相似度计算，常用的算法包括：皮尔森相关系数、余弦相似性、调整余弦相似性和条件概率等。

在 paper[1] 里，Sarwar 教授通过试验得到 Item-based 方法的推荐效果要略好于 User-based 方法的结伦。但其实这也并不尽然。在 2003 年，Mild 教授从批判的角度重新审视了各种推荐算法，指出基于 Item-based 方法并不一定好，算法准确度与采用的实验数据数据有关，大多数情况下还是 User-based 方法好。我个人倒是认为，其实没有绝对的好坏之分，而应该根据问题的不同和数据集的特点，选择最合适的方法。

上面所说的偏重于学术界一些，算法的出发点还是基于打分，多数使用的是 MovieLens 的数据。工业界实际使用的多是在基本 Item-based 方法基础上的变形，例如基于关联规则的方法，这些方法最大的变化就是在计算项的相似度方面做文章。其实正如 Greg 曾经说过的，协同过滤最大的特点是“以数据为先”的，只当有了大量的数据积累，才可能找到最有效的、最适宜的方法。

后面我将会陆续写一些实际算法方面的东西，欢迎互动交流。

还有一些图片，不过也得等海那边的光缆修好之后，我才能发上来。

协同过滤技术可以分为三类：基于用户（User-based）的协同过滤；基于项目（Item-based）的协同过滤；基于模型（Model-based）的协同过滤。这篇文章针对基于用户（User-based）的协同过滤技术。建立一个基于用户的协同过滤系统通常需要三个步骤。

步骤一，收集可以代表用户兴趣的信息。
传统的系统一般使用打分的方式，最著名的例如 MovieLens 。豆瓣上经常出现在右侧的“我来评价”也是这种方法。这种方式被称为“显式评分”方法。但它有一个明显的缺点，收集数据比较困难，用户通常并不愿意费力气为你贡献这种数据。这导致这种系统通常更多出现在实验室或者论文里面。在实际的商业系统中，即使使用了这种方法，也多会被包装为一种更加 user-friendly 的样子。
另外一种被认为更有效的方法是“隐式评分”方法。这种方法不需要用户直接输入评价数据，而是根据用户的行为特征由系统代替用户完成评价。一种研究得比较多的方法是 Web Mining 。电子商务网站在隐式评分的数据获取上有先天的优势，用户购买的商品记录是非常有用的数据。你在豆瓣上写书评，其实也是在为豆瓣贡献着这种评分数据。

步骤二，最近邻搜索。
协同过滤的出发点是与你兴趣相同的一组用户，术语叫做“最近邻”。最近邻搜索的核心是计算两个用户的相似度。例如用户A和用户B，首先需要获取用户A和用户B所有的评分项，然后选择一个合适的相似度计算方法，基于评分项数据，计算得到用户A和用户B的相似度数值。目前使用比较多的相似度算法包括，皮尔森相关系数（Person Correlation Coefficient）、余弦相似性（Cosine-based Similarity）以及调整余弦相似性（Adjusted Consine Similarity）。这里有一个试验，结论是“调整余弦相似性”算法的准确性较好。不知道豆瓣使用的是哪种算法？肯定不会仅使用一种，通常情况下，会根据数据集的不同选择不同的算法。

步骤三，生成推荐结果。
有了最近邻集合，就可以对目标用户的兴趣进行预测，生成推荐结果。通常根据推荐目的的不同，可以进行多种形式的推荐。最常见的推荐结果有两种，Top-N 推荐和关联推荐。
Top-N 推荐，这里的 Top-N 和一般网站（比如 digg）上见到的“最热门”列表是不同的。热门列表是基于全部数据集产生的，它对每个人都是一样的；Top-N 推荐是针对单个用户产生的，它对每个人是不一样的：通过对你的最近邻用户进行统计，选择出现频率最高且在你的评分项目中不存在的项目作为推荐结果。豆瓣上的“排行”栏目，应该是传统的“热门”列表，不是 Top-N 推荐。
关联推荐，也称为基于关联规则的推荐。与传统关联规则针对全部数据进行挖掘不同的是，此方法仅对最近邻用户的购买记录进行关联规则挖掘。如果你曾经购买过关联规则左边的商品，而没有购买过关联规则右边的商品，那么就把右边的这个商品推荐给你。它最突出的优点就是，可以帮助你发现你感兴趣的而以前却从来没有注意过的商品。在 Amazon 介绍书的详细信息的页面上，可以看到这种推荐的一个实际应用。例如在《The Search》的页面上，Amazon 给我的推荐是，

基于用户的协同推荐算法随着用户数量的增多，计算量成线性加大，其性能会越来越差。而对于 Web 应用系统，响应速度绝是影响用户体验的最重要因素之一。这一点极大的限制了基于用户的协同过滤技术在实际系统中的使用。Amazon 更多地使用了基于项目（Item-based）的协同过滤技术，而且随着 Amazon 的成功，Item-based 方法也大为流行起来。豆瓣主要使用的也是 Item-based 方法。在下一篇文章里，我会重点介绍 Item-based 方法。

Answers 上面关于 Collaborative Filtering 的 Topic 是一个好的学习起点。另外在 del.icio.us 上可以找到不少关于协同过滤的资料。