AUC离线和在线表现不一致问题：两个维度

AUC系列

以往分享的AUC系列中，介绍了离线评估使用AUC对比其它指标的优势，AUC的定义，AUC的计算，AUC的特点，本文分享算法工程师在实际业务中经常遇到的问题，即离线AUC涨而线上不涨，主要讨论导致该问题的原因以及如何分析。

在推荐领域，业界基本使用AUC作为分类模型的离线评估指标。相比于其它指标，AUC有明显的优势，它不依赖于阈值的选取，其值代表了对item的排序能力，它的排序性和推荐领域中大多数业务场景贴合，即关心item之间的相对序而非绝对值。

算法工程师在日常迭代工作中，最主要的离线参考指标是AUC，但也经常遇到离线AUC涨而线上不涨反跌的情况，没有遇到过这种情况的算法工程师，大概就是天赋异禀且一直幸运。

这个问题如此常见，和推荐系统的复杂性密切相关，模型从训练到上线的链路涉及非常多的模块和细节，任何一个细节都可能导致这个问题，原因很多，也有很多资料对这个问题有分析，但基本是罗列自己在实践过程中的经验，缺乏系统性地从问题本身涉及的方面出发进行分析和总结。推荐和日常遇到的事情非常像，想搞清楚原因，需要从事情本身出发，先搞清楚事情涉及的不同方面，再从这些方面去找问题。

AUC离在线表现不一致，不仅涉及离线和在线这一个维度的变量，但还包括当前模型和基线模型这一维度的变量，指标的上涨和下跌，是当前模型基于基线模型对比得到的。所以这个问题背后的原因，可以从这两个维度的所涉及的变量进行分析。

对同一个模型而言，当离线评估和在线评估的条件一致时，离线的情况可以代表在线的效果，则不会出现模型AUC离线和在线表现不一致的问题。而在实际推荐系统运行的环境下，离线和在线条件几乎不可能保持一致。

离线和在线的差异主要由两方面带来：

(1) 推荐系统的工程实现带来的差异，包括模型训练和上线的框架设计、工程实现方面的问题，可以通过优化模型训练和上线的工程框架，确保代码的正确性来解决，一个实际问题中常遇到的问题是，工程实现问题往往定位比较困难，生产bug很容易，但发现bug很费时费力；

(2) 推荐系统中模型离线训练和线上推理的本身特点导致的差异，属于机制导致的差异，实际不可避免。

推荐系统是一个相对完整的闭环，如图1所示，从用户来到某个推荐场景开始，触发一次后台请求后，推荐内容呈现给用户，用户产生多种行为，这些行为被日志系统回收，经过一系列处理得到模型需要的样本，模型利用新样本不断更新，通过模型服务生成推荐结果，经过后台服务呈现给用户。整个推荐系统的框架庞大，其中任何一个环节在离线和在线有差异，都可能导致离线和在线AUC表现不一致问题。

工程性差异通常由2方面带来：(1) 工程实现的bug，推荐系统的工程实现复杂，需要多个团队合作，整个过程涉及的链路环节多，很容易出现bug，且不容易被察觉；(2) 模型训练和上线的工程框架，当整个流程的底层框架不完善时，容易在样本生成、离在线特征处理、模型更新上线等过程产生离线和在线的差异。

1.1.1 工程bug

工程实现是一个框架设计和实现细节都要求很高的环节。好的框架设计可以通过有经验的架构师实现，而实现细节则很难把控，整个链路涉及的团队至少包括前端、后端、数据、算法等，各个环节的细节取决于负责该部分的工程师的风格，整个链路还需要不同团队之间的沟通和配合，涉及个人风格和团队合作的部分，不可控性大，bug产生概率也大。

缓解这个问题的方法只能是加强测试。而一个现实是，现在很多公司包括大公司，测试岗越来越弱甚至没有，开发岗兼具测试岗，自己开发自己测试，很容易陷入自己的思路闭环中而难以找出问题。等到实际使用时，基本是在最末端环节的算法工程师，发现一些异常现象后，开始沿路排查问题，往往发现的是一些代码粗心、处理逻辑上的问题。

工程bug问题，只能是沿路排查，数据上报、样本处理、特征拼接等是出问题概率较高的几个环节。一些遇到过的例子，比如数据上报把作品时长误上报为播放时长，样本拼接采用了错误的时间戳等。更高层次的解决，那是公司和部门在团队工作流程设计和考核的问题，处于底层的算法工程师往往无能为力。

1.1.2 模型的工程框架

模型训练和上线的流程，主要涉及在线推理的特征获取，离线样本生成以及模型更新。当流程设计不完善时，很容易导致离线和在线特征、样本不一致问题。

1.1.2.1 特征不一致

