你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 API 的预发布副本。三十年来，整个预发布（pre-production）学科都建立在一个假设之上：你可以创建一个足够忠实于生产环境的副本，对其进行测试，并从中了解到发布后会发生什么的真实情况。
然后，你将托管模型添加到了关键路径中，这个假设便悄然瓦解了。那个现在主导你产品行为的组件——决定你的应用实际上在说什么、做什么的那个东西——正是你无法搭建预发布副本的唯一组件。它由别人进行版本管理，由别人进行速率限制，并由别人按照你无法察觉的时间表悄悄更新。你的预发布环境拥有一切的预发布副本，唯独没有预发布模型。
大多数团队直到遇到第一个预发布环境本该捕获却没能捕获的故障时才会注意到这一点。该功能周二在预发布环境中运行正常。周三发布。周四在生产环境中表现异常，而当你周五回到预发布环境尝试重现时，预发布环境却表现正常——因为预发布环境底层的模型也发生了变化，现在这两个环境都与实际发生 Bug 时的环境不匹配了。就在那一刻，这种安逸的假象崩塌了：预发布环境从未针对真正的决策者进行演练。它只是在针对一个移动的目标进行演练，而这个目标恰好静止了足够长的时间，欺骗了你。
“预发布”到底是为了什么
明确预发布环境能为你带来什么是很有帮助的，因为模型会以不同的方式打破每一项保证。
预发布为你提供可复现性（reproducibility） ：相同的输入产生相同的输出，因此你看到的 Bug 也是你可以追踪的。它为你提供隔离性（isolation） ：你可以对其进行压力测试，而不会触及真实的客户或真实的资金。它为你提供一致性（parity） ：它足够接近生产环境，因此预发布环境的成功预示着生产环境的成功。它还为你提供了一个演练空间（rehearsal surface） ：在代码进入生产环境之前，运行与生产环境完全相同的代码路径。
托管模型从本质上违反了其中的第一点和第三点。可复现性消失了，因为即使输入固定，模型也是不可预测的（nondeterministic），而且更糟的是，端点背后的权重可能会在没有任何你察觉的版本升级的情况下发生变化。一致性也消失了，因为在预发布和生产环境中使用“相同的模型”只是名称上的一致，而不是名称背后构件（artifact）的一致。你将两个环境都指向 gpt-4o 或 claude-sonnet-4 并假设 它们解析为相同的东西，就像你假设两个指向 Postgres 15 的环境运行的是同一个 Postgres 一样。事实并非如此。别名化的模型端点只是一个符号链接（symlink），供应商可以随时重新定向。
隔离性基本得以保留——你可以使用单独的 API 密钥、单独的速率限制桶、测试租户。演练空间部分保留。但是，使预发布环境在认识论上有用（epistemically useful） ——即它能可靠地告诉你关于生产环境的真相——的两个特性，恰恰被模型剥夺了。
无论你是否喜欢，你都将继承的三个差距
环境间的版本偏差。 如果预发布和生产环境都调用同一个别名，那么在供应商轮换默认版本的瞬间，它们就会悄无声息地产生分歧。你没有部署任何东西。没有人动过配置文件。然而，预发布环境现在正在测试模型 A，而生产环境运行的是模型 B，你的代码仓库中没有任何 diff 能解释为什么行为发生了变化。这就是大语言模型（LLM）版本的“在我的机器上运行正常”，只不过这台机器是一个你不拥有的数据中心，而且这种漂移在它产生负面影响之前是不可见的。每个人最终都会学到的缓解措施是在每个 环境中固定不可变的快照 ID（例如 gpt-4o-2024-11-20，而不是 gpt-4o），并将模型版本的更改视为一次部署——经过审查、预发布并有意识地逐步推出。固定版本并不能给你一个预发布模型。它只是让这种偏差变成一个决定，而不是一个意外。
无法复现以进行调试的行为。 当用户报告助手说错了一些话时，经典的循环是：获取输入，在预发布环境中重放，观察失败，修复，观察通过。对于托管模型，这个循环在第二步就断了。你重放输入，模型却给出了一些虽然不同但同样合理 的回答，所以你甚至无法确认你看到的是否是同一个 Bug。而且，如果故障依赖于一个已经轮换的模型版本，那么产生 Bug 的构件就不再存在于任何你可以触及的地方。你正在调试一个已经被高压水枪清洗过的犯罪现场。
在供应商已经轮换的快照上通过的评估（Evals）。 你的评估套件显示为绿色。它昨晚针对模型运行。但昨晚的“模型”和今天下午的“模型”可能有所不同，你的绿色勾号只是一个已经不复存在的状态的照片。团队将评估结果视为其“提示词+代码”的属性，而实际上它们是“提示词+代码+特定时间点的特定模型实例”的属性。去掉最后两个项，评估衡量的东西就比你想象的要少。
替代方案 —— 以及每种方案无法弥补的缺陷 行业已经趋于采用几种不完整的解决方案。没有一种方案能重建预发布模型 (staging model)；每种方案都只弥补了鸿沟的一小部分，而我们有必要诚实地面对它们各补全了哪一部分。
固定版本 (Pinned versions) ，在供应商允许的情况下，可以恢复跨环境的一致性 。如果 staging 和 prod 都固定使用 claude-sonnet-4-20250514，它们至少会指向同一个工件 (artifact)，而版本差异变成了你主动选择的结果，而不是被动承受的意外。固定版本无法弥补的是：快照是有保质期的。供应商会按照自己的时间表弃用固定版本 —— 在实践中，从发布通知到正式停用的时间窗口从几个月到短短两周不等 —— 因此，“永久固定”是不可能的。固定版本为你赢得了一段时间的稳定目标，但不是永久的。
录制并回放响应 (Recorded-and-replayed responses) —— 借鉴自 HTTP 测试的 VCR / 磁带模式 —— 为你的 CI 恢复了确定性 。你捕捉一次模型的真实响应，将其保存为测试固件 (fixtures)，并在后续的每次运行中回放。现在，只有当你的 输入发生变化时，测试才会失败。这让它们在捕捉提示词退化以及工具调用和控制流中的逻辑漏洞方面表现出色，且 API 成本为零，稳定性百分之百。回放无法弥补的是：它是一张照片，而不是一面镜子。它无法告诉你当前 模型的行为，因为从定义上讲，它并没有调用当前的模型。回放测试套件可以是 100% 通过的，而生产环境中的模型可能已经发生了漂移 —— 录制的内容恰恰无法察觉到漂移。
黄金副本 (Golden transcripts) 恢复了人类可读的基准 。你保留一组精心挑选的、具有代表性的对话及其预期形式，并将新的运行结果与它们进行对比。它们是发现重大行为变化的良好触发线。它们无法弥补的是：覆盖率。黄金副本捕捉的是你已经想到的行为。而那些真正致命的退化 —— 语气的转变、新的冗长倾向、模型在处理输入分布中模糊地带时发生的微妙变化 —— 是没有人编码记录的，因为如果你能想到这些，你早就已经处理好了。
针对真实模型的影子流量 (Shadow traffic) 恢复了对等性 ，而且它是唯一能做到这一点的替代方案。你将生产环境的一部分真实请求镜像到候选模型或版本中，记录两者的输出并进行比较 —— 且永远不会将影子响应展示给用户。这是现存最接近预发布模型的东西，因为它就是 真实的模型，运行在真实的输入上，只是它的输出被发送到了日志而不是客户那里。影子流量无法弥补的是：它存在于生产环境中。当你能够运行它时，你已经部署了你想要演练的东西。它是一个绝佳的安全网，但却是一个糟糕的排练舞台。你无法对尚未产生生产流量的功能进行影子测试，你也无法在发布某些东西 之前，用它来回答“发布这个是否安全”。
将它们排开，结论就很清晰了。固定版本解决了一致性但没解决永久性。回放解决了确定性但对漂移视而不见。黄金副本解决了可读性但没解决覆盖率。影子流量解决了对等性，但只能在发布后进行。每一个都是实用的工具。但没有一个是预发布模型，即使把这四种方案堆叠在一起，中间仍然留有一个空洞：在进入生产环境之前，没有一个地方可以让你确定地在生产环境将使用的完全相同的模型工件上运行完全相同的代码，并获得能够保证成立的结论。对于所有其他依赖项，这个地方曾经是存在的。但对于模型，它不存在。
针对“空洞”进行工程化，而不是假装它已消失 失败的模式并不在于这些替代方案太弱。而在于团队采用其中一种后，感受到了流水线全绿带来的熟悉温暖，于是又悄悄带回了那个旧假设：即预发布环境全绿意味着生产环境安全。真正有效的准则始于拒绝这种心理安慰。
将模型版本视为已部署的工件，而不是配置。在所有地方固定快照版本，记录每一个生产输出源自哪个快照，并将模型版本的升级流程置于与代码更改相同的评审、金丝雀发布和回滚路径中。当你无法复现 Bug 时，第一个问题应该是“是哪个模型版本产生的 Bug，以及该版本是否还存在” —— 因为有时诚实的回答是该工件已经消失，该 Bug 从结构上来说是无法复现的，意识到这一点能让你免于在预发布环境中浪费一天时间去捕风捉影。
根据各自的擅长领域对替代方案进行分层，而不是希望某一种方案能覆盖所有领域：在 CI 中使用回放和黄金副本，以低成本、确定性地捕捉你的 退化；在固定模型上进行实时评估，有目的地衡量模型的当前行为；在生产环境中使用影子流量，将其作为因为 预发布对等性无法实现而进行的对等性检查，而不是作为事后的补救措施。当你升级模型时，要假设基准测试分数的提升几乎无法告诉你用户真正依赖的涌现行为发生了什么 —— 将旧版本保留为实时对照组，让真实流量而非预发布环境来投出决定性的一票。
一个令人不安的事实是，对于现代 AI 产品中最重要的依赖项，预发布环境不再是一个可以完全演练的地方。它是一个降低风险的地方，然后你需要在系好安全网的情况下，在现场观众面前完成最后的演练。Staging 并没有消失。它只是不再是最后一道防线，而那些能够可靠交付的团队，是那些将真实验证转移到真实模型所在地 —— 即受到严密监控且具备快速回滚能力的生产环境 —— 的团队。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
