1. 从Jev刷屏说起：一个被忽视的校准问题
最近技术圈里Jev的讨论热度居高不下，从模型本身的架构设计到在Codex中的实际调用方式，再到API的接入体验，几乎每个环节都被翻来覆去地拆解。但如果你仔细翻一遍这些讨论，会发现绝大多数注意力都集中在“模型能力有多强”“推理速度有多快”“接入成本有多低”这些维度上。很少有人注意到一个更底层、也更致命的问题：模型输出的概率到底可不可信。
这个问题听起来有点学术，但它直接决定了一个模型在实际业务中能不能用、敢不敢用。举个很简单的例子：你让模型判断一封邮件是不是垃圾邮件，它告诉你“87%的概率是垃圾邮件”。如果这个87%是准的，那你可以放心地设置一个阈值，比如超过80%就自动拦截。但如果这个87%其实是拍脑袋出来的，实际准确率只有60%，那你的自动化策略就会频繁误杀正常邮件。这就是概率校准要解决的核心问题。
Jev之所以火，很大程度上是因为它在多个基准测试上展现出了很强的推理能力。但推理能力强不等于概率输出可靠。一个模型可以在分类任务上达到很高的准确率，同时它的置信度分布却是一塌糊涂。这两件事在技术上是解耦的。而NeurIPS 2025上有一篇叫ConfTuner的工作，恰好就在探索如何用更聪明的方式来做概率校准。它的核心思路和Jev这类模型面临的校准需求高度吻合，只是当时没有引起足够的关注。
这篇文章不打算复述Jev的技术报告，也不准备把ConfTuner的论文从头到尾翻译一遍。我想做的是：把这两件事串起来，讲清楚为什么概率校准是当前大模型落地的一个关键瓶颈，ConfTuner提出的Tokenized Brier Score到底解决了什么问题，以及如果你手头正在用Jev或者类似的模型做业务，应该怎么理解和处理校准这件事。不管你是刚接触这个概念的新手，还是已经在做模型评估的从业者，下面这些内容应该都能给你一些可以直接用的东西。
2. 概率校准到底在调什么：从置信度到实际命中率
2.1 一个模型说自己“80%确定”时，它在说什么
先把这个概念掰开揉碎。假设你训练了一个图像分类模型，给它看一万张图片，每张图片它都会输出一个概率分布。对于其中某一类，模型说“我有80%的把握这张图是猫”。现在你把所有模型认为“80%是猫”的图片挑出来，数一数里面到底有多少张真的是猫。如果正好有80%是猫，那这个模型的校准就是好的。如果只有50%是猫，那模型就是过度自信的；如果有95%是猫，那就是过度保守的。
这个定义非常直观，但实际操作起来有很多坑。最典型的问题是：准确率高不代表校准好。一个模型可以在测试集上达到95%的准确率，但它的置信度分布可能严重偏离对角线。比如它把所有样本都预测成“90%确定”，但实际只有70%是对的。这种情况下，虽然最终分类结果大部分是对的，但一旦你依赖这个置信度做决策——比如设置阈值、做集成、做风险控制——就会出大问题。
Jev这类模型在实际使用中，用户经常会让它做判断类任务：这段代码有没有bug、这个回答是否安全、这个请求该不该路由到人工。这些场景下，模型给出的不只是一个标签，还有一个隐含的置信度。如果这个置信度不可靠，整个决策链路就是建在沙子上。
2.2 为什么大模型时代的校准比传统分类更难
传统分类模型的校准问题已经研究了十几年，温度缩放、Platt Scaling、Isotonic Regression这些方法都比较成熟。但到了大模型时代，事情变得复杂得多。原因有几个：
第一，输出空间不再是固定的类别集合。传统分类模型输出的是固定数量的类别概率，而大模型输出的是token序列。你没法直接说“这个回答的置信度是73%”，因为回答是由几十个token组成的，每个token都有自己的概率。怎么把这些token级别的概率聚合成一个整体的置信度，本身就是个开放问题。
第二，校准的维度变了。传统校准关注的是“预测为A类的样本中实际有多少是A类”。但在生成任务中，你关心的可能是“这个回答的事实准确性有多高”“这段代码能不能跑通”“这个翻译是否忠实于原文”。这些维度的校准和传统的类别校准不是一回事。
第三，评估成本极高。传统分类任务可以轻松拿到几千几万个标注样本做校准曲线。但大模型的生成任务，每个样本都需要人工评估或者用另一个强模型来打分，成本高、周期长。这就导致很多团队根本不做校准评估，直接默认模型的置信度可用。
ConfTuner之所以值得关注，就是因为它试图在不增加太多标注成本的前提下，给出一个可操作的校准方案。它的核心创新Tokenized Brier Score，本质上是在token级别上重新定义了校准的度量方式。
2.3 Brier Score的老问题和新解法
Brier Score本身是个很经典的指标，公式很简单：预测概率和实际结果之间的均方误差。对于二分类问题，如果实际结果是1，模型预测概率是p，那Brier Score就是(1-p)²；如果实际结果是0，就是p²。这个指标同时惩罚了过度自信和过度保守，而且对概率的细微变化很敏感。
但直接把这个指标用到语言模型上会碰到一个尴尬的问题：语言模型的输出是token序列，每个位置都有一个概率分布。你没法直接拿整个序列的Brier Score来做校准，因为不同位置的token重要性完全不同。一个句子里，“的”“了”“是”这些功能词的预测概率通常很高，但它们对回答质量的贡献很小；而关键实体、数字、逻辑连接词的概率才是真正重要的。
ConfTuner提出的Tokenized Brier Score就是针对这个问题。它的思路是：不要把所有token一视同仁，而是根据token在序列中的角色赋予不同的权重。具体来说，它会把token分成几类：内容token、结构token、功能token，然后对不同类型的token分别计算Brier Score，最后加权聚合。这样得到的校准指标更能反映模型在关键决策点上的置信度质量。
这个思路听起来简单，但实际操作中有很多细节需要处理。比如怎么定义token的类型、权重怎么设定、不同任务下权重是否需要调整。这些在ConfTuner的论文里都有讨论，但如果你要自己实现，需要根据具体业务场景做适配。
3. ConfTuner的Tokenized Brier Score：拆开看它的设计逻辑
3.1 为什么不能直接用序列级概率做校准
在深入ConfTuner的细节之前，先搞清楚一个前置问题：为什么不能直接把整个序列的联合概率拿来做校准？比如模型生成一个回答，联合概率是0.003，这个数字能不能直接当作置信度？
答案是不能，原因有两个。第一，序列长度会严重影响联合概率。一个10个token的回答和一个100个token的回答，联合概率的量级完全不同。即使两个回答的质量一样，长回答的联合概率也会低得多。这就导致你没法跨样本比较置信度。
第二，联合概率对局部错误极其敏感。如果回答中有一个token预测错了，整个序列的联合概率会断崖式下跌。但这个token可能只是个无关紧要的虚词，对整体质量影响很小。用联合概率做校准，会把这种微小错误放大成严重的置信度下降。
ConfTuner的做法是放弃序列级联合概率，转向token级校准。它不试图给整个回答一个统一的置信度分数，而是关注模型在每个关键token上的概率是否可靠。然后通过聚合这些token级的校准指标，得到一个整体的评估。
这个思路的转变很关键。它意味着校准不再是“给每个回答打个分”，而是“评估模型在生成过程中的概率质量”。这两种视角对应的是完全不同的应用场景。前者适合做过滤和排序，后者适合做模型诊断和改进。
3.2 Token分类的具体规则和权重设计
ConfTuner把token分成三类，这个分类规则是整套方法的基础。根据论文的描述和我的理解，大致是这样的：
- 内容token：承载实际信息的token，比如名词、动词、形容词、数字、专有名词。这些token的预测质量直接决定回答的准确性和信息量。
- 结构token：负责组织内容的token，比如标点符号、连接词、段落标记。这些token影响回答的可读性和逻辑性，但不直接贡献信息。
- 功能token：语言中的高频虚词，比如“的”“了”“是”“在”。这些token的预测通常很容易，概率普遍很高，对校准的区分度贡献很小。
权重设计上，内容token的权重最高，结构token次之，功能token最低。具体数值在论文里有消融实验，但核心思想是：把校准的注意力集中在真正重要的决策点上。
这个设计有一个很实际的考虑：如果对所有token一视同仁，功能token的高概率会拉高整体校准指标，掩盖内容token上的校准问题。而内容token恰恰是模型最容易出错、也最需要校准的地方。
注意：Token分类规则需要根据具体语言和任务调整。中文和英文的token分布差异很大，代码生成和自然语言生成的token类型也完全不同。直接套用论文里的权重可能效果不好，建议在自己的数据上做一轮验证。
3.3 从Brier Score到可操作的校准信号
Tokenized Brier Score最终输出的是一个数值，但这个数值本身怎么用，才是实际落地时最关心的问题。ConfTuner给出了几个使用方向：
第一，模型对比。当你需要在两个模型之间做选择时，除了看准确率，还可以看Tokenized Brier Score。一个准确率稍低但校准更好的模型，在实际业务中可能更可靠。
第二，阈值设定。如果你要用模型置信度做过滤或路由，Tokenized Brier Score可以帮助你判断在哪个置信度区间内模型的输出是可信的。比如你可以画出校准曲线，找到模型实际准确率和声称置信度最接近的区间。
第三，训练信号。如果你在微调模型，可以把Tokenized Brier Score作为辅助损失函数的一部分，直接优化模型的校准质量。这比只在训练后做温度缩放要更根本。
第四，异常检测。当模型在某个样本上的Tokenized Brier Score异常高时，说明它在这个样本上的概率输出很不靠谱。这可以作为一个信号，触发人工审核或者降级处理。
这四个方向里，前两个是评估层面的，后两个是训练和部署层面的。对于大多数团队来说，从评估层面入手是最现实的。先把校准指标纳入模型评估体系，再逐步往训练和部署环节渗透。
4. 把ConfTuner的思路接到Jev的实际使用中
4.1 Jev在Codex场景下的校准需求
Jev在Codex中的使用场景很具体：代码补全、代码审查、bug定位、重构建议。这些任务有一个共同特点：模型需要做大量局部决策。每一行代码、每一个变量名、每一个函数调用，都是一个决策点。这些决策点的概率质量直接决定了生成代码的可用性。
举个例子，假设Jev在补全一段Python代码时，对某个函数名的预测概率是0.6，对参数类型的预测概率是0.9。如果0.6这个概率是准的，那说明模型在这个位置确实不太确定，你可以选择让用户确认或者提供多个候选。但如果0.6实际上是过度自信的，真实准确率只有0.3，那用户就会频繁遇到“模型很自信但结果是错的”这种情况。
这就是校准在代码场景下的实际价值：它决定了你能否信任模型的置信度来做交互设计。如果校准做得好，你可以根据置信度动态调整交互策略——高置信度直接插入，中置信度给候选列表，低置信度触发人工确认。如果校准不好，这套策略就没法用。
4.2 在Jev输出上实现Tokenized Brier Score的实操步骤
如果你手头有Jev的API访问权限，想自己跑一遍Tokenized Brier Score，大致需要这几步：
第一步：构造评估数据集。准备一批有标准答案的任务样本。对于代码任务，可以是“给定上下文，补全下一行”或者“给定代码，判断是否有bug”。每个样本需要有明确的正确答案，这样才能计算Brier Score。
第二步：获取token级概率。大多数模型的API不会直接返回token级概率，但有些会返回logprobs。如果Jev的API支持logprobs输出，那就可以直接拿到每个位置的token概率分布。如果不支持，就需要用本地部署的版本或者通过采样来估计。
第三步：token分类和权重分配。根据任务类型定义token分类规则。代码场景下，关键字、函数名、变量名属于内容token；括号、分号、缩进属于结构token；注释中的常见词属于功能token。权重需要根据任务目标来定，如果更关注逻辑正确性，内容token的权重应该更高。
第四步：计算加权Brier Score。对每个位置，取模型预测概率和实际结果（1或0），计算Brier Score，然后按权重聚合。最终得到一个样本级的校准指标。
第五步：画校准曲线。把所有样本按置信度分桶，计算每个桶内的实际准确率，然后和平均置信度对比。理想情况下应该接近对角线。如果偏离严重，说明校准有问题。
这套流程听起来步骤不少，但实际操作中大部分工作可以脚本化。关键是要有足够的评估样本，以及一个可靠的token分类规则。
4.3 实测中容易踩的三个坑
我在类似流程中踩过几个坑，这里直接列出来，能帮你省不少时间：
坑一：把logprob当成概率。很多API返回的logprob是自然对数，需要取exp才能得到概率。这个转换看起来简单，但如果你忘了做，后续所有计算都是错的。而且logprob通常是负数，直接拿来做Brier Score会得到莫名其妙的结果。
坑二：忽略tokenization的差异。不同模型的tokenizer不一样，同一个句子在不同模型下会被切成不同数量的token。如果你用模型A的token分类规则去处理模型B的输出，分类结果会完全乱掉。做跨模型对比时，一定要用各自的tokenizer重新处理。
坑三：样本量不够就下结论。校准曲线需要足够的样本才能稳定。如果每个置信度桶里只有几个样本，曲线会剧烈波动，根本看不出真实趋势。一般来说，每个桶至少需要50-100个样本，总样本量最好在几千以上。
提示：如果评估成本太高，可以先从最关键的子任务入手。比如代码场景下，先只评估函数名预测的校准，而不是所有token。这样可以用更少的样本得到更有针对性的结论。
5. 校准之外：Jev这类模型还有哪些概率质量问题
5.1 温度参数的调节不是万能药
提到校准，很多人第一反应是调温度。温度缩放确实是最简单的校准方法：在softmax之前把logits除以一个温度参数T，T>1会让分布更平滑，T<1会让分布更尖锐。通过在一批验证数据上优化T，可以改善校准。
但温度缩放有个根本局限：它假设校准偏差是全局一致的。也就是说，它只能修正整体上的过度自信或过度保守，没法处理“某些样本过度自信、另一些样本过度保守”这种异质性问题。而大模型的校准偏差往往就是异质的：在常见模式上可能过度自信，在罕见模式上可能过度保守。
ConfTuner的Tokenized Brier Score之所以有价值，就是因为它能在更细的粒度上暴露这种异质性。你可能会发现，模型在内容token上过度自信，但在结构token上反而偏保守。这种发现是温度缩放给不了的。
5.2 采样温度和校准的纠缠
另一个容易被忽略的问题是：采样温度会直接影响校准。当你用较高的温度做采样时，模型输出的多样性增加，但每个样本的置信度会下降。这时候如果你还用默认的校准评估，会得到完全不同的结果。
实际操作中，你需要区分两个温度：训练时的温度和推理时的温度。训练时的温度影响模型学到的概率分布，推理时的温度影响你实际使用的输出。校准评估应该在你实际使用的推理温度下进行，而不是在默认温度下。
Jev的API可能允许你设置推理温度。如果你在做校准评估，建议固定一个温度，然后在这个温度下收集数据。不要在不同温度之间混用，否则校准曲线会失去意义。
5.3 多轮对话中的校准漂移
Jev在Codex中使用时，往往是多轮交互。用户给一个请求，模型生成代码，用户反馈，模型修改。这种多轮场景下，校准会发生变化。
第一轮生成时，模型基于完整的上下文做预测，校准可能还不错。但到了第二轮、第三轮，上下文里包含了模型自己之前的输出。如果之前的输出有错误，模型可能会在错误的基础上继续生成，而且置信度可能依然很高。这就是校准漂移：随着对话轮次增加，模型的置信度越来越不可靠。
处理这个问题的一个实用方法是：在每一轮都重新评估校准，而不是假设校准质量在整个对话中保持不变。如果发现某一轮之后校准明显变差，可以考虑重置上下文或者引入外部验证。
6. 从评估到落地：校准指标怎么进生产流程
6.1 把Tokenized Brier Score做成常规监控指标
校准评估不应该是一次性的。模型更新、数据分布变化、业务场景扩展，都会影响校准质量。把Tokenized Brier Score做成常规监控指标，可以及时发现校准退化。
具体做法是：每周或每月跑一批评估样本，计算Tokenized Brier Score和校准曲线。如果指标突然变差，触发告警。这个监控可以和现有的准确率监控并行，但不要混在一起看。准确率和校准是两个独立的维度，一个下降不一定导致另一个下降，反之亦然。
监控的粒度可以根据业务需求调整。如果业务对置信度特别敏感，可以按任务类型、按用户群体、按时间段分别监控。如果只是做粗粒度健康检查，一个全局指标就够了。
6.2 用校准信号驱动人机协作策略
校准指标最有价值的落地场景是人机协作。当模型置信度高且校准好时，可以放心自动化；当置信度低或校准差时，引入人工。
具体策略可以设计成三层：
- 高置信度+好校准：直接采用模型输出，不打扰用户。
- 中置信度或校准一般：给用户提供候选，让用户选择。
- 低置信度或校准差：触发人工审核，或者明确告知用户“这个结果可能不可靠”。
这套策略的关键是阈值设定。阈值不能拍脑袋，要基于校准曲线来定。比如你可以找到模型实际准确率达到90%对应的置信度区间，把这个区间的下界作为高置信度的阈值。
6.3 校准反馈闭环的搭建成本
搭建一个完整的校准反馈闭环需要投入不少资源：评估数据集的维护、token分类规则的迭代、监控管道的搭建、策略阈值的调优。对于小团队来说，一开始不需要做全套。
我的建议是分阶段来：第一阶段只做离线评估，搞清楚模型在核心任务上的校准质量。第二阶段把评估脚本化，定期跑。第三阶段才考虑接入生产流程做实时决策。每个阶段之间留出足够的时间观察效果，不要一上来就追求全自动化。
7. 一些个人体会和后续可以尝试的方向
ConfTuner这篇工作最让我欣赏的地方，是它没有试图提出一个“万能校准器”，而是老老实实地回到问题本身：语言模型的概率输出到底该怎么评估。Tokenized Brier Score不是终点，但它指出了一个正确的方向——校准需要细粒度、需要任务适配、需要和实际决策场景挂钩。
如果你正在用Jev或者类似的模型做业务，我建议至少做一件事：拿一批有标准答案的样本，画一条校准曲线。不需要复杂的工具，用Python的sklearn.calibration就能做。这条曲线会告诉你很多模型报告里不会写的东西。你可能会发现模型在某些任务上校准得很好，在另一些任务上完全不可信。这种发现比任何基准测试分数都更有指导意义。
后续可以尝试的方向有几个：一是把Tokenized Brier Score和具体的业务指标关联起来，看校准改善能不能带来业务收益；二是探索在微调阶段直接优化校准，而不是只在推理阶段做后处理；三是把校准评估扩展到多模态场景，因为图像、文本、代码的token分布差异很大，统一校准框架需要更多工作。
校准这件事，说起来枯燥，做起来琐碎，但它决定了一个模型能不能从“演示可用”走到“生产可靠”。Jev的火爆让更多人开始关注模型能力，而ConfTuner提醒我们：能力之外，还有可信度这个维度值得认真对待。
