模型更新如何破坏 LLM 的可复现性

Vincent Schmalbach 2026-08-13T06:47:18.657987

2026年8月11日 · Vincent Schmalbach

大语言模型（LLM）会根据提示词生成文本、结构化数据、代码或工具调用。但托管的 LLM 并不是提示词文本的固定函数：服务商可以在不修改调用方代码的前提下，更换模型、安全控制、路由策略、API 行为或服务基础设施。

我是在开发 vroni.com 的过程中写下这篇文章的。这是一个 AI 编码工具，可以把任务直接变成 pull request。

上面提到的那些变化，可能导致后续运行返回不同的答案、拒绝、JSON 对象、工具动作、分类结果或研究结论。把 temperature 设为 0、固定随机种子、使用带日期的模型标识，确实能减少一部分差异，但都无法保证托管 LLM 工作流可以永久重放。要实现可复现性，必须对整个推理依赖链路做版本管理和测试，而不仅仅是保存提示词。

先明确三类可复现性目标

在 LLM 讨论中，「可复现性」这个词常常被用来描述几种不同的目标。把它们区分开，可以避免把某个有限的控制手段误当成完整的解决方案。

逐字重放文本是其中一个可能的目标，但正确的要求取决于具体工作流：创意写作可以容忍措辞变化，代码生成服务可能要求编译和测试结果一致，安全分类器可能要求标签保持稳定，而 Agent 可能要求工具参数合法、动作安全。

仅靠提示词日志，无法唯一确定一次 LLM 执行的具体情况。一个更有用的模型是：

\text{output} = F(
\text{model version},
\text{weights},
\text{system behavior},
\text{decoding},
\text{tools and retrieval},
\text{serving stack},
\text{request}
)

解码设置（decoding settings）决定模型如何选择 token，包括 temperature、top-p、最大输出长度和随机种子。检索（retrieval）是指获取外部文档或记录，再把它们补充进提示词。服务技术栈（serving stack）则包括推理框架、硬件、数值精度、批处理、路由，以及相关基础设施。

一个完整的执行记录，不能只记模型系列名和 temperature 值。还需要记下：客户端请求的模型标识符（model identifier）、服务商返回的模型标识符、系统指令（system instructions）和开发者指令（developer instructions）、渲染后的输入、解码参数、工具（tools）、检索到的内容、API 和 SDK 版本、响应 ID，以及后处理行为。

固定随机种子（seed）只能锁定执行时的某一个输入，它并不能冻结模型权重、隐藏指令、工具结果或服务商的底层基础设施。同理，像 gpt-4o 或 model-family-default 这样的模型名，也可能指向一个会变动的别名（moving alias），而不是一个稳定不变的产物。

识别服务商侧的变更

托管的 LLM 一旦更新，可能在多个层面改变行为。服务商不需要改动客户端的提示词或代码，实际生效的函数就已经变了。

动态别名取代稳定引用

别名指向的是一个部署（deployment），而不是唯一标识某个不可变的模型产物。latest、default 这类名字，或某个系列级别的标识符，用起来虽然方便，但服务商随时可以把它们重新指向别处。

时间线是这样的：

1. 1 月份，实验调用 model-x-latest。
2. 3 月份，服务商更换了别名指向的目标。
3. 4 月份，同样的代码、同样的提示词和 temperature 再次运行。
4. 4 月的结果反映的是新目标的行为，不一定还是 1 月份那个模型。

Google 明确区分了稳定的 Gemini 模型名和 latest 别名——后者会随着新版本发布被热替换。代码没变，只能说明请求没变，并不能说明依赖没变。

带日期的快照（dated snapshot）更安全，因为它把模型身份限定得更窄。OpenAI 也把 dated snapshot 描述为一种锁定特定版本、以获得更一致行为和性能的方式。不过，快照依然不保证永久可用，也不保证托管执行的结果逐位一致。

每次请求，这两个值都要记：

• 客户端提交的模型标识符；
• 服务商元数据里返回的模型标识符。

第二个值能帮你发现客户端并没有主动请求过的别名解析、路由或部署变更。

权重与后训练如何改变概率

模型提供商可以通过额外训练、指令微调、强化学习、安全微调，或者修改推理行为来调整模型权重。这些改动会改变模型在可能输出上的概率分布：

