不确定性：如何设计不完全可预测的软件

传统软件并非没有不确定性。需求会有歧义，网络会中断，时钟会漂移，并发写入会互相冲突，外部服务也会发生变化。即便如此，工程师通常仍然期待：对于受控环境中的确定性组件，只要状态和输入相同，结果也应当相同。

当生成式模型参与理解请求、生成产物或选择行动时，这种预期就不足以描述整个系统。请求可能存在几种合理解释；现有证据可能不足；多个结果可能同样有用；重复运行可能走过不同路径；工具面对的外部状态也可能不断变化。无论属于哪种情况，最终答案都可能看起来流畅而笃定。

这并不意味着软件无法做到可靠，而是要求我们重新说明“可靠”意味着什么，以及哪些保障必须由应用程序来落实。

论点

模型行为可以变化，软件仍然可以保持可靠。前提是团队明确哪些输出、执行过程和结果可以接受；在模型之外强制执行重要约束；并明确记录尚未解决的不确定性，而不是强求系统给出一个确定答案。

工程目标不是让每次输出都一模一样，而是分清哪些差异有价值、哪些无关紧要、哪些已经违反产品要求。要作出这种判断，首先要找到不确定性来自哪里。

区分不确定性、可变性、非确定性与错误

在严格的计算意义上，确定性计算在完整状态与输入相同时会产生相同结果。**非确定性（non-determinism）**则表示：即使完整条件相同，也不能保证唯一结果或执行路径。随机采样可能造成非确定性，并发调度也可能造成非确定性。

产品团队很少能够观察或控制所有相关条件。模型版本、提示、隐藏上下文、检索结果、工具响应、时间和并发活动，都可能让两次表面相同的运行实际上有所不同。这会增加精确复现的难度，但从严格定义看，并非所有差异都属于非确定性。

以下四个概念不应混为一谈：

不确定性：我们掌握的信息还不足以判断哪种解释、主张、行为或环境状态正确，或者接下来会发生什么。
可变性：不同试验的输出、行动轨迹或结果存在可观察的差异。
非确定性：可变性的一种成因，不能用来统称请求歧义、证据不足或外部状态变化。
错误：系统行为不符合已经声明的验收标准。

系统可以产生不同结果，却都没有出错；也可以每次都给出相同结果，却始终是错的。因此，“能否精确复现”和“是否可靠”是两种不同性质。本章同时讨论上述四类问题，不会用“非确定性”笼统指代所有不确定性。

四个实用的检查问题

下面四个问题不是一套统计学分类，而是帮助团队先找到问题位置，再决定系统下一步该怎么做。

检查位置	诊断问题	如何发现问题	常见应对方式
请求	是否存在会明显影响结果的不同解释？	明确列出假设、检查必填信息、记录澄清过程	追问、说明假设或收窄任务范围
证据	所需证据是否缺失、相互冲突、已经过时或无法取得？	引用、检索覆盖、来源日期、冲突标记	检索、核验、明确说明无法判断，或升级处理
重复运行	条件相当的多次运行是否会产生明显不同的输出或行动轨迹？	重复试验、结果评分、轨迹对比	定义验收标准、有目的地采样并验证
执行环境	工具、外部状态、并发活动或基础设施是否会改变系统看到的信息或执行结果？	带版本的配置、状态快照、工具结果、时间戳	隔离运行、保证幂等、重新读取状态并支持恢复

这些问题会相互影响。含糊的请求可能产生不同计划；不同计划可能检索到不同证据；变化的证据又可能导致不同行动。检查表的目的不是把每次失败强行塞进唯一格子，而是避免用“不确定性”一个词掩盖几种性质不同的工程问题。

输入歧义

当输入仍然存在几种会实质影响结果的合理解释时，就有输入歧义。“给管理层总结这份材料”没有说明具体受众、待作决策、篇幅和风险偏好；“订一张合适的机票”没有说明价格、时间、行李和改签条件如何取舍。

系统不应悄悄选择一种解释，然后按高影响任务继续执行。它可以追问、明确写出假设、给出有限选项，或者采用事先定义的产品默认值。如何选择，取决于打断用户的成本和误解需求的后果哪个更大。

证据缺失或相互冲突

当系统没有足够依据支持某个主张或决定时，就需要进一步处理证据问题。相关信息可能不在当前上下文中，模型可能无法取得，多个来源可能相互矛盾，已有知识可能过时，所需资料也可能无法访问。

