上个月帮一个内部团队排查 AI 问答系统现象很典型模型把所有问题都答得很快但文档里没有的内容它也能编造出引用来源。团队最开始归因于“幻觉”于是反复调提示词、换模型、做 RAG 检索优化结果问题仍然偶发。后来我意识到真正的瓶颈不在于模型“不知道”而在于它根本判断不了“自己知不知道”。这个问题在工程和学术里的名字就是不确定性推理。最近 DeepMind 的一位副总裁在公开讨论中也谈到了这个话题。我理解他的核心判断是AI 系统的可靠性不应该建立在“模型永远给出正确答案”的假设上而应该建立在“模型能够表达不确定并且系统知道如何处理这种不确定”的基础上。这句话听起来像常识但真正在工程里落地时会发现大多数人处理的思路还停留在“让模型更准确”而不是“让模型更自知”。这篇文章想从工程视角把这件事拆开不确定性推理到底指什么为什么生成式模型很难天然具备这种能力以及我们在一套真实的 AI 应用里应该怎么设计流程让它能在不确定时拒绝、降级、求助或转人工。我不会去复述某一次演讲只会把它放到普通开发者能复用的场景里。1. 先别急着让模型更聪明先解决它“不知道自己不知道”的问题1.1 模型错在细节上最危险的是一本正经地错如果你只是拿大模型做写文案、写摘要这类低风险任务不确定性好像不是那么致命。真正让人头疼的是把它放进业务决策链路比如根据内部知识库回答客户问题让 Agent 调用工具去查数据、改配置阅读长文档后做筛选和标注在客服场景里代替人工给出最终答复。这些任务的共同特点在于模型出错没有固定规律。有时候是检索到的上下文不完整有时候是模型把两个相似概念拼在一起有时候是它压根没学过相关知识。问题是模型在输出这些内容时话术非常流畅甚至比人类答得还像“标准答案”。用户很难从语气上判断它是不是在编。我在排查那个问答系统时团队一开始只统计“最终答案对不对”结果发现大部分问题都答得不错但少数错得非常离谱。真正让我警惕的不是错误率而是错误出现时完全没有预警信号。这就是“一本正经地错”它看起来确定所以下游没有机会启动兜底机制。1.2 不确定性推理不是让模型更犹豫而是让输出可被信任很多人会把不确定性推理误解成“让模型变得含糊其辞”比如在答案后面加上“我可能不是完全确定”“以上建议仅供参考”。如果只是这样那任何一个提示词工程师都能做到完全不需要讨论。不确定性推理真正要解决的是让模型能够对“自己是否知道”给出一个可评估的信号。这个信号不是自然语言里的“我觉得”而是一个可以量化、可以设置阈值、可以被下游流程消费的状态。换句话说我要的不是一个更谨慎的回答而是一个能告诉我“这个回答可不可信”的接口。有了这个接口系统才可以决定直接返回给用户返回结果但附加风险提示转给人工审核拒答并让用户补充条件。所以不确定性推理本质上是一种“能力边界感知”。它不一定让模型变得更聪明但它让模型和系统之间的协作变得更安全。2. 从工程视角理解“确定性”和“不确定性”的边界2.1 模型内部的不确定性至少可以分成几种来源如果我们想把不确定性推理落地第一步不是去找一个现成算法而是先建立分类意识。同一个模型面对不同问题时的“不确定”来源完全不同处理方式也完全不同。我一般会把不确定来源分为四类数据本身存在歧义问题里的实体名有多个近似解释比如“苹果”指公司还是水果要看上下文。训练知识覆盖不足模型没有学过相关内容或者只见过零散片段无法形成可靠判断。推理链条过长多步推理时任何一步出错都会累积到最终结果哪怕模型每一步都“看起来”有道理。采样随机性带来的波动即使输入完全相同温度参数导致每次生成结果不同模型实际没有稳定的答案。前两种属于“知识边界”问题后两种属于“推理稳定性”问题。在真实项目里它们经常混杂在一起。如果不分类你看到“答案不对”时很难知道该改数据、改检索、改提示词还是改不确定性评估方法。2.2 为什么生成式模型天然很难给出可靠的“概率”一个很常见的工程误区是既然模型在生成每个 token 时都给了概率那我把整条输出的 token 概率乘起来不就能代表置信度吗这个思路听起来合理但实际不可靠。模型给出的 token 概率反映的是它估计“人类可能写出的下一个 token”分布而不是“客观事实成立的概率”。它受训练数据分布影响很大。有些原本编造的内容因为训练语料里见过类似写法token 概率反而不低。另一个问题是采样策略。很多模型在解码时会做 temperature、top-p 采样这会让最终输出概率分布发生变化。你把温度调高模型生成多样性大了但每个 token 的概率并不是直接量化“置信度”的可靠信号。更麻烦的是简单乘起来会偏斜因为长回答的联合概率天然小于短回答。所以我通常不建议直接信任 logprob 或类似内部概率除非你已经做过校准实验。工程上更稳定的做法是设计外部验证机制而不是依赖模型自己给出的数值。2.3 不确定性和“幻觉”不是一回事但必须一起处理很多人会问不确定性推理是不是就是“防幻觉”我的理解是它们高度相关但不能完全画等号。幻觉强调“生成内容与事实不一致”。不确定性强调“模型对当前输出的判断有多可靠”。实践中会出现四种组合输出正确模型也确定输出正确但模型不确定输出错误模型却非常确定输出错误模型也表现出不确定。对工程系统来说最危险的是第三种错得自信。因为这种错误会被下游流程直接接受。而第四种虽然结果还是错的但至少提供了干预信号我们可以把它拦下来。不确定性推理的价值就是尽量把“错得自信”的样本转移成“错误但不确定”然后通过拒绝或人工审核来兜底。所以不要只统计“幻觉率”或“正确率”还要观察模型什么时候自信、什么时候犹豫。这个维度才是判断系统可不可靠的关键。3. 如何让 AI 在关键流程中“知道何时该说不知道”3.1 让模型输出置信度不等于不确定性推理有些团队为了快速解决问题会在提示词里加一句“请对你的回答进行置信度评估输出 0 到 100 的分数。”然后程序根据这个分数决定是否返回结果。这个做法有一定参考价值但它存在一个问题模型给出的分数未必已经经过校准。它很可能是在模仿训练语料中“置信度表达”的文字形式而不是在真实评估自己。举个直观的例子你让模型说“我的回答有 90% 把握”它也能说得出来但不代表它真的达到 90% 的正确率。我并不是说这种方法完全没用。在资源有限、问题简单、风险可控的场景里它可以作为第一版过滤条件。但我更建议把它当成“辅助信号”而不是“安全依据”。真正可靠的判断最好来自可复现的实验而不是模型的自述。3.2 一个可落地的最小流程从抽样响应到一致性评估在没有底层模型内部状态权限的情况下一个相对简单且通用的做法是一致性评估。核心思想是如果模型对同一个问题在多次独立采样中都能给出语义一致的回答说明它有一个比较稳定的答案如果几次结果互相矛盾说明它并不确定。我通常建议按这个流程跑固定 Prompt对同一个问题做 4 到 5 次采样温度设置在 0.7 到 1.0 之间。收集输出后先做轻量归一化比如去除标点差异、统一大小写。计算语义一致性可以用字符串相似度也可以用嵌入向量余弦相似度。设置一致率阈值比如 5 次中至少 4 次语义等价才认为“确定”。对低于阈值的样本进入“不确定”分支而不是直接返回答案。下面是一段“示例结构”代码不是完整的生产实现# 伪代码不确定性评估最小流程 responses [ model.generate(prompt, temperature0.8) for _ in range(5) ] normalized [normalize_text(r) for r in responses] consistency compute_semantic_consistency(normalized) if consistency 0.8: answer most_common_answer(normalized) return answer, high-confidence else: return None, uncertain这种方法的优点是不依赖模型内部概率比较容易在不同模型之间移植。缺点是多几次采样会带来额外推理成本和延迟。所以它更适合用在风险较高的环节而不是每一句对话都跑一遍。3.3 把不确定性表达成行动策略拒绝、降级、求助、转人工模型给出“不确定”信号之后系统不能只是把它当作一个标签必须转化为具体行动。我比较建议预先定义一张行动策略表。一致率区间动作例子高例如 ≥ 0.8正常回答客服直接返回最终答案中例如 0.5 ~ 0.8降级处理返回答案并标注“建议人工复核”低例如 0.5求助/转人工拒绝自动回答转给人工客服或让用户补充信息这里的关键不是阈值本身而是阈值一定要结合业务风险来调整。如果答错了会造成严重损失阈值就调高一点宁可多转人工。如果只是辅助写作阈值可以放宽因为人工本来就会把关。注意不要一上来就把阈值定成 0.9先用一小批真实问题做标注看一致性评估和最终正确率之间的关系再决定阈值。4. 不确定性推理在 Agent 和自动化流程中的真正价值4.1 只靠单次生成无法构建可靠的 AgentAgent 类应用这两年非常热门但很多问题也出在“单次生成”上。Agent 需要调用工具、阅读结果、决定下一步每一步都可能出错。我见过一个典型的失败案例Agent 要搜索某个配置项第一次检索结果不完整但模型没有意识到这一点直接基于不完整信息做了决策。如果这个 Agent 能对“检索结果是否足以支持回答”做一次不确定性判断它可能就会多查一次或者向用户确认。只靠单次生成的另一个问题是大模型很容易被前面的错误带偏。当 Agent 已经生成了中间步骤后续生成会顺着这个路径走下去。如果不确定信号只在最后输出层出现那么错误已经发生止损成本很高。4.2 给 Agent 加一个“风险开关”我的建议是在 Agent 的每一步关键操作前都插入一个“风险开关”。这个开关的任务是判断当前是否有足够信息继续行动还是应该停止、回退、或请求外部输入。一个很轻量的检查流程可以是这样当前任务要用到哪些外部信息这些信息是否已经全部获得本次模型生成的历史上下文里是否存在异常信号比如检索结果为空、工具返回错误、前后不一致。如果继续执行自动操作可能造成的影响有多大是只读查询还是写操作如果执行失败后悔成本有多高是否有回滚机制注意这个开关不一定需要复杂算法。很多时候一个简单的“信息完整性校验”就能拦截大量错误。比如 Agent 要调用一个删除接口但输入参数里有必填字段为空这时直接停止并汇报比让模型自己决定“要不要猜一个”要安全得多。4.3 实际落地时日志、指标、反馈回路缺一不可不确定性处理不是一次性的模型配置它和整个系统的运营状态强相关。我在生产项目里通常会重点看三类数据日志记录每一次“不确定拒绝”“转人工”“自动通过”的完整上下文包括输入问题、检索结果、模型输出、一致性分数。指标统计拒绝率、覆盖率、通过后的正确率、转人工后的人工复核结果。反馈回路每周抽取不确定但被拦截的样本让业务方判断拦截得准不准再把结果用来调整阈值和提示词。如果没有反馈回路不确定性阈值就是拍脑袋。有了反馈回路系统会逐渐变得更符合业务风险偏好。这里要特别提醒不确定性推理不是“调一个参数就完事”它需要持续维护。5. 从模型评估到生产部署不确定性指标怎么选、怎么用5.1 校准度模型说 90% 时正确率是不是真的接近 90%工程上判断一个置信度信号好不好最重要的一条叫校准度。意思是当模型给出一组置信度为 90% 的预测时这组预测的实际正确率应该也接近 90%。如果模型说 90% 的答案实际只有 70%说明它过度自信。判断校准度最简单的办法是画校准曲线。把测试样本按置信度分层比如 0~0.2、0.2~0.4、0.4~0.6、0.6~0.8、0.8~1.0然后统计每一层的实际正确率。如果实际正确率和置信度大致落在一条对角线上说明校准效果好如果曲线明显在下面说明模型普遍自信过头。对于使用一致性评估的系统同样可以这样评估把多次采样的一致率作为“置信度信号”看它和真实正确率的关系是否单调。如果一致率高不代表正确率高就要换信号或调评估方法。5.2 工程上常用的不确定性指标要组合着看只盯一个指标很容易被误导。我建议至少组合这几个指标一起看指标含义使用时注意正确率自动通过的结果里有多少是对的单独看会掩盖高风险错误拒绝率触发“不确定”并转人工/拒答的比例太高会失去自动化的意义覆盖率未触发“不确定”自动返回结果的比例覆盖率与拒绝率互补一致性率多次采样语义等价的比例可以作为不确定性信号风险代价错误放过的损失 vs 错误拒绝的损失业务上更准确的目标在实际项目里我会先确定一个可接受的风险代价再反推拒绝率阈值。比如客服场景中一次错误自动回答的成本如果很高那么宁可拒绝率高一些也要保证通过的结果基本可靠。5.3 别只看平均正确率要按样本难度分层看平均正确率是最容易骗人的数字。因为简单问题占多数时即使困难问题全错平均正确率还是很高。但真正会影响业务口碑和用户信任的往往是困难样本。我习惯把测试集分为几类简单事实型问题比如“API 版本号是什么”检索库里有明确答案。隐含推理问题需要结合多段文档才能判断。多文档冲突问题多个来源说法不一致。开放式建议问题没有唯一正确标准更多依赖常识或经验。每一类需要单独统计一致率和正确率。如果发现在“多文档冲突问题”上模型虽然一致性高但正确率低说明它可能只选了某一份文档的内容并没有真正理解冲突。这时候要做的不只是调阈值而是优化检索和上下文组织。如果出现“该拒绝时没拒绝”的情况排查顺序应该是先看 Prompt 是否暗示必须回答再看采样参数和阈值设置再看一致性评估方法是否合理最后回到检索和上下文是否充分。6. 我们可以从 DeepMind 的讨论中收获什么6.1 真正的难点不在于算法而在于“把不确定交给流程”围绕 DeepMind 副总裁谈 AI 不确定性推理的讨论很多技术博主关注的都是“新方法”“新论文”。但我更在意的是一个认知层面的转变我们不再把 AI 当成一个“全知系统”来对待而是把它当成一个“有时可靠、需要被校验”的参与者。算法层面的不确定性模型当然很重要但对绝大多数业务系统来说真正改变可靠性的是流程设计。你愿不愿意在模型前面加一层校验你愿不愿意在风险操作前停止自动执行你愿不愿意接受“不知道”也是一个合法输出这些决定往往比换一个更强模型更有效。6.2 适合先做的三个实验如果你刚接触这个话题不想一上来就上复杂方案我建议先做三个小实验。第一个在现有问答接口上加一个 5 次采样一致性评估只记录不拦截。跑一周看“一致率低”的样本在最终人工复核里到底错多少。这个实验能帮你判断当前模型的不确定信号是否有效。第二个把低一致率样本改成“返回不确定并转人工”对比用户满意度和人工处理量。观察拒绝率是否在可接受范围以及用户是否因此更信任系统。第三个在 Agent 的关键步骤前加一个简单的“信息完整性检查”。比如工具调用前如果必要参数不存在就停止并汇报。先不用复杂模型用规则就能拦住很多明显错误。这三个实验难度都不高但能让你真正理解不确定性推理在业务里的作用。6.3 不确定性推理会改变人与 AI 的协作方式最后说一点更长期的观察。过去我们使用 AI习惯问“它能不能答对”。有了不确定性推理之后我们会开始问“它什么时候需要人帮忙”。这会让 AI 从“自动回答工具”变成“带边界感知的协作系统”。对开发者来说这意味着未来设计应用时除了功能逻辑还要给模型设计“退出路径”对产品经理来说这意味着一件事把“AI 不确定”也当成一个正常的用户交互节点对团队管理者来说这意味着评价 AI 项目时不能只看准确率还要看错误是否可被及时发现。这不是某个模型厂商单独能解决的。它需要模型、框架、业务策略和人工反馈一起配合。也正因为如此不确定性推理不只是一篇论文里的概念它会成为 AI 工程化里一项越来越基础的能力。