大規模評估與改進 Replit Agent（第 2/2 段）

🧑‍🏫 這是 Replit 分享的後半段，講他們怎麼讓自家寫程式的 agent（能自己動手完成多步驟任務的 AI 助手）每天進步：先讓 AI 從大量執行紀錄裡找出問題，再讓 AI 寫修改，最後由人決定要不要上線。講者也提醒，這個流程裡人的判斷仍然很關鍵。想知道 AI 產品團隊怎麼靠使用者真實使用的情況持續改進，這支很值得看。

• 13:51 把使用者的各種訊號彙整起來，就得到類似 A/B test 結果的儀表板
  ↳ A/B test 是把使用者分成兩組，一組用舊版、一組用新版，看哪一版比較好。Replit 把使用者的各種反應整理成一張總表，看起來就像一份 A/B test 的結果。
• 13:51 A/B test 的殘酷事實：結果不會全綠或全紅，很少給出非常明確的訊號
  ↳ 現實是新版通常有些指標變好、有些變差，很少一面倒。所以光看數字，很難斷定新版到底是好是壞。
• 13:51 例子：agent 平均執行時間增加 7%，但成本便宜 8%，正面與負面情緒也有波動
  ↳ 舉例來說，新版 agent 做事平均慢了 7%，成本卻省了 8%，使用者的正面和負面情緒也都有起伏。這樣算進步還是退步，數字本身給不出答案。
• 14:24 遇到這種不明確的結果時，人的品味（human taste）和產品理念仍扮演關鍵角色
  ↳ 數字分不出高下時，就得靠團隊的判斷：我們想做出什麼樣的產品？這種「品味」決定要選快一點，還是便宜一點。
• 14:24 為了產生 A/B test 候選項目，他們每天把收到的所有 trace 分群（cluster）
  ↳ trace 是 agent 每次做事的完整過程紀錄。為了找出值得測試的改進點，他們每天把所有 trace 依相似程度分成一群一群，這就叫 cluster（分群）。
• 14:54 先辨識哪些 cluster 代表 agent 的正常行為；大多數情況是成功的，但仍有一條長尾問題
  ↳ 先認出哪幾群是 agent 正常運作的樣子。大部分任務都成功，但還有一長串數量少、種類雜的零星問題，這叫長尾（long tail）。
• 14:54 找到有問題的 cluster 後，把所有失敗摘要做 embedding，依類型分群，找出同一時間發生的各種失敗
  ↳ embedding 是把文字轉成一串數字，意思相近的文字，轉出來的數字也相近。把每則失敗摘要都轉成 embedding，同類型的失敗就能自動歸在一起。
• 15:24 再交給 LLM 分類到底發生什麼事
  ↳ 分好群之後，再請 LLM（像 Claude 這種大型語言模型）讀每一群，說明這群失敗實際上是怎麼回事。
• 15:24 關鍵是不靠 regex 或確定性的日誌技術，才能把語意相近、但 agent 輸出不完全一樣的東西分在一起
  ↳ regex 是用固定規則比對文字的傳統做法。agent 每次出錯的說法都不一樣，死規則抓不到；改用語意分群，意思一樣就能歸成同一類。
• 15:24 cluster 設定必須每晚重新訓練，因為同時跑好幾個版本、每天出很多版，無法固定
  ↳ 分群方式不能設定一次就一直用。他們同時跑好幾個版本、每天又發很多新版，錯誤的樣子天天在變，所以每晚都要重新分群。
• 15:54 重新訓練後可以回頭看：以為修好的問題，對應的 cluster 是否真的消失了
  ↳ 每天重新分群還有一個好處，就是能回頭檢查：以為修好的問題，要看到它那一群真的消失了，才算數。
• 15:54 例：某個只在特定條件下約 1% 發生的工具失敗，不會出現在 DataDog 儀表板上，但能靠 cluster 追到
  ↳ DataDog 是一種常見的系統監控儀表板。某個工具只在特定條件下約 1% 會出錯，量小到在儀表板上看不出來，分群卻能把它找出來。
