DeepMind 副总裁谈 AI 不确定性推理这个话题最近在 AI 应用开发者圈子里讨论热度不低。核心问题其实不复杂当一个大模型给出答案时它自己到底有多大把握这个把握应该怎么表达、怎么验证、怎么被业务系统使用只看 Demo 的时候很多模型都能把任务做得像模像样一旦放进真实业务模型经常会在自己并不确定的地方给出一个非常确定的回答最后变成误导。这个现象叫“过度自信”也是 AI 落地过程中比“能力不够”更隐蔽的问题。这篇文章不打算转述某位高管的原话而是站在 AI 应用开发者的角度把“不确定性推理”这个偏研究的话题拆成可以落地的几个方向不确定性是什么、怎么量化、怎么校准、怎么在 Agent 和自动化流程里真正用起来。如果你正在用大模型处理客服、日志分析、代码生成、自动摘要或者在做 AI Agent 类的产品这篇内容会比单纯追热点更有参考价值。1. 为什么“不确定性推理”比“生成更准”更值得关注1.1 模型“能说”和模型“知道”是两码事大模型的训练目标本质上是在海量文本上预测下一个 token。这一步做得好模型就能生成流畅、结构完整的句子但训练过程并没有单独给模型建立“我对这个问题有没有把握”的机制。换句话说模型“能说”不代表“知道”更不代表“知道自己是知道还是不知道”。这在业务落地时会带来一个很实际的困扰。比如客服系统里用户问“这个订单明天能到吗”模型可能直接回答“可以预计明天下午送达”。如果这个判断本身没有依据或者模型只是把类似话术拼接出来了用户就会按这个承诺去安排时间最后订单没到问题就变成投诉。用户侧看到的现象是“AI 胡说八道”开发者侧看到的现象是“所有输出看起来都很可信但不知道哪几条不可信”。所以我一直觉得对做 AI 应用的人来说最大的风险不是模型能力不行而是模型没有把“不确定性”传递出来。能力不行至少可以被发现过度自信才最难排查。1.2 不确定性来自三个层面数据、参数和任务定义不确定性不是单一原因造成的。按我自己的理解至少可以分成三层。第一层是数据冲突。模型训练语料来自不同来源同一个问题在不同文档里可能有相反答案。模型被迫在这些冲突文本上做折中最后输出一个“平均答案”但这个问题本身就没有标准答案。第二层是参数化知识带来的压缩。模型把所有训练知识压缩成权重细节必然会丢失尤其是知识截止日期之后的事件、冷门概念和强时效信息。你让它回答一个刚发生不久的事件它很难区分自己是真的知道还是在根据相似新闻做合理推测。第三层是任务定义模糊。用户问“给我整理一下”到底要整理成表格、列表还是摘要上下文没写清楚时模型只能猜而猜就会产生不确定性。很多 Agent 场景里的误操作根源不是模型不会调用工具而是模型对用户意图本身就不确定却还是硬着头皮执行了。这些不确定性光靠调 prompt 很难消除。prompt 能改善表达但改变不了模型内部对问题没有明确答案这个事实。所以行业里开始强调“不确定性推理”意思是让模型和系统能够识别出“这个回答其实存在疑问”然后通过置信度、校准、多采样、人工兜底等机制把这个疑问显性化。1.3 不解决不确定性调 prompt 的边际效应会越来越低有一个现象值得注意很多团队在模型输出质量不好时第一反应是不断改 prompt今天加一句“请仔细思考”明天加一句“请用 json 输出”。前期效果提升明显但改到一定阶段后效果会进入平台期。这时候问题往往不在 prompt而在于模型根本不知道自己该在什么情况下放弃回答。举个例子你让模型做意图分类输入是一段很模糊的消息。模型在两个意图之间反复横跳置信度各占一半。这种情况下再怎么写 prompt 也无法让它真正确定用户想要什么。正确的做法不是逼它选一个而是让系统感知到这种不确定性然后回问用户、转人工或者给出多个候选让用户确认。这就是不确定性推理给工程实践带来的最大变化把“模型必须给出一个答案”换成“系统可以根据置信度决定要不要给答案”。这个思路一旦建立很多 prompt 层面的死结都能解开。2. 把不确定性变成可验证的工程指标2.1 置信度不是正确率先分开看待一说到不确定性很多人的第一反应是让模型在回答里加上“我可能不对”“仅供参考”。这个做法有一定作用但很不稳定。模型输出文本里的“可能”不等于概率更不等于模型真实把握。工程上要做的事是给每次推理记录一个数值化的置信度然后拿这个数值和最终结果是否正确的标签做统计。这个统计过程专业一点叫校准。校准的作用很简单如果模型给出 0.9 的置信度那么这一批样本里真实正确率应该接近 90%这样才能把置信度当成决策依据。我第一次做类似统计时发现结果非常扎心。模型对很多问题的置信度都集中在 0.95 以上但实际正确率只有 70% 左右。也就是说模型不仅会错还会非常自信地错。所以第一步不是去调阈值而是先建立“置信度和正确率之间的关系报告”。没有这份报告所有阈值讨论都是拍脑袋。2.2 用分箱统计建立自己的校准报告校准报告不需要很复杂的工具。按下面流程走一遍就够了。先准备一个验证集。这个验证集要贴近真实业务不能直接用网上公开的通用测试集因为业务里的问法和难度跟通用测试不一样。然后对每条样本记录模型返回的置信度以及人工标注的最终结果是否正确。最后按置信度区间分箱比如 0 到 0.5、0.5 到 0.7、0.7 到 0.9、0.9 到 1.0计算每个区间内的真实正确率。下面是一个简化版示例用来表达统计逻辑实际生产里要加上日志读取、异常处理和更细的分箱策略。# 示例按置信度区间统计真实正确率 def build_calibration_report(samples): # samples 是列表每个元素是 (confidence, correct) bins [ (0.0, 0.5, []), (0.5, 0.7, []), (0.7, 0.9, []), (0.9, 1.0, []), ] for confidence, correct in samples: for low, high, bucket in bins: if low confidence high: bucket.append(correct) break report [] for low, high, bucket in bins: if not bucket: continue accuracy sum(bucket) / len(bucket) report.append({ confidence_range: f{low}-{high}, sample_count: len(bucket), accuracy: round(accuracy, 3), }) return report拿到报告后怎么判断如果某个置信度区间内的真实正确率明显低于区间下限比如 0.9 到 1.0 区间只有 0.7说明模型在这个业务上过度自信。这时候直接调低置信度阈值没有意义更重要的是先看这批样本错在哪是数据冲突、输入太短还是任务边界模糊。校准报告不是做一次就结束。业务数据会变模型版本会换prompt 会调整每过一次大改都应该重新统计。频率不用太高但在上线关键流程前必须跑一遍。尤其在模型本身迭代很快的阶段上周的报告这周就可能失效。2.3 温度、多采样与置信度的关系除了模型返回的置信度还有一个常用手段是调整采样温度。温度越低输出越确定但可能陷入重复或保守的答案温度越高输出越多样但稳定性下降。温度本身并不直接代表不确定性它只是改变了输出的分布形态。所以更稳妥的做法是把置信度和多采样结合使用。对同一个问题生成多次统计答案的分布。如果多次输出高度一致说明模型在这个问题上有稳定的内部表示即使单次置信度不是最高也可以认为风险较低。如果多次输出差异很大即使在某一次输出里模型给了高分整体可信度也应该下调。多采样的代价是延迟和成本不适合所有任务。我的习惯是先在校验阶段用多采样摸清任务的稳定性。如果任务天然稳定单次生成就能用如果任务经常出现答案漂移再考虑在关键节点上引入多采样比如工具调用前的意图判断。2.4 根据校准结果设置决策阈值有了校准报告阈值才谈得上“设置”。阈值不是随便拍一个 0.9而是要看业务能承受多大的错误率。比如客服自动回答场景如果答错会造成差评那阈值就要定在真实正确率超过 95% 的位置。假如模型置信度 0.85 的时候真实正确率只有 90%达不到要求那就要把决策阈值提高到 0.92让低于 0.92 的回答走人工审核。如果业务容错高比如生成一段宣传语初稿错误影响不大阈值可以定低一点避免大量任务进入人工。可以这样理解模型输出的置信度只是候选分数业务阈值才是最终决策点。两者必须分开讨论。置信度区间真实正确率示例建议动作0.90 - 1.0072%不能直接自动执行需提高阈值或检查校准0.80 - 0.8968%进入人工审核0.60 - 0.7955%重试、澄清或直接拒绝0.00 - 0.5940%低置信度默认不走自动化表格里的数字只是说明判断逻辑不是通用标准。真实项目的校准报告会完全不一样所以一定要用自己业务数据跑出来。3. Agent 和自动化任务里的不确定性设计3.1 日志只记答案不记置信度出了问题很难复盘很多 AI 应用上线后日志里只有用户问题和模型回答缺少置信度、采样参数、模型版本、prompt 版本这类字段。平时看着没什么一旦用户投诉或者自动化流程误操作复盘会非常困难。你根本不知道当时模型是拿什么依据做的决定。我的建议是日志从第一天开始就带上这些字段请求 ID、模型名称、prompt 版本、输入摘要、输出内容、置信度分数、采样温度、推理耗时、有没有触发重试、最终决策动作。不需要每个字段都展示给用户但内部排查时必须有。尤其是 Agent 场景模型会反复调用工具、读写文件、修改状态如果日志只有一句“执行成功”后续定位问题等于大海捞针。先有日志再谈不确定性闭环。这是我在多个项目里踩过坑之后最深的体会。日志里的置信度字段最好和最终业务结果关联起来。只有这样几个月后再回头统计“置信度 0.9 以上但最终被用户投诉的样本”才找得到线索。3.2 低置信度分支重试、澄清、人工、拒绝在 Agent 或自动化流程里低置信度的处理不能只是“打印一句我不确定”。要设计明确的分支。常见分支有这么几个重试一次或多次适合临时性波动向用户澄清适合输入有歧义转人工适合高风险操作直接拒绝执行适合缺少必要信息但动作不可逆的场景。举一个实际例子Agent 接到指令“把这个文件里的数据整理一下发到群里”。如果模型对“整理成什么格式”不确定直接开干很可能生成一个不完全符合预期的文件。更稳妥的做法是先用一句话回问“需要的输出格式是表格还是摘要”澄清一次通常比事后返工更高效。给模型配置“请求澄清”不是示弱而是减少错误扩大的成本。特别是 Agent 有写权限、发送权限、支付权限时先确认后执行应该成为默认规则。3.3 Agent 工具调用前先做意图确认Agent 场景里不确定性推理最关键的节点不是最终输出而是工具调用之前。模型调用工具本身就等于做出了一个决策它认为当前需要外部数据或者需要对系统状态做修改。如果这个决策建立在低置信度上工具调用的后果会被放大。我一般会在工具调用前加一层判断。比如模型准备调用“发送邮件”这个工具系统检查一下它给出的置信度、收件人是否明确、邮件内容是否完整。只要有一个关键字段不明确就拦截下来先返回给模型做澄清而不是直接执行。这不是限制 Agent 能力而是给 Agent 增加安全边界。很多 Agent 翻车都不是模型不会调工具而是它在不该调的时候调了或者调的时候参数选错了。不确定性机制能在这一层起到真正的拦截作用。3.4 把不确定性设计成闭环而不是单点优化很多人会陷入一个误区只调 prompt只在回答里加一句“如果不确定请说不知道”就以为处理了不确定性。实际上真正落地时要把“不确定性”贯穿到整个系统链路。闭环大致是模型输出时带上置信度置信度进入日志日志累积后用校准报告与业务结果做对比校准报告反哺阈值和 prompt 设计再回到模型输出。这样一来不确定性就不是一句口头提示而是可量化、可监控、可改进的系统指标。这个闭环不需要一开始就做得非常重。可以先从“记录置信度”开始运行一两周后再做分箱统计再根据统计结果决定要不要引入多采样或人工兜底。一步一步来比一次性追求完美方案更靠谱。4. 不同场景的落地强度别把所有任务都按同一套标准做4.1 高风险场景把不确定性当成安全阀需要明确的是不是所有 AI 应用都要建立复杂的置信度体系。是否需要取决于错误代价。高风险场景包括自动客服给用户承诺、代码生成并自动合并、财务数据处理、医疗建议输出、法务信息摘要、Agent 自动发送对外消息等。这些场景一旦出错轻则返工重则造成资损或法律风险。在这些场景里不确定性机制应该是一个安全阀。宁可让一部分任务因为没有达到阈值而转人工也不能让低置信度输出直接进入自动执行链路。具体做法上这类场景要把校准报告作为上线前置条件。没有跑出置信度和正确率关系的模型不应该直接开放给用户。同时要保证低置信度分支里有真人在线而不是让用户等一个永远不来的审核。4.2 内容生成和创意任务可以先跑通再校准内容生成类的任务比如广告文案、短视频脚本、商品描述、邮件草稿容错空间会大一些。用户拿到结果后通常会自己修改模型错一点也能接受。这类任务不需要非常严格的阈值机制先用默认配置把流程跑通记录用户的修改率和反馈再决定要不要做校准。有一点要注意内容生成任务里“高置信度”不一定代表高质量。模型可能对一段平庸的文案给出很高置信度因为它在统计上很常见。这类效果评估更依赖人工打分或业务转化数据不能只靠置信度判断。4.3 团队资源有限时的落地顺序很多读者可能不是大公司研究员而是三五个人甚至一个人的开发团队。这时不用急着把整套不确定性框架都搭起来可以按优先级推进。我建议的顺序是第一日志里记录置信度和关键上下文这一步成本最低第二准备业务验证集做一次校准统计看看当前模型在业务上的过度自信程度第三针对最高风险的一条链路设置阈值和人工兜底第四后续再逐步加入多采样、澄清分支和自动重试。这四步做完已经能覆盖大部分自动化和 Agent 场景。检查清单可以是每个关键接口是否返回置信度分数日志里是否能定位到某次决策使用的模型版本和 prompt 版本是否知道当前模型在业务验证集上的置信度与正确率关系低置信度输出的后续动作是转人工、重试、澄清还是直接拒绝模型版本或 prompt 更新后是否重新做过校准统计这五条比背概念更实际。能回答清楚基本上就具备了不确定性闭环的雏形。5. 实测中容易踩的坑和排查思路5.1 坑一置信度高不代表绝对正确最典型的坑是把单次置信度当成正确率。同一个问题换一种问法模型可能从置信度 0.99 变成 0.4同一个输入在不同 prompt 下输出也可能完全不同。置信度只是模型在内部参数条件下给出的分数不是对客观事实的保证更不等于业务结果正确。我见过一些小团队上线时看着置信度 0.98 就放心自动执行结果用户一投诉才发现模型把两个相似订单搞混了。所以看置信度之前先校验模型和业务场景是否匹配。置信度只能作为决策信号之一不能单独成为自动执行的依据。5.2 坑二让模型说“我不知道”并不能解决问题有些人会用 prompt 告诉模型“如果你不确定就说不知道”。这个方法有一定效果但很容易造成假象。模型可能在它其实知道答案的时候也说“不知道”也可能在它并不知道的时候照样给答案。它并没有真正理解“不知道”背后的概率判断。更稳的做法是同时统计两个指标知道答案时的正确率以及“拒绝回答”的比例。如果拒绝率很高但正确率没有明显上升说明 prompt 只是在压制模型输出而不是真正帮助模型识别不确定性。这时候需要回到输入侧检查任务定义和上下文是否足够清楚。5.3 坑三只改 prompt 不做数据评估还有一个常见问题是效果不好就反复改 prompt却不去看数据分布。比如模型总是把某类问题判错可能是验证集里这类样本太少也可能是标注本身有歧义。改 prompt 只能掩盖表面问题数据层面的问题会换一个形式继续出现。正确的做法是先抽样看错误样本找到共性再判断是输入信息不足、标注不一致还是模型知识缺失。如果输入信息不足应该让模型请求澄清如果标注不一致应该优化标注标准只有模型本身理解有偏差才需要调整 prompt。跳过数据评估直接改 prompt很容易陷入“按下葫芦浮起瓢”的循环。5.4 排查链路先看数据再看日志最后调阈值如果你已经接入了置信度但业务里还是出现低质量输出我建议按下面的顺序排查。先复现问题把出问题的输入原样再跑一次看是不是稳定复现。不稳定复现的问题大概率是采样随机性或模型版本切换导致的。然后看日志确认当时的置信度、模型版本和 prompt 版本不要只看输出文本。接着做分箱统计看置信度区间内的真实正确率是否达标。如果不达标去检查验证集有没有数据泄漏输入样本分布和线上是否一致。最后再考虑调阈值或改 prompt。这里容易犯的错误是跳过日志直接改 prompt。改完发现另一批样本又崩了因为根因根本不在提示词。不确定性相关的问题排查顺序基本是“数据 - 日志 - 校准 - 阈值 - prompt”。顺序反了问题只会反复出现。5.5 从功能上线到可信上线的差距在哪里很多项目把“模型能回答问题”当成上线标准但真正可信的标准应该更严格模型清楚哪些问题自己答不了系统有办法把不确定的输出分流每次误判都能从日志里找到线索模型更新后所有指标还能保持稳定。差距不一定来自模型参数更多时候来自工程体系。DeepMind 副总裁谈 AI 不确定性推理本质上也是在提醒这个方向AI 系统不能只会输出答案还要学会管理和表达自己的不确定性。对我们普通开发者来说不一定要立刻实现顶会论文里的复杂算法但至少在日志、阈值、人工兜底和校准评估这些环节应该尽早动手。我个人更建议把“记录置信度”当作所有 AI 应用的基础项而不是高级项。先把这条链路跑起来再逐步加深。越早积累业务侧的校准数据后面的优化就越有方向。希望这篇内容能给你的 AI 应用开发带来一些具体启发。