當 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 的模型生命週期遵循一個模式：

新模型發布帶有日期版本（例如 gpt-4o-2024-08-06）
別名指向最新版本（例如 gpt-4o 指向最新的日期版本）
較舊的日期版本被淘汰，提前 3-6 個月通知
淘汰日期之後，對舊模型的呼叫返回錯誤或被自動重新導向到替代版本

通知期聽起來很寬裕。實際上並非如此。

為什麼 3-6 個月不夠

淘汰不僅僅意味著在你的程式碼中更改一個模型字串。當你切換模型時，行為會改變：

輸出格式改變： 你的提示詞是針對特定模型的傾向而調校的。新模型可能以不同方式格式化 JSON、使用不同的措辭，或以不同方式處理邊界情況。

準確度變化： 在 gpt-4-0613 上達到 90% 準確率的提示詞，在 gpt-4o 上可能達到 85% 或 95%。在測試之前你無從得知。

Token 使用量變化： 不同模型的 token 化方式不同，生成的回應長度也不同。你的成本模型會改變。

延遲變化： 較新的模型可能更快或更慢。你的 UX 時間假設可能會失效。

每一項都需要測試、提示詞重新調校，以及可能的程式碼修改。對行動應用程式來說，這還意味著通過 App Store 審核流程的新版本發布。

行動應用程式的問題

網頁應用程式可以在幾分鐘內部署修復。行動應用程式不行。

App Store 審核： iOS App Store 審核平均需要 24-48 小時。如果你需要更改模型字串，你需要推送新版本、等待審核，然後等待使用者更新。

使用者更新延遲： 即使你推送了更新，使用者也不會立即更新。80% 的使用者更新 iOS 應用程式的中位時間是 1-2 週。Android 更糟。你可能有使用者在修復版發布後數週仍在舊版本上呼叫已淘汰的模型。

測試需求： 每個新模型版本都需要在你整個 AI 功能集上進行迴歸測試。自動化測試有幫助，但基於提示詞的 AI 本質上是不確定性的。通常需要人工 QA。

連鎖風險

如果你的應用程式直接呼叫已淘汰的模型（寫死的模型字串），時程看起來如下：

OpenAI 宣布淘汰（第 0 天）
你注意到公告（第 1-14 天，取決於監控）
你測試替代模型對你提示詞的表現（第 14-30 天）
你重新調校在新模型上不起作用的提示詞（第 30-60 天）
你推送新的應用程式版本（第 60-65 天）
Apple 審核該版本（第 65-67 天）
使用者更新（第 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 檔案不會過期
沒有第三方可以淘汰你的模型
你控制何時以及是否更新
模型更新按照你的時程進行，而非供應商的

模型升級路徑變成：

你決定更新（根據你自己的測試，而非截止日期）
微調新版本
針對你的品質基準進行測試
透過你的正常模型分發流程將更新推送給使用者
尚未更新的使用者仍可繼續使用舊模型

沒有強制時程。沒有緊急遷移。沒有 App Store 審核壓力。

穩定性的成本

在像 Ertas 這樣的平台上微調模型，每次運行成本 $5-50。這就是完全獨立於淘汰時程、行為變更和供應商時程的成本。

相比之下，一次被迫遷移的工程成本：2-4 週的開發者時間用於測試、提示詞重新調校和部署。以典型的開發者成本計算，一次淘汰回應的成本為 $5,000-$20,000 的工程時間。

微調路線不僅更穩定。每次遷移事件的成本也更低。

現在該做什麼

盤點你的模型依賴。 你的應用程式呼叫了哪些模型？它們是日期版本還是別名？
設置淘汰監控。 訂閱 OpenAI 的更新日誌、Anthropic 的公告和 Google 的 API 更新。
建立遷移計劃。 如果你的主要模型明天被淘汰，發布修復需要多長時間？
開始收集訓練資料。 你今天進行的每次 API 呼叫都是明天你將擁有的模型的潛在微調範例。
評估裝置端路徑。 在你的領域資料上微調一個小型模型，匯出 GGUF，在裝置端測試。當它達到你的品質標準時，就部署它。

目標不是完全避免雲端 API。目標是停止為使用者依賴的功能依賴你無法控制的基礎設施。