Evals 自動化的三個常見錯誤: Shreya Shankar 演講整理

看了 Shreya Shankar 的演講 How to Automate AI Evals (Correctly)，蠻有料的一場。這是 Hamel Husain 主辦的 AI Product Engineering 系列第一場(系列分 evals、context、systems 三類，主題是「把模型變成有用的產品，中間要做的工」)。Shreya 是資訊工程教授，也跟 Hamel 合開了那門 AI Evals 課程(ihower 也上過)。

這場要講的事很明確: 市面上賣「自動化 evals」的工具越來越多，她想說服你 evals 沒辦法整包丟給 coding agent，但 AI 還是幫得上忙，只是要用在對的地方。她刻意不點名任何一家廠商，講了三個常見錯誤，中間現場 demo 了自己寫的 error analysis skill(已開源)。

編按: 這場演講預設你已經知道 error analysis(錯誤分析)是什麼。沒有背景的話，建議先看 ihower 寫過的〈什麼是 AI 應用評估的錯誤分析 Error Analysis?〉，那篇補足了這場沒細講的部分: 為什麼 LLM 應用不能沿用傳統 ML 的評估方式(理解、規格、泛化三個落差)，以及實際跑一輪 error analysis 的四個步驟(先湊出涵蓋多個維度的 100 筆樣本、逐筆看並寫下觀察到的問題、把相似的問題歸類、反覆標到沒有新模式出現為止)。那篇也早就提到「不要用 LLM 做第一輪標註」，跟這場的主張正好接得上。

以下是重點整理:

1. 先看廠商在賣什麼

投影片一開始給了 evals 的定義:「有系統地量測你的應用的品質。」然後放了 LangSmith 年度報告的圖表，agent 上線的最大障礙排出來，第一名就是輸出品質。

接著這張投影片標題是「The Rise of Evals Automation」(自動化 evals 的興起)，貼了 LangChain、Braintrust、Arize 三家的產品頁截圖，功能標語都在講同一件事: 自動找出失敗模式、即時根因分析、從真實失敗生出合成資料。

這些工具的願景大致是端到端: 讓它讀你的 agent traces，它就告訴你應用哪裡壞了，順便幫你修好。Shreya 說這個願景很有野心，她也希望是真的，這些工具確實找得到一些錯誤，但解決不了全部的問題。

然後她在同一張投影片上疊了一個方框，寫著這場演講的核心主張:

「我們永遠沒辦法把 evals 全自動化。真正的瓶頸是知識，不是算力。對你的產品來說什麼叫『好』，答案在你自己身上，不在 trace 裡。」

她還補了第二個論證，小編覺得比第一個更有說服力: 如果真的有一個工具能幫你把產品從頭建好、把問題全部修好，那它對你所有的競爭對手也做得到同一件事，於是你的產品就沒有任何東西能跟別人區隔。換句話說，你的判斷力是你的產品唯一的差異化來源。

那 AI 到底該扮演什麼角色? 她用這場的封面投影片(本文的封面圖)回答，兩句話:

「AI 工具不該做的是: 把整個 evals 生命週期自動化。」 「AI 工具該做的是: 幫你更快地表達、更快地套用你的判斷。」

2. Analyze、Measure、Improve: AI 能幫上忙的位置不一樣

課程裡教的是三步驟的 evals 生命週期，投影片上是一個循環圖:

1. Analyze 分析你的資料，找出 AI 犯了哪些錯
2. Measure 量測這些錯誤有多普遍
3. Improve 改進你的產品，避免犯下代價高的錯

底下還特別標了「Iterate on this lifecycle」(在這個循環上反覆迭代)，意思是做完一輪不是結束。

她用一個 AI 寫作助手當例子貫穿全場，先放了一張 Graphite 的統計圖說明為什麼挑這個例子: 藍線是人寫的文章、橘線是 AI 生成的文章，兩條線在中間交叉，也就是現在網路上超過一半的文章讀起來明顯是 AI 寫的。

所以這個寫作助手的目標是「不要寫出 slop(低品質的 AI 廢話)」，但這個標準非常模糊。

