LLM 置信度分数：信任之前先校准

LLM 置信度分数只有在你明确它预测的内容、固定测量协议，并使用来自自身任务的带标签结果进行测试后才有用。模型自报的“90%”、token log probability，以及十次采样中有九次答案一致，是三种不同的信号。它们都无法为你提供一个答案正确的通用 0.9 概率。

适用读者： 中级读者——需要让 LLM 回答、升级处理或拒答的产品工程师、数据团队和技术负责人。

将原始数值视为特征，而不是决策依据。在留出集上对其进行校准，检查当你拒绝低分答案时错误率如何变化，并为任何可能转移资金、暴露数据或改变生产状态的操作设置确定性控制。

LLM 置信度分数衡量什么？

LLM 置信度分数是一种数值信号，用于对模型输出的可靠性进行排序或估计。它的含义取决于生成方式。

如果一个分数要表现得像经过校准的概率，那么被赋予 0.8 分的输出，在同类任务中应当约有 80% 的概率正确。这一说法需要明确四个细节：

缺少其中任何一个细节，“0.8 置信度”就会变得含义不明。它可能表示模型认为某种措辞很可能出现、模型多次给出了相同答案、模型遵循指令输出了一个数字，或者模型将某个答案排在其他选项之上。这些属性可能与正确性相关，但它们本身并不等于正确性。

校准也不同于区分能力。当正确答案通常排在错误答案之前时，分数具有良好的区分能力。当数值与观察到的频率相匹配时，分数具有良好的校准性。一个系统可以很适合排序，但其百分比是错误的；也可以在平均意义上校准合理，却无法有效区分正确答案和错误答案。

通常被称为置信度的三种信号

在这些方法之间进行选择是一项工程决策。组合使用可能有所帮助，但集成方法仍然需要在目标任务上进行评估。

语言化置信度是通过提示引出的答案

最简单的方法是询问：

text Return your answer and the probability that it is correct from 0 to 1.

这几乎适用于任何模型，但也意味着置信度值本身成为生成内容的一部分。prompt 措辞、响应尺度、提供的上下文，以及答案是否由模型自行生成，都可能改变结果。

一项发表于 2026 年的研究，在四个问答基准上测试了三个开放的 7–8B 基础模型/指令微调模型系列。研究人员固定语言化置信度 prompt，同时改变被评分的答案、用于提供 token 分数的答案 token，以及这些 token 之前的上下文。改变条件上下文对语言化置信度与 token 校准比较的影响，大于改变校准估计器的影响；在 12 个指令微调设置中，无论使用 ECE 还是 Brier 分数进行比较，这一变化都在 9 个设置中改变了看起来更优的信号。当模型对给定答案进行评分时，合理但错误的答案获得的语言化置信度几乎与给定的正确答案相同。因此，作者将这两种信号都描述为依赖协议的行为测量，而不是不确定性的直接读数（Kim and Kang, 2026）。

这一结果并不能证明所有语言化分数都没有用。它说明，像“请诚实地表达你的置信度”这样的 prompt，不能替代校准集。

Token logprobs 衡量下一个 token 的似然

log probability 记录的是：在模型的条件生成分布下，某个 token 出现的可能性。OpenAI 文档将其定义为：给定前置上下文后，某个位置上的 token 的概率；序列 log probabilities 可以求和，用于评分或排序（OpenAI Cookbook）。当所选 API 和模型支持时，Google 的 GenerateContent 响应同样会提供候选答案的平均 log probabilities 以及 token 级别的 logprob 结果（Gemini API reference）。

对于 `approve` 与 `reject` 这样的封闭式选择，这一信号很有价值。你可以收集分配给允许标签的概率质量，然后对该分数进行校准。但对于较长的自由文本答案，解释起来就困难得多。分词方式、答案长度、改写方式以及条件 prompt 都会影响序列似然。

流畅的错误陈述可能具有很高的似然。正确但不常见的名称可能具有较低的似然。这个分数回答的是“在这里，这个 token 序列有多符合预期？”它不会自动回答“这个主张是真的吗？”

重复采样衡量一致性

多次采样模型可以得到一种黑盒一致性信号。如果十次响应中有八次表达了相同答案，那么经验一致性分数就是 0.8。自由文本响应通常需要进行语义聚类，以便将改写视为同一个答案。