当离线和在线使用两套流程获取特征时，很容易出现离线在线特征不一致的问题。采用不同流程获取线上推理和离线样本的特征，业界常用的做法是，在线推理时，获取该时刻的特征，生成离线样本时，根据特定的时间戳去获取该时刻的特征，或者直接获取拼接时刻的特征，这种方式容易导致一些问题：

这类问题可以通过训练流程的改进来解决，即将在线预估时获取到的特征落盘，离线拼接样本时不需要再通过另一套流程获取特征，只需要拼接样本的label即可，这样可以保证离线训练使用的特征就是在线时刻推理的特征，实现离线和在线特征的一致性。

1.1.2.2 特征穿越

特征穿越是指训练中使用的某些特征包含了样本发生时刻之后的信息，而这些信息往往和label有一定的相关性，导致离线训练时模型根据这类特征对label拟合得非常好，而在线推理时刻的特征只包含了到当前时刻为止的信息而没有未来的信息，导致相关性消失，模型能力明显下降。

特征穿越问题往往是因为特征离在线不一致问题导致，比如用户的行为序列特征，在线推理时使用的是到当前时刻的行为序列，而离线拼接样本时获取的是最新时刻的特征，则其行为序列的特征中则极有可能包含用户在推理时刻之后发生的正向行为，如点击、播放等，这些行为和样本label强相关，而模型在训练时利用这种相关性实现对label的准确拟合。但推理时刻模型无法获得当前时刻之后的行为，则效果下降。

这类问题一般可以通过定位离在线特征一致性的问题进行改进。

1.1.2.3 样本标签

离线样本的生成，依据的是用户对曝光内容的行为，而用户产生行为到曝光之间有一定的时间差，日志系统回收用户的行为也需要一定的时间，因此需要在一个时间窗口的范围内对用户的行为日志进行处理。当时间窗口较窄时，用户发生靠后的正向行为容易被丢失，从而使正样本变成了负样本，导致离线样本和实际样本标签不一致。

缓解这类问题，可以设置一个较长的时间窗口，保证回收到用户大部分的行为，生成正确的样本，而对时间窗口之外的正向行为，可以通过正样本补发来改进正样本误拼为负样本的情况，即再生成一条正样本。

1.1.2.4 模型更新

模型的更新频率依赖于系统的实时性，实时性越高，模型更新越快。一般发展路径为从天级更新到小时级更新，到分钟级更新，最后是实时更新。更新速度越快，对工程的要求越高。

当模型更新较慢时，存在离在线数据分布差异较大的问题，从而导致离在线AUC不一致，当模型更新的实时性越高，离线和在线的数据分布差异越小，由分布差异导致的离在线AUC不一致问题将被缓解。

机制性差异的产生原因：离线评估时样本和指标表示的信息和模型线上推理时需处理的信息的不一致。这种不一致性包括：

1.2.1 AUC评估方式

离线AUC具有全局性，是基于训练过程中所有用户构成的全量样本计算得到的，而模型在线上推理时仅基于当前这一个用户，因此基于全局样本的离线AUC高，并不代表基于特定用户的准确性就高，则导致离线AUC涨而线上效果不佳。

当聚焦到某个特定用户时，其他用户产生的正负样本对该用户而言是没有意义的，这时基于全局样本计算的AUC的评估效果可能失真。举个例子，假设有两个用户A和B，分别有4条样本， A^+ 和 B^+ 分别表示这两个用户产生的正样本， A^- 和 B^- 表示负样本，当离线预估时得到的样本顺序为 [A^+, A^+, A^+, B^-, B^-, B^-, A^-, B^+] 时，根据《如何计算AUC》分享的AUC计算方法，可算出AUC为0.75，而B用户的离线评估样本为 [B^-, B^-, B^-, B^+] ，AUC为0，也就是模型对B用户几乎没有任何预测能力，所以线上对B用户的效果差，此时全局性的AUC对B用户而言失去了评估的准确性，极大地高估了模型对B用户的效果，而对A用户而言，AUC为1，低估了模型对A用户的效果。所以离线AUC上升并不代表针对单个用户的预估准确性提高，线上效果也不一定提高。

离线AUC上升，表示模型对于全局样本的正负性的区分更明显，而不一定对单个用户拟合更准确。改善这个问题的方法是基于用户粒度进行离线评估，即使用GAUC指标[1]，从而使离线指标和在线预估时的用户粒度保持一致，《什么是好的推荐，重新认识AUC》 的2.5节也对AUC的缺点和改进介绍过。GAUC是论文Din提出的，计算如式子(1)所示，对每个用户计算其AUC，再通过样本数量进行加权。

