把 eval 做到真正有用

074Nick Ung、Akshay Sharma（Lyft）37:442026-07-19

Build Evals That Actually Matter - Nick Ung & Akshay Sharma, Lyft

Lyft 資料科學團隊拆解如何把客服 AI agent 的評測做到真正有用，而不是虛高又不可操作的分數。

重點摘要

離線評測是上線前的關卡：Lyft 客服 agent 上線前，先用模擬使用者跑多輪對話，搭配 LLM judge 打分，沒通過門檻就不能上線。
太客氣的模擬使用者會騙人：一開始的模擬使用者講話太有禮貌，讓評測分數衝到九成以上，跟真實用戶的落差其實很大，後來靠真實語料 fine-tune 才修正回來。
LLM judge 要可操作才有用：套裝的通用指標看得到分數卻不知道怎麼改善，要跟 domain expert 一起把 eval 定義成任務成功或失敗的二元判準。
judge 本身也要被驗證：把 LLM judge 當成分類器，用人工標註算 precision、recall，才知道這個 judge 是不是真的可信。
小樣本的進步可能是假的：樣本數不夠時，分數差距看起來像進步，其實要靠信賴區間跟統計嚴謹度才能判斷是不是真的。
評測是要持續跑的迴圈：追蹤執行紀錄、找失敗模式、只留有用的指標、重新評測，這件事要常態化，不是做一次就結束。

時間軸15 段

00:00	開場	Nick 與 Akshay 自我介紹，兩人都在 Lyft 資料科學團隊，做客服 AI agent 一年多，今天要講怎麼把 eval 做到真正有用。
02:06	評測系統全貌	development 階段先做離線評測，agent 上線後才進入線上評測，兩段都要有把關機制才能往下推進。
05:34	評測常見三個敗因	分數沒被當成上線關卡、LLM judge 太籠統沒人信、系統退步時沒有清楚的人去追，是評測最常失敗的三個原因。
07:44	離線模擬架構	借鏡 Sierra AI 的 tau-bench，讓 agent 跟模擬使用者 LLM 互動，依客服流程規範產生多輪對話再評分。
10:12	加入確定性檢查	除了 LLM judge，也用類似單元測試的規則，比對 agent 實際呼叫的工具跟預期結果是否一致。
11:19	合成資料的陷阱	不能只靠 LLM 生 50 條測試題，要混入真實 production 抽樣，並針對邊界情境做變化，資料才會像真實流量。
13:04	假警報：過關率破九成	模擬使用者講話太客氣有禮，讓離線評測分數灌到九成以上，跟真實用戶的落差其實很大。
15:06	fine-tune 出真實語氣	用 Lyft 真實用戶語料 fine-tune 模擬使用者，分數因此下降，但更貼近實況，也定義出多種 user persona。
17:26	通用指標不夠用	Akshay 接手講 LLM judge，指出用套裝指標評出的分數太籠統，看不出該怎麼改善 agent。
19:16	跟 domain expert 合作	把 eval 框成任務成功或失敗的二元判準，並示範一個判斷該不該升級處理的評分規則。
21:13	把 judge 當分類器驗證	人工標註 pass、fail，切出 train、dev、test，用 precision、recall 才知道 judge 準不準。
23:35	判準會一直漂移	評測標準要跟著看到的資料持續修正，不能一開始就把判準定死不動。
24:50	幫分數加信賴區間	樣本數只有 50 筆時，84% 跟 88% 的差距其實看不出是不是真的進步，要靠信賴區間判斷。
27:54	錯誤分析要常態化	追原始執行紀錄、抓失敗模式、只留跟決策有關的指標再重新評測，這是持續的迴圈，不是一次性稽核。
32:22	下一步方向	Nick 收尾：要把散落各處的評測腳本整理成系統化 eval harness，也在評估 fine-tune 模型與強化學習。

值得記的話4 句

This almost sounds too good to be true, and I think it indeed is too good to be true.這個結果好到不像真的，事後也證明真的不是真的14:15
If you have an eval that's too easy, that doesn't give you any real production insights into how your AI agent is actually going to perform.如果 eval 太簡單，就看不出 agent 在正式環境裡實際的表現16:05
We shouldn't use them as our core eval matrix because we want eval matrix to be actionable and tied to the business outcome.不該把這些拿來當核心評測指標，因為指標必須可操作、對得回業務結果19:16
The key idea is that we actually discover what our evaluation criteria is by looking at the data and grading our outputs.重點是評測標準其實是看資料、幫輸出打分的過程中才發現的23:35

名詞與人物7 個

tau-bench: Sierra AI 提出的評測框架，讓 agent 跟模擬使用者互動產生對話再打分，這場的離線模擬架構參考它。
Sierra AI: 提出 tau-bench 的公司，同樣在做客服類 AI agent。
LangGraph: 講者用來串起模擬使用者與 agent、跑出多輪對話紀錄的框架。
DeepEval: 團隊最早拿來當基準的一套現成評測指標庫，後來發現分數太籠統、看不出該怎麼改善。
annotation queue: 讓 domain expert 幫對話紀錄標記、給回饋的介面，不用直接看原始 JSON。
LangSmith、Langfuse: 團隊用來記錄與檢視 agent 執行過程的追蹤工具。
precision、recall: 拿人工標註的答案驗證 LLM judge 準不準時用的分類指標。

提到但沒有展開

講者提到參考了 Microsoft 一篇關於模擬使用者 LLM 的論文，但沒有進一步說明論文內容。
提到未來想把識別出的模型失敗模式框成 reward-modeling 問題，藉此做強化學習，但沒有展開細節。
提到會把 eval harness 接進 pre-commit 檢查與 CI/CD，做成 regression、acceptance test，但沒有說明實際怎麼串接。

Agent評估開發工具

在 YouTube 看原片 ↗