Caching、harness 與 advisor：在 GitHub 規模下用 Claude 打造產品（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這段是 GitHub Copilot 團隊分享他們怎麼跟 Claude 合作：怎麼讓便宜的小模型在需要時找大模型幫忙、怎麼讓另一個模型挑毛病，以及導入新模型時怎麼測試、怎麼判斷真的有效。想知道 AI 怎樣用得又省又準、以及怎麼判斷成效的人，很值得一看。

• 13:08 Anthropic 能評估模型的時間很短，但 Copilot 團隊仍會給出很有洞見的回饋，API 功能也一樣；平台上很多功能要歸功於 Mario 的團隊
  ↳ Anthropic 自己評估新模型的時間很短，但 Copilot 團隊測完還是能給出很有用的回饋。API（讓程式呼叫模型的介面）的回饋也一樣，平台上很多功能都要歸功於 Mario 的團隊。
• 13:39 Copilot 團隊提出的需求：想要 Opus 等級的智慧，但只付 Haiku 等級的價格
  ↳ Opus 是 Claude 最聰明也最貴的模型，Haiku 則小又便宜。Copilot 團隊的要求很直接：想要大模型的腦袋，但只付小模型的錢。
• 14:10 Advisor strategy 的靈感來自軟體團隊：junior 工程師有 senior 當 mentor 幫忙看 code、一起看設計文件，就會進步很多，也不會佔用 senior 太多時間。模型也是如此
  ↳ Advisor strategy 就是讓小模型做事，卡關時再問大模型。概念跟新人配導師一樣：導師只在關鍵處幫忙看，新人進步很快，導師也不會被佔用太多時間。
• 14:10 做法是讓 Haiku 當 executor，並讓它可以呼叫 Opus；Opus tokens 用得非常保守
  ↳ executor 是實際動手做事的模型，這裡是 Haiku，它可以自己去找 Opus。tokens 是模型處理和計費的文字單位，Opus 這部分被刻意用得很省。
• 14:40 示意圖：Haiku 能辨識大部分形狀，碰到超出能力的怪形狀時，就用 tool 呼叫 advisor（Opus），讓更大的模型做更多推理
  ↳ tool 是模型能主動呼叫的功能。平常大部分狀況 Haiku 自己處理，遇到它搞不定的，才透過 tool 去問 Opus，讓大模型負責比較難的推理。
• 15:13 evals 顯示這樣能接近 Opus 等級的智慧，價格卻低很多。原因是 advisor 送出的 tokens 很少，加上兩個模型價差大
  ↳ evals（評估測試）顯示，這樣效果接近 Opus，花費卻少很多。原因有兩個：Opus 只送出很短的建議，而且兩個模型的單價差很多。
• 15:43 Demo：左邊是 GitHub Copilot + Haiku，右邊是 Haiku + 新的 advisor tool，兩邊解同一道腦筋急轉彎題目
  ↳ 示範是同題比較：同一道腦筋急轉彎，左邊只用 Haiku，右邊的 Haiku 可以用新的 advisor tool 找 Opus，看兩邊解題的過程差在哪。
• 16:16 左邊 Haiku 一直嘗試各種方法，像一個很積極但還沒找到答案的 junior 工程師；右邊的 Opus advisor 回傳了，因為它是 Opus，本來就知道那筆資料
  ↳ 左邊的 Haiku 一直換方法試，很努力卻找不到答案。右邊的 Opus 直接回了提示，因為這題需要的資料 Opus 本來就知道，小模型不知道。
• 16:49 提示帶回 context 後，接下來仍全部由 Haiku 執行，右邊先完成；Opus 一點點提示、成本和延遲都很小，就讓 Haiku 強很多
  ↳ context 是模型當下看得到的資訊。Opus 的提示放進去之後，其餘工作仍由 Haiku 完成，卻比左邊早做完，而且多付的錢和等待時間（延遲）都很少。
• 17:20 這還是實驗功能，會在即將釋出的 GitHub Copilot CLI 中展示
  ↳ 這個功能目前還在實驗階段，會在即將推出的 GitHub Copilot CLI 裡展示。CLI 是在終端機用打指令操作的版本。
