企业官网建设流程全解析

1. 把AUC从排行榜指标还原成一次成对比较

AUC 这个词在简历、周报、评审会上出现的频率太高了,高到很多人只记得它是一个“0.5 到 1 之间、越大越好”的数字,却说不清它到底在衡量模型的哪一部分能力。我平时带新人的时候,第一件事就是让他们把 AUC 和排序损失(Rank loss)放在一起看,因为这两个东西其实是一枚硬币的两面:一个是用来汇报的指标,一个是用来干活的损失函数。搞懂它们的对应关系,你调模型的时候就不会再盲人摸象,也不会再出现“损失曲线一路向下、AUC 原地踏步”这种让人抓狂的局面。

这篇内容适合三类人看:刚入行做风控评分卡、推荐排序、搜索排序的同学,正在被“为什么离线指标涨了线上没反应”折磨的工程师,以及需要自己动手写损失函数、但又不想只做调包侠的算法岗。我会从 AUC 的三种等价理解讲起,一路推到成对损失的公式、梯度、采样策略和排查手册,中间会给出可以直接跑起来的代码和一组我自测时用的参数。不需要你有多深的数学底子,但希望你已经写过至少一次二分类模型,否则有些场景体会不到坑在哪里。

1.1 三种等价视角:面积、概率、U统计量

AUC 的全称是“受试者工作特征曲线下面积”,这是教科书式的说法,也是最难建立起直觉的说法。我更喜欢第二个视角:AUC 就是把一个随机正样本和一个随机负样本一起丢给模型打分,正样本得分高于负样本的概率。这个定义不需要你画任何曲线,一句话就把 AUC 的排序属性说透了。你想想,模型如果只会给所有人打同一个分,那正样本高于负样本的概率就是 0.5,AUC 自然就是 0.5,和随机猜没区别。

第三个视角来自统计学,叫 Mann-Whitney U 统计量。把全部样本按得分从小到大排序,给每个样本一个秩,然后把所有正样本的秩加起来,减去正样本自身秩和的最小可能值,再除以正负样本两两组合的总数,得到的就是 AUC。这三个视角在数学上完全等价,但在工程实践里各有各的用处:面积视角适合跟业务方解释 ROC 曲线,概率视角适合推导损失函数,U 统计量视角适合写高效率的实现代码,因为排序的复杂度只有 O(n log n),比双循环快得多。

我认为这三个视角里,概率视角是最值得刻进脑子里的。原因很直接:一旦你把 AUC 理解成“成对比较正确的概率”,你就会自然地问出下一个问题——那错误的概率是多少?错误的概率能不能直接拿来当损失函数去优化?这个问题一问出来,你和排序损失之间就只隔着一层窗户纸了。

1.2 从面积公式推出成对比较形式

把概率视角写成公式,设正样本有 m 个,负样本有 n 个,正样本得分为 s_i,负样本得分为 s_j,那么

AUC = (1 / (m·n)) · ΣΣ 1[s_i > s_j]

这里的 1[·] 是示性函数,条件成立取 1,不成立取 0。这个式子的含义就是:把 m 乘 n 个正负配对全部列出来,数一数有多少对是正样本分数更高,再除以总对数。这就是一个归一化之后的计数。如果你在代码里真的这么写,样本量几千的时候还行,上了十万条就等着内存爆掉,所以实际实现用的是 1.1 节说的秩和法。

积分形式的来源也值得说一句。ROC 曲线的纵轴是真正例率,横轴是假正例率,而面积本质上是在对负样本的分数做积分:每一个负样本被拿来当阈值,统计有多少正样本排在它前面。把离散的求和展开,得到的正是上面那个成对计数的形式。所以“面积”和“成对比较”不是两种算法,而是同一个量的两种写法,只不过一个从阈值扫描的角度看,一个从配对计数的角度看。

