7 篇博文 含有标签「model-versioning」

你的事故时间线显示“过去 72 小时内没有部署”。你的 Prompt 注册表也印证了这一点：prompt v37 已经冻结三周了。你的评估工具链在周二晚上运行正常。但在周三早上，你其中一个 Agent 的结构化输出失败率翻了三倍，另一个 Agent 的重试预算翻了一倍，而第三个 Agent 开始愉快地忽略一条它已经遵守了一个月的指令。什么都没变。除了确实有东西变了，而且变在组织中两边都没盯着的地方：模型。

Prompt 注册表记录 Prompt 版本。模型网关记录模型版本。但在实践中，几乎没有人追踪这两者的“配对”关系。Prompt v37 并不是一个独立的工件——无论你的工具链是否承认，它都是一份针对特定模型协商后的契约。当平台团队将 claude-sonnet-latest 别名向前推进一个补丁版本时，另一端的契约已经被悄悄修改了。由于部署发生在别人的基础设施上，且名称未变，你的事故时间线依然显示“没有部署”。

一个客户支持工单在周二送达。客户附上了一张你的产品在 6 周前生成的输出截图。他们声称该输出是错误的、不安全的，或者根本不符合预期，并要求修复。你的支持工程师将提示词粘贴回同一个 API 终端，得到了一个清晰、合理的回答。就系统目前的状态而言，这个 Bug 并不存在。

Bug 是存在的，但产生这张截图的模型已经不在了。自从客户提交工单以来，你的 v1-chat 终端背后的权重已经更换了两次——一次是为了提升质量，一次是为了优化成本——而原始的检查点（checkpoint）已无法访问。客户的“这东西坏了”现在成了一个针对变动目标的无法证伪的断言，支持团队既无法确认它，也无法关闭它。

这不是一个古怪的边缘案例。这是将模型版本控制视为内部 MLOps 问题，而非客户可见的产品合约的必然结果。终端 URL 是稳定的，但它背后的产物（artifact）却不是。在你的支持流程、保留策略和客户合约承认这一差距之前，每一个针对已轮换检查点的 Bug 报告都会掉进同一个分类真空区。

一个团队以 70% 的准确率发布了某个 AI 功能。十八个月过去了。用户起初抱怨，随后逐渐适应。他们学会了哪些提示短语能绕开边缘情况，知道了涉及日期的输出需要二次核查，因为 AI 有时会产生特定字段名称的幻觉，所以他们在工作流中加入了验证步骤。然后团队发布了新模型，准确率跃升至 85%。支持工单激增。投诉最多的用户，恰恰是那些最重度使用该功能的人。

这就是"准确率即产品契约"问题，而且大多数 AI 团队都是以惨痛的方式发现这一点的。

在 AI 工程领域流传着一个隐秘的神话：模型的一次“小幅”升级——比如 claude-x.6 到 claude-x.7，或者 gpt-y.0 到 gpt-y.1，甚至是按日期推进的补丁级快照更新——都应该是无缝替换的。厂商发布的更新日志里谈论着推理能力的提升、更低的延迟以及更好的工具调用。版本号轻轻跳动，没有任何迹象表明这些改动会破坏现有系统。

然后更新上线了。值班频道随即被各种警报点亮：摘要生成器莫名其妙多出了一段以前没有的话；JSON 提取器开始对以前不处理的 Unicode 字符进行转义；Agent 循环在以前只需三次调用就能完成的任务上，现在却触碰到了最大步数限制。从整体上看，评估得分似乎没什么问题，但用户可见的功能却在细微之处出了错。

某家厂商在周二下午向模型别名推送了一个“小幅更新”。到了周四，四家客户公司正在进行事件响应。他们本周都没有部署代码。他们的仪表板上没有任何关于延迟、错误率或任何其他基础设施维度的指标退化。改变的是，在他们固定的别名背后的模型开始返回略有不同的句子、略有不同的 JSON 以及略有不同的拒绝——而他们的团队针对旧行为编写的每一个提示词（Prompt）现在都成了一份没人履行的合约。

这种不对称性就是问题的核心。供应商将这次发布视为一次部署：经过内部测试，通过了一些聚合评估，并在维护窗口内逐步推向 100%。而消费端将其视为一次语义化版本（semver）违规：一个依赖项在生产环境中自动升级，却没有更改其版本字符串，随后最终用户的错误报告接踵而至，主题还带着轻快的“我们这边什么都没改”。

当 OpenAI 在其较新的模型中弃用 max_tokens 而改用 max_completion_tokens 时，已经稳定运行了数月的应用程序开始返回 400 错误。没有任何公告触发警报，你的代码中也没有错误。模型改变了，但你的假设没有变。这是将模型升级视为破坏性变更（Breaking Change）的典型案例 —— 只不过大多数变更更加隐蔽，因此更难被发现。

基础模型的更新并不遵循与库发布相同的“社会契约”。Git 提交中没有 BREAKING CHANGE: 前缀。没有语义化版本（SemVer）的提升来告知你的 CI 流程去报错。输出格式变窄、语调偏移、JSON 结构重组、推理路径缩短 —— 下游消费者是通过逐渐恶化的用户体验和混乱的数据分析慢慢发现这些问题的，而不是通过抛出的异常。

你的生产系统运行正常。可用性为 99.9%。延迟处于正常水平。错误率告警为零。然后一个用户提交了一个工单：“最近的摘要变得莫名其妙地偏差。”你调取日志，一切看起来都没问题。你检查模型版本 —— 还是三个月前部署的那个。到底发生了什么变化？

是模型提供商变了。而且是悄无声息地变了。

这就是模型升级陷阱：基础模型在你不知情的情况下发生了变化，而标准的观测基础设施对这种行为偏移（behavioral drift）完全视而不见。等到用户注意到时，性能下降已经持续累积数周了。