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

🧑‍🏫 這是 Anthropic 官方影片的最後一段。講者用 evals（一套檢查 AI 產出好不好、確認改動有沒有用的測試方法）示範怎麼一步步把自動做投影片的 AI 調好。除了加規則、換模型，這段也教你怎麼設計讓 AI 打分的評審，避免分數很好看，其實量錯了東西。

• 26:10 新增規則：投影片至少要有一張產生出來的圖表，而且要以真正的圖片插入；接著更新 system prompt 或 agent 其他可調整的部分，再跑一次看結果
  ↳ 新規則是：至少要有一張真正以圖片插入的圖表。訂好後，去改 system prompt（事先交代 AI 怎麼做事的說明書）或 agent（會自己動手完成任務的 AI）的其他設定，再跑一次，看有沒有變好。
• 26:10 講者個人不喜歡開場投影片放圖片，但這是先前定義的要求，所以就接受
  ↳ 講者自己覺得開場頁放圖不好看，但這是之前定好的規則，就照規則走。意思是評分要依事先講好的標準，不能看個人喜好臨時改。
• 26:40 範例圖表比較「沒談薪」和「主動談薪」，顯示時間越久差距越大；有了具體數據，整份簡報馬上好很多，不再空泛帶過
  ↳ 範例圖表比較「沒談薪」和「有談薪」的人，時間越長，收入差距越大。有真實數字撐著，簡報就從講空話變成有說服力，這正是加圖表規則想要的效果。
• 26:40 還是有幾張投影片不理想，例如圖片看起來有點被拉伸（也可能只是截圖的問題）
  ↳ 改完還是有幾頁不理想，例如圖片看起來被拉長或壓扁，講者也說可能只是截圖造成的。改一輪不會全部變好，要繼續檢查。
• 27:12 看 score.json：沒有 emoji、投影片不擁擠，但文字還是偏多、字體偏小；講者認為有圖片的情況下這些可以接受
  ↳ score.json 是記錄每項檢查結果的檔案。這次的結果是：沒有 emoji、版面不擁擠，但字還是偏多、字體偏小。講者判斷有圖片撐場，這些可以先放過。
• 27:42 有了圖片後可以看 image judge 的分數，結果是 3.8/5，但它只給一個數字，看不出是什麼意思、要怎麼改進
  ↳ image judge 是 judge grader（讓 AI 當評審替產出打分）的一種，專門評圖片，這次給 3.8 分（滿分 5）。問題是它只丟一個數字，看不出扣分在哪，也就不知道要改什麼。
• 27:42 有一招在每種使用情境都很有效：加上 QA loop
  ↳ 講者說有一招不管什麼用途都很有效，就是 QA loop：一個 AI 負責做，另一個 AI 負責挑錯，來回修改，直到雙方都滿意。
• 28:12 以寫程式為例：一個 agent 負責寫程式，第二個 agent 專門挑毛病（有 bug、不符合規範等），再把回饋交回給負責產出的 agent 修改
  ↳ 拿寫程式舉例：A 負責寫程式，B 專門找 bug（程式錯誤）或不合規範的地方，再把意見交回給 A 修。就像寫報告時有人幫你校稿。
• 28:42 這個循環會一直重複，直到兩邊都認為「可以了，能出貨」為止
  ↳ 這個來回會一直跑，直到做的一方和挑錯的一方都同意「可以交出去了」才停，不是只檢查一次就收工。
• 28:42 prompt 寫法：要求 QA loop，並「假設一定有問題，你的工作就是找出來」，把 QA 當成抓 bug，而不是確認步驟
  ↳ prompt（給 AI 的指令文字）要寫明：要跑 QA loop，而且「先假設一定有錯，你的工作就是找出來」。這樣檢查就是在抓錯，不是走過場打勾。
• 29:12 重點在於刻意要求 agent 用對抗的角度檢查：直接說「一定有問題，去找出來」，而不是「可能有問題」
  ↳ 關鍵是叫 AI 用 adversarially（對抗）的角度檢查。你說「可能有問題」，它常看一看就說沒事；說「一定有問題」，它才會認真挑毛病。
• 29:12 具體流程：寫完簡報後轉成圖片、自己逐張檢查、修正、重新產出、再檢查，至少完成一輪「修正並驗證」才能停
  ↳ 實際流程是：做完簡報→轉成圖片→AI 自己一張張看→修正→重新產出→再看一次。規定至少要完整跑過一輪「改完再確認」才能結束。
• 29:42 這其實就是前面人工做的事：看投影片、找問題、更新 grader 和 system prompt，再跑一次
  ↳ 這其實就是講者前面手動在做的事：看投影片、找毛病、改評分規則和 system prompt、再跑一次。QA loop 等於把這段人工流程交給 AI 自己做。
• 29:42 加上 QA loop 之後：圖片變大，遠看也更容易讀，而且有標出處；結構更清楚，也出現「你的價值 vs 團隊平均」這類有意思的圖表
  ↳ 加了 QA loop 後，圖片變大，遠看也讀得清楚，還標了資料來源。整份架構更清楚，也出現「你的價值 vs 團隊平均」這種有意思的圖表。
• 30:12 還是有缺點：部分投影片仍有問題、出現奇怪的勾勾符號，而且圖片佔掉的空間影響了版面
  ↳ 缺點還在：有些頁面仍有問題，還冒出莫名其妙的勾勾符號。圖片佔掉太多空間，把版面擠亂了。
• 30:44 看分數：所有 judge 都比之前高，落在 4.2 到 4.4，方向正確，可以繼續這樣迭代
  ↳ 所有評審的分數都比之前高，落在 4.2～4.4。方向是對的，可以照這個方式一輪一輪繼續改。
