2.4 评估查准率（precision）和召回率（recall）
我们可以从更广义的角度去看待推荐问题：它并不是严格的要去估计偏好指数来提供推荐结果，也不总是要向用户提供准确的偏好指数的值。很多时候，我们只需从好到坏列出推荐排序，事实上，有些时候我们只需列出很少一部分排名考前的就可以了。
这样来看，我们也可以利用经典的信息检索中的度量方法去评估分类器：查准率和召回率。这些术语被典型的用在搜索引擎之中。而且，搜索引擎正是为一个查询返回一些排名较好的结果。
一个搜索引擎虽然要尽量多的返回相关结果，但是一定不能在靠前的结果中返回一些不相干的结果。查准率描述的是在靠前的结果中相关结果所占的比例，我们说“10条结果的精度”就是说前十条之中正确结果所占的比例。而召回率描述的是在靠前结果中包含了多少应该出现的结果。看下面的示意图可以帮你大致的了解一下：
图2.3 上下文搜索中的查准率和召回率
这些术语很容易在推荐器上套用：查准率就是在靠前的推荐结果中准确的推荐结果所占的比例，召回率就是在靠前结果中准确的推荐结果在整个应该被推荐结果中所占的比例。在下一小节中我们将会更出更直观的解释。
清单2.4 查准率与召回率评估程序的配置和运行
RandomUtils.useTestSeed();
DataModel model = new FileDataModel(new File("intro.csv"));
RecommenderIRStatsEvaluator evaluator =
new GenericRecommenderIRStatsEvaluator ();
RecommenderBuilder recommenderBuilder = new RecommenderBuilder() {
@Override
public Recommender buildRecommender(DataModel model)
throws TasteException {
UserSimilarity similarity = new PearsonCorrelationSimilarity (model);
UserNeighborhood neighborhood =
new NearestNUserNeighborhood(2, similarity, model);
return
new GenericUserBasedRecommender(model, neighborhood, similarity);
}
};
IRStatistics stats = evaluator.evaluate(
recommenderBuilder, null, model, null, 2,
GenericRecommenderIRStatsEvaluator.CHOOSE_THRESHOLD,
1.0); A
System.out.println(stats.getPrecision());
System.out.println(stats.getRecall());
A 前两条结果的查准率和召回率
如果不调用RandomUtils.useTestSeed()，那么结果将会随着每次对训练集和测试集的选择不同而发生微妙的变化，但是我们的测试程序数据很少，所以没有必要在用真正的随机函数。运行结果如下：
0.75
1.0
在前2条的结果中，查准率为0.75；平均看来有四分之三的结果是正确的。召回率为1.0；所有应该被推荐的结果都在结果之中。
但是，究竟什么才算应该被推荐的结果？其实这个框架下也没有一个合适的定义，直觉告诉我们，在测试集中偏好指数最高的那些项目肯定是最应该被推荐的，而其余的则不是。
清单2.5 测试集中用户5的偏好指数
5,101,4.0 5,102,3.0 5,103,2.0 5,104,4.0 5,105,3.5 5,106,4.0
让我们来看看引擎为用户5的推荐结果，在想想对于101、102、103应该是如何推荐的。结果中显示三个项目的偏好指数分别是4.0、3.0、2.0。没错，三个项目的排序是没问题的，但是103应该被推荐吗？它可是最低的了，用户5貌似不是很喜欢103，而102也一般般。不过101但是很受5的喜爱，102、103是可以被推荐的，但是不是一个好的推荐。
这个问题需要RecommenderEvaluator来解决。如果不给定一个确定的临界值，我们将无法知道那些是好的推荐那些是不好的推荐，而这个框架为每个用户提供了一个临界值。这个临界值的定义为用户平均的偏好指数加上一个标准差：
如果你忘记了统计学的知识，不必担心。这一项不仅仅是比高一点点就行了，它需要加上一个很有意义的标准差。在实践经验中，一般推荐结果前16%的就算是较好的结果了，另外一个参数作用和之前讨论的差不多，您可以在相关文档中看到详细的信息。
2.4.2 查准率和召回率的一些问题
查准率和召回率发挥作用的前提是如何定义什么才是“好”的推荐结果。在上面我们给出了一个临界值，或者说程序提供了这样的定义。
另外还存在一个模糊的问题，推荐结果包含了一些用户已经表现出喜欢的项目。其实一个好的推荐应该把这些用户已经知道的项目去除掉在推荐出来。
试想我们为一个喜欢法国信徒电影的用户做推荐，但是这种电影本身就很少。比如，我们为这个人推荐了一个电影，但是该电影几乎从来都没有人知道，那么这也不是一个好的推荐，虽然客观的讲这确实很了不起。一些好的推荐应该从所有其他用户已知的电影中选取。
时候，偏好不能取值，或者说偏好是一些布尔的值，那么情况就会变得复杂一些了。在这里，偏好程度没有一个可比性（因为没有大小之分），所以在集合中我们选取一些应该被推荐的就可以了。
查准率和召回率在测试环节也有某种用途。用户喜欢一个被推荐项目理论上可以认为是一个好的推荐，但是绝不能等同于是最喜欢的。然而，对于这种布尔型的偏好程度，你只能采取查准-召回的评估方法，均差和均方差都不能奏效。所以对数据的限制的理解还是十几重要的。
2.5 评估GroupLens的数据集
有了前面的基础，我们不仅能够讨论推荐引擎的处理速度，也可以评估他的推荐质量。大数据的实验还在后面的章节之中，但是现在我们可以使用一些小的数据集来实战一下。
2.5.1 提取推荐数据
GroupLens ( http://grouplens.org/ ) 是一个可以提供一些不同大小数据集的搜索项目，每个数据集来自于真实的用户对电影的评价。它是世界上可以获取真实数据的项目之一。本书后续还将继续使用它提供的数据。从GroupLens网站上下载“100K data set”，连接为 http://www.grouplens.org/node/73。解压你下载的数据，然后找到一个名为ua.base的文件，这个文件是一个标签化的文件，包括：用户ID,项目ID，等级（偏好指数）和一些附加信息。
这个文件有用吗？里面只有标签，没有逗号隔开，而且每一行还包含了一些额外的信息。没错，这个文件需要配合FileDataModel对象才有意义。回到清单2.3，这里我们构建了一个RecommenderEvaluator，尝试把文件的路径改为ua.base的路径。在运行一下，这回大概需要几分钟的时间，因为它里面包含了100,000条数据。
最后运行结果应该为0.9，不算很差，虽然在五个等级的情况下不是很理想。或许这个Recommender对象不是很适合这样的数据。
2.5.2 用其他的推荐器进行实验
我们来用一个叫做“slope-one”的推荐器跑一下这个数据，它在即将来临的章节中讲到。只需替换一下RecommenderBuilder对象。把他替换成org.apache.mahout.cf.taste.impl.recommender.slopeone.SlopeOneRecommeder。就象这样：
清单 SlopeOneRecommender的评估程序
RecommenderBuilder 20ecommenderBuilder = new RecommenderBuilder() {
@Override
public Recommender buildRecommender(DataModel model) throws TasteException {
return new SlopeOneRecommender(model);
}
};
重新跑一遍，你发现它同样很快，而且得到了一个0.748的结果。它已经比以前更准确了！
这并不代表slope –one总是那么的快和准确。每一种算法都有自己的特点和属性去处理很困难的数据。Slope –one在运行时是比较快的，但是它需要一定的预处理时间。例如，基于用户的推荐器对于第一个例子中的数据处理的会很好。我们将在后续章节讨论每种算法的优点。它强调拿真实数据测试的重要性以及Mahout在处理这类问题是多么的轻而易举。
2.6 总结
这一章我们介绍了推荐引擎的主要思想。我们还创建了一些输入数据用推荐器跑了一下，然后分析了他的运行结果。
然后我们在推荐之前花了一些时间去分析推荐引擎的输出，因为我们将会在后续章节频繁的做这样的工作。这章也讲了如何利用差值去评估计算结果的精度，以及信息检索领域的查准率和召回率在评估中的应用。最后我们对GroupLens的推荐实例进行了评估，展示了如何以经验为主的去提高一个推进引擎的性能。
在深入的学习推荐引擎之前，有一个重要概念是需要知道的，我们将在下一章介绍：数据表达（representation of data）。
（翻译 By 花考拉）