60 分鐘
三方比較：現行流程、非 AI 改善、AI 輔助
評估方法必須包含現行流程、可行的非 AI 改善方案（例如更新知識庫、增加人力、簡化表單）與 AI 輔助方案三方比較；若某一方不適用，必須在評估計畫中明確說明原因，不能省略不提。
三方比較設計範例（沿用 SYN-CS-001）| 方案 | 說明 | 預期指標 |
|---|
| 現行流程（baseline） | 客服人員手動搜尋知識庫並草擬回覆 | baseline_log.csv 的全流程分鐘數 |
|---|
| 非 AI 改善 | 整理並更新過期知識庫文件，加上關鍵字索引 | 同一批案例重測，預期減少搜尋時間 |
|---|
| AI 輔助 | AI 草擬回覆初稿並附引用來源，人工核對後送出 | 同一批案例上，AI 輔助全流程分鐘數與重大錯誤率 |
|---|
注意
常見錯誤：只比較「現行流程」與「AI 輔助」，跳過非 AI 改善方案。如果一個簡單的知識庫整理就能達到大半的效益，這是 Sponsor 必須知道的資訊，不能被 AI 方案的亮點掩蓋。
重點: 沒有非 AI 改善方案的比較基準，就無法回答「這個效益是不是非用 AI 不可」這個 Sponsor 一定會問的問題。
60 分鐘
開發集與驗收集：穩定識別碼與排除規則
開發集（development set）用來調整 Prototype，驗收集（acceptance set）用來做最終判斷；驗收集不能被用來調整 Prototype，否則評估結果會系統性高估。兩者都需要穩定識別碼、明確用途與排除規則。
開發集／驗收集欄位（沿用 SYN-CS-001 schema.md）| 欄位 | 說明 |
|---|
| case_id | 穩定識別碼（例如 DEV-001、ACC-001），不可重複使用同一編號代表不同案例 |
|---|
| case_category | 一般、缺漏資訊、來源矛盾、來源過期、無答案、權限限制（依專案需求調整） |
|---|
| split | dev 或 acceptance，一經指定不可事後更改以配合結果 |
|---|
| exclusion_reason | 若案例因故排除（例如資料損毀），需記錄原因，不可悄悄刪除 |
|---|
注意
常見錯誤：Prototype 開發過程中「順手」把驗收集的案例拿來除錯調整，之後又直接拿驗收集算分數。這等於用同一批資料訓練又驗收，分數會失真；驗收集一旦被看過就必須換一批或重新標記為開發集並公開說明。
資訊
SYN-CS-001 的 cases_practice.csv 提供 40 筆合成案例，涵蓋六種類別，可直接切分為開發集與驗收集練習使用（合成練習不代表正式專案的驗收樣本數）。
重點: 驗收集是用來做最終判斷的資料，一旦被用來調整 Prototype，就失去驗收的意義。
60 分鐘
量測方式與停止條件
評估必須分開報告任務品質、完整流程時間、人工修改量與成本，不能只給一個綜合分數；重要錯誤（例如給出錯誤資訊卻語氣自信）不能被整體平均掩蓋，樣本不足時必須明確揭露。
- 任務品質：依案例類別分別報告正確率／品質分數，不跨類別平均掩蓋弱項。
- 完整流程時間：包含 AI 生成、人工核對、修正與重做，不是只算 AI 回應秒數。
- 人工修改量：人工需要修改的比例與程度，反映實際可用性。
- 重要錯誤：單獨列出高風險錯誤類別與案例，即使數量少也要揭露，不可用平均分數稀釋。
資訊
若使用 LLM-as-judge 輔助評分，僅能作為輔助，需要有人工校準樣本，並記錄人工評分與 LLM 評分不一致時的處理方式（例如以人工判定為準）。
注意
停止條件（stop criteria）必須在測試前就定義好，例如「重大錯誤率超過 10% 立即停止並列為 Hold」，不能等看到結果不理想才臨時決定「這次先不算」。
- 1練習
為你的專案寫出：三方比較設計、開發集／驗收集切分規則、至少三種量測指標與一個停止條件，整理成 evaluation plan 草稿。
重點: 停止條件要在看到任何結果之前就定義清楚，否則事後很容易被結果本身影響判斷。
