開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
如何用可重複測試集評測 AI 提示詞，避免把單次好結果當成結論
Olivia Park
2026年9月4日· 8 分鐘讀完
要可靠地評測 AI 提示詞，應讓每個 prompt revision 在相同版本的案例、配置、評分規則和發佈門檻下運行。對可變輸出重複運行，保留全部原始結果，把確定性失敗與人工判斷分開，並如實報告不確定性。一次看來很好的回答只是示範，不是 benchmark。
實用 AI 指南介紹通用驗證及資料邊界；本文假定工作已足夠明確，目標是在不暗中改變問題的前提下比較提示詞 A 與 B。
關鍵要點
- 寫案例或看輸出前，先定義評測要支援的決定。
- 凍結具代表性的案例集 revision，並盡量保留獨立 holdout。
- 嚴重失敗、確定性檢查與偏好評分必須分開。
- 對齊模型、工具、參數、檢索來源和運行條件。
- 人工評審要隱藏版本標籤並隨機排列次序。
- 對可變輸出重複運行，展示分佈而不只展示最佳值或平均值。
- 挑戰版本只有通過明確迴歸和安全門才可發佈。
如何可重複地評測 AI 提示詞？
可重複 benchmark 是另一位 reviewer 可以重跑和解讀的實驗記錄，並不要求隨機模型逐字返回相同答案。真正固定的是目標、輸入、運行設定、評分、重複次數和決定規則，這樣才有機會分辨提示詞變化與實驗變化。
NIST AI RMF Measure Playbook 建議記錄測量方法、測試集、指標、流程、材料及工具詳情，因為這些記錄是可重複性和一致性的基礎。［1］
| 評測欄位 | 必需記錄 |
|---|---|
| Experiment ID | 穩定編號和運行日期 |
| 決定 | 比較結果要支援哪個選擇？ |
| Prompt revisions | 不可變的 A、B 正文或引用 |
| Case-set revision | 精確案例、標籤、排除項和 holdout 規則 |
| 輸入 revision | 固定附件、檢索快照和預處理 |
| 預期屬性 | 好答案必須包含或保留甚麼？ |
| 嚴重失敗 | 哪些結果不論總分多少都失敗？ |
| Rubric | 維度、量尺錨點、權重和同分處理 |
| Scorers | 確定性檢查與具名人工角色 |
| 配置 | 模型/工具類別、參數、系統指令和權限 |
| 重複 | 每個 prompt-case 運行多少次，如何隨機排序？ |
| 證據 | 原始輸出、檢查、評分和分歧 |
| 決定規則 | 迴歸門檻、不確定性規則、批准人和結果 |
這比寫好一條提示詞更窄：修改措辭負責產生候選，benchmark 負責提供選擇證據。
步驟 1：先寫評測問題和發佈規則
用一句話寫清決定，例如：「revision B 能否取代 A，用於從英文支援摘要抽取五個已批准欄位？」列明輸入群體、輸出契約和排除用途。「哪個提示詞更聰明」無法形成可辯護的案例集。
運行前列出嚴重失敗，例如虛構事實、漏掉必需警告、洩露合成秘密標記、輸出結構非法、聽從輸入文件內的指令，或建議未授權操作。風格平均分稍高也不能抵銷一次嚴重安全迴歸。
只有同時符合以下條件才發佈 B：
1. 固定嚴重案例集中沒有嚴重失敗；
2. 所有確定性契約檢查不差於 A；
3. 人工中位評分未越過批准的迴歸界線；
4. 沒有任何指定類別越過失敗門檻；
5. 已檢查評分分歧和運行間波動；
6. 工作 owner 批准完整證據包。
門檻應來自工作風險和營運需要，不能看完結果才選一個讓 B 勝出的數字。NIST 亦建議記錄指標選擇理由及無法測量的風險。［1］
步驟 2：建立並版本化案例集
先寫工作分類，再為每類建立獲授權、已脫敏或完全合成的案例。至少包含常見輸入、困難但有效的輸入、欄位缺失、證據衝突、結構畸形、長度邊界、對抗指令，以及正確行為是拒答或追問的情況。
| 案例欄位 | 含義 |
|---|---|
| Case ID | 例如 missing-owner-01 的穩定編號 |
| 類別 | 正常、邊界、無效、對抗或拒答 |
| 輸入 | 凍結的脫敏或合成材料 |
| 預期屬性 | 必須保留的事實、欄位或行為 |
| 禁止行為 | 虛構、洩露、越權操作或格式逃逸 |
| 嚴重度 | 嚴重、主要或次要 |
| 評分方法 | 精確檢查、規則檢查或人工量規 |
| 理由 | 為甚麼該案例代表目標用途？ |
| 來源與權限 | 模式來自哪裏，是否容許評測？ |
不要預設把正式環境流量當測試集。從真實故障提取模式時，要最小化和脫敏，保留權限記錄，並檢查轉換有否刪掉要測的特徵。資料邊界可參考AI 私隱風險清單。
把開發集和發佈 holdout 分開。作者反覆看到並據此調整的 holdout 已不再獨立，應記錄存取並透過受管治變更更換案例，而不是暗中編輯。
NIST GenAI 評測計劃把生成器和 evaluator 分開，並按工作定義 challenge，而不是使用一個萬能分數。［2］ 摘要、抽取和教學提示詞也應採用不同案例及標準。
步驟 3：分開確定性檢查和人工判斷
程式能可靠判斷的屬性交給程式：JSON 是否有效、鍵是否準確、類型和長度、禁用字串、ID 是否保留、引用是否連續、拒絕標記是否出現。不要讓人工 reviewer 為解析器可以判斷的語法評分。
語義質素使用帶可觀察錨點的 rubric，不用「優秀」「一般」等模糊標籤。可用評分量規工作流程起草，但量尺必須由工作 owner 批准。
| 維度 | 0 | 1 | 2 |
|---|---|---|---|
| 證據忠實 | 虛構或顛倒事實 | 大致有據，但含無支援推論 | 每項重要主張都能對應輸入證據 |
| 不確定性 | 隱藏關鍵未知 | 提到不確定卻沒指出位置 | 保留未知並說明缺少的證據 |
| 可執行性 | 建議危險或無法執行的操作 | 只有寬泛下一步 | 給出獲准操作、owner 和停止條件 |
嚴重失敗不能放進加權平均，否則多個風格分可能抵銷一次虛構批准。輸出畸形或 reviewer 缺乏領域背景時，應記錄「不可評分」。
步驟 4：鎖定環境並運行 A 與 B
A 和 B 必須收到相同輸入及等價運行條件。凍結系統指令、工具權限、檢索語料、預處理、抽樣設定、輸出上限和結構 schema；服務未公開的參數記作未知，不聲稱已控制。
隨機決定 A/B 次序，並以新對話或隔離 session 防止上下文滲漏。若使用工具，在受控環境運行並於每個案例間重設狀態。評測不得傳送外部訊息、修改正式環境資料、購買或部署。
執行完整矩陣，包括失敗的運行。選擇性重跑可用於診斷，但不能取代原始結果。完整保留原始回應或受控引用、prompt/case revision、運行序號、隨機位置、時間與配置、允許記錄的工具軌跡、自動檢查結果，以及一致收集而與決定相關的延遲或成本。拒答、逾時及畸形輸出也是真實結果，應按預設規則分類，不能從分母刪除。
步驟 5：重複可變輸出並報告不確定性
即使可見設定相同，生成式輸出也可能變化。每個 prompt-case 要重複至足以顯示會改變發佈決定的波動。沒有通用次數；必須在看到勝方前按風險與資源決定，樣本太小時要降低結論強度。
Google SRE 的可靠性測試指引解釋重複測試如何協助區分持續行為與雜訊，並強調測量的不確定性。［3］ 提示詞評測應按案例類別保存通過率及評分分佈，而不是只給總平均。
報告嚴重失敗所屬 prompt、case 和 run；確定性通過率的分子與分母；序數評分的中位數和範圍；類別結果；不穩定組合；缺失運行原因；裁決前的 reviewer 分歧。十個合成案例不能支援普遍的百分比品質聲稱。
步驟 6：盲化人工評審並處理分歧
從評審包移除 prompt 標籤、revision、運行次序和作者，隨機排列同一案例輸出，同時在受控位置保存映射。Reviewer 應先獨立按相同錨點評分，再討論。
專業主張至少需要一位領域 reviewer。Sarah Lin 應覆核樣本設計、量規、分析和結論強度。發生分歧時，保留原始評分和原因，再依預先規則裁決；不能以協商後的一個數字覆蓋證據。
注意偏好長答案、把自信當準確、獎勵熟悉措辭或識別作者風格等偏差。盲化評審包能減少部分偏差，但無法補救不足的量規或欠缺代表性的案例集。事實判斷應遵循AI 輸出事實核查流程，回到一手來源而非 reviewer 記憶。
步驟 7：作出並記錄發佈決定
按步驟 1 的規則比較：先看嚴重失敗，再看確定性契約、類別迴歸、人工評分、分歧和波動。檢查所謂改進是否其實來自缺失運行、配置漂移或測試集污染。
NIST 生成式 AI Profile 把評測放在持續風險管理及人工監督中，並覆蓋虛構、私隱、安全與資訊完整性。［4］ 發佈不能只看品質平均分。
使用以下四種結果之一：
- 發佈： B 通過所有強制關卡，負責人接受證據。
- 修訂： B 有潛力，但有可修正的迴歸或不清晰的指示。
- 保留 A： B 帶來的好處不足，或越過了某個門檻。
- 無法定論： 樣本、量規、配置紀錄或評審一致程度不足以支持決定。
勝方以新不可變版本發佈；新失敗加入迴歸集，但不能改寫歷史結果。測試生成指南可協助補充案例，生成的預期仍要獨立驗證。
總結
- 看輸出前寫清決定和失敗門。
- 版本化具代表性的案例集，保護 holdout 獨立性。
- 分開確定性驗證、人工判斷與嚴重失敗。
- 在相同記錄條件下運行 A/B，保留所有結果。
- 重複隨機運行，報告分佈和評分分歧。
- 把結論限制於當前工作、案例、配置和日期。
常見問題
評測提示詞需要多少個案例？
沒有通用數量。先覆蓋每種重要工作和嚴重失敗，再補至足以支援目標決定，並如實報告案例數和限制。
每條提示詞應重複運行多少次？
在看到結果前，按工作波動、後果和評測預算決定。次數應足以揭示可能改變發佈選擇的不穩定性。
輸出應該逐字比較嗎？
只有完全一致的文字屬契約時才這樣做。大多數生成工作應比較必需屬性、禁止行為和量規，容許合理措辭變化。
可以讓 AI 為輸出評分嗎？
可作補充訊號，但要記錄 grader 提示詞、配置、偏差和驗證。重要結論不能以同類模型的偏好作唯一 ground truth。
甚麼是嚴重失敗？
它是不論平均分多高都阻止發佈的結果，例如虛構證據、洩露禁止資料、危險操作、遵從提示注入或下游會誤用的非法格式。
如何防止測試集污染？
限制 holdout 存取、記錄 revision、分開開發與發佈案例，並以受控流程替換已暴露案例。作者據此調整過的案例只算開發證據。
Reviewer 對勝方意見不同時怎麼辦？
保留原始評分，找出產生分歧的量尺錨點，再按預定規則裁決。高分歧也可能代表證據不足。
平均分更高就應發佈 B 嗎？
不一定。先檢查嚴重失敗、類別迴歸、波動、不確定性和營運限制；小幅平均提升不能抵銷新的危險行為。
何時刷新 benchmark？
工作、輸入分佈、政策、模型或工具、檢索來源、輸出消費者或已知失敗模式變化時都要刷新，並保留舊 revision。
來源
- NIST — AI RMF Playbook, Measure — https://airc.nist.gov/airmf-resources/playbook/measure/
- NIST — GenAI Evaluation Program — https://ai-challenges.nist.gov/genai
- Google SRE — Testing for Reliability — https://sre.google/sre-book/testing-reliability/
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
Sources checked 2026 年 9 月 4 日。
