LLM Evals Playbook 是怎麼工作的？我用一條真實鏈路把它講清楚

一條真實評測鏈路

上周我在整理一個客服問答 Agent 的回歸測試，遇到最頭疼的問題是：每次模型微調后，怎麼快速知道哪些地方變好了、哪些地方反而變差了？

傳統的單元測試不適用——LLM 輸出是自然語言，沒有固定的斷言值。 翻了一圈工具，最終選擇了 LLM Evals Playbook 的思路。 它不是一本 PDF，而是一套可執行的評測框架，核心流程是：定義評測標準 → 生成測試數據集 → 運行評估 → 分析結果並反覆運算。

下面是我跑通的第一條完整鏈路，每一步都有對應的代碼和配置檔。

第一步：定義評測標準

評測必須從業務出發。 我的場景是客服問答，所以定義了三個維度：

• 答案準確性：回答是否基於提供的知識庫，不 hallucinate。
• 完整性：是否覆蓋用戶問題的所有子問題。
• 語氣合規：是否保持友好、不推卸責任。

每個維度用 1-5 分打分，並附上評判標準說明。 Playbook 要求這些標準必須可操作，比如「準確性」不能只說「正確」，而要寫成答案中每一條資訊都必須能在知識庫中找到對應原文」。

這裡最容易犯的錯誤是標準過於模糊。 我第一版寫的是“回答應該準確”，結果不同評估員打出來的分數方差很大。 後來改為“答案中若出現知識庫中沒有的實體或數據，扣 2 分”，一致性才上來。

第二步：生成測試數據集

Playbook 建議數據集包含三類樣本：正常問題、邊緣問題（如缺上下文）、對抗問題（如誘導模型輸出不當內容）。

我用自己業務中的真實使用者日誌生成了 50 條正常問題，然後手動構造了 20 條邊緣和 10 條對抗問題。 構造對抗問題時要小心——不要直接拷網上的 prompt injection 範本，那往往脫離你的實際業務場景。

一個關鍵失敗點：數據集和評測標準之間必須對齊。 如果你的標準要求“不 hallucinate”，但數據集裡大部分問題都是簡單查詢，模型本來就不會胡說，那評測結果就缺乏區分度。 正確做法是先跑一輪小樣本，看模型在哪裡容易出錯，據此補充數據集。

第三步：運行評估

我用 LangChain 的 Evaluator 框架對接了 Playbook。 每個測試樣本的評估過程是：先讓被評測的 Agent 回答問題，然後用一個 Evaluator LLM（比如 GPT-4o）根據預設標準打分。

評分必須附帶理由，不能只給分數。 例如：「準確性 4 分：回答中提到了價格 199 元，但知識庫中是 1999 元，扣 1 分。 完整性 5 分：覆蓋了價格、貨期、售後三個子問題。 “ 這樣後續分析時能精確定位缺陷。

第四步：分析結果並反覆運算

評估完成後，我的輸出是一個 CSV 表格，每行是樣本 + 各維度分數 + 理由。 分析時重點看：

• 哪些維度分數普遍低：如果完整性平均只有 2.5 分，說明模型經常遺漏資訊。
• 哪些樣本分數波動大：評估員之間或樣本之間的差異，往往指向標準不清晰。

我第一次跑出來的結果：準確性 4.2，完整性 3.0，語氣 4.8。 完整性低的原因是模型只回答了使用者顯式問的問題，沒有主動提供關聯資訊（比如使用者問“什麼時候發貨”，模型回答了發貨時間，但沒有連帶說明物流查詢方式）。 於是我在 prompt 里加了「如果用戶問題涉及訂單，主動補充訂單號查詢物流的步驟」。 第二輪評測完整性提升到 4.5。

最容易失敗的地方與錯誤理解

Playbook 最大的陷阱是數據集和標準脫節。 很多人照著範本寫了幾條標準，再從 HuggingFace 隨便拉個數據集就跑評測，結果分數很好看但實際不反映業務問題。 正確做法是：標準和數據集必須來自同一業務場景，並且先做小規模驗證。

另一個常見錯誤是把評測當成一次性驗收。 Playbook 的價值在於持續回歸：每次模型更新、prompt 調整後都要重新跑，形成“評測 -> 分析 -> 修復 -> 再評測”迴圈。 如果只跑一次就丟在那裡，那本質上就是沒有評測。

如果你現在就要落地，第一步應該怎麼做

1. 選擇一個具體的業務場景（比如客服問答、代碼生成、摘要）。 不要試圖覆蓋所有能力。
2. 定義 2-3 個可操作的評測維度，每個維度寫清楚扣分條件。
3. 收集 10 條真實樣本，手工跑一遍：你親手用標準打分，看標準是否清晰，數據集是否有區分度。 這一步不花超過 1 小時。
4. 根據手工跑的結果調整標準，然後擴展到 50-100 條樣本。
5. 接入自動化框架（LangChain、DeepEval 等），開始迴圈。

下一步去哪裡系統化學習

如果想把評測體系搭建得更完整，或者想瞭解如何在 Agent 工程中系統整合 Evals，可以進一步閱讀更系統的原創付費文章和 AI 程式設計進階課程。