NeurIPS'25 | ConfTuner 教 LLM 说真话的置信度，也照出了 Jev 的校准短板
NeurIPS’25 | ConfTuner 教 LLM 说真话的置信度，也照出了 Jev 的校准短板
原文：ConfTuner: Training Large Language Models to Express Their Confidence Verbally
1. 一个只回答”是”或”否”的模型，为什么还需要”校准”
上周刷到 TypeSafe 发布 Jev 的消息，卖点很简单粗暴：这是一个专门做决策的模型，不写文章、不聊天，只回答”选 A 还是选 B”、”打几分”、”是不是”这三类问题,而且每个答案都带一个概率。官网首页的对比图很直白——同一个分类任务，普通 LLM 跑 8.566 秒,Jev 跑 0.114 秒,标题写着”193.6x Faster, 444.6x Cheaper”。
这类”给个概率”的设计不新鲜。真正的问题是:这个概率能信吗?
这也是 ConfTuner 这篇 NeurIPS’25 论文在死磕的事。它研究的场景更朴素:让一个普通的对话 LLM,在回答问题的同时,老老实实吐出一个”置信度: 80%”这样的数字,而且这个 80% 得是真的 80%——如果模型说了 100 次”置信度 80%”,这 100 次里差不多得对 80 次。这种直接用自然语言表达出来的置信度,论文里叫 verbalized confidence(语言化置信度),区别于模型内部 softmax 算出来但从来不说出口的那个数值概率。
Jev 号称”零幻觉”、每个决策都带”calibrated confidence”(校准置信度)。ConfTuner 恰好告诉我们,做到这件事有多难,以及现在的方法在哪些地方还差得远。这篇文章想把两者放在一起看:一个是学术界怎么把生成式 LLM 的嘴里话调准,一个是工业界怎么干脆换一套不说话的模型来绕开这个问题——但绕得干净吗?
2. 校准置信度的两条老路,都在用错误的东西打分
在 ConfTuner 之前,已经有工作在做同一件事,但走的是一条弯路。
最直接的思路是监督微调:构造一批”问题 + 答案 + 置信度”的样本,让模型学着模仿。但置信度标签从哪来?没有人能给每道题标一个”这道题客观上应该有多大把握”的真值,只能用代理指标去凑——比如用模型自己回答同一题目多次的答案一致率当置信度(一致率高就打个高置信度标签),或者用另一个模型给答案打分当置信度。论文里提到的 SaySelf、LACIE 就是这类方法的代表。
问题是,这些代理指标本身就不准。一致率高可能只是因为模型对错误答案也很固执地重复,而不是因为它真的更有把握。用不准的代理标签去监督训练,模型学到的是”怎么让代理指标好看”,不是”怎么让置信度真的可信”。这是这条路线绕不开的天花板。
另一条路是完全不训练,靠模型自身的输出概率(logits)推置信度,或者多次采样做 ensemble(集成多个回答再投票)。这条路不需要标注,但ensemble 要跑多次推理,推理成本直接翻几倍;单次 logits 的方式,论文的实验结果(下面会看到)也证明它并不比什么都不做好多少。
ConfTuner 换了个更直接的思路:不用代理标签,直接用题目本身的对错(0/1)去监督置信度。答对了,置信度就该往高走;答错了,就该往低走。听起来是句大白话,但要把”对错”这个离散的 0/1 信号,变成一个能梯度下降的损失函数,需要一个新的数学工具——这就是论文提出的 tokenized Brier score(token 化的 Brier 分数)。
3. 把”置信度”当成一个词表上的 token,用 Brier score 校准它
先说清楚 ConfTuner 具体在干什么。它是一个两阶段的 LoRA 微调方法,流程如下图:
输入格式是一句自然语言指令,类似”请提供你的答案和置信度(0%-100%),问题是:1051 是否大于 1039+15?”,模型正常生成文本,直到生成到”Confidence:”这个位置。
第一阶段要解决的问题是:模型接下来要生成的置信度是一个 0~100 之间的整数,但语言模型的 vocabulary(词表)里,数字是当成普通 token 处理的,直接对某一个 token 做优化没法把”90%”和”91%”这种大小关系带进损失函数里。ConfTuner 的做法是:取出词表里对应”0”到”100”这 101 个数字 token 的 logits,做一次 softmax,得到一个长度为 101 的概率分布 $q = (q_0, q_1, …, q_{100})$——这个分布可以理解成模型对”置信度应该是几”这件事自己内心的完整概率分布,而不只是它最终吐出来的那一个数字。
第二阶段才是校准发生的地方。设真实的对错标签是 $y \in {0, 1}$(答对为 1,答错为 0),论文把 $y$ 映射成一个只在 100(对应”置信度=100%”)或 0(对应”置信度=0%”)处为 1 的 one-hot 分布,然后用这个 one-hot 分布和模型预测的 $q$ 之间的Brier score(经典的概率校准评分,对每一类的差值取平方再求和)做损失函数去微调模型:
\[\mathcal{L} = \sum_{i=0}^{100} (q_i - \mathbb{1}[i = 100y])^2\]论文的 Theorem 1 证明了这个损失是一个proper scoring rule for verbalized confidence(语言化置信度下的”正当评分规则”)——proper scoring rule 是概率校准理论里的一个经典要求,通俗地说就是:要让这个损失函数的最优解恰好等于真实的对错概率,不能让模型靠”耍滑头”(比如无论对错都固定报一个中间值)拿到比说真话更低的损失。有了这条数学保证,微调才不会把模型往”说谎但损失更低”的方向带偏。
微调本身用 LoRA,rank=8、alpha=32,只挂在 Q/V 投影矩阵上,训练数据只用了 HotpotQA 的 2000 条样本,单次采样(不需要像 SaySelf 那样为每条样本采样几十次去凑代理标签)。这也是论文效率数据里最扎眼的一条:
ConfTuner 训练只要 4 分钟、推理 1 分钟,而 SaySelf 训练用了 120 分钟、总训练数据量因为要多次采样滚到了 900 万条。少标注、少采样,是因为它没有绕着代理指标打转,直接拿现成的对错标签当监督信号——这条设计选择比模型结构本身更值得记一笔。
4. 实验数字:同分布内校准提升明显,跨分布迁移打了折扣
ECE(Expected Calibration Error,期望校准误差)是这篇论文的主要指标,算的是”模型说的置信度”和”实际正确率”之间的平均偏差,越低越好。另一个指标 AUROC 衡量置信度能不能把对的答案和错的答案排序区分开,越高越好。
在训练用的 HotpotQA(同分布测试集)上,ConfTuner 在三个不同的 LLM(LLaMA、Qwen、Ministral)上都把 ECE 打到了明显更低的水平——比如 LLaMA 上从 Base 的 0.4803 降到 0.0405,这是本文开头那种”置信度基本可信”的效果:
但把同一批模型直接搬到没训练过的 GSM8K、TriviaQA、StrategyQA、TruthfulQA 这几个 OOD(out-of-distribution,分布外)数据集上,ECE 的提升幅度就没那么夸张了——Qwen 上的 Average ECE 从 Base 的 0.3781 降到 0.2872,比 HotpotQA 上从 0.6312 降到 0.4212 那种量级的改善温和得多。AUROC 的表现类似:
这里要老实说一句:ConfTuner 教会的不是”通用的说真话能力”,更像是”在训练分布附近,把嘴里的数字和内心的把握对齐”。跨分布迁移能打个折扣,但没有失效——这本身也符合直觉,毕竟监督信号(题目对错)天然是任务相关的。
论文还测了一个更实用的场景:置信度能不能帮模型自我修正。让模型看到自己给出的答案和置信度,再给一次机会修改,ConfTuner 在 HotpotQA 上把正确率变化率从 Base 的 -1.2% 拉到 +3.5%,意味着低置信度确实能提示模型”这题我该重新想想”,而不是提示了也没用:
5. Jev:一个不生成文本、只吐类型化答案的”System One”模型
回到开头的 Jev。它 2026 年 9 月 15 日由 TypeSafe 发布,自称是”the first System One model”——这个命名借用了 Kahneman(丹尼尔·卡尼曼)”系统一/系统二”的说法:系统一负责快速、直觉式的判断,系统二负责慢速、深思熟虑的推理。TypeSafe 把现在主流的 GPT/Claude/Gemini 这类会一步步想、写长文本的模型归为”System Two”,而 Jev 定位成反过来的东西——它不生成任何自由文本,只回答开发者预先定义好类型的问题,并且每个答案自带一个概率。
具体来说,TypeSafe 的文档里定义了三种问题类型(primitive,可以理解成 Jev 唯一能”说”的三种话):
- Choice:从一组预定义选项里选一个,返回被选中的选项、每个选项的概率、以及一个整体置信度
- Score:按一组有序的描述性等级打分,返回分数、每个等级的概率分布、置信度
- Noul:回答一个是非问题,返回”是”的概率
这三种类型的答案都是结构化的、可被程序直接读取的字段,不是需要再解析的自然语言——TypeSafe 自己的表述是”Decisions, not strings”(决策,而不是字符串)。
6. 训练方法叫 RLCD,目标从”讨人喜欢”换成了”数字要对得上”
Jev 的训练方法被称为 RLCD(Reinforcement Learning for Calibrated Decisions,面向校准决策的强化学习),TypeSafe 的文档把它和另外两种大家更熟悉的强化学习方法放在一起对比:
- RLHF(基于人类反馈的强化学习)训练模型”说出人们更喜欢的回答”,这是 ChatGPT 之类聊天模型的核心训练方式,但它优化的信号是”读起来舒不舒服”,不是”内容对不对”——文档直接点名这是”confident-sounding hallucinations”(听起来很有把握的幻觉)的来源之一。
- RLVR(可验证奖励强化学习)训练出像 DeepSeek-R1 这类擅长数学、代码的推理模型,但代价是生成更长、更慢、更贵的思维链。
- RLCD 换了个目标:不追求”读起来讨人喜欢”或者”推理链条完整”,只要求”模型给出的概率,长期来看要和真实发生的频率对上”——文档举的例子是,如果一批决策模型都标了 0.2 的概率,这些事情实际发生的比例得接近 20%。这正好是 ECE 想衡量的同一件事:概率数字是不是可信。
这里能看出 Jev 和 ConfTuner 其实在同一个目标上使力,只是走的是两条完全不同的路。ConfTuner 是在一个已经会自由生成文本的 LLM 上后训练,让它在保留说话能力的前提下把嘴里报的置信度调准;RLCD 训练的 Jev 从一开始就没有”自由说话”这个负担,它的整个输出空间被限制成有限的类型化答案,校准问题在设计上就被大幅收窄了——这也是它敢说”从不产生幻觉”的底气所在,但下一节会看到,这句话没有那么绝对。
至于 RLCD 训练用的数据具体怎么构造,TypeSafe 目前公开的文档没有给出细节(不像 ConfTuner 论文把 HotpotQA、2000 条样本、单次采样这些数字都摆出来),这是目前能查到的信息里的一个空白,只能标注为”未披露”而不是替它补全。
7. 255 个选项怎么塞进一次前向传播,超限之后靠链式收窄
用户最关心的问题往往是:Choice 类型最多支持 255 个选项,这个数字从哪来,选项一多是不是就顶不住了?
TypeSafe 文档里对这一点说得很直接:“A Choice question accepts up to 255 options, and adding options costs a few tokens each”——每加一个选项,只是多花几个 token 的输入成本,不是让模型多想一步。255 这个数字大概率是工程上的一个方便边界(正好是一个字节能表示的范围),不是什么算法极限。
真正有意思的是超过 255 个选项怎么办。文档给出的方案不是让模型一次性在几千个选项里做绝对判断,而是“chain Choice questions level by level”(把 Choice 问题按层级串起来),并且提到可以做”a beam search over Choice probabilities, keeping the best K candidate paths at each level”——也就是把一次性的超大规模选择,拆成多层小规模 Choice,每层只从概率最高的 K 个候选里往下走,而不是一条路走到底的贪心搜索。这本质上是把”分类问题”变成了”树状检索问题”:先分大类,再分子类,一层一层收窄到最终答案。文档给的例子集中在工单分类、产品分类这类天然带层级结构的场景,契合这套”链式 Choice”的设计。
这条链式方案在 TypeSafe 自己的文档里写得比较正式;另外能查到的一些第三方报道还提到过”先粗筛再精选”的两阶段做法(比如先用打分筛出一批候选,再对候选做精确选择),这类描述目前没有在 TypeSafe 的主文档原文里直接对上,更像是开发者根据链式 Choice 思路摸索出的应用套路,这里就不当作官方规范来写了,只提一句作为参考。
8. “并行采样”拆开看:靠的不是新架构,是输出格式本身就没有自回归的必要
这是这篇文章最该讲清楚的一点。Jev 宣传的核心速度优势叫”parallel sampling”——同一个 state(可以理解成一次调用里共享的上下文/输入)下,可以同时问多个 Choice/Score/Noul 问题,官方文档给的数字是,把 13 个问题打包成一次调用,比拆成 13 次单独调用“is 12.2x cheaper and 10.0x faster with no change in answers”。文档管这种用法叫”Ask independent questions together”——比如同时问”是否申请了退款”“证据是否显示重复扣款”“政策是否支持退款”这三件独立的事,一次调用全部拿到答案。
那这背后靠的是什么新技术?独立开发者 Sean Goedecke 写了两篇分析文章,拆得比营销页面清楚得多。核心判断是:“I suspect Jev does not have a substantial technical moat, and their claimed ‘Reinforcement Learning for Calibrated Decisions’ is not a brand-new scaling axis. It will probably be pretty easy for any other lab to replicate, or for individual programmers to retrofit existing open-source LLMs into a fast Jev-like model.”——他认为 RLCD 不是什么全新的能力维度,别的团队或者个人开发者用现成的开源模型改一改就能做出类似效果。
他给出的具体实现思路是:“prefill the response with "choice": " and generate one token, restricted to the user-provided choices”——把回答的开头直接预填好(比如 JSON 里 "choice": " 这几个字符),模型只需要在这个前缀之后生成一个 token,并且把候选范围限制在用户给的选项集合里(这就是常见的 constrained decoding,约束解码)。因为需要生成的只有一个 token,而不是一整句自然语言答案,所以”多问几个问题几乎不增加耗时”这件事就自然成立了——耗时的大头本来就是自回归时逐 token 展开的那部分,一旦答案被压缩成一个受限的 token,多问几个独立问题只是多做几次这种”准 O(1)”的调用,而不是要模型多写几百字。他自己用 Qwen2.5-1.5B-Instruct 复现,拿到了”2x-3x speedup”。
所以”并行采样”更准确的说法是:它不是在物理上同时做了多个 forward pass,而是把每个问题的答案空间压缩到几乎不需要自回归展开的程度,再借助 batch 推理把多个这样的轻量请求合并处理——这套组合下来,时延确实能压到 70~500ms 这个区间,和普通 LLM 跑一整段文本生成完全不是一个量级,但支撑它的是”输出格式足够窄”这个工程选择,不是某种全新的模型架构突破。下图直观对比了两种范式的差异:
这也解释了 Jev “Zero Hallucinations”(零幻觉)这句宣传语该怎么理解。Sean Goedecke 对这句话的评价是:“this seems like a semantic dodge, since Jev can absolutely still pick the wrong choice”——这是一种文字游戏,因为 Jev 完全可能选错选项,只是”选错”不再被叫作”幻觉”。确实,如果输出空间被限制在预定义的选项集合里,模型就不可能编造一个不存在的选项出来,这消灭的是”编造”这一类错误;但选项集合本身覆盖不到的情况、或者集合里选错了正确答案,这类错误依然存在,只是换了个名字。
9. 小结
把 ConfTuner 和 Jev 放在一起看,能看清一件事:”让模型的概率数字可信”这个目标,现在有两条并行的实现路径,谁都没有完全解决问题。
ConfTuner 选的是”改造现有生成式 LLM”这条路,代价是只用 2000 条数据、4 分钟训练就能在同分布上把 ECE 打下来一大截,但换到没训练过的分布,提升幅度明显收窄——校准这件事目前看还是偏”任务相关”,而不是一种能直接迁移到任何新场景的通用能力。
Jev 选的是”从一开始就不让模型自由说话”这条路,把输出收窄成 Choice/Score/Noul 三种类型化问题,配合 RLCD 训练去对齐概率和真实频率,顺带靠”答案被压缩成受限的一两个 token”拿到了数量级的速度提升。但拆开看,”并行采样”背后没有神秘的新架构,”零幻觉”消灭的也只是编造不存在选项这一类特定错误——选错依然会发生,只是不再叫幻觉。至于超过 255 个选项之后怎么办,目前官方给出的答案是链式 Choice + beam search,而不是单次前向就能兜住任意规模的选择问题。
两边都在往”可信的概率”这个方向努力,一边在补生成式模型的短板,一边在用收窄输出空间的方式规避短板——这大概也是判断这类”校准”、”零幻觉”宣传语时,值得多留一个心眼的地方:先看清楚它解决的是哪种错误,再决定要不要为另一种错误买单。
顺带扯一句题外话。ConfTuner 里”用 LoRA 做轻量微调解决一个具体的能力短板”这个思路,和《动手学 AutoML:从 NAS 到大语言模型优化实战》里讲 LLM 压缩、模型融合的章节角度不太一样——那本书更关注的是怎么用搜索的方式自动找到压缩和融合方案,而不是像 ConfTuner 这样针对单一目标(置信度校准)设计一个新损失函数去微调。两者算是”话题相邻”:都是在预训练模型之上做增量式的能力改造,只是一个靠自动化搜索,一个靠手工设计的评分规则,角度不同但目标相近,感兴趣的话可以对照着翻一翻。