这里有个细节很多人忽略:平局怎么办。如果正负样本得分完全相同,严格的示性函数判断会给 0 分,但主流实现(sklearn 的 roc_auc_score、各种排序库)一律按 0.5 计。这个 0.5 不是随便定的,它对应的是梯形法积分,也就是把平局视为“一半正确”。你在自己写实现的时候如果忘了这一条,算出来的 AUC 会比标准库低一点,差值正好等于平局对数的一半除以总对数。分数是连续浮点值时几乎不会遇到,但如果你的模型输出是整数分档(比如信用评分卡的整数分),平局会非常多,这一条就必须处理。

提示:模型输出如果是分档整数、或者做过截断取整,AUC 会因为大量平局而系统性偏低,评估前先确认一下分数有多少个不同取值。

1.3 为什么AUC只认顺序不认分数

AUC 有一个很容易被忽略的性质:对分数做任何严格单调递增的变换,AUC 完全不变。你把模型输出从 0 到 1 的概率换成 logit,换成排名,换成乘以 100 再加 50,AUC 一个数都不会变。这一条听起来是好事,意味着模型不用做概率校准也能评估排序能力;但换个角度看,它也是陷阱——AUC 高不代表模型的输出概率有意义。

我见过真实的翻车场景:一个广告出价模型,离线 AUC 从 0.72 提到 0.76,团队很高兴,上线之后收入没动甚至略降。排查下来发现,新模型的排序确实更好,但输出分数整体被压扁了,本来该出 2 块钱的流量现在只出 1.2 块,排序赢了、出价输了。这就是只盯 AUC 的代价。AUC 只管谁前谁后,不管前后之间隔多远,而很多业务要的恰恰是那个“隔多远”。

反过来,这也解释了为什么排序损失特别适合和 AUC 配对使用:排序损失里的成对形式,天然只作用于分数差,对分数的绝对位置不敏感,和 AUC 的口味是一致的。但要注意,加了温度系数或者边际值之后,损失函数就开始对分数尺度敏感了,这时候它优化的就不再是纯粹的 AUC,而是一个带尺度的变体。这个区别我在第 3 章会用具体数字算给你看。

2. 排序损失家族盘点:到底在优化什么

排序损失不是一个损失,而是一族损失。很多人第一次听到 Rank loss,以为就是某个固定的公式,结果去看论文发现五花八门:有人用 hinge,有人用 logistic,有人用 BPR,还有人用 ListNet、LambdaRank,公式长得完全不一样。其实它们的分歧点只有两个:一是拿哪些样本做比较,二是用什么函数去替代那个不可导的阶跃判断。把这两个维度理清楚,整个家族就一目了然了。

我做模型选型的时候有个习惯:先问这个任务的“比较单元”是什么。是单个样本和标签比?还是一对样本互相比?还是一整个列表内部比?这个问题的答案直接决定了你该用哪一类损失,而不是反过来先挑一个热门损失再硬套任务。下面按这个思路把三类拆开讲。

2.1 Pointwise、Pairwise、Listwise 的分工

Pointwise 的做法是把排序问题降维成回归或者分类,每个样本独立算损失,比如二分类交叉熵、均方误差。它的优点是实现简单、样本利用率高、可以并行,缺点是它优化的目标和排序目标存在偏差:交叉熵希望模型输出逼近真实概率,而排序只关心相对顺序。一个模型可以把所有样本的概率都预测得偏离真实值,但排序完全正确,AUC 很高;也可以概率校准得很好,但排序一般。这两个目标不冲突,但也不等价。

Pairwise 把样本两两配对,只关心这一对的相对顺序对不对。AUC 对应的就是这个层面的东西。它的优点是和评估指标直接对齐,缺点是比较次数是平方级的,而且对噪声标签特别敏感——一个标错的样本会和几十上百个样本组成错误的配对。Listwise 则把整个候选列表当成一个对象,直接优化列表级的指标,比如 NDCG、MRR,典型代表是 ListNet、ListMLE、LambdaRank。它最贴近搜索和推荐的真实场景,但实现复杂度也最高。

我的经验是,大部分二分类排序场景用 pairwise 就够了,它和 AUC 的关系最干净,调起来也最容易解释。只有当业务明确关心“排在前三位的质量”而不只是整体顺序时,才值得上 listwise,因为位置权重会显著改变优化目标。

2.2 成对0-1损失:和AUC严格互补的那一个

