私人 AI 升級需要接受記錄

升級審查中應包含兩個配置：已被接受用於任務的配置與擬議替代配置。若缺乏雙方證據，團隊只能描述新軟件，卻無法解釋其對自身工作流程的變更。我們建議在舊配置消失前，將接受記錄納入升級流程。

本篇八月補充文章於九月研究並發佈，提出實用的審查方法；並非報告實際客戶部署數據或承諾特定改進。

保留舊決策

從現有配置被接受的原因開始。定位模型身份、運行時版本、測試輸入及審查標準。若該記錄不存在，記錄仍可驗證的部分並標明缺失項目。切勿憑記憶重建成功測試並當作觀察結果呈現。

在評估候選版本期間，透過組織的正常變更流程保持舊配置可用。這可能需要記錄不僅是模型檔案：文件集合、提示模板及應用設定亦可能影響任務。記錄與擬議變更相關的部分。

對於共享 AI Server 部署，請列明依賴該服務的應用工作流程。對一個工作流程有利的變更，可能對另一個工作流程需不同的接受決策。將服務使用者視為審查範圍的一部分，而非假設一次示範代表全部。

升級應有具體理由。團隊可能尋求受支持的運行時、修正已知錯誤，或在特定任務上取得更佳結果。以可檢核形式書寫該理由。“使用較新模型”是行動指示，並未定義預期效益。

NIST 的 AI RMF 概述描述了在 AI 系統設計、使用及評估中對可信度的考量。[1] 我們應用此原則，將評估與變更緊密連結。先前的接受決策不應默默成為未曾測試配置的證據。

同時說明必須保持可接受的條件。若工作流程匯出結構化數據，匯出仍須符合接收合約。若審查者依賴來源參考，參考仍須支持答案。這些條件應與期望改進並列，而非置於遺忘的獨立清單。

對舊配置與候選配置使用保留的輸入集。套用相同審查標準。記錄對任務重要的輸出變化，包括新失敗。評估者不應猜測有利結果是來自升級還是替換了困難的測試輸入。

MLCommons 定義了具體工作負載和質量條件的推理基準。[2] 對內部審查而言，可借鑑的經驗是重視條件，而非有權直接引用外部的性能結果。請測量實際工作流程並記錄其運行情況。

將正確性審核與時間分開處理。較早收到的回應若遺漏了必需項目，則不符合接受規則。較長的回應若未提供額外有用證據，不應僅因文字較多而被視為改進。

使用包含異議欄位的記錄。如果兩位審核者對輸出有不同解讀，請保留有爭議的範例並釐清接受標準。將分歧平均化可能會掩蓋任務本身的模糊性。

審核可作出有限決定：接受該候選人用於測試的工作流程、重複指定測試，或保留現有配置。請描述該決定背後的證據及仍存的限制。一次文件集的成功試驗不應被視為對伺服器上所有應用的批准。

在推出前訂明回退路徑。指明誰有權作出決定及觸發該決定的證據。保持程序具體明確，以便在壓力下執行。我們的配套文章關於模型選擇記錄解釋了為何在此處準確的候選人身份至關重要。

該企業平台概覽可以協助構建部署討論。升級決定仍應與一項已觀察的任務、其驗收規則及另一人可檢查的記錄相關聯。