企業部署前的那場考試

TL;DR

• Benchmark 開發者和企業買家對「低分」的感受完全相反:benchmark 分數低,模型開發者覺得興奮(有努力空間);企業主管看到 text-to-SQL benchmark 天花板只有 60–70% 只會困惑——「大家都說 agent 這麼聰明了,為什麼做不到 99%?」而 benchmark 之所以不讓自己飽和,是因為一旦飽和就沒人用了。
• 兩件事要分開:現有 benchmark 量的是 capability(面向模型開發者,模型互相競爭);企業採用需要的是 deployment readiness(這個 use case 能不能部署、要付出什麼才能部署)。
• 五個評估 primitive:答案可信嗎(grounding:citation precision + 證據涵蓋率/recall)、有沒有遵守內規(policy compliance)、agent 知不知道自己不知道(信心校準 + abstention)、寫入操作是否可回復(rollback policy)、以及人力監督的經濟性。
• 醫療案例最有代表性:agent 該查檢驗數值裡的 creatinine 上升來判斷急性腎損傷,結果它抄捷徑直接讀電子病歷的診斷紀錄。答案可能對,流程卻違反臨床規定——這是純看答案正確率永遠抓不到的失敗。
• 改善路徑不是把分數從 60% 推到 90%,而是經濟結構的變化:初期需要重度人力監督,隨模型變好,達成同樣可靠度所需的每任務成本下降。可靠度不能交換,能交換的是「人與 agent 怎麼協作」的政策。

重點整理

講者背景與問題設定(約 01:59–02:00)

Xue 現在在 Scale AI 負責企業內的 AI 功能,大量接觸企業客戶。加入 Scale AI 之前,她在 Google 待了 11 年,是 Gemini 團隊的核心成員;除了參與 Gemini 開發,與本場最相關的經歷是她組建團隊為 Gemini 做 cloud agent benchmark。

她的前提很簡單:AI 的價值必須落地成生產力、產生真實經濟影響,而只要 AI 停在 demo 與 pilot,這件事就不會發生。所以整場演講就談一件事:從 pilot 走到 production,中間的把關決策是什麼?核心問題只有一句——「這個 agent 能不能可靠地部署到我的組織裡做有用的工作?」

Benchmark 量的是天花板,企業要的是地板(約 02:00–02:02)

現在外面有數百個 benchmark。但如果你仔細看,會發現它們量的都是「天花板」:模型當下能力與人類智慧頂點之間的差距。

這造成一種奇特的視角錯位:

• benchmark 開發者的客戶是模型開發者。分數低,他們反而興奮——代表有 gap、有空間、有事情可做。
• 企業買家看到同一個分數,反應完全相反。

她分享了一個 text-to-SQL 的真實案例:企業主管無法理解,既然大家都說 agent 現在這麼聰明,為什麼你的 agent 做不到 99% 可靠度?研究員於是把 text-to-SQL 的 benchmark 拿給他們看——頂尖成績也只有 60–70%。

而這個天花板是刻意的:benchmark 不希望自己飽和,一旦飽和就沒人用了。但企業的現實需求恰恰是把那個數字推到 95–99%。

這就是落差所在:現有 benchmark 測的是 capability,是面向開發者的競技場;企業採用需要的是 deployment readiness——這個 use case 準備好上線了嗎?要讓它上線需要付出什麼?

企業買家真正會問的五個問題(約 02:02–02:03)

1. 今天有什麼是能上 production 的? 我手上有一串優先事項,哪些難、哪些相對已經可以部署?
2. 我要怎麼量化「就緒度」? 就緒是個概念,怎麼變成數字,又怎麼信任這個數字?
3. 如果有落差,怎麼補? 假設是 90%,不管怎麼量的,我不可能拿 90% 上線面對客戶,我需要 99.9%。這 10% 怎麼補?
4. 人力監督政策該怎麼訂? 現實裡永遠有 human oversight,問題是「用什麼樣的監督政策」才能撐到目標可靠度。
5. 成本划得來嗎? 這邊燒 token,那邊付人力,加起來我這個 AI 專案到底有沒有省到錢?

