Semver 的谎言：为什么 LLM 的次要更新比重大重构更容易搞垮生产环境

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

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

错误在于将 LLM 的版本视为软件版本。事实并非如此。软件语义化版本（Semver）是一种契约——1.2.3 → 1.2.4 的补丁更新承诺了行为兼容性，打破这个承诺就是维护者必须修复的 Bug。而 LLM 版本则不包含这种契约。输出分布才是真正的 API 表面，而这种分布随着权重的每一次变动、分词器的每一次微调、推理栈的每一次优化而发生偏移。版本号只是营销手段。行为才是你真正依赖的东西，而没有人承诺过会保持其稳定性。

并不存在的兼容性契约

翻开任何主流厂商的弃用说明页，你会发现关于“可用性”的政策——模型何时退役、快照保持可调用的时长、迁移窗口的具体安排。但你几乎找不到关于“行为”兼容性的说明。契约的内容是“你可以在接下来的 N 个月内继续调用此端点”，而不是“下一个版本会对你的提示词做出同样的响应”。

这种差距是结构性的，而非疏忽。即使是厂商也无法给出保证。模型是一个拥有 2000 亿参数的函数，其行为是从训练中涌现出来的；数据配比的微小变化、RLHF 奖励建模或训练后的安全过滤，都会对输出产生非局部的连锁反应，无论是实验室还是评估团队，在发布前都无法完全掌握这些影响。Apple 关于模型更新兼容性的研究为这种现象创造了一个术语——“负向翻转”（negative flips）：即旧模型能处理正确的案例，新模型反而出错了，即便整体准确率有所提升。整体数据掩盖了局部性能退化，而这些退化恰恰就是你生产系统所依赖的东西。

因此，正确的心理模型应该是：每一次模型升级都是一次伪装的破坏性变更。版本号不重要。补丁级别不重要。写着“提升了指令遵循能力”的营销文案也不重要。真正重要的是，联合分布 P(output | your specific prompts, your specific inputs, your specific tool schemas) 是否发生了偏移。而答案几乎总是肯定的。

为什么小幅升级比重大更新更致命

与直觉相反的是，小幅更新往往比重大更新更容易破坏生产环境。这是一种普遍的行为模式，而非某个特定厂商的问题，其反复出现主要有三个原因。

第一个是心理因素。重大版本升级——比如 Claude 3 到 Claude 4，或者 GPT-4 到 GPT-5——会触发组织内部的警报。工程师会重新运行评估。产品经理会安排发布审核。会有相应的预算、上线计划和回滚方案。而小幅升级或日期快照的推进则不会触发这些。它看起来很常规，作为一行配置修改被推送到变更管理流程中。捕捉问题的运行机制是根据版本号来校准的，而不是根据改动的实际影响范围。

第二个是结构性因素。重大版本升级通常伴随着明确的迁移指南，因为厂商知道改动很大。而小幅升级则没有，因为厂商的内部评估显示了整体提升，他们没有理由发出提醒。但实验室的评估套件并不是你的评估套件。MMLU 上的整体收益对于一个分布与基准测试完全不同的客户支持分类器来说，是完全不可见的。版本差距越小，实验室就越倾向于认为这次改动是一次“稳赢”，从而也就越少记录底层的变动。

第三个是别名陷阱。大多数团队并未锁定具体的快照，而是调用 claude-sonnet 或 gpt-4o-latest 这种别名。当厂商发布新快照时，别名会自动升级。锁定快照是一个审慎的工程决策，每当新快照发布时，都需要有人去做决定并重新配置。别名默认是“永远最新”，这意味着别名订阅者会将每一次微小的变动体验为一次即时的、未通知的生产部署，且完全没有灰度发布。这导致了双重糟糕的局面：你既要承受模型更换带来的破坏，又要面对未经授权的配置推送带来的惊喜。

快照之间究竟发生了什么变化

可见的发布说明（release notes）仅描述了实验室认为有意义的内容。实际的增量（delta）通常更大。

加载中…