Build Evals That Actually Matter - Nick Ung, Lyft

Lyft 的客戶支持 AI 代理已經開發超過一年，在這個過程中，Nick 和 Akshay 團隊認識到評估系統是確保代理質量的關鍵。他們將評估分為開發階段和生產階段，設計了一個端到端的管道。

在開發階段，工程師需要構建代理的各個組件：管理上下文、建立 Red 管道獲取教育對話、定義工具、設計代理圖和系統提示。完成後，代理必須通過嚴格的離線評估才能進入生產環境。這一理念來自機器學習模型開發的最佳實踐——在發佈前進行離線評估，而不是讓真實用戶成為測試對象。

離線評估流程採用了 Tau Bench 論文的靈感，包含三個核心組件：一個是 AI 代理本身，一個是扮演用戶的 LLM，兩者進行多輪對話生成完整軌跡；二是領域政策規則，定義客戶支持場景下的處理指南；三是評判器，既有 LLM 評判器也有代碼斷言形式的確定性檢查。

然而，Lyft 在初期遇到了一個嚴重問題。使用前沿 LLM 扮演用戶時，模型傾向於表現得過度友好和耐心，導致對話聽起來不像真實的支持票，評估準確率虛高達 90%。真實的 Lyft 用戶往往不耐煩、已經挫折，對話簡短且直接。為了解決這一問題，他們用真實用戶對話數據對 LLM 進行了微調，同時定義了多種用戶角色（忠實客戶、退款尋求者、AI 懷疑論者等），使模擬器更接近現實場景。微調後評估分數下降了，但這正是所期望的——評估應該反映真實難度。

在 LLM 評判器設計上，Lyft 最初使用 DeepEval 提供的預構建指標，如回應幫助性、對話自然度等，但這些指標太通用、不可操作。例如，如果「回應幫助性」得分為 0.5，開發人員無法從中獲得改進方向。因此，他們與領域專家合作，定義了與業務目標對齐的二元指標，如「教育文案」指標：檢查代理是否在應該升級時進行了升級，或是否在無機會教育用戶時過早升級，以及其他失敗情況。這些指標是可操作的，能直接指導代理改進。

為了驗證評判器的有效性，Lyft 採用了機器學習分類器的驗證方法。他們手工標註約 100 個例子為通過/失敗，分割成訓練集、開發集和測試集。訓練集用於從評判提示中提取示例，開發集用於迭代改進評判提示和框架，測試集用於最終驗證。隨後計算精確度和召回率，確保評判器在看不見的數據上表現一致。

此外，Lyft 認識到評估標準不應前置定義，而應隨著觀察到的數據而演化。他們進行定期的誤差分析循環，深入檢查失敗案例，識別失敗模式，去除噪音指標，保留真正影響決策的指標。這個循環應持續運行（如每週或雙週），而不是一次性審計。

在統計方法上，他們添加了置信區間，避免虛假結論。例如，若一個評判器得分 84%，另一個 88%，在只有 50 個樣本的情況下，4% 的提升可能不具統計意義。只有在樣本量足夠或提升幅度明顯時，才能得出有效結論。

生產環節也有在線評估，使用 LangSmith 或 LangFuse 等工具追踪每次代理執行的完整軌跡（調用的節點、LLM 看到的信息、使用的工具、令牌用量、延遲等），結合 LLM 評判器和人工分析，持續識別失敗模式並反饋給開發團隊。

最後，Lyft 構想了一個配置驅動的評估框架，使用 YAML 文件定義任務、數據集、用戶角色、LLM 適配器和評估器等原語，允許工程師、分析師和數據科學家都能貢獻。該框架支持並行執行，處理數千甚至數萬評估案例。代理開發者可在本地調整提示時立即運行評估獲得反饋，在提交前執行評估確保性能無退化，在 CI/CD 中構建回歸測試套件。