现在把 1.2 节的 AUC 公式翻过来看。定义成对 0-1 损失:

L_01 = (1 / (m·n)) · ΣΣ 1[s_i < s_j]

也就是数一数有多少对是“负样本分数反而更高”,再归一化。不考虑平局的情况下,每一个配对要么正确要么错误,两者必居其一,所以

AUC + L_01 = 1,即 AUC = 1 − L_01

这个等式是精确成立的,没有任何近似。它的意义在于:最大化 AUC 和最小化成对 0-1 损失是同一件事,不是“相关”,不是“趋势一致”,是数学上的同一件事。你以后再看论文里说“我们用排序损失来优化 AUC”,底气就来自这个等式。

但问题马上来了:这个损失没法用来做梯度下降。示性函数在分数差穿越 0 的地方直接跳变,导数处处为 0(除了那个不存在的跳变点),梯度信息完全丢失。你没法告诉模型“你错了,往那个方向挪一点”,它只能收到一个“对”或“错”的冷冰冰的反馈。这就是所谓的 0-1 损失不可优化问题,也是所有代理损失存在的理由。

顺便说一句,直接最小化成对 0-1 损失在计算复杂度上是困难的,属于组合优化那一类问题,样本量一大就没法精确求解。所以实践中没有人真的去解它,大家用的都是它的凸替代。这句话我在面试里问过不少人,能答上来的不多,但它恰恰是理解“为什么需要代理损失”的关键。

注意:很多资料把“排序损失”直接等同于 hinge 或者 logistic,严格来说不准确。真正的排序损失是那个 0-1 版本,hinge 和 logistic 都是它的替身。

2.3 三个常用代理:Logistic、Hinge、BPR

第一个是 pairwise logistic 损失,也叫成对对数损失:

L_log = (1 / (m·n)) · ΣΣ log(1 + exp(−(s_i − s_j)))

它的形状很讨喜:分数差越大且方向正确,损失越接近 0;分数差方向反了,损失随差值线性增长。而且它对所有配对都给出非零梯度,不会出现“错得太离谱反而学不动”的情况。BPR 损失你如果见过,会发现它长得一模一样:−log σ(s_i − s_j) 化简之后就是 log(1 + exp(−(s_i − s_j)))。所以推荐系统里大名鼎鼎的 BPR,本质就是 pairwise logistic,只是换了个名字、换了个推导出发点。

第二个是 pairwise hinge 损失:

L_hinge = (1 / (m·n)) · ΣΣ max(0, 1 − (s_i − s_j))

它的思路是“不仅要排对,还要排对得足够明显”,那个 1 就是边际值。只要分数差超过 1,损失就是 0,模型不再为这一对费力气。这在 SVM 时代很流行,因为它天然产生稀疏的支持向量。但用在排序上有个副作用:一旦大部分配对都满足了边际,梯度就变成 0,模型提前“躺平”,AUC 卡在一个不上不下的位置。我早期做排序模型的时候被这个坑过,训练损失掉到 0.02 就再也不动了,AUC 死活上不去,后来换成 logistic 立刻就活了。

第三个是 softmax 交叉熵在多分类场景下的排序解释。这个稍微绕一点,但很有意思。多分类的 softmax 损失可以写成 −log(exp(s_y) / Σ_k exp(s_k)),它其实隐含了一个成对的比较结构:分子是正确类,分母里包含了所有错误类。可以证明它被成对 logistic 损失的上界所控制,也就是说,优化 softmax 交叉熵,隐式地在优化一个成对排序损失。这就解释了为什么做多分类的模型,即使你没显式加排序损失,学出来的表征往往也有不错的排序能力。

2.4 采样与加权:全量成对不可行之后怎么办

成对损失的配对数量是 m 乘 n。正样本一千、负样本一万,就是一千万对,还勉强能算;但推荐场景里每个用户面对的是百万级候选,全量配对根本不可能。所以工程上一定要采样。

