Ara Khan：評估雖有缺陷仍值得使用
Ara Khan：評估雖有缺陷仍值得使用
核心衝突：客觀指標 vs. 直覺感受
AI 開發常常在評估（evals）上分成兩個錯誤陣營：客觀指標陣營，直接把基準分數（如 ELO 或 SweetBench）當真；以及直覺/氛圍陣營，完全拋棄數字，只憑主觀感受判斷。
兩種做法都不足。客觀基準可能被實驗室操弄，以取得高分卻未提升實際效用；而只依賴「氛圍」則無法系統化改進。有效的路徑在於兩者之間：將評估視為絕對真理的對立面，而是作為迭代開發的關鍵啟發式工具。
解讀外部評估的啟發式方法
在評估模型實驗室或其他公司提供的基準時，開發者應套用以下三個主要啟發式，以免被行銷數字誤導：
1. 將實驗室評估視為近似值
不要把模型實驗室（例如 GPT 或 Claude 版本）的數字當作「神諭」般的絕對真理。雖然它們通常是相當不錯的近似值，但應以辨識的態度使用，而非作為優越性的最終證明。
2. 穩定性優先於搶先採用
在快速變動的 AI 版圖中，「最佳」模型每隔數月就會更換。試圖在新模型剛發布時立即切換，會消耗過多的心智資源。建議的做法是讓新模型的熱度稍降，等待數週後再將其納入生產工作流程。
3. 尋找問題特定的基準
通用基準往往無法反映真實世界的效用。例如，SWE‑bench 曾是編碼代理的標準，但最終變得「飽和」——模型分數過高，以致基準無法區分品質層次。開發者應尋找與自身問題領域高度相似的評估（例如購物、基礎建設或特定程式任務）。
為程式代理實作代理式評估
評估代理與評估單回合 LLM 回應本質上不同。因為代理可以多回合交互、使用各種工具、走不同路徑，其答案空間實際上是無限的。
向真實任務的轉變
早期許多評估聚焦於簡單的學術題目，例如實作 Fibonacci 數列。這類測試無法映射到專業軟體工程。為了解決這個問題，Cline 團隊採用了 Terminal Bench（由 Stanford ALOT Institute 開發），其中包含 89 個真實的軟體工程任務，涵蓋資料庫問題、競爭條件與前端錯誤等。
代理式評估流程
與確定性測試不同，代理式評估允許代理長時間運行（有時 30‑45 分鐘），執行網路搜尋、安裝函式庫、編輯檔案等操作。成功與否以 確定性單元測試 為依據，檢查最終輸出是否能執行並通過所需測試。
需要追蹤的關鍵指標
為了在品質與成本之間取得平衡，開發者應追蹤：
- 回合數（Turn count）：代理執行了多少次迭代。
- 工具呼叫次數（Tool calls）：使用了多少工具。
- Token 使用量（Token usage）：整體執行成本。
- 執行時間（Execution time）：整體牆時（wall‑clock）耗時。
建置穩健的評估基礎設施
要有效執行評估並避免任務之間的相互干擾，必須確保隔離性。
- 容器化：每個評估任務應在獨立容器中執行，擁有自己的相依性與環境，防止任務互相破壞環境。
- 平行化：順序執行評估可能需要數小時。使用 Modal 等基礎設施，可在平行且容器化的環境中執行，顯著縮短回饋迴路時間。
迭代改進循環
評估讓開發者從哲學式猜測走向工程實作。透過分析「失敗組合投資組合」，開發者可以將錯誤歸類為廣泛的類別（例如「無法讀取檔案」、「推論錯誤」、「安裝迴圈」）。
三個改進區域
- 區域 1：明顯缺陷。修復根本性錯誤，如
read_file工具損壞或檢查點失效，使代理能正常運作。 - 區域 2：爬坡優化。這是主要的優化領域。開發者精進提示工程、調整工具定義、優化重試邏輯，以提升代理解決問題的哲學方法。
- 區域 3：危險區。過度擬合的風險。開發者必須避免僅為提升基準分數而加入特定 hack，這會削弱一般表現。
三向對齊
成功的代理表現需要三個要素的對齊：
- 模型：底層 LLM 的能力。
- 框架（Harness）：代理的腳手架與工具實作。
- 問題：實際要解決的任務。
即使模型再優秀，若框架寫得不好也會失敗。迭代評估有助於辨識失敗是源於模型智慧不足，還是代理框架的缺陷。
摘要： Ara Khan 解釋了為何 AI 代理開發者應該超越「氛圍」感受，使用結構化的評估（即使它們有缺陷），以迭代提升代理效能與工具可靠性。
標題： Ara Khan：評估雖有缺陷仍值得使用