用 Evals 衡量品味：逐步改進（hill-climbing）一個投影片生成 agent（第 1/3 段）

🧑‍🏫 這支 Claude 官方影片的第一段在講 Evals：替 AI 系統量身設計的一套考題，以及為什麼做 agent 的人都該自己建一套。沒有 Evals，你改指示、換模型都只能靠感覺；有了它，才知道到底變好還是變差。後半段介紹三種評分方式各自的長處和限制，幫你判斷什麼情況該用哪一種。

• 00:51 這堂課的目標：讓大家願意動手建 Evals，知道該怎麼思考、哪些 Evals 有用，以及怎麼用 Evals 做出更好的 agent
  ↳ 這堂課想讓你真的動手做 Evals（替 AI 設計的考題），學會判斷哪些題目有用，並靠考試結果把 agent（會自己分步驟完成任務的 AI 助手）改得更好。
• 01:22 課程會實際做一個投影片生成 agent，找出該量測什麼，再根據 Evals 的回饋改進 agent
  ↳ 課程用一個自動做投影片的 agent 當實例：先想清楚要檢查哪些地方，再根據 Evals 給的回饋去修 agent，一輪一輪往上改。
• 01:22 Evals 的定義：有系統的測試，用來量測 AI 系統在特定領域或使用情境上的表現
  ↳ Evals 不是隨手試幾次，而是有計畫、可以重複跑的測試。它只考你實際要用的領域或情境，不是泛泛地考 AI 聰不聰明。
• 01:53 Evals 會告訴你結果品質如何、哪裡做得好、哪裡不好、可以怎麼改進
  ↳ 好的 Evals 不只給一個分數，還會指出哪些部分做得好、哪些卡住，讓你知道下一步該往哪裡改。
• 01:53 Evals 由 task 組成：task 定義情境，再透過評分邏輯（grading logic）寫進你的預期
  ↳ Evals 由一題題 task（測試題目）組成。每題設定一個情境，再用 grading logic（評分規則，把「我期待的樣子」寫成能判對錯的條件）來打分。
• 01:53 如果輸出一定要符合某種品質或必須包含某些東西，可以寫成 Evals；Evals 沒過，就代表 agent 沒照預期運作
  ↳ 只要你對輸出有硬性要求，例如投影片一定要有標題頁，就能寫成一題。這題沒過，就表示 agent 沒照你的期待做事。
• 02:25 Evals 把「好像可以用」變成「確定可以用」；「今天感覺比較差」這種 vibes 很難拿來行動
  ↳ 「好像可以用」只是印象，Evals 讓你拿得出證據說「確定可以用」。「今天感覺變差」這種 vibes（主觀感覺）很難讓你知道要改哪裡。
• 02:55 講者認為 vibes 可以大致了解使用者的感受，但不夠 actionable，而 Evals 要給你能採取行動的資訊
  ↳ vibes 不是沒用，它能反映使用者大概的感受。但它不夠 actionable（能直接指出下一步該做什麼），Evals 的價值就在給出能動手改的資訊。
• 02:55 每次發布模型都會附上 benchmark 成績單，列出各項 Evals 的成績，並和舊版及競爭對手的模型比較
  ↳ AI 公司發布新模型時，會附一張 benchmark（業界共用的標準考卷）成績單，列出各項分數，並跟自家舊版和競爭對手的模型比較。
• 03:25 常見 benchmark：SweetBench（量測 agentic coding 能力）、Terminal Bench；工具使用與 agent 類有 Tower Bench、OSWorld
  ↳ 常見考卷有 SweetBench，考 agentic coding（AI 自己寫程式、改程式的能力），還有 Terminal Bench。考工具使用和 agent 能力的有 Tower Bench、OSWorld。
• 03:56 推理與知識類的 benchmark 例如 Arc-AGI
  ↳ 也有考推理和知識的 benchmark，例如 Arc-AGI。這些名字不用硬記，知道各家會拿同一批考卷來比分數就好。
• 03:56 這些通用 benchmark 只能大致看出模型的能力和進步幅度，對你正在做的 agentic 系統通常參考價值不大
  ↳ 通用考卷只看得出模型的整體實力和進步幅度。你的 agent 要做的是自己特定的工作，通用分數高，不代表在你這裡就好用。
