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

🧑‍🏫 這段示範怎麼替一個會自動做 PowerPoint 的 agent（能自己動手完成任務的 AI 助手）設計 eval，再依照評分結果反覆修改 agent 的指令和評分方式。值得看的地方有兩個：它把「好不好看」這種主觀品味拆成能量化、能修改的項目；也誠實示範評分工具本身同樣會出錯、需要修正。

• 13:05 repo 導覽：resources 是主要工作目錄，agent.yaml 用來定義 agent
  ↳ repo 是放整個專案程式碼的資料夾。講者先帶大家看結構：主要在 resources 資料夾裡工作，agent.yaml 是寫這個 agent 設定的檔案。
• 13:36 使用 managed agent，做法和午餐前那場 session 相同
  ↳ 這裡用 managed agent（交給平台幫你執行的 agent），設定方式和午餐前那場一樣，所以講者沒有重講細節。
• 13:36 初始 system prompt：你是投影片生成 agent，使用者給主題時在指定位置建立 PowerPoint 檔；並告訴它有 shell，已預裝 Python PPTX
  ↳ system prompt 是給 agent 的角色與規則。初版很簡單，只要它做投影片、存到指定位置，並告訴它有 shell（能下指令的命令列）和預裝的 Python PPTX（產生 PowerPoint 的工具）。
• 13:36 另外定義了 environment，裝好完成任務所需的幾個套件
  ↳ environment 是 agent 工作的執行環境。事先把需要的套件裝好，agent 開工就能直接用，不必自己摸索安裝。
• 14:06 講者問觀眾：做投影片生成 agent 時，好的 eval 是什麼？要量什麼、想從 eval 得到什麼資訊？
  ↳ eval 是衡量 agent 表現的測試。講者先問大家：投影片 agent 到底該量什麼？重點是 eval 要能告訴你下一步該改哪裡。
• 14:38 觀眾提出「每張投影片的字數」：可以量化，能用 deterministic 的 code grader 直接計算
  ↳ 有觀眾提議算每張的字數。能直接用數字表示的項目適合 code grader，也就是用程式固定計算。同一份投影片每次算出來都一樣，這叫 deterministic（確定性）。
• 15:08 文字重疊或溢出版面這類問題很難用程式碼判斷，可改用 model grader
  ↳ 文字疊在一起、超出版面這類問題很難寫成規則判斷，就改用 model grader：讓 AI 模型看過投影片後打分數，類似請人幫忙審稿。
• 15:08 repo 已預先定義 grader，分成 code 和 judge 兩個目錄；code grader 屬於 deterministic
  ↳ repo 裡已經寫好評分工具，分成 code 和 judge 兩個資料夾。judge 就是 model grader 的另一個叫法；code 那邊全是用固定規則計算。
• 15:08 emoji count grader 例子：計算整份投影片裡出現幾個 emoji，因為觀察到 emoji 很常出現
  ↳ 舉例來說，emoji 計數器會算整份投影片有幾個 emoji。會設這一項，是因為實際看過產出，發現 AI 很愛放 emoji。
• 15:38 agent 跑一次要花不少時間，所以事先跑好；初版 agent 產出 5 張投影片，符合 prompt 要求，但品質不算好
  ↳ agent 產一份投影片要花一段時間，所以講者事先跑好。初版做出 5 張，字面上符合要求，但成品看起來並不好。
• 16:39 觀眾指出問題：一直用 teal 色；講者也指出文字重疊、奇怪的配色等狀況
  ↳ 觀眾一眼看出整份都用 teal（藍綠色）。講者補充還有文字重疊、配色奇怪。這些讓人覺得不對勁的地方，就是設計 eval 的素材。
• 17:09 做法是先看產出結果，再決定要針對哪些問題定義 grader
  ↳ 順序很關鍵：評分項目不是憑空想出來的，而是先看實際產出哪裡有問題，再針對這些問題設計 grader。
• 17:42 code grader 包括：emoji 數量、cluttered slides（算形狀數量）、投影片張數（都要求 5 張）、含圖片的張數、小字體、文字過多
  ↳ code grader 有六項：emoji 數、形狀數量（太多代表雜亂）、張數是否為 5、含圖片的張數、小字體張數、字太多的張數。這些都能用程式直接數。
• 17:42 講者說這些 grader 的選擇有點隨意，只是覺得能代表一份投影片的樣貌
  ↳ 講者坦白說，這六項選得有點隨意，只是覺得大致能反映一份投影片的樣貌，並不是標準答案。
• 18:13 什麼是好的 grader 要看 use case；拿不到有用資訊的 grader 就不該放進 eval
  ↳ 好的 grader 沒有通用清單，要看你拿 agent 做什麼。如果某個分數不管高低都不會讓你改任何東西，它就沒用，不該放進 eval。
• 18:13 每個測試情境都要說得出：想得到什麼資訊、測的是系統哪個部分、效能下降時要怎麼處理
  ↳ 每個測試都要答得出三件事：想知道什麼、測的是系統哪個部分、分數下降時要怎麼修。答不出來，就代表這項測試還沒想清楚。
• 18:44 judge grader 包括 color judge（評色彩對比，給 0 到 5 分），以及 image、layout、text
  ↳ judge grader 有四個：color judge 看色彩對比，給 0 到 5 分；另外還有評圖片、版面、文字的評分器。
