模型替換或 prompt 改寫帶來的風險，比大多數事故都更安靜：不是新版本更差，而是沒人趕在使用者之前量過它。LLM 迴歸測試和 prompt 變更驗證存在的意義，就是讓這種測量變成例行公事。工作集是三件產物加五個步驟。產物：一套帶已知正確答案的真實輸入 golden set、給新輸出打分的 grader，以及一次把變更放到線上流量旁邊先跑、再決定是否替換的 shadow run。步驟：定義成功標準、構建集合、選擇評分方法、跑 shadow，然後套用事先定好的閾值。這是本站變更驗證層的第一篇；“遷移手冊講的是你依賴的模型下線時該怎麼辦，這一篇講的是在採納變更之前先證明它。
LLM 迴歸測試：先把成功標準定下來
Claude 的官方評估指南開頭就有一句值得裱起來的話：構建一個成功的 LLM 應用，始於清楚定義你的成功標準，然後設計評估來衡量它們，而這個迴圈是 prompt engineering 的核心。同一份指南還補充說，大多數用例都需要沿多個成功標準做多維評估，而這正是團隊把“這次變更有沒有搞壞什麼”壓縮成一個數字時跳過的那部分。
有用的標準是具體的、可衡量的、可達到的、相關的。“表現良好”一條都不佔；“在我們定義的標籤上準確分類情感”則全佔。對一次 API 整合來說，四個類別足以覆蓋大多數需求：
- 任務保真度。輸出是否真的回答了使用者的請求，包括在罕見或困難的輸入上？
- 格式與結構。下游程式碼能解析它嗎？它遵守了你的系統所依賴的契約嗎？
- 安全與拒答行為。模型是否拒絕了該拒絕的，並且沒有拒絕不該拒絕的？
- 成本與穩定性。用量水平和錯誤率在這裡充當代理指標，這正是成本指南在其操作順序中賦予驗證的同一種護欄角色。
把每條標準寫成評審者能夠判斷“過或不過”的句子。如果你讀它的定義都判斷不出是否通過，那麼下游的任何分數都無法比較。
Golden set 評估：從生產取樣，按邊緣場景組織
golden set 是一組凍結的輸入與期望輸出配對，它的第一條規則是來源：從真實生產流量中取樣，不要憑空編造輸入。編出來的例子是拿模型去測你的想像，而想像恰好是問題裡已經被解決的那部分。
第二條規則是按邊緣類別組織，而不是按方便組織。官方示例評估把用例圍繞那些歷史上會搞壞系統的輸入來組織，包括諷刺、混合情感、誤導性標題、話題突變、依賴對話很早之前的上下文，以及受保護健康資訊之類的敏感資訊。把這套分類法拿過來改造：你集合裡的每個類別都應當對應你的應用曾經被搞糊塗、或者可能被搞糊塗的一種方式。
關於規模，請保持定性，同時在兩個方向上都嚴格：小到每次有意義的變更都能跑完整套（包括在 CI 裡），又寬到你識別出的每個邊緣類別都有代表。跑得太久的集合會被跳過；只覆蓋 happy path 的集合給你虛假的信心。把集合和評分邏輯一起做版本管理，並用審查程式碼的方式審查對其中任何一項的改動，因為集合現在已是你係統契約的一部分。
LLM grader、基於程式碼的檢查，以及如何選擇裁判
評分是流程變得機械化的地方，官方指南按可靠性給這些方法排序：優先基於程式碼的評分，因為它最快、最可靠、最可擴充套件；當判斷力確實必要時用人工評審，代價真實；當問題足夠微妙、規則無法表達時，用基於 LLM 的評分。實踐中，順著這個順序往下走，你會得到：
- 基於程式碼的檢查。與 golden 答案精確匹配（
output == golden_answer，通常在規範化空白和大小寫之後）以及字串匹配檢查（key_phrase in output）覆蓋了驚人比例的用例，而且執行成本為零。可機器檢查的輸出格式會擴大這一類別，這也是讓輸出在結構上可驗證這一更廣泛的教訓。 - 基於 LLM 的評分。對於語氣、連貫性或其他定性標準，由模型裁判按照評分細則給輸出打分。有兩條官方提示很重要：寫出詳細、清晰的評分細則；並且通常用與生成輸出的模型不同的模型來評估，因為自我評估帶有自己的偏差。
- 人工評審。最靈活、質量最高，但慢且貴；指南的建議是能避免就避免。把它留給校準另外兩種方法。
在 OpenAI 這邊，evals 把這一切打包成一個可描述的測試：一個 eval 配置有data_source_config（測試資料的 schema）和testing_criteria（判斷模型輸出是否正確的一批 grader）；執行會接收測試輸入併產出結果，你來分析、迭代，文件把這個迴圈比作行為驅動開發。同一頁面直接說出了本文的論點：編寫 eval 來了解應用相對預期的表現，尤其是在升級或嘗試新模型時，是構建可靠應用必不可少的組成部分。Grader 是評分那一側：它們把參考答案與模型生成的答案對比，可以給部分分而不是嚴格通過或失敗，文件列出的型別包括字串檢查、文本相似度和基於程式碼的檢查，並且可以巢狀和組合。兩個頁面都帶有關於評估工具演進的過渡說明：把機制部分當作活的文件，構建時對著官方頁面核實細節，並檢視棄用說明裡哪些適用於你當前的賬號。evals 頁面把時間線寫得很直白：OpenAI 正在棄用 Evals 平臺；現有的 evals 內容在過渡視窗內仍然可用；Evals 將於 2026 年 10 月 31 日對現有使用者變為只讀；平臺計劃於 2026 年 11 月 30 日關閉。Grader 作為其所支撐的 evals 和微調工作流的一部分，也在被棄用。當前時間線請見官方棄用頁面：https://developers.openai.com/api/docs/deprecations#2026-06-03-evals-platform。實際結論也由此而來：golden set 和評分邏輯是你自己的資產，所以要給它們做版本管理、保持可遷移，並把圍繞它們的託管功能視為可替換的。
Shadow 流量測試：把變更放在生產旁邊跑
切換前的最後一件產物是 shadow run：把真實流量切一片複製給新模型或新 prompt，記錄一切，不給使用者返回任何東西。因為 shadow 路徑從不回答使用者，所以它是在零使用者風險下看清變更是如何作用於今天真實輸入、而不是昨天 golden set 的唯一辦法。
在兩條路徑上比較你會在生產裡監控的那些表面：
- 格式合規性，以輸出能解析並通過校驗的頻率衡量；
- 拒答率，按類別拆分；
- 錯誤響應的分佈，使用標準分診中的狀態碼族；
- 真實併發下的限流與拒絕行為；
- 用量水平和快取命中行為，讓成本意外在賬單到來之前浮現；
- 機制層面的行為：tool calling 的模式，比如哪些工具被以什麼引數呼叫，以及流是否乾淨地終止；tool calling 指南講了為什麼這些表面值得有自己的迴歸檢查。
兩條紀律讓 shadow run 保持誠實。第一，shadow 路徑不能消耗生產配額，也不能給面向使用者的路徑增加延遲；如果它做到了，你造出的是一個事故，不是一次測試。第二，shadow 記錄必須打上標記，並被排除在生產指標和看板之外，因為一個靜默混合了 shadow 與真實流量的指標，會汙染你日後想要的每一次比較。以工具呼叫比較為例：它之所以存在，是因為一次變更可以通過所有文本檢查，卻仍然改變工具的呼叫方式。
閾值與回滾開關
在第一次執行之前就把切換標準書面定好，否則你最終會把標準調到剛好吻合出現的結果。閾值應當既是定性的，又是具體的：
- 關鍵用例相對 golden set 必須零迴歸；
- 邊緣用例上的每一次失敗都必須有解釋，而不是聳聳肩；
- 成本和用量指標必須留在這個變更的預算範圍內。
與之對應的要求是一個回滾開關：舊模型或舊 prompt 必須只差一次配置改動就能恢復，而且你應當真的、故意地排練一次恢復，而不是等到壓力之下才第一次用。然後把結論寫在樣本集旁邊，就像模型選擇決策在基於約束的選擇指南裡記錄理由一樣，因為下一個做變更的人會先讀你的筆記，再讀文件。
常見失敗模式
- 只覆蓋 happy path。修法：圍繞上面的邊緣類別組織 golden set，並按類別審查覆蓋情況。
- 模型給自己打分。修法：用另一個模型做評估，或者在答案可由規則判定時優先用基於程式碼的檢查。
- 平均值改善了，於是變更上線。修法：把關鍵用例放在零迴歸要求下，與聚合分數分開評估。
- 機制表面被忽略。修法：把工具呼叫行為和流終止明確寫進迴歸清單，而不只是文本質量。
- shadow 流量漏進生產指標。修法：打標籤、隔離，保持看板乾淨。
- 結果出來之後才定閾值。修法：先寫切換標準；它是實驗設計的一部分，不是實驗的結論。
- 什麼都沒記錄。修法：樣本集、評分邏輯、執行結果和決策一起進版本控制。
驗證清單
- 先寫成功標準，多維且可判定，然後再設計任何測試。
- golden set 從真實輸入中取樣；按邊緣類別組織；保證它在每次變更時都能跑。
- 按可靠性給評分方法排序：先基於程式碼的檢查，微妙之處用帶清晰細則的 LLM 裁判並配獨立的評估模型，人工用於校準。
- 用真實流量對變更做 shadow run；比較格式、拒答、錯誤、限流、用量與快取行為，以及工具呼叫和流結束這類機制層面的行為。
- shadow 資料單獨打標，排除在生產指標和配額之外。
- 在執行前設定閾值，並保留一個排練過的一步回滾。
- 把集合、評分邏輯、結果和決策一起記錄下來，這樣下一次變更能從證據出發。
這些都不是什麼奇巧機械，而這正是重點：你所選擇的變更與你所造成的事故之間的差別，通常就是一組成套的用例、一種評分方法，和一次在生產旁邊跑的 shadow。當你的呼叫走的是相容端點時，端點層面的細節在平臺自己的文件裡。