【美团 技术篇】美团推荐算法实践

一、前言

推荐系统并非新鲜的事物，在好久以前就存在，可是推荐系统真正进入人们的视野，而且做为一个重要的模块存在于各个互联网公司，仍是近几年的事情。

随着互联网的深刻发展，愈来愈多的信息在互联网上传播，产生了严重的信息过载。若是不采用必定的手段，用户很难从如此多的信息流中找到对本身有价值的信息。

解决信息过载有几种手段：

• 一种是搜索，当用户有了明确的信息需求意图后，将意图转换为几个简短的词或者短语的组合（即query），而后将这些词或短语组合提交到相应的搜索引擎，再由搜索引擎在海量的信息库中检索出与query相关的信息返回给用户；

• 另一种是推荐，不少时候用户的意图并非很明确，或者很难用清晰的语义表达，有时甚至连用户本身都不清楚本身的需求，这种状况下搜索就显得捉襟见肘了。尤为是近些年来，随着电子商务的兴起，用户并不是必定是带着明确的购买意图去浏览，不少时候是去“逛”的，这种情景下解决信息过载，理解用户意图，为用户推送个性化的结果，推荐系统即是一种比较好的选择。

美团做为国内发展较快的o2o网站，有着大量的用户和丰富的用户行为，这些为推荐系统的应用和优化提供了不可或缺的条件，接下来介绍咱们在推荐系统的构建和优化过程当中的一些作法，与你们共享。

二、框架

从框架的角度看，推荐系统基本能够分为数据层、触发层、融合过滤层和排序层。

数据层包括数据生成和数据存储，主要是利用各类数据处理工具对原始日志进行清洗，处理成格式化的数据，落地到不一样类型的存储系统中，供下游的算法和模型使用。

候选集触发层主要是从用户的历史行为、实时行为、地理位置等角度利用各类触发策略产生推荐的候选集。

候选集融合和过滤层有两个功能，一是对出发层产生的不一样候选集进行融合，提升推荐策略的覆盖度和精度；另外还要承担必定的过滤职责，从产品、运营的角度肯定一些人工规则，过滤掉不符合条件的item。排序层主要是利用机器学习的模型对触发层筛选出来的候选集进行重排序。

同时，对与候选集触发和重排序两层而言，为了效果迭代是须要频繁修改的两层，所以须要支持ABtest[1]。为了支持高效率的迭代，咱们对候选集触发和重排序两层进行了解耦，这两层的结果是正交的，所以能够分别进行对比试验，不会相互影响。同时在每一层的内部，咱们会根据用户将流量划分为多份，支持多个策略同时在线对比。

备注：

① ABtest 概念：

A/B测试是一种新兴的网页优化方法，能够用于增长转化率注册率等网页指标。AB测试本质上是个分离式组间实验，之前进行AB测试的技术成本和资源成本相对较高，但如今一系列专业的可视化实验工具的出现，AB测试已愈来愈成为网站优化经常使用的方法。

使用A/B 测试首先须要创建一个测试页面（variation page），这个页面可能在标题字体，背景颜色，措辞等方面与原有页面（control page）有所不一样，而后将这两个页面以随机的方式同时推送给全部浏览用户。接下来分别统计两个页面的用户转化率，便可清晰的了解到两种设计的优劣。

传统的A/B测试，是一种把各组变量随机分配到特定的单变量处理水平，把一个或多个测试组的表现与控制组相比较，进行测试的方式。

新的A / B测试，不只仅其范围限制在web分析方面，而是为其注入新生命，即移动设备端分析。Pathmapp联合创始人兼首席执行官亚当Ceresko表示，今天，开发人员须要大大提升优化工具的性能，移动分析已成为A/B测试增加最快的一个领域。

三、数据应用

数据乃算法、模型之本。美团做为一个交易平台，同时具备快速增加的用户量，所以产生了海量丰富的用户行为数据。固然，不一样类型的数据的价值和反映的用户意图的强弱也有所不一样。

行为类别	行为详情
主动行为数据	搜索、筛选、点击、收藏、下单、支付、评分
UGC	文本评价、上传图片
负反馈数据	左滑删除、取消收藏、取消订单、退款、负评、低评
用户画像	用户人口属性、美团DNA、品类偏好、消费水平、工做地与居住地

• 用户主动行为数据记录了用户在美团平台上不一样的环节的各类行为，这些行为一方面用于候选集触发算法（在下一部分介绍）中的离线计算（主要是浏览、下单），另一方面，这些行为表明的意图的强弱不一样，所以在训练重排序模型时能够针对不一样的行为设定不一样的回归目标值，以更细地刻画用户的行为强弱程度。此外，用户对deal的这些行为还能够做为重排序模型的交叉特征，用于模型的离线训练和在线预测。

  
  