這個寫作助手不是為了演講捏造的例子，是她實驗室真正在做的 DocWriter 專案，研究目標是「走到一個沒有 slop、但仍然充滿 AI 的世界」(出處: X)。其中的 plain-writing skill 已開源，後來還加了一個 deslopify 指令。投影片上 Analyze 底下列了三個子點:

• 這一步是探索導向的，「錯誤」本身不容易定義
• 例如: 你有辦法精確定義什麼叫「slop」嗎? 有辦法把所有寫作上的反模式列完嗎?
• 這跟傳統的監督式機器學習不一樣，那邊的錯誤就是「預測 != 標籤」，定義很乾淨

Measure 那一步，投影片列的是: 失敗模式(failure mode)會有很多種，例如 emoji 用過頭、「it’s not X, it’s Y」這種句型; 而且有 Pareto 法則: 80% 的問題來自 20% 的失敗模式，所以要找出最常出現的那幾種、優先修它們。

編按: 演講之後她把前兩步的分工講得更清楚 (出處: X):「evals 裡有兩個完全不同的部分: (1) 發現失敗模式有哪些，(2) 針對性地量測這些失敗模式有多普遍，好讓你決定先修哪一個。LLM 在 (1) 幫得上一些忙，但找不到全部，因為很多失敗模式是主觀的、關於人怎麼詮釋輸出。LLM 在 (2) 可以看一筆 trace 判斷某個失敗模式在不在，這樣人就不必每一筆都看。但很多人犯的大錯是讓 LLM 把 (1) 和 (2) 全部自動化。LLM judge 是人類專家的補充，不是取代。」她轉推的那則原文說得更直接 (出處: Isaac Flath): LLM judge 應該當成量測的儀器，而不是 eval 本身: eval 是人的標註，LLM judge 只是把那些標註規模化，所以跳過人的標註直接做 LLM judge 根本說不通。

Improve 那一步的選項則具體得多:

• 改 prompt (例如加一條指令:「絕對不要寫 it’s not X, it’s Y」)
• 換模型 (例如換成 Opus 4.8)
• 微調模型 (例如拿精選過的寫作範例去訓練 Kimi 2.6)
• 還有其他

注意第一條的例子「it’s not X, it’s Y」就是她等一下在 demo 裡親手標出來的那個問題。

最後她在同一張生命週期圖上加了兩個紅字註記，這是整場的定位圖:

Analyze 旁邊標了「AI 在這步做不好」，Improve 旁邊標了「AI 幫得上忙」。越往生命週期後面走，AI 能接手的部分越多; 最前面的 Analyze 高度依賴個人判斷，是最不能整包交出去的。

3. 錯誤一: 打開 coding agent 說「幫我評估這個 app」

最常見的做法是: 打開 Claude Code，丟一個 S3 bucket 或一個 jsonl 檔就開始。投影片放的是她自己的真實畫面，輸入的 prompt 是:

Check out my traces for my ai writing assistant app. can you evaluate the app? dataset.jsonl is the dataset of traces. (看一下我 AI 寫作助手的 traces。你可以評估一下這個 app 嗎? dataset.jsonl 就是那份 trace 資料集。)

agent 的反應看起來完全合理:「讓我先看一下資料集和專案結構，了解我們在處理什麼。」接著讀了 2 個檔案、列了 2 個目錄、跑了 2 個 shell 指令。她特別強調「這是真實截圖，沒有動過手腳」。

五分鐘後它交出一份清單，標題是「我找到的問題」，內容相當有模有樣:

1. 語氣極度重複。 21% 的 AI 文章以「I used to…」開頭(人寫的是 0%); 58% 從第一人稱軼事開始(人寫的只有 2%)。每篇都套同一個「親切部落客」人設: 先自白式開場，接著結構化建議，最後鼓勵收尾。33 篇讀起來就像同一個人寫的，不管主題是什麼
2. 公式化的結構。 幾乎都是同一個模板: 個人軼事開場 → 「這才是真正有用的做法」轉折 → 4 到 6 個 H2 段落的建議 → 樂觀的結尾。人寫的文章結構差異很大，有的先放目錄、有的先放重點摘要、有的直接進正文，AI 文章從來不會這樣
3. 語言上的破綻。 有幾個詞幾乎只出現在 AI 文字裡:「the good news」出現 9 次(人寫的 0 次)、「genuinely」「nobody」「weird」比例高得離譜、「here’s the thing」「turns out」這類緩衝語是 AI 的標記。句子也整體偏短(平均 13.4 字 vs 人寫的 17.4 字)
4. 長度分佈太窄。 AI 文章集中在 930 字左右(範圍 868 到 1032)，人寫的從 453 字到 5086 字都有。真實文章的深度差異很大，AI 的輸出「均勻得可疑」

