推荐系统杂谈

标签: 推荐系统 | 发表时间:2016-08-30 20:39 | 作者:
出处:http://www.rowkey.me/

推荐系统是近些年非常火的技术,不管是电商类软件还是新闻类app,都号称有精准的推荐系统能给你推送你最感兴趣的内容。现象级的资讯类app“今日头条”就得益于此成为了势头非常猛的一款产品。本文就针对推荐系统讲述一些相关概念和实践经验。

首先需要明确的就是推荐系统的目标,一般来说不外乎以下几个:

  • 用户满意性:首当其冲的,推荐系统主要就是为了满足用户的需求,因此准确率是评判一个推荐系统好坏的最关键指标。
  • 多样性:虽然推荐系统最主要还是满足用户的兴趣,但是也要兼顾内容的多样性,对于权重不同的兴趣都要做到兼顾。
  • 新颖性:用户看到的内容是那些他们之前没有听说过的物品。简单的做法就是在推荐列表去掉用户之前有过行为的那些内容。
  • 惊喜度:和新颖性类似,但新颖性只是用户没看到过的但是确实是和他行为是相关的,而惊喜度是用户既没有看过和他之前的行为也不相关,但用户看到后的确是喜欢的。
  • 实时性:推荐系统要根据用户的上下文来实时更新推荐内容,用户的兴趣也是随着时间而改变的,需要实时更新。
  • 推荐透明度:对于用户看到的最终结果,要让用户知道推荐此内容的原因。比如,“买过这本书的人同时也买过”、”你购买过的xx和此商品类似”。
  • 覆盖率:挖掘长尾内容也是推荐系统很重要的目标。因此,推荐的内容覆盖到的内容越多越好。

基于这些目标,推荐系统包括四种推荐方式:

  • 热门推荐:就是热门排行榜的概念。这种推荐方式不仅仅在IT系统,在平常的生活中也是处处存在的。这应该是效果最好的一种推荐方式,毕竟热门推荐的物品都是位于曝光量比较高的位置的。
  • 人工推荐:人工干预的推荐内容。相比于依赖热门和算法来进行推荐。一些热点时事如世界杯、nba总决赛等就需要人工加入推荐列表。另一方面,热点新闻带来的推荐效果也是很高的。
  • 相关推荐:相关推荐有点类似于关联规则的个性化推荐,就是在你阅读一个内容的时候,会提示你阅读与此相关的内容。
  • 个性化推荐:基于用户的历史行为做出的内容推荐。也是本文主要讲述的内容。

其中,前三者是和机器学习没有任何关系的,但却是推荐效果最好的三种方式。一般说来,这部分内容应该占到总的推荐内容的80%左右,另外20%则是对长尾内容的个性化推荐。

个性化推荐系统

个性化推荐是机器学习应用的一个典型场景。在本质上和搜索引擎是一样的,同样是为了解决信息过载的问题。搜索引擎某种意义上也是一个个性化推荐系统,但是其输入特征是可以从搜索关键字直接可以得到的。而一般的推荐系统,输入特征则是需要机器学习才能得到。

个性化推荐系统一般由日志系统、推荐算法、内容展示UI三部分组成。

  • 日志系统:这是推荐系统的输入源,是一个推荐系统所有信息的源头。
  • 推荐算法:这是推荐系统的核心,根据输入数据得出最终的推荐结果的具体过程就在这里。
  • 内容展示UI:对于推荐结果如何展示,也是一个值得权衡的地方。以更好地满足推荐系统的目标,并能更好的收集用户的行为信息等。

其中,个性化推荐中最为核心的推荐算法,目前比较流行的有以下几种:

  • 基于内容的推荐:根据内容本身的属性(特征向量)所作的推荐。
  • 基于关联规则的推荐:“啤酒与尿布”的方式,是一种动态的推荐,能够实时对用户的行为作出推荐。是基于物品之间的特征关联性所做的推荐,在某种情况下会退化为物品协同过滤推荐。
  • 协同过滤推荐:与基于关联规则的推荐相比是一种静态方式的推荐,是根据用户已有的历史行为作分析的基础上做的推荐。可分为物品协同过滤、用户协同过滤、基于模型的协同过滤。其中,基于模型的协同又可以分为以下几种类型:基于距离的协同过滤;基于矩阵分解的协同过滤,即Latent Factor Model(SVD);基于图模型协同,即Graph,也叫社会网络图模型。

个性化推荐系统的典型架构如下图所示:

recommend-sys

