大規模評估與改進 Replit Agent（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這支影片是 Replit 分享他們怎麼天天檢查、改進自家會寫程式的 AI。重點是 benchmark（用固定題目比較 AI 能力的標準測驗）量不出「做出來的 app 能不能用」，所以他們自己設計了新測驗，再搭配真實使用數據。想知道 AI 工具的好壞怎麼評估、自己用 AI 做東西要注意什麼，這支很值得看。

• 00:24 講者 Mikael Cata 是 Replit 總裁兼 AI 負責人，主題是 Replit Agent 的日常大規模評估與改進
  ↳ 講者 Mikael Cata 是 Replit 總裁，也負責 AI。這場談的是怎麼每天大量檢查 Replit Agent（會自己動手寫程式的 AI 助手）的表現，再拿結果去改進它。
• 00:24 Replit 定位為給知識工作者的 vibe coding 平台（字幕寫 back-coding），已處理這個問題將近 2 年
  ↳ Replit 的定位是讓一般上班族也能 vibe coding 的平台：用說話的方式講你要什麼，AI 就幫你做出程式。這件事他們已經做了快兩年。
• 00:55 Replit 情境比一般更極端：使用者只給自然語言需求，不指定框架、不寫測試，期待 agent 跑完就能用
  ↳ 他們面對的狀況比一般寫程式更難：使用者只說「我要一個訂位系統」，不指定用什麼技術，也不寫用來檢查程式對不對的測試，卻期待 AI 做完就能直接用。
• 00:55 因此過去為軟體開發者設計的評估方式與 agent 建構方式必須根本改變
  ↳ 以前的評估方法和 agent 設計，都假設使用者是會自己把關的工程師。現在對象換成非工程師，這些做法就得從根本重新想，小修小補不夠。
• 01:26 挑戰：模型持續快速變化，演進速度比一年前更快，團隊始終站在「變動的地面」上
  ↳ 背後的 AI 模型一直在換代，速度還比一年前更快。團隊就像站在會動的地上，昨天調好的東西，換了模型之後可能就不準了。
• 01:56 system prompt、user prompt、tool 定義也常改動（新增、簡化），每天有多次 Replit Agent 發布，面對數百萬使用者
  ↳ system prompt 是預先寫給 AI 的工作守則，user prompt 是使用者輸入的需求，tool 是 AI 能呼叫的功能。這些常常在改，Agent 一天發布好幾次，影響數百萬人。
• 02:26 傳統評估：跑一次產生單一分數，由人判斷 harness 或模型是進步還是退步、是否要再做 post training
  ↳ 傳統做法是跑一次測驗拿一個分數，由人判斷 harness（包住模型、讓它實際做事的機制）或模型是進步還是退步，要不要再做 post training（模型訓練完之後的追加調教）。
• 02:26 講者主張轉向「持續性評估」；production 每天產生數百萬筆 traces，裡面有大量可萃取的價值
  ↳ 講者主張評估不能偶爾考一次就算，要一直持續做。production（正式給使用者用的環境）每天產生數百萬筆 traces，也就是 agent 每次做事的完整紀錄，裡面有很多線索可以挖。
• 02:56 Replit 結合離線評估（類似 SweetBench 等知名 benchmark）與依據系統實際使用的線上評估
  ↳ Replit 兩種都用：offline eval 是像 SweetBench（業界常用的程式能力測驗）這種固定題目的考試；online eval 則是看系統在真實使用中的表現。
• 02:56 評估應做到三件事：優化使用者真正在意的事、立即指出哪裡壞了、告訴團隊下一步該改進什麼
  ↳ 好的評估要做到三件事：分數要反映使用者真正在乎的結果；東西壞了要馬上指出壞在哪；還要告訴團隊下一步該改哪裡，不能只丟一個數字。
• 03:26 系統有兩大支柱；第一個是傳統離線 benchmark，通常在發布新版 agent 前使用
  ↳ 整套系統有兩根支柱。第一根是傳統的離線 benchmark，通常在新版 agent 發布前先跑一輪。
• 03:59 離線 benchmark 像布林旗標／守門員：若有重大退步就停止發布，無變化或進步才繼續
  ↳ 離線測驗像守門員，只回答「能不能放行」：分數明顯退步就擋下、不發布；持平或進步才放行，就像一個是或否的開關。
• 03:59 第二個支柱是線上：做大量 A/B 測試，並把 production traces 分群以取得洞見
  ↳ 第二根支柱在線上：大量做 A/B 測試（使用者分成兩組，一組用新版、一組用舊版，比較結果），也把真實的 traces 按相似程度分群，從中找出問題。
• 04:29 線上支柱在發布後運作，逼團隊盡快反應；循環是：反思兩邊結果→改程式→跑 eval→重複，Replit 每天都跑這個循環
  ↳ 線上支柱在發布之後運作，一出問題就逼團隊盡快處理。循環是：看兩邊的結果→改程式→再跑評估→重來一次。Replit 每天都在跑這個循環。
