LLM Evals Workflow Checklist：從工程視角拆解核心機制、邊界與代價

為什麼需要一套 LLM evals workflow checklist

很多團隊在給 LLM 應用 evals 時，第一個反應是「用哪個框架」——LangSmith、MLflow、DeepEval 還是自建。但實際踩坑之後你會發現，工具選型只是最後一步。真正決定 eval 管線是否有效的是：你的問題定義是否清晰、指標選擇是否符合業務場景、資料建構是否涵蓋了邊界和失敗模式。

這是一份針對工程團隊的 LLM evals workflow checklist，不是通用指南，而是圍繞著「你已經有了一個 LLM 應用，現在需要判斷它的品質」這個前提展開。

第一步：問題定義－你究竟要評估什麼？

場景：一個客服摘要模型

假設你正在評估一個為客服對話產生摘要的 LLM。初步想法是計算 ROUGE-L 和 BERTScore，和人工標註對比。看起來合理，但實際運行兩週後，團隊發現 ROUGE 得分很高，但業務方抱怨摘要經常漏掉關鍵決策點（例如「已退款」或「需要升級工單」）。

這是典型的「指標與業務目標脫節」問題。 ROUGE 衡量的是 n-gram 重疊，而業務需要的是事實完整性和決策可追溯性。

檢查項目：

• 你的評估目標是輔助模型迭代，還是作為上線進入門檻？
• 如果有多個業務維度（事實準確度、語氣、結構完整性），你分別用什麼指標來衡量？
• 你是否區分了「模型行為」和「業務結果」？例如摘要夠簡潔但遺失了關鍵訊息，二者是不同層級的品質問題。

失敗點：定義模糊導致指標失效

最常見的問題是「使用語意相似度來評估摘要品質」。 Semantic Similarity 可以衡量兩個文本的含義一致性，但它無法區分「遺漏了關鍵事實」和「表達了不同但語義近似的觀點」。如果業務需要“所有關鍵事實都被覆蓋”，那麼你需要的不是相似度，而是 fact coverage 或基於 JSON 的結構化驗證。

第二步：操作步驟－搭建一次可重複的 eval run

1. 建構評估資料集

不要只用手寫的十幾個例子。一個策略：從生產日誌中採樣 200-500 條真實 query，然後人工標註「golden reference」。如果人工標註成本太高，可以用少量標註 + 弱監督擴展，但必須確保測試集是獨立於訓練集的。

檢查項目：

• 測試集是否涵蓋了正常場景、邊界場景（長文本、生僻詞）、失敗場景（使用者輸入不完整、格式異常）？
• 每一個測試輸入是否有對應的「預期輸出」？對於開放式任務，可以沒有 single reference，但必須有「不可違反的條件」（例如「不得包含未出現在使用者輸入中的時間資訊」）。

2. 選擇並適應指標

常見組合：

• 精確比對：適合分類任務。
• ROUGE / BLEU：適合文字生成，但注意它們對同義詞和句式變化不敏感。
• 基於 LLM 的評估：使用 GPT-4 或 Claude 對輸出評分。需要設計清晰的 prompt 和評分標準，否則 LLM judge 會引入自身偏好。
• 自訂規則：適合強約束場景，例如「輸出必須包含 user_name 和 decision 兩個 JSON 欄位」。

檢查項目：

• 你選擇的主指標是否和第一步定義的業務目標對齊？
• 是否加入了「次要指標」來偵測副作用？例如摘要任務除了 ROUGE，還可以用「幻覺偵測」（hallucination rate）作為一票否決指標。

3. 運行與記錄

每次 eval run 必須記錄：

• 模型版本 + 參數（temperature、top_p 等）
• 資料批次標識
• 所有指標的原始分數
• 失敗案例（分數極低或違反約束的輸出）

如果使用 LangSmith 或 MLflow，請確保 metrics 的命名和版本是可追溯的。

失敗點：只關注平均分，忽略分佈

某次 eval 平均得分 0.85，但實際上是 20% 的極端壞例子拉低了整體？還是 80% 的例子都在 0.95 以上？這兩種情況的 avg 可能相同，但業務影響完全不同。 檢查項目： 報告指標時，必須同時輸出 P50、P90、P99 以及失敗模式分佈。

第三步：迷思－四個高頻踩坑點

迷思 1：依賴單一指標

即使你用了「ROUGE + BERTScore + GPT 評分」多個指標，如果它們是相關度高的（例如 ROUGE-L 和 ROUGE-1 高度相關），實際上並沒有提供太多新資訊。你需要選擇正交的指標：一個衡量事實準確性，一個衡量結構，一個衡量使用者偏好。

迷思 2：測試集與訓練集分佈差異過大

有些團隊直接從訓練集拆出測試集，但訓練集往往經過清洗和格式統一，而生產環境的輸入更吵雜。最後 eval 結果好看，上線後卻崩盤。 解決方案： 一定要建立一個獨立的“生產鏡像測試集”，盡量模擬真實流量分佈。

迷思 3：把人工評估當作 gold standard 卻不做一致性校驗

如果你依賴人工評估（例如給 3 個標註員評分），一定要計算 inter-annotator agreement (如 Cohen's Kappa)。如果只有 0.3，表示任務定義有歧義，需要重新設計評估標準。

迷思 4：忽略 eval 本身的代價

每次 eval run 都有計算成本和時間成本。如果你每天跑 100 個測試樣本 × 10 個變體，呼叫雲端 API 的費用可能會超過模型微調的費用。 檢查項目： 定期清理無用 eval 緩存，使用採樣策略（例如只測試 10% 的 outlier 樣本）來平衡覆蓋率和成本。

真實場景：一次失敗的 eval 流程

團隊 A 為客服摘要模型搭建了 eval pipeline，使用 ROUGE-L 和人工評分。結果：ROUGE-L 0.82，人工評分 4.2/5。上線兩天后，客訴率飆升。分析發現：

• 人工評分樣本集中在「無爭議」場景；
• ROUGE-L 對「已退款」這類關鍵實體權重不足；
• 測試集裡沒有覆蓋「使用者包含髒話」或「客服切換語言」的案例。

修復方案：在測試集中加入 5% 的 dirty data（包含拼字錯誤、表情符號、多語言混用），並增加一條「關鍵實體覆蓋度」的硬規則，任何摘要若遺漏了標記為「must_cover」的實體，直接判為失敗。

替代方案：如果 eval 管線跑不起來怎麼辦？

如果你剛開始、算力有限，或是業務場景頻繁變化，可以先不做全量 eval，改為「日誌 + 抽檢 + 規則監控」三步驟：

• 每個輸出記錄到日誌，包含輸入、輸出、timestamp。
• 每天隨機抽取 50 條，由 1 位工程師快速人工標註是否符合基本要求。
• 設定幾個硬規則（如 JSON 格式校驗、長度限制、敏感字詞偵測），失敗則觸發警告。

這套輕量方案可以以較低成本發現問題，直到你的業務進入穩定期後再搭建完整 eval 管線。

總結

一份好的 LLM evals workflow checklist，不應該只是把框架步驟列出來。真正的價值在於：幫你辨識每一步的目標、代價和失敗模式。從問題定義出發，選擇與業務對齊的指標，建立覆蓋邊界的測試集，然後避免常見誤解。如果條件不允許，也可以從輕量方案起步。