16. 模型版本升级（如 GPT-4 → GPT-5、Claude 3.5 → Claude 4）你会怎么迁移？

简单回答

模型版本升级不是"改个 API 名字"——新模型的输出风格、对 Prompt 的反应、tokenizer、latency 特性、价格、限流配额都会变，每一项都可能引发线上回归。我的迁移流程是：先离线对一组金标准 query 跑 A/B 评估明确质量变化；如果质量持平或更好，再做小流量灰度看真实用户指标；同时回归测试 Prompt 和工具调用（新模型对相同 Prompt 可能有不同遵守度）；最后阶梯放量并保留旧模型作为快速回滚通道。整个过程通常要 1-2 周。最容易翻车的不是模型本身，而是 Prompt 适配、Prompt Caching 重新预热、tokenizer 变化导致的限流配额错位、以及 Provider 自己的 SLA 抖动。

详细解释

为什么模型升级比想象中复杂

很多人第一反应是"新模型更好，把 model 参数从 gpt-4 改成 gpt-5 不就行了"。在生产里这么做几乎一定翻车。原因有几类：

输出风格变化。新模型可能更啰嗦/更简洁、更倾向 markdown 格式/更倾向纯文本、更喜欢用 bullet points/更喜欢段落写作、更礼貌/更直接。这些风格变化对依赖固定输出格式的下游解析（提取字段、渲染卡片、JSON 解析）是直接破坏。

指令遵循程度变化。同一段 System Prompt 在不同模型上效果可能差很多。新模型对"请用 200 字以内回答"可能更严格也可能更松；对 Few-shot 示例的模仿可能更精准也可能更跳脱；对"不要做 X"这种否定指令的遵守度可能完全不同。

Tokenizer 变化。GPT-3.5 → GPT-4 的 tokenizer 几乎一致，但 GPT-4 → GPT-5 可能换 tokenizer，Claude 3 → Claude 4 也可能换。同一段中文文本在新 tokenizer 下 token 数可能变 ±20%。这对成本预估、限流配额、长度截断逻辑都有影响。

价格和限流。新模型通常更贵，且初期限流配额低（Provider 给新模型的容量需要逐步释放）。直接全量切换可能短期内频繁触发 429。

Provider 端 SLA 不稳定。新模型刚上线时 Provider 自身可能有问题——延迟高、抖动大、偶发 5xx。这不是你的代码问题，但表现出来是你的服务质量下降。

迁移流程

我的标准流程分四步：

Step 1：离线评估（半天到 1 天）

准备一组 评估金标准 query 集——按业务场景分类、覆盖各种 query 类型的 200-500 条样本。如果生产有日志，从历史调用里抽样最有代表性的。

对这批 query 用旧模型和新模型分别跑一遍，记录：

• 输出内容（用于人工和 LLM judge 对比）
• 输入/输出 token 数（看新 tokenizer 下成本变化）
• 每次请求延迟
• 失败率（新模型可能有不同的 refusal 倾向）

然后做对比评估：

• LLM judge（用一个独立的强模型）对每对 (旧输出, 新输出) 打分，看新模型胜率
• 关键样本人工审核——业务核心场景的回答必须人工把关
• 自动化检查格式遵守度（JSON 解析成功率、字段完整率、长度合规率）

如果离线评估显示新模型质量明显下降，先别上灰度——回去调 Prompt 适配新模型，或者放弃这次升级。

Step 2：Prompt 和工具适配（1-3 天）

如果离线评估发现某些场景新模型表现差，往往不是模型问题而是 Prompt 没适配。常见调整：

• Few-shot 示例可能不再合适，新模型可能更聪明，例子里"过度展示"反而成了限制
• System Prompt 里针对旧模型的"防御性指令"（"不要乱说"、"不要超出 X 字数"）在新模型上可能不再需要，甚至适得其反
• 工具描述可能要更新——新模型对工具调用的理解可能更精准，老的过分啰嗦的描述可以简化
• Output schema 严格性的取舍——新模型 structured output / JSON mode 支持可能更好，可以从"用 prompt 约束格式 + 后处理修复"换成"用 strict JSON mode + 严格 schema"

每次调整都要回到 Step 1 重跑离线评估，确认新 Prompt 在新模型上确实更好。

Step 3：小流量灰度（3-7 天）

按本专题第 17 篇（系统设计）讲的灰度策略，从 1% → 5% → 25% 逐步放量。多轮对话场景按用户/会话粘性切，避免同一用户两次请求落到不同模型。

每个阶段并行监控：

• 技术指标：成功率、TTFT、TBT、P99 延迟、错误分类（特别注意 Provider 端的 429 和 5xx）
• 业务指标：用户主动反馈率、重新生成率、对话长度变化
• 质量指标：LLM judge 抽样打分、人工抽检
• 成本指标：实际平均 input/output token 数（tokenizer 变化和输出风格变化的综合影响）

每阶段稳定 1-2 天再放量。不稳定就停下来分析。

Step 4：全量 + 保留回滚通道（持续）

灰度通过后全量切换，但旧模型不要立刻下线。生产里至少保留一周的"双轨"能力——配置开关一键切回旧模型。线上发现新模型在某些 corner case 上的问题（这种问题往往评估集覆盖不到），能立刻回滚。

回滚要保留足够多的失败样本供后续分析。

