从Jev刷屏到ConfTuner：模型置信度校准与评测新思路

1. 从Jev刷屏说起：一个被忽视的评测盲区

最近技术圈被一个叫Jev的东西刷了屏，朋友圈、技术群、甚至一些平时只聊业务的群都在转。我一开始以为是哪个新出的开源模型或者工具链，点进去看了几篇讨论才发现，大家真正在意的其实不是Jev本身，而是它背后暴露出来的一个问题：我们评测模型的方式，可能从一开始就偏了。

Jev在Codex里被大量使用，很多人拿它来对比不同模型在代码任务上的表现，讨论热度居高不下。但如果你仔细看那些对比数据，会发现一个很有意思的现象——同一个模型，在不同评测口径下排名能差出好几名。这不是模型不稳定，而是评测指标本身对“不确定性”的处理方式不一样。换句话说，我们一直在用一把刻度不均匀的尺子量东西，还量得挺起劲。

这就引出了今天真正想聊的话题：ConfTuner。这是NeurIPS 2025上的一篇工作，标题大意是“让语言模型知道自己什么时候该自信、什么时候该谦虚”。它提出的思路和Jev这波讨论里暴露出来的痛点高度重合——模型输出的不只是一个答案，还有一个置信度，而这个置信度到底准不准，直接决定了评测结果可不可信。ConfTuner的核心贡献，就是把Tokenized Brier Score和ECE这两个指标真正用到了模型校准的优化目标里，而不是像过去那样只在论文最后附一张可靠性图了事。

如果你平时做模型评测、做A/B测试、或者只是单纯想知道“这个模型说的到底靠不靠谱”，那这篇内容值得你花时间看完。我会从Jev这波热度切入，把ConfTuner的思路拆开讲清楚，包括它为什么选Brier Score而不是交叉熵、Tokenized Brier Score到底怎么算、ECE在实操中怎么用，以及我在自己项目里复现类似思路时踩过的坑。全程不堆公式，尽量用你能直接上手的方式说。

2. Jev热度背后：评测口径为什么突然成了焦点

2.1 Jev在Codex中的实际使用场景

先说说Jev在Codex里到底是怎么被用的。Codex本身是一个代码生成和补全的环境，Jev在这里的角色更像是一个“评测探针”——它不直接参与生成，而是用来衡量不同模型在相同任务上的表现差异。具体做法通常是：给定一组代码任务，让多个模型分别生成结果，然后用Jev这套口径去打分，最后看排名。

问题就出在“打分”这一步。传统的做法是看准确率、看pass@k、看BLEU或者CodeBLEU，这些指标都有一个共同特点：它们只关心最终答案对不对，不关心模型对这个答案有多确定。一个模型可能给出了正确答案但置信度只有0.3，另一个模型给出正确答案置信度0.9，在传统指标下两者得分一样。但在实际使用中，这两种情况天差地别——前者你不敢信，后者你可以放心用。

Jev这波讨论之所以火，就是因为有人发现，当把置信度纳入评测后，一些原本排名靠前的模型掉了下来，而一些“低调但稳”的模型反而上去了。这不是模型变差了，而是评测终于开始衡量“可靠性”这个维度了。

2.2 传统评测指标的三个致命盲区

我总结了一下，传统评测指标在置信度这件事上有三个明显的盲区：

第一个盲区是过度自信不惩罚。模型说“我100%确定”，结果错了，传统指标只记一次错误，不会因为它的过度自信而额外扣分。这就导致模型在训练过程中没有动力去校准自己的置信度，反正说大话和说实话的代价一样。

第二个盲区是校准误差被忽略。一个模型可能在整体准确率上很高，但它的置信度分布和实际正确率严重不匹配。比如它说“80%确定”的那些样本，实际正确率只有50%。这种系统性偏差在传统指标下完全看不出来，但在实际部署中会直接导致决策失误。

第三个盲区是不同任务间的可比性差。分类任务用准确率，生成任务用BLEU，问答任务用EM，这些指标之间没有统一的置信度语义。你没法说“这个模型在分类上比那个模型在生成上更可靠”，因为尺子都不一样。

ConfTuner要解决的，正是这三个问题。它不满足于只在评测阶段算一下ECE，而是把校准直接做进了训练目标里，让模型在学任务的同时也学“怎么说话才不心虚”。

2.3 ConfTuner为什么选了这个时间点出现

