一份模型評估報告裡，最容易被記住的往往是第一個數字：整體準確率提高了多少、平均處理時間縮短了多少。這些數字有用，我也需要它們。但如果要決定一項 AI 功能能否上線，我會接著問：平均值把哪些人的經驗合在一起？錯誤集中在什麼情況？被判錯的人有沒有辦法知道並修正？
先定義問題：平均值回答的是整體，不是每個人
假設某項系統幫忙篩選大量申請資料，整體表現看起來不錯；但對一小群資料格式較特殊的申請者，它經常把完整資料判成缺件。這只是說明評估問題的假設情境，不是我參與過的專案。即使這群人占比不高，對被擋下的當事人而言，錯誤也不會因為全體平均漂亮就變小。
我不認為任何模型都能做到零錯誤。真正需要定義的是：哪些錯誤代價較高，代價由誰承擔，以及我們用什麼證據判斷風險可以接受。若把所有判斷壓成一個分數，這三個問題就很容易消失。
已知的評估邊界：分數取決於測試怎麼設計
模型測試的結果，取決於測試資料與評分方式。資料沒有涵蓋的情況，分數就無法替它說話；對不同錯誤給相同權重，分數也不會主動告訴我們哪一種錯誤更值得擔心。這是評估方法的邏輯，不是模型好壞的道德判決。
因此，我想看的不只有總分，還有失敗案例的類型、不同條件下的表現，以及測試資料與實際使用情境之間的差距。某些群體樣本太少時，不宜用看似精確的百分比下定論；但也不能因為樣本少，就把他們的錯誤直接忽略。這時更需要補充測試、人工檢視，並說明目前不知道什麼。
我的推論：上線門檻應由後果決定
如果模型只是替使用者整理可隨時改動的清單，一次分類錯誤通常容易發現，也容易修正。如果它影響的是取得服務、申請機會或個人紀錄，錯誤即使不常發生，也可能拖得很久。兩種情境使用同一個「達標分數」，在我看來沒有足夠的理由。
比較合理的做法，是在測試之前就說明哪些錯誤不能只用平均值抵銷：什麼情況必須交由人審核，使用者如何提出異議，收到異議後多久應有回覆，以及問題被證實時怎麼補救。這些安排看起來不像模型效能的一部分，卻決定了模型出錯時，一個人會不會被留在流程外面。
風險：總分可能成為停止追問的理由
我最擔心的不是團隊使用平均值，而是會議一看到平均值過線，便把其餘問題當作細節。時間壓力確實存在；產品不可能無限期測試。但若組織先說「大家都這樣做」，再要求受影響者承擔未說清楚的風險，這不是風險消失，只是風險被移轉了。
另一種陷阱是只展示容易量化的改善。使用者因錯誤而多跑幾次流程、需要反覆申訴，或根本不知道自己被判錯，這些成本若沒有進入報告，就很難進入決策。模型團隊可以交出漂亮數字，服務團隊也可能忙著處理後果，兩邊卻沒有一張共同的風險清單。
結論：看見分布，才有資格談整體進步
我支持用數字做決策，也相信嚴謹的評估能幫助我們避免直覺偏誤。但數字應該讓問題更清楚，而不是讓權力更容易說「已經足夠」。一個負責任的評估，不只報告平均表現，還要誠實交代它在哪些情況失靈、哪些人可能承受後果、出錯之後如何回到可以申訴與修正的流程。
平均分數可以告訴我們系統大致往哪裡走。少數人的錯誤則提醒我們，前進的路上有沒有人被留在原地。兩種資訊都必須被看見，才稱得上真正的進步。