如何評估你的微調模型：非技術人員指南

你微調了一個模型。訓練沒有出錯地完成了。損失曲線下降了。接下來呢？

大多數團隊在這一步就部署了。他們手動執行幾個提示，輸出看起來合理，模型就進入了生產環境。兩週後，客戶報告說模型在幻覺不存在的產品功能，或者以破壞下游整合的方式格式化回應。

問題不在模型。問題在於「看起來合理」不是一個評估策略。

評估是微調管道中被跳過最多的步驟。它也是決定你的模型是否真的在生產中有效，還是只在演示中有效的步驟。本指南提供五種實用的評估方法，不需要任何 ML 專業知識——只需要領域知識和系統化的意願。

為何評估比訓練更重要

這裡有一個讓大多數團隊驚訝的數字：一個模型可以達到出色的訓練指標，但在真實生產查詢中仍然失敗 15-30%。訓練損失衡量模型學習訓練資料的程度。它不衡量模型處理從未見過的輸入的程度。

對於向客戶交付模型的代理商來說，「訓練成功」和「在生產中有效」之間的差距是聲譽建立或毀滅的地方。一次高知名度的失敗——一個法律 AI 引用不存在的法規，一個醫療聊天機器人提供不正確的劑量資訊——可以抹去數月的關係建立。

評估不是可有可無的品質步驟。它是你可以有把握收費的模型和你希望能用的模型之間的差異。

方法 1：人工審查抽樣

最簡單也最被低估的評估方法。從你預期的生產流量中抽取 50-100 個代表性輸入，通過模型運行，並由領域專家審查每個輸出。

如何進行：

1. 收集代表你實際使用案例的 50-100 個輸入。如果模型處理客戶支援，使用真實的支援票。如果它生成法律摘要，使用真實的案件摘要。
2. 通過你的微調模型運行每個輸入並捕獲輸出。
3. 讓有領域知識的人按簡單的評分標準評價每個輸出：正確、部分正確或錯誤。
4. 計算你的準確率。對大多數生產使用案例，你希望 90% 以上正確，錯誤低於 5%。

這能捕獲什麼： 自動化指標遺漏的系統性錯誤。一個模型可能在困惑度上得分很好，但一致地誤用行業特定術語。人工審查員立即發現這個問題。

50 個範例的最低要求： 少於 50 個範例，你的準確率估計變化太大，無法有用。在 50 個範例時，如果你看到 45 個正確輸出，你的真實準確率可能在 82%-97% 之間（95% 置信區間）。在 100 個範例時，這個範圍收緊到 87%-96%。更多範例給你更多信心，但 50 個是有意義信號的底線。

專業提示： 不要讓準備訓練資料的人做評估。他們離預期的輸出太近，會無意識地將邊緣案例評為正確。新鮮的眼睛能發現更多問題。

方法 2：與基線的 A/B 比較

並排比較是最具資訊性的評估技術之一，且不需要任何統計背景。

如何進行：

1. 選擇你的基線。這可以是微調前的基礎模型、提示的 GPT-4，或你之前的模型版本。
2. 通過兩個模型運行相同的 50-100 個測試輸入。
3. 向審查員並排呈現輸出（盲測——不要標記哪個是哪個）。
4. 對每對，審查員選擇哪個輸出更好，或標記它們相等。
5. 統計勝、負和平局。

解讀結果： 你的微調模型在與基礎模型的頭對頭比較中應該贏得至少 60%，以證明部署的合理性。如果它贏得少於 50%，訓練出了問題。如果它贏得 50-60%，微調產生了邊際改善——考慮維護自訂模型的運營成本是否值得。

這能捕獲什麼： 退化。微調可以提高你目標任務的表現，同時降低通用能力。A/B 比較揭示模型是否在你的特定任務上變得更好，但在基本推理、語法或遵循指令方面變得更差。

常見失敗模式：微調模型完美地執行輸出格式，但內容品質下降。沒有並排比較，你可能不會注意到，因為輸出乍看之下是對的。

方法 3：黃金測試集

黃金測試集是帶有已知正確輸出的精選輸入集合。它是最接近你的模型的單元測試套件的東西。

如何構建：

1. 從涵蓋你核心使用案例的 30-50 個範例開始。
2. 對每個範例，寫出理想的輸出——你希望模型產生的確切回應。
3. 包含難度層次：60% 直接案例，25% 中等複雜度，15% 困難邊緣案例。
4. 將其儲存為版本化文件（JSONL 效果很好），永不用於訓練。

如何評分：

對分類任務，準確率很直接——模型要麼選擇了正確的類別，要麼沒有。對生成任務，評分需要更多細微差別：

• 完全匹配率： 多少百分比的輸出與黃金答案完全匹配？對結構化輸出如 JSON 或類別標籤很有用。
• 語義匹配率： 多少百分比在功能上等同，即使措辭不同？需要人工判斷。
• 關鍵事實包含率： 對事實任務，列出每個答案必須包含的 3-5 個事實。評分所需事實存在的百分比。

關鍵規則： 永不在你的黃金測試集上訓練。測試範例一旦洩漏到訓練資料，你的評估就變得毫無意義。分開保存這些文件，並定期審計以確保沒有污染。