P_{\text{old}}(y \mid x) \ne P_{\text{new}}(y \mid x)

把温度（temperature）设为 0 并不能抵消这种变化。它只是让当前响应请求的模型选出概率最高的续写内容，从而减少采样带来的随机性。如果一次更新改变了最可能的 token（词元），那么确定性解码在新模型下就会给出不同的结果。

这种变化影响的远不止事实类回答，还可能改变：

• 模型是否遵循某条特定指令；
• JSON 响应中字段的顺序或内容；
• 生成的代码能否直接运行；
• 模型会选择哪个工具；
• 模型给输入打标签时的置信程度；
• 模型是否会拒绝主观或涉及安全敏感的请求。

安全与管控层同样改变语义

生产环境中的模型行为，不只是由神经网络权重决定的。提供商还可以改动隐藏的系统指令、内容审核分类器、策略执行逻辑、拒绝机制、警告提示、工具权限以及输出后处理。

一次安全更新可能改善了对有害内容的处理，但也可能破坏某个原本期望直接回答的工作流：之前会返回分类结果的模型，之后可能直接拒绝作答。代码生成接口可能把原本让解析器直接读取的代码，额外包上一层解释性文字。工具调用服务也可能开始拒绝此前一直接受的参数。

Chen、Zaharia 和 Zou 对 GPT 的纵向研究发现，GPT-4 在 2023 年 3 月和 6 月两次测量之间，对一项意见调查的响应率从 97.6% 降到了 22.1%。作者认为，部分变化源于模型对主观问题的拒绝明显增多。这个结果说明的是兼容性漂移（compatibility drift），而不是后来的行为全面变差。这项经过同行评审的研究，测量的是特定条件下的特定任务。

API 契约与默认参数会变

即便生成的文字看上去差不多，一次更新也可能改变模型周边的接口。相关变化包括：

• 结构化输出的强制方式；
• 工具调用格式与参数校验；
• 上下文长度限制；
• 分词方式；
• 默认采样参数；
• 推理控制项；
• 被移除或重新定义的参数；
• 停止条件；
• API 版本要求。

微软将模型版本与 API 版本分开管理，并提醒升级可能影响行为和兼容性。如果应用依赖合法 JSON、特定 schema 或稳定的工具调用格式，那么它可能在完全没有 HTTP 错误或类型错误的情况下，出现语义层面的失败。

举例来说，模型可能返回语法上合法的 JSON，但某个字段的含义已经变了。解析器能正常接受，下游业务规则却会做出错误判断。而只检查“是否成功响应”的冒烟测试，根本发现不了这类问题。

基础设施带来额外漂移

即使名义上的模型权重没变，服务栈也可能改变输出。相关因素包括：

• GPU 类型；
• 数值精度；
• 量化方式；
• 推理框架；
• 内核实现；
• 动态批处理；
• 分布式执行；
• 请求路由。

量化会降低模型参数或中间值的数值表示精度。精度与内核的变化会轻微改变计算结果，而很小的概率变化又可能影响后续生成的 token 或决策。

2026 年的 DriftBench 研究评估了 236,985 组“提示-响应”对，覆盖 105 种配置，涉及五个模型、四种 GPU 平台、三种框架和三种精度。结果显示，硬件与精度变化会带来系统性漂移；此外，在一次高漂移升级后，生产环境验证中“安全/不安全”标签的翻转率达到 23.85%。这些发现来自已发表的 MLSys 会议论文，但并不能据此推断所有基础设施都存在统一的漂移率。

闭源 API 通常不会暴露足够的信息，让人难以判断到底是哪一层导致了观测到的变化。前后对比测试可以确认漂移确实发生，并衡量它在运行层面的影响，但很难证明是权重、安全控制、路由、精度还是硬件造成的。

模型退役后无法重跑

服务商可以在提供一段时间后，将某个带日期的模型快照退役下线。到那时，即使实验记录得再完整，也只能依靠归档输出进行审计，无法再重新运行。

Amazon Bedrock 明确记录了模型的几种状态：活跃（Active）、遗留（Legacy）和终止支持（End-of-Life）。进入终止支持状态的模型不再可用，向该版本发出的请求可能直接失败。Microsoft 同样公布了模型退役和自动升级的策略。固定版本部署能在模型退役前提升稳定性，但它不等于永久存档。