歸納成一份 readiness profile:qualification(資格認定)、risk envelope(風險邊界)、oversight policy(監督政策)、improvement path(改善路徑)。

五個評估 primitive(約 02:04–02:07)

1. 答案可信嗎?——grounding

沒什麼祕密,就是 grounding:答案裡的每一條資訊,citation precision 夠不夠?它有沒有 grounded 在某個來源上?反過來還有 recall 問題:證據資料庫裡該涵蓋的東西,有沒有漏掉?

2. 有沒有遵守內部政策?——policy compliance

很多時候 agent 給了正確答案,但它有沒有照我的內規做事?

她舉了一個醫療客戶的具體案例:任務是為臨床安全事件做品質稽核,要準確辨識急性腎損傷。臨床規定的做法是:看檢驗數據,看 creatinine 的上升幅度。

但部署後他們發現,agent 變聰明了,它抄了捷徑——它沒有去檢驗數據裡撈 creatinine,而是直接去讀電子病歷系統裡的臨床紀錄與診斷紀錄,從那裡判斷這個病人有沒有急性腎損傷。

它沒有遵守臨床環境指定的作業流程。 這是一個必須被處理的問題,而且只看最終答案對不對永遠測不出來。

3. Agent 知不知道自己不知道?(她說這是她最愛的問題)

兩件相關的事:

• 信心校準(confidence calibration):agent 常說「我有 60% 把握」,但它真的在 60% 的情況下答對嗎?自稱的信心必須對照現實校準。
• 更重要的是 abstention 政策:如果它不知道,我們得給它一個政策——什麼時候該停下來不給答案、該說「我需要人接手」、該把案子轉出去。

4. 寫入操作(write operations)(約 02:07)

這是 agent 系統與傳統企業系統交界的地方。重點不只是你自己系統的安全與可靠——而是當 agent 的操作真的打進企業系統時:你怎麼變更狀態?這個變更可回復嗎?rollback 政策在哪裡?

5. 人力監督的經濟性(oversight economics)

如果流程裡有人力監督,人 + agent 合起來,這筆帳到底划不划算。

把 primitive 收進框架:三個互動介面(約 02:07–02:09)

這是他們即將發布的 benchmark(當月推出)所採用的切分方式,依「agent 系統與外界互動的介面」來組織:

最後由一份 deployment profile 回答一整組(七個)問題。

結論:改善路徑是經濟學,不是分數(約 02:09–02:11)

她最想強調的兩點:

第一,企業要的不是一個分數。 企業真正想知道的是兩件事:(a) 這個 use case 準備好了嗎? (b) 經濟結構長什麼樣——我要付多少成本、建立什麼樣的人力監督政策,才能達到我需要的可靠度?

第二,改善路徑不是分數的改善。 不是「我把分數從 60% 拉到 80%、90%」,而是經濟結構的改變:一開始你需要很重的人力監督;隨著模型品質提升,你為同一個任務付出的成本會持續下降。

她給出全場最鋒利的一句框架:我們被可靠度約束住了,而可靠度不是可以拿來交換的東西。可以交換的是「政策」——人與 agent 要怎麼以可信的方式一起工作。

金句

"When the benchmark is saturated, people don't use it anymore."(約 02:01)

一句話解釋了為什麼企業永遠在公開 benchmark 上看到令人失望的天花板——那個天花板是設計出來的。

"The agent has become smart. It does a shortcut."(約 02:05)

急性腎損傷案例的核心:agent 的「聰明」正是它繞過臨床規定的方式。答案對,流程錯。

"Does the agent know what it doesn't know?"(約 02:06)

她自己說這是她最喜歡的問題:拆成信心校準與 abstention 政策兩件事。

"We are constrained by reliability. Reliability is not something you can trade off. What is trade-off is what's the policy."(約 02:10)

整場演講的結論句。

"Don't only ask how intelligent the agent is. Ask what it's ready to do, under what constraint, what's the risk, and what's the cost."(約 02:10,最後一張投影片)