Mahout in action 中文版-2.推荐器的介绍-2.4~2.6

2.4 评估查准率(precision)和召回率(recall)

我们可以从更广义的角度去看待推荐问题:它并不是严格的要去估计偏好指数来提供推荐结果,也不总是要向用户提供准确的偏好指数的值。很多时候,我们只需从好到坏列出推荐排序,事实上,有些时候我们只需列出很少一部分排名考前的就可以了。

???????? 这样来看,我们也可以利用经典的信息检索中的度量方法去评估分类器:查准率和召回率。这些术语被典型的用在搜索引擎之中。而且,搜索引擎正是为一个查询返回一些排名较好的结果。

???????? 一个搜索引擎虽然要尽量多的返回相关结果,但是一定不能在靠前的结果中返回一些不相干的结果。查准率描述的是在靠前的结果中相关结果所占的比例,我们说"10条结果的精度"就是说前十条之中正确结果所占的比例。而召回率描述的是在靠前结果中包含了多少应该出现的结果。看下面的示意图可以帮你大致的了解一下:

?
?

图2.3 上下文搜索中的查准率和召回率

???????? 这些术语很容易在推荐器上套用:查准率就是在靠前的推荐结果中准确的推荐结果所占的比例,召回率就是在靠前结果中准确的推荐结果在整个应该被推荐结果中所占的比例。在下一小节中我们将会更出更直观的解释。

清单2.4 查准率与召回率评估程序的配置和运行

?


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23


RandomUtils.useTestSeed();

DataModel model = new?FileDataModel(new?File("intro.csv"));

??
?

RecommenderIRStatsEvaluator evaluator =

??new?GenericRecommenderIRStatsEvaluator ();?

