2011年12月3日

页面抓取匹配时,万恶的\r,\n,\t  要先替换掉为空,出现匹配有问题,都是这个引起的
posted @ 2011-12-03 00:04 yuejianjun 阅读(15) 评论(0) 编辑

2011年12月1日

http://www.ibm.com/developerworks/cn/web/1103_zhaoct_recommstudy1/index.html

赵 晨婷, 软件工程师, IBM
马 春娥, 软件工程师, IBM


简介: 随着 Web 技术的发展,使得内容的创建和分享变得越来越容易。每天都有大量的图片、博客、视频发布到网上。信息的极度爆炸使得人们找到他们需要的信息将变得越来越难。传统的搜索技术是一个相对简单的帮助人们找到信息的工具,也广泛的被人们所使用,但搜索引擎并不能完全满足用户对信息发现的需求,原因一是用户很难用恰当的关键词描述自己的需求,二是基于关键词的信息检索在很多情况下是不够的。而推荐引擎的出现,使用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的上下文信息更丰富的信息发现。

本文的标签:  appstore, recommender, search, seo, 引擎, 探索推荐引擎内部的秘密, 推荐, 推荐引擎, 推荐引擎内部, 搜索

标记本文!


发布日期: 2011 年 3 月 16 日 
级别: 高级 
访问情况 22690 次浏览 
建议: 6 (查看或添加评论) 
 平均分 (共 66 个评分 )

“探索推荐引擎内部的秘密”系列将带领读者从浅入深的学习探索推荐引擎的机制,实现方法,其中还涉及一些基本的优化方法,例如聚类和分类的应用。同时在理论讲解的基础上,还会结合 Apache Mahout 介绍如何在大规模数据上实现各种推荐策略,进行策略优化,构建高效的推荐引擎的方法。本文作为这个系列的第一篇文章,将深入介绍推荐引擎的工作原理,和其中涉及的各种推荐机制,以及它们各自的优缺点和适用场景,帮助用户清楚的了解和快速构建适合自己的推荐引擎。

信息发现

如今已经进入了一个数据爆炸的时代,随着 Web 2.0 的发展, Web 已经变成数据分享的平台,那么,如何让人们在海量的数据中想要找到他们需要的信息将变得越来越难。

在这样的情形下,搜索引擎(Google,Bing,百度等等)成为大家快速找到目标信息的最好途径。在用户对自己需求相对明确的时候,用搜索引擎很方便的通过关键字搜索很快的找到自己需要的信息。但搜索引擎并不能完全满足用户对信息发现的需求,那是因为在很多情况下,用户其实并不明确自己的需要,或者他们的需求很难用简单的关键字来表述。又或者他们需要更加符合他们个人口味和喜好的结果,因此出现了推荐系统,与搜索引擎对应,大家也习惯称它为推荐引擎。

随着推荐引擎的出现,用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的信息发现。

如今,随着推荐技术的不断发展,推荐引擎已经在电子商务 (E-commerce,例如 Amazon,当当网 ) 和一些基于 social 的社会化站点 ( 包括音乐,电影和图书分享,例如豆瓣,Mtime 等 ) 都取得很大的成功。这也进一步的说明了,Web2.0 环境下,在面对海量的数据,用户需要这种更加智能的,更加了解他们需求,口味和喜好的信息发现机制。

推荐引擎

前面介绍了推荐引擎对于现在的 Web2.0 站点的重要意义,这一章我们将讲讲推荐引擎到底是怎么工作的。推荐引擎利用特殊的信息过滤技术,将不同的物品或内容推荐给可能对它们感兴趣的用户。

图 1. 推荐引擎工作原理图

图 1 给出了推荐引擎的工作原理图,这里先将推荐引擎看作黑盒,它接受的输入是推荐的数据源,一般情况下,推荐引擎所需要的数据源包括:
 要推荐物品或内容的元数据,例如关键字,基因描述等;
 系统用户的基本信息,例如性别,年龄等
 用户对物品或者信息的偏好,根据应用本身的不同,可能包括用户对物品的评分,用户查看物品的记录,用户的购买记录等。其实这些用户的偏好信息可以分为两类:
 显式的用户反馈:这类是用户在网站上自然浏览或者使用网站以外,显式的提供反馈信息,例如用户对物品的评分,或者对物品的评论。
 隐式的用户反馈:这类是用户在使用网站是产生的数据,隐式的反应了用户对物品的喜好,例如用户购买了某物品,用户查看了某物品的信息等等。

显式的用户反馈能准确的反应用户对物品的真实喜好,但需要用户付出额外的代价,而隐式的用户行为,通过一些分析和处理,也能反映用户的喜好,只是数据不是很精确,有些行为的分析存在较大的噪音。但只要选择正确的行为特征,隐式的用户反馈也能得到很好的效果,只是行为特征的选择可能在不同的应用中有很大的不同,例如在电子商务的网站上,购买行为其实就是一个能很好表现用户喜好的隐式反馈。

推荐引擎根据不同的推荐机制可能用到数据源中的一部分,然后根据这些数据,分析出一定的规则或者直接对用户对其他物品的喜好进行预测计算。这样推荐引擎可以在用户进入的时候给他推荐他可能感兴趣的物品。

回页首

推荐引擎的分类

推荐引擎的分类可以根据很多指标,下面我们一一介绍一下:
 推荐引擎是不是为不同的用户推荐不同的数据