检索可以减少这类不确定性，却不能消除它。检索到的材料也可能不完整、过时、不相关，甚至包含恶意内容。因此，证据需要保留出处和日期，并明确它支持的是哪项主张。NIST 把模型自信地产生错误或无依据内容列为生成式 AI 的核心风险，并把验证放在完整生命周期的风险管理中处理（NIST，2024）。

多次运行的结果不同

当多次运行产生不同措辞、答案、计划、工具选择或最终结果时，系统就表现出了可变性。有些变化是有意保留的：一份材料可以有几种同样优秀的总结或设计。另一些变化则说明产品要求或控制措施不够稳固，例如路由器反复改变去向，票据抽取结果的金额不一致，或者智能体有时成功、有时执行破坏性操作。

一次成功不能说明整体表现如何。Anthropic 的智能体评估文章建议使用多次试验，同时检查行动轨迹与最终结果，并隔离评估环境，因为模型行为、评估工具和环境本身都可能带来变化（Anthropic，2026）。

执行环境发生变化

环境不确定性来自一次运行所观察或改变的外部事物，包括网页、库存、权限、代码仓库、消息队列、其他用户、时钟和外部服务。两个看起来完全相同的请求，可能因为外部世界已经变化而不再等价。

应对方法来自分布式系统的基本功，只是有模型参与的执行需要更谨慎：在可能时保存输入快照，记录组件版本，为有副作用的操作使用幂等键，在真正提交前重新验证前置条件，并让部分完成的任务可以恢复。一次模型重试绝不能悄悄变成重复付款、重复发信或重复部署。

用四类任务检验这些问题

即使任务对“正确”的定义截然不同，这四个问题仍然能够帮助我们分析风险。

任务	不确定性出现在哪里	验收标准与允许的变化	必须由程序保证的约束及处理方式
票据抽取	模糊数字存在歧义；税务规则或商户身份可能缺失；多次解析可能不同；OCR 或汇率服务会变化。	必填字段符合数据模式；字段值能定位到原始文档区域；无法稳定识别的字段会被标记。	明细与总额必须一致；币种必须明确；无法判断的高影响字段转人工复核。
研究问答	问题范围不清；证据不完整或互相冲突；不同运行选择不同资料；网页会更新。	主张回答了指定问题；引用确实提供支持；重要分歧得到披露。	高影响主张不得没有依据；保留访问日期与来源；证据不足时允许不作结论。
创意生成	受众和语气可能不清；品牌事实可能缺失；结果多样性本来就是目标；素材服务会变化。	只要符合创作要求、政策、事实和格式约束，多个结果都可以有效。	必须包含的事实和禁止出现的内容由风格判断之外的检查来保证；不追求逐字相同。
采购智能体	“最好”取决于未说明的偏好；库存和政策会变化；计划和卖家可能不同；购买前价格可能变动。	所选商品符合明确偏好与组织政策。	在提交前强制检查授权、预算、供应商白名单、交易幂等性和最终价格；不满足时暂停或升级处理。

这个比较揭示了一个重要差别：创意任务中的变化可能就是产品价值，财务任务中的变化则可能成为产品风险。“把温度调低”不是通用答案，每种能力都必须明确说明什么可以变化。

明确什么样的结果可以接受

确定性函数经常用唯一的预期结果来测试；使用生成式模型的能力往往允许多种有效结果，但这些结果仍然应当有明确、可检验的验收标准。

可以从三个层面定义验收标准：

输出层：产物是否有效、有依据、足够完整并符合政策？数据模式很有用，但通常还不够。
过程层：系统是否只使用获准的数据和工具，是否遵守预算，是否保留证据来源，是否取得必要审批？
结果层：任务是否实现了预期效果，同时没有产生不可接受的副作用？

输出看起来正确，执行过程却可能侵犯隐私；每一步都走在允许路径上，最终答案仍可能错误；某次结果成功，也可能只是环境碰巧掩盖了缺陷。真正的可靠性要覆盖所有重要层面，而不是只检查最容易打分的一层。

验收标准可以同时包含硬性规则、分级质量门槛和人工判断。并非每条标准都必须写成代码，但团队必须能够解释什么算成功、判断依据是什么，以及证据无法得出结论时该怎么办。

在模型之外强制执行重要约束

