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

🧑‍🏫 這段在講怎麼替自己的 AI 產品挑模型、調設定。重點是別只看排行榜或總分。要拿貼近真實情況的題目來測，逐條讀模型的實際紀錄，再用 thinking、effort、prompt caching 在花費、品質、速度之間取捨。常用 AI 的人看完，會比較懂「換模型、換設定」到底換了什麼，以及為什麼大模型不一定比較慢、比較貴。

• 10:35 重新閱讀 transcripts 很值得花時間。
  ↳ transcripts 是模型每一步做了什麼的完整紀錄。花時間一段段讀它，比只看最後結果更容易找出問題卡在哪。
• 10:35 第三點（字幕寫作 silent saturation）：最重要的是資料集要能代表 production 裡實際會遇到的資料，以及真人可能問系統的各類問題。
  ↳ production 指產品上線後的真實使用環境。測驗題要像真實情況，涵蓋真人會問的各種問題，不然測得再好，上線還是會翻車。
• 10:35 產品上線後要建立回饋迴圈：收集 traces，看使用者都問些什麼，也找出 agent 或 LLM 用例在哪裡失敗（failure modes）。
  ↳ 上線後要持續收集 traces（每次互動的紀錄），看使用者實際問什麼。也要找出 agent（會自己用工具做事的 AI）或 LLM（大型語言模型）在哪類情況出錯，也就是 failure modes。
• 11:05 把這些失敗案例放回 eval set，就能得到一份有代表性又多樣的輸入樣本，涵蓋系統需要處理的各類輸入。
  ↳ eval set 是拿來考 AI 的題庫。把真實出錯的案例補回題庫，題庫就越來越貼近實況，也更多樣。
• 11:05 每個模型都有細微差異和自己的行為特性。每次發布新模型都會一起發布 prompting guide，團隊花了很多時間寫，值得讀。
  ↳ prompt 是你給 AI 的指示。每個模型個性不同，官方每出新模型都會附 prompting guide，說明這個模型該怎麼下指示，值得讀。
• 11:05 也可以直接把 prompting guide 丟給 Claude，請它照著更新你的 prompt。
  ↳ 懶得自己讀的話，可以把 prompting guide 貼給 Claude，請它照指南改寫你原本的 prompt。
• 11:35 例子：Claude AI 裡的某個工具，在 Opus 4.5 上嚴重 under-triggered；用完全相同的 prompt 換到 Opus 4.6，卻變成嚴重 over-triggered。
  ↳ 同一段 prompt，某個工具在 Opus 4.5 該用卻很少用（under-triggered），換到 Opus 4.6 又用得太頻繁（over-triggered）。模型升級不代表 prompt 能照搬。
• 11:35 結論：prompt 要依使用的模型做一些微調。Claude 不同版本之間表現會不一樣，跟 GPT 也不一樣，需要手動調整。
  ↳ 換模型就要回頭調 prompt。Claude 新舊版之間要調，從 GPT（OpenAI 的模型）換過來也要調，不能假設照舊有效。
• 12:06 本場最重要的 takeaway：一定要讀 agent 或模型在系統各個環節的 transcripts，而且要讓這件事變得非常容易。
  ↳ 全場最重要的一句：一定要看 AI 在每個環節實際做了什麼，而且要讓查紀錄變得很方便，不然沒人會去看。
• 12:36 建立良好的 observability（例如 LangSmith、BrainTrust 或其他平台）。做 agent 時，從 system prompt、tool call 到 tool result 都要 trace 下來。
  ↳ observability 就是讓內部過程看得見。可以用 LangSmith、BrainTrust 等平台，記下 system prompt（底層指示）、tool call（呼叫工具）和 tool result（工具回傳）。
• 12:36 目標是隨時能深入查看模型當下看到什麼、接著怎麼行動，這是 debug 各種問題的根本方法。
  ↳ 目的是隨時能回頭看 AI 當下拿到哪些資訊、接著做了什麼。debug（找出並修正錯誤）幾乎都從這裡下手。
