Using LLM for confidence scoring is a bad idea（用 LLM 自评置信度是个坏主意）

📅 2026-10-20 | 🏷️ 安全 & 评测 | ⭐ HN 202分/99评论
🔗 原文：https://rumple.github.io/blog/2026/10/20/asking-llm-for-confidence.html
💬 HN 讨论：https://news.ycombinator.com/item?id=50176082

是什么

一篇在 HN 引发广泛共鸣（202 分 / 99 评论）的技术博客，核心论点直白：直接让 LLM 给自己输出的结果打"置信度分"，是个坏主意。模型口头报告的"我 90% 确定"并不是统计学意义上的概率，把它当作自动化流程里的质量门槛或路由信号，会在最关键的环节埋雷。

🔍 小白解读

先说几个词

• 置信度（Confidence）：对"这个答案有多可信"的量化打分；在自动化系统里常被用作"要不要转人工"的开关。
• 校准（Calibration）：说 80% 把握的事，实际命中率就在 80% 左右；不一致就叫校准差——天气预报说明天 90% 降雨却十次九次晴天，就是校准差。
• 口头置信度（Verbalized Confidence）：直接问模型"你多大把握"得到的分数，它是生成的文字，不是测量的数据。
• 采样一致性：同一问题问模型多次（或换个问法再问），看答案稳不稳定，稳定性可以当一种"把握"的代理信号。
• 幻觉：模型一本正经地编造事实；最麻烦的是编造时语气同样自信。

这篇到底在说什么

打个比方：让一个爱面子的实习生自己给工作打分——"这版方案我 95% 确定没问题"。这个分数反映的是他的性格和措辞习惯，而不是方案的真实质量。LLM 自评置信度就是这个问题：模型的"把握表述"受措辞、提示词、训练偏好影响很大，和真实正确率对不上号；越是有害的错误（幻觉），往往还包装得越自信。HN 上 200 多分的热度说明大量工程师踩过这个坑：用"模型自评分数 > 0.8 就自动执行"这样的逻辑上线，结果自动化越彻底，错得越整齐。工程上靠谱的替代思路是：用标注数据测校准、看多次采样的一致性、或者引入独立的验证器/规则检查，而不是问模型"你自己有多少分"。

这跟普通人有什么关系

如果你用的 AI 产品"自信满满但答错"，很可能是产品把模型的自我评分当成了质量开关。理解这一点，你会对"AI 说它很确定"多一分警惕——确定的态度不等于正确的内容。

为什么值得架构师关注

• 门控信号选型错误是系统性风险：自评置信度被用于"是否自动执行/是否免审/是否路由到专家"的阈值判断时，校准误差会直接转化为业务错误率，而且错误分布不可预测。
• 替代方案有成本谱系：标注集校准（一次性成本）、多次采样一致性（推理成本×N）、外部验证器（工程成本）、人工抽检（运营成本）——按风险等级混搭，而不是单点依赖模型自评。
• 与本周主题呼应：GUI 智能体的"转移级校验"（06 篇）、决策模型的"校准概率"（04/08 篇）都在强调同一件事——自动化决策需要外部可验证的信号，模型的自我报告不在此列。

核心内容

• 核心论点：让 LLM 自报置信度不能产生统计学上可信的概率，不应作为自动化决策的门控信号（来源：博客标题与 HN 讨论热度）
• HN 202 分 / 99 评论，属于本周评测方法论方向讨论度最高的话题
• 行业背景：决策类产品（Decisions API、决策模型）快速升温，"概率从哪来、可不可信"成为下游集成的前置问题
• 工程共识方向：置信度应来自校准数据、采样一致性或独立验证器，而非模型自我报告

行动建议

• 立即排查：全局搜索生产代码中"confidence"相关的阈值逻辑，凡是直接取自模型自述分数的，标记为高风险项
• 短期改造：重要流程的置信度改用"标注集校准分数 + 采样一致性 + 兜底规则"组合；自评分数最多用于日志观测，不用于决策
• 团队规范：把"禁止用模型自评置信度做门控"写进 AI 应用的代码评审清单