隨時間維護： 每月從真實生產失敗案例中添加 5-10 個新範例。模型在生產中出錯的案例是最有價值的測試案例，因為它們代表了真實的差距。

方法 4：邊緣案例測試組

邊緣案例是微調模型失敗最劇烈的地方。一個模型可以完美地處理 95% 的標準查詢，但在剩餘的 5% 上完全崩潰——而那 5% 通常是客戶記得的案例。

圍繞這些類別構建你的邊緣案例測試組：

模糊輸入。 可以多種方式解釋的查詢。行為良好的模型應該要求澄清，或者處理最可能的解釋同時承認替代方案。

超出範圍的輸入。 模型不應該回答的查詢。如果你微調了一個法律文件摘要器，當有人要求它寫行銷文案時會發生什麼？模型應該優雅地拒絕，而不是幻覺一個回應。

對抗性輸入。 旨在破壞模型的輸入——提示注入嘗試、極長的輸入、意外語言的輸入、包含矛盾資訊的輸入。你需要 10-20 個這樣的輸入。

邊界條件。 你預期範圍極端的輸入。可能最短的有效輸入。最長的。具有不尋常格式的輸入。結合多個子任務的輸入。

如何運行：

創建一個包含這些類別的 30-50 個邊緣案例的電子表格。對每個案例，定義預期的行為（不一定是特定的輸出，而是什麼類別的回應是可接受的）。通過模型運行它們，並標記任何行為意外的案例。

通過標準： 零災難性失敗（無冒犯性輸出，無危險建議，無資料洩漏）。至少 80% 的邊緣案例得到優雅處理。識別的失敗模式記錄用於客戶溝通。

方法 5：生產監控

評估不會在部署時結束。最重要的評估發生在生產環境中，真實用戶在那裡生成你從未預料到的輸入。

監控什麼：

• 輸出長度分佈。 平均輸出長度的突然變化通常表明有問題。如果你的模型通常生成 200 字的回應，開始產生 50 字的回應，某些東西改變了。
• 拒絕率。 追蹤模型拒絕回答的頻率。拒絕率的突然上升可能表明模型過於保守，或者它正在接收分佈外的輸入。
• 每個請求的延遲。 微調模型應該有一致的推論時間。延遲峰值可能表明輸入處理問題。
• 用戶回饋信號。 如果你的應用程式包含點讚/點踩或重試行為，追蹤這些。超過 15% 的重試率表明用戶對首次嘗試輸出不滿意。
• 按輸入類別的錯誤率。 按查詢類型細分表現。你可能發現模型完美地處理類別 A，但在類別 B 上很吃力——這些資訊驅動你的下一次訓練資料收集。

持續審查的抽樣： 即使在部署後，每週仍從生產輸出中隨機抽取 20-30 個進行人工審查。這能捕獲自動化指標遺漏的緩慢退化。如果你的週準確率低於基線，立即調查。

常見評估錯誤

錯誤 1：在訓練資料上評估。 如果你的測試範例與訓練範例重疊，你的準確率數字毫無意義。模型不是在展示泛化能力——它在展示記憶能力。

錯誤 2：只評估正常路徑輸入。 運行 50 個標準查詢並看到 50 個正確輸出並不意味著模型有效。它意味著模型在標準查詢上有效。邊緣案例是生產失敗的所在地。

錯誤 3：使用單一指標。 單靠準確率告訴你的資訊不夠。一個準確率 90% 但在 2% 的輸入上災難性失敗（產生冒犯性或危險內容）的模型，比一個準確率 85% 但優雅失敗的模型更差。

錯誤 4：評估一次就部署。 模型本身不會退化，但生產流量確實會隨時間變化。每月重新評估能在客戶注意到之前捕獲分佈偏移。

錯誤 5：因為信任訓練資料而跳過評估。 好的訓練資料是必要的，但不是充分的。模型可能從正確的資料中學到錯誤的模式——過擬合到表面特徵而不是底層任務。

Ertas Studio 如何協助評估工作流程

Ertas Studio 包含為沒有 ML 專業知識的團隊設計的內建評估工具：

並排比較介面。 通過多個模型版本運行測試輸入，並以乾淨可審查的格式比較輸出。不需要腳本。

黃金測試集管理。 上傳你的測試集一次，只需點擊一下就能在每個新模型版本上重新運行它。自動追蹤各版本間的準確率趨勢。

匯出評估報告。 生成顯示模型在你的測試套件中表現的可分享報告——用於客戶演示和內部審批。

目標是使評估與訓練同樣容易。如果評估需要 Python 腳本和 Jupyter 筆記本，大多數團隊會跳過它。如果評估需要點擊按鈕並審查表格，大多數團隊實際上會去做。

---

延伸閱讀

• Fine-Tuning vs. RAG: Which Approach Is Right? — 理解首先何時微調是正確選擇
• How to Fine-Tune an LLM — 微調過程的完整演示
• Fine-Tuning Quality Checklist: 10 Tests Before Deploying to Clients — 與本評估指南配套使用的部署前清單