看起來很厲害對吧。但她說真正的問題有三個:

一、agent 找得到一些問題，但所有跟品味有關的問題它一個都找不到。 凡是沒有外顯在 trace 或 prompt 裡的判斷標準，agent 永遠不會發現。

二、agent 通常找不到優先度最高的問題，還會自己編一個它認為最重要的。 「語氣極度重複」本身就很含糊，而且憑什麼它是最該修的? 也許其他更奇怪的措辭、或 AI 的幻覺，才是你真正在意的問題。

三、完全沒有重用。 每次你叫 AI 找問題，它就重讀一次資料、重新想一遍失敗模式，整個流程從零跑一遍。換一批新的 trace 再跑一次，前一輪的成果一點都沒有留下來。

投影片上第三點還有一行補充: 我們要的是把生命週期的中間產出保留下來，包括失敗模式的定義、量測出現頻率的程式碼或 LLM judge，以及持續的能見度和更新。

4. 她的做法: error-discovery skill 的五個階段

她的做法不是端到端自動化，而是守住自己的流程，只讓 AI 幫特定的環節。整套做法寫成一個開源的 skill，投影片上這張圖就是完整流程:

① 理解資料。 載入 JSONL / CSV / JSON，先看 5 到 10 筆，辨識出有哪些欄位、內容結構長什麼樣、哪些東西在筆與筆之間會變; 然後先想一下這個領域可能有哪些失敗類別。圖的下面列了它支援的內容型態: 文章、輸入輸出對、agent trace、程式碼、結構化輸出。

② 設計視覺編碼。 把資料的每一個「變化維度」對應到一個視覺屬性，每個通道只做一件事:

• 顏色 = 角色或類別(system / user / assistant / tool / thinking 各一個色)
• 間距 = 層級(同一個步驟裡的訊息靠緊，不同步驟之間拉開)
• 透明度 = 這段內容是重複的樣板還是重要的內容
• 字體 = 內容型態(散文 / 程式碼 / metadata / 思考過程)
• 容器邊框 = 把該綁在一起的東西框起來(工具呼叫和它的結果放同一格)

投影片角落標了「Uses Gestalt principles」(完形心理學原則)。skill 原始碼裡對透明度還有一條值得注意的規定:不要按角色決定要不要淡化。system message、tool result、thinking 區塊裡面都可能藏著真正的 bug，只有「每一筆都一模一樣的樣板內容」才該淡化。

③ 建 review app。 用 Python 標準函式庫寫一個 HTTP server，加上一個單檔 HTML 前端，沒有任何相依套件。前端三個畫面: 內容檢視、地圖檢視、進度檢視。後端五組端點: samples(要看哪些樣本)、annotations(人的標註)、graph(降維後的座標)、patterns(失敗模式分類法)、suggestions(agent 的建議)。前端每次標註都自動存檔，並持續輪詢有沒有新的樣本和建議。

④ 分群並挑出初始樣本。 抽特徵、分群(目標 6 到 10 群)，挑 15 到 25 筆當初始樣本。其中 60 到 70% 是各群的代表，30 到 40% 是純隨機抽的，最後去掉重複。為什麼要留隨機樣本? 因為分群不見得抓得到每一個重要的維度，隨機抽的部分就是拿來補漏的。skill 裡寫了一句定調的話:「優先追求多樣性。這一步的目標是發現失敗模式，不是估算它們有多常見。」估算頻率是 Measure 的事。

⑤ 互動式檢視迴圈。 這是整套設計最有意思的部分，值得單獨講。

