网站分析常用的指标之内容指标(推荐系统没有确定性的预期响应维度更高的功能响应)

优采云 发布时间: 2021-11-08 18:12

  网站分析常用的指标之内容指标(推荐系统没有确定性的预期响应维度更高的功能响应)

  当我们刚开始学习推荐系统的时候,希望你想想你为什么要做推荐系统。在逐渐深入的过程中,我开始唠叨推荐系统。

  今天,如果你已经有了自己的推荐系统,这个系统已经上线了,代替了之前的大部分人工,日夜工作,为电商创造销售网站,为信息流创造阅读时间和互动为社交 网站 创建社交关系。

  为什么要关注指标

  可是,这样睡得安心吗?显然你错了。当它成功启动时,也是你失业的时候。有没有这么一天我们暂且不说。即使一切正常,你仍然需要每天将这个系统握在手中,在棘手的用户面前教它如何成长。不仅要注意它学习不好,还要注意它很懒惰。

  总之,养过孩子的人都会明白。面对一个推荐系统,一个有很多复杂因素相互作用、协同作用的系统,你必须时刻知道它的好坏,还需要掌握一些测试方法和测试指标。

  推荐系统测试方法

  在前几篇文章中,我说你需要有不确定性思维,但这绝不是你老板的借口。

  推荐系统也需要测试,但不同于传统的功能测试。在传统软件的功能测试中,功能的响应是可预期的。当您点击一个关注按钮时,产品文档中明确规定了应该做出什么响应;因此,在开发功能时,您可以同步编写测试用例。

  这是非常清楚的。在功能开发过程中,如果有任何改动,只要运行测试用例,逻辑是否正确就一目了然。另一方面,推荐系统就没有那么容易了。如果你什么都不动,两次推荐的结果可能会有所不同,而且很可能是你或者你的老板要求的不同。

  那么应该如何测试推荐系统呢?与其说推荐系统没有确定性的预期响应,不如说推荐系统的响应维度更高。

  因为确定性函数响应就像一个点,所以推荐系统的响应是高维空间中的一个区域,而不是一个点。那么推荐系统不再需要单元测试了吗?显然不是。

  综上所述,推荐系统的测试方法有四种:业务规则扫描、离线模拟测试、在线对比测试、用户访谈。

  1. 业务规则扫描

  首先,业务规则扫描本质上是对传统软件的功能测试。一定的业务规则会对应一定的规则,这些规则可以转化为单元测试,比如运行一个单元测试,一一扫描推荐系统寻找业务规则。

  通常这些业务规则对测试也有“软”和“硬”要求。前者将对违反业务规则的行为提出基线要求。例如触发概率小于万分之一,扫描测试时统计触发次数。只要统计触发概率不超过基线,就认为是合格的。

  硬性规则是一票否决。例如,一些业务黑名单只是高压线。在测试期间不能触摸它们。如果它们被触摸,它们就是虫子。你必须找到纠正它们的方法。

  除了业务规则,还有一些地方很容易被忽视。例如,大多数推荐模型都涉及数学计算,数学计算中也存在一些不可违反的潜在规则。

  例如,除数不能为0。例如,计算机浮点数的精度是有限的。经过一些指数计算,可能会出现意想不到的结果。也可能会有一些连续的乘法计算,以防止出现0乘法,类似于计算中的这些。还需要扫描和测试潜在的业务规则。

  2. 离线模拟测试

  二是离线模拟测试。这是一次军事演习式的测试。当然,模拟测试不能代替真实数据,但也能暴露出一些问题。通常的做法是先采集业务数据,即根据业务场景的特点构造推荐接口的参数供用户访问。

  这些参数要尽量还原到当前场景,然后利用这些参数数据实时访问推荐推荐,生成推荐结果日志,采集这些结果日志,计算评价指标,是离线模拟测试。

  显然,离线模拟测试是一种失真测试,评价指标也有限,无法得到用户真实及时的反馈。但还是有参考意义的。

  这些模拟日志可以统称为曝光日志,可以衡量一些非效果指标,如推荐覆盖率、推荐失败率、推荐多样性等。这些指标的具体含义将在后面讨论。离线模拟测试是不是对效果一无所知,无法模拟?

  也不是真的。一种方式是利用历史真实日志构建用户访问参数,得到带有评价界面的结果日志后,结合相应的真实反馈,可以进行定性评价效果的对比。

  比如可以评估推荐结果的TopK的准确率,或者排名效果AUC。虽然这些模型效果指标并不能代表最终关注的业务指标,但两者之间一般存在一定的相关性。

  一般来说,TopK的准确率高,或者AUC高于0.5的越多,相应的业务指标就越好。这是一个基本假设。通过离线模拟评估模型每天的性能指标,计算出当天的真实业务指标。可以绘制两者之间的散点图,以返回一个简单的模型。线下模型效应用于估算上线后的真实业务指标。.

  3. 在线对比测试

  第三种测试方式是真人实战,也就是ABTest,即在线对比测试,分为流量进行真实评测。这需要一个支持流量正交分段的ABTest框架,在上一篇文章中已经提到过。有了足够的样本,ABTest基本可以判断新推荐系统是否优于旧推荐系统。

  4. 用户访谈

  最后一种测试方法是用户访谈或用户调查。前三种测试方法背后的想法是数据驱动的。

  但是,正如我在本文开头所说的,数据衡量系统的外部性能,并不反映系统的原理。此外,数据指标是由人类设计的。它们是主观的和片面的。人类有不同的认知广度和深度。不同的。

  因此,除了紧紧围绕“数据驱动”的核心思想紧密团结,我们还需要深入用户,最直接地与用户沟通,采访用户。更重要的意义不是评价推荐系统,而是评价推荐系统的指标。设计是否合理,高度是否符合您的预设。

  另外,如果您通过前面三种测试方法知道系统表现不佳,那么结合直接真实的用户调查和访谈,您可以找到系统优化的真正原因。这种方法的比喻是:修理下水道时,需要进入下水道。

  常用指标

  推荐系统有很多指标。如果你之前看过一些介绍推荐系统指标的文献或者书籍,你肯定会被指标之多,总之各种费率望而却步。事实上,所有指标都在回答两个问题:系统有多好,能持续多久?

  这两个问题恰恰反映了推荐系统中一个老难题:探索和利用问题。

  系统有多好?这就是问:数据使用得彻底吗?可以多久?这个问题是问:你能探索用户的新兴趣吗?这样,开采和利用才能继续。这也就像在工作场所看一个人一样。除了看他现在的经验和解决问题的能力,还要看他的学习能力有多强。毕竟世界在变,日出也会变成落日。

  让我谈谈这两种类型的指标。

  1. 系统有多好?

  检测系统有多好,其实有两种,一种是深度型,一种是广度型。

  把数据看成一个矿,推荐系统就是挖掘这个矿的设备。“系统好不好”的问题是关心挖矿好不好,所以实际上要看现有的矿井深不深。到位。广度指数是指在矿井中进行完整的钻探,而不是仅仅盯着一个地方。

  深度指数是看推荐系统在自己的工作中做得如何。还记得推荐系统的工作是什么吗?它是预测用户和物品之间的联系。预测方法包括分数预测和行为预测。

  因此,深度指标是指检测系统能否完成这两项任务。有离线模型指标和在线指标。让我分别谈谈它们。

  1. 评分的准确性。通常是均方根误差RMSE,或其他误差指标,反映预测评分效果的好坏。在谈论协同过滤时,已经详细讨论了该指标。我不会在这里重复。

  2. 排序。检查推荐系统的排名能力是非常重要的,因为将用户喜欢的物品放在首位是推荐系统的天职。

  由于推荐系统的输出是非常个人化的,除了用户自己以外的任何人都很难回答对他来说哪个好哪个不好,所以通常搜索引擎排名指标很少用于评估推荐的排名效果系统,如 MAP、MRR、NDCG。

  搜索引擎评估搜索结果和查询的相关性,具有很强的客观属性,可以被其他人代替进行评估。推荐系统评价排名通常使用AUC。我之前介绍BPR模型的时候也专门讲过。

  3. 分类准确率。这个指标也是针对行为预测的,行为预测是一个分类问题,所以评价准确率自然。

  在推荐系统中,评价精度稍有特殊。一般评估TopK的准确率,与TopK的召回率相对应。这里K与实际推荐系统场景有关,即实际推荐系统每次需要输出几个结果。

  TopK的准确率计算如下:

  如果用户在日志中有两个项目 A 和 B 具有正反馈行为,推荐系统将推出一个长度为 K 的项目列表。 该列表可能收录 A 和 B 两个项目中的一个或多个,如图所示下表解释了TopK准确率和TopK召回率的含义。

  

  这三个指标更直观地反映了数据挖掘在推荐系统“预测”事项中的深度。其实由于机型不同,也可以提供不同的指标,指标也可以自己设计,这里不再赘述。但这三个指标也是比较早的指标,离最终的商业指标还有一定的距离。

  通常测试推荐系统的商业指标是:点击率和转化率。其实从打开你的应用或者网站到完成一次消费,中间有几个步骤,这也是大家常说的漏斗转化的过程。

  如果推荐系统在其中一个链接中工作,则必须测量该链接的转化率。与之前的三个指标相比,这更接近真实的效果。

  除了比例业务指标,还要注意绝对业务指标。常见的有:社交关系数、用户停留时长、GMV(交易价值)、绝对关注数。除了因为是真正的商业目标,还有一个原因就是看推荐系统和其他系统之间是否存在零和博弈。

  如果推荐系统的导流效果提高,搜索引擎导流降低,从整个平台的角度来看,因为整个平台的商业目标没有那么可喜,我们也需要保持警惕。

  说完深度指数,下面我们进入广度指数。

  4. 覆盖率。这个指标是看推荐系统成功挖掘了多少用户,覆盖率又细分为UV覆盖率和PV覆盖率。UV覆盖率计算方法是。

  COVuv =Nuv Nl>c

  解释一下,首先要定义有效推荐,即推荐结果列表的长度保证大于C。独立访问用户的去重是UV。有效推荐覆盖的独立去重用户数除以独立用户数即为UV覆盖率。PV覆盖率的计算方法类似,唯一不同的是计算时没有去掉分子和分母。

  COVpv =Npv∗ Nl>c∗

  5. 失败率。失败率指数衡量推荐未能产生结果的情况。又分为UV故障率和PV故障率。UV故障率计算方法是。

  LOSTuv=NuvNl=0

  分子为推荐结果列表覆盖的独立用户数,长度为0,分母仍为去重后的独立用户数。PV故障率也是一样,不同的是没有去重。

  LOSTpv =Npv∗ Nl=0∗

  6. 新奇。对于用户来说,“老是看你的老脸”让他们审美疲劳,所以对于用户来说,推荐的商品一定要有一定的新鲜感。直观的理解是用户从未见过。

  因此,新颖性需要讲粒度、项目粒度、标签粒度、主题粒度、分类粒度等。评估用户在每个粒度上没有看到的项目的比例。对于item级别的新颖性,更多的是通过直接过滤来保证,这在前面章节中关于相应的过滤算法中已经具体提到过。

  7. 更新率。检查推荐结果的更新程度。如果推荐列表每天几乎都一样,显然是不可取的,尤其是新闻信息,每次都需要不同的刷新,需要更高的更新率。有很多方法可以衡量更新率。一个是衡量推荐列表中不同项目在每个推荐周期中与前一个周期相比的比例。这个循环可以每次或每天刷新。

  UPDATE=NlastΔNdiff

  2. 可以多长时间?

  除了关注系统性能如何之外,您还需要担心另一件事。你的系统能用多久?即系统是否健康。

  在推荐系统中,数据需要不断更新,让系统成为一个有生命的系统,用户兴趣客观上会发生变化,数据源客观上会用完一天,所以如果推荐系统不能应付这两个改变,不会更好。太长。

0 个评论

要回复文章请先登录注册


官方客服QQ群

微信人工客服

QQ人工客服


线