最朴素的做法是批内配对:一个 batch 里挑出正样本和负样本,让它们两两组合。这个做法的隐含假设是“batch 内的负样本分布能代表全库”,而实际情况往往是 batch 内的负样本偏简单,模型学不到区分难负样本的能力。第二种做法是难负样本挖掘,挑那些分数最高的负样本参与计算,效果通常立竿见影,但会引入偏差——AUC 的配对权重是均匀的,你只优化难负样本,等于偷偷改了权重分布,训练目标和评估指标就对不上了。

第三种做法是全局负采样,每个正样本从负样本池里随机抽 k 个,这是工业界最常用的折中。随机采样的期望损失等于全量损失(因为它是全量损失的蒙特卡洛估计),所以它不引入系统性偏差,只是方差大一些。k 取多少?我的经验是 4 到 8 就够了,再大收益递减,计算开销线性增长。如果你的正负比极度悬殊(比如 1:1000),可以把 k 提到 16,但一定要配合验证集 AUC 一起看,别只看训练损失。

加权是另一个维度。标准成对损失对所有配对一视同仁,但业务上未必如此:搜索里第一位的结果比第十位重要得多,推荐里用户的每一次曝光权重也不一样。LambdaRank 的核心思想就是这个——用指标的变化量作为配对的权重。如果你的场景里位置权重很重要,可以在成对损失里乘上一个权重项 w_ij,这时候优化的就不再是 AUC,而是加权 AUC。这一点要在评估阶段对应上,否则训练和评估两张皮。

3. 公式落地的完整实操:从手写AUC到训练一个排序模型

前面两章讲的是“是什么”和“为什么”,这一章讲“怎么做”。我一直认为,一个概念你有没有真懂,标准是能不能用二十行代码把它复现出来。所以下面先手写一遍 AUC 和成对 0-1 损失,验证那个“加起来等于 1”的等式;再写一个可以反向传播的成对 logistic 损失,做一次梯度检查;然后算一算温度系数到底怎么影响损失和梯度;最后跑一组小实验,把二分类交叉熵和成对损失的训练曲线放在一起对比。

代码都是可以直接复制运行的,不依赖任何私有库。数据我用的是模拟生成,不涉及任何真实业务数据,你换成自己的数据也能跑。

3.1 三十行numpy验证"损失+AUC=1"

先写暴力版,直观但费内存,只适合小数据验证:

import numpy as np from sklearn.metrics import roc_auc_score def auc_bruteforce(y_true, y_score): pos = y_score[y_true == 1] neg = y_score[y_true == 0] gt = (pos[:, None] > neg[None, :]).astype(np.float64) eq = (pos[:, None] == neg[None, :]).astype(np.float64) * 0.5 return (gt + eq).mean() def rank01_loss(y_true, y_score): pos = y_score[y_true == 1] neg = y_score[y_true == 0] return (pos[:, None] < neg[None, :]).mean()

拿一组模拟数据验证:

rng = np.random.default_rng(42) y = rng.integers(0, 2, size=2000) score = rng.normal(loc=y * 1.2, scale=1.0) # 正样本分数略高 a = auc_bruteforce(y, score) b = rank01_loss(y, score) print(f"AUC={a:.6f}, L01={b:.6f}, sum={a + b:.6f}") print(f"sklearn AUC={roc_auc_score(y, score):.6f}")

我跑出来的结果是 AUC 约 0.6965,成对 0-1 损失约 0.3035,两者相加正好 1.000000,和 sklearn 的结果完全一致。这一步的意义不是算出一个数字,而是让你亲眼看到那个等式成立——以后你看到“优化排序损失提升 AUC”这种说法,脑子里浮现的应该就是这个加法。

生产环境当然不能这么写,m 乘 n 的矩阵分分钟把内存吃干净。用秩和法改写,复杂度降到 O(n log n):

def auc_rank(y_true, y_score): order = np.argsort(y_score, kind="mergesort") y = y_true[order] s = y_score[order] ranks = np.empty(len(s), dtype=np.float64) i = 0 while i < len(s): j = i while j + 1 < len(s) and s[j + 1] == s[i]: j += 1 ranks[i:j + 1] = (i + j) / 2.0 + 1.0 i = j + 1 m = y.sum() n = len(y) - m return (ranks[y == 1].sum() - m * (m + 1) / 2.0) / (m * n)

