模型版本控制、回滾和漂移：供應商不給您的生產控制

每個工程團隊都知道如何管理生產軟體。您固定依賴版本。您使用語義版本控制。您為每次部署制定回滾計劃。您對風險性更改運行金絲雀部署。您監控生產系統，並且為失敗模式制定了操作手冊。

然後您整合了一個雲端 AI API，並放棄了所有這些。

AI 模型成為您建立的每個軟體生產規範的例外。模型版本在任何有意義的意義上都沒有被固定。回滾是不可能的。行為變更監控需要您可能從未構建的自定義工具。當出現問題時——靜默的模型更新以破壞下游邏輯的方式改變了行為——您從用戶投訴中發現這一點。

這是一個普遍問題，它被低估是因為 AI 失敗通常看起來像品質下降，而不是系統故障。API 仍然返回 200 狀態碼。延遲沒問題。但輸出在重要方面有所不同。

當模型行為改變時會發生什麼

讓我們具體說明生產中的行為漂移是什麼樣子的。

法律 AI 文件摘要器生成平均 340 字的摘要。在靜默的模型更新後，摘要平均 210 字。您的審查介面是為較長格式設計的。律師因為較短的摘要省略了關鍵條款而錯過了它們。這不是一個錯誤——API 正在工作。但變更是有後果的。

醫療編碼助理對基準測試集上的一類診斷代碼進行分類，準確率為 94%。更新後，該類別的準確率下降到 87%。下降超出了您設置的任何明確閾值——因為您從未設置閾值，因為您沒有監控框架。索賠被錯誤編碼。您在一個月後出現計費差異時發現這一點。

欺詐偵測模型有一個決策邊界，對合法交易產生 1.2% 的誤報率。更新後，該率轉移到 1.8%。在每天 200 萬筆交易中，每天有 12,000 筆額外的錯誤拒絕。客戶投訴增加。收入受到影響。原因是三週前發生的模型更新。

這些不是災難性的失敗。它們是悄悄發生並造成真實業務影響的那種降級。它們都不會觸發系統警報。所有這些都可以通過適當的模型版本控制和效能監控來捕獲。

API 版本固定的幻覺

雲端 AI 提供商提供版本固定的端點。您可以調用 gpt-4-1106-preview 而不是 gpt-4。這感覺像是版本固定。但它不是。

版本固定的端點在滾動的基礎上被棄用。當固定版本被棄用時，您被移動到後繼版本，或者端點完全停止工作。棄用通知通常是 6-12 個月。這聽起來有足夠的時間。在實踐中，對於受監管行業的生產系統，6-12 個月幾乎不足以完成模型更新的安全審查，更不用說針對合規要求驗證行為了。

更根本的是：即使固定版本可用，您也無法稽核該版本的功能。您沒有權重。您無法在隔離中對模型運行行為測試。您可以通過 API 調用觀察模型的行為，但您無法驗證行為是否穩定，也無法理解當它確實改變時為什麼改變。

真正的版本固定意味著您擁有檢查點。模型狀態是您控制下的文件。它不會改變，直到您改變它。沒有棄用通知。沒有您沒有選擇的遷移路徑。

AI 模型的真正版本控制

當您擁有模型權重——通過微調開源基礎模型或從頭開始訓練——您有一個版本化工件的模型檢查點。它的行為就像一個文件，因為它就是一個文件。

這給您帶來的：

精確的可重現性：給定相同的輸入和相同的模型權重（以及設置為 0 以確定性的相同推理溫度），您得到相同的輸出。這對於基於 API 的 AI 不成立，在那裡模型可以被更新，推理基礎設施也可以變化。

明確的更新：當您決定重新訓練並部署新檢查點時，模型才改變。不是之前。更新是故意的、經過測試的和批准的——不是從供應商靜默吸收的。

行為差異：您可以在同一評估集上直接比較兩個模型檢查點。前後比較不是通過 API 的觀察——它們是兩個模型都可用的受控實驗。

回滾：如果新部署的模型在您的生產評估指標上表現比其前身更差，您就恢復前一個檢查點。回滾是一個文件操作。

漂移偵測：測量什麼

模型漂移是輸入和輸出之間關係隨時間的變化。它發生有兩個原因：模型改變（明確的更新或靜默的供應商更新），或輸入分佈改變（用戶行為不同、資料品質改變、出現新的使用案例）。