• 31:14 另一個做法是直接換更聰明的模型，因為模型越來越強，可以期待它自己判斷好的投影片應該長什麼樣子
  ↳ 另一條路是直接換更聰明的模型。模型越來越強，也許不用把規則講得那麼細，它自己就知道好的投影片長什麼樣子。
• 32:14 只用基本 prompt，Opus 的結果就明顯比 Sonnet 好、結構更清楚，不過還是有問題要修
  ↳ 只用最陽春的 prompt，Opus 做出來的就明顯比 Sonnet 好，架構也更清楚。但還不完美，仍有地方要修。
• 32:44 Opus 完全不用 emoji，也比較少字體太小的投影片，看起來本來就懂簡報該有的樣子和讀者的期待
  ↳ Opus 完全沒用 emoji，字太小的頁面也比較少，好像本來就知道簡報該長怎樣、看的人期待什麼。前面辛苦加的規則，有些它天生就會。
• 33:16 judge 分數：4.4、圖片 5 分（但簡報裡根本沒有圖片）、layout judge 4.2、color judge 4.8、title body coherence 4.4
  ↳ 各評審分數：整體 4.4、layout judge（評版面）4.2、color judge（評配色）4.8、title body coherence（標題和內文是否對得上）4.4。圖片給滿分 5，但簡報裡根本沒有圖。
• 33:16 分數都非常高，反而表示我們可能量錯了東西；這種 judge grader 出現這個狀況並不意外
  ↳ 分數高到不合理，反而是警訊，代表評審可能量錯了東西。講者說用 AI 當評審，出現這種狀況很常見，不能看到高分就開心。
• 33:46 code grader 很直接，例如 emoji 數量就是數一數；judge 的寫法才有問題，只叫它給 0–5 分，卻沒有任何參考基準
  ↳ code grader 是用程式直接檢查，像 emoji 數一數就知道，不會錯。問題出在 judge：只叫它打 0–5 分，卻沒告訴它幾分代表什麼。
• 34:16 judge 不知道好和壞分別長什麼樣子，所以要判斷哪些是模型本來就懂的、哪些需要多給資訊
  ↳ 評審不知道好和壞各長什麼樣子，打分就沒有依據。所以你要分清楚：哪些標準模型本來就懂，哪些需要你寫清楚告訴它。
• 34:16 改善建議：給範例，例如 0 分的爛簡報有哪些明顯特徵，再逐步描述不同分數區間
  ↳ 改法是給範例：先描述 0 分的爛簡報有哪些明顯特徵，再逐段說明每個分數區間長怎樣。就像老師改作文前，先把評分標準發下去。
• 35:17 就算這樣，LLM 輸出的數字還是很難解讀（例如沒有圖片卻給 5 分），所以要一直要求 judge 說明理由
  ↳ 就算給了標準，AI 打的分數還是可能很怪（像沒有圖卻給 5 分），所以一定要它每次都寫出理由，你才看得出它是怎麼判斷的。
• 35:47 要注意順序：如果先給分數再給理由，LLM 是 autoregressive，會想盡辦法替已經給的分數辯護，就算其實應該只有 1 分
  ↳ LLM（大型語言模型）是 autoregressive：一個字接一個字寫，會順著前面寫過的內容走。先寫分數，它後面就會硬找理由撐那個分數，就算其實只該給 1 分。
• 36:18 正確做法是反過來：先列出理由、優缺點、應該給高分和低分的原因，最後根據這些理由再決定分數
  ↳ 所以順序要反過來：先列出理由、優缺點、該給高分和該給低分的原因，最後才依這些決定分數。先想清楚再打分，分數才可信。
• 36:18 驗證也可以用多個 agent：一個負責找出所有問題，另一個負責反駁這些問題
  ↳ 驗證也可以分給多個 agent：一個負責把問題全部找出來，另一個負責反駁，留下真正站得住腳的問題，避免亂挑錯。
• 36:49 法律文件例子：要模型上網蒐集資料，摘要某個案件的判決和對其他案件的影響；agent 很容易直接跳到結論
  ↳ 法律例子：叫 AI 上網查資料，摘要某個案件的判決，以及它對其他案件的影響。AI 很容易沒把過程查清楚，就直接跳到結論。
• 37:19 grader 可能會指出內容不清楚、可能不正確、忽略了事實；但 grader 本身也可能產生幻覺，尤其是細微的情況，所以可以用多個 grader 看哪些問題反覆出現
  ↳ 評審會指出內容不清、可能有錯、漏掉事實，但評審自己也會 hallucinate（講出不存在的問題），越細微越容易發生。所以要找多個評審，看哪些問題反覆出現。
• 37:51 目標是讓 judge 產出一致又能拿來行動的結果；這場只是 evals 的入門，講者認為 45 分鐘講 evals 太短
  ↳ 目標是讓評審每次的結果都一致，而且看了就知道怎麼改。講者也說這場只是入門，45 分鐘講 evals 其實太短。
• 37:51 benchmarks 說到底也是 evals；各家模型都重視 benchmark，是因為要找出模型擅長和不擅長的地方，讓下一代更好
  ↳ benchmarks（大家常拿來比較 AI 模型的標準測驗）本質上也是 evals。各家重視它，是為了找出模型強在哪、弱在哪，讓下一代更好。
• 38:22 開發 AI agent 應用也是同樣道理：找出有效和無效的做法、持續迭代，確保每個改動都有依據，而且真的讓最終產出變好
  ↳ 做 AI 應用也是同樣道理：搞清楚什麼有效、什麼沒用，然後持續改。每次改動都要有證據，確認最後的產出真的變好，而不是憑感覺。

講者建議 judge grader 在評分時，分數和理由的順序應該怎麼安排？