这一信号通常比单次自报更有信息量，但也有两个成本。第一，在批处理、缓存或缩短 prompt 改变计算方式之前，十次生成的输出调用成本大致是单次调用的十倍。第二，当模型重复同一个误解时，一致性也可能是自信地错误。

近期研究清楚地展示了这两点。一篇发表于 2026 年 7 月的论文，在简短事实问答和多跳问答上比较了语言化置信度、基于 logit 的验证器，以及一种名为 SliCK 的基于采样的方法。在该设置中，SliCK 的校准误差更低，并且在正确与错误答案的排序方面优于另外两种方法。但在评估案例中，它仍有 31% 未通过基于蕴含的概率一致性测试。该研究依赖 LLM 评审者进行语义聚类，使用简短答案基准、一个主要模型加上较小规模的跨模型子集，并假设采样频率能够反映信念（Matta, Naphade, and Zou, 2026）。

实际解读应比“采样解决了置信度问题”更谨慎。一致性是有用的原始信号，但仍然必须根据结果进行检查。

*生产环境中的阈值应建立在任务特定的标签和校准检查之后，而不是直接建立在模型输出之后。*

为什么看似合理的置信度数字仍可能误导

以下三项近期研究结果，应当改变团队阅读 LLM 答案旁百分比数字的方式。

准确率和校准性可能分别变化

ConfidenceBench 在 200 道私有英文选择题上，评估了 15 个前沿模型通过 prompt 生成的概率，题目涵盖空间推理、高精度数学、词语查找和不可知问题。每个模型对该题集回答三次。该基准使用 Brier 分数，即惩罚报告概率与二元结果之间平方距离的指标。

模型按校准性排序的结果，并不简单地重复其按准确率排序的结果。作者报告的最佳 Brier 分数为 0.103，而部分被评估系统的得分甚至差于经过校准的四选一随机基线 0.1875。该基准规模刻意较小、数据私有、仅使用英文和选择题。其语言化分数可能反映指令遵循能力和 prompt 框架，因此不应推广到长文本或多轮任务（ffrench-Constant et al., 2026）。

应直接测量校准性。不要从模型的整体基准准确率推断校准性。

测量协议可能改变结论

分数属于特定的流水线。如果团队更改 prompt、模型快照、答案格式、候选标签、上下文窗口、temperature 或 logprob 聚合方式，那么它就改变了测量工具。

每次评估结果都应记录这些选择。原始的 code-agent activity metrics 也需要系统和评估上下文，之后才能说明可靠性。如果 prompt 或模型发生变化，重新校准是发布检查的一部分，而不是可有可无的清理工作。

经过校准的分数仍可能在某个切片上失败

平均值可能掩盖某种语言、产品、客户群体、文档类型或答案长度上的失败。一个支持分类器可能因为常见的账单问题占据测试集大多数而整体看起来校准良好，但罕见的安全工单仍然过度自信。

始终检查拥有足够样本、能够支持结论的切片。当样本稀疏时，应报告不确定性，而不是把噪声很大的比率当作事实。

可复现的 LLM 置信度校准工作流

下面的工作流刻意保持简洁。在采用更大的不确定性框架之前，可以先运行它。

1. 定义事件和操作

用一句话完成以下模板：

示例：

避免使用“答案很好”之类的事件。这类事件无法被一致地标注。

对于具有不可逆影响的操作，置信度不能替代授权。模型可以帮助选择路径，但 AI agent permissions 仍应强制执行允许的资源、参数、审批规则和凭证。

2. 构建任务特定的留出集

收集具有代表性的输入，这些输入不曾用于调整 prompt 或校准映射。应包括：

在可能的情况下，使用确定性验证器标注正确性。对于主观任务，应使用书面评分标准和裁决流程。置信度分数的可辩护程度，不可能高于其结果标签的可辩护程度。

先使用足够的数据来发现明显的校准失误，然后围绕重要切片和阈值扩展数据。小型基准可以指导探索，但不能为高风险生产阈值提供充分依据。

3. 在不改变协议的情况下捕获原始信号

存储以下信息：

评估前不要进行四舍五入。如果模型只输出 `0.7`、`0.8` 和 `0.9`，就应将其作为三个粗粒度桶进行评估，而不是将其呈现为精确的概率测量。

4. 计算 Brier 分数和可靠性表

对于二元正确性，Brier 分数为：