這個 skill 已經開源，而且從演講當時的單一 skill 擴展成一整包 plugin。她和 Hamel 八月中又整理過一輪 (出處: X)，現在裡面有 8 個 skill(從產生合成測試資料、寫 judge prompt、校準 judge，到稽核既有的 eval pipeline)，還多了一個 start skill 負責先看你的處境，再把 agent 導到對的流程。介紹文在 Hamel 的 blog，error-discovery 的完整指令在 SKILL.md，整包在 ai-evals-course/evals-skills。

5. 關鍵機制: 用 Monitor 讓 UI 從「輸出」變成「輸入」

演講之後 Shreya 補了一段，說整場最有用的東西就是這個，小編也同意 (出處: X):

「最有用的部分是怎麼用 Claude Agent SDK 裡的 Monitor 工具(它會盯著背景任務，把每一行 stdout 當成一個事件來反應)，讓使用者在 agent 生成的 UI 裡的操作真的能回過頭去引導 agent，而不是讓那個 UI 只能唯讀。」

「這非常有用: 你只要在指示 coding agent 生成 HTML 產出物的時候，一併叫它生一段 JS，把使用者的互動編譯成日誌(例如「使用者點了 X」「使用者在這個回饋欄位打了 Y」)，然後 agent 靠著 Monitor 就會即時訂閱這些日誌，隨之調整 UI 或給出新的洞見。」

「真正新的想法是: UI 的程式碼不再只是輸出，它同時也是輸入，而且因為是 agent 生的，它是為你手上這個任務量身打造的。」

「我沒看過有人這樣用 Monitor，所以我到處都在講這件事。」

Monitor 是 Claude Code / Agent SDK 裡的工具: 你給它一個背景指令，它把每一行輸出都變成事件送給 agent，agent 就不必每隔幾秒自己去問「好了沒」。原本的典型用途是盯 CI、盯 log、盯測試進度。

而在這個 skill 裡，Monitor 盯的是人的標註檔。原始碼裡的做法:

• 把 Python server 起在背景，打開瀏覽器，跟使用者說可以開始了
• 監看 error_discovery_data/annotations.json，每 2 秒比對一次內容，看有沒有新增或刪除的標註
• 在 Claude Code 裡用 Monitor 工具加 persistent: true，每次偵測到變化就變成一個通知，agent 可以即時反應
• 其他環境就自己寫一個輪詢腳本丟到背景，輸出接到 log 檔，每次輪到自己講話時讀新的幾行
• 明確禁止用 inotifywait 或作業系統的檔案事件，理由是跨平台可靠性，單純的「讀取並比對」迴圈比較穩

反方向也一樣: agent 把整理好的分類法 POST /api/patterns、把建議 POST /api/suggestions、把補充樣本 POST /api/samples，前端一直在輪詢這些端點，新東西一到就出現在畫面上。於是人和 agent 透過幾個 JSON 檔案形成一個雙向迴圈:

小編覺得這個做法值得學的地方是: 它解決了一個很常見的問題。agent 生的網頁通常是一次性的報告，人看完了、有想法了，還是得回到終端機打字告訴 agent。這裡等於是把「人在圖形介面上的操作」變成 agent 的輸入通道，而那個介面本身還是 agent 為這份資料現寫的。要複製這個做法不需要這個 skill，只要在請 agent 產生互動式頁面時多加一句「把使用者的操作寫成一份 append-only 的日誌檔」，再用 Monitor 盯著那個檔案就行。

6. Demo 實況: 4 分 42 秒生出一個標註介面

資料是 33 篇 AI 生成的部落格文章。agent 讀完資料、分成 6 群、選出 21 篇要人看的，然後寫了 server 和單檔 HTML，全部花了 4 分 42 秒。

地圖檢視是全部 33 篇的 PCA 二維散布圖，6 個群各一個顏色並畫出範圍，被選進樣本的點比較大、已標註的另外標色。點一下就跳到那篇的內容檢視。

