挑選合適的模型（第 1/3 段）

🧑‍🏫 Anthropic 的講者 Lucas 在談一個常見的煩惱：新模型一直出，到底該用哪一個？他建議不要看網路評論或公開排行榜，而是自己出一份小考卷，從品質、速度、成本三方面實際測過再決定。如果你常在不同 AI 模型之間猶豫，這支很實用。

• 00:16 講者 Lucas 來自 Anthropic 的 applied AI 團隊，主題是如何挑選合適的模型；概念上看似簡單，但越深入越困難
  ↳ 講者 Lucas 來自 Anthropic（開發 Claude 的公司）的 applied AI 團隊，這個團隊專門把 AI 用在實際工作上。他這次講怎麼挑模型。這件事聽起來簡單，實際做下去才會發現越來越複雜。
• 00:48 情境：Anthropic 推出新模型時，會同時發布 model card、prompting guides 和 benchmark 結果，網路上也會出現各種 hot takes，從「AGI is here」到「Anthropic is cooked」都有
  ↳ 新模型推出時，會附上 model card（模型說明）、prompting guides（使用指南）和 benchmark（公開測驗成績）。網路上評價很兩極，有人喊 AGI（通用人工智慧）來了，也有人說 Anthropic 完了。
• 01:18 真正的關鍵問題是：這個新模型對你的使用情境和業務代表什麼？要不要直接換進產品裡？會不會有提升？如果是全新（greenfield）專案，一開始該選哪個模型？
  ↳ 對你來說，真正該問的是：新模型對我的工作有沒有幫助？要不要直接換上？如果是 greenfield（從零開始做的新專案），一開始該選哪個？
• 01:18 解法是建立一套可重複的流程，每次都能明確給出「要不要改用新模型」的 yes／no 決定，也就是要建立一個 eval
  ↳ 與其每次憑感覺判斷，不如建一套固定流程，新模型一出來就跑一遍，直接得出「換」或「不換」。這套流程就叫 eval（評估測試）。
• 01:50 基本原則：需要更高智慧選 Opus；需要更低延遲或成本選 Haiku；想在兩者之間取得平衡選 Sonnet
  ↳ Claude 分三種：Opus 最聰明，Haiku 最快、最便宜，Sonnet 介於兩者之間。可以先看你的任務最在意哪一點，粗略挑一個。
• 01:50 加上 effort levels 後，問題會更複雜，例如 Sonnet 開 max thinking 對上 Opus 開 low thinking，或比較都不開 thinking 的 Haiku 和 Sonnet
  ↳ effort levels 是設定模型要「想多久」，thinking 是讓模型先思考再回答。加上這些設定後組合變多，例如 Sonnet 想到最多、Opus 只想一點，哪個比較好就很難說了。
• 02:20 很多人不只比較 Claude 的模型，也會跨其他供應商比較模型
  ↳ 實際上很多人不只比 Claude 自家的模型，還會拿其他公司的模型一起比，選項就更多了。
• 02:20 選模型的三大支柱之一是模型品質：在你的任務上實際表現如何，例如任務完成率、準確度等指標
  ↳ 第一個考量是品質。重點不是模型整體有多強，而是它在「你的工作」上做得好不好，例如任務完成的比例、答對的比例。
• 02:51 第二是延遲，對面向客戶的使用情境尤其重要；第三是成本，這也是很多客戶的重要考量
  ↳ 第二是 latency（延遲，也就是發問後要等多久才拿到回覆），客戶直接使用的服務特別在意這點。第三是成本，很多公司也很看重。
• 02:51 可以圍繞品質、成本、延遲這三大支柱建立 eval，幫助你在有依據的情況下決定要用哪個模型
  ↳ 把品質、成本、延遲三項都實際量出來，選模型時就有數據可以依靠，不用憑印象。
• 03:22 重點一：一個小型但設計良好的 eval（可以非常小），比任何公開 benchmark 更能幫你判斷該用哪個模型
  ↳ 自己設計的測驗就算只有幾題，只要題目貼近你實際的工作，會比任何公開排行榜更能告訴你該用哪個模型。
• 03:22 重點二：適合你的模型不一定是每個 token 最便宜或最快的那個，而是「每次成功結果成本最低」的那個
  ↳ token 是模型計算用量和收費的單位。單價便宜的模型如果常出錯、要重做，總花費反而更高。該比的是「平均做成一件事要花多少錢」。
• 03:52 重點三：有很多可以調整的設定，能更細緻地在成本與準確度的邊界上移動，甚至能讓效能對成本的 Pareto 曲線整體移動
  ↳ 可以調整的設定很多（例如思考程度），能細調要多花多少錢來換準確度。Pareto 曲線是把每種花費下能做到的最好表現連成一條線；有些做法能把整條線往上推，同樣的錢做得更好。
• 04:24 公開 benchmark 大致能反映模型在 coding 等任務上是否進步；模型發布時常會附上 SWE bench verified、browse com 等結果，分別對應一般的 coding 能力和研究型任務能力
  ↳ 公開 benchmark 能看出模型大方向有沒有進步。發布時常附 SWE bench verified（測寫程式能力）和 browse com（測上網查資料、做研究的能力）的成績。
• 04:24 但這些 benchmark 通常不符合你的使用情境：實際上線的 coding agent 常常得先上網查某個 SDK 的冷門細節，再寫成程式碼，一個任務就跨了兩種 benchmark
  ↳ 但真實工作常常是混合的。例如寫程式的 agent（能自己分好幾步完成任務的 AI）得先上網查某個 SDK（開發工具包）的冷門用法，再寫成程式，一件事就橫跨兩種測驗。