在软件工程中，**不变量（invariant）**是指必须始终成立的条件。对于使用模型的能力，凡是涉及授权、资金、隐私或不可逆操作的要求，都不应依赖模型能否正确记住或理解提示词。例如：

调用者确实获得了执行该操作的授权；
交易永远不超过已经批准的金额；
结构化数据符合数据模式和字段间的一致性规则；
破坏性操作必须携带有效的批准凭证；
同一项副作用最多执行一次；
当使用场景要求事实依据时，对外陈述的每项事实都可以追溯到证据。

提示词可以向模型说明这些规则，但文字说明不等于强制执行。授权检查、策略检查、数据模式、交易约束、白名单和幂等机制应当独立拒绝不合规操作。模型负责提出方案，应用负责判断方案能否被接受。

并非所有要求都能完全自动检查。“医疗回答不能遗漏重要禁忌”可能需要专业评估器或人工复核，但它仍然属于验收标准，而且检查力度应当与后果相匹配。

明确记录尚未解决的不确定性

许多系统只有 success 和 error 两种结果，不确定性只能被强行塞进其中一种。如果 success 必须包含一个确定答案，系统就会受到“证据不足也要给答案”的激励；另一种结果是，仍有价值的部分产物被当作失败全部丢弃。

可以增加一组明确状态，例如：

needs_clarification：请求存在会实质影响结果的不同解释；
insufficient_evidence：系统没有足够证据支持必要主张；
conflicting_evidence：可信来源之间存在冲突；
needs_approval：方案本身有效，但即将跨过需要审批的后果边界；
retryable_environment_error：模型方案可能没有问题，但执行环境暂时失败；
needs_human_review：现有自动检查无法化解风险；
completed_with_assumptions：只有在明确说明的假设下，结果才可以使用。

每个产品可以采用不同名称，原则却不变：尚未解决的不确定性应当被明确记录，出现在遥测和评估用例中，并在界面里对应可执行的下一步。这并不要求产品把内部状态名称原样展示给用户。

这也会改变系统激励。关于幻觉成因的研究指出，只按准确率计分会鼓励模型猜测；在确实无法确定时，评估不应把明确说明不确定性视为与错误答案同样糟糕（Kalai 等，2025）。如果产品惩罚每一次“暂时无法回答”，人和模型都会更倾向于掩盖不确定性。

根据问题选择处理方式

不确定性不是一种单一状况，因此也不存在一个能够解决所有问题的“置信度阈值”。

处理方式	适用情况	不应把它误当作
澄清	缺失的用户选择会实质改变结果。	把系统本可检索或验证的事实问题推给用户。
检索	外部很可能存在更好的证据。	已经证明检索结果完整可信。
验证	可以用模式、规则、模拟器、工具或独立证据检查候选结果。	在未校准的情况下，让同一个模型批准自己的答案。
不作结论	找不到必要依据，或猜测的预期伤害高于价值。	没有恢复路径的笼统报错。
重试或重新采样	故障是暂时的，或生成多个可独立验证的候选确实有价值。	已经避免重复副作用或共同的系统性错误。
回退	范围更小的确定性能力仍然能提供有用服务。	假装回退方案与原能力的范围和质量相同。
升级处理	需要由负责任的人或专家补充判断、权限或上下文。	加一道审阅者无法真正判断的形式化审批。

这些动作可以组合。研究系统可以先检索，在发现证据冲突后请用户缩小时间范围，再带着局限说明完成任务。采购智能体可以自由制定计划，但在真正提交前重新读取价格与库存、验证政策，并请求审批。

评估行为分布，而不是一次演示

面对可变行为，一个评估用例不能只有一项输入和一份参考输出，还需要说明验收标准、相关环境、试验次数以及如何汇总结果。

Anthropic 的智能体评估文章介绍了两种回答不同产品问题的汇总方式（Anthropic，2026）：

pass@k：在明确的试验条件下采样 k 次，是否至少有一次成功？适合“先生成候选，再由可靠的验证器选择”的场景。
pass^k：k 次试验是否全部成功？它用于衡量产品在重复使用时的一致性，不能取代实际观察到的单次成功率和失败率。

