CourseFoundry 技術筆記

LLM 輸出如何驗收？把期待寫成可重跑的測試

更新日期：2026 年 10 月 8 日 · 約 5 分鐘閱讀

LLM 回答可以有變化，但產品規格不能只剩「看起來不錯」。先說清楚任務成功的條件，再用一組固定案例比較提示詞、模型或設定的改動，才能看見改動帶來的好處與退步。

先把「好答案」拆成可檢查的條件

驗收方式要配合任務。分類結果、JSON 欄位和允許使用的來源網址，適合用程式檢查；摘要是否抓到重點、解釋是否易懂，通常需要逐項評分或人工抽查。若答案本來可以有多種寫法，就不要把與參考答案逐字相同當成唯一標準。

描述任務與失敗風險

寫下輸入是什麼、輸出要給誰使用，以及錯誤最可能造成什麼後果。把「內容正確」再拆成可觀察的項目，例如不可超出提供的資料、必須保留特定欄位、不能捏造來源。

留一小組固定測試案例

從典型輸入開始，也加入缺欄位、互相矛盾、格式邊界和超出能力範圍的案例。保存輸入資料與來源版本；不要把真實個資或機密直接放入測試集。

把檢查分成硬條件與品質判斷

硬條件可自動確認，例如 JSON 可解析、必填鍵存在、類別屬於允許集合、引用網址出現在輸入來源中。語意品質另以具體規準評分，並保留人工覆核，不要讓單一模型評分取代高影響決策的責任人。

比較改動，記錄重現資訊

每次執行都記下模型識別名稱或版本、提示詞版本、生成設定、測試資料版本、執行時間及檢查程式版本。對結果有隨機性的任務，可在相同案例上重複執行，觀察失敗型態是否穩定出現。

分析失敗，再擴充案例

整體分數上升不代表每個重要案例都改善。逐項檢查退步案例、邊界案例和被誤判的原因；把新發現加入測試集，再決定是否採用這次改動。

一份精簡的驗收表

檢查項目	可用的方法	例子
輸出結構	程式檢查	JSON 可解析、必填欄位齊全、欄位型別正確。
範圍與依據	規則檢查加人工抽樣	每個事實主張都能回到允許的來源；缺少依據時清楚標示未知。
語意品質	明確評分規準或成對比較	是否回答問題、是否保留重要細節、有沒有互相矛盾。
風險案例	人工設計邊界案例	資料缺漏、來源衝突、要求模型猜測答案。
改動影響	版本化結果對照	比較新舊提示詞在同一組輸入上的通過與退步項目。

用這個小契約開始

任務：根據提供的產品文件回答使用者問題。
成功條件：
- 輸出含 answer、evidence_urls、unknowns 三個欄位。
- evidence_urls 只能引用本次輸入列出的網址。
- 文件沒有交代的細節必須放入 unknowns，不可以猜測。
- answer 直接回應問題，不加入文件以外的產品承諾。

固定案例：
1. 文件有完整答案。
2. 文件沒有答案。
3. 兩份文件內容互相矛盾。
4. 使用者要求提供文件未說明的保證。

記錄：模型版本、提示詞版本、參數、案例集版本、執行日期。
覆核：逐項查看失敗案例；高影響輸出由負責人確認。

測試集不是保證書。它只顯示系統在已測案例與條件下的表現。真實輸入會變化；用途、模型或提示詞改變時，要重新評估，並持續收集經授權、去識別化的失敗案例。

選擇評估工具時，先看目前的產品狀態

OpenAI 官方文件把評估描述為：先定義成功條件、準備測試輸入、執行並分析結果，再反覆改善。文件也說明 Evals 平台正在退場：既有 Evals 將於 2026 年 10 月 31 日轉為唯讀，預計 2026 年 11 月 30 日關閉；剛開始探索評估的使用者可先看 Datasets。工具時程可能再更新，採用前請直接查看官方公告。

OpenAI：Working with evals · OpenAI：Evaluation best practices