推荐算法评测心得

   ◆版权声明：本文出自胖喵~的博客，转载必须注明出处。

    转载请注明出处：http://www.javashuo.com/article/p-qcrnswee-co.html 

 

 

作推荐算法的质量工做将近一年，这一年尝试了不少东西，踩了很多坑，也对推荐的评测工做稍微有了些本身的心得，如今分享出来，但愿能和作这块工做的同窗一块儿交流、探讨，也欢迎多拍砖，多提意见。

 

推荐系统

目前推荐技术的应用已经很是较普及了，新闻、商品、问答、音乐，几乎都会用到推荐算法来为你呈现内容。下面是淘宝、知乎、微博三个app的推荐模型，能够看到推荐都在很是重要的位置。

 

 

在介绍推荐算法评测以前，我先简单说下推荐系统，这里我以商品为例，简单描述下推流程，让你们更明白一些，通常推荐主要包含如下步骤：

召回->打分排序->透出

召回

召回阶段一般的手段是协同过滤比较场景的i2i,u2i等这种x2x（有兴趣能够看下我写的基于itembase的推荐），也有使用embedding的方式经过向量之间的距离进行召回。以i2i为例，假如如今要针对我推荐一个商品，那么首先要找到我感兴趣的物品 ，这些数据是经过个人历史行为来进行获取，好比拿到我最近一段时间内的点击、加购、收藏、购买的物品，将这些商品作为trigger进行召回，协同算法的具体就再也不这里叙述了，有兴趣能够看下连接，最终咱们按照协同过滤算法算出商品之间的类似分值，而后按照必定数量进行截断，由于这里截断也是依靠分数来进行的，因此通常这一步也称粗排。这样召回截断就完成了。

打分

召回完商品后，咱们须要对这些商品进行再一次的精排，这里须要用模型来预估ctr，通常状况下LR、GBDT、FM用的比较多，这里深度网络相对用的少，主要为了考虑到性能，尤为是rt，由于绝大部分的精排都是须要实时预测的，全部对耗时有必定的要求。继续说下模型预测的步骤，首先针对召回的商品进行特征的补充，例如该商品的一级类目、叶子类目（一级类目表明比较，叶子类目表明最细分的类目）、被多少用户购买等，而后再加入人的特征，例如性别、年龄、收入、对类目的偏好等，而后将这些信息作为feature，用模型进行预测，而后根据模型预测的结果进行排序，输出。

模型

打分过程当中的模型是须要提早训练和部署，训练集的来源就是用户的实时行为加上用户和商品的特征。feature的构成是用户的特征和商品的特征，label则是用户是否点击了该商品。

 

质量方案

接下来讲下如何保证这块的质量。因为推荐系统最终对用户须要提供实时的服务化，所以免不了有工程端的技术须要一块儿配合。所以我这块主要分为两个维度来开展，一方面是工程端的质量保证，一方面是算法侧的质量保证。

工程端质量

这一块能够将算法当成一个黑盒子，只把他当成一个有结果返回的接口。针对这方面前人已经有了丰富的经验，咱们能够作接口的单元测试和冒烟测试，另外就是压测，在预估的qps下看rt是否知足业务方的要求，load是否过大，超时和错误的比例是否符合必定的预期。这里就不细说了，重点说说第二部分。

算法端质量

这里我再进行细分一下，分为三部分介绍：算法数据、算法模型、算法效果；

算法数据：

你们都知道算法在作训练前数据的处理部分很是的重要，有兴趣能够看下特征工程相关的内容，数据的来源，特征的构造，数据抽取、加工整个的过程都有可能会出现错误，并且数据通常都是存储在分布式系统数据库里，所以须要借助相似hive这样的工具将sql转换成MapReduce的任务去进行离线的计算，离线任务的产出一般会耗费很多的时间，而对于一些日更新的模型经过对数据对产出时间有必定的要求。所以数据这块最主要的保证点为：数据自己的质量，和数据的产出时间。数据自己的质量通常能够经过数据大小的总体抖动，以及关键字段是否为空，主键是否重复，作法比较简单能够经过简单sql或者udf来完成，而后借助工程能力作到预警、检查、出报表等。

算法模型：

模型的自己在迭代过程当中也是须要关注的，不过一般算法同窗的训练优化也是参考这些指标，因此咱们也能够把这几个指标作为模型自己好坏的评估。具体为：准确率、召回率、AUC。

算法效果：