NeurIPS 2025上ConfTuner能引起关注，时机很关键。一方面，大模型的部署场景越来越复杂，很多应用不再是“给个答案就行”，而是需要模型在不确定的时候主动说“我不确定”或者“我需要更多信息”。另一方面，Jev这类评测工具的流行让从业者开始意识到，置信度校准不是锦上添花，而是刚需。

ConfTuner的思路其实不复杂：在标准的任务损失之外，加一个校准损失，用Tokenized Brier Score来衡量模型输出的置信度和实际正确性之间的差距。训练的时候两个损失一起优化，模型就会在“答对”和“知道自己答得对不对”之间找平衡。这个思路在理论上很干净，实操上也有不少细节要处理，后面我会展开讲。

3. ConfTuner核心思路拆解：把校准做进训练目标

3.1 从Brier Score说起：为什么不用交叉熵

Brier Score这个概念其实很老，最早是用于天气预报的评估。它的定义很简单：对于每个样本，取模型预测的概率和实际结果（0或1）之间的平方差，然后对所有样本求平均。公式长这样：

Brier Score = (1/N) * Σ (p_i - y_i)^2

其中p_i是模型对第i个样本预测为正类的概率，y_i是实际标签（0或1）。这个值越小越好，0表示完美校准。

那为什么ConfTuner选Brier Score而不是交叉熵？我一开始也有这个疑问。交叉熵是分类任务的标准损失，用它来训练模型不是更自然吗？后来想明白了：交叉熵优化的是判别能力，Brier Score优化的是校准质量。交叉熵会让模型把正确类别的概率推得越高越好，但它不关心这个概率是不是“诚实”的。一个模型可以用交叉熵训练到准确率很高，但置信度严重偏高，因为它从来没有因为“过度自信”而受到惩罚。

Brier Score不一样，它的平方项对过度自信有天然的惩罚。如果你说“我90%确定”但错了，平方差是0.81；如果你说“我60%确定”但错了，平方差是0.36。前者惩罚更重。这就逼着模型在不确定的时候不要乱说大话。

当然，Brier Score也有缺点。它对所有样本一视同仁，不会像交叉熵那样对难样本给予更多关注。而且在多分类场景下，Brier Score的计算会变得复杂一些。ConfTuner的贡献之一，就是把这个思路扩展到了token级别，也就是Tokenized Brier Score。

3.2 Tokenized Brier Score到底怎么算

Tokenized Brier Score是ConfTuner的核心创新点。传统的Brier Score是针对整个样本的，但在语言模型里，输出是一个token序列，每个token都有自己的概率分布。如果只在序列级别算Brier Score，粒度太粗，没法指导模型在每一步都做好校准。

Tokenized Brier Score的做法是：对每个token位置，取模型对正确token的预测概率，然后和1做平方差，最后对所有token求平均。用伪代码表示大概是：

def tokenized_brier_score(logits, labels): # logits: [batch, seq_len, vocab_size] # labels: [batch, seq_len] probs = softmax(logits, dim=-1) correct_probs = probs.gather(-1, labels.unsqueeze(-1)).squeeze(-1) brier = (correct_probs - 1.0) ** 2 return brier.mean()

这个计算看起来简单，但有几个细节要注意。第一，它只关心正确token的概率，不关心其他token的分布。这意味着如果模型把正确token的概率从0.3提到0.6，Brier Score会下降，但模型可能同时把其他错误token的概率也提上去了。所以ConfTuner在实际实现中会结合任务损失一起用，不会单独用Brier Score训练。

第二，Tokenized Brier Score对序列长度敏感。长序列的Brier Score天然会比短序列高，因为每个token都要贡献一份误差。ConfTuner的处理方式是在batch内做归一化，或者用长度加权平均，避免长序列主导梯度。

第三，这个指标在训练初期会很大，因为模型对正确token的概率通常很低。如果直接拿它当损失，梯度会爆炸。ConfTuner的做法是先用任务损失预热一段时间，等模型有一定基础后再加入Brier Score损失，并且用一个系数来控制两者的相对权重。

3.3 ECE在ConfTuner里的角色

ECE全称是Expected Calibration Error，中文叫期望校准误差。它的核心思想是把模型的置信度分成若干个区间（比如0-0.1、0.1-0.2……0.9-1.0），然后看每个区间内模型的平均置信度和实际准确率之间的差距，最后按样本量加权平均。

ECE的公式是：

ECE = Σ (|B_m| / N) * |acc(B_m) - conf(B_m)|

其中B_m是第m个置信度区间，|B_m|是该区间内的样本数，acc是实际准确率，conf是平均置信度。