測量它的工具：

群體穩定性指數（PSI）：測量基準期和當前期之間模型輸出（或輸入）分佈的偏移。PSI 低於 0.1 表示沒有顯著偏移；PSI 在 0.1-0.2 之間需要監控；PSI 超過 0.2 表示需要調查的顯著漂移。PSI 計算速度快，不需要真實標籤。

輸出分佈監控：追蹤關鍵輸出特徵的分佈——分類置信度分數、輸出長度分佈、拒絕率、分類任務的類別分佈。這些分佈中的顯著偏移通常先於準確率下降。

保留評估集上的準確率：定期對您知道正確答案的保留評估集運行您的模型。這是模型效能的真實測量。它需要前期的標記工作，但它是直接追蹤準確率的唯一測量。高風險模型每週運行，低風險模型每月運行。

人工抽樣：讓領域專家定期審查隨機樣本的模型輸出，並根據評分標準評估品質。這捕捉了定量指標錯過的定性降級——語調偏移、推理失敗、邊緣案例處理。

在 PSI 和輸出分佈指標上自動化警報。將評估集運行的準確率下降展示給模型負責人。在部署之前建立明確的閾值——而不是在回應生產事件之後。

回滾策略：AI 模型的藍/綠部署

藍/綠部署是一種標準軟體生產模式：維護兩個生產就緒的部署，將流量路由到一個（綠色），將更改部署到另一個（藍色），驗證，然後切換。如果切換發現問題，路由回綠色。

這也適用於 AI 模型，有一個重要的補充：評估門控。

在將新模型提升到生產環境之前：

1. 對照相同的評估集運行新模型和當前生產模型
2. 比較準確率、偏差指標、輸出分佈和延遲
3. 要求新模型在所有指標上達到或超過生產模型性能（或以記錄的理由明確接受權衡）
4. 如果新模型通過：金絲雀部署到 5-10% 的流量，監控生產指標 24-72 小時，然後完整提升
5. 如果新模型未能通過評估門控：回到訓練，沒有生產流量

這是評估門控原則。它防止回歸在未被偵測的情況下到達生產環境。它需要一個保留的評估集和並排比較基礎設施——這兩者都是任何運行自有模型的團隊的標準要求。

重新訓練決策

漂移偵測告訴您何時調查。它不會自動告訴您何時重新訓練。

在以下情況下重新訓練：

• 輸入分佈上的 PSI 超過 0.2（資料漂移顯著到足以使訓練分佈無效）
• 評估集上的準確率比啟動基線下降超過 3-5%（閾值取決於風險等級）
• 人工抽樣在特定類別中發現系統性定性失敗
• 已積累的新訓練資料將有意義地改善覆蓋範圍（通常是當您比上次訓練時有多出 20-30% 的標記資料時）
• 發生了領域偏移（產品發布、監管變更、用戶群體變更），當前模型未被訓練適應

不要在每次投訴後反應性地重新訓練。不要按固定時間表重新訓練，無論是否發生漂移。這兩種方法都會浪費資源並引入不必要的變更。當資料告訴您時重新訓練。

Ertas 微調：您的模型的版本控制

Ertas Fine-Tuning SaaS 將每次訓練運行保存為明確的檢查點。您可以在決定部署之前在評估集上並排比較模型。訓練血緣——數據集版本、超參數、訓練持續時間——與每個檢查點一起記錄。

所得的 GGUF 是您在自己基礎設施上部署的可攜帶工件。在對象存儲或模型登記冊中對其進行版本化，就像您對軟體發布進行版本化一樣。用訓練日期、數據集版本和評估指標標記檢查點。維護前一個檢查點，直到新的在生產中被證明。

這是真正有效的模型版本控制——而不是會過期的端點固定。

查看早鳥定價 →

相關：生產 AI 模型治理涵蓋了模型版本控制支援的更廣泛治理框架。有關供應商依賴框架，請參閱為什麼「我們使用 API」意味著您沒有控制。

將 AI 模型作為一流生產工件對待的工程紀律——版本化、監控、提升前門控、可回滾——對於在重要場景中運行 AI 的團隊來說不是可選的。這就是您的軟體工程實踐對其他一切看起來的樣子。在這裡也適用它。