• 04:26 通用 benchmark 不一定適用你的使用情境，所以要自己建 Evals、比較不同模型、評測自己的 agent，確保用對模型
  ↳ 就像學測高分，不保證適合某個特定職缺。所以要自己出題，用自己的 Evals 比較不同模型、測自己的 agent，才知道哪個模型真的適合。
• 04:56 沒有 Evals 時：客戶只回報「換新模型後怪怪的」，很難處理，只能要 log 手動 debug，等於在盲飛
  ↳ 沒有 Evals 時，客戶只說「換新模型後怪怪的」，你不知道怪在哪，只能跟對方要 log（系統運作紀錄）一筆筆手動 debug（找錯），等於在盲飛。
• 05:27 沒有 Evals 會一直處於被動循環，只能在 production 才發現問題
  ↳ 沒有 Evals，你只能被動等問題冒出來再處理，而且常常要到 production（正式上線、真的有人在用的環境）才發現。
• 05:27 修好一個問題可能製造更多問題，例如改一下 prompt，就讓其他沒考慮到的 task 能力下降
  ↳ 修一個問題可能弄壞別的地方。例如為了某個狀況改了 prompt（給 AI 的指示文字），結果其他沒想到的任務反而變差。
• 05:57 沒有 Evals 也很難分辨真正的回饋和雜訊，因為人對結果的感受本身會有偏誤
  ↳ 人的感受會被心情、期待、印象特別深的個案影響，所以只靠感覺，很難分辨哪些是真的問題、哪些只是偶然的雜訊。
• 05:57 講者認為最重要的一點：沒有 Evals 就沒辦法驗證改動究竟是進步還是退步
  ↳ 講者最看重這點：沒有 Evals，你改完根本無從判斷是變好，還是出現 regression（改了之後品質反而退步）。
• 06:28 有 Evals 的好處之一是清楚：你必須先定義什麼叫成功；連自己都說不出來，就沒辦法確認 agent 表現是否正確
  ↳ 做 Evals 會先逼你回答「怎樣算成功」。如果你自己都講不出好投影片長什麼樣，就沒辦法判斷 agent 做得對不對。
• 06:58 建立 Evals 會逼你把對 agent 的期待定義清楚、正式寫下來
  ↳ 把期待寫成一題題 Evals，腦中模糊的「要好看、要清楚」，就得變成明確、寫下來、別人也看得懂的標準。
• 06:58 有了 Evals 可以反覆迭代，找出最佳的 agent 設定（agent config）
  ↳ 有了固定題目，你可以改設定再重考，比較哪種 agent config（agent 的整套設定，例如用哪個模型、指示怎麼寫）表現最好。
• 06:58 可以更快導入新模型：清楚知道新模型哪裡比較好、哪裡沒有，藉此判斷要不要遷移；新模型推出速度很快，這點特別重要
  ↳ 新模型推出得很快。有自己的 Evals，新模型一出來跑一次，就知道它在你的工作上哪裡變強、哪裡沒有，再決定要不要換。
• 07:29 可以在上線前就讓問題浮現；你信任、能提供大量洞見的案例，最能發揮 Evals 的價值
  ↳ Evals 讓問題在上線前就被抓出來。題目越是你信任、越能反映真實狀況的案例，跑出來的結果越有參考價值。
• 07:59 prompt engineering 的流程：先寫 test case（也就是 Evals）→寫 prompt→用 task 測試→修改 prompt→重跑，直到有信心後再推出
  ↳ prompt engineering（反覆調整給 AI 的指示）的做法：先寫 test case（測試題，也就是 Evals），再寫 prompt、跑題、修 prompt、重跑，有把握才上線。
• 08:30 加入 agent 之後，系統有 tool calls、skills、各種 context 最佳化手段，變得更複雜，能調整的地方也更多
  ↳ 換成 agent 會更複雜：它會做 tool calls（呼叫搜尋、存檔等外部工具），用 skills（預先準備的做事模組），還有各種整理 context（餵給 AI 的背景資料）的手法。