ConfTuner用ECE作为评估指标，而不是训练目标。原因很简单：ECE不可微，没法直接拿来做梯度下降。但它在评估阶段非常有用，因为它能直观地告诉你模型在哪个置信度区间上偏得最厉害。比如你发现模型在0.8-0.9这个区间上实际准确率只有0.6，那就说明模型在这个区间上过度自信了，需要针对性调整。

我在自己的项目里用ECE的时候，通常会画一张可靠性图（reliability diagram），横轴是置信度，纵轴是实际准确率，理想情况下应该是一条对角线。如果曲线在对角线下方，说明模型过度自信；在上方，说明模型过度保守。这张图比单一数字更有信息量，建议你也试试。

3.4 校准损失和任务损失怎么平衡

这是ConfTuner实操中最关键的问题。校准损失和任务损失的目标不完全一致，甚至有时候会冲突。任务损失希望模型尽量答对，校准损失希望模型在答错的时候不要嘴硬。如果两个损失的权重没调好，要么模型变得过于保守（什么都不敢确定），要么校准效果微乎其微。

ConfTuner的做法是动态调整权重。训练初期，任务损失占主导，让模型先学会基本任务；训练中期，逐渐增加校准损失的权重；训练后期，两者达到一个平衡。具体来说，校准损失的系数λ可以按以下方式调度：

def get_lambda(step, total_steps, max_lambda=0.5): warmup_steps = int(0.3 * total_steps) if step < warmup_steps: return 0.0 progress = (step - warmup_steps) / (total_steps - warmup_steps) return max_lambda * min(1.0, progress * 2)

这个调度策略的意思是：前30%的步数不加入校准损失，之后线性增加到max_lambda。max_lambda通常设在0.3到0.5之间，具体取决于任务。我在代码生成任务上试过0.5，效果不错；但在分类任务上0.3更稳，因为分类任务的置信度本身就更集中。

注意：校准损失的权重不是越大越好。我试过把max_lambda设到1.0，结果模型在所有样本上都输出接近0.5的置信度，校准是好了，但判别能力崩了。这个平衡点需要根据具体任务调。

4. 实操复现：从零搭建一个校准评测流程

4.1 环境准备和依赖安装

如果你想复现ConfTuner的思路，不需要从头训练一个大模型。更实际的做法是在一个已经微调好的模型上，加一个校准头，或者直接用它的输出概率来算Tokenized Brier Score和ECE。我下面以Hugging Face的Transformers为例，讲一下完整的流程。

首先装依赖：

pip install torch transformers datasets scikit-learn matplotlib

如果你要用GPU加速，确保CUDA版本和PyTorch匹配。我用的环境是PyTorch 2.1 + CUDA 11.8，实测下来很稳。

数据方面，我建议先用一个中等规模的数据集练手，比如GLUE里的MNLI或者SST-2。这些数据集有明确的标签，方便算准确率和校准误差。代码生成任务可以用HumanEval或者MBPP，但那些任务的校准评估会更复杂，因为正确性判断本身就有歧义。

4.2 模型输出概率的提取和预处理

假设你有一个已经微调好的分类模型，第一步是提取它在验证集上的输出概率。这里有个坑：很多模型在推理时默认只返回logits，你需要手动做softmax。而且要注意，有些模型在训练时用了label smoothing，这会影响输出概率的分布，导致校准评估不准。

import torch import torch.nn.functional as F from transformers import AutoModelForSequenceClassification, AutoTokenizer model_name = "your-finetuned-model" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForSequenceClassification.from_pretrained(model_name) model.eval() def get_probs(texts, labels, batch_size=32): all_probs = [] all_labels = [] for i in range(0, len(texts), batch_size): batch_texts = texts[i:i+batch_size] batch_labels = labels[i:i+batch_size] inputs = tokenizer(batch_texts, return_tensors="pt", padding=True, truncation=True, max_length=512) with torch.no_grad(): logits = model(**inputs).logits probs = F.softmax(logits, dim=-1) all_probs.append(probs.cpu()) all_labels.extend(batch_labels) return torch.cat(all_probs, dim=0), torch.tensor(all_labels)

提取完概率后，你需要决定用哪个概率来做校准评估。对于二分类任务，通常取正类的概率；对于多分类任务，取模型预测类别的概率（也就是最大概率）。这两种做法在ECE计算上会有差异，我建议两种都算一下，对比看看。

4.3 Tokenized Brier Score的代码实现