• 负反馈数据反映了当前的结果可能在某些方面不能知足用户的需求，所以在后续的候选集触发过程当中须要考虑对特定的因素进行过滤或者降权，下降负面因素再次出现的概率，提升用户体验；同时在重排序的模型训练中，负反馈数据能够做为不可多得的负例参与模型训练，这些负例要比那些展现后未点击、未下单的样本显著的多。

  
  

• 用户画像是刻画用户属性的基础数据，其中有些是直接获取的原始数据，有些是通过挖掘的二次加工数据，这些属性一方面能够用于候选集触发过程当中对deal进行加权或降权，另一方面能够做为重排序模型中的用户维度特征。

  
  

• 经过对UGC数据的挖掘能够提取出一些关键词，而后使用这些关键词给deal打标签，用于deal的个性化展现。

四、策略触发

上文中咱们提到了数据的重要性，可是数据的落脚点仍是算法和模型。单纯的数据只是一些字节的堆积，咱们必须经过对数据的清洗去除数据中的噪声，而后经过算法和模型学习其中的规律，才能将数据的价值最大化。在本节中，将介绍推荐候选集触发过程当中用到的相关算法。

一、协同过滤

提到推荐，就不得不说协同过滤，它几乎在每个推荐系统中都会用到。基本的算法很是简单，可是要得到更好的效果，每每须要根据具体的业务作一些差别化的处理。

●清除做弊、刷单、代购等噪声数据。这些数据的存在会严重影响算法的效果，所以要在第一步的数据清洗中就将这些数据剔除。

●合理选取训练数据。选取的训练数据的时间窗口不宜过长，固然也不能太短。具体的窗口期数值须要通过屡次的实验来肯定。同时能够考虑引入时间衰减，由于近期的用户行为更能反映用户接下来的行为动做。

●user-based与item-based相结合。

	群体/个体	计算代价	适用场景	冷启动	可解释性	实时性
user-based	更依赖于当前用户相近的用户群体的社会化行为	适用于用户数较少的场合	时效性强，用户个性化兴趣不太显著的场合	新加入的物品能很快进入推荐列表	弱	用户新的行为不必定致使推荐结果的变化
item-based	更侧重用户自身的个体行为	适用于物品数较少的场合	长尾物品丰富，用户个性化需求强烈的场合	新加入的用户能很快获得推荐	强	用户新的行为必定致使推荐结果的变化

尝试不一样的类似度计算方法。在实践中，咱们采用了一种称做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都不发生的次数

	Event A	Everything but A
Event B	A and B together (k_11)	B, but not A (k_12)
Everything but B	A without B (k_21)	Neither A nor B (k_22)

则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为几个元素组成的系统的香农熵)

二、location-based

对于移动设备而言，与PC端最大的区别之一是移动设备的位置是常常发生变化的。不一样的地理位置反映了不一样的用户场景，在具体的业务中能够充分利用用户所处的地理位置。在推荐的候选集触发中，咱们也会根据用户的实时地理位置、工做地、居住地等地理位置触发相应的策略。

●根据用户的历史消费、历史浏览等，挖掘出某一粒度的区域（好比商圈）内的区域消费热单和区域购买热单

区域消费热单

区域购买热单

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

●此外，还能够根据用户出现的地理位置，采用协同过滤的方式计算用户的类似度。

三、query-based

搜索是一种强用户意图，比较明确的反应了用户的意愿，可是在不少状况下，由于各类各样的缘由，没有造成最终的转换。尽管如此，咱们认为，这种情景仍是表明了必定的用户意愿，能够加以利用。具体作法以下：

●对用户过去一段时间的搜索无转换行为进行挖掘，计算每个用户对不一样query的权重。

●计算每一个query下不一样deal的权重。

●当用户再次请求时，根据用户对不一样query的权重及query下不一样deal的权重进行加权，取出权重最大的TopN进行推荐。

四、graph-based

对于协同过滤而言，user之间或者deal之间的图距离是两跳，对于更远距离的关系则不能考虑在内。而图算法能够打破这一限制，将user与deal的关系视做一个二部图，相互间的关系能够在图上传播。Simrank[2]是一种衡量对等实体类似度的图算法。它的基本思想是，若是两个实体与另外的类似实体有相关关系，那它们也是类似的，即类似性是能够传播的。

●Let s(A,B) denote the similarity between persons A and B, for A != B

