Eval:驅動 Agent 改善的引擎

TL;DR

• 問題不是團隊不想做 eval,是摩擦力:每個團隊都想要高品質的 production agent,但都選擇「先把 agent 上線,eval 之後再想」——這在要驗證 PMF 的當下是完全理性的決定。代價是掉進「事後補 eval + 事後查為什麼壞掉」的無盡迴圈。平台團隊的工作就是把這些摩擦點一個個消掉。
• 四個介入手段:(1) 第一天就在每個環境開 tracing;(2) 用 agent 的建構脈絡與文件自動推薦 starter kit evaluator,並直接推播到 Slack;(3) 用 CLI 與 skills 把 eval 從工程專屬變成產品團隊也能擁有的東西;(4) 換掉敘事——這一項沒有工具可以解。
• 最好的說服素材是一個失敗案例:語音叫車的離線 eval 有 95%+,但 production eval 顯示每個 session 的輪數異常偏高。追下去發現:乘客要去 SFO,背景有人說了一句「我想吃 pizza」,agent 把它當成輸入,開始把人導向最近的 pizza 店。
• 終點是把 eval 從「分數」變成「引擎」:traces → 失敗被自動分類 → 自動提出對 agent 與 evaluator 的修改建議 → 團隊只要 accept / reject。分數是你已經知道的事;引擎是持續讓 agent 往客戶在乎的方向靠攏。

重點整理

開場的三個舉手題(約 03:01)

Aayush Agrawal 是當天 Compass Stage 的壓軸。他先用三個問題暖場:

1. 今天有誰搭過 Uber?(少數人舉手)
2. 更重要的:誰真的為 production 的 agent 寫過 eval?(他稱這些人為 real builders)
3. 最後一題,你要為這件事感到驕傲:那些 eval 有沒有告訴你什麼、進而改變了你出貨產品的方式?

他要指出的正是這條分界線:把 eval 當成一個打勾項目,和 eval 真的改變你的產品方向,是兩件事。 而讓每一個 agent 團隊都能做到後者,正是 Uber 花了一年多在做的事。

背景:Uber 的 agent platform(約 03:02)

Uber 正在整個生態系中出貨 agent——對外(例如用語音叫車)與對內都有。在企業規模上支撐這一切的,是他所管理的 Uber agent platform,底下有一系列元件,讓 agent 團隊不必操心基礎設施。這場談的是其中的 eval。

診斷:一個理性的決定,一個必然的迴圈(約 03:02–03:03)

他觀察到跨團隊的共同模式:每個團隊都想要高品質的 production agent,但每個團隊都做了同一件事——「我先把 agent 上線,eval 之後再說。」

他很公允地指出這是非常理性的決定:他們當下要證明的是 product-market fit,他們只想知道這東西到底行不行。

但代價是:他們接著就被困在一個無情的迴圈裡——事後補 eval,事後回頭拼湊那個 agent 到底為什麼壞掉。

平台團隊的結論是:存在真實的摩擦點,阻止團隊更早進入有 eval 的狀態。那就把它變成零摩擦。

四個介入:讓 eval 成為預設值(約 03:03–03:05)

1. Tracing 從第一天、每個環境開始

(他也提到這點當天很多講者都講過。)只要開發一啟動,每個環境就都有 tracing。這給了團隊建立後續評估的地基:你可以就這樣把 agent 蓋起來、跟它 vibe 一下、丟出去,而它一路怎麼變化的所有資訊都已經在那裡了,不是之後要回頭補的東西。

2. Starter kit evaluator,直接送到 Slack

有了資料之後,新的卡點是:團隊不知道怎麼開始寫 eval——不知道最好的寫法是什麼,也不知道該寫在哪裡。

平台的做法是:利用這個 agent 是怎麼被建構的脈絡、以及它的文件,推導出最適合的 starter kit evaluator,然後把這些洞見直接推播給 builder 的 Slack。

他舉的例子很具體:「我不知道 LLM judge 是什麼,但我知道 tool contradiction 是什麼意思,而且我可以因此做出修改。」

3. CLI:把 eval 從工程手上釋放出來

他點出一個關鍵差異:agent 的 eval 和 QA 測試非常不同,它們不是純工程的東西。

但必須把這個落差補起來,好讓離客戶最近的團隊——產品與客服團隊——有能力理解這些 eval。CLI 體驗真正民主化了這件事:透過建構管理 eval 的 skills,他們看到產品團隊能夠擁有整個流程。

4. 換掉敘事(這一項沒有工具可以解)

最後一項是他明說「我們沒辦法用工具繞過」的:改變大家對「eval 是要做什麼用的」的認知。

他們把團隊的提問從「你的 eval 有沒有 90% 以上?」換成:

• 你真的信任你的 eval 嗎?
• 因為 eval 告訴你的事,你對 roadmap 做了什麼改變?
• 你更新資料集的速度有多快?你的資料集是不是已經五個月沒動、跟現在的產品早就對不上了?

成果:出貨更快,而且在產品生命週期中更早抓到問題。

案例:語音叫車與那份 pizza(約 03:05–03:06)

Uber 即將推出乘客語音叫車。他們的 eval 抓到了這樣一件事:

• 離線 eval 分數是 95% 以上,看起來很好。
• 但 production eval 顯示:每個 session 的輪數(turns per session)遠高於平均。

深入追查後發現:有一位乘客正要叫車去 SFO,但背景有人說了一句「欸我想吃 pizza」——agent 把這句話當成了輸入,開始把乘客改導向最近的 pizza 店。

由此他們意識到:agent 必須理解真正的意圖(true intent),並且要有 no-op——在不該聽的時候就不要聽。

他強調這個發現之所以可能,是因為同時有 eval,也有產品團隊在迴圈裡。

終局:從 eval-as-default 到 eval-as-engine(約 03:06)

Uber 的演進路徑是:透過上述介入讓 eval 成為預設值,而現在他們正往下一階段走——eval 是一台引擎:

traces → 失敗被自動分類 → 自動提出對 agent 與對 evaluator 的修改建議 → 團隊 accept / reject → 改善回饋迴圈。

他的結尾對比很清楚:

一邊是一個 eval metric——一個關於你已經知道的事情的分數;另一邊是一台引擎,持續幫你把 agent 調校到客戶真正在乎的方向。

「這就是讓你在 Uber 的每一趟行程都感覺神奇的原因。」

金句

"That's the difference between having eval as a checkbox versus an eval actually changing your product direction."(約 03:01)

開場三個舉手題要問出來的那條線。

"They said that, hey, let me just ship the agent and I'll think about eval. And it was a very rational decision."(約 03:02)

他不責怪團隊——他把它當成平台要解的摩擦力問題。

"We changed teams' narratives from 'hey, is your eval 90% plus?' to 'do you actually trust your eval?'"(約 03:04)

唯一一個沒有工具可以解的介入。

"Is your data set five months old and not really up to date with your product?"(約 03:05)

Eval 資料集會腐爛,而腐爛的資料集會給你一個令人安心的假分數。