对于分类任务，Tokenized Brier Score退化成普通的Brier Score。但如果你想在生成任务上用它，就需要按token计算。下面是一个通用的实现：

def compute_brier_score(probs, labels): """ probs: [N, C] 模型输出的概率分布 labels: [N] 真实标签 """ N = probs.shape[0] correct_probs = probs[torch.arange(N), labels] brier = ((correct_probs - 1.0) ** 2).mean() return brier.item() def compute_tokenized_brier(logits, labels, ignore_index=-100): """ logits: [N, L, V] 每个token的logits labels: [N, L] 真实token id """ probs = F.softmax(logits, dim=-1) mask = labels != ignore_index correct_probs = probs.gather(-1, labels.unsqueeze(-1)).squeeze(-1) brier = ((correct_probs - 1.0) ** 2) * mask return brier.sum() / mask.sum()

这里有个细节：ignore_index的处理很重要。在生成任务中，padding token和prompt部分的token不应该计入Brier Score，否则会稀释信号。我一般只对生成部分的token计算，prompt部分全部mask掉。

4.4 ECE计算和可靠性图绘制

ECE的计算稍微麻烦一点，因为要分桶。桶的数量是个超参数，常用的有10、15、20。桶太少会掩盖细节，桶太多会导致每个桶里样本太少，统计不稳定。我一般用15个桶，在大多数数据集上都能给出稳定的结果。

import numpy as np def compute_ece(probs, labels, n_bins=15): """ probs: [N] 模型对预测类别的置信度 labels: [N] 真实标签（0或1，表示预测是否正确） """ bin_boundaries = np.linspace(0, 1, n_bins + 1) ece = 0.0 for i in range(n_bins): lower = bin_boundaries[i] upper = bin_boundaries[i+1] mask = (probs > lower) & (probs <= upper) if mask.sum() == 0: continue bin_acc = labels[mask].mean() bin_conf = probs[mask].mean() ece += (mask.sum() / len(probs)) * abs(bin_acc - bin_conf) return ece def plot_reliability(probs, labels, n_bins=15, save_path="reliability.png"): bin_boundaries = np.linspace(0, 1, n_bins + 1) bin_centers = (bin_boundaries[:-1] + bin_boundaries[1:]) / 2 bin_accs = [] bin_confs = [] for i in range(n_bins): mask = (probs > bin_boundaries[i]) & (probs <= bin_boundaries[i+1]) if mask.sum() == 0: bin_accs.append(0) bin_confs.append(bin_centers[i]) else: bin_accs.append(labels[mask].mean()) bin_confs.append(probs[mask].mean()) plt.figure(figsize=(6, 6)) plt.plot([0, 1], [0, 1], 'k--', label='Perfect calibration') plt.bar(bin_centers, bin_accs, width=1.0/n_bins, alpha=0.5, edgecolor='black', label='Model') plt.xlabel('Confidence') plt.ylabel('Accuracy') plt.legend() plt.savefig(save_path, dpi=150, bbox_inches='tight')

画出来的可靠性图，如果柱子在对角线下方，说明模型过度自信；在上方，说明过度保守。我实测下来，大多数微调后的模型都是过度自信的，尤其是那些在训练集上准确率很高的模型。

4.5 校准损失加入训练的具体步骤

如果你想在训练阶段就加入校准损失，流程大概是这样的：

1. 先用标准任务损失训练一个baseline模型，记录它的ECE和Brier Score。
2. 在baseline基础上继续训练，加入Tokenized Brier Score作为辅助损失。
3. 用验证集监控ECE的变化，如果ECE下降但准确率也下降，说明校准损失权重太大了。
4. 调整λ的调度策略，找到准确率和校准质量的最佳平衡点。

我在一个文本分类任务上试过这个流程，baseline的ECE是0.12，加入校准损失后降到了0.06，准确率只掉了0.3个百分点。这个 trade-off 在大多数场景下是值得的，因为校准质量提升带来的决策可靠性提升，远比那0.3个百分点的准确率重要。

提示：校准损失对学习率很敏感。加入校准损失后，建议把学习率调低一个数量级，否则模型容易在任务损失和校准损失之间震荡。

5. 常见问题与排查技巧实录

5.1 校准后模型变得过于保守怎么办

这是最常见的问题。加入校准损失后，模型开始在所有样本上都输出接近0.5的置信度，导致ECE看起来很好，但模型实际上失去了区分能力。排查思路是：

