挑選合適的模型（第 3/3 段） ☕ Buy me a coffee

🧑‍🏫 這是「怎麼挑模型」系列的最後一段，重點有兩個。第一，把送給 AI 的資料先整理乾淨，就能省錢、變快，而且答案更準。第二，用你自己設計的測驗實際比較各種模型和設定，靠數據決定用哪一個，不要只看排行榜或名氣。講者用真實案例和圖表示範，看完你會知道「最貴的模型不一定最好，最便宜的也不一定最省」。

• 21:07 講者的「hot take」：大家花太多時間在很複雜的多 agent 協作（multi-agent orchestration）系統上，卻沒花足夠時間做簡單又有效的事，也就是 context hygiene 和 context engineering
  ↳ 講者直說：大家忙著蓋多個 AI 分工合作的複雜系統（multi-agent orchestration），卻忽略更簡單有效的基本功 context hygiene／context engineering，也就是把送進模型的資料整理乾淨、精簡。
• 21:07 提高工具回傳內容（tool response）的 token 效率，可以少送很多 token 給模型，同時省成本、降低 latency
  ↳ 工具（像查資料的功能）回傳給 Claude 的內容叫 tool response。內容越精簡，送進模型的 token 越少（token 是模型計算文字量和收費的單位），就越省錢，等回應的時間（latency）也越短。
• 21:38 附帶的好處：給 Claude 更乾淨、更精簡的資料，Claude 的回答通常也會更好、更準確
  ↳ 不只省錢。資料乾淨、沒有多餘雜訊，Claude 比較不會被無關內容干擾，答案通常也更準。
• 21:38 範例：一個回傳運動資料（Premier League 比分）的工具。第一個改動是用 markdown 取代 JSON
  ↳ 例子是一個查英超比分的工具。第一步把 JSON（程式間交換資料的格式，有很多括號和引號）改成 markdown（用簡單符號排版的純文字），資訊一樣，字卻少很多。
• 22:10 第二個改動是把完整又冗長的日期時間戳改成很簡單的格式；另外加上星期幾，Claude 就不用自己推算每場比賽是星期幾
  ↳ 第二步把精確到秒的冗長時間戳記改成簡單的日期，再直接標上星期幾。這樣 Claude 不用自己推算，既省 token，也少一個算錯的機會。
• 22:10 光是整理這個回傳內容，這個 tool response 的 token 就少了 66.4%
  ↳ 光是整理格式，這份回傳內容的 token 就少了 66.4%，資訊沒少，份量只剩約三分之一。
• 22:10 效果會一直累積：agent 跑多輪時，tool response 不是只出現一次，而是在對話的每一輪都會出現，所以這些小的 hygiene 改善影響很大
  ↳ agent 是會自己呼叫工具、一步步完成任務的 AI。它每多跑一輪，前面的工具回傳內容都會再送進模型一次，所以省下的量會一輪一輪累積，小改善最後變成大差別。
• 22:40 客戶案例（web search）：把同一次搜尋、甚至不同次搜尋回傳的文章先去重（deduplicate），再交給 Claude
  ↳ 另一個客戶的網路搜尋功能，常在同一次或不同次搜尋抓到重複的文章。他們先去重（deduplicate，重複的只留一份），再交給 Claude。
• 23:11 去重的結果：Claude 收到的 input token 少了 77%，成本降低 65%，準確度反而提高 9%，因為要推理的資料變少了
  ↳ 結果 Claude 讀進的 token 少了 77%，成本降了 65%，準確度還提高 9%。要讀的東西變少、重複的雜訊不見了，模型反而更抓得到重點。
• 23:11 這些數字不是隨口說的。能實際量出來，是因為一開始就先建好了 eval
  ↳ 這些數字之所以可信，是因為他們事先建好了 eval（依自己實際用途設計的一套測驗題）。改之前、改之後跑同一套題目，才量得出到底差多少。
• 23:43 靠 context engineering 省下 65% 成本後，就有空間改用更聰明的模型，或在同樣預算下跑全新的使用情境
  ↳ 省下 65% 成本不只是省錢而已。這筆預算可以拿去換更聰明（通常也更貴）的模型，或在同樣的花費下做原本做不起的新應用。
• 23:43 建議別把 API 回應直接原封不動傳回工具。很多工具都是包裝 API 的，應該先把 API 回來的 JSON 整理過再交給 Claude，跟給人看一樣，越簡單好讀越好
  ↳ 很多工具其實只是在轉接某個 API（程式之間互相要資料的接口）。別把 API 回傳的原始 JSON 直接丟給 Claude，先挑出需要的欄位、整理成好讀的樣子，就像整理給人看一樣。
• 24:14 重點一：一個小而設計良好的 eval，比任何公開 benchmark 更能告訴你該用哪個模型，值得花時間建
  ↳ 重點一：自己做一套小而精的 eval，比看公開的 benchmark（通用的評比排行）更能告訴你哪個模型適合你，因為它測的就是你真正要做的事。
• 24:44 重點二：合適的模型不是「每個 token 最便宜」，而是「每次成功完成任務最便宜」。有了 eval 就能用多種模型和設定跑，看出 Pareto frontier，再決定要選曲線上的哪一點
  ↳ 重點二：要比的是「每成功完成一次任務花多少錢」，不是 token 單價，便宜但常失敗的模型反而貴。用 eval 跑過多種組合，就能畫出 Pareto frontier：每種花費下能拿到的最好表現連成一條線，再決定要選線上哪一點。
• 25:14 重點三：用 effort、thinking、prompt caching、context engineering 這幾個「旋鈕」更細緻地控制落在 frontier 的哪個位置，甚至把整條 frontier 往前推
  ↳ 重點三：有幾個設定可以調：effort（要模型多用力）、thinking（先想再答）、prompt caching（重複的內容暫存起來重用，省錢又省時），再加上 context engineering。調這些能微調你落在線上的位置，甚至讓整條線往前推。
