企業 AI 測試集怎麼做？案例來源、標註、切分與版本完整指南
企業 AI 測試集不是隨手整理二十個漂亮問題，也不是把網路上的模型題庫搬進公司。它要代表實際使用者、資料、權限、例外與錯誤後果，並讓不同版本能在相同條件下重跑。NIST AI RMF Measure 要求記錄測試集、指標與 TEVV 工具，並在接近部署條件的環境量測；這是自願性框架，不是固定樣本數或認證。
先定義評測單位與決策
測試集要對應完整系統：提示、模型、檢索、工具、資料、人工關卡與輸出目的。先寫這次要決定 PoC、限縮試用、上線或版本替換，再選能影響決策的案例。若只想比較模型本身，不能把結果直接外推到含 RAG 與 Agent 的正式流程。
用AI 驗收計畫產生器建立第一版系統範圍與建議案例，再到AI 測試案例庫挑選正常、邊界、依據、安全、營運與人工案例。每題至少要有案例 ID、來源、適用版本、預期行為、失敗訊號、嚴重度與證據欄位。
從真實工作抽樣，但不要只抽容易案例
先從正式流程抽樣常見任務，依部門、角色、資料來源、語言、長度、類別與風險分群。接著補上真實資料很少但後果很大的情境：必要欄位缺漏、規則邊界前後、新舊來源衝突、無答案、跨角色查詢、提示注入、工具逾時、重複寫入與人工停止。
測試資料涉及個資或機密時，優先使用合成、遮罩或最小必要樣本，並限制存取與保存。不要把正式客戶對話整批複製給不明評測服務；資料流與供應商也屬於系統邊界。
標準答案可以是行為與證據
擷取與分類可用欄位、標籤與混淆矩陣；RAG 可標註相關文件、必要主張與無答案；Agent 要列允許、需批准、禁止的動作及外部狀態。生成任務可用 rubric，把必要要點、禁止事項、來源與嚴重錯誤分開。不是所有題目都有唯一文字答案，但每題都應有可重現的判斷規則。
標註者分歧不能默默平均。先寫標註指南，用一小批案例校準，再記錄爭議、裁決與變更原因。NIST AI 800-2 目前仍是初稿，其中也強調評測目標、benchmark 適配、協議、實作、執行與報告要完整揭露；自動基準不能滿足所有目的。
開發、驗收與回歸資料要分開
開發集可以反覆查看並用來除錯；驗收集應避免被團隊針對性調整；回歸集則保存已發現的重大失敗與代表性案例。資料有限時可做版本化切分與輪替，但必須記錄哪些題目已被看過，避免把記住答案誤當泛化能力。
每次新增案例都要有原因：真實事件、近失、使用者回報、資料變更或新風險。把測試版本、逐題結果與批准結論連回AI 系統清冊及AI 評測指標資料庫，上線後才知道什麼變更要觸發重測。