PNAS Nexus 上关于专有模型的讨论，把这个问题归结为"过程可复现性"难题：当研究者需要验证结果时，历史模型状态可能已经无法访问。

长期测量行为漂移

最有力的直接证据来自纵向评估：对不同版本或不同服务日期的模型，运行相同或等价的任务进行对比测试。

历史 GPT 测量数据

同行评审研究《How Is ChatGPT's Behavior Changing Over Time?》对比了 GPT-3.5 和 GPT-4 在 2023 年 3 月与 6 月版本的表现，覆盖八个任务类别。结果显示，相同的任务设计并不能保证相同的行为：

这些数据描述了该研究的提示词、任务、访问条件，以及 2023 年 3 月与 6 月的对比情况。它们表明托管模型的行为会随时间变化；但该研究并没有为所有服务商或模型确立当前的通用漂移率。

漂移不等于退化

一次更新可能改善某些任务，同时让另一些任务变差。它可能提高事实准确性，却降低结构（schema）有效性；可能增加拒答率、改变校准度，或者生成更少可执行的代码。安全更新同样如此：在减少不安全回答的同时，可能增加误拒答。

可以站得住脚的一般性结论是“行为漂移”（behavioral drift），但要说整体退化，就得围绕应用目标做更全面的评估。在真正重要的结果维度上，比较候选版本和现有版本：

• 标签准确率和标签翻转情况；
• 拒答率和误拒率；
• JSON 结构合法性；
• 代码能否编译、单元测试是否通过；
• 工具参数是否合法；
• 引用覆盖范围；
• 不安全操作发生率；
• 延迟和成本。

单看一个基准测试分数，或者某一次输出的主观印象，都无法判断一次模型更新对生产流程到底是好是坏。

固定随机种子并不能保证可复现

即使在模型更新发生之前，可复现性本身就有自己的失败模式。2026 年的一篇预印本论文《Same Prompt, Different Answer: Exposing the Reproducibility Illusion in Large Language Model APIs》（同样的提示词，不同的答案：揭露大语言模型 API 的可复现性错觉）报告了涉及 8 个模型、5 家 API 提供商的 4104 次受控实验。结果显示，在温度设为零、随机种子固定的条件下，API 托管的模型重复生成相同输出的概率只有 22.1%，而本地部署的模型则能达到 95.6%。

这项结果尚属初步结论，因为它是预印本，且结论依赖于所测试的提供商、配置以及“完全一致”的定义。它能支撑的结论比较有限：固定种子和温度为零，并不能保证托管 API 一定返回逐字节相同的输出。对这份预印本的证据，不应视为已定论的共识。

把大语言模型当作语义依赖来对待

传统软件依赖升级时，往往通过接口的显式变化暴露出问题：某个方法没了、类型对不上了，或者回归测试失败了。

而大语言模型的更新，API 接口看起来一切如常，应用的语义却可能悄然改变：

• 返回的 JSON 依然合法，但里面的值不对或变了；
• 工具调用换了个工具，或传入了非法参数；
• 原本能回答的问题，现在变成了拒答；
• 排序结果发生变化；
• 生成的代码无法编译了；
• 统计抽取得到了不同的聚合值；
• 安全标签出现了翻转。

这样一来，LLM 升级更像是一次语义层面的依赖变更，而不是普通的库替换。服务商可能保持端点和响应结构不变，但响应的实际含义已经变了。

托管服务还削弱了可观测性。调用方看不到隐藏的系统行为、路由决策、推理二进制文件、硬件配置，也拿不到完整的变更日志。开放权重模型则更容易归档——运营方可以保存权重并独立重新运行。但这并不能消除分词器版本、量化、精度、硬件、框架、提示词格式或服务配置带来的漂移。

因此，即使服务商声称没有破坏 API 兼容性，一次 LLM 更新也是一次发布事件。正确的应对方式是对照应用的实际输出结果做兼容性测试。

构建可复现的 LLM 工作流

当每一项关键输入和依赖都变得明确、有版本、可测试时，可复现性就会得到改善。

固定模型版本，记录服务商元数据