• 16:26 發出新 PR 後，那個 cluster 消失了，就有證據表示問題已經緩解
  ↳ PR（pull request）是工程師送出程式修改、申請併入正式程式的單子。修正的 PR 上線後，那群錯誤不見了，就證明問題已經緩解。
• 16:26 內部打造的技術叫 Telescope，是一個相對簡單的迴圈
  ↳ Telescope 是 Replit 自己做的內部工具，本質上是一個簡單的循環：找問題、修改、驗證、上線，然後一直重複。
• 16:56 Telescope 第 1 步：根據 trace 分群來發現問題
  ↳ 第一步就是前面說的：把 trace 分群，從裡面看出哪一群代表有問題。
• 16:56 第 2 步：用 coding agent 自動開 PR，依據 trace、日誌和各種儀表板的資訊產生程式碼修改
  ↳ 第二步交給 coding agent（會自己寫程式的 AI）。它讀 trace、日誌和各種儀表板的資料，自動寫出修改並開 PR。
• 16:56 第 3 步：評估這個修改是否是 breaking change，重新跑 By bench（字幕原文）
  ↳ 第三步檢查這個修改會不會把原本正常的功能弄壞（這種狀況叫 breaking change），做法是重跑一套字幕寫作 By bench 的評測。
• 17:26 By bench 像 litmus test（試金石）：分數掉 10 分，就判定這個修改不好
  ↳ litmus test 原本是化學試紙，引申為簡單明確的檢驗。By bench 就是這個角色：分數掉 10 分，這個修改就直接判定不合格。
• 17:26 有爭議、可能對 agent 產生負面影響的修改，會跑 A/B test 讓使用者試，找出取捨
  ↳ 如果修改有爭議、可能帶來副作用，就放給一部分使用者試用、跑 A/B test，看實際上是得多還是失多。
• 17:26 如果改動明確有益，就直接上 production
  ↳ production 是指正式上線、真實使用者在用的環境。如果修改明顯只有好處，就不另外測試，直接上線。
• 17:26 假設正確但 PR 不完美時，會持續迭代，可能再跑一次 A/B test，直到狀態良好才上線
  ↳ 如果問題判斷對了，但 AI 寫的修改還不夠好，就繼續改，必要時再跑一次 A/B test，確定穩了才上線。
• 17:57 這和 AI engineer 平常的工作很像，但現在其中 90% 由迴圈裡的 agent 協助完成
  ↳ AI engineer 是專門打造 AI 產品的工程師。這套流程本來就是他們的日常工作，差別在現在大約九成由迴圈裡的 agent 代勞。
• 17:57 實例：Replit Agent 在收到第一個 prompt 時就會啟動執行環境，設定要花好幾秒
  ↳ 實際案例：使用者一送出第一個 prompt（給 AI 的指令），Replit Agent 就開始準備跑程式用的環境，這要花好幾秒。
• 18:28 長尾情況下環境設定時間比預期長，agent 在環境還沒設好時就開始動作
  ↳ 少數情況下，環境準備得比平常久，agent 卻沒等環境準備好就開始動手。
• 18:28 agent 很急著解決問題，於是跑偏去當場修環境
  ↳ agent 很急著把事情做完，一發現環境怪怪的，就自己跑去修環境，偏離了使用者真正交代的事。
• 18:28 agent 不是確定性的，每次除錯過程都不同，光看日誌幾乎找不到這個長尾問題
  ↳ non-deterministic（非確定性）是指同樣的輸入，每次結果可能不同。agent 每次處理這狀況的方式都不一樣，日誌各不相同，光翻日誌很難看出來。
• 18:59 透過語意層把 trace 分群後，才發現這問題其實蠻常發生，於是馬上做出 patch 修好
  ↳ 用語意分群之後，才發現這些看似不同的狀況其實是同一件事，而且還蠻常發生，於是馬上做出修補（patch）解決。
