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%。均值看起来很正常，但尾部风险是灾难性的。用户不会访问“均值”——他们访问的是自己的特定情况，而长尾用户正是那些会大声抱怨并流失的人。

在发布之前，这两个维度都需要进行采样。一个只改变输入但固定种子的演示，只能测量输入的稳健性，而无法测量随机性。一个只改变种子但固定输入的演示，只能测量随机性，而无法测量分布覆盖率。生产环境会同时触发这两个问题，因此发布前的评估也必须如此。

方差优先的准则：每次发布必备的三个产出物

一个内化了“是方差而非打磨”理念的团队，在任何发布里程碑达成之前，都会产出三样东西。这些都不需要新的工具——它们只需要在交付功能前坚持运行实验的决心。

一份 n-of-k 采样报告。 选取 50 个具有代表性的输入。将每个输入运行 k 次（k 至少为 8，理想情况下为 32）。记录每个输入的：成功率、最差输出、各次运行间的语义多样性（各次运行的结果是否一致，还是大相径庭？）。显著地报告两个数字：预期成功率（所有输入和运行的均值）和最差情况下的用户体验（底部 5% 的运行表现）。如果这两个数字的差距超过两倍，则说明该功能属于高方差，发布计划需要对此进行说明：更严格的重试预算、回退路径、人工接入，或者是一个监控底部 5% 而非均值的受限发布。

一个最差情况输入库。 演示输入从构造上来说就是精选的。其补集——“最差情况输入”——必须刻意去培养。来源包括：来自姐妹产品或 Beta 测试群体的真实用户查询、演示输入的对抗性改写、带有结构性噪声的输入（截断、双重编码字符、语种混合文本）、现有支持工单中的边缘案例，以及团队评估工程师标记为“不符合模式”的输入。这个库与评估套件并存，并随时间增长。新的失败会被添加进去；如果最差情况库的表现未达到预设的底线，功能就不会发布。

一份分布偏移核查表。 演示分布是精选的，而生产分布是全量用户。核查表迫使团队在发布前阐明两者之间的差异。示例问题包括：英语输入与产品服务的其他语种输入的比例是多少？短输入与真实用户发送的长度分布比例是多少？精选集中有多少比例拥有清晰的 schema，对比生产数据中常见的缺失字段情况如何？在演示集中，罕见但关键的意图（如滥用、退款、合规上报）与生产环境相比出现的概率是多少？核查表的输出不是“是/否”，而是一份分布差距列表，发布计划要么消除这些差距，要么将其标记为已知风险。

这三个产出物将对话从“模型好吗？”（这是一个“打磨”导向的问题，答案永远是“再迭代一下”）转移到了“模型在我们将实际面临的情况下是否足够可靠？”（这是一个“方差”导向的问题，其答案是一个数字、一个区间以及一组团队选择接受的已知案例）。

以方差为视角时的发布流程

从“方差优先”思维中延伸出的发布规范虽然看起来似曾相识，但细节与“润色优先”的版本大不相同。

发布是按分位数分阶段进行的，而不是按百分比。一个 10% 的发布如果刚好落在中位数用户身上，在一周内看起来可能运行良好，但当长尾用户最终被抽样进入该群体时，系统就会彻底崩溃。相比之下，具备方差意识的发布会预先定义尾部群体分桶——非英语地区、企业级规模的输入、无障碍用户、低带宽用户——并从第一天起就为每个分桶分配一部分发布流量，并配备独立的仪表盘。团队不再是被动地发现 5% 的用户面临 50% 的失败率；他们从第一天起就在衡量这一点。

指标仪表盘报告的是底层分位数的健康状况，而不只是平均值。当底层 5% 的分位数正处于水深火热之中时，95% 置信区间内的平均成功率看起来依然会很完美。具备方差意识的团队会报告单用户成功率的 p5、p10、p50、p90，并在均值波动之前，先对尾部的波动发出告警。这与十年前延迟监控经历的转变如出一辙——因为平均值会撒谎，p99 成为了 SLO——同样的教训也适用于 AI 质量。

重试策略是感知方差的，而不仅仅是感知瞬时故障。经典的重试假设存在网络波动；如果你重放请求，很可能会成功。LLM 的重试则是重放同一个随机过程，如果某个输入产生了一次畸形输出，第二次也很可能产生类似的畸形输出，因为该模型在该输入下的分布就是那样的。具备方差意识的重试策略将第二次尝试视为一个改变某些东西的机会——例如降级到不同的模型、扩大温度窗口、简化提示词——而不仅仅是再次掷一次骰子。

故障预案将性能倒退视为分布层面的声明，而非模型层面的声明。当模型没有改变时，“Agent 变差了”很少是正确的诊断。正确的诊断通常是“输入分布发生了偏移”——一次营销活动带来了新的用户群体，一次客户成功部门的推广推高了入职引导流量，或者一个特性开关暴露了不同的意图组合。方差优先的故障响应会在动模型之前先检查输入分布。而润色优先的故障响应会立即调整提示词，这往往会使原本正常的群体的方差变得更糟。

组织重构：谁对方差负责？

润色由每个人负责——每个 PM、每个工程师、每个设计师都可以争取“更多润色”，因为润色是一种感觉（vibe）。而方差必须由具备统计素养和测量工具的人负责，但在 2026 年的 AI 功能团队中，这种职责通常是缺失的。如果有评估工程师（eval engineer），他们是天然的负责人，但评估工程普遍人手不足，评估工程师的时间表往往成为路线图上的瓶颈，导致方差报告沦为一个被发布流程忽略的勾选项。

组织上的修复方案是为方差提供一个明确的归属：建立一个发布就绪审查程序，在做出发布决策前，要求提供 n-of-k 报告和分布偏移检查清单，并赋予其独立于急于上线的 PM 之外的否决权。如果没有这一点，方差报告就变成了谁在那周碰巧记得运行一下 pass@k，而“我们测量方差了吗？”的答案将永远是“Demo 看起来棒极了”。

成本架构也值得关注。在 50 个输入上运行 k=32 的 n-of-k 抽样意味着每次发布检查需要 1,600 次推理，按尖端模型的价格计算，这是一笔不容小觑的开支——但它远比发布后因性能倒退而导致的为期六周的紧急抢修要便宜得多，而这种倒退团队本可以在发布前就发现。在 2026 年胜出的团队，是那些将评估算力视为他们能买到的最便宜的保险，而不是将其视为需要优化的开销的团队。

核心结论

Demo 与生产环境之间的差距不是靠润色来弥补的——而是通过接触系统必须处理的实际输入输出分布来拉开的。让高管惊叹的模型在 Demo 与发布之间并没有退化；团队只是用完了精选的输入和精选的运行次数，最终真相大白。

如果你的团队正盯着发布后的性能倒退，而会议内容不断回到“我们需要更多润色”或“模型需要更多调优”，这就是一个信号：没有人测量过方差，团队正在用应对另一类问题的方案来处理当前问题。药方不是更完美的提示词，而是一份 n-of-k 报告、一个最差情况输入库，以及一个将 Demo 视为众多样本之一的发布流程——因为它从来都只是其中之一。