RecommenderBuilder? recommenderBuilder = new?RecommenderBuilder() {

[email protected]

??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的评估程序

?


1

2

3

4

5

6


RecommenderBuilder? 20ecommenderBuilder = new?RecommenderBuilder() {

[email protected]

??public?Recommender? buildRecommender(DataModel model) throws?TasteException {

????return?new?SlopeOneRecommender(model);?

??}

}; ?

重新跑一遍,你发现它同样很快,而且得到了一个0.748的结果。它已经比以前更准确了!

这并不代表slope –one总是那么的快和准确。每一种算法都有自己的特点和属性去处理很困难的数据。Slope –one在运行时是比较快的,但是它需要一定的预处理时间。例如,基于用户的推荐器对于第一个例子中的数据处理的会很好。我们将在后续章节讨论每种算法的优点。它强调拿真实数据测试的重要性以及Mahout在处理这类问题是多么的轻而易举。

2.6 总结

这一章我们介绍了推荐引擎的主要思想。我们还创建了一些输入数据用推荐器跑了一下,然后分析了他的运行结果。

然后我们在推荐之前花了一些时间去分析推荐引擎的输出,因为我们将会在后续章节频繁的做这样的工作。这章也讲了如何利用差值去评估计算结果的精度,以及信息检索领域的查准率和召回率在评估中的应用。最后我们对GroupLens的推荐实例进行了评估,展示了如何以经验为主的去提高一个推进引擎的性能。

在深入的学习推荐引擎之前,有一个重要概念是需要知道的,我们将在下一章介绍:数据表达(representation of data)。

?
?

源文档 <http://www.cnblogs.com/colorfulkoala/archive/2012/07/22/2603765.html>

时间: 2024-10-16 23:53:17

Mahout in action 中文版-2.推荐器的介绍-2.4~2.6的相关文章

Mahout in action 中文版-2.推荐器的介绍-2.1~2.2

2?推荐器的介绍 本章概要: ???????? Mahout中的推荐器 ?????????推荐器实战一瞥 ?????????推荐引擎精度与质量评估 ?????????基于一个真实数据集的测试:GroupLens 每天我们都会对一些喜欢的.不喜欢的甚至不关心的事物进行一些评价.这中行为往往是无意识的.你在收音机上听到一首歌,你可能会因为它的美妙或者难听而注意到它,也可能直接忽略.这样的情形也会非常普遍的发生在人们对于T恤.沙拉酱.滑雪场.发型.脸型或者电视节目. ???????? 尽管人们的口味多

Mahout in action 中文版-2.推荐器的介绍-2.3

2.3 评估推荐器 ???????? 推荐器是一个工具,它用来解决"如何为一个用户给出最好的推荐"这样的问题.在得出结果之前,最好先弄清楚问题.究竟怎样才是一个好的推荐结果?我们如何才能得出这样的结果?这一章剩下的部分将停下来探索推荐器的评估,因为这是用来了解特定推荐器的有力工具. ???????? 最理想的推荐器会像巫师一样某明奇妙的猜到你所喜欢的东西.它可能会知道你有多喜欢一个东西,甚至你都没有见过它或者从未表达过你是否喜欢它.一个推荐器能够精确的得出你对于每个项目的偏好指数,然后

Mahout in Action 学习---基于物品的分布式推荐算法(Wikipedia数据集)

文字总结自<Mahout in Action>中文版第六章的内容 1.1 数据集介绍 Wikipedia数据集:一篇文章到另外一篇文章的链接. 可以将文章看作是用户,将该文章指向的文章视为该源文章所喜欢的物品. 类型:单向布尔型偏好. 相似性评估算法:LogLikelihoodSimilarity 关于LogLikelihoodSimilarity具体算法思想见: 对数似然比相似度 - xidianycy - 博客频道 - CSDN.NET http://blog.csdn.net/u0143

Mahout各种推荐器主要特点

Mahout有很多推荐的实现,下面对各自特点进行介绍:1.GenericUserBasedRecommender: 基于用户的推荐,用户数量相对较少时速度较快. 2.GenericItemBasedRecommender: 基于物品的推荐,物品数量较少时速度较快,外部提供了物品相似度数据后会更加有效率. 3.SlopeOneRecommender: 基于slope-one算法(想想那个填空的表格吧)的推荐,在线推荐或更新比较快,需要先下大量的预处理运算.物品数量相对较少时使用比较合适. 4.SV

Solr In Action 中文版 第一章(四、五)

1.1             功能概览1. 4 最后,让我们再按照下面的分类,快速的过一下Solr的主要功能: ·用户体验 ·数据建模 ·Solr 4的新功能 在本书中,为你的用户提供良好的搜索体验会一直贯穿全书的主题.所以我们就从用户体验开始,看看Solr是如何让你的用户感觉到爽的. 1.4.1             用户体验类功能 Solr提供了一系列的重要功能来帮助你搭建一个易用的,符合用户直觉的,功能强大的搜索引擎.不过你需要注意的是Solr仅仅是提供了类REST风格的HTTP AP

自译Solr in action中文版

目录 Part 1 初识 SOLR 1 Solr 简介 2 开始熟悉 Solr 3 Solr 核心概念 4 配置 Solr 5 建立索引 6 文本分析 Part 2 Solr 核心功能 7 发起查询 和 处理结果 8 分类索引 9 命中结果高亮 10 查询建议引导 11 结果分组 合并域 12 将Solr产品化 Part 3 Solr 高级应用 13 扩展Solr云 14 多语言搜索 15 复杂数据操作 16 相关性的调整 17 跳出思维定势 附录: A 从源代码编译Solr B 玩转Solr社

Solr In Action 中文版 第一章(一)

1.1我到底需要一个搜索引擎吗? 第一章           Solr 简介 本章速览: ·搜索引擎处理的数据特性 ·常见搜索引擎用例 ·Solr核心模块介绍 ·选择Solr的理由 ·功能概述 伴随着社交媒体.云计算.移动互联网和大数据等技术的高速发展,我们正迎来一个令人激动的计算时代.软件架构师们开始面对的主要挑战之一,便是如何处理全球巨大的用户基数所产生及使用的海量数据.此外,用户们开始期待在线软件应用永远都是稳定可用的,并且能够一直保持响应,这对应用就提出了更高的可扩展性和稳定性需求.为了

Solr In Action 中文版 第一章 (二)

Solr到底是什么? 在本节中,我们通过从头设计一个搜索应用来介绍Solr的关键组件.这个过程将有助于你理解Solr的功能,以及设计这些功能的初衷.不过在我们开始介绍Solr的功能特性之前,还是要先澄清一下Solr并不具有的一些性质: 1)  Solr并不是一个像Google或是Bing那样的web搜索引擎 2)  Solr和网站优化中经常提到的搜索引擎SEO优化没有任何关系 好了,现在假设我们准备为潜在的购房客户设计一个不动产搜索的网络应用.该应用的核心用例场景是通过网页浏览器来搜索全美国范围

Solr In Action 中文版 第一章(三)

3.1              为什么选用Solr? 在本节中,我们希望可以提供一些关键信息来帮助于你判断Solr是否是贵公司技术方案的正确选择.我们先从Solr吸引软件架构师的方面说起. 3.1              软件架构师眼中的Solr 在评估一项新技术时,软件架构师必须要考虑一系列的因素,其中就包括系统的稳定性,可伸缩性,还有容错性.Solr在这三方面的得分都很不错. 说到稳定性,Solr是一个由活跃的开源社区和经验丰富的代码提交者共同维护的一项成熟技术.Solr和Lucene的