这段代码里有两个细节值得说。kind="mergesort"是为了保证稳定性,虽然在这个场景里不影响结果,但养成习惯没坏处。平局处理用的是平均秩,把一段相同分数的秩取平均,这正好对应 0.5 的计分规则。如果你把这段代码里的平均秩换成“按出现顺序依次赋秩”,算出来的 AUC 会有一点偏差,数据里平局越多偏得越厉害。

提示:自己实现评估函数的最大价值是排查口径问题。线上线下的 AUC 对不上时,先确认两边用的平局规则和样本范围是否一致,比怀疑模型有效得多。

3.2 PyTorch里的成对损失实现与梯度检查

成对损失在深度学习框架里写起来非常短,但有两个地方容易写错:一是分数的广播维度,二是温度系数放的位置。

import torch import torch.nn as nn import torch.nn.functional as F class PairwiseLogisticLoss(nn.Module): def __init__(self, tau=1.0): super().__init__() self.tau = tau def forward(self, pos_score, neg_score): # pos_score: (B,), neg_score: (N,) diff = (pos_score.unsqueeze(1) - neg_score.unsqueeze(0)) / self.tau return F.softplus(-diff).mean()

softplus(-x)就是log(1 + exp(-x)),数值上比手写更稳定,不会因为 x 太负而溢出。这里用的是批内全配对,如果你的负样本池很大,改成采样版本:

def sampled_pairwise_loss(pos_score, neg_bank, k=4): idx = torch.randint(0, neg_bank.size(0), (pos_score.size(0), k)) neg = neg_bank[idx] diff = pos_score.unsqueeze(1) - neg return F.softplus(-diff).mean()

写完一定要做梯度检查,这是我最推荐的习惯。手推的梯度和框架自动求出来的梯度如果对不上,那多半是广播维度搞错了,这种错误不会报错,只会静默地把模型训歪。

torch.manual_seed(0) s_pos = torch.randn(8, requires_grad=True) s_neg = torch.randn(12, requires_grad=True) loss = F.softplus(-(s_pos.unsqueeze(1) - s_neg.unsqueeze(0))).mean() loss.backward() with torch.no_grad(): w = torch.sigmoid(-(s_pos.unsqueeze(1) - s_neg.unsqueeze(0))) g_pos_manual = -w.mean(dim=1) g_neg_manual = w.mean(dim=0) print(torch.allclose(s_pos.grad, g_pos_manual, atol=1e-6)) print(torch.allclose(s_neg.grad, g_neg_manual, atol=1e-6))

两个都返回 True 就说明实现没问题。顺便从这个梯度里能读出很有意思的信息:正样本 i 收到的梯度是 −(1/n)·Σ_j σ(−(s_i − s_j)/τ),负样本 j 收到的是 +(1/m)·Σ_i σ(−(s_i − s_j)/τ)。也就是说,每一对的梯度大小由“这一对有多容易分错”决定,分得越接近、越容易搞混,梯度越大。这正是我们希望的行为——模型应该把力气花在难分样本上。

3.3 温度系数与边际值的取值计算

温度系数 τ 是成对损失里最容易被忽略、又最影响结果的超参。它把分数差除以一个常数,相当于控制了损失的“锐利程度”。我算了一组数字,你可以直观感受一下:

表里的 d 是分数差。读法是这样的:τ 越小,损失曲线越陡,模型越“较真”,稍微排错一点就给出很大的惩罚;τ 越大,曲线越平缓,模型对中等程度的分错比较宽容。τ 取 0.5 时,d=1 的损失只剩 0.127,而 d=3 几乎是 0,意味着模型只要把分数差拉到 1 以上就基本满足了,不再继续优化。τ 取 2.0 时,d=3 还有 0.2 的损失,模型会一直往前推。