容易踩的坑

Prompt Caching 失效带来的短期成本上涨

如果应用大量依赖 Prompt Caching，切换到新模型相当于所有缓存重新预热——一段时间内 Prompt Caching 命中率为零，input token 成本飙升到原来的 5-10 倍。这个短期成本要在迁移预算里考虑，可能要分阶段预热（不同业务线分批切，让每一批的 Prompt Cache 错峰重建）。

Tokenizer 变化导致限流配额错位

如果限流是按 TPM（Tokens Per Minute）配置的，tokenizer 一变化同样的文本对应的 token 数变了，配额相对值就错了。要重新校准每个用户/租户的配额。

输出风格变化破坏下游解析

新模型可能开始用 emoji、用 markdown、用更多换行——下游如果依赖字符串匹配或正则提取就直接出问题。强类型的 structured output / JSON mode 是更稳的依赖方式。

Streaming 协议细微差异

不同模型的 streaming chunk 边界、delta 字段、tool_call 的 streaming 表示可能略有不同。前端流式渲染的代码可能要适配。OpenAI 和 Anthropic 之间这类差异尤其多。

评估集 overfit 到旧模型

如果评估集是基于旧模型生成的回答标注的"什么是好回答"，新模型可能在客观上更好但被标低分（因为它的风格和评估时用的"好回答"不一样）。要意识到这种偏置，必要时重新标注评估集。

安全和合规的回归

新模型的 refusal 边界可能不同——某些以前能回答的问题现在拒绝（用户体验下降），或者反过来某些以前拒绝的现在能答（可能引入合规风险）。安全测试集也要在迁移流程里跑。

跨 Provider 迁移更复杂

OpenAI → Anthropic（或反向）比同 Provider 内升级复杂得多：

• API 协议不同（messages 结构、tool_call 格式、streaming chunk 格式）
• 系统消息处理方式不同（OpenAI 是 role: system，Anthropic 是顶级字段）
• Tool calling 行为差异大（Claude 倾向于先输出 thinking 再 tool_call，需要 Prompt 适配）
• Prompt Caching 的 API 调用方式完全不同
• 计费维度不同（cache_creation / cache_read 字段不一样）
• 安全策略和 refusal 边界差别大

这种跨 Provider 迁移建议先在 Gateway 层做适配（参考工程系统设计专题第 14 篇的多 Provider 接入层），让上游业务代码完全不感知 Provider 切换，然后再做迁移。

面试时怎么讲个人项目的真实经历

面试官问这个问题时，期待听到 具体的迁移故事 而不是空泛流程。可以这样组织：

我们去年从 GPT-3.5 迁到 GPT-4o-mini。一开始以为很简单，直接换 model 参数，结果上线第二天就发现 P99 延迟涨了 30%、成本反而涨了——因为 4o-mini 比 3.5 慢一点点，而且我们的 Prompt 没适配，模型在每个回答开头都加了一段冗长的"客气话"，output token 涨了 40%。

回滚后我重新做了流程：先离线评估 300 条历史 query，发现新模型在多数场景下质量持平或更好，但输出更啰嗦。改了 System Prompt 加上"直接给答案不要客套"的指令，重新评估后输出长度回到合理水平。然后小流量灰度 5% 三天，监控延迟和 token 数，确认稳定后逐步放量。这次切换花了两周，但避免了再次回滚。

最大的收获是这种迁移要把"Prompt 适配"当成必做项，不能只看模型是不是"更强"。强不等于在你的 Prompt 上更好。

面试时可以这样答

模型升级最容易翻车的不是模型本身，而是 Prompt 适配、Prompt Caching 重新预热、tokenizer 变化、Provider 端 SLA 抖动这些周边的事。新模型的输出风格、指令遵循度、tokenizer、价格、限流都会变。

我的标准流程四步。第一步离线评估——准备 200-500 条覆盖各业务场景的金标准 query，用新旧模型分别跑，用 LLM judge 和人工对比质量，同时看 token 数变化、延迟、失败率。质量明显下降就别上灰度。

第二步 Prompt 适配——如果离线发现某些场景新模型表现差，多半是 Prompt 没适配。Few-shot 例子可能要换，针对旧模型的防御性指令可能要去掉，工具描述可能要简化，输出格式约束可能要从 prompt 改成 structured output 严格模式。每次改了重新跑评估。

第三步小流量灰度——按用户粘性切流量从 1% 涨到 25%，每阶段稳定 1-2 天。监控技术指标、业务指标、质量指标、成本指标四类。

第四步全量但保留回滚通道——旧模型不立刻下线，至少保留一周一键切回的能力。

容易踩的坑包括：Prompt Caching 短期失效成本飙升、tokenizer 变化导致限流配额错位、输出风格变化破坏下游解析、新模型 refusal 边界变化引入合规风险。跨 Provider 迁移比同 Provider 升级复杂得多，建议先在 Gateway 层做适配让业务代码不感知 Provider 切换。

常见追问

1. 离线评估的金标准 query 集怎么维护？多久更新一次？
2. 灰度过程中如果新模型在 95% 的 query 上更好但 5% 上明显差，怎么决策？
3. 跨 Provider 迁移时怎么对齐 Prompt？同样的 System Prompt 在 OpenAI 和 Anthropic 上效果差异大怎么办？