推荐系统总结

导言：我们做推荐的初衷是解决长尾效应，让那些对于某些人很适合有不经常展示的菜品（餐厅）得到展示，不能推荐的一直都是用户经常点的，热卖的菜品和餐厅，这样的话会陷入死循环，让用户看到的一直都是热卖的热门菜品或餐厅，给其他的商家没有展示的机会，会不利于平台和推荐系统的运行。

1.数据的类型

1.1）用户行为数据：1）搜索，筛选，收藏，下单，点击，评分 2）负反馈：删除，取消订单，取消收藏，退款，差评

1.2）待挖掘数据：文本评论，（图片评价）PS：这一部分，暂时初级阶段不做考虑，后来可以对用户贴标签；（挖掘提取用户特征标签，对最终的推荐结果进行修正）；

1.3）用户画像：用户性别，用户口味偏好，用户消费水平，用户工作和住地区域，年龄

2.数据使用和出来

2.1）数据特征的选择和噪音的清洗（刷单，作弊，代购，拼单）数据；

2.2）合理的选取训练时间窗口数据，数据要注意，时间衰减；

2.3）对于用户画像数据；1）作为候选集筛选时候的加权、降权，或者在二次排序的LR，GBDT，AG模型使用；

2.4）对于用户行为数据，进行基本模型和规则筛选出候选集：item-base，user-item，local-base，规则，query-base，graph-base

3.策略触发（产生候选集）

1）item-base与user-base相结合

计算用户喜爱的菜品

相似度计算方法：

闵可夫斯基距离、标准化欧式距离、马氏距离、夹角余弦距离

loglikelihood ratio[1]的相似度计算方法。在mahout中，loglikelihood ratio也作为一种相似度计算方法被采用。

下表表示了Event A和Event B之间的相互关系，其中：

　　k11 ：Event A和Event B共现的次数

　　k12 ：Event B发生，Event A未发生的次数

　　k21 ：Event A发生，Event B未发生的次数

　　k22 ：Event A和Event B都不发生的次数

则logLikelihoodRatio=2 * (matrixEntropy - rowEntropy - columnEntropy)

　　其中

　　rowEntropy = entropy(k11, k12) + entropy(k21, k22)

　　columnEntropy = entropy(k11, k21) + entropy(k12, k22)

　　matrixEntropy = entropy(k11, k12, k21, k22)

　　(entropy为几个元素组成的系统的香农熵)

2）local-base

根据用户历史消费、历史浏览来计算用户在某一个区域的热卖实物；

2.1 当新的线上用户请求到达时，根据用户的几个地理位置对相应地理位置的区域消费热单和区域购买热单进行加权，最终得到一个推荐列表；

2.2 根据用户出现的地理位置，采用协同过滤的方式计算新用户和原来这一区域用户的相似度，把相似用户的订餐菜品推荐给新用户；

3）基于搜索

搜索是一种强用户意愿，即使最后没有成功的转化，但是反应了用户的强需求；

3.1 对用户过去一段时间的query且无转换进行挖掘：计算同一用户对不同query权重（最简单，就是搜索物品占总搜索物品的占比）；

3.2 计算每个query下不同deal（交易）的权重；（计算通过搜索交易的数据：计算搜索同一关键词不同人进行交易次数的占比）；

3.3 当用户再次请求时，根据用户对不同query的权重及query下不同deal的权重进行加权，取出权重最大的TopN进行推荐：一、通过不同query的权重得到推荐的菜品候选集，在根据query下不同交易的权重 得到推荐菜品的排名；

4）图论算法

 基本思想是，如果两个实体与另外的相似实体有相关关系，那它们也是相似的，即相似性是可以传播的。

可以避免协同过滤过滤，对于user之间或item之间的图距离是独立；对于更远距离不考虑在内，而图算法可以把user和item的关系视作图上关系传播；

4.二次重排序

使用非线性模型：xg-boost、AG

使用线性模型：LR、FTRL（线上）

ps：对于非线性模型，上述特征可以直接使用；而对于线性模型，则需要对特征值做一些分桶、归一化等处理，使特征值成为0~1之间的连续值或01二值。

我们考虑的特征：

餐厅：餐厅本身属性、包括档次、折扣活动、销量、评分、类别、pv等

用户：用户基本属性、客服端类型、用户消费档次、高校/白领、口味偏好（店铺的类型）

餐厅和用户交叉特征：restaurant_user包括用户对餐厅的购买、点击、收藏、搜索

实时位置特征：用户实时地理位置、工作及其家庭地理位置、常去地理位置、POI（POI（Point of Interest），即兴趣点，每个POI包括四个方面的信息：名称、类别、经度、纬度。一家餐厅，一个酒店，一个商户，一个景点都可以成为一个独立的POI）即用户和附近餐厅的位置

5.模型的进入和训练过程

我们使用触发模型得到筛选出想用户推荐餐厅的候选集；在对候选集进行重排序，推荐给用户；

         当前（2016-06-01——2016-07-01）：由于模型框架的限制不能实时对模型进行更新限制；当前我们使用的是，在离线直接对数据集进行模型训练（没有候选集模型的参与）对于当前的在线工程而言，实现一个通过配置把离线模型加载进去的在线部分，的确没什么工作量，几行代码；但，要实现一个真正强的在线部分，都要几周时间完成，这一点从当前工程的进度而言是可以理解的；这样的话仅相当于对用户附近的餐厅使用机器学习模型进行重排序打分（注意这里我感觉当前的问题：对用户附近所有餐厅进行打分，相当于餐厅用户重排序，带来的也是有问题的：1.对于用户去了新的地方，这里由于没有用户定过的店，还是不加筛选的对附近餐厅重排序，这样的话会出现与用户没定过餐厅的不相似的餐厅；2.对餐厅进行重排序，直接来说没有对用户以前行为进行过针对性强的筛选（即产生单门推荐候选集））；当然这样做也有推荐的部分在里面，因为是通过用户行为和餐厅行为特征进行训练所以你会看到你的推荐列表中，你订过的餐厅会很靠前，但是在往下面每个人推荐的餐厅就会很接近。没什么区分度，没什么真正的个性化；3.这里如果产生候选集当然会有点附近餐厅过少问题，但是，可以使用补救策略，类似于推荐“冷启动”的方法进行避免还有近视加权分级展示；

          

           针对候选集模型的产生怎么引用到当前的模型框架中，由于现在是直接离线训练线上直接配置调用pmml模型文件，这个就需要，我们在做候选集触发的时候产生hive表（针对于当前模型框架），而后离线的pmml模型是用这个候选数据集，那么我的候选数据集在计算时间上是否来得及，这个还要请教下我们组的同事，我们在商讨下，对于现在这个框架：是做几个融合模型产生候选推荐集？还是对此暂时维持这一版，进行训练特征的优化及其检验分析，模型的调节，还望大家一起拍砖和拍脑袋啊。