AI 模型更新後怎麼驗？用固定任務集檢查輸出差異

用固定任務、前後輸出與事先訂好的門檻，檢查模型或服務版本更新是否改變工作結果，並決定採用、暫停或回復。

模型或服務版本更新後，回答出現差異不一定代表品質變差；反過來說，幾個示例看似正常，也不足以證明可以直接切換。以下用固定任務、更新前後輸出與事先訂好的門檻，建立可重複的驗收流程，幫助團隊決定採用、暫停或回復。先固定測試範圍、輸入、評分方式與核准責任，讓每次比較都在相同條件下進行。重點不是追求完全相同的措辭，而是確認差異會否改變任務結果、風險或人工處理量。

記下更新前版本

先把「更新前」定義成可重現的版本組合，記錄供應商或服務名稱、模型名稱、版本或快照識別（若有提供）、API 版本、端點區域、帳戶或專案、SDK 版本與呼叫日期。若服務只顯示別名或自動更新，照實註記「未提供固定快照」，不要猜底層版本。另保存呼叫參數，例如 temperature、top_p、max_tokens、system 指令版本、提示模板、工具定義、輸出格式限制，以及可設定時的取樣 seed。不要把密碼、金鑰或個資複製進驗收文件；用內部代號指向受控的憑證管理位置即可。

把更新通知、變更紀錄連結與內部變更單編號放在同一筆紀錄，說明這次是供應商更新、團隊改設定，還是兩者同時發生。若來源尚未確認，就標成未知，先不要把結果歸因於模型。比如服務名稱沒變，但 SDK 升版且 system prompt 也修改，這就不是單一變因；應先固定其中一項，或拆成兩次比較。基線要讓同事在另一個工作階段依相同設定重跑，才能作為更新前參照。欄位缺漏時，留下目前可取得的識別資訊並寫明限制，不要用日期冒充版本。最後記下紀錄人、資料集代號與基線保存位置，讓後續核准者知道這份參照來自哪一次執行。

若供應商同時提供模型 ID 和顯示名稱，兩者都記下，並保留原始回應中的 request ID 或版本欄位；這些識別未必能單獨還原模型，但可協助查詢同一次請求。將一筆基線視為設定快照：提示、參數、工具規格或資料前處理任一項改動，就建立新版本，不覆寫舊紀錄。若呼叫之間有自動路由，標記每筆回應對應的可見版本；無法取得時註記未知，避免把不同模型的輸出混在一起。也可用表單固定欄位名稱，避免漏記。

挑選代表任務樣本

不要只挑最容易得到漂亮答案的題目。先按用途分層，例如摘要、分類、資料抽取、客服草稿或程式輔助，再從每類挑出常見流程、邊界情況與曾出錯的任務。樣本應來自可合法使用且已去識別的工作資料，保留完成任務所需的上下文，移除姓名、帳號、訂單號等不必要資訊。若任務含有高風險步驟，另放入會觸發拒答、要求人工確認或資料不足的案例，檢查更新後是否仍守住流程界線。

把每筆樣本寫成固定輸入、必要背景、預期輸出特徵與不可接受結果；不要只寫「回答要好」。例如客服分類樣本可要求輸出一個類別和一行理由，並明定缺少訂單資訊時須標示待確認，不能自行補值。任務集規模依風險與可用評審時間決定，不要把小樣本說成能代表所有使用情境。可先用十筆是假設性的起步清單：六筆常見、兩筆邊界、兩筆失敗或例外，再依實際錯誤補樣本；這只是配比示例，不是通用標準。每次更新都沿用同一版任務集，新增題目則另開版本並說明原因。更新前若發現題目含糊，先修正並重跑基線，避免把題目歧義誤判成模型退步。

挑選時先列出工作流程的入口與預期去向，再從每個去向反推樣本；若某類錯誤會造成較大返工，可增加例子，不必讓各類題數相同。也可分成固定核心集與補充集：核心集每次必跑，補充集檢查近期新增情境。題目入選原因和未涵蓋的情境都留簡短註記。若任務涉及跨語言或多輪對話，保留完整對話歷程在同一筆樣本，不要只測首輪或把追問拆開。

保存更新前輸出

在切換版本前，使用同一任務集與設定完整執行一次，保存每題的輸入、原始回應、必要的工具呼叫結果、錯誤訊息與執行時間。保留原始格式，不要只存整理過的答案，因為格式差異、空值、截斷或額外欄位也可能影響下游流程。另存可供評分的副本，把模型名稱等線索遮蔽，降低評審先入為主；原始資料仍需保留可追溯的題目代號與執行識別。

保存前先確認樣本可用範圍與存取權限；輸出可能帶有個資或商業機密時，應先遮蔽或改用合成資料，並限制讀取對象。記錄資料集版本、參數、執行時間、輸出檔案位置和雜湊值（若現有工具可產生），讓之後能確認比較的是同一份基線，而不是被覆寫的檔案。若回應受隨機性影響，先固定可控參數；不能固定時，對少數關鍵題目重跑並記下次數與差異，不要挑其中最好的一次當基準。更新後以相同方式保存新輸出，並將新舊結果以題目代號配對。若基線已遺失、設定無法還原或樣本內容已變更，先標示比較限制；必要時重新建立基線，不要把不對稱的兩次執行包裝成公平測試。