根据这个指标,推荐引擎可以分为基于大众行为的推荐引擎和个性化推荐引擎
 根据大众行为的推荐引擎,对每个用户都给出同样的推荐,这些推荐可以是静态的由系统管理员人工设定的,或者基于系统所有用户的反馈统计计算出的当下比较流行的物品。
 个性化推荐引擎,对不同的用户,根据他们的口味和喜好给出更加精确的推荐,这时,系统需要了解需推荐内容和用户的特质,或者基于社会化网络,通过找到与当前用户相同喜好的用户,实现推荐。

这是一个最基本的推荐引擎分类,其实大部分人们讨论的推荐引擎都是将个性化的推荐引擎,因为从根本上说,只有个性化的推荐引擎才是更加智能的信息发现过程。
 根据推荐引擎的数据源

其实这里讲的是如何发现数据的相关性,因为大部分推荐引擎的工作原理还是基于物品或者用户的相似集进行推荐。那么参考图 1 给出的推荐系统原理图,根据不同的数据源发现数据相关性的方法可以分为以下几种:
 根据系统用户的基本信息发现用户的相关程度,这种被称为基于人口统计学的推荐(Demographic-based Recommendation)
 根据推荐物品或内容的元数据,发现物品或者内容的相关性,这种被称为基于内容的推荐(Content-based Recommendation)
 根据用户对物品或者信息的偏好,发现物品或者内容本身的相关性,或者是发现用户的相关性,这种被称为基于协同过滤的推荐(Collaborative Filtering-based Recommendation)。
 根据推荐模型的建立方式

可以想象在海量物品和用户的系统中,推荐引擎的计算量是相当大的,要实现实时的推荐务必需要建立一个推荐模型,关于推荐模型的建立方式可以分为以下几种:
 基于物品和用户本身的,这种推荐引擎将每个用户和每个物品都当作独立的实体,预测每个用户对于每个物品的喜好程度,这些信息往往是用一个二维矩阵描述的。由于用户感兴趣的物品远远小于总物品的数目,这样的模型导致大量的数据空置,即我们得到的二维矩阵往往是一个很大的稀疏矩阵。同时为了减小计算量,我们可以对物品和用户进行聚类, 然后记录和计算一类用户对一类物品的喜好程度,但这样的模型又会在推荐的准确性上有损失。
 基于关联规则的推荐(Rule-based Recommendation):关联规则的挖掘已经是数据挖掘中的一个经典的问题,主要是挖掘一些数据的依赖关系,典型的场景就是“购物篮问题”,通过关联规则的挖掘,我们可以找到哪些物品经常被同时购买,或者用户购买了一些物品后通常会购买哪些其他的物品,当我们挖掘出这些关联规则之后,我们可以基于这些规则给用户进行推荐。
 基于模型的推荐(Model-based Recommendation):这是一个典型的机器学习的问题,可以将已有的用户喜好信息作为训练样本,训练出一个预测用户喜好的模型,这样以后用户在进入系统,可以基于此模型计算推荐。这种方法的问题在于如何将用户实时或者近期的喜好信息反馈给训练好的模型,从而提高推荐的准确度。

其实在现在的推荐系统中,很少有只使用了一个推荐策略的推荐引擎,一般都是在不同的场景下使用不同的推荐策略从而达到最好的推荐效果,例如 Amazon 的推荐,它将基于用户本身历史购买数据的推荐,和基于用户当前浏览的物品的推荐,以及基于大众喜好的当下比较流行的物品都在不同的区域推荐给用户,让用户可以从全方位的推荐中找到自己真正感兴趣的物品。

深入推荐机制

这一章的篇幅,将详细介绍各个推荐机制的工作原理,它们的优缺点以及应用场景。

基于人口统计学的推荐

基于人口统计学的推荐机制(Demographic-based Recommendation)是一种最易于实现的推荐方法,它只是简单的根据系统用户的基本信息发现用户的相关程度,然后将相似用户喜爱的其他物品推荐给当前用户,图 2 给出了这种推荐的工作原理。

图 2. 基于人口统计学的推荐机制的工作原理

从图中可以很清楚的看到,首先,系统对每个用户都有一个用户 Profile 的建模,其中包括用户的基本信息,例如用户的年龄,性别等等;然后,系统会根据用户的 Profile 计算用户的相似度,可以看到用户 A 的 Profile 和用户 C 一样,那么系统会认为用户 A 和 C 是相似用户,在推荐引擎中,可以称他们是“邻居”;最后,基于“邻居”用户群的喜好推荐给当前用户一些物品,图中将用户 A 喜欢的物品 A 推荐给用户 C。

这种基于人口统计学的推荐机制的好处在于:
 因为不使用当前用户对物品的喜好历史数据,所以对于新用户来讲没有“冷启动(Cold Start)”的问题。
 这个方法不依赖于物品本身的数据,所以这个方法在不同物品的领域都可以使用,它是领域独立的(domain-independent)。

那么这个方法的缺点和问题是什么呢?这种基于用户的基本信息对用户进行分类的方法过于粗糙,尤其是对品味要求较高的领域,比如图书,电影和音乐等领域,无法得到很好的推荐效果。可能在一些电子商务的网站中,这个方法可以给出一些简单的推荐。另外一个局限是,这个方法可能涉及到一些与信息发现问题本身无关却比较敏感的信息,比如用户的年龄等,这些用户信息不是很好获取。

基于内容的推荐

基于内容的推荐是在推荐引擎出现之初应用最为广泛的推荐机制,它的核心思想是根据推荐物品或内容的元数据,发现物品或者内容的相关性,然后基于用户以往的喜好记录,推荐给用户相似的物品。图 3 给出了基于内容推荐的基本原理。