標註方式是就地進行: 在文章裡把那段字反白，旁邊浮出一個輸入框，打完按 Enter，那段字就被標起來，註記顯示在右邊邊欄，跟對應的位置對齊。她說這樣才能立刻把想法外化出來。她隨手標了幾條: 不喜歡每個句子都有冒號、句子要寫成完整句、不喜歡「it’s not X, it’s Y」這種措辭。

agent 在背景一直監看標註檔。標了幾筆之後它自己整理出兩個失敗模式，推到進度檢視裡:「Informal fragments and colon interjections」(不完整的口語句子與冒號插入語)和「’Not X, it’s Y’ contrastive framing」(「不是 X，而是 Y」的對比句型)，每一個底下都列出對應的原文和人寫的註記。

這段 demo 結束時她放了三個要點:

• 互動式地跟你的 AI 助手一起標註資料
• 同時追求「廣度」(涵蓋到各種失敗模式)和「深度」(每一個失敗模式都標到很多實例)
• 是你在駕駛 AI。不要讓 AI 駕駛你，做出一些你根本不知道的事

skill 原始碼裡把這兩種模式寫成一個交替節奏: 先廣度找到一個新模式，就切進深度把它挖清楚，再切回廣度。而且明訂要等人標過大約 5 筆不同的資料之後，才第一次做全庫掃描，太早的標註不足以判斷這個人到底把什麼當成失敗。

7. 她自己承認粗糙的地方

這場 demo 有意思的地方，是她講得非常誠實:

• 取樣終究是猜的。 skill 裡只叫 agent「找出能解釋這些資料如何變化的特徵」然後分群，沒有指定方法。「看樣本是有用的，但你不能假設分群或樣本挑選是完美的。」
• 第一版指定的方法後來被推翻。 她一開始要求 agent 把 trace 做 embedding 再用 k-means 分群，後來發現 embedding 不見得是 trace 的好表示法，而且有時候要分析的根本不是 trace 而是最終輸出。所以演講當時 skill 已經改成不指定方法，讓 agent 自己判斷怎麼分。有趣的是，現在公開版的 SKILL.md 又寫回了具體做法(「用 KMeans 或類似方法對正規化後的特徵分群，目標 6 到 10 群」)，確實一直在來回調整
• agent 生出來的 UI 還是很粗糙。 「就算用的是最好的 agent，UI 生成這塊還有很長的路要走。」畫面上會莫名其妙多出一堆標籤，她有時候直接叫 agent 不要生那些; 地圖檢視的圖例裡同一個顏色出現了兩次(這剛好違反她自己在第 2 階段訂的「每個通道只做一件事」)
• skill 裡寫的指令，agent 不一定照做。 她要求 agent 用 Monitor 監看標註，結果它就是沒用，她當場在台上問「你為什麼沒有照我 skill 裡寫的用 monitor 工具?」
• 「我不知道有誰做出了很好的 error discovery skill。如果你有，請寄給我。」

她說這個 skill 一直在改: 每次看到 agent 生出來的介面哪裡不順，就把改法寫回 skill 裡。

8. 最實際的收穫: 「我以為 AI 本來就該知道」

這段小編覺得是整場最有價值的部分。她做完這輪 error analysis 才發現:「當初建第一版 app 的時候，我完全沒想到這些偏好應該要寫進 system prompt。我以為 AI 自己就該知道。」

Error analysis 真正的產出不是一份 bug 清單，而是你發現自己有一整套從來沒寫下來的標準。找出來之後，Improve 那步就是回頭改 system prompt，例如加一條指令:「絕對不要寫 it’s not X, it’s Y。」這也解釋了為什麼 Analyze 這一步沒辦法整包交給 agent: 還沒寫下來的東西，它讀不到。

9. 錯誤二: 資料只看一遍

很多人標註時每一筆 trace 只看一次。她拿自己的論文《Who Validates the Validators?》來講這個問題:

三個要點是:

• 不要每一筆 trace 或輸出只看一遍
• criteria drift(評估標準漂移): 你對好壞的感覺會隨著看的資料變多而移轉，所以第二遍、第三遍看同一批資料一定會冒出新東西
• 你心裡累積的 trace 越多，分析做得越好; 不同 trace 在腦中的新組合會觸發新的失敗模式

