第一堂不准你寫評分標準：AI 功能怎麼測、evals 怎麼做

先問一個問題。

你手上那個 AI 功能，上一次有人真的坐下來，把它的輸出一筆一筆讀完，是什麼時候？

如果答案是「沒有」，那你每次改 prompt 之後說的「嗯這樣好像對了」，其實只驗證了眼前那一筆。其他三十種情況變好還是變壞，你不知道。

吳恩達說 evals 是最能拉開差距的一項技能，也是最難練的。而教這件事教得最兇的兩個人，Hamel Husain 和 Shreya Shankar，他們的課訓練過四千五百多個工程師和產品經理，學員來自 OpenAI、Google、Meta、Amazon、Microsoft。

課程第一件事不是教你寫評分標準。是叫你去讀 log。

這篇拆五件事：為什麼要反過來、二十筆怎麼標、三種評分方式怎麼選、LLM 當裁判會怎麼騙你、以及什麼時候該停手。

先講清楚 eval 是什麼

Eval 是一組固定的輸入，加上一個自動判定對錯的機制，讓你每次改動都能量到同一件事有沒有變好。

它不是 benchmark。benchmark 量的是模型的通用能力，eval 量的是你這個功能在你的資料上做對了沒有。

沒有這個東西的時候，你的迴圈長這樣：使用者說怪怪的，你打開那個 case，改 prompt，看起來對了，上線。

問題就出在「看起來對了」這四個字。

系列第一篇提過吳恩達的判斷：最能區分「AI 系統做得好」跟「做不好」的特質，就是有沒有辦法推動一個紀律嚴謹的 evals 與錯誤分析閉環。而且他說這技能很難練，因為做法會隨專案、甚至隨專案階段大幅改變。

難的地方其實不在寫程式。

難在順序。

第一步：先讀，不要先評分

你打開後台，看到一堆對話紀錄。第一個念頭通常是：我來訂個評分標準吧，準確度、相關性、語氣，各給 1 到 5 分。

先別。

順序反了。還沒看資料就訂標準，你訂出來的是你以為會出錯的地方，不是它真正出錯的地方。這兩件事的重疊度，往往低得讓人意外。

實際會發生什麼？你會拿到一份分數很漂亮的報表，然後 production 繼續出包。因為你量的東西跟壞掉的東西，根本不是同一批。

反過來做才會準。先撈真實的失敗，讀完，再從那些失敗長出指標。這樣量出來的東西，能預測什麼會壞。

那「讀」到底怎麼讀？

分兩輪。第一輪不預設立場地看：一筆一筆讀，看到什麼寫什麼。「這句答非所問」「這裡把租客的訴求誤判成維修」「語氣太硬」，全記下來，先不管分類。這一輪的正式名稱叫 open coding。

第二輪把那堆散裝標籤攤開來分群。重點在這裡，因為你會突然發現：欸，這三十筆裡有十筆根本是同一個原因。

那一刻才是整個 evals 流程真正的起點。

有人會問，這麼機械的事為什麼不丟給 AI 做？

因為讀資料養出來的那個手感沒辦法外包。Hamel 和 Shreya 在課裡講得很白：太早把讀 trace 交給模型，你等於閉著眼睛開飛機。你之後寫的每一個評分器，都是靠這一輪讀出來的直覺撐著。

第二步：二十到五十筆，只標對錯

規模不用大，這點值得先講，因為很多人卡在「我資料不夠多」。

Braintrust 的建議是從 production 流量或真實情境撈二十五到五十筆，定義兩三個你最在乎的品質指標，跑第一次評估建立基準線。Galtea 的建議也差不多：五十筆真實失敗案例，一位領域專家逐筆給對錯，而且要附上一句文字說明。

然後是最反直覺的一條規則。

評分用對錯，不要用 1 到 5 分。

聽起來很粗糙對吧？但理由很實際。「3.5 分」沒辦法告訴你下一步該修什麼。「錯，因為它把租客的訴求誤判成維修請求」可以。

還有一個組織上的設計，課程裡叫它 benevolent dictator：標註標準要有一個人說了算。三個人各自對「這算不算錯」有不同定義的話，你標出來的資料本身就是噪音。

到這裡你手上有的是：二十到五十筆真實輸入、每筆一個對錯、每個錯附一句原因。