GAUC = \frac{\sum_{1}^{N}{\#impression_i AUC_i}}{\sum_{1}^{N}{\#impression_i}} \tag{1}虽然GAUC可以改善这个问题，但理论上，离线和在线在评估方式上仍然无法完全对齐，因为在线推理时呈现给用户的是当前这一次请求的结果，而离线评估时是用户在某个时间窗口的所有样本，若干个前者构成后者，因此在评估方式上的完全对齐，还需要考虑基于session的粒度。而基于session的粒度也会带来新的问题，比如低活用户在session内没有任何正样本，导致AUC无法计算，从而使最终评估的有效性打折，因此需要在对齐和有效性之间做一个平衡，目前采用GAUC基本可以比较好地解决该问题。

1.2.2 位置信息

离线样本包含的信息和在线推理需处理的信息存在不一致，其中一个容易被忽视的就是位置信息。item曝光后经过系统一系列处理得到样本，隐式地涵盖了样本所处的位置信息，一个明显的体现是ctr和位置有强关系，一般位置越靠前的item对应的点击率越高。由样本得到的AUC，评估的不是单纯的ctr，而是包含了位置信息的ctr，而模型在线上推理时，并未考虑位置信息，因此离线AUC提升表示带位置信息的ctr效果好，其中一部分效果可能是位置信息贡献的，而线上只考虑单纯的ctr时，效果不一定好。

理论上，模型建模时应显式地考虑位置信息，将位置信息作为特征，线上推理时，应考虑item在不同位置的ctr，再排列组合，使该次请求所有位置的ctr相乘的综合分最高，但这会导致线上推理计算量大量增加，线上性能无法支撑，所以在线上推理时，通常都不考虑位置信息，而直接按照预估分的高低依次呈现给用户。所以当模型建模时位置信息参与度越高而线上推理忽略位置因素时，该问题越容易出现。

缓解该问题的方法是对位置消偏的建模，离线训练时显式地考虑位置信息，线上推理时对所有item的位置取同一个值，经典的方法可以参考youtube发表于RecSys2019的论文[2]，建模方式如图1所示。

在推荐系统迭代初期，机制性差异对离线和在线的效果影响占比较小，可以暂时忽略。当迭代到一定阶段后，推荐系统工作比较精细时，机制性差异对效果的影响变得更明显，这时候需要考虑减小这种差异，方便问题定位和优化迭代。

当前模型和基线模型这个维度的差异，主要来自两个模型在线上推理时预估分数的分布差异。

业务迭代时，通常情况是离线AUC有提升后会直接上线ab实验看效果，用线上效果说话，而很少会进行线上AUC的计算和对比，计算线上AUC往往是因为线上效果不佳，通过这一步来进行问题定位和分析。

计算线上AUC时，容易忽略两个模型所使用的样本不一致问题，它们的样本集合，分别来自ab实验中实验组和对照组，基于两组不同的用户，模型分别进行线上推理得到各自的线上样本，由于样本不一致，AUC的涨跌增加了随机性，导致离线和在线的AUC涨跌不一致。而模型离线训练时，基线模型和当前模型用于计算AUC的样本来自相同的样本集合(测试集)，计算出的AUC具有可比性。

业界往往采用两种方式缓解这个问题：

这两种方式本质上都是在削弱基线模型的样本主导优势，因为离线训练时绝大多数样本都是基线模型生成的，当前模型生成的样本只有实验流量这部分，占比很小，这会导致当前模型拟合的是基线模型的样本而非自己产生的样本，而基线模型拟合的就是自己产生的样本，所以在评估时，基线模型有天然的优势。

当前模型在基线模型的基础上引入一些变化后，可能导致模型的预估分数分布发生变化，比如同一个请求，可能在基线模型得到低预估分，而在当前模型得到高预估分。而AUC是基于所有分数段的样本进行评估，难以看出分布差异，因此需要根据不同分数段的样本，对模型AUC的评估进行细化，从而对比当前模型和基线模型的得分分布。

通过预估分数段的细粒度AUC，可以对比当前模型和基线模型在不同分数段中AUC的表现，从而定位出AUC的提升或下降是主要来自哪部分分数段。通常预估分数不会发生太大变化，当模型发生比较大的版本优化时，容易出现这种情况，比如DNN模型相比传统模型，由于泛化性更强，其得分会更平滑，从而分布发生比较大的变化。

最后，AUC离在线不一致问题，是算法工程师在日常工作遇到的普遍但令人有点头疼的问题，因为在分析和定位问题时，可能会做很多无用功，但是在这个过程中，可以加深对所在业务推荐系统的熟悉度，同时也可以加深对推荐效果的理解。

ref

[1] Deep Interest Network for Click-Through Rate Prediction. https://dl.acm.org/doi/pdf/10.1

[2] Recommending What Video to Watch Next: A Multitask Ranking System. https://dl.acm.org/doi/abs/10.1145/3298689.3346997

推荐系列文章：

用户行为序列建模

多目标

冷启

模型结构-特征交叉

推荐基础知识点

工具

工作相关的内容会更新在【播播笔记】公众号，欢迎关注

生活的思考和记录会更新在【吾之】公众号，欢迎关注

吾之系列文章：