Let s(c,d) denote the similarity between items c and d, for c != d

O(A),O(B): the set of out-neighbors for node A or node B
I(c),I(d): the set of in-neighbors for node c or node d

●simrank的计算（采用矩阵迭代的方式）

●计算得出类似度矩阵后，能够相似协同过滤用于线上推荐。

五、实时用户行为

目前咱们的业务会产生包括搜索、筛选、收藏、浏览、下单等丰富的用户行为，这些是咱们进行效果优化的重要基础。咱们固然但愿每个用户行为流都能到达转化的环节，可是事实上远非这样。

当用户产生了下单行为上游的某些行为时，会有至关一部分由于各类缘由使行为流没有造成转化。可是，用户的这些上游行为对咱们而言是很是重要的先验知识。不少状况下，用户当时没有转化并不表明用户对当前的item不感兴趣。当用户再次到达咱们的推荐展位时，咱们根据用户以前产生的先验行为理解并识别用户的真正意图，将符合用户意图的相关deal再次展示给用户，引导用户沿着行为流向下游行进，最终达到下单这个终极目标。

目前引入的实时用户行为包括：实时浏览、实时收藏。

六、替补策略

虽然咱们有一系列基于用户历史行为的候选集触发算法，但对于部分新用户或者历史行为不太丰富的用户，上述算法触发的候选集过小，所以须要使用一些替补策略进行填充。

●热销单：在必定时间内销量最多的item，能够考虑时间衰减的影响等。

●好评单：用户产生的评价中，评分较高的item。

●城市单：知足基本的限定条件，在用户的请求城市内的。

五、子策略融合

为告终合不一样触发算法的优势，同时提升候选集的多样性和覆盖率，须要将不一样的触发算法融合在一块儿。常见的融合的方法有如下几种[3]：

一、加权型：最简单的融合方法就是根据经验值对不一样算法赋给不一样的权重，对各个算法产生的候选集按照给定的权重进行加权，而后再按照权重排序。

二、分级型：优先采用效果好的算法，当产生的候选集大小不足以知足目标值时，再使用效果次好的算法，依此类推。

三、调制型：不一样的算法按照不一样的比例产生必定量的候选集，而后叠加产生最终总的候选集。

四、过滤型：当前的算法对前一级算法产生的候选集进行过滤，依此类推，候选集被逐级过滤，最终产生一个小而精的候选集合。

目前咱们使用的方法集成了调制和分级两种融合方法，不一样的算法根据历史效果表现给定不一样的候选集构成比例，同时优先采用效果好的算法触发，若是候选集不够大，再采用效果次之的算法触发，依此类推。

六、候选集重排序

如上所述，对于不一样算法触发出来的候选集，只是根据算法的历史效果决定算法产生的item的位置显得有些简单粗暴，同时，在每一个算法的内部，不一样item的顺序也只是简单的由一个或者几个因素决定，这些排序的方法只能用于第一步的初选过程，最终的排序结果须要借助机器学习的方法，使用相关的排序模型，综合多方面的因素来肯定。

一、模型

非线性模型能较好的捕捉特征中的非线性关系，但训练和预测的代价相对线性模型要高一些，这也致使了非线性模型的更新周期相对要长。反之，线性模型对特征的处理要求比较高，须要凭借领域知识和经验人工对特征作一些先期处理，但由于线性模型简单，在训练和预测时效率较高。所以在更新周期上也能够作的更短，还能够结合业务作一些在线学习的尝试。在咱们的实践中，非线性模型和线性模型都有应用。

●非线性模型

目前咱们主要采用了非线性的树模型Additive Groves[4]（简称AG），相对于线性模型，非线性模型能够更好的处理特征中的非线性关系，没必要像线性模型那样在特征处理和特征组合上花费比较大的精力。AG是一个加性模型，由不少个Grove组成，不一样的Grove之间进行bagging得出最后的预测结果，由此能够减少过拟合的影响。

每个Grove有多棵树组成，在训练时每棵树的拟合目标为真实值与其余树预测结果之和之间的残差。当达到给定数目的树时，从新训练的树会逐棵替代之前的树。通过屡次迭代后，达到收敛。

●线性模型

目前应用比较多的线性模型非Logistic Regression莫属了。为了能实时捕捉数据分布的变化，咱们引入了online learning，接入实时数据流，使用google提出的FTRL[5]方法对模型进行在线更新。

主要的步骤以下：

●在线写特征向量到HBase

●Storm解析实时点击和下单日志流，改写HBase中对应特征向量的label

●经过FTRL更新模型权重