• 18:59 這個案例是純粹的 regression，所以不用跑 A/B test；需要測試的問題才會多加一步
  ↳ regression 是指原本正常的功能退步、壞掉了。這個案例單純是壞掉要修，沒有取捨問題，所以不必跑 A/B test。
• 19:31 講者認為這個迴圈裡仍有很多需要人類做的智力工作
  ↳ 雖然很多工作交給 agent 做了，講者強調這個流程裡還有不少需要人動腦的地方。
• 19:31 找到 cluster 時，團隊一定先提出「哪裡可能出錯」的假設
  ↳ 看到一群問題時，團隊一定會先自己推測「可能是哪裡出錯」，不會直接整包丟給 AI。
• 20:02 production 會產生大量可修的候選問題，必須排優先順序，決定把心力和資源放在哪
  ↳ 正式環境每天冒出的可修問題太多，不可能全部修，必須排優先順序，決定人力和資源要花在哪裡。
• 20:02 假設夠有意思才往下做，而且不會讓 agent 在沒人監督下寫 PR，會提供團隊的理解作為指引
  ↳ 推測夠有價值才往下做。而且不會放 agent 自己亂寫 PR，會把團隊對這個問題的理解交給它當方向。
• 20:02 每次決定做哪個 PR、跑哪個 A/B test，就是在塑造要最佳化的方向（shaping the hill）
  ↳ shaping the hill 的意思是決定要往哪座山頂爬。每次選擇修哪個問題、測哪個版本，就是在決定產品要往什麼目標優化。
• 20:34 例：若只在乎讓產品更便宜，就會去修所有異常花費問題並盡量最佳化
  ↳ 例如只在乎省錢，就會去修所有花費異常的問題，拼命壓低成本。目標不同，修的東西也就不同。
• 20:34 這些選擇決定了呈現給使用者的產品理念
  ↳ 這些選擇一次次累積下來，就成了使用者感受到的產品理念和個性。
• 20:34 A/B test 結果不明確時，要不要上線仍是人類的決定，在 Replit 常常由講者本人決定
  ↳ A/B test 結果模稜兩可時，要不要上線還是由人拍板，在 Replit 常常就是講者本人決定。
• 21:05 結論：評估不該只是上線前最後一道檢查、不只是一個 boolean flag，而是讓你每天推出更好 agent 的引擎
  ↳ boolean flag 是只有「是／否」兩種狀態的開關。講者的結論是：評估不該只是上線前打個勾，而是每天推動 agent 進步的引擎。
• 21:36 Hannah 是 Anthropic Applied AI 團隊成員，和 Michele 一起合作 Replit Agent 及他們用 Claude 做的東西
  ↳ Hannah 是 Anthropic 應用 AI 團隊的成員，和講者 Michele 一起合作 Replit Agent，以及他們用 Claude 做的其他產品。
• 21:36 Vibez 曾被用來給 Anthropic 正在測試的研究模型提供回饋
  ↳ Vibez 是 Replit 公開給大家使用（開源）的一套評估方式，也曾被拿來替 Anthropic 還在測試中的研究模型提供意見。
• 22:06 為何開源 Vibez：講者認為應盡量回饋社群，公開評估對大家都有好處，能做出更好的模型、agent 與產品
  ↳ 為什麼要開源？講者認為應該盡量回饋社群。評估方式公開，大家都能拿去做出更好的模型、agent 和產品。
• 22:37 講者不相信在評估上競爭，他來自研究背景，認為一切應該開放；邀請大家一起合作 Vibez
  ↳ 講者不認為大家該在評估上互相競爭。他出身研究界，習慣一切公開，所以邀請大家一起改進 Vibez。
• 22:37 過去演講時多次倡議社群來做，最後發現得自己動手做
  ↳ 他以前演講時多次呼籲社群來做這件事，後來發現只能自己動手。