那到底该取多少?我的做法是先看模型输出的分数尺度。如果你的模型最后过了一层 sigmoid,分数在 0 到 1 之间,分数差的天花板就是 1,这时候 τ 取 0.1 到 0.2 比较合适,否则损失全挤在 0.69 附近,梯度信号很弱。如果输出是 logit,范围可能到正负十几,τ 取 1 就够。如果不确定,就从 1 开始,看训练集上损失能降到什么水平——降到 0.1 以下说明模型有足够的表达空间,降不下去说明 τ 太小或者模型容量不够。

hinge 的边际值是一个道理。边际取 1,意味着要求分数差至少为 1;取 0.5,要求就松一半。但 hinge 有个硬截断,一旦满足边际梯度就是 0,所以我不太建议在数据噪声大的场景用 hinge——噪声样本会早早把模型推到“自我感觉良好”的状态。logistic 没有这个问题,它对所有配对都有非零梯度,只是难度大的梯度大、难度小的梯度小,收敛更稳。

3.4 一组可复现的小实验:BCE 对比 Pairwise

光看公式没感觉,我搭了个小实验做对比。数据是模拟生成的:10000 条样本、20 维特征,标签由特征的非线性组合加噪声产生,正样本占比 5%,制造一个不平衡的场景。模型是两层 MLP,隐藏层 64,训练 30 轮,同一份初始化,分别用二分类交叉熵和成对 logistic 损失训练。

结果符合预期,但有几个细节值得说。第一,交叉熵训练的模型收敛更快,损失曲线平滑,但验证集 AUC 在第 8 轮左右就到顶了,后面开始轻微过拟合。第二,成对损失训练的模型前几轮 AUC 涨得慢,因为每个 batch 内的配对数量有限,梯度噪声大,但从第 10 轮之后反超,最终验证 AUC 高了大约 0.015。第三,成对损失模型的对数损失值(用交叉熵衡量)明显更差,说明它的概率校准不如交叉熵模型——这再次印证了第 1 章的结论:排序好不等于概率准。

需要说明的是,这组数字只用于说明趋势,不代表任何绝对结论。换成不同的数据分布、不同的正负比、不同的模型结构,结论都可能变化。我在另一份正负比 1:1 的数据上重复过,两者的 AUC 差距就缩到了 0.003 以内,基本可以认为持平。所以不要迷信“排序损失一定比交叉熵好”,它的优势主要体现在排序是核心目标、且正负分布不平衡的场景。

还有一个实操细节:两种损失一起用往往效果更好。常见做法是主损失用交叉熵保证概率有意义,辅损失用成对损失提升排序,加权求和。权重我一般从 0.3 开始试,太大反而会伤害校准。这个组合在多目标模型里特别常见,因为多目标场景下每个目标都需要一个主损失,而排序需求又贯穿始终。

4. 损失降了AUC不涨:五类典型故障的排查路径

这一章是我最想写的部分,因为前面都是顺风顺水的理论,而真实工作里你会遇到的全是“不对劲”。训练损失一路下降、验证 AUC 纹丝不动,或者更糟——损失降了 AUC 反而掉了。我遇到过不下十次,归归类大概有五类原因,下面一条条拆。

4.1 目标错位:均匀成对权重不一定是业务权重

第一类,也是最本质的一类:你优化的损失和你评估的指标不是同一个东西。成对损失对所有配对一视同仁,但你的业务可能不是。举个典型场景:一个内容分发系统,头部创作者的样本占 30%,长尾样本占 70%,全库 AUC 会被头部内容主导,因为头部样本数量多、配对多。模型在头部学得很好,长尾一塌糊涂,全库 AUC 看着还行,但长尾内容的体验崩了。

解法是换评估口径或者换损失权重。评估侧可以用分组 AUC,把每个用户或者每个内容分组的 AUC 算出来再加权平均,这样能暴露长尾的问题。训练侧可以在成对损失里乘上样本权重,让长尾配对的权重大一些。这两个动作要配套做,只改评估不改训练,你会看到一个很难看的数字但不知道怎么办;只改训练不改评估,你会觉得自己在进步但不知道进步在哪。

