用 LLM 进行置信度评分是个坏主意

# 向 LLM 索要置信度 来源：https://rumple.github.io/blog/2026/10/20/asking-llm-for-confidence.html 基于 LLM 的智能体能完成很多任务——或者至少，它们看起来能完成。比如，它们能写代码、总结论文、规划行程、填写表单。如果你向它索要一个概率或置信度分数，它也会给你一个。我见过很多智能体设计师用这种方式让 LLM 生成置信度分数。问题在于，我们没有任何充分的理由去信任这个数字。这篇文章要讲的就是为什么我们不能依赖 LLM 来生成置信度分数。 ## 置信度的含义 在理解为什么 LLM 无法给出可信的置信度分数之前，我们需要先弄清楚置信度到底是什么。 举个例子，想象一位天气预报员说："我有 70% 的把握明天会下雨。" 预报员在预测明天会下雨。70% 是他对这个预测的确信程度。明天要么下雨，要么不下雨，而他今天的确信程度取决于他所掌握的信息。 他的置信度来源于他所使用的信息。其中一些是关于明天的：气压、湿度、风向，以及雷达上的云图。另一些来自过去：多年的气象记录，以及在过去看起来和今天类似的日子里下雨的频率。他拥有的信息越多，信息指向某一方向的趋势越强，他的置信度就能越接近 100% 或 0%。 从理论上说，将这些信息转化为置信度是一个计算过程，而非主观意见。假设这个计算过程可以用一条假想的规则来表示：你从历史信息出发，再用关于明天的信息来更新它。如果两位预报员拥有完全相同的信息，并且都正确地运用了这条规则，他们必然得出完全相同的置信度。预报员之间出现分歧，要么是因为他们掌握的信息不同，要么是因为其中一位错误地运用了规则。 现在假设预报员被问到两周之后的天气。他对那一天还毫无信息，唯一的依据就是过去。假设在一年中的这个时段，大约 30% 的日子会下雨。那么他能说的最好的话就是："我有 30% 的把握会下雨。"随着那一天越来越近，他会获得更多信息，置信度也会随之向 100% 或 0% 移动。 ## 如何衡量置信度分数的准确性 既然我们知道了置信度的含义，接下来看看如何判断一个置信度分数是否准确。 单靠一天无法判断预报员说的 70% 是否正确，因为那一天要么下雨，要么不下。我们只能在很多天的数据上检验他的置信度。 把预报员说"70% 把握下雨"的所有日子拿出来。如果其中大约 70% 的日子确实下雨了，那他的 70% 是准确的。如果其中只有 40% 的日子下雨了，说明他过于自信。如果其中 90% 的日子下雨了，说明他信心不足。对每一个置信度等级都可以做同样的检验。假设这是一年的记录： | 他给出的把握 | 天数 | 下雨天数 | 实际比例 | |---|---|---|---| | 10% | 120 | 13 | 11% | | 30% | 90 | 26 | 29% | | 70% | 80 | 57 | 71% | | 90% | 75 | 67 | 89% | 在每个等级上，实际下雨率都接近他给出的数值。当置信度与实际频率像这样吻合时，就叫做*校准良好*（calibrated）。这也是我们了解预报员是否遵循规则的方式。 但仅有校准还不够。一个忽略明天的天气、始终说 30%（该季节的通常比率）的预报员，同样是校准的。在一年的时间里，他所说的 30% 的日子里确实大约有 30% 下了雨。但他从不利用关于明天的信息，所以他的置信度实际上什么也没告诉我们。上表中的预报员更好，因为他的大多数预测日都靠近 10% 或 90%。他利用了信息，同时仍然保持了校准。 还有一个条件容易被忽视：要做上述这一切，必须有人把每一次预报和实际发生的情况都记录下来。没有这份记录，就无从得知一个置信度分数是否准确。 因此，一个你能够信赖的置信度分数需要具备两个条件： 1. 它反映的是预测所依据的信息量。 2. 它已在同类问题上，针对实际结果做过检验。 ## LLM 如何给出置信度分数 LLM 逐个 token 地生成文本。每个 token 都基于其前面的 token 来选择。这就是"自回归"（autoregressive）的含义。例如，当你问"你有多确定？"时，"0.85"这个回答并不是从模型内部的某个仪表上读取的。模型像写其他任何文本一样，一个 token 接一个 token 地把它写出来。"0.85"只是对话的一个合理续写，并不是对任何事物的测量。 用上一节的术语来说，这个数字两项属性都不具备。它不反映模型掌握了多大的信息量，因为它是文本的续写，而非对证据的总结。它也从未被校准过。预训练确实会用结果来评判模型，但那个结果是下一个 token。所以模型在"接下来是什么文本？"这个问题上有一定程度的校准。但它从未在"它写出的置信度是否与其正确率相符"上被评判过。模型学到的是置信度分数在文本中长什么样，而不是让自己的分数与实际准确率匹配。 这带来了一些你可以亲自验证的后果： - **再问一次，数字就变了。**比如，同一个问题可能这次得到 0.85，下次得到 0.7。信息并没有变化，所以如果模型是在应用一条规则，置信度也不应该变。 - **换了措辞，数字就变了。**比如，如果你问"你确定吗？"，分数通常会变化，即使问题本身没有任何改变。不同的措辞并不是新的信息。 - **数字前面的文本决定了这个数字。**比如，如果模型已经写出了"这显然是正确的答案"，那么一个高分就是自然的延续。分数来自前面的文字，而非来自证据。 模型总会给你一个数字，看起来很精确。而且，就像我上一篇文章（https://rumple.github.io/blog/2026/10/14/tool-or-automation.html）中关于论文总结的情况一样，一个错误的数字看起来和正确的数字没什么两样。你只有将大量的数字与标准答案对照打分，才能弄清楚这些数字是否可信。而大多数向 LLM 索要置信度分数的人并没有这样做。 ## 不依赖 LLM 如何测量置信度 如果我们不能向 LLM 索要置信度，那它从哪里来？我们可以像预报员那样做：构建一条将信息转化为置信度的规则，并不断用实际结果来检验它。LLM 仍然可以执行任务，比如撰写回答。但置信度分数来自规则，而非 LLM。 举个例子，想象一个通过搜索帮助中心来回答客服问题并撰写回复的智能体。我们希望为每条回复给出一个置信度分数，以便让不确定的回复在发送之前先经过人工审核。 **第一步：选择信息。**列出我们可以观察到的关于每条回复的各种事实，而不必询问 LLM 的"感觉"。搜索是否找到了与该主题相关的文章？找到了几篇？这类问题之前是否被该智能体回答过？如果向智能体提同一个问题两次，两个回答是否一致？这就是智能体版本的气压、湿度和风向。 **第二步：从过去开始。**在我们拥有任何其他数据之前，最好的置信度就是通常的比率，正如两周后的预报一样。如果有人检查了过去 200 条回复，其中 150 条是正确的，那么每条回复的初始置信度就设为 75%。 **第三步：记录每条回复及其结果。**对于每条回复，保存第一步中收集的信息、规则给出的置信度，以及这条回复最终是否正确。如果审核人员批准了这条回复，或者客户没有再次追问，就算正确。这就是前面各节所说的我们所需要的记录。 **第四步：根据记录更新规则。**将过去的回复按其信息特征分组，看看每个组中正确的频率。如果有匹配文章且两个回答一致的回复有 95% 是正确的，那么规则对下一条类似回复就应该给出 95%。如果没有匹配文章的回复只有 40% 是正确的，规则就应该给出 40%。一开始，各组数据较少，规则比较粗糙。随着数据增多，各组变得更充实，规则也能利用更多的信息。 **第五步：持续检验。**每隔一周左右，制作一张和之前为预报员制作的同样的表格：在每个置信度等级上，回复正确的频率是多少？如果标注 90% 的回复实际上只有 70% 是正确的，说明规则过于自信，而新增的记录会告诉我们如何修正它。 这样的规则具备了 LLM 给出的数字所不具备的那些属性。相同的信息总是给出相同的置信度。置信度取决于信息，而非措辞。并且它是基于我们自己的问题类型校准过的，因为它是从我们自己的记录中构建出来的。它还会随着使用而变得更好，因为每条回复都在丰富记录。 不过，规则的好坏取决于记录的质量。如果没有人检查回复是否正确，那就没有东西可供学习，我们又回到了一个没有经过任何测量的数字。