這樣就已經是可以跑的 eval 了。寫成二十行 script，每次改動都跑一次就好。不需要平台，也不需要框架。

第三步：三種評分方式怎麼選

從標註出來的失敗模式，長出對應的自動評分器。三種選項，判準只有一句話：這個模式能不能寫成一句斷言？

能寫成 assert 的，用 code-based。回傳格式對不對、必填欄位在不在、有沒有引用到不存在的文件 ID、金額有沒有超出範圍。毫秒級、零成本、每次 commit 都能跑。

有標準但主觀的，用 LLM-as-judge。語氣合不合適、有沒有回答到問題、摘要有沒有偏離原文。下一段會講它的坑，坑不小。

高風險、或標準本身還沒穩定的，留 human-in-the-loop。上線決策這種不可逆的判斷，人工仍然是黃金標準。

Galtea 把這三種對應到三層 pipeline，節奏各不相同。第一層是單元測試，毫秒級，每次 commit 跑，抓明顯壞掉的東西。第二層是人加模型的評估，每個 PR 對 golden dataset 跑一次，抓品質退步。第三層是 A/B 測試，用 production 流量，要夠大的樣本數才有意義，產品成熟才值得建。

想從第二層開始建的團隊，會跳過第一層那個快速回饋迴圈，然後發現第二層根本跑不動。

先有跑得快的那一層，慢的那一層才有辦法運作。

這跟 Loop vs Graph 那篇談的「加閘門」是同一個思路：迴圈本身不保證收斂，是閘門讓它收斂。

LLM 當裁判之前，先知道它會怎麼騙你

這是整個流程最容易崩掉的地方。

好消息先講。原始研究（MT-Bench 與 Chatbot Arena）顯示 GPT-4 跟人類評分者的一致率超過八成，而且這個數字跟不同人類評分者彼此之間的一致率是同一個水準。

聽起來夠好用了對吧？

壞消息有三層。

第一層，可靠度不是普遍的。 2026 年 RAND 的研究發現，沒有任何一個裁判模型在所有 benchmark 上都可靠，而且前沿模型在困難的偏誤測試上錯誤率超過五成。那個「八成一致」是特定任務、特定結構下的數字，不是保證。

第二層，它只在自己會做的題目上準。 有一篇叫〈No Free Labels〉的研究做了一千兩百筆專家標註，結論很尖銳：沒有給正確參考答案的時候，LLM 裁判只在「它自己也答得對」的題目上跟專家高度一致。給它專家寫的參考答案，能大幅緩解這個問題。

講直接一點：你最需要它幫忙抓的那些難題，正好是它最不可靠的地方。

第三層，有三個已知偏誤。 它偏好排在前面的選項（位置偏誤）、偏好比較長的回答（冗長偏誤）、偏好自己生成的輸出（自我偏好）。

第三個特別麻煩，因為裁判跟被評的模型常常來自同一個家族，架構和訓練資料重疊。那等於讓學生改自己的考卷。

有研究支持的緩解方法有四個：用你自己領域的人工抽查去校準裁判；有正確答案時把它給裁判當參考；用 meta-judge 而不是辯論式的多模型互評（後者會放大偏誤）；裁判模型選跟生成模型不同供應商的。

說白了，裁判不是免費的。它只是把標註成本換成校準成本。

第四步：怎麼知道你的 evals 是好的

evals 自己也會爛，而且爛的時候症狀很像成功。

最明顯的警訊是：分數一直往上，體感沒變。

這通常代表你在量的東西不是使用者在意的東西。

判斷裁判好不好，方法是量它跟人工標註的一致率。留一組裁判沒被調校過的資料當 holdout，量兩邊判定的吻合程度。沒有這個對照，你沒有任何客觀方式知道裁判是真的可靠，還是只是穩定地產出看起來合理的分數。

不過真正有價值的其實不是一致率那個數字。

是不一致的那幾筆。

人工說對、裁判說錯的地方，就是裁判 prompt 需要修的地方。那幾筆的資訊量，比一百筆兩邊都同意的高得多。

第五步：讓錯誤分析決定下一步做什麼

有了自動評分之後，失敗案例會開始累積。這時候的問題變成：先修哪一個。

答案不是平均用力，是分群之後修最大那群。