在线业务系统的日志接入数据高速公路,再由数据高速公路迅速运转到离线数据处理平台和在线流计算平台;离线数据处理平台周期性地以批处理方式加工过去一段时间的数据,得到人群标签和其他模型参数,存放在高速缓存中,供在线业务系统使用,与此同时,在线流计算平台实时对线上的日志数据做处理,对离线计算出的数据进行补充、修正等;在线业务系统综合离线特征和在线特征使用一定的逻辑得到输出供业务使用,产生的日志流入数据高速公路。

基于此框架,个性化推荐系统的典型流程如下所示:

recommend

可知,一个推荐系统主要有以下模块组成:

  • 用户行为日志:此部分主要是用户行为日志的存储,属于数据统计的一部分, 存储在hive中。在此不做赘述。
  • 数据ETL-1:将用户日志转换为推荐算法所需要的数据格式。
  • 推荐算法:是个性化推荐最主要的部分,包括通过用户行为计算相关内容以及推荐结果等。
  • 数据ETL-2: 将推荐算法得到的结果进一步加工为存储模块的输入数据。
  • 用户画像存储:存储用户的偏好以及行为数据,如对内容关键字的偏好、点击过哪些内容等。
  • 推荐结果存储:存储各种推荐算法产生的推荐结果,可以分为两部分:{用户 : itemList}推荐结果,为用户推荐的内容列表;{item : itemList}推荐结果,与item相关的内容列表。
  • 服务调用模块:整合推荐结构,对外提供提供推荐的调用接口。

数据ETL-1

对原始的用户行为等数据进行清洗、加工,如字段、属性、格式化等,作为下一步推荐算法的输入。

推荐算法

对于个性化推荐系统来说,推荐算法应该是其最核心的部分。目前有很多流行的算法,比如:

  • 基于内容和用户画像的推荐:此种算法,可见之前的一篇文章: http://www.rowkey.me/blog/2016/04/07/up-recommend/
  • 基于矩阵分解的推荐: 基于SVD/ALS算法对用户进行内容推荐。相比起SVD,ALS更加适合解决稀疏矩阵的问题。Spark mlib中已经集成了对als算法的实现,需要做的就是在etl-1中把数据转换为als需要的数据格式以及调整als算法的各种参数。这里有一篇文章比较具体地描述了如何使用spark来做基于ALS的推荐: http://colobu.com/2015/11/30/movie-recommendation-for-douban-users-by-spark-mllib/
  • 用户&物品协同过滤推荐:包括UserBased CF和ItemBased CF。对于这两者,需要根据业务的不同来选择不同的算法。当用户非常多的时候,考虑到维护用户矩阵的成本,一般是不推荐选择用户协同过滤的,而对于候选item很多的时候,则不推荐使用物品协同过滤。

推荐算法的输出结果一般是一个用户对应一个item列表或者是一个item对应一个item列表。此部分主要考虑的是算法的时间复杂度,不管是哪一种算法,一旦用户或者内容数据上了百万级别,都需要通过分布式计算如MapReduce、Spark等来进行解决。

推荐算法的基本流程如下图所示:

数据ETL-2

对推荐算法产生的结果进行清洗、格式化等,作为下一步存储模块的输入。

用户画像存储

存储用户的偏好以及行为数据等信息。对于偏好,采用标签量化来表示,是一种随着时间衰减的值。对于用户画像,是批量写入、实时读取,所以存储要着重考虑读的性能。可以选择使用Redis集群作为技术方案,能够最大满足读的性能,缺点是Redis的成本昂贵且不支持auto index。也可使用Hbase作为存储,使用 ElasricSearch构建二级索引,以应对根据多种维度聚集用户的需求(比如过滤某一个标签下的所有用户)。

推荐结果存储

对各种推荐算法计算出的推荐结果的存储。存储空间要求大,格式复杂。对于存储的容量和读写性能要求都比较高。可以选择使用Redis集群作为此部分的存储方案。

服务调用

整合用户画像和推荐结果两部分数据,向外提供推荐调用的接口。主要是数据库IO调用开销。

  1. 根据用户id,获取推荐的item列表。
  2. 根据item,获取相关联的item列表。
  3. 根据用户id, 获取用户画像。

该模块需要采取一定的策略聚合多种推荐算法的推荐结果,直接面向业务。策略由于会随着面向的业务不同而不同,需要可配置化。同时也提供对外暴露用户画像的接口,使得业务方可以使用用户画像做针对性的处理。可以采用RPC机制对外暴露服务接口。

需要考虑的问题

对于一个推荐系统,结合其实现目标,还有一些需要注重考虑的问题。

实时性问题

