打造可靠的 agent:以 eval 為先的方法

TL;DR

• 問題設定:企業與受監管產業的 agent,錯 5% 就是責任風險——客戶發票上的錯誤數字、法遵申報裡的錯誤陳述、寫壞一個下游有上千系統依賴的 production 資料庫。她引用當天早上被提到的 MIT 研究:95% 的 AI pilot 進不了 production。
• 評估對象變了:不是評模型輸出的文字,而是評一個隨時間展開、與真實環境互動的系統——模型 + prompt + 工具 + orchestration + 環境(production API、知識庫、檔案、企業流程)。要清楚區分哪些元件可調、哪些是給定的。
• 四層 eval 框架:L0 商業成果(北極星 KPI)、L1 任務成功(黑盒,迭代的操作核心)、L2 元件評估(打開黑盒看子任務)、L3 診斷(解釋 L1/L2 為何失敗)。常見失敗模式:團隊花太多時間優化 L2/L3,卻沒讓 L1 一起變好。
• 設計原則:能用確定性演算的就不要交給 agent。油井 casing 案例中,agent 從不計算任何數字、也不驅動流程,所以數值保真度依設計即為 100%,評估問題被壓縮成「問答品質 + 文件完整正確與否」。
• eval 是活資產、也是護城河:模型可以隨時換掉,eval suite 留下來——這才是客戶投資的 IP,讓他們能一路搭上基礎模型進步的浪。

重點整理

為什麼企業 agent 的「大致正確」不夠(約 00:28–00:30)

Scale 的使命是為世界上最重要的一些決策打造可靠的 AI 系統。她點出這件事本質上的張力:你用的是本質隨機的技術,卻要交付確定性的商業結果。

支撐這個觀點的背景:90% 的 frontier labs 使用 Scale 的 data engine;他們替政府(含美國國防部與 Defense Innovation Unit)以及醫療、金融、電信等受監管產業的企業建 AI 應用。與日常生產力用的 consumer/prosumer agent 不同,這些場景可靠性就是一切——例如與 Mayo Clinic 合作把 agent 帶進病患照護,目標字面上就是救命,沒有出錯空間。

她引用當天早上提到的 MIT 研究:95% 的 AI pilot 沒能進到 production。在企業情境下,agent 即使只錯 5%,那也是責任問題:客戶發票上的錯誤數字、法遵申報中的錯誤陳述、寫壞一個上千個下游系統依賴的 production 資料庫。

Scale 對每個上線 agent 有 8 道工程關卡(涵蓋資料隱私、正確的存取控制與 authZ/authN 等);本場專注在其中的「嚴謹 evals」。

評的是系統,不是模型(約 00:30–00:31)

相對於模型 benchmark,企業 agent 的評估有個本質轉變:agent 是一種系統能力,它隨時間展開、在真實環境中互動。你評的不再是模型與它輸出的文字,而是端到端系統:模型、prompt、工具、orchestration,以及環境——在企業裡環境包含 production API、知識庫、各種檔案、以及該企業既有的商業流程。

她強調一個實用的區分:哪些元件可以調、哪些是給定的;好的 eval 設計會把兩者分開。

四層評估框架(約 00:31–00:33)

框架的核心是把商業對齊、黑盒評估、可除錯性三件事分層放,彼此保持獨立但因果相連:

• L0 商業成果:北極星 KPI,agent 實際帶來的價值——結案率、每張工單成本、分析師省下的時間。
• L1 任務成功:把 agent 當黑盒,只問任務是否完成。例如:退款金額是否正確?案件記錄的最終狀態是否正確?這是 agent 評估的操作核心,也是團隊實際迭代、試不同做法、看分數變化的那一層。
• L2 元件評估:打開黑盒看子任務——抽取相關事實、選對欄位、產生正確的記錄變更。
• L3 診斷:除錯與最佳化所需的「為什麼」,解釋 L1/L2 為何失敗。