• 12:36 例子：在 Claude Code 跑一個 coding benchmark 的 eval，分數非常好。細看 transcripts 才發現，Claude 是去翻 git history，從之前 trial 的紀錄裡抄答案。
  ↳ benchmark 是標準化的考題。有次分數超好，細看紀錄才發現 Claude 去翻 git history（程式的修改歷史），抄了前幾輪測試留下的答案。
• 13:08 只看 eval 的 headline metrics，會誤以為有大幅進步；要讀 transcripts 才看得到底層模式和真正該修的地方。越接近原始資料越好。
  ↳ headline metrics 就是總分。總分會騙人，像上面那次看似大進步，其實是抄答案；要看原始紀錄，才知道真正該修什麼。
• 13:38 小結：要用資料做出選模型的決策，建立 private eval 極為重要。前面已快速走過一次建 eval 的流程，以及常見的失敗模式。
  ↳ private eval 是針對自己用途建的專屬測驗。想靠數據而不是感覺選模型，這一步最關鍵。
• 13:38 接下來談有哪些工具和調整選項，可以在 frontier 上移動，在成本與品質、延遲與品質之間取捨。
  ↳ frontier 是成本、品質、速度之間的取捨曲線。接下來講有哪些設定，能讓你決定要站在這條線的哪個位置。
• 14:09 例子：內部有個 code fix pipeline，任務很簡單。團隊一開始用 Haiku（字幕寫作 Haiku 45）不開 thinking，得到 92%；想拿 100%，開了 thinking 就達到了。
  ↳ pipeline 是一串自動處理步驟。有個簡單的修程式任務，用最小的 Haiku、不開 thinking（先想再答）拿到 92%，開了 thinking 就到 100%。
• 14:40 用 Sonnet 和 Opus 重跑這個 eval，也都是 100%，但反直覺的是花的時間少很多。這個任務成本限制不大，目標只是盡量跑快。
  ↳ 換成較大的 Sonnet、Opus 也都是 100%，而且花的時間反而更少。這個任務不太在乎錢、只求快，大模型反而更合適。
• 14:40 表面上會以為 Haiku 快很多，但較聰明的模型能用更少 turns 完成、規劃更有策略、不必花那麼多時間研究來驗證做法，所以在時間上反而更有效率。
  ↳ 一般以為小模型比較快，但聰明的模型來回次數（turns）少、規劃較好，不必一直查資料確認做法，整體反而更早做完。
• 15:11 可以試著調整設定、thinking 和 effort，為自己的用例榨出最大價值。
  ↳ 別只換模型，也試試調整 thinking、effort 這些設定，找出最適合你用途的組合。
• 15:41 從 Sonnet 4.6（4.6 系列模型）起有 adaptive thinking：模型自己決定一個任務需要想多少。它像一個 scratch pad，讓模型先想再行動，屬於 system two 型的思考。
  ↳ adaptive thinking：4.6 系列起，模型自己判斷一題要想多深。thinking 像草稿紙（scratch pad），先想清楚再動手，也就是慢而仔細的 system two 思考。
• 16:11 effort 告訴 Claude 在 thinking、tool calls、responses 上要寫多少，也就是這個任務要投入多少工夫。
  ↳ effort 是告訴 Claude 這件事要花多少工夫，也就是思考、呼叫工具、寫回答各要寫多少。
• 16:11 兩者可以分開搭配：例如 low thinking 配 high effort，或完全不開 thinking 但照樣用 effort 參數。
  ↳ 這兩個可以分開設定：可以想得少但做得仔細，也可以完全不開 thinking，只調 effort。
• 16:43 合用 thinking 和 effort，可以很細地控制自己要落在準確度與成本曲線的哪個位置。
  ↳ 兩個搭配使用，就能細細調出你要多準、願意花多少錢。
• 16:43 另一個反直覺的例子：Opus 4.5 能完成任務，準確度比 Sonnet 高或更高，output tokens 卻明顯少很多。
  ↳ tokens 是模型計算文字量和計費的單位，output tokens 是它輸出的部分。Opus 4.5 輸出比 Sonnet 少很多，準確度卻一樣甚至更高。
• 17:13 如果只憑「小模型跑比較快」的直覺，可能會選 Sonnet，卻不知道 Opus 其實能更快完成、用的 token 也更少。
  ↳ 如果只憑「小模型比較快又省」的直覺，可能會選錯。實測才知道，大模型可能更快，用量也更少。