由于计算用户、item矩阵或者进行矩阵分解是需要离线进行且比较耗时,因此协同的推荐算法是很难达到实时性的。实时部分的推荐主要依靠基于用户画像的推荐来进行。最终的推荐列表是根据一定的策略对这两部分进行聚合的结果。

时效性内容问题

时效性内容指的是那些与时间强相关的内容,比如新闻、时事等。如果一条10天前xx球员获得冠军的新闻现在被推荐了出来,可想用户肯定是莫名其妙或者是很失望的。因此,对于时效性内容,需要与普通的待推荐的内容区分开,做单独的推荐或者不走个性化推荐。

冷启动问题

不管使用何种推荐算法,都会面临冷启动问题:当用户是新用户,如何给用户推荐item呢?当内容是新内容,如何推荐给用户?

  • 对于新用户,可以采取的一种策略就是采用热门推荐或者人工推荐,把绝大多人关心的内容推荐出来。
  • 对于内容,可以将内容分为新内容池和待推荐内容池。新内容产生时,首先进入新内容池。每次推荐的时候,先从新内容池做候选推荐,并给此内容的传播度+1,直到其传播度大于一个阈值的时候,将其移至待推荐内容池。这样既可以解决新内容的冷启动问题也在一定程度上可以保证新内容的曝光量。

多样性问题

在基于用户画像的推荐算法中,取出用户的多个标签,然后根据相关度从不同的标签中取不同数量的内容,这样既兼顾了用户的多种兴趣也能够在一定程度上解决多样性的问题。

如:用户具有tag:A B C D,相关度为wA wB wC wD,Total推荐为总共需要推荐的条数,那么

  RecommendList(u) = A[Total推荐 * wA] + B[Total推荐 * wB] + C[Total推荐 * wC] + D[Total推荐 * wD]

内容质量

不管是热门推荐、人工推荐还是取某一标签下的内容列表都牵扯到的一个问题就是:如何给内容排序?

当用户对内容的喜好不一样,可以按照兴趣度来排序;但当无法区分兴趣度的时候(比如:用户是新用户;内容都是新内容;用户对于某一标签下的内容兴趣度一样),可以使用内容质量来做排序。 click/pv是一种评判内容质量的方式。此外,使用卷积神经网络相关算法也可以构建内容质量模型。

惊喜问题

推荐系统的惊喜目标一直是一个难题,被称作EE(Exploit & Explore)问题,bandit算法是解决这个问题的一个派系,就是估计置信区间的做法,然后按照置信区间的上界来进行推荐,以UCB、LinUCB为代表的。简单点说就是先不考虑你喜不喜欢就把质量高的内容推荐给你,后面根据用户的行为反馈对推荐内容作调整。具体的可以参见此篇文章: 推荐系统的苟且和远方

总结

借用 推荐系统的那点事一文的几句话做为结语:

  • 实力派的【算法工程师】往往都是ABC[always be coding],这样的算法工程师才能根据实际问题建立模型或者建立规则库,是真正能解决问题的人。往往是一些有研究背景,经验丰富的研究员,更加重视工程,因为工程架构上一些恰当合理的设计,效果往往就能远远高过于模型算法优化。
  • 学院派的【算法工程师】往往是为了算法而算法,而不是为了解决推荐系统的问题去找最适合算法。这也是为什么大公司经常招了一些博士毕业的算法工程师后,不是研究算法而是让他们整天在那看数据报表?【因为发现算法没啥好研究,只能让他们在那看看报表找找规律了。】
  • 【几乎所有所谓的智能推荐算法都是花拳绣腿】
  • 当一个做推荐系统的部门开始重视【数据清理,数据标柱,效果评测,数据统计,数据分析】这些所谓的脏活累活,这样的推荐系统才会有救。

以上是推荐系统实践的一些经验

相关 [推荐系统] 推荐:

Min-Hash和推荐系统

- - xlvector - Recommender System
前几年看Google News Recommendation的那篇Paper,对里面提到的MinHash的算法基本没有注意,因为之前的习惯都是只注意论文的模型那块,至于怎么优化模型一般都只是扫一眼. 不过最近看了大量的Google Paper,发现Google在实现一个算法方面确实有很多独到之处. 其实,Min-Hash是LSH(Locality Sensitive Hash)的一种,我之前对LSH的了解仅仅限于知道它能把两个相似的东西Hash成两个汉明距离接近的2进制数.

推荐系统实战