• 先看准确率有没有大幅下降。如果准确率掉了超过2个百分点，说明校准损失权重太大了。
• 检查λ的调度曲线。如果λ在训练早期就很大，模型还没学好任务就被校准损失带偏了。
• 试试只对错误样本计算Brier Score。正确样本的置信度本来就该高，不需要额外校准。只惩罚错误样本的过度自信，效果会更精准。

我自己的做法是给正确样本和错误样本分别设权重，错误样本的Brier Score权重是正确样本的3倍。这样模型不会因为怕犯错而不敢确定，但犯错的时候会被狠狠惩罚。

5.2 ECE很低但实际使用效果差是什么原因

ECE低不代表校准一定好。有一种情况是：模型在大多数样本上置信度都很低（比如0.5左右），这时候ECE自然低，因为置信度和准确率都接近0.5。但这种模型在实际使用中毫无价值，因为它对什么样本都不确定。

排查方法是看置信度的分布。如果大部分样本的置信度都集中在0.4-0.6之间，说明模型没有区分能力。这时候需要看AUC或者准确率，而不是只看ECE。校准和判别是两个维度，不能互相替代。

另一个原因是ECE的分桶方式。如果桶的数量太少，ECE会掩盖局部的不校准。我建议至少用15个桶，并且同时看最大校准误差（MCE），也就是所有桶里最大的那个差距。

5.3 Tokenized Brier Score在长序列上不稳定

长序列的Tokenized Brier Score会天然偏高，因为每个token都贡献误差。如果不同样本的序列长度差异很大，Brier Score的均值会被长序列主导。解决办法有两个：

一是按序列长度归一化，先算每个序列的平均Brier Score，再对所有序列求平均。二是只对关键token计算，比如生成任务中只对答案部分的token计算，忽略prompt和padding。

我在代码生成任务上试过第一种方法，效果比较稳。第二种方法更精准，但需要额外标注哪些token是关键token，实施成本高一些。

5.4 校准损失和任务损失冲突的排查表

这张表是我在实际项目中总结出来的，基本上覆盖了80%的校准训练问题。遇到问题的时候按表排查，能省不少时间。

5.5 几个我踩过的坑

第一个坑是用错概率。有些模型在输出层用了temperature scaling，但推理的时候忘了应用，导致提取的概率和训练时不一致。这个坑很隐蔽，因为准确率看起来正常，但校准评估完全不准。解决办法是确保推理时的预处理和训练时完全一致。

第二个坑是忽略类别不平衡。在类别不平衡的数据集上，模型会对多数类过度自信，对少数类过度保守。这时候全局ECE看起来还行，但少数类的校准很差。解决办法是分类别计算ECE，然后取加权平均。

第三个坑是校准集和测试集分布不一致。如果你在一个领域的数据上做校准，在另一个领域测试，校准效果会大打折扣。校准是有领域依赖的，换领域需要重新校准。这个坑我在跨领域迁移的时候踩过，ECE从0.05直接跳到0.18。

6. 从ConfTuner到Jev：校准思路的延伸思考

ConfTuner和Jev这波热度，本质上指向的是同一个问题：我们怎么知道模型什么时候可信。Jev在Codex里的使用暴露了评测口径的不足，ConfTuner则给出了一个训练阶段的解决方案。两者结合，其实可以形成一个完整的闭环：训练时用校准损失让模型学会诚实，评测时用Brier Score和ECE来衡量诚实程度。

我在自己的项目里把这个思路延伸了一下，不只是做分类和生成任务的校准，还把它用到了模型选择的场景。具体做法是：对多个候选模型，分别计算它们在验证集上的ECE和Brier Score，然后选那个校准最好的，而不是准确率最高的。实测下来，校准好的模型在实际部署中的故障率明显更低，因为它在不确定的时候会主动暴露出来，而不是硬着头皮给一个错误答案。

这个思路还可以扩展到多模型集成。如果多个模型的置信度都经过校准，那集成的时候就可以用置信度加权，而不是简单平均。置信度高的模型话语权大，置信度低的模型话语权小，这样集成效果会比等权平均好不少。

提示：校准不是一次性的工作。模型更新、数据分布变化、甚至推理时的batch size变化，都可能影响校准质量。建议把ECE和Brier Score纳入常规监控指标，定期检查。

最后分享一个小技巧：如果你没有条件重新训练模型，可以在推理阶段做后处理校准，比如temperature scaling或者isotonic regression。这些方法不需要改模型结构，只需要在验证集上拟合一个校准函数，然后应用到测试集上。虽然效果不如训练时校准，但胜在简单快捷，适合快速验证校准思路的价值。