图 3. 基于内容推荐机制的基本原理

图 3 中给出了基于内容推荐的一个典型的例子,电影推荐系统,首先我们需要对电影的元数据有一个建模,这里只简单的描述了一下电影的类型;然后通过电影的元数据发现电影间的相似度,因为类型都是“爱情,浪漫”电影 A 和 C 被认为是相似的电影(当然,只根据类型是不够的,要得到更好的推荐,我们还可以考虑电影的导演,演员等等);最后实现推荐,对于用户 A,他喜欢看电影 A,那么系统就可以给他推荐类似的电影 C。

这种基于内容的推荐机制的好处在于它能很好的建模用户的口味,能提供更加精确的推荐。但它也存在以下几个问题:
 需要对物品进行分析和建模,推荐的质量依赖于对物品模型的完整和全面程度。在现在的应用中我们可以观察到关键词和标签(Tag)被认为是描述物品元数据的一种简单有效的方法。
 物品相似度的分析仅仅依赖于物品本身的特征,这里没有考虑人对物品的态度。
 因为需要基于用户以往的喜好历史做出推荐,所以对于新用户有“冷启动”的问题。

虽然这个方法有很多不足和问题,但他还是成功的应用在一些电影,音乐,图书的社交站点,有些站点还请专业的人员对物品进行基因编码,比如潘多拉,在一份报告中说道,在潘多拉的推荐引擎中,每首歌有超过 100 个元数据特征,包括歌曲的风格,年份,演唱者等等。

基于协同过滤的推荐

随着 Web2.0 的发展,Web 站点更加提倡用户参与和用户贡献,因此基于协同过滤的推荐机制因运而生。它的原理很简单,就是根据用户对物品或者信息的偏好,发现物品或者内容本身的相关性,或者是发现用户的相关性,然后再基于这些关联性进行推荐。基于协同过滤的推荐可以分为三个子类:基于用户的推荐(User-based Recommendation),基于项目的推荐(Item-based Recommendation)和基于模型的推荐(Model-based Recommendation)。下面我们一个一个详细的介绍着三种协同过滤的推荐机制。

基于用户的协同过滤推荐

基于用户的协同过滤推荐的基本原理是,根据所有用户对物品或者信息的偏好,发现与当前用户口味和偏好相似的“邻居”用户群,在一般的应用中是采用计算“K- 邻居”的算法;然后,基于这 K 个邻居的历史偏好信息,为当前用户进行推荐。下图 4 给出了原理图。

图 4. 基于用户的协同过滤推荐机制的基本原理

上图示意出基于用户的协同过滤推荐机制的基本原理,假设用户 A 喜欢物品 A,物品 C,用户 B 喜欢物品 B,用户 C 喜欢物品 A ,物品 C 和物品 D;从这些用户的历史喜好信息中,我们可以发现用户 A 和用户 C 的口味和偏好是比较类似的,同时用户 C 还喜欢物品 D,那么我们可以推断用户 A 可能也喜欢物品 D,因此可以将物品 D 推荐给用户 A。

基于用户的协同过滤推荐机制和基于人口统计学的推荐机制都是计算用户的相似度,并基于“邻居”用户群计算推荐,但它们所不同的是如何计算用户的相似度,基于人口统计学的机制只考虑用户本身的特征,而基于用户的协同过滤机制可是在用户的历史偏好的数据上计算用户的相似度,它的基本假设是,喜欢类似物品的用户可能有相同或者相似的口味和偏好。

基于项目的协同过滤推荐

基于项目的协同过滤推荐的基本原理也是类似的,只是说它使用所有用户对物品或者信息的偏好,发现物品和物品之间的相似度,然后根据用户的历史偏好信息,将类似的物品推荐给用户,图 5 很好的诠释了它的基本原理。

假设用户 A 喜欢物品 A 和物品 C,用户 B 喜欢物品 A,物品 B 和物品 C,用户 C 喜欢物品 A,从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的,喜欢物品 A 的人都喜欢物品 C,基于这个数据可以推断用户 C 很有可能也喜欢物品 C,所以系统会将物品 C 推荐给用户 C。

与上面讲的类似,基于项目的协同过滤推荐和基于内容的推荐其实都是基于物品相似度预测推荐,只是相似度计算的方法不一样,前者是从用户历史的偏好推断,而后者是基于物品本身的属性特征信息。

图 5. 基于项目的协同过滤推荐机制的基本原理

同时协同过滤,在基于用户和基于项目两个策略中应该如何选择呢?其实基于项目的协同过滤推荐机制是 Amazon 在基于用户的机制上改良的一种策略,因为在大部分的 Web 站点中,物品的个数是远远小于用户的数量的,而且物品的个数和相似度相对比较稳定,同时基于项目的机制比基于用户的实时性更好一些。但也不是所有的场景都是这样的情况,可以设想一下在一些新闻推荐系统中,也许物品,也就是新闻的个数可能大于用户的个数,而且新闻的更新程度也有很快,所以它的形似度依然不稳定。所以,其实可以看出,推荐策略的选择其实和具体的应用场景有很大的关系。

基于模型的协同过滤推荐

基于模型的协同过滤推荐就是基于样本的用户喜好信息,训练一个推荐模型,然后根据实时的用户喜好的信息进行预测,计算推荐。

基于协同过滤的推荐机制是现今应用最为广泛的推荐机制,它有以下几个显著的优点:
 它不需要对物品或者用户进行严格的建模,而且不要求物品的描述是机器可理解的,所以这种方法也是领域无关的。
 这种方法计算出来的推荐是开放的,可以共用他人的经验,很好的支持用户发现潜在的兴趣偏好

