看到 Eugene Yan 這篇 “Product Evals in Three Simple Steps“，把 LLM 產品的 eval 怎麼做講得非常清楚。Eugene Yan 在 Amazon 做 Applied Science，之前寫過好幾篇 eval 相關的好文，這篇算是他跟不同團隊反覆講了 N 遍之後，終於整理下來的實戰指南。

做 LLM 產品的人一定有感: eval 大家都知道重要，但真正動手時常常不知道怎麼開始，搞太複雜又沒人維護。這篇把事情收斂成三個步驟，每一步都給了很具體的做法跟踩坑經驗，非常值得參考。以下是重點整理:

1. 標註一小批資料

第一步是從正式環境的 LLM 輸入/輸出中取樣，由人工標註輸出是否符合評估標準 (例如忠實度、相關性等)。工具不用複雜，試算表就好，欄位放輸入、輸出、輔助判斷的額外資訊，再加一欄標籤。

用二元標籤，別用評分量表

這個建議蠻反直覺的。一般人會覺得 1-5 分的量表比較精細，資訊量更大，但實際操作起來問題很多: 人類標註者之間對「這到底是 3 分還是 4 分」的判斷差異就很大了，即使給了詳細的評分指引也校不準。LLM 評估器也一樣 — 如果人都標不一致，LLM 當然也很難一致。

而且他觀察到一個很現實的狀況: 利害關係人一開始會說「我要 1-5 分，這樣之後可以彈性調門檻」，但實際上從來沒有人真的回去調過。最後大家還是問「通過率多少?」然後要你給一個建議門檻。既然終點就是二元判斷，不如一開始就用通過/不通過，標得快、一致性高，校準評估器也容易得多。

如果評估標準比較主觀 (例如「哪個摘要比較簡潔?」)，可以用勝/負/平手的比較式標籤，允許標平手很重要 — 強迫人在兩個差不多的輸出之間選贏家只會引入噪音。

收集足夠的失敗案例

這是很容易忽略的點。假設你標了 200 筆但裡面只有 5 筆不通過，這筆資料基本上沒辦法拿來校準評估器，因為失敗的樣本太少了。他建議至少要有 50-100 個失敗案例，總樣本 200+ 筆，才算是一個平衡、可用的資料集。

那失敗案例怎麼來? 他推薦用比較小、能力比較弱的模型跑一輪。這些模型會自然產生「有機」的失敗 — 長上下文處理不好、推理能力不夠、邊界情況搞砸 — 這些剛好是正式環境中真正會碰到的錯誤類型。

相對地，用強模型刻意生成合成缺陷 (叫它故意犯錯) 他認為問題不小: 這種人造的錯誤容易跟真實分布不同，要嘛太誇張、要嘛太細微，跟實際情況差很多。如果評估器是在這些合成失敗上校準的，到了正式環境反而抓不到真正的問題。可以拿來起步，但不能只依賴它。

另一個好方法是主動學習: 等你有一個堪用的評估器之後，拿去跑在大量未標註的資料上，把它判斷為不通過的優先拉出來人工審核，這樣就不用盲標幾千筆，效率高很多。

2. 校準 LLM 評估器

有了人工標註的資料，接下來要做 LLM-as-Judge: 寫提示模板，讓 LLM 吃輸入和輸出 (加上輔助資訊)，自動吐出跟人工標註一致的標籤。

做法跟傳統機器學習一樣，把標註資料分成開發集 (75%) 和測試集 (25%)。開發集拿來迭代提示模板 (試不同寫法、加不同範例)，測試集留著最後評估評估器的泛化能力，避免過擬合到你看過的那些案例。

一個評估器只評一個維度

不要想做一個「萬能評估器」用一個提示一次評忠實度、相關性、簡潔度、語氣等 5-10 個面向。他說從來沒看過這種做法成功的。原因是: 當你發現分數不對的時候，你根本沒辦法知道是哪個維度校不準，除錯起來是噩夢。

正確做法是每個維度各做一個評估器，最後用簡單規則合併 (例如全部通過才算通過)。這樣哪個維度拖後腿一目瞭然。而且不同維度的性質不同 — 有些是護欄指標，不過就不能上線 (例如不能出現幻覺)；有些是北極星指標，是持續改善的方向 (例如回答簡潔度)。拆開才能區別對待。