text mean((confidence - outcome)²)

数值越低越好，但该数字需要基线和可比数据集。可靠性表可以让误差更容易观察：将相近的分数分组，然后比较每组的平均分数与观察到的准确率。

下面这个不依赖第三方库的 Python 脚本从 CSV 文件中读取 `id,score,correct`：

python import csv

with open("predictions.csv", newline="") as source: rows = [ (float(row["score"]), int(row["correct"])) for row in csv.DictReader(source) ]

if not rows: raise SystemExit("predictions.csv has no rows")

brier = sum((score - correct) ** 2 for score, correct in rows) / len(rows) print(f"Brier score: {brier:.4f}")

bin_count = 10 bins = [[] for _ in range(bin_count)]

for score, correct in rows: if not 0 <= score <= 1 or correct not in (0, 1): raise ValueError("score must be 0..1 and correct must be 0 or 1") index = min(int(score * bin_count), bin_count - 1) bins[index].append((score, correct))

print("range,count,mean_score,accuracy,gap") for index, values in enumerate(bins): if not values: continue mean_score = sum(score for score, _ in values) / len(values) accuracy = sum(correct for _, correct in values) / len(values) lower = index / bin_count upper = (index + 1) / bin_count print( f"{lower:.1f}-{upper:.1f},{len(values)}," f"{mean_score:.3f},{accuracy:.3f},{mean_score - accuracy:+.3f}" )

该表是描述性的。分桶边界可能改变 ECE 风格的汇总结果，尤其是在小数据集上。应将 Brier 分数、可靠性视图和面向操作的指标结合使用，而不是只优化其中一张图表。

5. 根据风险和覆盖率选择阈值

0.8 的阈值没有通用含义。评估系统仅接受分数达到或超过每个候选阈值的输出时会发生什么：

python print("threshold,coverage,accepted_accuracy") for threshold in (0.5, 0.6, 0.7, 0.8, 0.9): accepted = [ correct for score, correct in rows if score >= threshold ] coverage = len(accepted) / len(rows) accuracy = sum(accepted) / len(accepted) if accepted else float("nan") print(f"{threshold:.1f},{coverage:.3f},{accuracy:.3f}")

这会生成一个基础的风险—覆盖率视图。提高阈值可能降低已接受案例中的错误率，但也会将更多工作交给后备处理流程。应根据错误接受、错误拒绝、审核、延迟和用户伤害的成本来选择阈值。

当产品支持时，至少使用三种结果：

6. 测试漂移和协议变化

在以下情况下运行留出集：

重复采样和更深层的推理也会增加计算量。应将这一权衡纳入评估：比较错误减少量与延迟和 token 成本，而不是假设 more reasoning tokens 总是值得购买。

应该使用哪种置信度方法？

开源库可以减少实现工作。例如，UQLM 提供黑盒一致性、白盒 token 概率、评审者、集成和长文本评分器。其文档也明确说明了延迟和访问权限方面的权衡：一致性方法需要更多调用，而白盒方法需要 logprobs（UQLM documentation）。该仓库在 2026 年 7 月仍持续发布版本，包括 v0.6.4 修复；相比仅看累计 stars，这是一项更有力的维护信号（UQLM v0.6.4）。

库可以提供估计器，但无法提供标签、任务定义、风险容忍度或生产监控；而这些才是让阈值具备可辩护性的要素。

当前研究尚未证明什么

引用的研究并未证明某一种方法在所有 LLM 应用中都胜出。

研究可以识别候选信号。应在系统实际要执行的工作上验证完整系统。

常见问题

LLM 置信度分数准确吗？

有时它们与正确性相关，但准确性取决于模型、任务、评分方法、prompt 和评估分布。将未经校准的分数视为排序特征。在把它解释为概率之前，先使用带标签的结果进行测试。

Token logprobs 等同于置信度吗？

不等同。Token logprob 是给定上下文时某个 token 的条件似然。它可以支持置信度估计，尤其适用于封闭标签任务，但它并不自动表示自由文本答案在事实上的正确概率。

应该使用什么 LLM 置信度阈值？

不存在通用阈值。应根据留出集上的风险—覆盖率分析来选择阈值，并反映错误接受、人工审核、拒答和错失自动化机会的成本。在模型、prompt 或数据分布发生变化后，应重新验证该阈值。

主张核查

来源