那么这个算法推荐出的效果究竟好很差呢，这个是一个很是主观的事情，每一个人的感觉也不是同样的，可是咱们仍然要衡量它的好坏，这里我参考业内学者的推荐书籍以及本身的一些摸索，总结出下面一些方法，供你们参考。

人工评测：

顾名思义，邀请一帮人来对你的推荐系统的结果进行评测。这里想法来自于我在作翻译评测时期的经验，首先这个成本比较高，另外就是参杂了人的主观性很是的高，翻译的好坏咱们能够经过制定一些细致的规则来进行约束，可是推荐的好坏咱们却很差制定详细的规则，另外就是推荐以前的用户行为如何模拟，如何让评测者进行感知，这些都是比较难的，而且和基准的对比也不是很好作，因此这里不是很推荐用这个方法，可是仍是要提一下。

指标评估：

指标化推荐结果，也就是将推荐的结果用不一样的指标来进行说明，经过这些指标，你能够更加的了解你的推荐系统，部分指标不必定越高越好，可是你须要让它保持在必定的范围内。说到具体的例子的时候，我会提一下。下面咱们看下这些指标。

覆盖率

定义：

推荐系统可以推荐出来的“商品/类目”占“总商品/类目”集合的比例。假设系统的用户集合为U，推荐系统给每一个用户推荐一个长度为N的物品列表R(u) ，总物品为N。那么：

覆盖率 =  $\frac{\Sigma R(u)}{N}$

意义：

描述推荐结系统对物品长尾发掘能力；

举个例子，淘宝上商品千千万万，推荐系统可否保证让新的一些商品有足够的机会曝光出去呢？仍是有些商品永远都没法获得推荐曝光的机会。这个指标反应的就是这个状况，显然物品的覆盖率是达不到100%的，可是咱们能够看类目的覆盖率来进行衡量，假设全网全部的一级大类目一共2千个（和全网上亿的物品相比很是的少），那么推荐系统一天以内推荐出去的商品对应的一级类目，这个就是咱们要衡量的标准。若是覆盖率达不到100%，那么确定是有问题的。

基尼系数

覆盖率反应出的分布状况是比较有限的，咱们只能知道哪些类目覆盖了，哪些没有覆盖，那类目之间究竟哪一个类目占的多，哪一个类目占的少呢？为了更细致地描述推荐系统发掘长尾的能力，咱们须要统计推荐列表中不一样类目出现次数的分布，引入基尼系数来评价。

基尼系数：按照类目的流行度（曝光次数）从大到小排序后进行统计后进行洛伦茨曲线的绘制。

作法： 以类目分布基尼系数为例，算出全部的类目被曝光的次数，须要以天周期为单位进行数据的统计。

 

这里须要说明一下，基尼系数越大表明全部类目的分布越不均匀，系数越小表明类目分布越均匀。咱们知道，每一个电商网站都有其侧重的类目，所以绝对平均不是一件好事，头部的类目占比稍多一些可是不能太离谱，举个例子100个类目，前5个占比到30～40%是相对比较好的。固然绝对的只看这个数据意义也不是很大，更多的是长期对这个指标进行监控，看是否会发生大的变更。

打散度

定义：描述推荐结果中结果数据的分散程度。

打散度 =  $\frac{2}{k(k-1)} \sum\limits_{i\neq j}^{k} 0.85^{dis((i,j)-1) * sim(i,j)}  $ (dis(i,j) = |i-j|,sim(i,j) 为 i==j?1!0)

这里须要解释一下，这里首先是对两两物品（不一样的位置）计算为打散度后，得出总体的打散度。类似函数sim表明两两是否相同，相同则为1，不类似则为0。关于两个内容之间距离对打散度的影响，不能是线性的关系，由于随着两个商品出现的位置愈来愈大，用户对重复商品的感觉会逐渐的减弱（很近的位置就有两个类似的内容以为会有些重复，可是若是比较远的位置有两个类似的通常是能够接受的），通常双列流屏幕出现内容大概是4个，0.85^(5-1) 大概在 0.5左右，因此若是是5之内，则打散度会很低，可是若是>5了，打散度就不会衰减的比较厉害了。 类似的两个物品越靠近，权重越大。

更新率

定义：描述推荐系统不断迭代过程当中推荐结果变化程度的指标。

更新率 = 1 - $\frac{S_{昨日}  ∩  S_{昨日}}{S_{昨日}  ∪  S_{昨日}}$

上面公式仍是以类目为例，$S_{昨日}$表明昨天一天出现的全部商品所在的类目的个数，而后两天的交集除以并集，计算得出推荐出商品所属类目的更新率。