• 08:30 能調的東西越多，越需要 Evals 具體找出哪些東西可以改、哪些改動對系統有正面影響；流程本身和原本相同
  ↳ 可以調的東西越多，越難憑感覺知道哪個改動真的有幫助，就更需要 Evals 一項項驗證。流程不變，一樣是出題、修改、重跑。
• 09:01 Grader 是用來評判輸出的方法，建立 Evals 時主要有幾種 grader
  ↳ grader（評分者）就是判斷輸出好壞的機制。做 Evals 時主要有三種 grader，接下來一一介紹。
• 09:31 第一種：code-based grader，類似軟體工程的 unit test，例如字串比對、regex、fuzzy match，屬於嚴格分析
  ↳ 第一種 code-based grader 用程式自動檢查，像 unit test（軟體的自動小測驗），例如比對字串、用 regex（文字格式規則）或 fuzzy match（容許小差異的比對）。
• 09:31 code-based grader 的優點是快、便宜、結果固定；缺點是脆弱（brittle）而且缺乏細膩度
  ↳ 優點是快、便宜、結果固定（deterministic，同樣輸入每次都得到同樣結果）；缺點是 brittle（脆弱），規則寫死，稍有不同就判錯，也看不出細膩的好壞。
• 10:01 例子：投影片 agent 最後有沒有產出 slide deck，可以用確定性檢查；但投影片品質很細膩，很難用確定性檢查寫出來
  ↳ 例如 agent 最後有沒有產出 slide deck（整份投影片檔），用程式一查就知道。但版面好不好看、內容通不通順，很難寫成固定規則。
• 10:32 第二種：model-based grader，用 rubric 推理，例如問「這張投影片品質高嗎？」「這段文字連貫嗎？」
  ↳ 第二種 model-based grader 是請另一個 AI 當評審，照 rubric（評分題目或標準）來判斷，例如「這張投影片品質高嗎？」「這段文字連貫嗎？」
• 11:03 pairwise comparison：把兩個輸出給模型，問它偏好哪一個、為什麼；講者認為這方法被低估，特別適合很難定義「哪個比較好」的情況
  ↳ pairwise comparison（兩兩比較）是給 AI 評審兩份結果，問它偏好哪份、為什麼。講者認為這招被低估，特別適合講不出絕對標準、但放在一起比就看得出高下的情況。
• 11:03 multi-judge consensus：例如三位評審各自獨立打分，以多數決為準
  ↳ multi-judge consensus（多評審共識）是讓幾個 AI 評審各自打分，例如三個，最後以多數意見為準。
• 11:33 LLM 的結果不固定，同一個 grader 跑 100 次，評價可能時好時壞；多評審共識是投入更多運算，換取更穩定的判斷
  ↳ LLM（大型語言模型，像 Claude 這類 AI）每次回答可能不同，同一個評審跑 100 次，會時鬆時嚴。多評審就是多花運算，換更穩定的判斷。
• 12:03 model-based grader 的優點是彈性大、可擴展、細膩；缺點是結果不固定、成本較高，而且需要校準，講者說校準一點也不容易
  ↳ AI 評審彈性大、能大量跑、看得出細節；缺點是結果會浮動、比較貴，還需要 calibration（校準，確認它的評分跟你的標準一致），講者說校準一點也不簡單。
• 12:03 第三種：human grader 最貴，開發 agentic 系統時大概是用最少的一種
  ↳ 第三種 human grader 是真人評分。它最貴，所以在開發 agent 的過程中，通常是用得最少的一種。
• 12:33 human grader 由領域專家（subject matter expert）完整審查系統，又貴又慢，但品質最高、最細膩，適合 A/B testing 和抽查（spot checking）
  ↳ 由 subject matter expert（該領域的專家）完整檢查，又貴又慢，但最準、最細膩。適合 A/B testing（比較兩個版本哪個好）和 spot checking（隨機抽幾份檢查）。
• 12:33 課程有準備 repo 讓大家事先 clone；因為人數太多，講者會改成多由自己示範
  ↳ 講者準備了 repo（放程式碼的專案）讓大家事先 clone（下載一份到自己電腦），但現場人太多，改成主要由他自己示範。

根據講者的說法，code-based grader（程式型評分器）的主要缺點是什麼？