而它也存在以下几个问题:
 方法的核心是基于历史数据,所以对新物品和新用户都有“冷启动”的问题。
 推荐的效果依赖于用户历史偏好数据的多少和准确性。
 在大部分的实现中,用户历史偏好是用稀疏矩阵进行存储的,而稀疏矩阵上的计算有些明显的问题,包括可能少部分人的错误偏好会对推荐的准确度有很大的影响等等。
 对于一些特殊品味的用户不能给予很好的推荐。
 由于以历史数据为基础,抓取和建模用户的偏好后,很难修改或者根据用户的使用演变,从而导致这个方法不够灵活。

混合的推荐机制

  • 在现行的 Web 站点上的推荐往往都不是单纯只采用了某一种推荐的机制和策略,他们往往是将多个方法混合在一起,从而达到更好的推荐效果。关于如何组合各个推荐机制,这里讲几种比较流行的组合方法。
  • 加权的混合(Weighted Hybridization): 用线性公式(linear formula)将几种不同的推荐按照一定权重组合起来,具体权重的值需要在测试数据集上反复实验,从而达到最好的推荐效果。
  • 切换的混合(Switching Hybridization):前面也讲到,其实对于不同的情况(数据量,系统运行状况,用户和物品的数目等),推荐策略可能有很大的不同,那么切换的混合方式,就是允许在不同的情况下,选择最为合适的推荐机制计算推荐。
  • 分区的混合(Mixed Hybridization):采用多种推荐机制,并将不同的推荐结果分不同的区显示给用户。其实,Amazon,当当网等很多电子商务网站都是采用这样的方式,用户可以得到很全面的推荐,也更容易找到他们想要的东西。
  • 分层的混合(Meta-Level Hybridization): 采用多种推荐机制,并将一个推荐机制的结果作为另一个的输入,从而综合各个推荐机制的优缺点,得到更加准确的推荐。

推荐引擎的应用

介绍完推荐引擎的基本原理,基本推荐机制,下面简要分析几个有代表性的推荐引擎的应用,这里选择两个领域:Amazon 作为电子商务的代表,豆瓣作为社交网络的代表。

推荐在电子商务中的应用 – Amazon

Amazon 作为推荐引擎的鼻祖,它已经将推荐的思想渗透在应用的各个角落。Amazon 推荐的核心是通过数据挖掘算法和比较用户的消费偏好于其他用户进行对比,借以预测用户可能感兴趣的商品。对应于上面介绍的各种推荐机制,Amazon 采用的是分区的混合的机制,并将不同的推荐结果分不同的区显示给用户,图 6 和图 7 展示了用户在 Amazon 上能得到的推荐。

图 6. Amazon 的推荐机制 - 首页

图 7. Amazon 的推荐机制 - 浏览物品

