Demo 不等於可上線：用 Eval 建立驗收標準

2. Acceptance Loop｜Specify → Measure → Improve 把模糊期待變成可以反覆檢查的購買標準。

1. Demo vs Eval｜可能做到，不等於可以上線

一個精心挑選的輸入、清楚 prompt 和熟悉示範者，很容易得到漂亮結果。真實工作卻有掃描錯誤、缺漏欄位、矛盾規則、奇怪格式、時間壓力和不能出錯的少數個案。

因此 demo 應回答『值不值得繼續探索』；eval 才回答『做到甚麼程度才值得購買、上線和擴大』。兩者用途不同，不應共用同一個成功標準。

Specify 把『要準確』改寫成理想輸出、不可接受錯誤和例外規則；Measure 用代表真實工作的資料持續測試；Improve 根據失敗類型改 context、工具、流程或模型，再重跑同一標準。

OpenAI 把 contextual evals 比作把模糊商業目標變成測量方法。最重要的不是某個平台，而是管理層先把『甚麼叫值得買』說成團隊和系統都能檢查的條件。

由業務專家收集正常、缺漏、模糊、邊界和高風險例子，並寫下可接受結果。初期數量不必追求龐大，但要代表真正會影響採購和使用信心的情況。

Golden Set 不是一次完成的考卷。每次上線遇到新例外、使用者大幅修改、或模型版本改變，都應把有代表性的個案加入，讓企業累積一套自己的品質資產。

只看最終文字可能漏掉真正風險。Agent 是否引用正確來源、使用獲准工具、在需要時停止、把例外交對人，以及失敗能否被發現，同樣屬於產品品質。

對管理層有用的 dashboard 應包含：任務完成率、人工修改率、未發現錯誤、例外量、升級是否正確、完成時間與使用者採用，而不是只展示平均『AI accuracy』。

Capability eval 問新系統能否處理更難工作；Regression eval 確保改 prompt、context、模型或工具後，原本做得到的事沒有悄悄變差。兩者缺一，迭代便容易變成修一個錯、製造另一個錯。

Anthropic 亦指出 Agent 的多步工具使用令評估更難，單一分數無法解釋全部行為。企業需要把自動 grader、規則檢查和人工審閱組合起來。

不要先要求團隊寫一份完整 AI 規格。帶來一小批最近真的發生過的例子，逐一標記理想結果、不能接受的錯誤、誰可判斷，以及現時完成要多久。

如果這些例子仍說不清，現在最值得補的不是模型，而是驗收標準。

評估集大小、grader 和通過標準必須按任務風險調整；一小批例子只是一個需求發現起點，不是上線所需樣本量。LLM grader 亦需要由人校準，不能當作客觀真相或取代行業專業判斷。