一个推荐系统，实现完整的设计-在百度搜索关键词推荐案例

在之前一篇博文中， 有同学在评论中问了个问题： 怎样解决因式分解带来的推荐冷门。热门关键词的问题。 在回答这个问题的时候， 想到了近几年在做搜索推荐系统的过程中， 学术界和工业界的一些差别。 正好近期正在做技术规划， 于是写偏文章说下工业界完整推荐系统的设计。结论是： 没有某种算法可以全然解决这个问题， 多重算法+交互设计， 才干解决特定场景的需求。

下文也对之前的一些博文进行梳理。构成一个完整工业界推荐系统所具有的方方面面（主要以百度关键词搜索推荐系统为例）

完整的推荐系统肯定不会仅仅用一种推荐算法

在学术界。 一般说到推荐引擎， 我们都是环绕着某一种单独的算法的效果优化进行的， 比如按内容推荐， 协同过滤（包含item-based, user-based, SVD分解等），上下文推荐。Constraint-based推荐。图关系挖掘等。

非常多比較牛的单个算法。 就能在某个指标上取得较好效果。 比如MAE。RMSE。。。只是有自己的长处。 每种算法也有自己的缺点。 比如按内容推荐主要推荐和用户历史结果相似的item，一般的item-basedeasy推荐热门item（被很多其它人投票过）。。。。 所以在工业界。比如各互联网公司，
都会使用多种算法进行互相配合， 取长补短， 配合产品提升效果。

并且在完整的推荐系统中，不仅有传统的Rating推荐。 还须要辅以许多的挖掘， Ranking来达到预期效果。

推荐系统3大件：User Profile、基础挖掘推荐、Ranking

在实践中， 一个完整的推荐系统会主要由3部分组成：

User Profile
基础推荐挖掘算法
Ranking

此处之所以将Ranking单独列出来，是由于其在推荐任务中过于重要。直接决定了推荐的效果。

下面为整个推荐的数据流：

User Profile

A user profile is a representation of information about an individual user that is essential for the (intelligent) application we are considering user profile主要是用户（注冊）信息，以及对用户反馈的信息进行处理，聚合，用于描写叙述用户的特征。 是兴许推荐和排序的基石。 普通情况下。user profile会包括下面详细内容：

用户兴趣数据
用户的基础注冊信息，背景信息：比如用户出生地，年龄，性别，星座，职业等。这些信息一般从用户注冊信息中获取。比如高德，百度地图注冊用户，淘宝注冊用户等
用户行为反馈：包含显示的反馈(explicit)和隐藏(implicit)的反馈，显示的反馈包含用户的评分，点赞等操作。百度关键词搜索推荐工具上的点赞（正向显示反馈）和垃圾桶（负向显示反馈），淘宝上的评分；隐式反馈包含用户的浏览行为，比如在百度关键词搜索推荐上搜过那些词，淘宝上点击了那些页面，在高德上点击了那些POI等
用户交互偏好：比如用户喜欢使用哪些入口，喜欢哪些操作，以及从这些操作中分析出来的偏好，比方在高德地图上依据用户行为反馈分析出来的用户对美食的偏好：更喜欢火锅，粤菜，还是快餐
用户上下文信息：这些信息有些是分析出来的，比如在LBS中分析出来的用户的家在哪儿，公司在哪儿，常常活动的商圈，常常使用的路线等

user profile常常是一份维护好的数据。在使用的时候，会直接使用该数据，或是将该数据存储在KV系统中。供Online系统实时使用。 在搜索或是推荐的场景下，每次请求一般仅仅会涉及到一次user profile的KV请求，所以online使用的时候。基本的实现困难是存储。以及高速KV的高速响应。

基础挖掘推荐算法

基础挖掘推荐算法， 主要使用传统推荐算法， 结合分析的item profile和user profile， 建立user和item的关系，此时并不会过多考虑其它因素。比如是否冷门/热门，最基本的就是建立user和item的关系。 在各种论文中狭义的推荐。主要就是指该部分内容。 主要环绕着Rating，以及Top N进行该处的Top N（更像是直接Rating值最高的Top N） 传统的推荐算法研究主要围着这块工作进行。如今已经有非常多比較成熟的算法。这些算法相关的研究可參见博文：《推荐系统经典论文文献及资料》；当中也能找到业界较多成功推荐系统的实践分享
主要包括下面几类：