按照定义，随着 k 增大，pass@k 不会降低，pass^k 不会上升。这并不表示多运行几次会让同一个模型同时“变好”和“变差”，而是因为两个指标问的是不同问题。如果直接用单次成功率的 k 次方计算 pass^k，还隐含了各次试验相互独立且分布相同的假设；共享的提示、模型和环境很可能破坏这个假设。因此，报告时应说明试验条件和实测结果，不能只套用公式。

如果系统会在行动前验证并选出一个方案，采样十份计划可能有价值；如果每一次采购操作都可能真正下单，重试十次就十分危险。生成多个候选与重复执行有副作用的操作，是两种完全不同的系统设计。

重复试验还应当只改变测试真正想研究的变量。衡量多次运行的差异时，应固定模型、提示、工具、数据和环境；测试系统能否适应变化时，则有目的地改变其中一项。否则，模型退化、测试设施缺陷和环境噪声会混在一起，无法诊断。

离线指标也不能完全说明部署表现。D’Amour 等人关于机器学习流程规格不足（underspecification）的研究表明：一些预测器在与训练数据同分布的测试集上表现相当，到了部署环境却可能出现重要差异（D’Amour 等，2022）。这项研究讨论的是训练流程，不是模型采样或提示变化；它在本章中支持的是一个更有限的判断：单一汇总分数不能证明所有重要的部署行为都符合要求。因此，生产准备度必须围绕整个系统建立测试与监控；较早的生产机器学习研究也已经提出这一点（Breck 等，2016）。

把置信度估计当作证据，而不是裁决

模型笃定的语气、模型自己报告的置信分数、多次采样的一致程度，以及用数据检验过的校准情况，是四种不同信号。

语言表达尤其容易让人误判。受试者研究发现，看到模型默认生成的解释后，人们可能高估答案准确率；更长的解释会提高人的信心，却不一定提高答案正确率（Steyvers 等，2025）。一段论证不能仅仅因为看起来完整，就获得更高权威。

某些不确定性测量方法在限定任务中确实有用。语义熵比较多次生成结果表达的含义，可以识别部分无依据生成（Farquhar 等，2024）。但结果一致并不代表事实正确：所有样本可能共享同一项知识缺口或错误观念。更广泛地说，数据分布变化也可能削弱原本有效的不确定性估计（Ovadia 等，2019）。

在使用任何置信度估计前，先回答五个问题：

这个信号具体估计什么？
它在哪一类任务分布上完成过校准？
对当前模型、提示、工具和用户群体，原有校准是否仍然成立？
信号落在不同区间时，系统分别采取什么行动？
还需要哪些独立检查？

如果这些问题没有答案，置信数字只是在给不确定性加装饰，而不是帮助系统作出可靠判断。

权衡

选择	收益	成本或风险
收紧验收标准	更容易验证，结果更一致	拒绝部分有用变化，也可能过度贴合评估样例
放宽验收标准	保留创造力和适应能力	更难评分，审阅负担更重，隐藏缺陷的空间更大
增加澄清	执行前减少歧义	打断操作流程，并把一部分工作转给用户
增加检索与验证	改善事实依据，发现部分错误	增加延迟、成本、来源风险与新的失效方式
增加采样或重试	可能找到有效候选，或克服暂时故障	提高成本，也可能放大共同错误或重复副作用
在应用代码中增加硬性约束	保护授权、数据完整性和有副作用的操作	减少模型决策空间，提高应用复杂度
增加人工复核	引入判断与责任主体	形成队列、疲劳与不一致，并限制规模

不存在适用于所有产品的统一答案。后果越大、越难撤销，不确定性越高、恢复越困难，验收标准就应当越严格。

常见失效模式

流畅即可信

界面展示连贯答案，却不展示证据、局限，也不允许表达尚未解决的不确定性。用户把表达质量误当成正确性。

用一次运行完成验收

团队因为一次令人信服的演示就批准能力上线。低频错误、不稳定路由和不一致的执行路径都没有被发现。

用逐字相同衡量可靠性

对于存在许多有效答案的任务，测试却只接受一句参考文本。它惩罚了有用的多样性，却可能放过一段碰巧与参考答案相似、实际上没有依据的内容。

把多数一致当成事实

几个样本给出同样答案，系统便认为已经验证。共同的训练偏差、知识缺口或带倾向性的提示，可能让所有样本以同一种方式出错。

配置变化不可见

模型、提示、检索索引、工具或政策改变后没有留下版本，也没有重新评估。系统于是把行为变化误判为随机噪声。