• 05:00 SweetBench、HumanEval 對產業很重要，但流程相同：套 patch 到 repo、跑測試、測試通過就得分
  ↳ SweetBench 和 HumanEval（另一個常見的程式測驗）對產業很重要，但考法一樣：把 AI 寫的修改（patch）套進現有程式庫（repo），跑事先寫好的測試，過了就得分。
• 05:30 這不符合 vibe coding：使用者不寫測試、常從空的 code base 開始，沒有可套 patch 的情境
  ↳ 這種考法不適合 vibe coding：使用者不寫測試，而且常常從一片空白開始做 app，根本沒有現成的程式庫可以套修改。
• 05:30 真正要衡量的是「app 有沒有做到使用者要的」，SweetBench 與此存在 functional correctness gap
  ↳ 真正該量的是「做出來的 app 有沒有做到使用者要的」。測試全過不代表 app 真的好用，這中間的落差叫 functional correctness gap（功能正確性落差）。
• 05:30 當場發布 ByBench：端到端 vibe coding 的新公開 benchmark，團隊花了數個月打造
  ↳ 講者當場發布 ByBench：一份新的公開 benchmark，專門測從需求到做出能用的 app 這一整段 vibe coding 流程，團隊花了好幾個月才做出來。
• 06:02 輸入只有一份 PRD（描述如何建構 app 的長 prompt）；取自 Replit 實際使用的 20 筆真實 traces，而非合成資料
  ↳ 題目只給一份 PRD（產品需求文件，這裡指描述 app 該怎麼做的長篇指令）。題目取自 Replit 上 20 筆真實使用紀錄，不是人工編出來的假資料。
• 06:02 PRD 是純英文規格，沒有任何實作限制
  ↳ PRD 只用一般英文寫要什麼，不規定用哪種程式語言或技術。怎麼實作由 AI 自己決定，就跟真實使用者的情況一樣。
• 06:32 有一個 harness 從空 repo 端到端建出可運作的 app
  ↳ 測驗裡有一套 harness，讓 AI 從空的程式庫開始，一路做到產出一個真的能跑的 app，從頭到尾自己完成。
• 06:32 關鍵：不用人工評分，而是打造自動化 evaluator，讓 benchmark 從每週跑一次變成每次 PR merge 都能跑
  ↳ 關鍵是不靠人工打分，而是做了自動評分程式。這樣測驗就能從一週跑一次，變成每次 PR merge（把一批程式修改正式併入主程式）都跑一次。
• 07:03 評估協定：輸入＋實作策略＋一組評估；提出五種組合，但講者說還能自行設計更多
  ↳ 每一種評估由三個部分組成：輸入什麼、用什麼方式實作、怎麼評分。講者提出五種組合，也說大家可以自己搭出更多種。
• 07:03 最基本組合：輸入 PRD，single shot 從零建構出 app
  ↳ 最基本的一種：給 PRD，讓 AI single shot（一次做完，沒有第二次機會）從零做出整個 app。
• 07:35 by bond ref：從已可運作的參考實作出發，在上面加新功能
  ↳ by bond ref：先給一個確定能用的標準版 app（參考實作），讓 AI 在上面加新功能，看它能不能在穩固的基礎上繼續擴充。
• 07:35 by bond vibe：從 agent 做出的 MVP 出發再加功能，即 X 上說的「slop on slop」（未驗證的 agent 程式上再疊 agent 程式）
  ↳ by bond vibe：先讓 AI 自己做出 MVP（最陽春的可用版本），再往上加功能。這就是 X（前身是 Twitter）上說的 slop on slop：在沒驗證過的 AI 程式上再疊 AI 程式。
• 08:06 幾個月前推出的 Agent 4 會隱藏任務拆解、平行跑 agents、合併 patches 的複雜度
  ↳ Replit 幾個月前推出的 Agent 4，會把工作拆小、同時派好幾個 agent 平行處理，再把大家的修改合併起來。這些複雜的過程都在背後進行，使用者看不到。
• 08:06 對應組合：輸入 PRD→任務拆解→平行執行→合併後再跑評估；平行＋合併情境對一般 coding agent 更具挑戰
  ↳ 對應的測法是：給 PRD→task decomposition（拆成小任務）→平行執行→合併後再評分。好幾個人同時改再合併，容易互相打架，對一般 coding agent 更難。
• 08:36 論文另有其他構想，例如從有 bug 的 app 開始加功能，看 agent 多難讓它正確運作
  ↳ 論文裡還有其他點子，例如先給一個有 bug 的 app，再要求加新功能，看 agent 得花多大力氣才能讓它正常運作。
• 08:36 最大的難點與投入最多心力之處是「如何評分」
  ↳ 整個專案最難、也最花心力的是「怎麼評分」。每個 app 的做法都不一樣，很難用同一把尺去量。
• 09:06 前一版 agent 時期打造了自動化 app 測試功能，對 app 本身一無所知
  ↳ 前一版 agent 的時候，他們就做了自動測試 app 的功能。這個測試者事前對 app 完全不了解，就像第一次打開它的使用者。
• 09:06 因使用者可自選語言與框架，evaluator 必須完全不依賴實作方式（agnostic）
  ↳ 使用者可以自己選語言和框架，所以評分程式必須是 agnostic 的，也就是不綁定任何特定寫法，不管 app 用什麼技術做都能測。