Content Based推荐： 按内容推荐，基本的工作是user profile, item profile的提取和维护，然后研究各种相似度度量方法（详细相似度度量參见博文：《推荐系统中的相似度度量》）
协同过滤：相当于应用了用户的行为进行推荐（差别于Content based算法）。比較经典的算法包含传统的item-based/user-based算法（參见博文：《协同过滤中item-based与user-based选择依据》，《collaborative-filtering依据近邻推荐时须要考虑的3要素》）。SVD，SVD++(详细原理及源代码參见博文：《SVD因式分解实现协同过滤-及源代码实现》)
上下文相关推荐：和传统推荐相比， 考虑很多其它上下文因素。LBS。 移动场景下使用比較多（详细參见博文：《context-aware-recommendation》）
基于图的关系挖掘推荐：主要是利用图论原理，依据item,user之间的数据，反馈关联关系。挖掘更深层次的关系进行推荐。该类方法一般效果都不错，当然资源要求也较高。

详细參见博文：《级联二步图关系挖掘关键词推荐系统》，《频繁二项集合的hadoop实现》《itemrankrandom-walk-based-scoring-algorithm-for-recommener-system》
Constrainted-based推荐：依据限制性条件进行演绎推荐

在实际应用时。我们常常使用按内容推荐，item-based寻找从感知的角度比較靠谱的结果。使用SVD,SVD++。图关系寻找更深层次的联系结果。

同一时候在推荐时，会结合非常多因素来进行综合排序，比如关键词， 或是LBS中POI的热度等。详细可參见下文ranking部分。

算法效果衡量

以上这些算法。 我们在离线的时候。使用Cross-Validation方式，就能够分析出其效果。并且离线分析的时候，代价比較小，比較easy操作。当然，对于不同的问题会使用相应的指标进行衡量。 对于预測Rating准确性主要是用RMSE，或是MAE；详细可參见博文：《关键词搜索推荐系统中的推荐准确性度量》
假设是排序。 则很多其它使用NDCG，MAP, MRR等指标。详细可參见博文：《使用ndcg评估关键词推荐系统的相关性》
在详细应用场景中。对于特定推荐问题，会涉及到选用哪种算法的问题。推荐不像CTR预估这种问题，目标比較单一，常常我们须要考虑多个指标，并且这些指标可能此消彼长。须要做权衡。比如须要考虑算法的准确性(accuracy)，同一时候也须要考虑算法的覆盖(coverage)。置信度（confidence）,新奇度(novelty)和惊喜度(Serendipity)。同一时候还须要考虑推荐为系统带来的收益和效用(utility)。 这些指标常常须要权衡，并且常常提升某一个的时候会导致其他下降，所以有时候存在一定的主观性：我们究竟看中哪一个指标？
并且这个问题可能随着系统，平台所处的阶段而不同。 比如在建立口碑的时候，我们可能不太关注coverage，而更关注accuracy，由于要让用户建立一种：该系统非常准的认知；假设在系统已经比較成熟了，此时可能须要考虑novelty, serendipity的同一时候，还须要考虑utility：该推荐能为系统带来什么收益。比如对百度的变现有多大收益？ 对淘宝的销售有多少收益等 详细这些指标的选择可參见博文：《选择推荐算法时须要考虑得因素》

Ranking，此部分是成熟的搜索，推荐系统具有的核心逻辑

比較简单的实现方法， 是直接对各种特征拍阈值进行线性加权，比較成熟的系统通常会使用机器学习的方式和综合个维特征， 学习出模型后进行排序， 比如使用Learning to rank技术。 该部分须要考虑的因素较多较为复杂。 和传统的推荐相比， 此处单独将Ranking拿出来。 基础推荐挖掘， 和传统的推荐部分比較类似，主要结合user profile， 挖掘哪些item适合推给哪些user。

