AI 输出为什么不稳定：temperature 解决不了的那部分随机性

📅 2026/10/25 ✍️ 小文 📖 约 1 分钟

同一个提示词两次结果不同，调低 temperature 也不管用。本文拆解采样、批处理、MoE 路由、上下文漂移、工具调用时序等六类真实噪声源，以及怎么在工程上兜住。

“我们把 temperature 设成 0 了，为什么同样的输入还是得到不同的输出？”

这是接入 LLM 后最常见的技术困惑之一。答案是：temperature 只控制采样阶段的一个参数，而整条链路上还有很多别的随机源。

理解这些随机源，是做好工程的基本功。因为很多问题（比如评测结果不可复现、线上偶发错误、A/B 结果不稳定）都源自对它们的不了解。

源头一：采样本身，不止 temperature

采样阶段涉及多个参数：temperature（温度）、top_p（核采样）、top_k、repetition penalty。设 temperature=0 通常变成贪心解码——每次选概率最高的 token。理论上确定性。

但注意两点：

更重要的是：即使解码完全确定，不同批次、不同硬件上的浮点运算顺序可能不同。GPU 上的矩阵运算会按批次并行，批次组成变了，累加顺序就变了，最后一位小数的差异可能让两个几乎同概率的 token 排名互换。这就是”输出前面一样、中间某个词开始分叉”的现象。

结论：在 API 场景下，不要假设绝对可复现。要做确定性验证，要么用支持固定 seed 且保证复现的推理后端，要么接受”语义等价”而非”逐字相等”。

最常见也最隐蔽的原因。看起来”同样的输入”，实际上：

排查方法：把每次实际送给模型的完整请求体落盘。太多团队只在应用层打印”用户输入”，看不到真实的完整 prompt。把请求体存下来做 diff，这类问题十分钟就能定位。

2026 年主流大模型大多采用 MoE（混合专家）架构。每个 token 会被路由到少数几个专家网络。路由是计算出来的，涉及浮点比较——当两个专家的分数非常接近时，微小的数值差异可能导致路由到不同专家。

这在实践中表现为：某些提示词对细微改动极其敏感，改一个标点，输出风格都变了。这不是玄学，是路由分叉。

应对方法只有一个：别指望靠微调提示词达到确定效果，要靠结构。用明确的输出格式约束（JSON schema、枚举值），把自由度压到最低。

供应商为了吞吐，会把多个用户的请求打包成 batch。batch 的组成随线上负载变化，进而影响浮点运算顺序（见源头一）。所以在高峰期和低峰期，同样的请求可能结果略有不同。

这也解释了一个现象：本地测试很稳，线上偶发出错。本地是单请求，线上是动态 batch。

Agent 场景的”不稳定”往往根本不是模型的问题，而是外部世界变了：

这类问题的定位方法是给工具调用加全链路 trace：记录每次调用的参数、耗时、返回摘要。看一次失败请求的 trace，通常一眼能看出是哪个工具返回了异常。

供应商可能在不通知的情况下更新快照版本。行为变化通常很小，但足以让依赖精确格式的代码出错。

应对：在请求里显式指定模型快照版本（而不是 latest 别名），并在升级时跑回归测试。锁定版本意味着你放弃自动获得改进，但换来可预测性。生产系统通常应该锁版本，定期主动升级并验证。

既然不能消除随机性，就要在架构上吸收它。

一、输出结构强制。 用 JSON schema / 结构化输出，而不是让模型自由发挥文本格式。解析失败率会大幅下降。

二、语义验证代替逐字比对。 测试里判断”是否包含必要字段、取值是否在允许范围”，而不是比较字符串是否相等。

三、关键操作加幂等与校验。 写操作前先读、执行后回读验证。同样的请求执行两次不应该产生两份数据。

四、多次采样投票。 对准确性要求高的场景（分类、抽取），跑三次取多数。成本涨三倍，稳定性提升明显，比换更大的模型更划算。这些任务通常用便宜模型，三次的成本依然很低。

五、评测用统计而非单例。 评测集至少几十条，看整体通过率的变化趋势，不要因为一条用例失败就大改提示词。

六、把不确定性暴露给用户。 低置信度的结果，产品上应该有”可能不准，请核对”的提示，而不是装作确定。这既是体验问题也是责任问题。

很多团队在追”让 AI 完全稳定”上花了过多时间。这大概率是徒劳的——底层是概率模型，绝对稳定不现实，而且随着模型变复杂，不确定性来源只会更多。

更现实的目标是：让系统在 AI 不确定时依然可靠。校验、重试、降级、人工兜底、可观测性，这些传统工程手段在 AI 时代没有过时，反而更重要。

模型只是一个不太可靠的组件。好的系统设计不假设组件完美，而是假设它会出错，并让错误可控。