• 25:14 做到這三點，就能選對模型，甚至開啟新的使用情境，用更低成本取得更高的智慧
  ↳ 三件事都做到，就能選對模型，還可能用更低的成本拿到更聰明的結果，做出以前划不來的應用。
• 25:44 實作工作坊連結：cwc26.short.gy/workshops，可以跟著做，也可以之後自己做
  ↳ 講者提供了實作工作坊的連結 cwc26.short.gy/workshops，可以現場跟著做，也可以之後自己練。
• 26:15 工作坊提供一個 skill，可以稽核你現有的 eval，也可以對 eval 做 sweep：改寫（instrument）程式，讓 eval 跨多個模型、thinking 開或關、多個 effort level 執行
  ↳ 工作坊附一個 skill（一包事先寫好、讓 Claude 照著做的指令）。它能檢查你現有的 eval，也能做 sweep：自動修改程式（instrument），讓同一套 eval 在不同模型、thinking 開或關、各種 effort 等級下全部跑一遍。
• 26:46 這個 skill 會把結果畫成圖、存檔並整理好格式，讓你看出 eval 在不同模型、thinking 設定、effort level 下的表現
  ↳ 跑完後，skill 會自動畫圖、存檔、整理好格式，你一眼就能比較各種模型和設定的表現，不用自己整理一堆數字。
• 26:46 示範用的是 Tao bench，一個客服 agent 使用情境的 benchmark，這次只看其中航空公司（airline）的部分
  ↳ 示範用的是 Tao bench，一套模擬 AI 客服處理顧客問題的測驗題，這次只跑航空公司客服的部分。
• 27:16 工作坊 README 的步驟：先下載並設定 Tao bench（可以把說明裡的 prompt 丟給 Claude，讓它幫你設定），接著執行 skill 改寫程式，最後跑 eval
  ↳ 照 README（專案附的說明文件）做三步：先下載並設定 Tao bench（可以把說明裡的 prompt 丟給 Claude 代勞），再用 skill 改寫程式，最後執行 eval。
• 27:48 示範中 Claude 成功載入 skill。為了節省時間，講者直接跳到事先跑好的結果
  ↳ 現場 Claude 順利載入了 skill。因為全部跑完很花時間，講者直接拿事先跑好的結果來講。
• 28:18 這次 sweep 跑了三個模型：Haiku、Opus（字幕作 Opus 4 7）、Sonnet（字幕作 Sonic 4 6），各自搭配 thinking 開或關與不同 effort level，講者說結果讓他很意外
  ↳ 這次比了 Haiku、Sonnet、Opus 三個模型（Haiku 最小、最便宜，Opus 最強），每個都搭配 thinking 開或關和不同 effort 等級。結果有些地方連講者都很意外。
• 28:48 圖一（每題通過率對每題平均 output token）：Opus 開 thinking、high effort 的通過率最高，而且用的 token 還比 Sonnet 在同一情境下少
  ↳ 圖一比通過率和平均輸出 token：Opus 開 thinking、high effort 的通過率最高，用的 token 卻比同樣設定的 Sonnet 還少。大模型不一定比較囉嗦。
• 29:20 圖二（成本）：Opus 在 high effort 下表現最好，但顯然也最貴。只追求通過率就選 Opus 開 high thinking
  ↳ 圖二看成本：Opus 在 high effort 下表現最好，但也最貴。如果你只在乎答對率、不計成本，就選 Opus 開 thinking、high effort。
• 29:20 如果要以成本為優先，Haiku 開 thinking 的表現和 Sonnet 開 thinking 加 high effort 差不多
  ↳ 如果成本優先，Haiku 開 thinking 的成績和 Sonnet 開 thinking 加 high effort 差不多，可以當作預算有限時的選擇。
• 29:50 圖三（latency）：Opus 開 thinking、high effort 反而比 thinking 程度相近的 Sonnet 更快、latency 更低
  ↳ 圖三看回應速度：Opus 開 thinking、high effort 反而比思考程度差不多的 Sonnet 更快，打破「大模型一定比較慢」的直覺。
• 29:50 這些圖更重要的意義是提供數據，讓你有根據地決定要用哪個模型和設定
  ↳ 這些圖真正的價值在於實測數據：有了數據，選模型和設定就不用憑感覺或名氣，而是有根據。
• 30:21 數據能揭露模型在不同 thinking level 下一些不直覺的特性，再依你重視的條件（latency、成本或模型品質）做取捨
  ↳ 數據常常會顯示違反直覺的結果，例如大模型更省 token、速度更快。看清楚之後，再依你最在意的是速度、成本還是品質來取捨。
• 30:21 結尾重點一：想選對模型，就要針對自己的使用情境建 eval。和 Anthropic 的 applied AI team 合作的客戶，他們可以幫忙建
  ↳ 結論一：想選對模型，先替自己的用途建 eval。和 Anthropic 的 applied AI 團隊合作的客戶，可以請他們協助建立。
• 30:52 結尾重點二：針對自己在意的指標做最佳化，用數據決定要優先追求智慧、latency 還是成本
  ↳ 結論二：先想清楚自己最在意哪個指標，再用數據決定要優先追求聰明、速度還是省錢。
• 30:52 結尾重點三：做好 context engineering、運用 prompt caching 等策略，可以把整條曲線往前推，讓模型發揮更多
  ↳ 結論三：做好 context engineering、善用 prompt caching 這類做法，可以在同樣成本下拿到更好的表現，等於把整條取捨線往前推。

講者分享的 web search 客戶案例中，把搜尋回傳的文章先去重再交給 Claude，「成本」降低了多少？