chp1:推荐系统框架

一、背景介绍
当下，个性化推荐成了互联网产品的标配。但是，人们对推荐该如何来做，也就是推荐技术本身，还不甚了解。为此，好学的你肯定在收藏着朋友圈里流传的相关文章，转发着微博上的相关讨论话题，甚至还会不断奔走在各种大小行业会议之间，听着大厂职工们讲那些干货。我知道，这样碎片化的吸收，增加了知识的同时，也增加了焦虑。因为技术的不平等广泛存在于业界内，推荐系统也不例外。推荐系统从搜索引擎借鉴了不少技术和思想，比如内容推荐有不少技术就来自搜索引擎， 由 Amazon 发扬光大的。推荐系统也是现在热门的人工智能分支之一，但凡人工智能类的落地，都需要具备这几个基本元素才行：数据、算法、场景、计算力。推荐系统也不例外，而刚好，现在的时代，这些元素的获得成本相比十年前已经小了很多。未来随着各种硬件设备越来越智能，万物互联得越来越紧密，人们的个性化需求、场景的多样性、数据的复杂性都对推荐系统提出了更高的要求。

二、主要内容

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

基于这些目标，推荐系统包括四种推荐方式：
1、热门推荐：就是热门排行榜的概念。这种推荐方式不仅仅在IT系统，在平常的生活中也是处处存在的。这应该是效果最好的一种推荐方式，毕竟热门推荐的物品都是位于曝光量比较高的位置的。
2、人工推荐：人工干预的推荐内容。相比于依赖热门和算法来进行推荐。一些热点时事如世界杯、nba总决赛等就需要人工加入推荐列表。另一方面，热点新闻带来的推荐效果也是很高的。
3、相关推荐：相关推荐有点类似于关联规则的个性化推荐，就是在你阅读一个内容的时候，会提示你阅读与此相关的内容。
4、个性化推荐：基于用户的历史行为做出的内容推荐。也是本文主要讲述的内容。
其中，前三者是和机器学习没有任何关系的，但却是推荐效果最好的三种方式。一般说来，这部分内容应该占到总的推荐内容的80%左右，另外20%则是对长尾内容的个性化推荐。

三、推荐框架设计

下面单个介绍上面的每个部分：
1、数据平台
作用：主要是存储推荐系统物品相关数据、用户行为日志收集，为模型、推荐提供源数据服务。
模型特征数据、用户实时日志数据、推荐商品/物件的基础数据
2、算法模型

核心模块
业务网关，推荐服务的入口，负责推荐请求的合法性检查，组装请求响应的结果。
推荐引擎，推荐系统核心，包括online逻辑，召回、过滤、特征计算、排序、 多样化等处理过程。

数据路径
1、请求的刷新从gateway，经过流量分配模块，传到业务gateway，业务gateway支持http，tcp（使用thirtf协议或者protobuf 协议）等多种类型接口；
2、用户行为数据，从gateway到Flume agent，然后到kafka，为后面online，realtime userprofile部分的提供实时数据，也为offline部分的数据存储系统提供数据。

offline部分：
从框架的角度看，推荐系统基本可以分为数据层、召回层、排序层。
1、数据层包括数据生成和数据存储，主要是利用各种数据处理工具对原始日志进行清洗，处理成格式化的数据，落地到不同类型的存储系统中，供下游的算法和模型使用。
sessionlog：对原始数据进行清洗合并，sessionlog一般就是清洗合并后的数据，后续的算法和统计都是根据sessionlog进行再加工。
userprofile：对用户属性和行为等信息进行采集和统计，为后续算法提供特征支持。
itemDoc：对视频、商品等属性、曝光、点击等字段进行统计， 为后续算法提供特征支持。
2、召回层主要是从用户的历史行为、实时行为等角度利用各种触发策略产生推荐的候选集，对不同的策略和算法产生的候选集进行融合并按照产品规则进行过滤，一般融合和过滤后的候选集还是比较多的，一次线上请求过来之后线上系统无法对那么多的候选集进行排序，所以在召回层一般还会有粗排序，对融合的候选集进行一次粗排序，过滤掉粗排分数较低的候选集。
3、排序层主要是利用机器学习的模型对召回层筛选出来的候选集进行精排序。