重试导致重复副作用

超时让系统无法判断操作是否已经提交，于是同时重试生成与执行，最终重复发送消息、重复购买或重复写入。

所有任务共用一个置信阈值

信息抽取、研究、创意写作和高影响操作使用同一分数控制流程，尽管它们的校准程度和失败后果完全不同。

会拒绝，却不会继续服务

系统拒绝执行，却不说明缺少什么证据，也不给出下一步、范围更小的回退能力或升级路径。风险降低了，产品价值也随之消失。

工程手册建议

对于每一项使用生成式模型的能力，在优化提示词之前先完成一份不确定性评审记录：

说明决策或产物。 什么可以变化，变化会带来什么后果？
回答四个检查问题。 哪些请求歧义、证据缺口、多次运行差异和环境变化值得关注？
定义验收标准。 分别说明有效输出、允许的执行过程、成功结果和允许的变化。
找出必须由程序保证的约束。 把授权、政策、数据模式、字段一致性、交易和副作用检查移到模型判断之外。
处理无法确定的情况。 定义澄清、证据不足、证据冲突、审批、重试、回退和升级路径。
选择需要保留的证据。 记录来源、配置、状态快照、行动轨迹、结果与人工决定。
进行重复评估。 根据产品真实使用方式选择试验次数与汇总规则。
测试每次变更。 把模型、提示、检索、工具、政策和环境更新都当作带版本的系统变更来重新评估。

一份精简的评审记录可以采用以下格式：

能力：
允许的变化：
不可接受的变化：
输入歧义：
证据缺口或冲突：
多次运行的差异：
环境变化：
由应用强制执行的约束：
未决状态及后续路径：
试验与评分方法：
保留的证据：

检验方法很简单：当两次运行出现差异时，团队能否判断二者是否都可以接受、差异为何产生，以及系统下一步该做什么？如果不能，系统虽然表现出了可变性，却还没有为这种变化做好可靠性设计。

检查清单

参考资料及使用说明

NIST，《Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile》，NIST AI 600-1（2024）——这是一份自愿采用、跨行业的风险管理资料。本章采用了其中对“自信地产生错误内容”的定义与讨论，以及从系统全生命周期管理风险的思路；它不是应用架构，也不能证明某一种缓解措施必然有效。
Anthropic，《Demystifying evals for AI agents》（2026）——基于 Anthropic 内部实践和客户经验的工程文章。本章用它支持多次试验、同时评估行动轨迹与结果、隔离评估环境，以及区分 pass@k 与 pass^k；它不是经过同行评议的统计标准。
Kalai 等，《Why Language Models Hallucinate》（2025）及 OpenAI 的研究摘要——论文从理论上解释预训练为何会产生部分事实错误，以及只按准确率评分为何会鼓励猜测。本章只采用其关于评估激励的结论；论文并未为所有产品给出一套通用的“无法确定时不回答”策略。
Farquhar 等，《Detecting hallucinations in large language models using semantic entropy》（2024）——经过同行评议的研究，说明比较多次输出在含义上的差异，可以发现一部分会随无关因素变化的错误生成。该方法不能发现稳定出现的系统性错误，多次结果一致也不能证明内容为真。
Ovadia 等，《Can You Trust Your Model’s Uncertainty? Evaluating Predictive Uncertainty Under Dataset Shift》（2019）——NeurIPS 论文，研究监督分类模型在数据分布变化后的预测不确定性。本章用它说明部署条件变化后应重新检查置信度校准；论文没有评估开放式文本生成或智能体行动轨迹。
D’Amour 等，《Underspecification Presents Challenges for Credibility in Modern Machine Learning》（2022）——JMLR 论文，说明在训练数据分布内测试表现相当的预测器，到了部署环境可能出现不同表现。它研究的是规格不足的训练流程，不是随机采样或提示变化。
Steyvers 等，《What large language models know and what people think they know》（2025）——经过同行评议的用户研究，范围是选择题和简短问答。本章用它支持关于默认解释、解释长度与用户信心的表述；该研究没有验证这些结果能否直接推广到长篇内容或智能体任务。
Breck 等，《What’s your ML test score? A rubric for ML production systems》（2016）——NIPS 研讨会论文，为生产机器学习系统提出一组可操作的测试。本章采用的是“应测试和监控整个系统”这一原则，同时承认这套量表早于现代生成式模型与智能体。