• 17:51 另一種把呼叫導向正確智慧的做法，GitHub 叫它 rubber duck：在正確時機插入一段 critique（評論）
  ↳ rubber duck 是另一種讓對的模型在對的時候出手的做法：不是遇到難題才求救，而是在關鍵時刻插入 critique，也就是另一個模型對目前做法的評論。
• 18:21 rubber duck demo：實作功能時，模型向 4.6 與 4.5 Opus 請求 critique，收到後在實作前先修改計畫，再照正確方式繼續實作並部署
  ↳ 示範中，模型在實作功能前，先請 Opus 4.6 和 4.5 評論計畫，照建議修改計畫後才動手，最後用正確的做法完成並部署上線。
• 18:21 rubber duck 跟 advisor 不同：用的是另一個模型，角色比較像評論者，提出「我覺得你應該這樣做」
  ↳ rubber duck 跟 advisor 的差別在角色：advisor 是被叫來解難題的高手，rubber duck 則由不同的模型當評論者，提出「我覺得你應該這樣做」的另一種看法。
• 18:51 插入點一：起草計畫之後。很多使用者會先寫計畫再執行
  ↳ 第一個插入時機是計畫寫好之後。很多人習慣先讓 AI 列計畫再執行，這時請別的模型挑毛病，還沒開始做就能先修正方向。
• 18:51 插入點二：完成複雜實作之後，有點像 pre-code review；比等到正式 code review 才看更省 tokens
  ↳ 第二個時機是複雜功能寫完之後，等於在正式 code review（程式碼審查）前先檢查一輪。問題越早發現，後面來回修改花掉的 tokens 越少。
• 19:22 插入點三：寫完測試、還沒執行之前。CI 測試要跑很久時，這樣能更快走完流程，也讓開發者保持專注（flow）
  ↳ 第三個時機是測試寫完、還沒跑之前。CI（自動跑測試的流程）要跑很久，先評論一輪能更快走完流程，開發者也不用一直等，比較能保持專注（flow）。
• 19:22 講者觀察到放在 plan 階段效果最好：這些系統越來越會規劃，在規劃階段就抓到問題，後面的收益最大
  ↳ 三個時機裡，講者發現放在計畫階段效果最好。現在模型越來越會規劃，問題越早在計畫裡抓到，後面省下的重工就越多。
• 19:52 rubber duck 已是實驗功能：下載 Copilot CLI 並啟用 experiments 就能用，也可隨時呼叫，例如「做計畫並諮詢 rubber duck」，取得跨模型家族的 critique
  ↳ 想試的話，下載 Copilot CLI、開啟 experiments 就能用。也可以隨時直接下指令，例如「做計畫並諮詢 rubber duck」，請不同家族的模型幫忙評論。
• 20:22 導入新模型的流程：一開始很亂，過去兩年半變得很有方法。拿到 Anthropic 的模型後，先 onboard 進 CAPI（Copilot API），產生一個 endpoint
  ↳ 導入新模型的流程，過去兩年半從很亂變得很有方法。第一步是把模型接進 CAPI（Copilot API），產生一個 endpoint，也就是可以呼叫這個模型的入口。
• 20:55 第一步是調 harness 和 prompt：GitHub 的 harness 不只服務一個模型家族，要與 Anthropic 密切合作更新 system prompts，並確保 tool interfaces 正確且經過優化
  ↳ harness 是包在模型外面的整套運作機制。GitHub 的 harness 不只服務一家的模型，所以要跟 Anthropic 一起更新 system prompt（給模型的底層指示），並把工具介面調對、調好。
• 20:55 還要微調 agent loop（現在比較少做）；更多心力花在 context management、compaction，以及達到正確的 cache hit rate
  ↳ agent loop 是模型「想、用工具、看結果」反覆跑的循環，現在比較少調。心力多放在管理 context、壓縮過長的內容（compaction），以及提高能沿用快取的比例（cache hit rate）。
• 21:27 接著同時做兩件事：跑 offline benchmarks，以及內部 dogfooding（可視為 online benchmarks），由 Microsoft、GitHub 開發者和密切合作的使用者提供回饋
  ↳ 接著兩件事同時做：offline benchmark 是用固定題庫跑分；dogfooding 是先給自家人用，由 Microsoft、GitHub 開發者和密切合作的使用者實際使用、提供回饋，等於線上測試。