她舉了一個具體的例子: 看到第三篇文章時才發現「matters」這個詞被過度使用，回頭一看前面每一篇都有。「一旦我跟你講了 matters 這件事，你以後就再也無視不了它。在 X 上看到文章你都會想: 喔，this break matters、first one matters。」

實作上的做法是: 每當人給了一筆新標註，agent 就拿這個標準回頭掃已經標過的和還沒標過的 trace，把符合的例子找出來給人確認。skill 裡的寫法是一個失敗模式開一個背景 subagent(不是一筆資料開一個)，多個模式可以同時跑，人這邊完全不用停下來等。

它也把兩種掃描結果的意義分開寫: 在已經看過的資料裡找到的，代表當時那個模式還沒進到你腦中，所以你漏看了(就是 criteria drift); 在還沒看過的資料裡找到的，就是新的覆蓋範圍，順便把那幾筆加進樣本。原始碼裡還有一句取捨很明確的指令:「寧可多報也不要漏報。退掉一個誤報很快，漏掉一個真的實例代價很高。」

她把這個節奏叫 outer loop(外層迴圈)和 inner loop(內層迴圈): outer loop 是把整批資料反覆看過，inner loop 是在同一筆資料上反覆檢查不同的失敗模式假設。skill 甚至規定 agent 要主動催人重看:「你在看完第 0 到 5 筆之後又找到了 3 個新的失敗模式，值得再看一遍，你很可能會發現第一次漏掉的東西。」

10. 分工的界線: 分類法由人決定

這點小編覺得是整套流程最關鍵的設計決定。她不會叫 agent 提出新的失敗模式類別，agent 只做一件事: 把人已經定義好的失敗模式套用到更多 trace 上。分類法完全由人掌握。

投影片上這是進度檢視的「agent 建議」分頁: 一整排都是同一個模式(不完整的口語句子與冒號插入語)的候選，每一列標明理由，例如「用來製造修辭效果的殘缺句」「沒有冒號但同樣口語的殘句開場」。上面有全選、接受所選、退掉所選的按鈕，讓人一次全選後取消掉少數不同意的，剩下的一鍵接受。

她試過讓 agent 提新類別:「有些我同意，有些我不同意，但我不喜歡那種一直在驗證 agent 品味的體驗。我說出我怎麼想，然後讓 agent 把它套用到很多 trace 上，這樣容易多了。」skill 原始碼把這條寫成第一原則:「人負責注意到，agent 負責整理。不要讓人去做分類。」

還有一個限制要知道: agent 找例子並不完整。它找得到一些符合某個失敗模式的實例，但找不到全部。它的角色是加速你自己的檢視，不是取代。

11. 錯誤三: 所有應用共用同一個準確度標準

這段很短但很實用。投影片的問句是「你的 evals 應該多嚴格?」，三個答案:

• 看你的應用情境而定，沒有一個通用標準
• 內部工具(例如摘要 Slack 討論串)可以容忍比較低的準確度
• 面對客戶的流程就必須把標準拉高

那標準怎麼訂? 她的做法是先想最壞情況: 把一批 trace、應用的描述、甚至整個 codebase 交給 Claude Code 或 Codex，請它站在使用者的角度想，最糟可能發生什麼事?

投影片上這張圖是一條從左到右的推導鏈。起點是「AI 寫作助手」，往下是「腦力激盪最壞情況」(旁邊註明這一步 AI 幫得上忙，而且不需要真實資料就能做)。再往下分出三個最壞情況，每個都對應到右邊一項具體的檢查:

• 捏造事實或引用來源 → 查證聲明是否屬實
• 整段逐字照抄 → 重疊比對
• 洩漏 prompt 裡的私密資訊 → 個資外洩掃描

她舉的例子: 如果使用者是記者，正在寫一篇報導，我們絕對不希望記者蒐集到的所有素材都出現在文章輸出裡。從這些最壞情況往回推，就知道該做哪些 eval 和 guardrail。

12. 那份還沒發表的 benchmark: 通用 coding agent 打得贏專門工具