• 19:14 judge prompt 會要求依各項標準評分，例如標題要簡單清楚、內文不要太多字、字體大小／樣式／顏色要一致好讀，每項都附上評估重點
  ↳ judge 的指令會列出具體標準，例如標題簡單清楚、內文不要太多字、字體大小樣式顏色一致好讀，並寫明每項要看什麼，讓 AI 評分有依據。
• 19:44 repo 附有腳本自動幫投影片評分，列出張數、含圖、文字過多、雜亂、小字體等 code 指標，以及各 judge 的 0–5 分
  ↳ repo 附了一支腳本，能一次跑完所有評分，列出張數、含圖、字太多、雜亂、小字體等計數，以及各 judge 的 0 到 5 分。
• 20:14 judge 分數落在 2.8 到 4，以這份投影片的品質來看偏高，代表需要做 calibration
  ↳ calibration 是校準評分標準。judge 給了 2.8 到 4 分，但投影片明明不好，代表 AI 評審太寬鬆，要調整標準，讓分數對得上真實品質。
• 20:45 eval 設好一次不代表就是 ground truth；它是會演進的 living artifact，不能做完就丟著、拿來做所有決策
  ↳ ground truth 指可以當作標準答案的依據。eval 設好不代表它就是標準答案；它是 living artifact（會持續演進的東西），不能做完就擺著、事事都照它決定。
• 21:16 eval saturation：因為各種原因，eval 不再提供可以據以行動的有用資訊
  ↳ eval saturation（eval 飽和）是指 eval 因為各種原因，不再提供能讓你採取行動的資訊。遇到這種情況，就該調整 eval 了。
• 21:46 改進第一步：更新 system prompt，加入字型規格：slide title、section header、body、caption 各自的字級
  ↳ 開始改進。第一步是改 system prompt，直接寫明字級：投影片標題、段落標題、內文、圖說各用多大的字，不讓 agent 自己猜。
• 22:16 加入版面與密度要求：內文要精簡、留白、段落靠左對齊
  ↳ 接著加上版面規則：內文要精簡、要留白、段落靠左對齊。等於把基本的排版原則寫成明確的指示。
• 22:16 講者看到明顯是 AI 寫的內容會懷疑能不能信任，所以要求避開 AI 生成的痕跡
  ↳ 講者說，看到一眼就知道是 AI 做的內容，他會懷疑能不能信任。所以要求 agent 避開 AI generated tells，也就是讓人看出是 AI 做的特徵。
• 22:47 具體禁止：標題不要用細的裝飾線，不要到處放 emoji 當裝飾圖示
  ↳ 具體點名兩種：標題旁的細裝飾線，以及到處把 emoji 當裝飾圖示。這兩種都是 AI 做的投影片常見的痕跡。
• 22:47 這些修改都來自 eval 結果：初版 emoji count 4、small font slides 4、cluttered slides 2，還有文字過多的投影片
  ↳ 這些修改都有根據：初版評分顯示有 4 個 emoji、4 張小字體、2 張雜亂，還有字太多的頁面，才針對這些問題改 prompt。
• 23:17 新版 agent 的投影片比較清爽：沒有重疊、沒有錢字號，配色和整份的一致性也更好，但有一張的字仍偏小
  ↳ 新版清爽很多：沒有文字重疊、沒有奇怪的錢字號，配色和整份的一致性也更好。不過仍有一張的字偏小，還沒完全修好。
• 23:47 流程是找出 failure modes，據此修改 system prompt 再重跑，形成「找問題→迭代→重跑→改進」的循環
  ↳ failure modes 是 agent 出錯的各種型態。整個流程就是：找出問題、改 system prompt、重跑、看結果，一輪一輪往上改進。
• 24:17 新版評分中 emoji count 反而變成 20，但講者在投影片上沒看到 emoji，懷疑是出錯；小字體問題還在，雜亂有改善
  ↳ 怪的是，新版的 emoji 數反而變成 20，但投影片上看不到任何 emoji，講者懷疑是計數器本身出錯。小字體問題還在，雜亂則有改善。
• 24:49 講者覺得那些投影片的文字量可以接受，但 grader 判為文字過多，這說明 human review 的價值：grader 定義不夠好
  ↳ grader 判定字太多，講者自己看卻覺得還好。這就是 human review（由人親自檢查）的價值：能發現問題其實出在評分標準定義得不好。
• 25:20 發現 grader 有問題時，要回頭修改 grader，讓它更貼近真正想量的東西
  ↳ 所以發現 grader 不準時，要回頭修 grader，讓它量到你真正在意的東西，而不是只顧著改 agent 去配合錯誤的分數。
• 25:20 agent 該怎麼表現、judge 該怎麼評分，這類 calibration 很難拿捏，值得投入足夠時間
  ↳ agent 該做到什麼程度、judge 該怎麼給分，這種校準很難拿捏，講者認為值得花足夠時間慢慢調整。
• 25:51 新需求：每張投影片都要有圖表。更新 system prompt，要求每張至少插入一個生成的 diagram 或 chart（本段字幕在此中斷）
  ↳ 新需求：每張投影片都要有圖表。於是再改 system prompt，要求每張至少放一個自動產生的 diagram（示意圖）或 chart（統計圖表）。本段在這裡中斷。

依 system prompt 修改後重跑，新版 agent 的評分結果中 emoji count 是多少？