研究基线或严格的回归测试目标，应使用最精确的模型标识符。除非"自动更新"是明确需求，否则避免使用 latest、default 或系列别名。

需要记录的信息包括：

• 服务商和端点；
• 区域；
• 请求的模型 ID；
• 返回的模型 ID；
• UTC 执行时间戳；
• API 版本；
• SDK 名称和版本；
• 部署方式和自动升级策略；
• 响应 ID 及相关的错误响应。

固定版本可以防止别名意外指向新模型，但并不能保证永久访问、在不同基础设施上精确重放，或独立重建。

创建机器可读的清单（manifest）

清单的作用是区分"模型漂移"和"工作流其他环节的变更"。应包含：

• 渲染后的系统、开发者和用户提示词；
• 提示词模板的哈希值或不可变副本；
• few-shot 示例；
• temperature、top-p、seed、token 限制及推理设置；
• 工具定义和工具结果；
• 输出模式的版本号；
• 检索到的文档、语料库版本、嵌入模型和索引版本；
• 请求负载、重试策略、超时设置和响应 ID；
• 原始输出的存储位置；
• 解析器和后处理脚本的版本。

保存渲染后的完整请求，而不只是模板。即使模板本身不变，模板变量、检索到的上下文和工具结果都可能改变实际输入。

分开保存原始结果与解析结果

在解析之前保存原始响应，同时记录：

• 解析后的输出；
• 工具调用和工具结果；
• 检索到的文档及排序；
• 下游决策；
• 人工审核或覆盖操作；
• 错误和重试行为。

把原始响应和解析输出分开保存，遇到后续结果不一致时，才能判断问题出在模型，还是解析器、模式校验器、业务规则或重试路径上。

把每次更新当作候选版本来测试

在切换生产流量之前，让现有版本和候选版本都跑一遍固定的回归测试套件。测试要覆盖常规、边界、对抗性、多语言、安全敏感和高价值场景。

评估指标要和输出类型匹配：

精确字符串匹配适合部分结构化字段，但对很多自然语言任务来说过于严格，对另一些任务又过于宽松。如果语义相似的答案改变了安全标签或财务决策，那它就不能算作可接受的等价结果。

在条件允许时，用影子流量、金丝雀发布或分阶段上线来部署通过的候选版本。上线后继续监控生产环境表现，并在生命周期规则允许的期限内保留回退路径。NIST AI 风险管理框架也建议对第三方 AI 依赖做文档化测试、生产监控和应急预案。

对周边系统做版本管理

如果其他依赖漂移，光固定模型版本也无法复现工作流。以下内容都要纳入版本管理：

• 提示词和少样本示例；
• 分词器和聊天模板格式；
• SDK 和 API 版本；
• 工具定义与实现；
• 检索语料库和索引；
• 嵌入模型和重排序模型；
• 输出解析器；
• 业务规则；
• 评测数据和评分代码；
• 运行环境。

应用层面要问的不是“文本是否逐字一致”，而是“工作流是否保住了我们关心的结果和失败率”。

回答实际问题

温度归零能让 LLM 可复现吗？

不能。温度归零只能降低当前处理请求的模型内部的采样波动，无法在权重、隐藏指令、安全行为、路由、工具或服务基础设施发生变化后，继续保持输出不变。固定随机种子（fixed seed）可以作为有用的元数据，但它并不能保证托管服务的输出逐字节一致。

latest 别名适合生产环境吗？

只有当「自动获取新版本」比「行为稳定」更重要时，才适合使用。对于研究、基准测试、受监管的工作流和严格的回归目标，建议改用带日期的快照或受控部署。Google 的文档也明确指出，latest 别名会随新版本发布而被热切换。

固定到带日期的快照能解决可复现性吗？

可以防止因别名漂移导致的意外变更，也方便做受控测试。但它不能保证快照无限期可用、跨基础设施逐位一致地执行，也无法做到独立重建。请务必保留原始请求和输出，因为提供商之后可能会停用该快照。

团队应该避免模型更新吗？

不应该。更新可以带来准确性、安全性、能力、延迟或成本上的改进。正确做法是把每次更新当作一个候选版本，先在冻结的应用数据上与当前版本做对比评估，再逐步部署上线，并持续监控相关指标，同时记录下改进之处和回退情况。

委派任务，交付软件

查看原文