“AUC提升了效果指标下降了”之原因分析

共计 5172 个字符，预计需要花费 13 分钟才能阅读完成。

特征维度

1.架构设计和工程问题导致的特征分布不一致

在线特征大都是服务实时抽取，上下文等由redis等实时读取。而离线复现特征的工程和线上是两套实现，比如线上c++，离线python，可能带来精度问题，更容易因为实现函数的边界值差异，带来特征分布长尾不一致。又或者线上实时上下文，离线redis回溯时间节点的微小差异，ID化词典的动态变化，等等。炼丹师们一次次饱受校验特征，监控，精度等问题困扰

其实就是算法侧数据流和工程serving 端存在着偏差导致的，举个例子，数据流段处理一个特征需要用A方法，然后工程端自己实现一个方法做类似的处理，那么就有极大的概率两者之间会有偏差。解决的方法也有一些，比如统一jar包的使用，数据流端和工程端统一jar包的使用。

合理的特征抽取架构设计可以很好的规避这一点，比如特征类，依赖类都严格实现ToString和反转的方法，日志直接带出精简的ToSring数字，在线离线用同代码编译的特征抽取类等。

2.样本有限导致重要特征分布不一致

样本有限或者机器资源有限导致重要特征分布不一致。早期顺利从FM+FTRL迁移为NN（WDL，DNN）后，在移动端场景，提升显著但是同样模型，同样特征设计，迁移到PC场景时，指标居然为负。后来定位到是用户id特征，在移动端点击用户行为全部抽取特征，即user-id分布线上线下一致。而PC场景受限于机器资源和离线语料join性能，也因为FM时期全语料和50%语料训练模型线上AB无差异，线上只打点了1/4左右用户的语料。而user-id又是模型中的重要特征。PC端移除user-id后，指标也超过了FM的base。

3.特征穿越或者”过拟合”某个特征

1. 穿越都好理解，比如一个实时序列特征，里面的特征处理出现了未来的数据。
2. 这里的“过拟合”不是离线训练train-test-eval能发现的过拟合，而是类似穿越，当前的模型设计存在漏洞，导致模型过渡依赖某个特征，比如在DNN（tf官方和实现两种都尝试）直接加入位置，同时当时的业务场景头部问题又比较严重，位置偏差很大。这时就会发现，加入这类特征离线auc大幅上涨，但是无它的同模型，上一版中的重要特征，权重都很小。这就和把label放到特征列中，其它特征的权重都变成几乎随机，类似的道理。而LR,FM模型，或者YouTube-shallow-tower的设计，模型都可以更好的利用位置/场景/样式等信息，又不过度依赖。不过sigmod之前求和还是之后乘积（PAL），很多业务场景也会上线比base反降，加正则加权CtrLoss或者类似蒸馏的滞后更新，可以缓解一些。

数据维度

1.正负样本比变化

正负比不同的集合，不适合比较AUC。样本集合Ctr低的，AUC大部分情况偏高。反过来采样加强正样本的，AUC自然比之前变低。

又或者单Ctr目标模型的多目标Loss加权，尤其只对正样本加权，变相改变了样本分布，auc也会有明显变化。

2.训练分布不一致

比如用类似ESMM方法建模和Ctr相关子目标时，如果子目标只用点击样本训练，离线在线不一致，上线后未见样本太多，子目标预估分就会很奇怪，指标大概率是陡降的。

模型维度

1.网络结构变化大

什么是网络结构变化大？模型不变只有特征变化时一般不会发生。

但是比如优化位置等bias的，YouTube-shallow-tower，或者PAL，联合Ctr和BiasCtr两个目标迭代，单Ctr侧的Auc和之前只有CtrLoss的base模型，Auc也不可比了。还有模型网络结构发生很大变化时，比如FM，LR模型升级为DNN，WDL，DIEN这些时。测试模型和base旧模型，二者的离线AUC差异很难稳定反应到线上。

这里还有推荐是个循环迭代体系，全链路一些变化的因素，具体分6，7来说明。

2.候选分布不一致

如果是rank，候选为粗排，而粗排候选为召回，离线训练样本，是经过ReRank，用户选择偏差，甚至超时影响后的实际曝光样本。也就是参考1中提的冰山效应，即离线训练用的是有偏的冰山上的数据，而在线上预估的时候，需要预测的是整个冰山的数据，包括大量冰面以下的数据（加粗为原文引用，链接见最后参考1）。

