7.1、推荐系统概述
如何在学习爆炸的时代找到自己需要的信息？搜索引擎（Google，Bing，百度等等）成为大家快速找到目标信息的最好途径。在用户对自己需求相对明确的时候，用搜索引擎很方便的通过关键字搜索很快的找到自己需要的信息。但搜索引擎并不能完全满足用户对信息发现的需求，那是因为在很多情况下，用户其实并不明确自己的需要，或者他们的需求很难用简单的关键字来表述。又或者他们需要更加符合他们个人口味和喜好的结果，因此出现了推荐系统，与搜索引擎对应，大家也习惯称它为推荐引擎。
随着推荐引擎的出现，用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的信息发现。
推荐引擎的原理图如下
图7.1.1 推荐引擎工作原理
7.2、推荐系统类型
推荐系统主要可以分为：协同过滤型和基于内容的推荐系统，本文主要讨论协同过滤型推荐系统的各个相关模块，并且是基于开源框架Mahout实现的。基于内容的推荐不在本文讨论范围。
7.3、推荐系统的组成
推荐系统可以分为三个模块：算法测试模块；推荐线上运行时模块；推荐系统线下训练模块，下面分别介绍。
7.4、基于协同过滤的推荐
7.4.1 什么是协同过滤
协同过滤是利用集体智慧的一个典型方法。要理解什么是协同过滤 (Collaborative
Filtering, 简称
CF)，首先想一个简单的问题，如果你现在想查找专业知识，但你不知道如何查找，你会怎么做？大部分的人会问问周围的朋友，看看他们是用什么方法解决你想解决的专业问题的，而我们一般更倾向于从口味比较类似的朋友那里得到推荐。这就是协同过滤的核心思想。
协同过滤一般是在海量的用户中发掘出一小部分和你品位比较类似的，在协同过滤中，这些用户成为邻居，然后根据他们喜欢的其他东西组织成一个排序的目录作为推荐给你。当然其中有一个核心的问题：
如何确定一个用户是不是和你有相似的品位？
如何将邻居们的喜好组织成一个排序的目录？
协同过滤相对于集体智慧而言，它从一定程度上保留了个体的特征，就是你的品位偏好，所以它更多可以作为个性化推荐的算法思想。
7.4.2 协同过滤的核心
要实现协同过滤，需要以下几个步骤
- 收集用户偏好
- 找到相似的用户或物品
- 计算推荐
协同过滤分为两种：基于用户的协同过滤（user-based）；基于项目的协同过滤（item-based）
7.4.3 协同过滤算法
4.3.1 基于用户的协同过滤推荐
图4.3.1 User-based推荐
假设每个用户的购买记录格式为
表4.3.1.1 用户的购买记录
| 商品id 用户id | i1 | i2 | i3 | i4 | i5 | i6 | i7 | i8 |
|---|---|---|---|---|---|---|---|---|
| u1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 |
| u2 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 |
| u3 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 |
| u4 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 |
| u5 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
以上表中的数据，说明User-based推荐算法的实现过程，表中每一行数据代表了一个用户曾经购买过的商品记录，1代表购买过，0代表没购买过。
1）为每个用户寻找相似的其它用户，
2）查找只有u1的相似用户中购买过的商品，而u1没有购买过的商品，例如u2中的i6-i8，u1就没购买过；同理u3的i6-i8，u1也没购买过，u4中i6,i7是u1没购买过的，u5中的i6是u1没购买过的。
3）引入这样的假设“人以类聚，物以群分”。既然是相似用户，所以就有相似的兴趣或者购买习惯。那么就可以将u2-u5购买过而u1没购买过的商品推荐给u1。在2）中已经找出了u1没购买过的商品为i6-i8。对于这三个商品可以推荐给u1了。注意：购物网站的商品可是有千万种，如果商品过多的话，是不是全部要推荐给用户哪？当然不是，而是要选取最“靠谱”的商品推荐给用户，这里的“靠谱”就是要对商品进行排序了。
4）对推荐结果进行排序，i6-i8的得分计算方式分别为：
4.3.2 基于项目的协同过滤推荐算法
图4.3.2.1 Item-based推荐
在上一节中介绍了User-based算法，其是通过寻找相似的用户达到推荐的目的。如果想找到与某一商品相类似的其它商品又该如何实现？Item-based算法可以实现这一目的，将表4.3.2.1转置变为表4.3.2.1，如果要计算与i1相似的其它商品，显然也只用计算i1与i2-i8的相似性，然后按照与i1的相似程度排序即可。
表4.3.2.1 用户的购买记录
| 用户id 商品id | u1 | u2 | u3 | u4 | u5 |
|---|---|---|---|---|---|
| i1 | 1 | 1 | 1 | 1 | 1 |
| i2 | 1 | 1 | 1 | 1 | 0 |
| i3 | 1 | 1 | 1 | 0 | 0 |
| i4 | 1 | 1 | 0 | 0 | 0 |
| i5 | 1 | 0 | 0 | 0 | 0 |
| i6 | |||||
| i7 | |||||
| i8 |
7.5 推荐算法评价
推荐引擎作为一个工具—一个回答问题的工具。对于用户来说，什么样的推荐才是最好的？在探求答案之前最好还是探究下问题（什么样的推荐引擎最好）。到底什么样的推荐引擎才是最好的。用户如何知晓推荐引擎如何才能产生满足需要的答案？本章的余下部分将介绍如何评价推荐引擎，因为，在实现一个特殊的推荐系统时其评价标准相当重要。
最好的推荐引擎可能需要有一种“通灵”能力，在某种程度上，它可以在用户的行为发生之前，就对用户的某些偏好做出预测，预测某些用户对某一项目（item）的偏好。推荐系统可以预测将来你对所有项目的实际偏好。这样的推荐系统才可能是一种好的推荐系统。
事实上，大多数的推荐引擎实际上也就是对所有项目（item）的评分进行预测。所以评价推荐引擎的性能指标就是要评估其对项目的预测精度如何，即如果预测值和实际值之间的误差越小，则推荐系统的准确性越好。
7.5.1 训练数据和得分
虽然这些确切的评分偏好并不存在。也没有人知道（包括你自己）未来你对一个新的项目（item）评分是多少。所以，在推荐引擎中，用一部分真实的数据作为测试数据，来测试预测值和真实值之间的误差。在真实的测试数据中，需要去掉一部分已经被评分的项目偏好数据。然后将去除特定评分项的数据输入推荐系统，让推荐系统预测缺失项目的评分，这样就可以用预测值和真实值进行对比，就可以知道推荐系统的精度了。
按照以上的叙述，测试推荐引擎的性能就很简单了。比如，可以很方便的计算预测值和真实值之间的平均误差。平均误差越低越好，因为那意味着估计值更靠近真实值。如果误差为0.0，那说明估计值的结果是相当完美的—估计值和真实值之间没有误差。
有时候也使用均方根误差作为误差评价标准：即预测值和真实值差的平方和取平均值后再开方。依然是，这个值越小越好。表7.5.1.1展示了相关结果。
表7.5.1.1 预测值和真实值间的平均误差和均方根误差
表7.5.1.1展示了一系列真实值和预测值之间的差异，从中可以看到如何计算平均误差和均方根误差的。均方误差计算方法对偏离程度大的项目（此处item2偏离度较大）有更大的惩罚（即误差越大，相比较而言均方误差的值比平均误差的值要大），在某些时候这种惩罚是符合实际需要的。For
example, an estimate that’s off by two whole stars is probably more than twice
as bad as one off by just one
star。因为均方误差计算方法更直观，物理意义上也更好理解，所以后续的例子中将使用平均误差作为误差测量方法。
7.5.2 准确率和召回率
对用户偏好的估计并不仅仅是推荐系统要做的唯一的事，还有其它一些方面用来衡量推荐系统的好坏。一般来说推荐系统只要能够向用户推荐出一系列按照相关性从大到小顺序排列的结果就可以了，并不需要向用户显示预测的偏好是多少。事实上，大多数情况下推荐结果列表的顺序如何并无太大的关系，关键是结果列表中要有对用户有用的项目。
更一般的观点，可以将经典的信息检索度量方法：准确度和召回率，用来衡量推荐系统。这两个指标的典型应用时搜索引擎，搜索引擎返回与查询串相关的一系列可能的结果。
搜索引擎不应该返回与查询不相关的结果，但是其需要尽可能多的返回与查询相关的结果。精度是在搜索结果中与查询相关的结果与整个搜索结果的比例。精度等于10表明有在搜索结果中有10条结果与查询相关。召回率指的是查询结果中与查询相关的结果与整体相关结果的比例。图2.3展示了这两者的示意图。
图2.3 搜索引擎中准确率和召回率的关系
推荐系统的准确率指的是推荐结果中符合要求的结果与整个结果列表数量的比值，召回率指的是推荐结果中符合要求的结果（good
recommendations）与整体符合要求的结果的比例。下节将介绍什么是符合要求的结果（good recommendations）。
