样本负采样为什么不影响AUC计算？

gengvvip

已于 2022-12-22 11:15:10 修改

阅读量983

点赞数 1

分类专栏：推荐系统算法工程师文章标签：人工智能

于 2022-12-16 21:24:02 首次发布

本文链接：https://blog.csdn.net/qq_23236081/article/details/128347358

版权

算法工程师同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

推荐系统

2 篇文章 0 订阅

订阅专栏

几个问题：

为什么对正负样本不敏感？

解释一：AUC的定义：随机取一对正负样本，正样本得分大于负样本得分的概率（auc不能衡量正样本内部的排序）。如果采样是随机的，对于给定的正样本，假定得分为s+，那么得分小于s+的负样本比例不会因为采样而改变！如果采样是均匀的，即>s+的负样本和<s+的负样本留下的概率是相同的
解释二：横轴FPR只关注负样本，与正样本无关；纵轴TPR只关注正样本，与负样本无关。所以横纵轴都不受正负样本比例影响，积分当然也不受其影响。

auc指标的特性

相比于准确率、召回率、f1-score等依赖于阈值判定的评估指标，auc则不用设定阈值。AUC常用在搜索和推荐等场景。

换句话说，

AUC指标本身和模型预测score绝对值无关，只关注排序效果，因此特别适合排序业务。AUC 反应了太过笼统的信息。无法反应召回率、精确率等在实际业务中经常关心的指标。

线上线下效果不一致问题？

虽然购买转化率模型的AUC会高于点击率模型，但往往都是点击率模型更容易做，线上效果更好。购买决策比点击决策过程长、成本重，且用户购买决策受很多场外因素影响，比如预算不够、在别的平台找到更便宜的了、知乎上看了评测觉得不好等等原因，这部分信息无法收集到，导致最终样本包含的信息缺少较大，模型的离线AUC与线上业务指标差异变大。

样本数据包含的信息越接近线上，则离线指标与线上指标gap越小。而决策链路越长，信息丢失就越多，则更难做到线下线上一致。

不同业务场景的AUC指标是否差异特别大？

点击率模型的auc要低于购买转化率模型的auc。
以预测点击和预测下单为例，下单通常决策成本比点击高很多，这使得点击行为比下单显得更加随意，也更加难以预测，所以导致点击率模型的AUC通常比下单率模型低很多。
那么月活用户和日活用户那个更容易区分下单与不下单用户呢？显然月活用户要容易一些，因为里面包含很多最近不活跃的用户，所以前者的AUC通常要高一些。
对于预测1小时和预测1天的模型，哪一个更加困难？因为时间越长，用户可能发生的意料之外的事情越多，也越难预测。举个极端的例子，预测用户下一秒中内会干啥，直接预测他会做正在干的事情即可，这个模型的准确率就会很高，但是预测长期会干啥就很困难了。所以对于这两个模型，后者更加困难，所以AUC也越低。

线下AUC有提升，但是线上没有效果？

特征/数据出现穿越：训练集和测试集差异比较大，label强相关的特征导致的数据泄漏
线上线下特征不一致：离在线代码抽取逻辑不一致、数据时间粒度延迟拼接导致不一致；最根本的方法就是同一套代码和数据源抽取特征，业内目前通用的方法就是，在线实时请求打分的时候落地实时特征，训练的时候就没有特征拼接的流程，只需要关联label，生成正负样本即可
数据分布的不一致：线上的预估空间是原始曝光到点击，线下模型训练是有效曝光到点击。
负样本采样：线下因为样本dump能力有限的原因，负样本数会少于线上实际打分的负样本

解决办法之——GAUC：

AUC作为排序的评价指标本身具有一定的局限性，它衡量的是整体样本间的排序能力，对于计算广告领域来说，它衡量的是不同用户对不同广告之间的排序能力，而线上环境往往需要关注同一个用户的不同广告之间的排序能力。线上的排序发生在一个用户的session下，而线下计算全集AUC，即把user1点击的正样本排序高于user2未点击的负样本是没有实际意义的，但线下auc计算的时候考虑了它。

这里的G可以是什么粒度？

用户粒度。比较适合于推荐场景这种单个用户反馈样本比较多的场景，但是广告场景单个用户的样本比较少，计算就不太准确；
session粒度：session就是某一天某一个时间段内，某个用户对网站从打开/进入，到做了大量操作，到最后关闭浏览器的过程就叫做session。这里的session比较类似电商行业里的店铺访问量，一天之内可以有好多商品的反馈
广告位粒度
广告位*广告粒度：之前的AUC计算是一个用户下面所有广告的排序情况；这里是反其道而行之，看一个广告下面的用户排序情况——这点非常牛逼！
我们设计gauc，里面的group不一定就是user，例如搜索广告下query+user也是一个合理的group。事实上，group的定义最好是区分一次排序队列的唯一key，但有时候过于细粒度的group key会导致group里面样本个数太少、无法有效地计算auc，因此这里面有个tradeoff。

这里是否会更合适，需要有更多实验、更多数据来做支撑！

sql参考计算auc的方式

推荐系统评估指标为什么用AUC而不用logloss？

logloss的物理意义：用于衡量算法预估的ctr与实际ctr的拟合程度。

如下损失函数也称为交叉熵损失函数，交叉熵可以衡量同一个随机变量的两个不同概率分布的差异程度，即真实概率分布与预测概率分布之间的差异，可简单地计算（所有样本预估ctr的均值）/（样本中正样本的比例，即真实ctr）偏离1的程度来衡量差异情况（即整体高估，还是整体低估），交叉熵值越小，算法预测的效果就越好。logloss的值越小越好，logloss值越小，表示CTR预估值跟实际值（跟正负样本的分布情况有关）越接近。从如下公式不难看出，预估ctr值的大小跟个样本中正负样本的比例是有关系的，在CTR预估场景中，通常负样本占大多数，而正样本只是少数，如果我们人为地只从负样本中取一部分样本用于训练（例如，采样率为1/2），则预估出来的ctr值将会整体偏大。
原文链接：https://blog.csdn.net/weixin_28567617/article/details/112509747

AUC指标本身和模型预测score绝对值无关，只关注排序效果，因此特别适合排序业务。