Prompt 評估
上線前怎麼知道品質穩定
Eval（evaluation，評估）就是幫你的 AI 功能建一套「考卷」：準備一批有標準答案的測試題，讓 prompt 跑一遍，自動打分，看它到底穩不穩。沒有 eval，你只是「試了幾次覺得還行」就上線，之後客戶遇到的錯你根本不知道。要把 AI 功能當產品交出去，eval 是從「感覺可以」升級到「有數據證明可以」的唯一方法。
這一站重點
- 「試了幾次覺得可以」不算數——你手動試的那幾題，跟真實使用者會問的千奇百怪不一樣。
- eval 的核心是一份 測試集：一批有代表性的輸入，加上你期望的輸出（標準答案或評分標準）。
- 兩種打分法：code-based grading（程式打分）——答案能用程式檢查對錯時用（分類對不對、有沒有含關鍵字、格式合不合法）。
- model-based grading（模型打分，LLM as judge）——答案沒有唯一正解時，用另一個 Claude 當評審，依你給的標準打分（回覆有沒有禮貌、有沒有答到重點）。
- 改 prompt、換模型、上線前，都先跑一次 eval 比較分數——這樣你才知道改動是變好還是變壞，而不是憑感覺。
深入研讀 · 實作步驟
上面的重點讀完就夠用了；想真的搞懂原理、照著做，往下看完整說明與步驟。
先講為什麼非做不可。你在聊天視窗把一個客服分類 prompt 試了五、六次，覺得「嗯，很準」，就上線了。問題是：真實客戶一天丟進來的訊息有幾百種講法——有人打錯字、有人中英夾雜、有人一則訊息問三件事。你手動試的那幾題根本蓋不到。結果就是上線後默默錯一堆，你還不知道，直到客戶抱怨。eval 的精神就是把「憑感覺」換成「有一張考卷、有分數」。這在你要把 AI 功能當成產品、對客戶或老闆負責時，是不可跳過的一步。
eval 的第一塊是測試集——一批「輸入加期望輸出」的題目。輸入要盡量涵蓋真實世界的多樣性：正常的、刁鑽的、模稜兩可的、會出錯的邊界案例都要放進去。期望輸出可以是明確的標準答案（這則訊息應該分類為「退款」），也可以是一組評分標準（好的回覆應該：有同理心、給出下一步、不超過三句）。這份測試集一開始不用大，二三十題有代表性的，就比你隨手試五次強太多；之後每次線上出包，就把那個案例補進測試集，讓考卷越來越貼近現實。
第二塊是怎麼打分，官方課程分成兩大類。第一類 code-based grading（程式打分）：當答案能用程式客觀判斷對錯時用。例如分類任務——Claude 回「退款」，你的標準答案也是「退款」，程式比對相等就得分；或檢查輸出是不是合法 JSON、有沒有包含必要欄位、字數有沒有超標。這類又快又便宜又客觀，能用就用。第二類 model-based grading（模型打分，也叫 LLM as judge）：當答案沒有唯一正解時用——像「這封客訴回覆寫得好不好」沒有標準答案，你就寫一份評分準則，請另一個 Claude 當評審，依準則給分（例如語氣 1 到 5 分、有沒有答到重點 1 到 5 分）。用機器當評審，才能規模化評估幾百題主觀品質。
第三塊是怎麼用進日常。eval 不是上線前跑一次就丟，而是變成你的迴歸測試（regression test）：每次你調 prompt、換模型（例如想從 Sonnet 降到便宜的 Haiku 省錢）、或加新功能，都先讓整份測試集跑一遍，比較分數。分數上升代表改對了；掉了代表你改壞了、該回退。這樣你做每個決定都有數據撐腰，而不是「感覺新版好像比較好」。工具方面，除了自己寫腳本，官方課程也介紹用 Promptfoo 這類現成評估框架，它能同時支援程式打分與模型打分、一鍵比較不同 prompt 或模型的成績，中小企業想快速起步很好用。一句話總結：沒有 eval 的 AI 功能，等於沒測試就上線的軟體——能動，但你不知道它什麼時候會壞。
實作步驟
- 收集真實輸入當測試集 從實際場景撈 20 到 30 個有代表性的輸入：正常的、刁鑽的、會出錯的邊界案例都要。別只放你希望它答對的漂亮題目。
- 為每題定義「什麼叫答對」 能有標準答案的就寫標準答案（該分成哪類、該含哪些欄位）；沒有唯一正解的就寫評分準則（好的回覆要具備哪幾點）。
- 能用程式判對錯的,用 code-based grading 分類、抽取、格式檢查這類客觀任務，寫程式比對標準答案或檢查格式（是否合法 JSON、是否含必要欄位、字數上限）。又快又便宜，優先用。
- 主觀品質的,用 model-based grading 像回覆語氣、是否答到重點這類沒標準答案的，寫一份評分準則，用另一個 Claude 當評審依準則打分，才能規模化評估。
- 跑整份測試集、算總分 讓 prompt 跑完所有測試題，統計通過率或平均分。可用
Promptfoo這類框架一鍵執行與比較。這個分數就是你的品質基準線。 - 每次改動前後都比較分數 改 prompt、換模型、上線前，都先跑一次 eval，比較分數升降再決定。線上出的每個新錯誤，補進測試集，讓考卷越來越貼近現實。
常見踩雷
- 測試集只放「你希望它答對」的漂亮題目——真實世界的刁鑽輸入沒測到，上線照樣爆。
- 主觀任務硬用程式比對字面相等——回答意思對但用字不同就被誤判成錯。
- 換模型省錢卻沒跑 eval——可能悄悄掉了品質，客戶先幫你發現。
- eval 跑一次就丟——它該是每次改動都重跑的迴歸測試，不是一次性儀式。
深入來源：anthropics/courses・Prompt Evaluations（CC BY-NC 4.0）
為一個 prompt 準備 20 題測試集，跑一次自動打分、算出通過率當作品質基準線。