勝負比較要處理位置偏差

如果你的評估是比較兩個輸出誰比較好 (勝/負)，LLM 通常會偏好放在前面的那個。解法是跑兩次，交換順序: 第一次基準版放前面、對照版放後面，第二次反過來。如果兩次結果一致，那判斷是可信的；如果翻轉了，表示兩個輸出差異太小，不如直接算平手。

怎麼評估「評估器本身」的品質?

既然評估器也是模型，當然也要有指標來衡量它好不好。用精確率、召回率和 Cohen’s Kappa:

  • 召回率 (對失敗類別): 最重要，要確保評估器能抓到缺陷，漏掉就失去意義了
  • 精確率: 也要顧，不能誤報太多 (把好的判成壞的)
  • Cohen’s Kappa: 衡量 LLM 評估器跟人類標註之間的一致性。0.4-0.6 算不錯，0.7 以上很好

一個很重要的心態調整: 基準是人類表現，不是完美。 利害關係人有時會要求評估器達到 90% 以上準確率，但事實是人類標註者之間的 Cohen’s Kappa 常常只有 0.2-0.3，看幾百筆之後疲勞了甚至會漏掉一半的缺陷。所以如果 LLM 評估器的召回率和一致性已經超過人類，那就算成功了。

LLM 評估器真正的優勢不是「比人準」，而是可規模化: 能在幾分鐘內一致地跑幾百筆評估，全天候不會累，不受人力瓶頸限制。這才是讓團隊能大量跑實驗、快速迭代的關鍵。

3. 每次改動都跑評估流程

最後一步是把個別評估器組合成一個評估流程 (eval harness): 吃一批輸入/輸出資料，平行跑各個評估器 (注意速率限制)，然後彙整成結果報表。他建議做一個工具函式把指標輸出成單列表格，方便直接貼到 Excel 讓 PM 追蹤，加個條件格式就能一眼看出哪些指標改善、哪些退步。

跟實驗流程串起來

這步的關鍵是: 評估流程要能直接吃實驗的輸出。這樣整個流程就是: 改一行設定 (提示模板、檢索參數、模型選擇) → 自動生成輸出 → 自動跑評估 → 看報表。想比較從 Claude Haiku 3.5 換到 Haiku 4.5 的效果? 改一行設定，啟動流程，去吃午餐，回來看結果就好。這個回饋迴圈越緊，迭代速度越快。

樣本量要多少?

取決於你需要多少統計信心。舉例: 假設產品要求缺陷率 < 5%，你跑了 200 筆觀察到 3% 缺陷率，95% 信賴區間是 3% ± 2.4%，也就是 0.6% - 5.4%。上界 5.4% 超過 5% 門檻，所以嚴格來說還不能下結論。

加到 400 筆的話，區間縮到 3% ± 1.7%，上界 4.7% 低於 5%，這樣才能有信心說達標了。不過要注意標準誤差跟樣本量的平方根成反比 — 想把誤差減半，樣本量要翻四倍，所以報酬會遞減，不是一味加量就好。(Anthropic 也有一篇 statistical approach to model evals 做了更深入的分析。)

四週建設，幾個月回收

文末有個很好的案例: 一個團隊花了大約 4 週建評估流程 — 定義評估標準、收集人工標註、校準評估器、建實驗流程。利害關係人一開始很緊張，覺得花一個月不做產品在搞基礎建設。

結果接下來兩週，團隊就跑了幾十個實驗，在不同模型、檢索設定、提示模板之間快速迭代，做出了可用的產品。再之後幾個月又跑了幾百個實驗來優化細節、加新功能、處理邊界情況。如果每次改動都要等人工標註才能評估效果，這種迭代速度是完全不可能的。

Product eval 的核心價值不只是量測品質，更是縮短回饋迴圈、讓團隊能快速迭代。 這點是這篇最重要的收穫。

Harrison Chase (LangChain/LangSmith 創辦人) 看完這篇也錄了一個影片，示範如何在 LangSmith 上實作這三個步驟 (標註資料、校準評估器、跑評估流程)，有在用 LangSmith 的可以參考。

原文: Product Evals in Three Simple Steps