Amazon 利用可以记录的所有用户在站点上的行为,根据不同数据的特点对它们进行处理,并分成不同区为用户推送推荐:
 今日推荐 (Today's Recommendation For You): 通常是根据用户的近期的历史购买或者查看记录,并结合时下流行的物品给出一个折中的推荐。
 新产品的推荐 (New For You): 采用了基于内容的推荐机制 (Content-based Recommendation),将一些新到物品推荐给用户。在方法选择上由于新物品没有大量的用户喜好信息,所以基于内容的推荐能很好的解决这个“冷启动”的问题。
 捆绑销售 (Frequently Bought Together): 采用数据挖掘技术对用户的购买行为进行分析,找到经常被一起或同一个人购买的物品集,进行捆绑销售,这是一种典型的基于项目的协同过滤推荐机制。
 别人购买 / 浏览的商品 (Customers Who Bought/See This Item Also Bought/See): 这也是一个典型的基于项目的协同过滤推荐的应用,通过社会化机制用户能更快更方便的找到自己感兴趣的物品。

值得一提的是,Amazon 在做推荐时,设计和用户体验也做得特别独到:

Amazon 利用有它大量历史数据的优势,量化推荐原因。
 基于社会化的推荐,Amazon 会给你事实的数据,让用户信服,例如:购买此物品的用户百分之多少也购买了那个物品;
 基于物品本身的推荐,Amazon 也会列出推荐的理由,例如:因为你的购物框中有 ***,或者因为你购买过 ***,所以给你推荐类似的 ***。

另外,Amazon 很多推荐是基于用户的 profile 计算出来的,用户的 profile 中记录了用户在 Amazon 上的行为,包括看了那些物品,买了那些物品,收藏夹和 wish list 里的物品等等,当然 Amazon 里还集成了评分等其他的用户反馈的方式,它们都是 profile 的一部分,同时,Amazon 提供了让用户自主管理自己 profile 的功能,通过这种方式用户可以更明确的告诉推荐引擎他的品味和意图是什么。

推荐在社交网站中的应用 – 豆瓣

豆瓣是国内做的比较成功的社交网站,它以图书,电影,音乐和同城活动为中心,形成一个多元化的社交网络平台,自然推荐的功能是必不可少的,下面我们看看豆瓣是如何推荐的。

图 8 . 豆瓣的推荐机制 - 豆瓣电影

当你在豆瓣电影中将一些你看过的或是感兴趣的电影加入你看过和想看的列表里,并为它们做相应的评分,这时豆瓣的推荐引擎已经拿到你的一些偏好信息,那么它将给你展示如图 8 的电影推荐。

图 9 . 豆瓣的推荐机制 - 基于用户品味的推荐

豆瓣的推荐是通过“豆瓣猜”,为了让用户清楚这些推荐是如何来的,豆瓣还给出了“豆瓣猜”的一个简要的介绍。

“你的个人推荐是根据你的收藏和评价自动得出的,每个人的推荐清单都不同。你的收藏和评价越多,豆瓣给你的推荐会越准确和丰富。
每天推荐的内容可能会有变化。随着豆瓣的长大,给你推荐的内容也会越来越准。”

这一点让我们可以清晰明了的知道,豆瓣必然是基于社会化的协同过滤的推荐,这样用户越多,用户的反馈越多,那么推荐的效果会越来越准确。

相对于 Amazon 的用户行为模型,豆瓣电影的模型更加简单,就是“看过”和“想看”,这也让他们的推荐更加专注于用户的品味,毕竟买东西和看电影的动机还是有很大不同的。

另外,豆瓣也有基于物品本身的推荐,当你查看一些电影的详细信息的时候,他会给你推荐出“喜欢这个电影的人也喜欢的电影”, 如图 10,这是一个基于协同过滤的应用。

图 10 . 豆瓣的推荐机制 - 基于电影本身的推荐

总结

在网络数据爆炸的年代,如何让用户更快的找到想要的数据,如何让用户发现自己潜在的兴趣和需求,无论是对于电子商务还是社会网络的应用都是至关重要的。推荐引擎的出现,使得这个问题越来越被大家关注。但对大多数人来讲,也许还在惊叹它为什么总是能猜到你到底想要些什么。推荐引擎的魔力在于你不清楚在这个推荐背后,引擎到底记录和推理了些什么。

通过这篇综述性的文章,你可以了解,其实推荐引擎只是默默的记录和观察你的一举一动,然后再借由所有用户产生的海量数据分析和发现其中的规律,进而慢慢的了解你,你的需求,你的习惯,并默默的无声息的帮助你快速的解决你的问题,找到你想要的东西。

其实,回头想想,很多时候,推荐引擎比你更了解你自己。

通过第一篇文章,相信大家对推荐引擎有一个清晰的第一印象,本系列的下一篇文章将深入介绍基于协同过滤的推荐策略。在现今的推荐技术和算法中,最被大家广泛认可和采用的就是基于协同过滤的推荐方法。它以其方法模型简单,数据依赖性低,数据方便采集,推荐效果较优等多个优点成为大众眼里的推荐算法“No.1”。本文将带你深入了解协同过滤的秘密,并给出基于 Apache Mahout 的协同过滤算法的高效实现。Apache Mahout 是 ASF 的一个较新的开源项目,它源于 Lucene,构建在 Hadoop 之上,关注海量数据上的机器学习经典算法的高效实现。

感谢大家对本系列的关注和支持。

回页首

声明

本人所发表的内容仅为个人观点,不代表 IBM 公司立场、战略和观点。


参考资料

学习

  • Toward the Next Generation of Recommender Systems: A Survey of the State-of-the-Art and Possible Extensions, Adomavicius, G.; Tuzhilin, A., 2005:2005 年的论文,对现今流行的推荐技术进行总结,深入具体的实现技术方法,同时也提出了对下一代推荐引擎的展望。
  • A Taxonomy of RecommenderAgents on the Internet, Montaner, M.; Lopez, B.; de la Rosa, J. L., 2003, 对互联网上推荐引擎进行总结,给出的不同推荐方法的分类和特点,帮助读者对推荐引擎有全面的认识。
  • Amazon: www.amazon.com:推荐技术的先驱,Amazon 在 B2C 领域的推荐技术值得大家参考。
  • 豆瓣:www.douban.com:作为国内社交网络的先驱,豆瓣在推荐技术上也处于领先的位置,同时对于不同内容的推荐策略有深入的研究。
  • 个性化推荐技术漫谈:对个性化推荐技术的基本原理进行简要介绍,提出了作者对优秀的个性化推荐的多角度认识
  • Google Recommender System Group:推荐系统的 Google 讨论组,有很多关于推荐引擎的有趣讨论
  • Recommender System Algorithms:关于推荐引擎算法的资源
  • Design of Recommender System:关于推荐引擎的设计方法的介绍
  • How to build a recommender system:这个演示给出了如何构建一个推荐引擎,并结合例子详细介绍了基于协同过滤的推荐策略。
  • developerWorksWeb技术专区:数百篇关于 Web 编程各个方面的文章。
  • developerWorks Ajax 资源中心:这是有关 Ajax 编程模型信息的一站式中心,包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。
  • developerWorks Web 2.0 资源中心,这是有关 Web 2.0 相关信息的一站式中心,包括大量 Web 2.0 技术文章、教程、下载和相关技术资源。您还可以通过 Web 2.0 新手入门栏目,迅速了解 Web 2.0 的相关概念。
  • 查看 HTML5 专题,了解更多和 HTML5 相关的知识和动向。


讨论

  • 加入 developerWorks 中文社区。


作者简介

赵晨婷,现就职于 IBM 中国软件开发中心 Web 2.0 开发小组,对 SOA,J2EE,Web 2.0 应用的开发有丰富的经验。主要关注点在数据处理,数据搜索,推荐算法和推荐系统设计等。


马春娥,工作在 IBM CSDL web2.0 team,开发人员,曾参与 Project Zero 和 Lotus Mashup Center 的开发。主要的关注点在 web2.0 领域的数据的建模,数据的处理,数据的可视化,Web2.0 领域的数据的语义,数据的关联等。

posted @ 2011-12-01 23:34 yuejianjun 阅读(7) 评论(0) 编辑
 

 

 目前所有对用户行为的分析莫过于这种几种模式:用户注册信息,定制列表,操作记录,用户历史轨迹跟踪等。但是这些都只是用户行为分析中的冰山一角,在实际分析过程中,维度(www.vdoing.com)将诸多信息进行权重排序,提炼核心信息来构建一个3维的统计分析体系。

  

 

  对于一个新站点来说,进行用户行为分析,最缺乏的是用户在站内的行为轨迹。因为没有一定量的数据,是很难通过正态分析,也没有办法进行聚类分析,无法确立群体特征的。如果一个新站希望能够在用户行为分析和挖掘上有一定的作为,在使用一般统计和分析情况下将非常困难,可能要从跟踪用户的所有轨迹,然后不断的沉淀才能逐步的实现。所以真正想分析出网站用户群体的特点,在传统的统计办法中,是很难在很短时间内完成的,基于这个情况,导致很难在短时间内完成用户行为分析,如果完成了,其结果也是很难准确的。

  对于一个已经有百万以上会员的网站来说,进行用户行为分析和挖掘,在传统统计分析过程第一步是需要分离用户,这也是一个非常艰难的事情。只有分离用户后,才可以找出有价值的用户,进行深度分析,使用传统办法,难度也将相当大。

  对于以上问题,或者说对于任意一个在互联网上活动的人来说,都可以将任何用户的访问过程进行定义,即:某个人、在某个区域、 在某个网络环境下、使用某个计算环境、 需要寻找或者处理某件事情,接着产生访问某个网站产生某些行为,对这些数据进行提炼分析,从而解决以上对用户访问分析的深度挖掘。

  维度将他们这个行为过程进行如此的分解:

  1、 某个人(性别、年纪、职业)

  2、 在某个区域(物理地址,比如:北京某地区)

  3、 在某个网络环境下(运营商,比如:北京电信ADSL)

  4、 使用某个计算环境(操作系统、IE等 ...)

  5、 需要寻找或者处理某件事情(如:查找信息或浏览)

  6、 接着产生访问某个网站产生某些行为(鼠标事件 。。。。)

  网站流量统计系统,是挖掘网站用户行为最重要的工具之一,因为统计系统是目前最详细记录访客行为过程的一种工具,我们将数据挖掘分为3个阶段,

  第一个阶段为:数据的采集和统计。

  第二个阶段则是对采集到的数据进行过滤和分析,

  第三阶段:也就是对已经过滤和初步分析的数据进行聚类等等分析,挖掘出其中蕴含的价值点或者方法。

  但是目前所有的网站流量统计系统都只做到了对数据的第一层,即:用户部分信息的统计,甚至这些部分的数据也没有完整获得。所以对于网站用户的深度分析,目前依然是一个具备相当挑战的工作,,对于数据分析领域,其中之艰辛,其中的难度远非常人可以想象。基于用户的行为过程,我们可以简单的如下归类,同时将用户行为定义为一个3个维度综合信息的体系

  1、 某个用户(用户性别、年纪等核心数据)

  2、在某段时间内(随着自然时间的推移,进行正常时间的记录)

  3、产生了某个行为(网络上的行为基本可以分为2种具体体现,即:1、键盘操作。2、鼠标行为。对于键盘操作信息,基本上是完全放弃,因为涉及用户隐私等基本原则问题,属于统计禁地。对于鼠标行为,只包括对用户鼠标轨迹,鼠标点击URL事件的记录,技术上可以实现,同时不直接涉及用户个人隐私,或相对较少,可能带来的危害性较小)

  

 

  基于这些过程信息,我们将用户访问过程进行归纳,提炼其访问过程核心信息。

  1、 某个用户,核心信息包括:用户性别、用户年纪、用户职业

  该数据只能为概率数据,原因如下:在基于一定基数的情况下,统计大量已知性别,年纪用户鼠标轨迹行为的特点后归纳其行为特征,寻找合适的轨迹算法,但是该轨迹算法是基于基准行为库的概率统计,所以该数据只可能以概率的形式在这个体系下表现。

  

 

  2、 用户行为,核心信息包括:鼠标鼠标滑动轨迹、鼠标点击热区、鼠标点击时间顺序

  

 

  

 

  3、 内容信息,核心信息包括:鼠标点击URL附着文字内容,对附着文字进行分词分析,确定其内容类别以及文本特点。

  

 

  未完待续,维度统计(www.vdoing.com)

  附,某网站用户热区图

  

 

posted @ 2011-12-01 23:33 yuejianjun 阅读(25) 评论(0) 编辑

2011年11月9日

索引文件类型:
1 Segments文件。记录索引片断文件的情况。
2.Deletable文件
3.Fields域数据文件(.fnm)。Field的名字都存储在Field信息文件中,后缀是.fnm。   
4.存储的Field(.fdx和.fdt)。
  Index(.fdx) 对每个文档来说,存储指向它的fields数据(.fdt)的指针(pointer)
  Fields Data(.fdt)这个文件存储每个文档的field数据
5.存储的term字典(.tii和.tis)
  Term字典使用如下两种文件存储,第一种是存储term信息(TermInfoFile)的文件,即.tis文件
  另一种是存储term信息的索引文件,即.tii文件,该文件包含.tis文件中每一个IndexInterval的值,与它在.tis中的位置一起被存储,这被设计来完全地读进内存中(read entirely into memory),以便用来提供随机访问.tis文件。该文件的结构与.tis文件非常相似,只是添加了一项数据,即IndexDelta。
6. Term频率数据(.frq)。Term频率数据文件(.frq文件)存储容纳了每一个term的文档列表,以及该term出现在该文档中的频率(出现次数frequency,如果omitTf设置为fals时才存储)。
7. Positions位置信息数据(.prx)。Positions位置信息数据文件(.prx文件)容纳了每一个term出现在所有文档中的位置的列表。注意如果在fields中的omitTf设置为true时将不会在此文件中存储任何信息,并且如果索引中所有fields中的omitTf都设置为true,此.prx文件将不会存在。
8. Norms调节因子文件(.nrm)
9. Term向量文件。Term向量(vector)的支持是field基本组成中对一个field来说的可选项,它包含如下4种文件: 文档索引或.tvx文件;文档或.tvd文件;域field或.tvf文件。
10.删除的文档 (.del)。删除的文档(.del)文件是可选的,而且仅当一个segment存在有被删除的文档时才存在。即使对一单个segment,它也是维护复合segment的外部数据(exterior)。  
11.Lock文件。写锁(write lock)文件名为“write.lock”,它缺省存储在索引目录中
索引过程
1.DocumentsWriter是由IndexWriter调用来负责处理多个文档的类,它通过与Directory类及Analyzer类、Scorer类等将文档内容提取出来,并分解成一组term列表再生成一个单一的segment所需要的数据文件,如term频率、term位置、term向量等索引文件,以便SegmentMerger将它合并到统一的segment中去
 
2.Lucene中基本的概念(fundamental concepts)是index、Document、Field和term。
     
1  一条索引文件(index)包含(contains)了多个(a sequence of)文档(documents)。
2  一个文档(document)是由一连串fields组成。
3  一个field是由一连串命名了(a named sequence of)的terms(词)组成。
4  一个term是一个string(字符串)。
注:一个terms(词)对应多个doc的field(字段),通过跳跃表,找到多个terms(词)的并集docID
posted @ 2011-11-09 17:44 yuejianjun 阅读(15) 评论(0) 编辑
 

根据搜索关键字分词后的多个词属性 term<位置 长度 权重 >,提取一定长度范围内的短语,计算权重 多个词的权重和

from:《走进搜索引擎 》

posted @ 2011-11-09 14:25 yuejianjun 阅读(13) 评论(0) 编辑
 
1 转到定义: F12;  
2 设置书签:Ctr+K+K;  
3 设置任务: //TODO:something,查看任务Ctrl+W+T;  
4 查找:Ctrl+ F, Ctrl+Shift+F;  
5 强迫智能感知:Ctrl+J;  
6 强迫智能感知显示参数信息:Ctrl-Shift-空格;  
7 格式化整个块:Ctrl+K+F;  
8 全屏幕:Alt+Shift+Enter;  
9 设置书签:Ctrl+B+T,跳转书签:Ctrl+B+N  
10 检查括号匹配(在左右括号间切换): Ctrl +]  
11 选中从光标起到行首(尾)间的代码: Shift + Home(End)  
12 在方法定义和调用之点切换:Ctrl+Shift+7(8)  
13 设置断点:F9  
14 查找所有引用: Shift + F12  
15 注释代码,助记方法,Edit + Comments:Ctrl + E,C  
16 取消注释, 助记方法:Edit + UnComments:Ctrl + E,U  
17 格式代码, 助记方法:Edit + Document(只能在代码能编绎的情况下起使用):Ctrl + E,D  
18 收拢代码:Ctrl+M, O  
19 选中自己圈中的长方块:Alt+Shift+鼠标  
20 调试模式下,“调试——窗口——反汇编”,或者ctrl + alt + d  
21 按下Ctrl+Enter会在上面插入一个空行,Ctrl+Shift+Enter则会在下面插入一个空行。光标会移至新行的开始处。  
22 使用Tab增加缩进,Shift+Tab减少缩进(相应的菜单命令在Edit - Advanced 中)  
23 格式化整篇代码: Ctrl+K, D  
24 用Ctrl+W选中当前字  
25 单个节点折叠与打开开关: Ctrl+M, M  
26 使用Ctrl+G跳至指定行  
27 使用Ctrl+Delete和Ctrl+Backspace分别删除后继和前驱的词  
28 使用Ctrl+L剪切当前行,Ctrl+Shift+L删除当前行  
29 如何创建书签并在其中进行跳转?(推荐)按下Ctrl+K, Ctrl+K 可以创建/取消一个书签,该命令绑定至Edit.ToggleBookmark,如果你的快捷键与此不同,可通过命令来查看具体的快捷键。30 使用Ctrl+J来帮助语句完成。
1 转到定义: F12;  
2 设置书签:Ctr+K+K;  
3 设置任务: //TODO:something,查看任务Ctrl+W+T;  
4 查找:Ctrl+ F, Ctrl+Shift+F;  
5 强迫智能感知:Ctrl+J;  
6 强迫智能感知显示参数信息:Ctrl-Shift-空格;  
7 格式化整个块:Ctrl+K+F;  
8 全屏幕:Alt+Shift+Enter;  
9 设置书签:Ctrl+B+T,跳转书签:Ctrl+B+N  
10 检查括号匹配(在左右括号间切换): Ctrl +]  
11 选中从光标起到行首(尾)间的代码: Shift + Home(End)  
12 在方法定义和调用之点切换:Ctrl+Shift+7(8)  
13 设置断点:F9  
14 查找所有引用: Shift + F12  
15 注释代码,助记方法,Edit + Comments:Ctrl + E,C  
16 取消注释, 助记方法:Edit + UnComments:Ctrl + E,U  
17 格式代码, 助记方法:Edit + Document(只能在代码能编绎的情况下起使用):Ctrl + E,D  
18 收拢代码:Ctrl+M, O  
19 选中自己圈中的长方块:Alt+Shift+鼠标  
20 调试模式下,“调试——窗口——反汇编”,或者ctrl + alt + d  
21 按下Ctrl+Enter会在上面插入一个空行,Ctrl+Shift+Enter则会在下面插入一个空行。光标会移至新行的开始处。  
22 使用Tab增加缩进,Shift+Tab减少缩进(相应的菜单命令在Edit - Advanced 中)  
23 格式化整篇代码: Ctrl+K, D  
24 用Ctrl+W选中当前字  
25 单个节点折叠与打开开关: Ctrl+M, M  
26 使用Ctrl+G跳至指定行  
27 使用Ctrl+Delete和Ctrl+Backspace分别删除后继和前驱的词  
28 使用Ctrl+L剪切当前行,Ctrl+Shift+L删除当前行  
29 如何创建书签并在其中进行跳转?(推荐)按下Ctrl+K, Ctrl+K 可以创建/取消一个书签,该命令绑定至Edit.ToggleBookmark,如果你的快捷键与此不同,可通过命令来查看具体的快捷键。30 使用Ctrl+J来帮助语句完成。
posted @ 2011-11-09 13:42 yuejianjun 阅读(17) 评论(0) 编辑

