人工智能模型升級的隱藏風險
你的 AI 系統在週五運作正常，在週一仍能快速準確地回覆問題，通過所有儀表板健康檢查。但答案卻出現了微妙變化—更長、更含糊、格式不符合解析器，甚至對以前正確的政策有錯誤判斷。
沒有任何故障發生。你的供應商提供了一個模型升級。
這是一種最讓領導團隊感到驚訝的失敗模式，因為它看起來完全不是故障。沒有紅燈，系統自己報告健康，但輸出質量卻在你察覺之前悄然改變。你的客戶比你的監控系統更早發現問題。
升級為何會破壞正常運作的功能
新模型平均表現更好，但在特定情況下有所不同。供應商根據整體指標進行優化；而你部署的是針對自己獨特現實的一小部分。當模型改變時，你調校的行為也會跟著改變—你提示中的語法、整合預期的 JSON 結構、合規團隊批准的拒絕邊界、用戶介面適用的長度等。
升級有三個途徑：供應商退役一個版本並進行遷移；你使用一個浮動代號默認解析到最新版本；或者你為了降低成本或縮短延遲而故意升級，並假設質量會更好。這三種方式都會導致行為改變，但沒有人測量過具體改變了什麼。
建立監控系統
唯一重要的控制手段是一組固定測試案例，具有已知正確的答案——黃金集。從你實際流量中選擇兩百個例子，涵蓋常見、邊緣和錯誤成本高的情況，每個例子都有你的業務認為正確的答案。
將這個集合運行在當前模型上並記錄結果。這就是你的基線。新模型出現時，再次運行同一集合並進行比較。比較結果就是整個產品：你現在有證據而不是印象。
建立黃金集需要幾天時間，需要運營人員而非工程師來定義「正確」的意思。大多數組織因為感覺像是啟動前的額外工作而跳過這個步驟。但這是一種最便宜的系統保險。
控制升級的進程
在每個生產配置中固定模型版本。固定版本將一場突襲變成一個你可以安排的時間決定。然後將每次升級視為一個小型項目：
- 將黃金集運行在新版本上並逐個案例與基線比較
- 讓業務所有者審查答案發生變化的每一個案例，不僅僅是變差的情況—改進也可能破壞下游系統
- 向新版本發送少量實時流量，觀察運營信號：升級率、處理時間、員工修改系統草稿的次數、重複聯繫同一問題的次數
- 在回滾窗口內保持舊版本可訪問，並知道誰有權切換
- 記錄決定、日期和證據，以便下一次升級從已知狀態開始
注意這個清單上沒有任何演示。觀看新模型回答五個問題令人印象深刻並不能告訴你流量二十百分位數的狀況，而正是這部分投訴來源。
觀察業務已產生信號
在升級之間，質量漂移會在你可能已經收集的數據中顯現出來。人類干預請求數量、平均處理時間、員工修改系統草稿的次數、同一問題在一個星期內重複聯繫的次數等。任何這些在兩週內移動三到四個點都值得檢查模型層面發生了什麼變化。
讓一名人員定期（每周）審查這些數據，與生產中使用的模型版本進行比較。不是委員會或季度審查，而是一位指定所有者花十五分鐘進行檢查。
納入合同
向供應商要求書面通知，退役版本前提供至少支持期，以及遷移期間可訪問上一個版本。一般為監管行業提供這種服務的供應商會這樣做。不提供的人將告訴你答案，在建立合作關係之前了解這些信息非常有用。
誠實的立場
你無法阻止供應商改進他們的模型，而且你也不希望這樣做。但你可以確保改進符合你的條件：量化、分階段、可逆轉和有人負責。
這是將 AI 部署在生產環境而不是試飛的無聊工作—這也是我們為客戶承擔的責任。無論如何，建立黃金集。一切其他都取決於它。