这个问题也可以说是评估指标问题，比如相比AUC，w-auc，或者阿里的GAUC，就要更接近用户能感知到的排序变化. 但是w-auc和指标也不是稳定正相关，因为推荐是个多层级的循环迭代体系。

举个例子，早期部门以移动端浏览器场景为主，后续才陆续接手集团pc浏览器，弹窗等场景。而那时@

样本调优那些事儿

采样和多场景实验才刚刚开始，大部分场景都是用的移动浏览器主模型。初期实验效果如下：

pc自身语料训练模型<移动浏览器采样模型<pc自身语料+采样模型, 10%流量AB总点击约提升3%。

但是放量之后，发现holdback的移动浏览器预估pc场景10%流量，和”pc自身语料+采样模型”放量base的差异越来越大，直到20%。而场景总点击其实提升约7%左右。看到这里是不是很熟悉，某个实验小流量时提升很小，但是逐步放量后提升越来越大，且拉长周期效果也是越来也好。

原因主要有二：

一是移动端模型预估pc端时，最终曝光和移动端分布差异要比用pc语料模型的小很多，而这样带来的曝光偏差，选择偏差，产生的样本又会持续影响上游的比如召回层分布。放量后，不止rank在变，前置的试投，召回，粗排也都被影响，且影响持续放大，导致训练分布和线上rank候选分布差异持续放大。

二是holdback的小流量实验，产生的行为已经不足以更新它的模型了。比如长周期的base模型中有大量id记忆和热门等，但是新的短周期test模型，只能学到最近的id以及现有推荐状态做前置条件时产生的用户行为。用户反馈是有限的，或者说本来数量足够就能拟合的行为，因为现有推荐体系产生很少，对应test模型却成为hard-sample了。这类问题一般发生在模型升级跨度很大，比如FM和树模型，机器学习到深度学习模型。这里抛个小问题，如果你负责的推荐体系，粗排和精排都是长周期半年以上模型，那么粗排不变时候，精排上线短周期可能平了或提升，但是AB几天后正巧粗排也上线短周期模型实验，或发生什么有趣的事呢？

所以近年看推荐业务指标，个人更倾向从全推荐体系变化，各层级分布变化和用户必要交互试错带来的潜力等，这些方面来分析问题。从循环迭代角度做长远考虑。

3.循环迭代偏差