2011年11月7日

摘要: http://quweiprotoss.blog.163.com/blog/static/408828832011523114133876/ 一个经典的问题,也就是10^N个数,远超过内存的大小,如何排序。答案虽然我自己也想到了,但别人更早想到,经典做法,把文件拆成多份,然后多线程对文件分别进行排序,然后进行多路归并,多路归并时,经典做法就是用优先队列。这也是Lucene在And操作时选择的方法,在DisjunctionSumScorer中有ScorerDocQueue scorerDocQueue,它就是一个优先队列。ScorerDocQueue的成员有:/*保存堆中的元素*/privat.阅读全文
posted @ 2011-11-07 12:14 yuejianjun 阅读(55) 评论(0) 编辑

2011年11月4日

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
using Comm;
using Entity;

namespace Service
{
   public class SearchTask
    {
        public static ReturnItem TaskSearchModuleSecond(QueryItemEntity queryItemEntity)
        {
            string[] indexPath = Profile.IndexModuleSecondPath();
            Task<ReturnItem> parentTask = new Task<ReturnItem>(() =>
            {
                IList<Task<ReturnItem>> taskArray = new List<Task<ReturnItem>>();

                for (int i = 0; i < indexPath.Length; i++)
                {
                    string path = indexPath[i];

                    Task<ReturnItem> childTask = new Task<ReturnItem>
                         (() =>
                         {
                             ReturnItem result = SearchService(queryItemEntity, path);
                             return result;
                         }, TaskCreationOptions.AttachedToParent);
                    taskArray.Add(childTask);
                }

                foreach (Task<ReturnItem> t in taskArray)
                    t.Start();

                ReturnItem listResult = new ReturnItem();

                foreach (Task<ReturnItem> t in taskArray)
                {
                    listResult.TotalHits += t.Result.TotalHits;
                    if (listResult.ReturnList == null)
                    {
                        listResult.ReturnList = t.Result.ReturnList;
                    }
                    else if (t.Result.ReturnList != null)
                    {
                        listResult.ReturnList.AddRange(t.Result.ReturnList); 
                    }
                } 
                return listResult;
            });
            parentTask.Start();
            parentTask.Wait();
            ReturnItem list = parentTask.Result;
            list.ReturnList.Sort((IndexEntity x, IndexEntity y) => y.Rank.CompareTo(x.Rank));
            return list;
        }
        public static ReturnItem SearchService(QueryItemEntity queryItemEntity, string path)
        {
          ReturnItem r=  SearchBase.MainSearch(queryItemEntity,false ,true ,path );
          return r;
        }
    }
}
posted @ 2011-11-04 17:33 yuejianjun 阅读(8) 评论(0) 编辑