• 21:27 再把發現分享給 Anthropic：以前只寫一份文件，現在會寫得更詳細
  ↳ 測到的發現會整理後分享給 Anthropic。以前只寫一份文件，現在會寫得更詳細。
• 21:57 雙方反覆迭代 API 需要的變更、甚至模型本身與 checkpoints 的變更，一直到模型發布
  ↳ 雙方會一來一回調整，不只改 API，有時還會動到模型本身和 checkpoints（訓練過程中存下的模型版本），一直持續到模型正式發布。
• 22:31 offline 只能給出指標、建立基準，有時不代表現實；上線後的 online evals 與實驗能學到更多，細節無法只靠 offline 調好
  ↳ 離線跑分能產生數據、建立比較基準，但跟真實使用有落差。上線後的 online eval 和實驗才看得出細節問題，很多調整只靠離線測試做不到。
• 22:31 透過 online 實驗調好一個模型通常要幾天，有時甚至幾週；會做大量 A/B testing，而且做法很有方法
  ↳ 靠線上實驗調好一個模型，通常要幾天，有時要幾週。過程中大量使用 A/B testing，也就是讓兩組人用不同版本、比較哪個比較好，而且做法很有系統。
• 23:02 每週把報告交給 Anthropic 和內部所有相關團隊，確保在對的時間調對的模型
  ↳ 每週把報告交給 Anthropic 和內部所有相關團隊，讓大家同步掌握狀況，確保在對的時間調對的模型。
• 23:02 harness 優化分四部分：build prompt and context、呼叫模型、execute tool、附加結果並 loop back；最花時間的是 execute tool 與 build prompt and context
  ↳ harness 每一輪分四步：準備 prompt 和 context、呼叫模型、執行工具、把結果接回去再跑下一輪。最花時間的是執行工具，以及準備 prompt 和 context。
• 23:34 工具很重要，但工具越多越容易混亂，要調的也越多；幾百個工具不是好事。應該依 surface、依具體情境搭配正確工具來調整
  ↳ 工具不是越多越好。給模型幾百個工具，它容易搞混，要調的地方也會暴增。應該依使用的產品介面（surface）和具體情境，只配真正需要的工具。
• 24:05 check permissions 與執行工具時，要傳入正確 context、讀取正確結果；每次新增工具，都要在模型層和工具執行層同時優化
  ↳ 檢查權限和執行工具時，要傳入正確的 context、讀對回傳的結果。所以每加一個工具，模型這一層和工具執行這一層都要同時調整。
• 24:05 心得一：要有公開 benchmark、內部 benchmark，更重要的是用 A/B 做 dogfood、建立 online eval，並確保結果可信
  ↳ 心得一：評估要分好幾層。公開跑分、內部跑分都要有，但更重要的是讓自家人實際用、搭配 A/B 建立線上評估，而且要確認結果真的可信。
• 24:36 心得二：衡量成果（outcome），不是衡量活動。程式碼的 acceptance rate 還可以，survival rate 更好：接受後又刪掉，代表沒有達成目的
  ↳ 心得二：要衡量成果，不是衡量做了多少事。acceptance rate 是 AI 寫的程式被接受的比例，survival rate 是接受後沒被刪掉的比例。接受了又刪掉，等於沒幫上忙。
• 24:36 acceptance rate 再高，survival rate 很低就代表做錯了
  ↳ 所以就算接受率很高，只要留存率很低，就代表 AI 給的東西看起來可以，實際上沒有用，方向做錯了。
• 25:07 AI 時代的產品會改變，要優化成果而非單一指標，否則可能優化了一個指標，卻拖垮整個產品的衡量
  ↳ AI 讓產品一直在變，只盯著單一數字很危險：某個指標可能衝高了，整個產品的表現反而被拖垮。要優化的是真正的成果。
• 25:07 總結：講了 prompt caching、advisor strategy、衡量方式，以及怎麼改進 harness
  ↳ 這支影片總共講了四件事：prompt caching（把重複的提示內容存起來重用，省錢也省時間）、advisor strategy、怎麼衡量成果，以及怎麼改進 harness。

講者認為衡量 AI 程式碼建議時，哪個指標比 acceptance rate（採納率）更好？