最後她預告了一份還沒發表的研究(Antaripa Saha 和 Hamel Husain 主導)，拿真實資料去 benchmark 市面上的自動化 eval 工具。

受測系統分成兩組，各自量了 recall(該找到的有沒有找到)和 precision(找出來的是不是真的失敗)，專門平台額外評了 DX(開發者體驗):

分組	系統	Recall	Precision
專門的 eval 平台	Braintrust Loop	87.2%	79.1%
專門的 eval 平台	Arize AX Alyx	74.4%	91.0%
專門的 eval 平台	LangSmith	79.5%	77.5%
通用 / coding agent	ChatGPT (GPT-5.5)	87.2%	81.2%
通用 / coding agent	Codex (GPT-5.5 High)	84.6%	82.8%
通用 / coding agent	Claude Code (Opus 4.8)	79.5%	77.4%
通用 / coding agent	Factory Droid (GPT-5.5 High)	84.6%	83.3%

開發者體驗只評了專門平台這一組: Braintrust Loop 拿 Excellent、Arize 拿 Good、LangSmith 拿 Average。

她下的結論是「通用 coding agent 贏過專門的 discovery 平台」，「這讓我蠻意外的」。不過小編建議自己看表格判斷: 比較準確的說法是通用 agent 不輸專門工具，Braintrust Loop 的 recall 跟 ChatGPT 打平，Arize 的 precision 反而全場最高。真正一致的訊號是: 沒有任何一個系統能同時做到高 recall 和高 precision，最好的 recall 也只有 87%，會漏掉真的失敗模式，也會把不是問題的東西標成問題。研究還沒發表，這些數字先當初步結果看。

Hamel 在旁邊補了一個解釋，小編覺得蠻到位的: 那些 eval 工具說到底就是別人寫的一段 prompt 加上一點 harness。既然如此，你完全可以把自己的領域知識寫進 prompt 裡，再把 coding agent 針對你的資料客製化，差距就補得差不多了。

編按: 「讓 agent 去讀 agent 的 trace」這件事各家做法不同，之前整理過一篇〈如何用 AI 分析 Agent traces?〉比較過 LangChain、FutureSearch、Raindrop 和 Shreya 自己的路線，關鍵分歧在於這個質性分析要交給誰的 agent、在什麼時間點做。

13. 結語: 想辦法把自己的判斷外化出來

她最後把三個錯誤和對應的做法列成一張總結，每個錯誤都用刪除線劃掉，後面接上該怎麼做:

• 叫 AI「做 evals」 → 拆成步驟，用互動式的流程一起做
• 資料只看一遍 → 反覆迴圈，讓新的失敗模式浮出來
• 所有應用同一個準確度標準 → 用最壞情況去推

然後她用開場那張投影片收尾(也就是本文的封面圖): AI 工具不該做的是把整個 evals 生命週期自動化，該做的是幫你更快地表達和套用你的判斷。

她講得很直接:「我不知道有什麼辦法能讓 AI 用 20 個問題的方式問出你的品味。」所以只能反過來做: 去看資料，資料會觸發你對應用的疑慮，你再把那個疑慮外化給 AI。evals 這件事永遠會有人的成分在。

小編覺得這場最值得帶走的不是那個 skill(她自己都說還在改)，而是它示範的分工方式: 人負責產生判斷，agent 負責把判斷規模化，中間用 Monitor 把 agent 現寫的介面變成雙向通道。這條界線劃在哪裡，決定了你的 eval 流程是在累積你自己的判斷，還是每一輪都在重新驗證 agent 的判斷。

14. 同系列案例: 做 evals 最常浪費時間的三件事

同一個系列後來有一場 Case Study: Putting Evals Into Production，講者 Lucas 是 AI Evals 課程的學生，在巴西的教育非營利組織 Nova Escola 負責一個 AI 備課助手(幫老師生成教案，服務約 20 萬名教師)。他帶團隊做了一年的 evals 實戰，分享了三個走過的錯，跟 Shreya 那場的主張正好互相印證。

1️⃣ 先寫好評分標準，才去看資料

