没有预发布模型的预发布环境

你可以搭建一个预发布数据库。你可以搭建预发布队列、预发布支付沙箱，以及你所依赖的每一个第三方 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 的构件就不再存在于任何你可以触及的地方。你正在调试一个已经被高压水枪清洗过的犯罪现场。

加载中…