Demo 只是一个随机种子:为什么你的 AI 发布面临的是方差问题,而非润色问题
高管演示进行得非常完美。模型回答了精选的问题,智能体(agent)完成了工作流,屏幕录像已保存到公司网盘,发布日期也已排入日程。六周后,上线部署遭遇惨败,复盘报告不言自明:模型需要更多打磨,提示词(prompt)需要更多迭代,团队低估了从原型到生产环境之间的工作量。
这种叙事是错误的,而且代价昂贵,因为它让团队回去重复那些已经失败的工作。演示并不是生产环境的“欠打磨”版本。它只是团队从未测量过的分布中的一个“单一采样”(single sample)。那个惊艳瞬间只是模型针对相同输入可能产生的数千个结果中的一次实现,而团队却把最好的那次当作典型表现发布了。演示与生产环境之间的差距不是质量下滑,而是团队尚未察觉的“方差”(variance)。
这种思维转变至关重要,因为方差问题的解决方法与打磨问题的解决方法完全不同。“打磨”导向会说:“迭代提示词,微调模型,雇个更好的产品经理。”而“方差”导向则会说:“在输入分布中进行 n 次采样之前,你根本不知道自己手里拿的是什么。”这两种诊断会产生不同的路线图、不同的预算以及不同的事故模式。那些在 2026 年能够可靠交付的团队,都清楚自己面临的是哪种问题。
“单一种子”到底意味着什么
现代 LLM 服务即使在 temperature 为 0 时也是非确定性的。浮点数非结合性、GPU 并行性以及张量分片(tensor-sharding)路由意味着,在同一个模型上运行两次相同的提示词可能会产生不同的 token。即使设置了 temperature=0、seed=42 和 top_p=1,你仍然会看到方差——供应商对此有文档说明,vLLM 也有相关的未解决问题,近期的稳定性分析报告显示,在相同的评估集上,日常指标会出现明显的漂移。
一项关于 2026 年智能体行为一致性的研究发现,最顶尖的前沿模型变异系数(coefficient of variation)为 15%,而一款流行的开源权重模型则高达 47%——这意味着重复运行同一任务,成功率会在平均值上下波动三分之一到二分之一。Scale AI 的可靠性研究报告指出,在任何版本更新之前,相同模型在相同评估下的表现每天可能会有 10–15% 的波动。
这就是演示在无形中忽略的数学逻辑。当创始人台上展示智能体完成多步工作流时,观众只看到了一个轨迹。模型对于同样的输入有数千个同等概率的轨迹,而演示之所以是幸运的那一个,是因为团队挑选了那个幸运的结果——或者更宽容地说,是因为他们只运行了三次,而第三次成功了。他们正 在优化的 pass@1 指标衡量的是“是否‘某些’运行会成功”。而生产环境需要的可靠性指标是“是否‘每一次’运行都成功”,或者至少失败率是受限的。
结果就是,80% 的 pass@1 通常会崩溃为 25% 的“k 次尝试一致性”。那个“有效”的智能体在回答同一个问题时,每四次只有一次是正确的。用户在看到第四次成功之前,如果连续遇到三次失败就会流失,而 pass@1 指标却从未改变。
演示未采样的双轴输入分布
方差有两个独立的维度,且在演示时通常都被采样不足。
第一种是随机方差(stochastic variance):相同的输入,不同的运行。这就是上一节所描述的情况——模型在掷骰子,而演示只看到了一次投掷。解决方法是在演示阶段进行 n-of-k 采样:对每个演示输入运行 8 到 32 次,并报告失败率、最差输出以及各次运行之间的分歧,同时附带“最佳运行”的标题。如果 32 次中最差的一次是不可接受的,那么你拥有的不是一个功能,而是一个包装成产品的“掷硬币”。
第二种是输入方差(input variance):不同的输入,提取自生产分布而非精选的演示集。演示输入之所以被选中,是因为它有效。生产输入则是不经选择、直接送达的。它们包含拼写错误、缺失字段、模棱两可的意图、冲突的约束以及演示数据集代表性不足的特定地域结构。近期对生产环境 AI 故障的调查报告显示了一个反复出现的模式:典型案例的成功率为 98%,而偏离精选集的 5% 案例中失败率达 50%。均值看起来很正常,但尾部风险是灾难性的。用户不会访问“均值”——他们访问的是自己的特定情况,而长尾用户正是那些会大声抱怨并流失的人。
在发布之前,这两个维度都需要进行采样。一个只改变输入但固定种子的演示,只能测量输入的稳健性,而无法测量随机性。一个只改变种子但固定输入的演示,只能测量随机性,而无法测量分布覆盖率。生产环境会同时触发这两个问题,因此发布前的评估也必须如此。
方差优先的准则:每次发布必备的三个产出物
一个内化了“是方差而非打磨”理念的团队,在任何发布里程碑达成之前,都会产出三样东西。这些都不需要新的工具——它们只需要在交付功能前坚持运行实验的决心。
- https://galileo.ai/blog/llm-reliability
- https://medium.com/@adnanmasood/reliability-benchmarks-for-production-llm-systems-a-field-guide-to-llm-benchmarks-78e4354ac8c1
- https://scale.com/blog/smoothing-out-llm-variance
- https://arxiv.org/html/2603.25764
- https://arxiv.org/html/2603.29231v1
- https://simmering.dev/blog/agent-benchmarks/
- https://www.applied-ai.com/briefings/llm-evaluation-gap/
- https://ykulbashian.medium.com/the-long-tail-of-ai-failures-and-how-to-address-it-9fa14615cd54
- https://scale.com/blog/taming-long-tail
- https://www.nexastack.ai/blog/success-rate-physical-ai
- https://www.vincentschmalbach.com/does-temperature-0-guarantee-deterministic-llm-outputs/
- https://unstract.com/blog/understanding-why-deterministic-output-from-llms-is-nearly-impossible/
- https://arxiv.org/html/2408.04667v1
- https://thenewstack.io/ai-demo-to-production/
- https://www.imaginaryspace.ai/blog/why-most-ai-products-fail-after-launch-and-what-production-ready-actually-means
