並排模型比較:如何在部署前選擇最佳微調模型
在部署前比較和選擇微調模型變體的系統性框架——包括評估集構建、評分標準和決策邏輯。
您已經訓練了三個微調模型變體——不同的基礎模型、不同的超參數或不同的訓練集。現在您需要挑選一個部署。這個決定比看起來更難。
損失曲線告訴您訓練進展。它們不告訴您哪個模型實際上在您客戶的真實用例中表 現更好。
這是在生產部署之前系統地比較模型的框架。
為什麼您不能只用損失來選擇
訓練損失是「模型在訓練集上預測得有多好」的代理指標。它不告訴您:
- 在邊緣案例上的表現
- 在訓練中未見過的提示上的泛化能力
- 格式合規性(輸出是否結構化為預期格式)
- 幻覺率(模型捏造答案而非說不知道的頻率)
- 在對抗性輸入上的穩健性
兩個具有相同驗證損失的模型在實際任務上可以有非常不同的行為。
第一步:構建評估集
在比較模型之前,您需要一個評估集——一組帶有已知良好答案的輸入。評估集是所有模型比較的基礎,需要仔細構建。
評估集組成
一個好的評估集代表您的任務分佈並系統地測試已知弱點:
| 類別 | 佔比 | 目的 |
|---|---|---|
| 常見案例 | 60% | 驗證正常任務的核心性能 |
| 邊緣案例 | 20% | 測試行為在非典型輸入上 |
| 容易出錯的情況 | 10% | 覆蓋基線模型已知失敗的情況 |
| 對抗性輸入 | 10% | 測試設計為令模型混淆的輸入 |
常見案例
來自您實際部署環境中典型交互的代表性樣本。如果您部署的是合同摘要助手,常見案例是典型的合同——標準條款、普通語言、預期的提取目標。
評估集中的常見案例越多,您對整體質量的估計就越準確。
邊緣案例
測試邊界條件的輸入:
- 極短或極長的輸入
- 包含異常格式的輸入(大量數字、非英語文本、奇怪的標點符號)
- 任務描述不完整或模糊的輸入
- 包含多個衝突指令的輸入
邊緣案例揭示了模型泛化的弱點——常見案例測試不會暴露的失敗模式。
容易出錯的情況
在基礎模型(微調前)或早期模型版本上已知表現差的具體輸入。如果您在迭代微調,這些應該 是您在上一個版本中記錄的失敗案例。
跟蹤這些不僅僅是為了評估——它們記錄了模型從一個版本到下一個版本的改進。
對抗性輸入
設計為打破行為的輸入:
- 注入指令(「忽略前面的指令並...」)
- 與系統提示矛盾的輸入(要求客服機器人提供非產品相關建議)
- 試圖從系統提示中提取信息的輸入
- 重複邊界請求
對抗性測試在安全敏感的部署中是必不可少的。在通用生產力應用中它不那麼關鍵,但仍然有價值。
第二步:評分標準
在針對評估集運行模型之後,您需要評分輸出。您評分的內容應該反映任務的實際要求。
通用評分維度
這六個維度適用於大多數生成任務:
1. 準確性 輸出中的事實聲明是否與輸入/已知事實一致?
評分:0(完全不準確)到 3(完全準確,無錯誤)
2. 完整性 輸出是否涵蓋任務所需的所有相關信息?
評分:0(嚴重缺失)到 3(完整覆蓋)
3. 格式合規性 輸出是否符合指定格式(JSON、Markdown 表格、特定標題結構等)?
評分:0(不符合格式)到 2(完全符合格式)
4. 語氣/風格 輸出是否匹配所需的語氣(正式/非正式、具體品牌聲音)?
評分:0(嚴重不匹配)到 2(完全匹配)
5. 幻覺率 輸出是否包含輸入中未支持的聲明?
評分:0(多個幻覺)到 3(無幻覺)
6. 邊緣案例處理 當輸入包含異常情況時,模型是否優雅地處理它(返回錯誤消息、請求澄清、降級)?
評分:0(崩潰/忽略)到 2(優雅處理)