看到 Hamel Husain 在 Decoding AI 寫的這篇 The Mirage of Generic AI Metrics，覺得講得蠻到位的。Hamel 是在 GitHub、Airbnb 等公司做過 ML 的老手，跟 Shreya Shankar 一起開 AI Evals 課程，對 evaluation 這塊有很深的實務經驗。

核心論點很直接: 那些現成的通用 eval 指標 — helpfulness、coherence、toxicity、ROUGE、BERTScore — 對你的產品來說基本上是「止痛藥」，讓你感覺良好但沒解決真正的問題。

Foundation Model Evals ≠ Application Evals

MMLU、HELM 這些 benchmark 是拿來衡量基礎模型的通用能力，像是標準化考試，告訴你模型大致有多強，但不代表它適合你的產品。

一個模型可以在 benchmark 上表現超好，放進實際產品裡卻炸得很慘。因為你的產品有特定的限制、特定的領域知識、特定的使用者期待，這些都不是通用指標能抓到的。

文中舉了一個很好的例子: 房仲助手幫客戶安排看房，結果推薦了房仲根本沒空的時段 — 這是嚴重的功能性錯誤。但通用的「helpfulness」評分可能給高分，因為它「有提供選項」啊。完全 miss 掉真正的問題。

通用指標當「手電筒」而非「成績單」

Hamel 提出一個蠻務實的觀點: 通用指標不是完全沒用，但應該當「手電筒」(flashlight) 來用，而不是最終成績單。

意思是: 用這些分數去排序你的 production traces，找出最高分和最低分的案例，手動去看到底發生什麼事。例如:

  • 用 verbosity 排序，可能發現最冗長的回答都在廢話，最短的回答又漏掉關鍵資訊
  • 在 RAG 系統裡，similarity score 拿來診斷 retriever 有沒有抓對文件，這是合理的用法
  • 低分有時候反而揭露你的 golden reference 本身就是錯的

重點是: 指標是調查的起點，不是結論。

正確做法: Error Analysis → Custom Metrics

文章提出的替代方案是一套 application-centric 的工作流，根基在「質性錯誤分析」(qualitative error analysis)。方法論其實借鑑了社會科學的 grounded theory:

Step 1: 收集資料 — 最好用真實的 production data。如果是 cold start，可以用合成資料，但要有假設地生成，不要亂撒。文中建議先定義 3-5 個維度 (例如食譜機器人: 飲食限制、料理類型、查詢複雜度)，組合出 tuples，再用 LLM 轉成自然語言查詢，收集 100-200 條 traces。

Step 2: Open Coding — 逐條看 trace，寫下觀察到的問題。關鍵原則: 描述發生了什麼，不要急著診斷原因。而且這步驟不能外包，必須是懂產品的人來做。

Step 3: Axial Coding — 把雜亂的筆記歸類成結構化的 failure mode 分類。可以讓 LLM 幫忙初步分組，但最終分類必須自己審。

Step 4: 迭代到飽和 — 反覆看新的 traces 直到不再出現新的 failure type。

LLM-as-a-Judge 要怎麼做才可靠

這部分我覺得特別有價值。很多人用 LLM-as-a-Judge 就是寫個 prompt 然後「prompting and praying」，但 Hamel 提出了一套 ML-inspired 的驗證流程:

  1. 從 error analysis 收集至少 100 個 labeled examples per failure mode
  2. 切分資料 — 但比例跟傳統 ML 不同: Training 20% (選 few-shot examples)、Dev 40% (迭代 prompt)、Test 40% (最終驗證)。因為你不是在訓練模型，是在「programming with prompt」
  3. 在 Dev set 上用 TPR/TNR 來衡量 judge 的準確度，目標 80-90%+
  4. 最後在 Test set 上做一次最終驗證，確認沒有 overfit 到 dev set

這個流程的好處是: 當 PM 問你「Constraint Violation 這個指標是什麼意思?」你可以直接拿出具體的失敗案例來說明，而不是含糊地說「嗯就是一個通用分數啦」。

結語

文末一句話我覺得講得很好: AI 產品的護城河不是模型，是 evaluation process。 這也呼應了我一直在說的 — 做 LLM 應用不只是調 API，真正的功夫在 eval、在理解你的使用者到底在哪裡卡關。

通用指標給你安全感，但那是假的。花時間去看你的 data，讓真實的 failure mode 引導你建立真正有意義的 metrics，這才是正路。

原文: The Mirage of Generic AI Metrics