• 23:38 建議一：若 6 個月前試過這種做法卻沒有回報而放棄，應該再試一次
  ↳ 建議一：如果半年前試過這種讓 AI 自動分析、自動修正的做法，卻因為沒效果而放棄，現在值得再試一次。
• 23:38 長 context、擅長推理大量內容的模型，讓你幾乎可以把 agent 的整條 trace 丟進 Opus，得到相當細緻的回饋
  ↳ context 是模型一次能讀進去的內容。現在的模型讀得多又會推理，幾乎可以把 agent 的整段 trace 丟給 Opus，拿到相當細的回饋。
• 24:08 建議二：盡量收集 agent 及其執行環境的所有訊號
  ↳ 建議二：盡量收集 agent 本身和它執行環境的所有訊號，資料越完整，越好判斷問題出在哪。
• 24:08 Telescope 的訊號不只來自 trace，也包含產品內收集的回饋
  ↳ Telescope 用的資料不只有 trace，也包括使用者在產品裡直接給的回饋。
• 24:39 有回饋表單：使用者抱怨時，同時有使用者觀點、agent trace、DataDog 平台監測資料，全放進 context 更能找出問題
  ↳ 使用者從回饋表單抱怨時，可以把使用者的說法、agent 的 trace、DataDog 的系統數據一起交給模型，比較容易找出原因。
• 24:39 Hannah 補充：單一 trace 很難除錯，分群並結合其他訊號才能得到可行動的資訊
  ↳ Hannah 補充：只看單一 trace 很難抓出毛病，要先分群、再搭配其他訊號，才能得到真的能動手改的資訊。
• 25:09 分群也讓 agent 開發者不那麼不知所措：使用量大時回饋多到難以負荷
  ↳ 分群也讓開發者不會被淹沒。用的人一多，回饋多到看不完，分群能先幫你整理好。
• 25:09 大量回饋是好訊號，代表大家在乎你的產品，但很難分辨重要與無關緊要的事
  ↳ 回饋多是好事，代表大家在乎你的產品。難的是分辨哪些重要、哪些可以先放著。
• 25:39 每天都出現、規模大、量多的 cluster 要優先修；因 agent 非確定性，長尾問題永遠存在
  ↳ 判斷原則是：每天都出現、規模大、數量多的群先修。agent 本來就不確定，長尾問題永遠修不完。
• 25:39 Hannah 認為 AI engineer 的品味非常重要，並詢問團隊如何培養
  ↳ Hannah 認為 AI engineer 的品味（判斷怎樣才是好產品的眼光）非常重要，於是問 Replit 團隊怎麼培養。
• 26:10 品味是隨時間培養的：一年半前剛推出時 agent 弱很多，比較像求生遊戲，只求勉強能用
  ↳ 講者說品味是慢慢累積的。一年半前剛推出時 agent 弱很多，那時像在求生存，能動就好，沒什麼好挑。
• 26:10 現在 agent 很強、選擇很多，品味應該和實際使用者族群一致
  ↳ 現在 agent 變強了、能做的選擇也多了，品味就要對準真正在用產品的那群人要什麼。
• 26:40 若做給軟體開發者的 agent，團隊每天約 80% 的選擇可能會完全相反
  ↳ 如果產品是做給軟體工程師用的，團隊每天大約八成的決定可能都會完全相反。
• 26:40 Replit 人人都很懂技術，但產品給的是從沒寫過程式的知識工作者，要記得使用者和自己不同
  ↳ Replit 的員工個個懂技術，但產品主要是給從沒寫過程式的上班族（知識工作者）用，要一直提醒自己：使用者跟我們不一樣。
• 27:11 現場的 Peter 是 Vibrent（字幕原文）的作者之一
  ↳ 講者提到現場的 Peter 是「Vibrent」（依字幕原文）的作者之一，這段影片沒有再多說明。

在 Replit 的 Telescope 迴圈中，重跑 By bench 時，分數下降多少會被判定為不好的修改？