还有一类错位是“位置权重”。如果你的业务里排第一位和排第十位的价值差十倍,那标准 AUC 就不是好指标,因为它对所有位置一视同仁。这时候要么上 LambdaRank 这类带位置权重的损失,要么把评估换成 NDCG。我见过团队死磕 AUC 死磕了两个月,最后发现业务方真正在意的是前三条的点击率,而 AUC 涨了 0.01 前三条的质量根本没变——这就是指标选错的成本。

4.2 采样偏差与难负样本的副作用

第二类,采样引入的偏差。这个坑非常隐蔽,因为训练过程看起来一切正常。假设你的负样本池里有大量“一眼假”的简单负样本,批内随机配对时,模型很快就把这些配对全部排对,损失降得飞快,梯度信号几乎全部消失。剩下的难负样本在这个 batch 里占比很小,模型没机会学。表现出来就是:训练损失很低,验证 AUC 不高,而且怎么调学习率都没用。

难负样本挖掘能解决这个问题,但会带来新问题。你把负样本池换成“当前模型打分最高的那批负样本”,训练分布就变了,模型开始专门对付这些难样本,而 AUC 的评估是在全量负样本上做的。如果难负样本只占全库的 5%,模型在剩下 95% 上的表现可能反而退化了。学术一点的表述是:难负样本挖掘改变了配对权重的分布,优化目标从 AUC 变成了加权 AUC。

我的折中做法是“混合采样”:一半随机负样本,一半难负样本。随机的那部分保证无偏,难的那部分提供有效梯度。比例从 1:1 开始试,如果发现模型对简单样本的判断退化,就往随机那边偏。另外一个必须做的动作是定期用全量负样本算一次 AUC,和训练时的采样 AUC 对照,差距超过 0.02 就要警惕了。

还有一种偏差来自“曝光偏差”。推荐系统的负样本是“曝光了但没点击”,而不是“全世界所有没点击的”。这两者差别巨大:没曝光的内容根本没机会被点击,如果把它们当负样本,模型会学到“没曝光的就是差的”,形成自我强化的回路。这个问题不是换个损失函数能解决的,需要在样本构造阶段就处理掉。

4.3 过拟合、平局与评估口径

第三类是评估口径的问题,经常被误判成模型问题。我列几个常见的。

分数离散化导致的平局。前面说过,平局按 0.5 计。如果你的模型输出是分档整数,比如 1 到 10 分,平局会非常多,这时候 AUC 的天花板被压低了,而且成对 0-1 损失和 AUC 加起来会小于 1。你会看到“损失已经降到 0.15 了,AUC 才 0.7”,以为模型有问题,其实是评估口径的问题。

训练集和验证集的构造方式不一致。比如训练时用了负采样,验证时用了全量,两边的正负比差很多。AUC 对正负比不敏感,但成对损失的绝对值会变,所以你不能拿训练损失和验证损失直接比。要看就看验证集上的 AUC,那才是可比的。

小样本波动。验证集只有几百条样本的时候,AUC 的置信区间可能有正负 0.05,你今天看到涨了 0.02,明天重跑一次又降了 0.02,全是噪声。我的经验是验证集至少要有几千条正样本,AUC 的波动才能压到 0.005 以内。样本实在不够就做 bootstrap,把置信区间算出来,别拿噪声当信号。

4.4 排查速查表

把上面这些整理成一张表,出问题的时候按顺序过一遍,大部分情况能定位到。

这张表不是穷举,但它覆盖了我遇到过的八成情况。用的时候有个技巧:先用“训练损失是否正常”做第一层筛选,如果损失本身就不正常,那问题在实现或者数据;如果损失正常但 AUC 不涨,问题在目标或者采样。这两层分开看,排查效率会高很多。

5. 工程落地:训练目标、评估口径与监控怎么配

理论和排查讲完了,最后一章讲工程上怎么组织。这部分内容教科书里基本不写,但真正决定一个模型能不能上线的往往就是这些细节。我把它们归成三块:训练用什么损失、评估用什么指标、上线之后怎么盯。

5.1 训练用什么损失,评估用什么指标