推荐，尤其大流量的重要业务场景，单个新模型的流量往往只能10%，5%，甚至更低。而训练这个模型时，使用的却是100%流量的全语料。我们的业务里场景自身30%流量模型AB效果，会比较稳定，和全量后效果类似(场景真实提升）。其中的原因这里我们简化解释下，如图，能抽出featureK的上下文交互，5%流量上A模型rank排出的x，点击概率只有0.1，模型推出了1w次。而全局能抽出featureK的交互行为，总体也推出了1w次，点击概率0.8. 这样就产生了2w个，点击率在0.1~0.8之间的样本。A模型用全语料训练，并不能快速修正错误。在<推荐，用户，数据>的循环链路中，缺失了足够的用户反馈。

再举个例子：

新场景C，大概一千万跳转点击（导出）的场景，根据场景特性补充了一些类似连续点击概率等特征，但是AB只有1.5%的提升，valid-loss方式后AB+2.3%。还有另一个公平性扰动实验，初始AB持平，valid-loss后+2.01%。

valid-loss是我们对生效流量样本加权的简称。上面提到样本数不足带来的“伪hard-sample”，或者hard-sample问题本身，最简单的无非上采样或者FocalLoss调权，而valid-Loss很简单，即AB模型生效的“自身流量”会加大权重，一般缩放到相当于采样到全流量30%（即10%，weight=3.0），而超过30%（经验值）后可以只用自身样本。

也可以FocalLoss或者上采样那些分析后的badcase样本，或者类似蒸馏，新模型的训练先用base的预估分作为label，迭代稳定后再逐步加权label权重。但是不太推荐用base-rank后，test模型再头部rerank，很多业务可能算力不够，且系统复杂，后续迭代像多个强化实验全量一样，后继乏力。

除了样本采样（加权），增加排序时真实候选，建模曝光几率也是一种不错的方法。整体思路也是通过这些方法让离线训练分布和在线预估时接近。

这里面还可以引申个问题，推荐这类交互循环体系，流量上对探测的分配。

比如用户点击反馈行为，如果无硬性策略或者强化探测，在一些不成熟的新生场景，可能受样本行为的不充分和新增某个作者“流量密码”导致热门数据点击率优势极大，造成模型自我迭代逐步弱化反馈。长此以往，整个体系锁死在某个局部解，即使垂类，长尾内容后续发力，尤其长周期模型的历史流行偏差极大，这个体系也要很久才能钮转，甚至期间大部分探测实验都会是负收益。系统被流行性偏差，选择偏差，低俗抖机灵内容带入死锁。

或者多目标排序偏差，尤其非用户兴趣行为目标（比如商业化），带来指标持续阴跌（场景10%以上而AB一直只差2%）。需要推荐业务的守护者们，做好去噪，探测，Debias和流控。就好像参考1中提到的两个组A提升后B组流量也会慢慢涨，反过来呢？危害也一样的。AB-2%，场景却跌10%，AB+6.5%（长尾推荐增强，“伪长尾”强化为真热门），场景+15%，都有发生。好的AB设计决定了业务的稳定性。

4.长周期差异

受限于深度模型训练耗时，在我们业务，实验模型往往最长也就五周（35天）样本训练上线，而离线auc比较初始阶段只用一周。

首先离线拟合就有问题，尤其多目标模型，可能一些稀疏目标Loss要比月级别还差很多。

其次多目标的Loss计算时，如果权重和没有调整，还可能陷入Loss陷阱。其实变相加大学习率，在短周期上带来离线指标虚高。

最后深度学习也好，机器学习也好，在我们的业务最终验证，即使模型和特征不变，长周期模型也会稳定带来2%以上收益。但是在FM+FTRL模型初期，长周期并不能带来稳定收益，后来我思考可能和团队那时频繁新增特征，调整离散化等，而特征又不好回溯（参考问题1），以及有小伙伴在推优质数据等业务，长周期上数据分布不连续，引导的用户行为前后有很大差异。甚至画像和NLP迭代等，所以在团队业务高速发展时期，”长周期比短周期指标好“未必适用。但是稳定期，在算力瓶颈之前，长周期大概率值得一试。

5.线下指标

1. 训练集与测试集是否存在重叠部分，此时对测试集的评估结果是不置信的；
2. 训练集中的特征是否存在穿越现象，特别是与label强相关的统计类和行为序列特征出现穿越，离线训练auc能夸张到0.99，相当于开了个上帝视角
3. 训练集是否出现了过拟合，这在添加强特征或者模型升级带来较大离线指标提升情况下需要格外注意，这个时候base模型的学习率、epoch个数和正则系数等超参已并不适合实验模型的训练，需要在确保没过拟合的情况下，离线试验出一组较优参数。

工程维度

1. 算力问题（加工累计偏差）

之前项目遇到过，AB两个模型实验，rank服务超时比例都不高，千分位，但是平均耗时，A比B多20ms，指标低0.5%。这里有个工业界经典问题，就是加工累计偏差。单独模块耗时偏差控制在范围内，但是实际全链路耗时早已经在临界线，最终超时。工作早期时我的一个项目就需要额外比base多30ms，但是当时多模块耦合在一套服务，项目没成，后来回想或许这才是我当时做优化的最大瓶颈。比如多目标复杂模型，比如复杂的特征，如有必要（自信），要说服耗时整体（层层）增加，你可能会发现AB-Test开始提升了。所以往往最后才发现，工业上算力才是业务最大的瓶颈之一。

其他问题

1、 流量抢夺，链路纠缠

典型的比如在营销场景，你在前面的PUSH，短信，固定入口广告做优化，把好转化的用户都转化了。那么下游的IVR电销，人工电销一定就变难了。

这时候你离线用历史数据训练的模型可能离线指标提升了，线上也不会有太多的效果。

这种在一些瀑布流程的场景中更为常见，一定要关注实验的上下游变化，比较经典的方法是做MVP机制，一直维持着最优流量的AB测。这样相对提升是可以把握住的。即使小模块指标变得难看了也没关系，可能大盘整体还是变好的。

2、特殊时间点的漂移

双十一大促，过年放假，这些时间点一定要注意。最好跟往年同时间的复刻对比，谨慎实验。因为这时候的幺蛾子特别多，尤其是在一些时间序列的预测任务上，基本上都跑飞了。所以成熟的算法工程师从不让自己利于危墙之下。

参考
https://www.zhihu.com/question/517418281/answer/2355367968