最近看到一場關於 AI Evals 的精彩論戰，爭論焦點不在模型訓練層面的評估(這個大家都有共識要做)，而是 AI 應用層面到底要做多少評估。這讓我想起自己在軟體開發的經驗: 如何寫測試也是我曾關注的問題，但說實話，我從來不追求 100% test coverage。即使 Ruby 社群也強調每件事都要有測試涵蓋，但我還是比較考量成本效益，自動化測試對我來說是值得做才會做的事。
現在 AI Evals 也處於類似階段。我去年就開始關注並分享如何做評估，但要求每個面向都 100% 有評估其實是不實際的。AI 是機率性軟體，評估難度更高，AI 的輸出好不好也非常有主觀成分，目前怎麼做很依賴實務經驗交流。最近剛上完 AI Evals For Engineers & PMs 課程，有了新的體會。首先，「評估驅動開發」(指先寫評估再開發) 竟然可能是錯的方向 – 對於沒有標準輸出的 AI 任務，你無法無限投資在評估上。
我目前認為評估可分兩種:
Soft preferences (graded helpfulness): 大多數範例用 LLM as Judge 給 1-5 分評估「有多少幫助」、「有多清晰」等，都屬於這類。坦白說，這種評估幫助有限，頂多做相對比較，實際效用不大。
Hard rules (binary guardrails): 這種其實更實用，就是會有標準答案的二元判斷，用 Code-based 或 LLM as Judge 判斷是不是有做到你要求的限制。這門課程重點就是教如何用 LLM 科學地做出對齊後的 binary classifier。
但是沒有標準答案的 LLM 要輸出怎麼做 binary classification? 我們不做通用的 LLM-as-Judge 評估，而是先人工做錯誤分析，找出真正重要的錯誤模式，然後做 LLM as Judge 只判斷 Y/N 輸出有沒有犯這個特定錯誤。這樣你會得到真正有用、精準的絕對指標，能實際幫助改進 AI 應用。
就如 Hamel Husain [0] 說的：「Generally no. Eval-driven development (writing evaluators before implementing features) sounds appealing but creates more problems than it solves.」重點是找到真正影響用戶體驗的關鍵指標，而不是為了評估而評估。
[0] x.com/HamelHusain/status/1950247467444031828
那 Soft preferences 怎麼辦？這部分還是得依賴人的判斷，AI 無法完全取代。無論是團隊自己 dogfooding、監控線上指標、收集用戶回饋，或是跑 A/B testing，還是得靠傳統產品開發的方法。AI 應用的評估不是非黑即白的選擇題，得在不同階段不同需求，靈活運用不同工具的智慧。
(以下整理整個論戰的精彩內容，透過 Claude 協助寫成)
AI Evals 論戰整理
這場辯論始於 Anthropic Claude Code 創始人 Boris 在訪談中[1]的坦白。當被問到如何評估新模型時，他的回答令人意外地簡單：「我就做我當天的工作」。沒有複雜的測試套件，沒有精密的指標，純粹就是感覺模型變聰明了嗎。Boris 承認他們試過建立產品評估系統，但發現建立評估真的很困難，最終最大的信號就是「感覺」。他認為很難找到能捕捉軟體工程所有複雜性的合成評估，SWE-bench 這類基準測試雖然表現出色，但真實的軟體開發遠比這些測試複雜。
這個坦白被 swyx 爆料後引發軒然大波。他在推特上諷刺地列出了產業現況：Claude Code 沒有 evals，某知名 code agent 公司沒有 evals，另一家知名公司只有敷衍的 evals，領先的 vibe coding 公司也沒有 evals。但賣 evals 的公司 CEO 會說「我所有的頂級客戶都做 evals，你也應該做」，愛上 evals 公司的創投也會附和「我所有的頂級創辦人都做 evals，必須做 evals」。swyx 補充說他確實認為 evals 很重要，但那些狂熱支持 evals 的 AI 工程師也注意到，做不做 evals 並不是成功的嚴格要求，至少在從 0 到 1 的階段，不做 evals 甚至可能與成功呈正相關。
[1] www.youtube.com/watch?v=iF9iV4xponk
[2] x.com/swyx/status/1963725773355057249
支持 Evals 的聲音
學術派代表 Shreya Shankar [3] 與 Hamel Husain 聯手為 evals 辯護，他們將 evals 定義為「對應用品質的系統性測量」，強調這不意味著特定的指標或方法，也不必是單一數字或完全準確。她指出那些聲稱「不做 evals」的團隊其實在自欺欺人，每個成功的產品都在某處做著評估，查看輸出、注意問題、dogfooding 產品並做出改變，這就是評估，只是沒有貼上「evals」的標籤。
她特別點出一個關鍵事實：即使像 coding agent 這樣的團隊感覺可以不做太多評估，那是因為他們已經從上游的嚴格評估中受益。編碼 evals 在後訓練中佔據如此重要的地位，實際上是其他人已經為你完成了大部分的 evals 工作。基礎模型供應商為每個新能力領域投入大量資金進行評估，因為他們知道沒有系統性測量就無法改進效能。
她特別擔心反 eval 情緒對社群的傷害，因為許多新手正在尋求建立 AI 產品，他們的任務可能不在後訓練中被充分代表，團隊也還沒有足夠經驗依賴直覺，對這些團隊來說，否定 evals 等於移除了幫助他們理解什麼有效、什麼無效的工具。
[3] www.sh-reya.com/blog/in-defense-ai-evals/
Braintrust CEO Ankur Goyal [4] 發表了一篇引戰文章，宣稱 A/B 測試已經跟不上 AI 時代的步伐。他認為傳統 A/B 測試建立在「創建變體很昂貴」的假設上，你需要為每個體驗投入大量設計和工程工作，所以只能測試少數選項。但 AI 改變了這個遊戲規則，當 AI 能自動為每個用戶生成個性化介面時，為什麼還要為「最佳平均體驗」做優化？他指出 OpenAI 收購 Statsig、Datadog 收購 Eppo 暗示著轉折點已經到來，未來屬於 evals 而非 A/B 測試。在他的願景中，系統能即時學習和改進，團隊從手工調整每個細節的工匠，變成自動化改進系統的架構師。
[4] www.braintrust.dev/blog/ab-testing-evals
實務經驗豐富的 Eugene Yan [5][6][7]把 evals 類比為測試驅動開發（TDD），在開發功能前先定義成功標準並從第一天就開始測量。他分享了自己的經驗：一旦設置好 eval 和實驗框架，讓調整配置和 prompt 變成一鍵運行加評估，團隊會享受運行實驗和提升指標的過程，進展會很快。但他也承認設置這個框架對每個新專案都是挑戰，需要處理模糊的工作，即使設置好了，也很少人想看生成的回應來做定性評估。他強調通用的 evals 像「faithfulness」或「helpfulness」是沒用的，你的 evals 必須與用戶問題對齊。
[5] x.com/eugeneyan/status/1960148508495020234
[6] x.com/eugeneyan/status/1964103249230774682
[7] x.com/eugeneyan/status/1964334356006391882
反對 Evals 的批判
AgentOps CEO Alex Reibman 發表了最激進的批評文章《Evals are a scam》 [8]，直指整個產業都在被「eval 洗腦」。他認為大多數 AI 團隊不需要 evals，需要的是 logging、QA 和品味。他指出基礎模型的 evals（測試 LLM 在各種任務的一般效能）和產品 evals（測試應用在真實使用案例的效果）是完全不同的東西，除非你在 OpenAI、Anthropic 或 Meta 工作，否則你不需要模型 evals。而產品 evals 是主觀、模糊且混亂的，eval 供應商試圖賣給你他們永遠無法提供的東西：對你自己產品的專業知識。他認為這些公司其實是「複雜性商人」，透過課程、電子書、部落格、網路研討會推銷他們的框架，最終真正賣的是昂貴的 logging 服務。
[8] hacktrace.substack.com/p/evals-are-a-scam-and-were-being-gaslit
前 GitHub Copilot 團隊、現 Quotient 創辦人 Julia Neagu [9] 從工程師視角提供了深入分析。她指出 LLM 作為 API 出現，這對工程師來說是熟悉的領域，所有成功的 AI 工具都有一個共同點：對工程師有良好的人體工學設計。但 eval 工具沒有映射到已知的開發者工作流程，這就是為什麼兩年來「evals 很重要」的論述下，eval 工具仍然沒有突破的原因。她在 GitHub Copilot 的經驗證實了這點：雖然有複雜的 eval 框架用於基準測試，但真正決定是否上線的還是 A/B 測試，而且推出的壓力如此之高，如果通過 A/B 測試就會直接上線。她總結說，儘管網上論述聲稱相反，大部分 AI 產品仍然是基於 vibes 在出貨。
[9] x.com/JuliaANeagu/status/1964704824299253888
Raindrop CTO Ben Hylak [10] 從監控角度批評 evals，認為 evals 只是已知問題的集合，是你透過對抗性選擇找到的失敗案例，無法發現未知問題。他引用 Replit 工程師的話：由於輸入空間不再有限，你無法簡單地寫幾個選定的測試然後遵循測試驅動開發，你會在不知情的情況下破壞關鍵功能。這就是為什麼在生產環境中測試，使用傳統 A/B 測試也很關鍵，能盡可能接近你服務的一般人群，有更高機會測試長尾結果。當 AI agents 變得越來越強大，能執行的任務越來越開放，運行時間越來越長，如果構建正確，它們能以你無法預測或想像的方式執行任務，測試所有可能性變得不可能，但監控仍然可行。
[10] www.raindrop.ai/blog/thoughts-on-evals
實踐者 Matt Shumer [11] [12] 分享了 Otherside 的經驗，他們使用基於真實流量的 A/B 測試，測量訂閱和留存率。他直言 evals 有幫助但與實際效用的相關性不高，試過所有方法後，A/B 測試才是正道。他的觀點簡單明瞭：如果你是實驗室，建立通用前沿模型，evals 很重要；如果你是產品建構者，evals 大多不重要。
[11] x.com/mattshumer_/status/1964178712452354551
[12] x.com/mattshumer_/status/1963789428029042822
尋求平衡的聲音
Hamel Husain [13] 試圖調解這場由兩家供應商引發的戰爭，他指出你需要線上和離線測試，它們有不同的權衡。離線指標是行為和結果的代理，迭代速度更快；線上指標和 A/B 測試是必要的，用來檢查確保你的離線指標確實是好的代理，而且某些東西只能透過線上測試來測量。他感嘆需要把資料科學帶回 AI 工程，因為這種缺失在討論中表現得很明顯。他後來補充說，OpenAI 的技術成功團隊花大量時間與客戶討論 evals，他們認為這是高槓桿活動，evals 是試點停滯和部署成功之間的區別。
[13] x.com/HamelHusain/status/1964110406596907170
Bryan Bischof [14] 認為 swyx 比其他討論者更深入理解這個議題的細微差異。他指出幾個關鍵點：evals 作為單元測試一直大多無關緊要，除了早期迭代或回歸測試；超級廣泛的黃金 eval 集往往老化得很差；那些說「就 A/B 測試啊，兄弟」的人，通常連 A/B 測試都不懂，更別說在 LLM 範式中做有效的 A/B 測試。他解釋為什麼 code agent 公司較少迷信 evals：因為用戶角色和產品開發者之間的差距很小，大家都同意 dogfooding 非常有價值，但飛輪是：dogfooding → 錯誤分析 → 編碼化的 eval。他直言不在應用層工作的人應該在這個話題上閉嘴。
[14] x.com/BEBischof/status/1963739648792117484
Brooke Hopkins [15] 指出這場辯論的核心問題：每個人用「evals」指代至少 6 種不同的東西，然後在對話毫無交集時感到震驚。她認為雙方都錯過了重點，真正的問題不是 evals 有效或無效，而是定義混亂。她主張不能把生產前和生產後的評估分開看待，需要整合的系統，讓生產前模擬能實際反映真實用戶模式，生產監控能回饋成更好的測試案例，人工審查員能有效發現演算法永遠不會捕捉到的邊緣案例。她特別強調需要更多資料科學家參與 evals，而不只是 ML 工程師，因為大多數 eval 框架是由確定性思維的人構建的，但 AI 系統是機率性的，我們使用了錯誤的心智模型。
[15] x.com/bnicholehopkins/status/1965130607790264452