推荐系统杂谈[转]

本文出自  飒然Hang

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

首先须要明确的就是推荐系统的目标，通常来讲不外乎如下几个：

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

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

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

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

个性化推荐系统

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

个性化推荐系统通常由日志系统、推荐算法、内容展现UI三部分组成。

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

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

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

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

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

基于此框架，个性化推荐系统的典型流程以下所示：

可知，一个推荐系统主要有如下模块组成：

• 用户行为日志：此部分主要是用户行为日志的存储，属于数据统计的一部分, 存储在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]，这样的算法工程师才能根据实际问题创建模型或者创建规则库，是真正能解决问题的人。每每是一些有研究背景，经验丰富的研究员，更加剧视工程，由于工程架构上一些恰当合理的设计，效果每每就能远远高过于模型算法优化。
• 学院派的【算法工程师】每每是为了算法而算法，而不是为了解决推荐系统的问题去找最适合算法。这也是为何大公司常常招了一些博士毕业的算法工程师后，不是研究算法而是让他们成天在那看数据报表？【由于发现算法没啥好研究，只能让他们在那看看报表找找规律了。】
• 【几乎全部所谓的智能推荐算法都是花拳绣腿】
• 当一个作推荐系统的部门开始重视【数据清理，数据标柱，效果评测，数据统计，数据分析】这些所谓的脏活累活，这样的推荐系统才会有救。

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