他們的教育團隊原本就有一套「好教案長什麼樣」的評分表(rubric)，團隊直接拿來當 eval 的標準，開始大量標註資料。問題是: 表上列的多數標準在實際產出中根本不會以失敗形式出現，他們花了大量時間標註不需要的資料。

後來上完課才調整做法: 先做 error analysis 找出真正存在且頻繁出現的失敗模式，只針對那些做 eval。Hamel 的總結很直接:「不要把你想得到的東西全部做 eval。先做 error analysis 來排優先順序，因為 eval 不是免費的。」

2️⃣ 為一個改 prompt 就能修好的問題做 eval

他們發現 AI 常常在教案裡生出兩個以上的學習目標，但規定只能有一個。團隊認真地為這個問題建了一整套 eval: 標註資料、寫 judge。結果改了一行 prompt 就修好了，再也沒復發，那套 eval 完全白做。

Hamel 補了一個判斷標準: 如果你看到一個問題而且知道怎麼修，直接修就好，不需要為每件事都做 eval。真正該做 eval 的是那種一直出現、試了好幾次還修不好的問題，因為那個 eval 才會持續提供價值。

3️⃣ 兩個標註者的共識度比丟銅板還低

課程建議由一個最懂產品的人(Hamel 叫這個角色「benevolent dictator」)獨自標註，但 Lucas 的團隊安排了兩個人。結果量了兩人的共識度，在好幾個標準上，意見一致率比丟銅板還低。Lucas 原話:「如果我丟銅板，銅板的一致率都比他們兩個高。」

根本原因是評分標準寫得不夠明確，兩個人看的是同一條標準，卻在評不同的東西。他們回頭找教育專家重寫標準、重新標註，每一輪要花一到兩個月。Hamel 也說，兩個人標註的摩擦成本非常高，值得花力氣找到那個真正懂產品的人來做。

🔹 他拆出的三道障礙: 技術、方法論、判斷力

除了三個具體的錯，Lucas 也把「做不成 evals」這件事拆成三層障礙(原文用 “three main barriers”):

技術: 光是把多輪對話、工具呼叫、RAG 檢索內容串成完整的 trace 就很痛苦，不只工程師，連他自己也不熟。解法是先上 LangFuse 做觀測，把系統內部發生的事全部記下來，再接上 Claude(透過 MCP)讓非工程師也能用自然語言查 trace 和資料集。

方法論: 錯誤分析、開放編碼(axial coding)、judge 校準、資料切分(train/dev split)，每一步都有坑。Lucas 提到光是「資料要切成幾比幾」這種細節就很容易搞錯，而課程的 eval skills 把這些方法論包進操作指引裡，團隊照著做就不容易出錯。不過他也說，他們不是直接把 skill 丟給團隊就好，而是先用課程教材帶團隊走過一遍八堂課的內容，讓他們理解 skill 背後的邏輯之後才開始用。

判斷力: 這才是真正值錢的部分。一份教案到底夠不夠好、能不能啟發學生思考、課綱對應是否正確，這需要教學專業判斷，不是工具能取代的。Lucas 原話:「沒有任何工具可以把這件事抽象掉，這就是我和我的團隊該做的事。」

前兩層被 LangFuse + Claude + skills 處理掉之後，團隊終於有餘裕把精力放在第三層。這跟 Shreya 講的 Analyze/Measure/Improve 框架是同一個結論: 工具能幫的是 Measure 和 Improve，但 Analyze 那一步的判斷力只能靠人自己。

他們現在有 4 個校準過的 judge 跑在正式環境裡，每天抽樣約 2% 的產出做批次評估(用 batch mode 省成本)，同時也當 PR 的 CI 關卡，每次改版都跑一次確認沒有退步。一年下來，產品跟最初完全不同，但他說不能簡單比較「變好了多少」，因為隨著產品改善，困擾他們的失敗模式也一直在變。

小編覺得這場跟 Shreya 那場放在一起看特別有意思。Shreya 講的是「為什麼不能全自動」的理論框架，Lucas 就是實戰走過那些彎路的案例。三個錯加在一起指向同一件事: eval 的成本很高，在投入之前要先確認這個問題值得用 eval 來處理，而 error analysis 就是那個篩選的步驟。