futureagi 整理的做法是三步。先拉出失敗的 trace：裁判低於門檻、使用者按倒讚、被升級到人工、對話中途放棄。再把使用者輸入、系統回應、trace 摘要向量化之後分群，可以跑 HDBSCAN、KMeans，或用 LLM 做主題探索。最後人工替每一群標一個根因，照影響範圍排序。

這一步才是 evals 真正的產出。

分數只是副產品，排序才是。

要讓 agent 自己把迴圈收掉的話，這套評分器就是它的 verifier。pi-autoresearch 那套自主優化迴圈能跑起來的前提，就是旁邊有一個夠可靠的評分函數在當裁判。沒有 evals，所謂的自主優化只是讓模型自我感覺良好得更快。

什麼時候該停

兩個停手訊號。

讀 trace 的停手點叫 theoretical saturation：新讀的 trace 不再產生新的失敗模式，就可以停了。不是讀滿一百筆，是讀到沒有新東西。

分群的停手點是覆蓋率：八成的失敗都能對應到已知的根因，這一輪就結束。剩下的長尾留給下一輪。

至於穩定之後長什麼樣，Hamel Husain 描述的終態小得出乎意料：兩三個 code-based eval 每次請求都跑，一兩個 LLM 裁判定期跑，每個月做一次錯誤分析抓新問題。

就這樣。

不是幾百個測試案例，也不是一整套評估平台。過度投資 evals 的訊號很好認：你建評估系統的時間，比修產品的時間還多。

但 Claude Code 團隊說不需要 evals

這個立場最常被引用的來源就是他們。說法大意是，在快速迭代的產品上，繁重的 eval 流程反而拖慢節奏。

Hamel 和 Shreya 在 Lenny's Podcast 上直接回應過，認為這個流行的立場是誤導的。

我覺得兩邊都對了一半，差別在你的失敗成本。

Claude Code 的使用者會立刻看到輸出、立刻能反饋，而且每次互動本身就是一次人工驗證。那種產品確實可以靠高頻回饋撐住。

但如果你的 AI 功能是批次跑的、是面對客戶的、或者錯了要三天後才有人發現，你沒有那個高頻回饋。你只有 evals。

判準很簡單：使用者會不會替你抓到錯？不會的話，你得自己抓。

利益揭露：以下是聯盟連結。錯誤分析最花時間的動作就是逐筆讀 trace，那是純粹的桌面工作，螢幕和手感比機器規格重要，桌面開發者 4 件套（機械鍵盤、USB-C Hub、螢幕掛燈、站立書架）是常見的 CP 值組合。

常見問題

LLM evals 要準備多少測試案例才能開始？

二十到五十筆就夠開始。Braintrust 建議二十五到五十筆加上兩三個指標，Galtea 建議五十筆真實失敗案例。重點不是數量，是那些案例必須來自真實流量或真實失敗，不是你想像出來的邊界情況。

評分要用 1 到 5 分還是對錯二選一？

對錯。Hamel Husain 與 Shreya Shankar 的課程明確主張二元判定比 Likert 量表更可操作，因為「3.5 分」沒辦法告訴你下一步要修什麼，「錯」可以。

LLM 當裁判可靠嗎？

要校準才可靠。原始研究顯示 GPT-4 與人類評分者的一致率超過八成，跟人類彼此之間的一致率相當。但 2026 年 RAND 的研究發現沒有一個裁判在所有 benchmark 上都可靠，前沿模型在困難的偏誤測試上錯誤率超過五成。

什麼時候可以停止做錯誤分析？

當新讀的 trace 不再產生新的失敗模式時，這叫 theoretical saturation。另一個實務判準是八成的失敗都能對應到已知的根因。

穩定之後的 evals 大概長什麼樣？

兩三個 code-based eval 每次請求都跑，一兩個 LLM 裁判定期跑，每個月做一次錯誤分析。這是穩定狀態，不是一開始就要建成這樣。

整套流程講完，最反直覺的其實還是第一步。

大多數人想開始做 evals 的時候，第一個動作是去找工具、找框架、找評分指標的清單。

但真正擋住你的從來不是工具。是願不願意坐下來，把二十筆失敗一筆一筆讀完。

所以問題不是「該用哪個 eval 平台」。

是開頭那一句：你手上那個 AI 功能，上一次有人真的逐筆讀過它的輸出，是什麼時候？