若模型會呼叫搜尋、資料庫或其他工具，測試時應改用安全模擬、唯讀權限或隔離環境，並保存工具回傳內容；不要讓驗收樣本真的寄信、修改紀錄或提交交易。基線和新版輸出分開保存並限制寫入，只有指定維護者可更新，評分結果則用題目代號連回原始請求。任務若可能重試多次，記錄重試次數、停止原因及最後採用哪次輸出，不能只挑成功結果。

比較品質與例外

評分前先寫好規準，再逐題看新舊輸出。可分成正確性、完整性、格式遵循與風險處理四項；每項用一致的級距描述可接受、需人工修正及不可接受的差異。涉及金額、權限、個資或對外承諾的任務，錯誤後果比文句流暢更重要，應設為獨立檢查項。若能安排未參與更新的人員遮蔽版本名稱評分，就先盲評，再查看原始差異；有分歧時記錄原因，不以平均分掩蓋單題重大失誤。

以下為假設示例，權重與分數只示範算法，不是通用門檻：

依表中假設數字，新版為 32+24+17+8=81 分，較舊版 88 分少 7 分；這個總分仍須與逐題例外一起判讀。差異記錄應指出哪個輸入導致何種變化、是否影響後續人工或系統處理，以及能否透過提示或流程修正。若輸出變短但資訊仍完整，未必是退步；若分類標籤改變並觸發錯誤路由，就算總分接近也不能忽略。把重大錯誤、一般退化、改善與無實質差異分開，並保留可重現的例子，讓決策依據可被核對。

對結構化答案，逐欄核對必要欄位、資料型別、空值與多出的鍵；對自然語言，分別標記事實錯誤、遺漏條件和措辭改變，不要把字句不同一律判成退步。若輸出會交給程式或同事接手，可再檢查下游是否能讀取、是否新增補救步驟。每項評分附上具體證據，例如「漏掉輸入中明列的日期」，比只寫低分更可行動。當新版改善一項卻退化另一項，依任務原先設定的優先級判斷，不要事後調權重。比較應同時看答案差異與工作結果：無關緊要的改寫可能可接受，格式錯誤卻可能讓後續流程無法執行。

決定接受或暫停

在執行前先訂採用條件，避免看完結果才移動門檻。條件可包含整體分數變化、關鍵任務最低要求、重大錯誤數量、格式通過情況與人工修正成本；門檻由任務風險、錯誤後果和現行流程決定，不要借用未經驗證的外部數字。任何涉及越權操作、錯誤對外承諾、敏感資料暴露或必須人工確認卻未提醒的失誤，都可以預先列為暫停條件，即使其他題目表現良好也要先處理。

若每個條件都達標，可先在有限、可觀察的流程中採用，保留一段回看期並監測同一類任務；確認沒有新例外後，再擴大範圍。若只有部分項目退化，先定位原因是模型版本、提示、工具或資料變更，再用原任務集重驗修正，不能只挑失敗題目以外的結果宣告通過。證據不足、版本資訊不明、樣本未覆蓋高風險用途或輸出差異尚無法解釋時，選擇暫停或小範圍試行，並列出還缺什麼證據與負責人。決策紀錄要寫明接受、暫停或拒絕的理由、適用任務及限制；「整體分數提升」不能代替逐題風險判斷。若更新只改善文句卻增加人工核對步驟，也要把維護成本納入判斷。

可將結果設成三種明確動作：接受並按範圍逐步啟用；暫停並安排補測或修正；拒絕此次變更並維持舊流程。每種動作都要對應負責人、完成條件和下一次檢視時間，讓「先觀察」不會變成無期限等待。若結果接近門檻或評分者有分歧，可追加樣本或重跑關鍵案例，分開呈現原始和追加結果；若新增資料改變結論，記錄哪些證據讓判斷轉向。這樣團隊能知道暫停是等待更多證據，還是已確認無法接受。

標明核准與回復方式

把驗收結果整理成一頁可追溯紀錄：變更來源、前後版本識別、任務集版本、執行設定、輸出位置、評分規準、重大例外、決策、核准人與日期。核准人應知道哪些任務被測、哪些沒有測，以及結論適用範圍；不要把一次驗收寫成對所有模型用途的保證。若樣本含敏感資料，紀錄只放受控位置或引用代號，不在一般變更單附上完整內容。任務集、提示模板或門檻日後若有修改，也要增加版本並留下變更理由，否則下次比較會失去可比性。

回復計畫要在採用前確認可行：舊版本是否仍可呼叫、設定如何切回、誰有權操作、需要人工接手哪些任務，以及回復後如何確認路由已生效。供應商未提供舊版本、版本切換會改動資料或回復需額外部署時，不要假設能一鍵還原；先準備替代流程，例如暫停自動處理、轉人工覆核或縮小使用範圍。可將回復觸發條件寫成可觀察事件，例如任一高風險樣本出現未授權行為，或連續執行未符合事先門檻，並指定決策人與通知對象。最後做一次不影響正式工作的桌上演練，確認每個人找得到基線、知道誰能切回，也知道何時改走人工流程。

若回復依賴供應商支援或需重新部署，先確認所需時間與權限是否有人負責；沒有把握時，將暫停自動化和人工接手列為可立即執行的替代方案。下一步可先挑三個高頻任務，保存本次版本與原始輸出，請未參與更新的人依規準評分，再決定是否擴大採用。若要把這套驗收方式放進既有工作流程，可從 ZhenheAI 首頁 了解相關方向。