• 09:36 evaluator agent 流程：讀 code base→開瀏覽器連到 app→依自然語言測試計畫逐步操作（如開 admin dashboard、登入、點 toggle）
  ↳ 評分用的 agent 會先讀程式碼，再開瀏覽器連上 app，照著一份用白話寫的測試步驟實際操作，例如打開管理後台、登入、點某個開關。
• 09:36 任何步驟失敗就彙整起來產生分數，跑完整份測試計畫後判定分數好壞
  ↳ 只要有任何一步失敗就記下來。整份測試步驟跑完之後彙總出分數，判斷這個 app 做得好不好。
• 10:08 SweetBench 的範圍固定（已知 repo 與任務）；ByBench 是完全 green field，所以花了數個月
  ↳ SweetBench 的範圍是固定的，用已知的程式庫和已知的任務。ByBench 是 green field（從零開始，沒有既有程式可依循），做出來的 app 什麼樣子都有可能，所以花了好幾個月。
• 10:08 整個 benchmark 開源於 bybench.ai，論文將在幾週後的 AI 與 agentic 系統研討會發表
  ↳ 整套 benchmark 已經開源（公開讓任何人免費使用），放在 bybench.ai。相關論文幾週後會在一場 AI 與 agent 系統的研討會上發表。
• 10:38 專案負責人兼論文第一作者 Peter 在現場，可會後找他聊細節
  ↳ 專案負責人、也是論文第一作者的 Peter 在現場，想知道細節的人可以會後直接找他聊。
• 10:38 結果一：frontier 模型與 open weights 模型之間差距將近 2 倍
  ↳ 第一個結果：在 ByBench 上，frontier 模型（各大廠最頂尖的模型）和 open weights 模型（模型檔公開、任何人都能下載使用的模型）差距將近兩倍。
• 11:09 開源理由：各模型廠商都在爬特定 benchmark，希望整個社群（開放與封閉權重）一起採用，推動 vibe coding 整體進步
  ↳ 開源的原因是各模型廠商都在拚特定測驗的分數。他們希望開放和封閉模型的整個社群都一起用 ByBench，讓大家在 vibe coding 上一起進步。
• 11:09 結果二：多數模型延伸「自己寫的程式碼」表現更差，slop on slop／by bond vibe 是最難的情境
  ↳ 第二個結果：大多數模型在延伸「自己寫的程式」時表現更差，所以 slop on slop（也就是 by bond vibe）是所有情境裡最難的。
• 11:39 因此講者主張每次新增功能之間都要有測試步驟，否則會建在不穩的地基上，最終 app 會失敗
  ↳ 所以講者主張，每加一個功能之後都要先測試。不然就是在不穩的地基上一直往上蓋，最後 app 一定會出問題。
• 12:09 離線與線上的差別在訊號量：離線目前約 20 個 app；線上 Replit Agent 每天收集數百萬 sessions
  ↳ 離線和線上最大的差別在資料量：離線測驗目前大約只有 20 個 app，線上的 Replit Agent 每天卻收集到數百萬個 sessions（使用者一次完整的使用過程）。
• 12:09 開源也是為了歡迎社群貢獻更多 app、更難的 prompt，讓 benchmark 越來越難
  ↳ 開源也是為了歡迎社群貢獻更多 app 和更難的題目，讓這份測驗越來越難，持續有參考價值。
• 12:40 線上 sessions 很有價值：反映使用者真實行為、完全非腳本化
  ↳ 線上 sessions 特別有價值，因為那是使用者真實的做法，完全沒照劇本走，會出現測驗題想不到的狀況。
• 12:40 大量 A/B 測試是讓團隊保持誠實的方式，因為 ByBench 只說明部分情況；建議 agent 開發者盡早投資 A/B 測試基礎設施
  ↳ 大量做 A/B 測試能讓團隊不自欺欺人，因為 ByBench 只看得到一部分。講者建議做 agent 的團隊，及早投資 A/B 測試需要的系統。
• 13:10 在 agent 中建了大量 instrumentation 與指標，例如偵測異常 span、agent 執行是否超過預期時間
  ↳ 他們在 agent 裡埋了大量 instrumentation（監測用的記錄點）和各種指標，例如找出不正常的 span（某一段執行步驟的紀錄），或偵測 agent 跑得比預期還久。
• 13:10 持續追蹤使用者情緒：對每則收到的 prompt 做 sentiment analysis，判斷使用者是否變得沮喪
  ↳ 他們也持續追蹤使用者的情緒：對每則收到的 prompt 做 sentiment analysis（自動判斷文字帶的情緒），看使用者是不是越來越沮喪。
• 13:41 Replit 特有訊號：使用者將 app 發布分享給同事或公開，是很強的正向訊號
  ↳ Replit 特有的訊號：使用者把做好的 app 發布、分享給同事或公開出去，代表對方覺得真的能用，這是很強的正面訊號。

根據講者分享的 ByBench 結果，哪一種情境對多數模型最具挑戰性？