2011年11月3日

摘要: usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingBusiness;usingLucene.Net.Index;usingLucene.Net.Documents;usingLucene.Net.Analysis;usingLucene.Net.Analysis.PanGu;usingLucene.Net.Search;usingLucene.Net.Store;namespaceIndex{classProgram{privatestaticstringpath=@"D:\Work\HotelInde阅读全文
posted @ 2011-11-03 15:56 yuejianjun 阅读(54) 评论(0) 编辑

2011年10月15日

摘要: 集中、分布式搜索引擎的4种设计方案共1页 对于搜索引擎, 在索引量和搜索量大到一定程度的时候, 索引更新的效率会逐渐降低, 服务器的压力逐渐升高, 因此基本上整个搜索引擎的利用率可以说是越来越低了, 并且随着海量数据存储带来的困难, 设计一个良好的分布式搜索引擎将是一个搜索引擎能否面相未来发展的关键因素了. 那么分布式搜索引擎的最主要的核心问题是哪些呢? 1. 分布的信息获取和计算以及对此进行的数据统一 这里面包括爬虫/或者相应的数据获取机制的分布, 对信息进行加工的统一管理 2. 数据处理后的分布存储和管理 主要是文件的准确定位和更新,增加,删除,移动的机制 3. 前端搜索服务...阅读全文
posted @ 2011-10-15 01:37 yuejianjun 阅读(27) 评论(0) 编辑