但仅依据这些挖掘就直接进行推荐是不够的。 真实online推荐场景中， 须要考虑很多其它其它因素。 比如：相关性，推荐的上下文，CTR预估，以及商业业务规则。

相关性： item与用户的相关性，这是大多数搜索和推荐任务的基石。比如在搜索中判定一个query和一个document的相关性，或是一个query 和 还有一个query的相关性，或是在特征比較多的情况下。 一个user 和一个item 记录的相关性；实现方式能够非常easy，比如传统的相似度度量方式（參见博文：《推荐系统中的相似度度量》），对于文本，业界使用简单的TF*IDF，或是BM25。
只是非常多时候我们须要添加很多其它维度特征，包含推荐item本身的重要性，比如IDF，Pagerank(详细參见博文：《pagerank的经济学效用解释》)。同一时候使用模型来提升相关性推断的准确性。

使用模型的方式会更加复杂，但效果提升也非常明显。详细可參见博文：《集成树类模型及其在搜索推荐系统中的应用》。《分类模型在关键词推荐系统中的应用》，《adaboost》
推荐的上下文：比如推荐产品的入口。交互方式。 不同的入口，甚至同一入口的不同交互方式。 推荐的结果有可能都须要不一样； 在LBS生活服务中， 请求发生的时间， 地点也是推荐须要重点考虑的上下文因素。比如饭点对餐饮item的提权。 异地情况下对酒店等结果的加权等
CTR预估：成熟的商业系统都会使用模型来完毕CTR预估，或是转化预估
以及商业业务规则：比如黑白名单，或者强制调权。

比如在百度关键词搜索推荐中。某些有比較高变现潜力的词。 就应该加权往前排； 比方在高德LBS服务中，有些海底捞的店点评评分较低。 但我们也应该往前排；或是在搜索引擎中。搜国家领导人的名字。 有些最相关的结果可能由于法律因素是须要屏蔽的

算法评估

非常直接，离线调研的时候看就看算法的评估指标，參见博文：《关键词搜索推荐系统中的推荐准确性度量》。《使用ndcg评估关键词推荐系统的相关性》
上线的时候，进行圈用户（圈定某两个user集合作为实验/对比用户组）实验， 或者圈请求实验（比如随机圈定5%流量进行实验），之后依据系统效果监控中的指标值推断实验效果。

下面为一个典型的效果监控截图： 实验假设证明成功，达到预期效果。一般之后推广到全流量；反之，假设实验未达到预期效果，则须要分析什么地方有问题。怎样改进，之后继续调整算法继续实验。

当实验较多时。还会涉及较多project问题，比如分层实验框架等。

系统效果监控

对于整个系统，须要建立晚上的效果监控平台进行效果的实时监控，以便发现用户的行为模型，系统的不足，分析兴许的发力点等。

一般这种监控平台会使用Dashboard来完毕，主要的框架是前段UI + 后端数据库。非常多时候，离线统计策略在hadoop上处理统计日志计算指标，并将计算出来的指标存入数据库。前端UI訪问数据库。拉出指定时间段内某些指标的值，并进行简单分析。 详细的监控指标，及指标体系的建立。可參见博文：《搜索引擎变现策略指标体系》

交互设计

完整的产品包含便捷的交互和背后牛叉的算法。非常多时候，要提升推荐的效果，须要算法和交互配合，才干达到理想的效果： 交互须要有健壮的算法产出结果；而算法也须要有配套的交互，才干达到预期效果。否则再牛叉的算法，对结果的影响也可能没那么明显。

一些交互的样例參见博文：

《关键词推荐工具中的用户引导机制之中的一个：总述》

《关键词推荐工具中的用户引导机制之二：suggestion架构》

《关键词推荐工具中的用户引导机制之三：相关搜索query技术》

《关键词推荐工具中的用户引导机制之四：种子query推荐》

说了那么多，中心就是想说明， 一个完整的推荐系统。远远不止是一两个rating算法可以覆盖的。并且此处还未涉及project部分。

很多其它内容，也可以直接访问： http://semocean.com