- Published on
AI 應用程式評估指南:為何評估不是單元測試 - Vercel 工程師 Ido Pesok 深度分析
在 AI 應用程式開發的世界中,確保模型表現穩定可靠一直是開發者面臨的重大挑戰。Vercel 工程師 Ido Pesok 在這場精彩的演講中,深入探討了 AI 應用程式評估(evals)的重要性,並透過生動的籃球場類比,為我們揭示了為何評估與傳統軟體開發中的單元測試截然不同。
Vercel V0 專案與 LLM 應用的挑戰
Ido Pesok 首先介紹了 Vercel 的 V0 專案,這是一個旨在簡化原型設計與網頁開發的全端 AI 編碼平台。隨著 V0 推出 GitHub 同步功能並達成一億條訊息的里程碑,Vercel 團隊對於 AI 應用程式的穩定性有了更深刻的認識。
「水果字母計數器」的教訓
透過一個看似簡單的「水果字母計數器」應用程式案例,Ido 生動地說明了大型語言模型(LLM)在實際應用中的潛在不可靠性。這個應用程式在開發者內部測試時表現完美,但在向用戶發布後,卻因無法處理多樣化或複雜查詢而出現錯誤。
最典型的例子是在「草莓」中計數「R」的數量時,模型的答案會從正確的三次,突然變成錯誤的回應。這個案例凸顯了 AI 應用程式的一個獨特特性:
- 演示時完美,部署後出錯:AI 應用程式在展示時往往表現完美,但在生產環境中常因「幻覺」或未預期的用戶輸入而產生錯誤
- 95% vs 5% 問題:即使 95% 的功能運作正常,但最關鍵的 5% 可能因 LLM 的不穩定性而失效,導致整個應用程式變得「無法使用」
評估的核心理念:籃球場類比
為了應對這些挑戰,Ido 提出了建立穩健評估機制的重要性,並用了一個絕妙的籃球場類比來解釋評估的構成要素:
評估三要素
數據(Data):籃球場上的點
- 代表用戶提出的各種查詢(Prompt)
- 涵蓋應用程式需要處理的所有使用場景
任務(Task):投籃的動作
- 即應用程式處理查詢的方式
- 包括不同的系統提示、前處理邏輯等
分數(Score):投籃是否命中
- 代表應用程式對查詢回應的成功與否
- 藍點為成功,紅點為失敗
一個好的評估應該能清晰地描繪出應用程式在不同類型查詢上的表現,如同籃球場上的投籃分佈圖。
建立高品質評估的四大策略
1. 了解你的「球場」
避免「界外球」:
- 不要為用戶不關心的查詢建立評估
- 專注於實際用戶會提出的關鍵問題
- 過多的無效評估只會分散資源
確保「全場覆蓋」:
- 評估數據應涵蓋應用程式所有關鍵功能和潛在使用場景
- 避免只集中在某一特定區域
- 有助於識別系統在邊緣案例或複雜查詢上的弱點
2. 數據收集來源
用戶回饋:
- 收集用戶的「讚」或「踩」數據
- 這些是判斷應用程式問題的直接訊號
日誌抽樣:
- 定期審查日誌中的隨機樣本
- 能深入了解用戶如何使用產品以及遇到的問題
社群論壇與社群媒體:
- 如 X/Twitter 等平台是用戶報告問題的重要管道
- 但可能伴隨較多噪音,需要過濾
重要提醒:沒有捷徑,必須投入精力去理解用戶行為和實際痛點。
3. 評估設計原則
數據為「常數」,任務為「變數」:
- 將用戶會穩定詢問的內容作為固定數據
- 將想要測試的系統變數放在任務中
- 這樣能提高評估的清晰度、重用性和泛化能力
程式碼共享:
- 利用 AI SDK 的中介軟體等機制
- 確保評估環境與實際運行環境共享相同的程式碼邏輯
- 使評估結果更貼近真實表現
簡化評分機制:
- 優先使用確定性的「通過/不通過」評分
- 避免過於複雜的分數設計
- 在除錯時,簡單的二元判定能更快幫助開發者找出問題
提示技巧:
- 可在評估用的原始提示中,要求模型將最終答案輸出在特定標籤內
- 這有助於簡化自動化評分時的字串匹配
4. 將評估整合至持續整合(CI)
強烈建議將評估流程納入 CI/CD 管線。例如:
- Brain Trust 等工具可以生成詳細的評估報告
- 顯示程式碼變更對應用程式整體性能的影響
- 包括改進和退步的部分
- 幫助團隊在發布前全面了解每次變更的影響
- 避免修復一部分問題卻破壞另一部分
核心觀念:沒有測量的改進是有限且不精確的
Ido Pesok 在演講的最後總結了一個重要觀念:「沒有測量的改進是有限且不精確的」。
評估應該成為 AI 應用程式開發的核心,可以將其視為模型的「日常訓練」。透過系統性的評估,開發者能:
- 更清晰地了解模型表現:在不同場景下的具體表現
- 做出數據驅動的決策:基於實際數據而非直覺
- 系統性地改進應用程式:有針對性地解決問題
這樣的評估機制能帶來:
- 更高的可靠性和品質
- 更高的轉換率和用戶留存率
- 減少支援和營運上的時間投入
個人想法與反思
這場演講真的是非常淺顯易懂,可以幫助開發者更好地理解模型的相關表現和評估。用籃球場來形容評估真的是相當巧妙的類比,讓抽象的概念變得具體可感。
特別是最後總結的那句「沒有測量的改進是有限且不精確的」,這一直以來都是軟體開發會遇到的問題之一。當使用者反映系統慢或有問題時,如果我們不知道具體是哪裡慢、哪裡有問題,又該如何修正呢?
沒有好的測量基礎,就無法進行有效的改善。我想這也是這幾年可觀測性(Observability)領域如此熱門的原因之一。當然,有點離題了 😄
如果你也在開發 AI 相關的應用程式,這場演講絕對值得一看。它不僅提供了實用的評估策略,更重要的是建立了正確的評估思維模式。
支持創作
如果這篇文章對您有幫助,歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力!
圖片來源:AI 產生