- - 博客园_首页
推荐算法:基于特征的推荐算法. 推荐算法准确度度量公式:. 其中,R(u)表示对用户推荐的N个物品,T(u)表示用户u在测试集上喜欢的物品集合. 集合相似度度量公式(N维向量的距离度量公式):. 其中,N(u)表示用户u有过正反馈的物品集合. 其中,S(u,k)表示和用户u兴趣最接近的K个用户集合;N(i)表示对物品i有过正反馈的用户集合;w(u,v)表示用户u和用户v的兴趣相似度;r(v,i)表示用户v对物品i的兴趣.

推荐系统杂谈

- - 后端技术杂谈 | 飒然Hang
推荐系统是近些年非常火的技术,不管是电商类软件还是新闻类app,都号称有精准的推荐系统能给你推送你最感兴趣的内容. 现象级的资讯类app“今日头条”就得益于此成为了势头非常猛的一款产品. 本文就针对推荐系统讲述一些相关概念和实践经验. 首先需要明确的就是推荐系统的目标,一般来说不外乎以下几个:. 用户满意性:首当其冲的,推荐系统主要就是为了满足用户的需求,因此准确率是评判一个推荐系统好坏的最关键指标.

个性化推荐系统综述

- Tony - 所有文章 - UCD大社区
上个月写过一篇产品推荐的文章,详情请见《我所了解的产品推荐》,内容很泛,多为工作心得. 本周读了几篇相关的论文,收获颇多,分享点干货. 以下内容摘自《个性化推荐系统的研究进展》,该文发表于2009年1月的《自然科学进展》专题评述,作者是刘建国、周涛、汪秉宏. 我略去了具体的算法和许多公式,重点看原理、思路和比较.

推荐系统开源工具 – SVDFeature

- Roger - Resys China
SVDFeature是我们(上海交大Apex实验室)在参加KDDCUP 2011期间开发的. 通过这个工具,我们和港科大(HKUST)的联合小组InnerPeace在KDDCUP 2011中获得Track 1第三名,并创造单模型最好成绩. 在此分享给大家,并希望和大家有更多的交流. (1)基于feature的可扩展性 —— SVDFeature实现了我们的基础模型feature-based matrix factorization.

Reculike : 开源论文推荐系统

- votis - Resys China
今天这篇博文主要总结一下reculike的系统架构. 两周前我们宣布发布了reculike的alpha版. 本着分享的原则,今天在这儿介绍一下我们的各个模块的设计方法. 我们这个项目一开始叫paperlens,这是因为我们想学习业界的前辈movielens,开发一个源代码和数据都开源的系统. 关于数据的开源,我想当用户数达到一定程度后,每个月会dump一次我们所有的数据库(密码等隐私信息除外),放到网络上供大家下载.

推荐系统那些事儿1

- - 冰火岛
知识库:用户知识库,Item知识库,用户评分数据(显性和隐性)等.不同的业务背景不一样,譬如电商,社交网络,视频,app应用等. 协同过滤引擎:根据用户评分数据集,通过collaborative filtering方法,计算用户喜欢的top N item. 数据格式: userid, itemid,score.

下一代个性化推荐系统

- - 技术改变世界 创新驱动中国 - 《程序员》官网
本文结合技术及社会需求发展的大背景,讲述了当前推荐系统的价值及所面临的挑战,并指出了下一代个性化推荐系统的设计思路及需要注意的问题. 作为个性化推荐系统核心的协同过滤(Collabora-tive Filtering)算法,是Goldberg等人在1992年的一篇学术论文中最早提出的. 他们在这篇文章中提出一种方法,在一个新闻组中,根据 用户下载的新闻计算他们之间在口味上的相似程度,并利用这种相似程度为他们进一步推荐相关的新闻.

淘宝推荐系统的学习

- - 标点符
维基百科:推荐系统属于资讯过滤的一种应用. 推荐系统能够将可能受喜好的资讯或实物(例如:电影、电视节目、音乐、书籍、新闻、图片、网页)推荐给使用者. 推荐系统大体可分为两类,即个性化推荐和非个性化推荐. 好的推荐系统更像一个有经验的网站导购员. 不同点:搜索是通过用户主动输入的关键字进行查询. 推荐则是用户在浏览网站的过程中,不一定需要用户输入,根据当前网页的上下文进行个性化的信息输出.

推荐系统那些事儿2

- - 冰火岛
学名:co –occurrence. 隐性数据:视频,社交网络,电子商务中的共同浏览,共同购买,互粉等等,对于一些隐性数据,计算共同行为,这也是最简单的. 一般的方式是,写个sql 自连接. 部分人定义为协同过滤思想,姑且看做狭义定义. 实际处理中,需要经过数据预处理,包括业务上的和技术上的. 这里,可以采用LoglikelihoodSimilarity作为相似性度量方式.