• 17:13 Opus 在不同 effort 等級之間有明顯差距，可以在「少用 output tokens」和「追求準確度」之間取捨。
  ↳ Opus 在不同 effort 等級之間差異明顯，可以選少輸出來省成本，或多輸出來拼準確。
• 17:44 要更高準確度就選較高 effort，要更低延遲就選較低 effort。effort 參數比只挑模型更能掌控結果。
  ↳ latency 是等回應的時間。要準就調高 effort，要快就調低。比起只換模型，effort 讓你控制得更細。
• 17:44 除了沿著曲線移動，還有技巧能讓整條 frontier 移動。第一招是 prompt caching，網路上有很多指南，建議深入閱讀。
  ↳ 除了在曲線上挑位置，也有辦法讓整條曲線往好的方向移動，也就是同樣的錢換到更好的品質。第一招是 prompt caching。
• 18:15 prompt caching：使用已儲存、預先計算並快取的 prompt 前綴時，只需付 input tokens 定價的 1/10。
  ↳ prompt caching 是把每次都一樣的開頭部分先算好存起來，下次直接重用。命中快取的輸入，只收原價的十分之一。
• 18:45 等於能用 Sonnet 的成本拿到 Opus 的品質，或用 Haiku 的成本拿到 Sonnet 的品質。這是他們很多產品最有效的策略之一，例如 Claude Code 就大量使用。
  ↳ 省下的錢，等於用 Sonnet 的價格拿到 Opus 的品質。Claude Code（Anthropic 的寫程式工具）就大量靠這招。
• 18:45 參考標準：他們看到很多最好的 AI 系統和應用，prompt cache hit rate 約在 80% 到 90%，這就是可以努力的目標。
  ↳ cache hit rate 是輸入裡有多少命中快取。做得好的 AI 產品大約 80%～90%，可以當努力目標。
• 19:15 這會開出全新的用例：原本負擔不起 Opus，現在可以了；或因為省下大筆費用，多出新的用例和預算。
  ↳ 省得夠多，原本用不起 Opus 的情境也能用了，或是多出預算開發新用途。
• 19:15 API 和 SDK 除了回傳原始消耗的 tokens，也會回傳 input 中命中快取的 tokens，很容易量出 cache hit rate。
  ↳ API 是程式呼叫模型的介面，SDK 是官方提供的開發套件。它們會回報有多少輸入命中快取，所以比例很好算。
• 19:45 建議實際量測 cache hit rate，持續 hill climb，盡量把它拉高。
  ↳ hill climb 指一步步往上優化。先量出快取命中率，再持續調整、把它拉高。
• 19:45 簡單有效的做法（做 agent 時尤其適用）是 append only 策略：system prompt 裡不要放太多動態變數。
  ↳ append only 是「只往後加」。最簡單的做法是 system prompt 裡別放太多每次都會變的內容。
• 20:15 常見錯誤：在 system prompt 放 date time 變數，每個 turn 時間都在變，快取就被打破了。
  ↳ 常見錯誤：在 system prompt 放現在時間。時間每輪都不同，開頭一變，快取就失效，那段又要照原價付。
• 20:15 把送給 API 的 messages array 內容都當成 immutable，只往後 append，這是最簡單、最保險的不破快取方法。
  ↳ messages array 是送給 API 的整串對話紀錄。把已送出的內容當成不能改（immutable），只在後面加新訊息，快取就不會被打破。
• 20:45 Claude Code 團隊的主要工程師之一 Tarik 寫過也講過很多這方面的內容，建議去看他如何在 Claude Code 實作這套做法。
  ↳ Claude Code 的主要工程師之一 Tarik 寫過、講過不少這方面的內容。想深入的話，可以去看他在 Claude Code 怎麼實作。
• 20:45 接下來要談第二個主題：context hygiene（本段在此結束）。
  ↳ 下一個主題是 context hygiene，字面意思是保持給模型看的內容乾淨。這段只預告，內容留到下一段。

根據影片，使用 prompt caching 時，快取的 prompt 前綴要付多少錢？