推荐过程：用户行为数据—>推荐引擎（第一层过滤）—>初始推荐结果—>过滤—>排名—>推荐解释—>推荐结果。

推荐引擎的架构可以试多样化的(实时推荐的+离线推荐的)，然后融合推荐结果（人工规则+模型结果），融合方式多样的，有线性加权的或者切换式的等。

上图中，A模块负责用户各类型特征的收集，B模块的相关表是根据图3中的推荐引擎来生成的，B模块的输出推荐结果用来C模块的输入，中间经过过滤模块(用户已经产生行为的物品，非候选物品，业务方提供的物品黑名单等)，排名模块也根据预设定的推荐目标来制定，最后推荐解释的生成（这是可能是最容易忽视，但很关键的一环，微信的好友推荐游戏，这一解释已经胜过后台的算法作用了）
3、模型服务
1、用户主动行为数据记录了用户在平台的的各种行为，这些行为一方面用于候选集触发算法（在下一部分介绍）中的离线计算（主要是浏览、下单），另外一方面，这些行为代表的意图的强弱不同，因此在训练重排序模型时可以针对不同的行为设定不同的回归目标值，以更细地刻画用户的行为强弱程度。此外，用户对deal的这些行为还可以作为重排序模型的交叉特征，用于模型的离线训练和在线预测。
2、负反馈数据反映了当前的结果可能在某些方面不能满足用户的需求，因此在后续的候选集触发过程中需要考虑对特定的因素进行过滤或者降权，降低负面因素再次出现的几率，提高用户体验；同时在重排序的模型训练中，负反馈数据可以作为不可多得的负例参与模型训练，这些负例要比那些展示后未点击、未下单的样本显著的多。
3、用户画像是刻画用户属性的基础数据，其中有些是直接获取的原始数据，有些是经过挖掘的二次加工数据，比如用户的聚类和向量化，这些属性一方面可以用于候选集触发过程中对deal进行加权或降权，另外一方面可以作为重排序模型中的用户维度特征。


4、推荐架构
下面介绍几个推荐做好的公司的推荐架构

总结：netflix的推荐系统，描述了推荐引擎搭建的整体架构，采用了三种计算方式的结合。整体流程：用户通过UI产生事件跟行为，然后分发给离线（我理解的是按天存储）、近线存储（不提供历史，存储当天用户实时行为。不知道理解是否有误），离线的计算利用离线的数据建好模型供实时调用，近线的计算利用用户的实时行为计算得出规则供实时调用，最后在线的计算通过前两种方式来得到最终的推荐结果，关键问题，就是如何以无缝方式结合、管理在线和离线计算过程，当然找到这些要求之间恰当的平衡并不容易，需要深思熟虑的需求分析，细心的技术选择，战略性的推荐算法分解，最终才能为客户达成最佳的结果。


总结：淘宝的推荐系统，描述了推荐引擎搭建的整体架构，包括离线的分布式计算和存储、监控、数据统计和分析、实验平台等。给我们搭建推荐引擎提供了很好的建议。整体流程大致这样。通过后台的分布式计算，将算法产生的算法结果数据存储进入一种介质中，首推hbase。然后，通过一种叫做云梯的机制将算法结果推入中间层介质中，供推荐系统在线部分调用。在线部分提供引擎和实验分流，用户的行为将存储进入hadoop中，数据统计分析平台由hive来搭建，主要用来分析和统计hadoop中的用户行为log。这张图不仅讲了，推荐系统的架构流程，也讲了跟这个平台有关系的人，是怎么介入的，我觉得提供的信息可很好的参考。

优酷推荐架构


总结：Griddle 框架由两级架构组成. 每一个实例可以被分成多个层, 每一层由多个模块组成. 在实际应用中我们通常对发挥不同功能的层有不一样的命名. 分别是 “召回”, “规则”, “分桶”, “精排”, “组合”. 每一个类型的层并不是必须的, 视需求而定.

五、参考文献:
1)https://www.cnblogs.com/redbear/p/8594939.html
2)https://blog.csdn.net/xiangxizhishi/article/details/79441423
3)https://blog.csdn.net/qq_23269761/article/details/81567292
4)https://blog.csdn.net/qq_32023541/article/details/79798812
5)http://www.dataguru.cn/article-13949-1.html