当 OpenAI 弃用你的应用依赖的模型时会发生什么

2024 年 6 月 6 日, OpenAI 弃用了 gpt-4-32k、gpt-4-vision-preview 和其他几个模型。使用这些模型的应用必须在特定日期前迁移。过了该日期, API 调用会返回错误。

这不是第一次弃用。自 2023 年以来, OpenAI 已退役超过 15 个模型版本。GPT-3.5-turbo-0301、GPT-4-0314、text-davinci-003、code-davinci-002。每次弃用都迫使所有依赖的应用进行迁移。

如果你的移动应用依赖特定的 OpenAI 模型,这将发生在你身上。问题不是"是否"而是"何时"以及"破坏性有多大"。

弃用模式

OpenAI 的模型生命周期遵循一个模式:

1. 新模型发布,带有日期版本(例如 gpt-4o-2024-08-06)
2. 别名指向最新版本(例如 gpt-4o 指向最新的日期版本)
3. 旧的日期版本被弃用,提前 3-6 个月通知
4. 弃用日期之后,调用旧模型会返回错误或被自动重定向到替代模型

通知期听起来很充裕。实际上并非如此。

为什么 3-6 个月不够

弃用不仅仅意味着在代码中更改模型字符串。当你切换模型时,行为会改变:

输出格式变化: 你的提示词是针对特定模型的倾向调优的。新模型可能以不同方式格式化 JSON、使用不同措辞或以不同方式处理边缘情况。

准确率变化: 在 gpt-4-0613 上达到 90% 准确率的提示词在 gpt-4o 上可能达到 85% 或 95%。在你测试之前无法知道。

Token 使用量变化: 不同模型的 token 化方式不同,生成的响应长度也不同。你的成本模型会改变。

延迟变化: 新模型可能更快或更慢。你的 UX 时间假设可能会被打破。

以上每一项都需要测试、提示词重新调优和可能的代码更改。对于移动应用,这还意味着通过 App Store 审核流程发布新版本。

移动应用的问题

Web 应用可以在几分钟内部署修复。移动应用不行。

App Store 审核: iOS App Store 审核平均需要 24-48 小时。如果你需要更改模型字符串,你需要推送新构建、等待审核并等待用户更新。

用户更新滞后: 即使你推送了更新,用户也不会立即更新。80% 的用户更新 iOS 应用的中位时间是 1-2 周。Android 更慢。在你的修复上线数周后,可能仍有用户在旧版本上调用已弃用的模型。

测试需求: 每个新模型版本都需要在你的整个 AI 功能集上进行回归测试。自动化测试有帮助,但基于提示词的 AI 本质上是非确定性的。通常需要手动 QA。

级联风险

如果你的应用直接调用已弃用的模型(硬编码模型字符串),时间线看起来是这样的:

1. OpenAI 宣布弃用(第 0 天)
2. 你注意到公告(第 1-14 天,取决于监控)
3. 你用新模型测试你的提示词(第 14-30 天)
4. 你重新调优不适配新模型的提示词(第 30-60 天)
5. 你推送新的应用构建(第 60-65 天)
6. Apple 审核构建(第 65-67 天)
7. 用户更新(第 67-80+ 天)

在 90 天的弃用窗口内,时间很紧。在 60 天窗口内,你可能来不及。

不只是 OpenAI 的问题

每个云 AI 供应商都会弃用模型:

Anthropic 已弃用 Claude 2、Claude 2.1 和 Claude Instant。Claude 3 系列模型也会跟随。

Google 已弃用 PaLM、Bard 和旧版 Gemini。Gemini 模型阵容定期变化。

这是全行业的模式: AI 模型开发速度很快。供应商没有动力无限期维护旧模型。提供过时模型的计算成本是真实的,而替代品从供应商角度看总是"更好的"。

缓解策略(在云模型范围内)

使用别名,不用日期版本

调用 gpt-4o 而不是 gpt-4o-2024-08-06。别名自动指向最新版本。你无需更改代码就能获得新模型。

缺点: 你失去了对行为变化时间的控制。模型可能在你不知情的情况下改变。昨天有效的提示词今天可能表现不同。

服务端模型配置

不要在移动应用中硬编码模型名称。将其存储在服务端配置中,应用启动时获取:

{
  "ai_model": "gpt-4o-mini",
  "ai_provider": "openai"
}

这让你无需推送应用更新即可更换模型。但它不解决行为测试问题。你仍然是在将未经测试的模型推送到生产环境。

提示词版本固定

维护一个提示词注册表,将每个提示词与其测试过的模型配对。当你更换模型时,注册表会标记哪些提示词需要重新测试。

这是好的工程实践,但增加了运维复杂性。

结构性解决方案

弃用问题存在是因为你依赖别人的基础设施和别人的时间表。当你拥有自己的模型时,就没有弃用。

你微调和部署的端侧模型属于你:

• 用户设备上的 GGUF 文件不会过期
• 没有第三方可以弃用你的模型
• 你控制是否以及何时更新
• 模型更新按你的时间表进行,而非供应商的

模型升级路径变为:

1. 你决定更新(基于你自己的测试,而非截止日期)
2. 微调新版本
3. 对照你的质量基准进行测试
4. 通过你常规的模型交付管道推送更新给用户
5. 旧模型继续为未更新的用户工作

没有强制时间线。没有紧急迁移。没有 App Store 审核压力。

稳定性的成本

在 Ertas 等平台上微调一个模型每次运行花费 $5-50。这就是完全独立于弃用时间表、行为变化和供应商时间线的成本。

对比之下,被迫迁移的工程成本: 2-4 周的开发者时间用于测试、提示词重新调优和部署。按典型的开发者成本计算,单次弃用响应花费 $5,000-$20,000 的工程时间。

微调路线不仅更稳定,而且每次迁移事件的成本更低。

现在该做什么

1. 盘点你的模型依赖。 你的应用调用了哪些模型?是日期版本还是别名?
2. 建立弃用监控。 订阅 OpenAI 的变更日志、Anthropic 的公告和 Google 的 API 更新。
3. 制定迁移计划。 如果你的主要模型明天被弃用,修复上线需要多久?
4. 开始收集训练数据。 你今天的每一次 API 调用都是明天你将拥有的模型的潜在微调样本。
5. 评估端侧路径。 在你的领域数据上微调一个小模型,导出 GGUF,在设备上测试。当它达到你的质量标准时,部署它。

目标不是完全避免云 API。目标是停止将用户依赖的功能建立在你无法控制的基础设施上。

Ship AI that runs on your users' devices.

Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

View early bird pricingor join the waitlist →