四層形成一條鏈。她點名一個常見失敗模式:團隊花大量時間優化 L3 診斷與 L2 元件,卻沒有確認 L1 也跟著改善。

案例一:油井 casing 設計(約 00:33–00:36)

Scale 協助一家大型石油公司改善油井設計,其中包括 casing(套在井外的鋼管)設計。原本流程是數週的循環:工程師跑上百次模擬、翻閱埋在 PDF 與各種資料庫裡的標準規範。

Agent 的設計刻意分成兩塊:

1. 確定性核心:工程師仍然主導,用可信的物理模擬器跑模擬;結果以確定性方式對照公司標準檢查;最終由工程師審核與批准安全的井設計。
2. Casing design agent:跟在工程師旁邊,從上百次模擬中抽取正確的 context,回答工程師提問並附上逐條引用(claim-level citation),最後產出井設計文件,也就是 Basis of Design(BOD)。

關鍵設計決策:agent 從不計算任何數字,也不驅動任何流程——因此數值保真度依設計即為 100%。整個 eval 問題於是被壓縮成:agent 回答工程師問題的品質如何?產出的 BOD 是否完整且正確?

套回四層框架: - L0 = 每年由領域專家(SME)簽核的 BOD 數量 - L1 = agent 的設計與回答是否完整、正確、可直接進審查 - L2 = 檢索與 context 管理 - L3 = 術語、grounding 保真度、recall

作法:與 SME 一起建 eval、校準 grader;由於 SME 的時間永遠是瓶頸,他們用合成方式擴充 SME 的樣板,再請 SME 驗證。在 L1 正確性上做 hill climbing 的成果:術語精確度 83% → 100%、主張精確度(claims precision)68% → 90%。這贏得了客戶端井設計工程師的信任,目前進入有限的 production rollout——繼續蒐集 production trace、評分、演進 eval set、再改進 agent。

她順勢帶出整場最強的一句主張:eval 是活資產,而且是最持久的資產。模型可以換、agent 的設計可以換,eval suite 留下來持續驗收——這是客戶真正投資的 IP 與護城河,讓他們能一直搭上基礎模型進步的浪。

案例二:財務盡職調查(約 00:36–00:37)

與一家四大會計/專業服務事務所合作,建了一個財務盡職調查 agent,把分析師取得經人工驗證的洞察所需的時間從 4–6 週壓到 2 天。同樣套用四層框架,L0 定義為「取得人工驗證洞察的總時間」,同樣經過建 eval、迭代 L1 正確性,同樣走向有限 production rollout。她補了一句實務觀察:eval 資料量不足往往是最大瓶頸之一,而有限的 production rollout 正是補資料、演進 eval suite 的好機會。

流程化與收尾原則(約 00:37–00:39)

Scale 內部對每個 agent 都會開一次 eval design review,由 forward deployed engineering 團隊與企業客戶及政府單位共同進行;他們用一張 performance maturity matrix 當作每個 agent 的 eval 計分卡,計分卡沒有全綠就不出貨。

收尾原則: - 你評的是系統,不只是模型。 - 用混合 grader:能確定性判斷的就確定性判斷,必要時才用模型當 grader,校準與高風險場景則用人工審查。 - 把 eval 當活資產,隨時間長大。 - 「evals first is how mostly right becomes production-ready.」

金句

"You have technology that is inherently stochastic, and you are trying to deliver deterministic business outcomes using this."(約 00:28)

一句話說完企業 AI 的核心張力,也是整套 eval 框架存在的理由。

"The agent never computes any number or drives any workflow. So, by design, numerical fidelity is 100%."(約 00:35)

最好的可靠性設計不是評出來的,是架構上讓錯誤不可能發生;剩下的才交給 eval。

"Evals are living assets … they are the most durable asset."(約 00:36)

模型會被換掉,eval suite 不會——這是她給企業客戶的核心建議。

"Evals first is how mostly right becomes production-ready."(約 00:39)