有效的 AI 評估不是縮小版排行榜，而是對系統必須完成的工作、使用者會注意到的錯誤，以及團隊願意接受的取捨所做的精簡建模。
先明確決策，再選擇指標
寫清楚誰在使用系統、他們要完成什麼，以及回答出錯會帶來什麼後果。起草回覆的客服助手需要測試是否遵守政策、是否遺漏步驟、是否表現出不恰當的自信；文件提取器則需要測試欄位準確率、結構描述有效性，以及是否明確處理缺失值。一個籠統的「品質」分數無法同時診斷這兩類問題。
OpenAI 的評估指南建議針對具體任務設計測試，儘早並反覆評估，儘可能採用自動評分，同時利用人工反饋校準評分工具。這些原則指向一種類似產品測試套件的評估集：範圍清晰、具有版本管理，並能對應團隊可以實施的改動。
從三個不同來源收集案例
先收集代表日常流量主體的普通案例。再加入邊界案例：長輸入、含糊的請求、缺少脈絡、相互矛盾的文件和不受支援的語言。最後加入紀錄和使用者報告中觀察到的真實失敗。第三類往往能產生價值最高的迴歸測試，因為它紀錄了看似合理的設計已經犯過的錯誤。
移除敏感資訊，只保留復現行為所需的脈絡。給每個案例標註待測能力和預期證據，而不只是附上一段理想答案。有些案例需要精確答案；另一些則適合採用評分準則，例如「行動前先請求澄清」或「只引用提供的文件」。
區分元件測試與端到端測試
代理可能因檢索漏掉資料、提示詞隱藏了某條指令、工具回傳格式錯誤的資料，或模型做出不當選擇而失敗。如果所有測試只檢查最終回答，團隊就可能最佳化錯誤的元件。除了端到端任務完成情況，還要分別測試檢索、工具引數、策略路由和輸出格式。
端到端案例仍然重要，因為各個元件單獨執行正常，也可能在協作時出問題。透過執行軌跡保留檢索片段、工具呼叫和診斷所需的中間狀態；不要把不可見的推論過程當作必要條件或可靠的稽核紀錄。
結合多種評分方法
對於結構描述有效性、必需欄位、禁止操作、引用和精確計算，優先使用確定性檢查。任務有穩定目標時，使用參考答案。相關性、完整性和語氣等維度可以使用基於評分準則的人員或模型評審，但要用人員評分結果校準自動評分工具，並檢查兩者的分歧。
呈現多維評分表，而不是把所有結果壓成一個數字。如果某次釋出改善了文風，卻降低了事實依據充分性，就不能簡單視為進步。為關鍵維度設定明確閾值，並按語言、工作流程和風險級別審查表現。
讓評估持續執行
在修改提示詞、模型、工具或檢索設定之前固定基線。針對候選方案執行同一套測試，紀錄設定和成本，調查每一項關鍵迴歸。加入新發現的失敗案例，不要悄悄刪掉難題。以後確需停用某項測試時，也應紀錄理由。
評估集是需要長期維護的產品資產。為它指定負責人、維護變更紀錄並設定訪問控制。每次重要變更都會執行的小型測試套件，比一年只執行兩次的大型基準測試更有用。
如何付諸實踐
先選取一個與「如何構建能發現真實故障的 AI 評估集」相關、邊界清晰的工作流程。改動系統之前，用一頁文件紀錄基線：目前的完成時間、品質檢查項、常見失敗類別、升級處理路徑和結果負責人。選取有代表性的樣本，而不是隻挑最乾淨的案例。納入普通案例、困難的邊緣案例，以及至少一個正確做法是停止或請求更多資訊的案例。
在允許候選方案取代現有流程前，先讓兩者並行執行。成功和失敗的輸出都要檢查，因為錯誤率下降仍可能掩蓋新的高影響失敗。紀錄每次測試使用的準確設定，並保留足以讓其他稽核人員復現結果的材料。試點結束時，依據事先商定的閾值決定擴大應用、修改方案還是停止，而不是事後憑一次最出色的演示作判斷。
向供應商或內部團隊提出的問題
詢問核心主張有哪些證據支撐、證據基於哪個系統版本和資料版本，以及排除了哪些條件。要求提供與你的部署場景相符的語言、輸入型別和風險類別的測試結果。詢問變更如何通知、迴歸問題如何發現，以及客戶如何匯出事故覆盤所需的紀錄。
還要問清：當置信度低、依賴項故障或請求超出支援範圍時，系統會如何處理。可靠的產品應有明確的失敗狀態，而不是僅僅給出更像樣的回答。責任歸屬同樣重要：明確誰能暫停流程、誰批准例外，以及重大錯誤流入正式環境後由誰通知受影響的使用者。
實用檢查清單
- 選擇模型或工具前，先明確使用者任務以及真正需要防範的失敗。
- 維護一個來自真實工作的、小規模且有版本紀錄的測試集，納入棘手案例和對抗性案例。
- 每次執行都紀錄模型、提示詞、工具、檢索設定、資料版本、延遲和成本。
- 不可逆、高影響或對外可見的操作必須經過人員確認。
- 按類別覆盤失敗，不要只看單一平均分，並將迴歸案例加入測試集。
Meydo Journal 延伸閱讀
原始資料
- 評估最佳實踐 — OpenAI