• 04:55 實際工作負載通常更多元；就算同樣是 coding 任務，也可能和 SWE bench 差很多，例如你用的程式語言根本沒出現在 SWE bench 裡
  ↳ 就算同樣是寫程式，你的情況也可能和測驗差很多，例如你用的程式語言在測驗裡根本沒考。
• 05:25 公開 benchmark 只能提供大致方向；針對你自己的工作負載，建立自己的 evals 非常重要
  ↳ 所以公開成績只能當作大方向的參考。真正要做決定，得靠依照你自己的工作量身打造的 eval。
• 05:25 eval 由一組 task 組成，task 是 eval 的最小單位：一個包含輸入和成功標準的測試，再把這些測試累積成資料集
  ↳ eval 由很多個 task 組成。task 是最小單位，也就是一道題：寫清楚輸入是什麼、怎樣算成功。題目累積起來就是一份題庫（資料集）。
• 05:56 講者的經驗法則是把 eval 當成學校的數學考試：有題目、有要答對的答案，也很重視中間的計算過程
  ↳ 講者把 eval 比喻成數學考試：有題目、有標準答案，老師也會看計算過程，不是只看最後的答案。
• 06:26 對 agentic 任務特別適用：除了檢查 agent 最後有沒有得到正確結果，也要確認它走了正確的步驟，過程和結果一樣重要
  ↳ 這點對 agentic 任務（AI 自己規劃、分好幾步執行的任務）特別重要。除了看結果對不對，也要檢查它是不是用對的方法做到的。
• 06:58 客服 agent 範例：用 LLM as a judge 檢查最終回覆是否符合預期回覆，也用 LLM as a judge 確認 agent 是否用正確方式查詢資料庫、找到客戶資料
  ↳ 以客服 agent 為例：用 LLM as a judge（請另一個 AI 當評審）檢查最後的回覆是否符合預期，也檢查它有沒有正確查資料庫、找到這位客戶的資料。
• 07:28 LLM as a judge 的好處：agent 寫出的 SQL 語法可能略有不同，只要撈出相同的資料，judge 仍能正確判斷，不會被語法差異干擾
  ↳ agent 查資料時會寫 SQL（查資料庫用的指令），每次寫法可能不太一樣。AI 評審看的是撈出來的資料對不對，不會因為寫法不同就判成錯。
• 07:28 也可以用確定性的程式碼 eval，例如確認 agent 一定有呼叫搜尋內部 routines 的工具，或搜尋時一定有加上參數，把範圍限定在客戶所在的國家
  ↳ 另一種是 deterministic（用固定規則判斷、不靠 AI）的程式檢查，例如確認 agent 一定有呼叫內部搜尋工具，或搜尋時一定有把範圍限定在客戶所在的國家。
• 07:58 每個 task 都要建立一組 graders；建立資料集、事先定義正確解法、正確結果和正確步驟很費工，但這是槓桿最高的工作之一
  ↳ 每道題都要搭配一組 grader（評分機制）。事先想好正確答案和正確步驟很花時間，但做一次之後，每次比較模型都能重複使用，回報很大。
• 07:58 在大量工作都交給 AI 自動化的時代，花時間建立 eval 資料集，是運用人類時間最好的方式之一
  ↳ 當很多工作都能交給 AI 自動做，人的時間最值得花在定義「怎樣才算做對」，也就是把測驗題目做好。
• 08:29 TLDR：建立一組參考用的 evals，作為挑選模型時更以資料為依據的決策基礎
  ↳ TLDR（懶人包）：準備一套自己的 eval 當作基準，選模型時靠數據，不靠感覺。
• 08:29 Anthropic 內部建立 evals 已有一段時間，接下來介紹建立 evals 時常見的陷阱和失敗模式
  ↳ Anthropic 自己做 eval 已經一段時間，接下來分享做 eval 時常踩的坑。
• 09:00 陷阱一：把雜訊誤當訊號。每個 task 都要跑好幾次，確認結果穩定；如果指標變異很大，可能代表 task 定義不夠清楚，或 evals 沒有完全對齊
  ↳ 第一個坑是把偶然當成真相。AI 每次回答可能不一樣，所以同一題要跑好幾次，看結果穩不穩。如果分數忽高忽低，可能是題目沒寫清楚，或評分標準沒對準。
• 09:30 陷阱二：infra failures。結果看起來怪怪的時候（例如 Opus 分數特別低），翻看 transcripts 可能會發現大量 API 或 tool call 失敗，這些要和模型本身的評估分開
  ↳ 第二個坑是 infra failures（系統環境出錯）。例如 Opus 分數低得奇怪，翻 transcripts（執行紀錄）才發現是 API（程式之間溝通的管道）或呼叫工具一直失敗，不是模型差。這類問題要分開算。
• 10:01 要深入看 transcripts，找出失敗發生在哪裡，判斷分數低是模型本身表現不好，還是 infra 出了問題；這件事很容易被忽略，人常常跑完 eval 就直接依結果做決定
  ↳ 所以要真的打開紀錄，看是哪一步失敗，分清楚是模型不行，還是系統出問題。很多人跑完只看分數就做決定，很容易判斷錯。

依照講者的說法，最適合你使用情境的模型應該是哪一個？