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

即便是微小的版本升级也可能改变分词器（tokenizer），哪怕是细微的变化——而不同的分词方式会改变 Prompt 的缓存方式，进而改变成本，最终影响你的 Prompt 缓存策略是否依然合理。它可能改变默认的 Temperature 行为、模型处理 system 与 user 角色优先级的方式、拒绝回答的冗长程度、JSON 模式的严格程度，以及在结构化输出周围生成代码块（code fence）的可能性。它还可能改变模型对不确定性的校准——以前返回“我不确定，但是……”的内容，现在可能变成自信的幻觉，反之亦然。

它还可以在不改变 模型 的情况下改变 推理服务（serving）层。新的快照日期（snapshot date）可能会保留相同的权重，但部署了新的 Attention kernel、新的量化方案、不同的投机采样（speculative-decoding）路径，或者在集群负载过高时采用不同的回退策略。从客户端来看，这就像是模型更新，但实际上是具有“模型级影响”的基础设施更新。从外部来看，你无法区分是“权重变了”还是“推理路径变了”，而且实验室通常不会告诉你到底发生了什么。

这意味着，从运维角度来看，“微小更新”这一类别没有任何实质意义。正确的度量单位应该是“我们在 API 调用中发送的版本字符串发生的任何变化”。每一次此类更改都应触发相同的兼容性测试流程，无论这种更改是快照日期的更迭、补丁版本号还是大版本号的变化。供应商的标签不应决定你的发布纪律；你的发布纪律应在评估完成前将所有更改视为破坏性变更（breaking change）。

四层发布纪律​

如果每一次模型更改都是破坏性变更，那么运维层面的应对方案就是让每一次更改都经过相同的发布流水线。四个层级可以涵盖现实中的故障模式。

第一层：固定的评估基准（pinned eval baseline）。 在尝试更改版本之前，必须有一套冻结的测试集，其中包含当前生产版本的已知正确输出。这套测试集不应是供应商的基准测试；它应提取自真实的生产流量，经过去重和过滤，并包含团队历史上曾遇到过的边界案例。评估套件应生成新旧版本针对每个 Prompt 的差异对比（diff），而不仅仅是一个汇总评分。汇总评分会掩盖事实。只有逐条 Prompt 的差异对比才能揭示那些在汇总数据中被抵消掉的性能倒退（regression）。

第二层：影子流量（shadow traffic）。 候选版本与生产版本并行运行，接收相同的输入，但其输出对用户不可见。每个影子输出都会与相应的生产输出一起记录，并通过 LLM-as-judge 或基于规则的检查器，在对业务场景至关重要的维度上进行评分——如 Schema 合规性、与检索上下文的事实一致性、语气匹配、任务完成情况（无多余字符）等。影子运行需要持续足够长的时间，以观察到那些在精选评估集中未出现的长尾输入；通常一周的影子流量就能发现评估套件漏掉的各种性能倒退。

第三层：金丝雀发布（canary rollout）。 一旦影子流量看起来没问题，就将一小部分真实流量（通常从 5% 开始）切流到新版本。监控那些能反映行为变化的运维指标：每个响应的 Token 数、Latency P50 和 P99、下游解析的错误率、工具调用的重试率，以及用户端的信号（如点踩率或会话放弃率）。不要因为评估结果看起来不错就缩短金丝雀观察期。金丝雀发布的全部意义在于暴露评估阶段漏掉的问题。在低比例下进行 48 小时的金丝雀观察，是预防长达数日的回滚成本的廉价保险。

第四层：真实的回滚路径。 “回滚”不能意味着“修改配置并重新部署”。它必须意味着“切换一个 Flag，流量在 5 分钟内切回固定版本”。这要求将之前的版本保持固定且处于热备状态（warm）——不是被弃用，不是在内部下线，而是以积极的状态保留在路由表中——直到新版本在 100% 流量下运行了足够长时间并获得你的信任。保持旧快照热备的成本很小，而当故障发生时无法立即回滚的代价则是整个事故本身。

只有当每一层都实现自动化时，这种纪律才有效。手动评估无异于直接发布性能倒退。如果影子运行需要人工读取日志，那么影子运行就不会真正落地。在下一次微小升级到来之前——而不是在升级过程中——就建立好差异对比工具、评判框架（judge harness）和金丝雀指标仪表盘。

组织架构的影响​

将模型版本升级视为破坏性变更会带来工程负责人经常低估的组织成本。这意味着模型升级不能是一个工程师就能完成的任务。这意味着评估套件必须由专人负责维护，并在其失效时承担责任。这意味着必须有人负责关注供应商的发布动态并触发发布流水线。这意味着回滚路径要定期演练（消防演习），以便在关键时刻形成肌肉记忆。

不这样做的团队并没有规避成本，而是在通过事故支付成本。工程论坛上每一个“模型一夜之间变笨了”的讨论帖，背后都是一个承受了未宣布的行为变更的团队，因为他们的版本跟踪纪律假设供应商会提醒他们。供应商没有提醒，因为在现有的合同约束下，并没有什么需要提醒的。现有合同与团队 假设 存在的合同之间的差距，正是生产环境发生故障的温床。

更健康的认知模型是：LLM 供应商不是类库（library）厂商。它更像是一个行为会按自身节奏变化的托管服务，类似于一个不提供版本化响应的第三方 API。如果没有契约测试（contract tests）、重放日志（replay logs）和回退路径，你绝不会针对第三方 API 部署关键工作流。同样的本能也适用于模型版本，而供应商提供给你的版本字符串，恰恰是你最不应该信任的部分。

将版本字符串视为常量，而非变量​

最彻底的思想转变是停止将模型版本视为一个不断更新的变量。将其视为代码库中的一个常量。当该常量发生变化时，这就是一次代码变更。它应当经历与数据库迁移相同的评审流程：明确的决策、评估、分阶段发布、文档化的责任人以及回滚计划。版本字符串的承重能力丝毫不亚于 SQL Schema，如果假装不是这样，团队迟早会发现摘要生成器从昨天开始莫名产生幻觉，却没人知道原因。

语义化版本（semver）的谎言确实方便。它让团队能以“保持最新”的名义快速推进。但这种谎言的代价是，生产环境变成了供应商发布节奏的函数，而不是团队自身的发布节奏，团队由此交出了关乎可靠性的唯一杠杆。夺回主导权。固定快照（Snapshot）。运行评估（Eval）。进行金丝雀发布（Canary）。今晚在生产环境中运行的模型应该是团队今天早上批准的那一个，而不是供应商在大家熟睡时推出的任何一个。