发现性

定义：推荐系统对用户未产生过关系的商品的发现能力。

在全网商品中，可能有一些比较好的商品，可是用户历来都没有点击过相似的物品，这时候推荐系统推荐给用户的时候，用户颇有可能会眼前一亮，满满惊喜。

发现性 = $\frac{1}{n} \sum\limits_{i=1}^{n}  \frac{ S_{今日点击（前一周未点击）}  }{  S_{前一周点击}}$  

一样以类目为例，今天我点击了一个我感兴趣的商品，而这个商品的相似偏偏是我前一周都没有点击过过的内容，这就说明推荐系统的为我推荐了一个我以前都没有关注过而且我感兴趣的内容，也就是系统的发现性，在算出每一个人的值以后，再进行求平均计算。

上新率

定义： 新内容被推荐系统推荐的曝光状况，这里能够从两个维度产出这项指标。

上新率1 = $\frac{当日曝光的内容中内容为最近一周生产的内容数}{当日曝光内容数} $

上新率2 = $\frac{当日曝光的内容中内容为最近一周生产的内容数}{最近一周生产的内容数} $

意义：对于一些社区类产品UGC内容的推荐，用户生产的优质是整个社区最重要的一部分，及时的曝光用户的新内容对于增长用户留存和给社区增添活力都有很大的帮助，所以须要这两个指标来评估推荐算法对于新内容的推荐能力。

NDCG

有些文章中也推荐使用这个指标，可是我的以为这个更加适合评价搜索结果，以前写过一篇关于NDCG的文章，有兴趣能够看下。

失效率

定义： 表示系统没有推荐或推荐后未被用户点击数据占全集的比例。

失效率 = $\frac{S(0)}{S} $

S(0) 表示实际点击次数为 0 的数据个数；S表示推荐集合的总数。

首先须要定义一个时间范围来计算没有被推荐出的。其含义为最终未被用户真正感知的数据的占比，未感知包含未推荐和推荐出去后未被点击的内容。

健壮性

定义：算法健壮性的评测主要利用模拟攻击。首先，给定一个数据集和一个算法，能够用这个算法给这个数据集中的用户生成推荐列表。而后，用经常使用的攻击方法向数据集中注入噪声数据，而后利用算法在注入噪声后的数据集上再次给用户生成推荐列表。最后，经过比较攻击先后推荐列表的类似度评测算法的健壮性。

总结：适合在离线环境进行完成，针对模型自己的评测。

除了上面介绍的经过这些指标的方法来进行评估，当推荐真正运用在业务上，经过业务侧的一些数据反馈也能够知道推荐算法的好坏。具体看下面两项：

负反馈

定义：负反馈至关于一个轻量级便携的用户反馈，用户能够直接对推荐出的内容给与反馈，推荐系统在拿到了用户实时反馈后就会马上针对反馈信息对推荐结果作出相应的调整，而咱们也能够在过后拿到负反馈的总体数据来评价推荐系统在用户侧是否有重大舆情产生。通常app的推荐都会有负反馈机制，如图：

ctr

Click-Througt-Rate，即点击率，点击数/曝光数。推荐算法效果的最最重要指标，没有之一。通常算法好很差，都会直接用这个指标直接定义。一般算法模型在迭代的过程当中都会进行ab test，所谓ab test就是有一个基准桶，一个对比桶，经过收集两个不一样方案在用户侧的点击率，来评估算法的好坏，通常来讲当流量特别大的时候，基本上一个ab实验上线几分钟就能够出算法的好坏了。固然算法的分桶不只限只有两个桶，像下面这个推荐每一个分桶的数据均可以很是直观的展现出来。通常须要借助像Blink这样的实时计算能力来实时的显示点击率数据。

 

ctr

Conversation Rate，即转化率，转化数/点击数。一般在广告上用的比较多，对于商品来讲也就是用户最终点击而且购买的转化率。由于最终决定转化的因素仍是比较多的，不仅仅是推荐算法影响的，因此这个指标一般不作为模型迭代优化的衡量标准，可是因为其和最终的"钱"挂钩，因此通常领导会更加关注这个指标。

 

 

总结

上面说了不少指标，其实单看指标可能没有特别好的体感，更多的时候，咱们须要真正的将这些内容结合到业务上去，看它究竟反应业务什么样的状况，抽丝剥茧，更加的理解业务、反哺业务，任何一个指标都须要对业务有指导意义，真正帮助业务提高。最后，我将总体的质量方案也画了一个概要图，能够参考看看。