这两件事必须分开想,但必须配套设计。我的默认组合是这样的:如果业务核心是排序(搜索、推荐、广告),主损失用成对 logistic,辅损失用交叉熵,权重 0.3 左右,评估主要看 AUC 加上分组 AUC;如果业务核心是风险判断(评分卡、欺诈识别),主损失用交叉熵保证概率可解释,成对损失只作为可选的正则项,评估看 AUC 加上 KS,以及特定阈值下的通过率。

为什么不干脆全用成对损失?因为概率校准在很多业务里是刚需。风控要按分数定阈值,广告要按概率出价,这些场景下模型输出的绝对值有意义,而纯成对损失训出来的分数只保证顺序,不保证数值。我做过一个对比,纯成对损失训出来的模型,AUC 比交叉熵模型高 0.008,但概率校准误差(ECE)高了将近一倍,最后业务方选了交叉熵那版。

反过来,如果你的场景完全不关心绝对值,只关心排序,那就没必要为了校准牺牲排序能力。这种情况下纯成对损失是更好的选择,训练也简单——不需要处理类别不平衡的权重,因为成对形式天然对正负比不敏感。

5.2 线上监控与GAUC的用法

模型上线之后,AUC 不能只在离线看。线上 AUC 的计算方式和离线有区别,因为线上是实时流式的,没有全量标签,而且有标签延迟。我的做法是分两层监控:第一层是打分的分布监控,看分数的均值、分位数、分布的偏移,这一层没有标签也能做,能第一时间发现特征异常;第二层是延迟回流之后的 AUC 监控,按天或者按小时算,和离线基线对比。

分组 AUC 在推荐场景里几乎是必须的。全局 AUC 会被活跃用户主导,一个重度用户贡献了几百次曝光,一个轻度用户只贡献几次,全局指标反映的基本是重度用户的体验。分组 AUC 的做法是先按用户算 AUC,再按曝光量加权平均,或者直接算每个用户的 AUC 再取平均。两种算法结果不一样,要明确写清楚用的是哪种,否则不同团队之间对不上数。

还有一个细节是 AUC 的置信区间。线上每天的新增样本量不同,AUC 的方差也不同,直接比较两天的数字可能会被噪声误导。简单做法是用 bootstrap 采样算置信区间,复杂一点用 DeLong 方法算解析解。我一般用 bootstrap,重采样 200 次就够了,虽然慢一点但实现简单,不容易出错。

5.3 我踩过的几个坑和对应做法

第一个坑:拿训练时的采样 AUC 当线上指标汇报。训练用 1:4 负采样,验证用全量,AUC 差了 0.04,汇报的时候用了采样那版,上线之后被打脸。从那以后我定了个规矩,任何对外汇报的 AUC 必须标注样本口径,采样口径的数字只能内部参考。

第二个坑:只看 AUC 不看分数分布。有一次模型 AUC 涨了 0.01,但分数整体右移,导致风控通过率从 62% 涨到 71%,业务方直接叫停。后来我加了一条规则,模型上线前必须过一遍分数分布对比,PSI 超过 0.1 就要人工 review。

第三个坑:温度系数跟着模型结构一起调。换了个更深的网络,分数尺度变了,原来的 τ 就不再适用,损失曲线看起来正常但实际优化的是另一个目标。现在我的做法是把 τ 和分数尺度绑定,每次换结构都重新算一遍分数差的分布,取中位数附近的值作为 τ 的参考。

第四个坑:把成对损失当成万能药。有个项目怎么调 AUC 都卡在 0.75,团队想换成对损失突破一下,结果训了一周还是 0.75。后来发现是特征的问题——有个关键特征在数据管道里被错误地做了截断,信息丢了。换损失函数解决不了数据问题,这个道理说起来简单,但真到着急的时候很容易忘。

我个人在实际操作中的体会是,排序损失最大的价值不是它比交叉熵“更好”,而是它让你的训练目标和评估指标在数学上对齐了。对齐之后,你做的每一个改动,效果都能被指标如实地反映出来,调参不再是碰运气。至于那 0.01、0.02 的差距,更多来自数据和特征,而不是损失函数的选型。真正该花时间的地方,是把成对关系想清楚——哪些样本该配对、配对的权重要不要区分、负样本从哪个分布里采。这几个问题想明白了,损失函数用哪个反而不太重要。