交付前如何對微調模型進行 QA

傳統軟體是確定性的。您寫一個測試，它通過或失敗，然後您有信心地發布。AI 模型不是這樣工作的。相同的輸入在不同的運行中可能產生不同的輸出。「正確」是一個範疇，而不是二元的。失敗模式不是崩潰——而是聽起來合理但微妙地、危險地錯誤的答案。

這就是為什麼微調模型的 QA 比傳統軟體的 QA 既更重要又更困難。跳過它，您將向客戶交付讓您出醜的模型。過度設計它，您花在測試上的時間將超過構建的時間。

本指南是實用的中間地帶：一個每個模型需要 4–8 小時的 4 階段 QA 流程，能捕捉真正重要的問題。

為什麼「只是運行測試」不奏效

在進入流程之前，讓我們澄清 AI QA 的不同之處：

不確定性。 相同的提示通過相同的模型運行 10 次，您可能得到 10 個不同的輸出。所有這些可能都是可接受的，或者 9 個可能很好，1 個可能很糟糕。您的 QA 流程需要考慮這種差異。

主觀品質。 「退款將在 3–5 個工作日內處理」比「您的退款應在一週內到達」更好還是更差？兩者在事實上都是正確的。答案取決於客戶的品牌語氣、客戶的期望和他們的內部政策。

分布偏移。 您的模型可能在測試集上得分 96%，但在看起來與測試資料完全不同的輸入上失敗。真實世界的輸入比您創建的任何測試集都更混亂、更模糊、更具對抗性。

級聯效應。 在管道中生成略微錯誤元數據的模型可能導致下游系統以看起來與模型完全無關的方式崩潰。

您需要一個處理所有這些問題的 QA 流程。以下是我們的流程。

第一階段：自動化評估（1–2 小時）

這是基準線。如果您的模型未能通過自動化評估，其他一切都無關緊要——回去重新訓練。

黃金測試集

每個客戶模型都需要一個黃金測試集：100–500 個代表核心用例的輸入和預期輸出示例。這些應該是：

• 代表性的。 涵蓋模型在生產中將看到的所有主要輸入類別。
• 由專家標注的。 不是由另一個 AI 模型生成的。人工標注的黃金標準。
• 版本化的。 測試集隨客戶需求的變化而演進。追蹤您評估的是哪個版本。
• 分層的。 包含適當比例的簡單、中等和困難案例。

要計算的指標

通過新模型運行黃金測試集並計算：

精確度或任務特定的正確性。 對於分類任務，這是直接的精確度或 F1。對於生成任務，使用 ROUGE 分數和對參考輸出的語義相似性的組合。目標：大多數用例超過 90%。

幻覺率。 計算包含輸入或模型知識庫未支持的事實聲明的輸出。對於有基礎的任務（RAG、提取），這應低於 5%。對於開放式生成，低於 10%。

格式符合度。 如果模型應該輸出 JSON，它多久產生有效的 JSON？如果它應該遵循模板，它多久匹配？目標：超過 99%。

延遲。 測量目標硬體上的 P50 和 P95 延遲。如果 P95 超過您的 SLA（對於實時用例通常為 2 秒），您有問題。

回歸檢查

將每個指標與前一個版本進行比較。如果任何指標下降超過 2 個百分點，請標記它。回歸很常見——在一個類別上表現更好的模型通常在另一個類別上略有下降。

創建比較表：

指標              | 前一版本（v1.2） | 新版本（v1.3） | 差異
--------------------|-----------------|------------|------
精確度            | 93.4%           | 95.1%      | +1.7%
幻覺率            | 3.2%            | 2.8%       | -0.4%
格式符合度        | 99.1%           | 99.4%      | +0.3%
P95 延遲          | 1.4 秒          | 1.3 秒     | -0.1 秒
退款類別精確度    | 91.2%           | 88.7%      | -2.5% ⚠️

退款類別的回歸？在上下文中可能是可以接受的（整體精確度提高了），或者如果客戶特別要求您改進退款處理，它可能是個問題。這就是為什麼僅自動化評估還不夠。

第二階段：邊緣案例測試（1–2 小時）

自動化評估告訴您模型在典型輸入上的表現。邊緣案例測試告訴您它如何失敗。

構建邊緣案例集

創建 50–100 個針對客戶領域的對抗性和不尋常輸入。要涵蓋的類別：

模糊輸入。 可以有多種解釋的查詢。模型是尋求澄清還是猜錯了？

邊界輸入。 技術上在範圍內但勉強的請求。一個在合同法上訓練的法律審查模型被問及稅法。

對抗性輸入。 提示注入嘗試、要求忽略指令的請求、嘗試提取系統提示或訓練資料。

空或最小輸入。 空白輸入會發生什麼？一個單詞？一個問號？

極長輸入。 接近或超過上下文視窗的輸入。模型是優雅地截斷，還是產生幻覺？

超出範圍的輸入。 明顯超出模型領域的請求。它是禮貌地拒絕還是自信地生成垃圾？

多語言輸入。 如果客戶用英語運營但有用西班牙語書寫的客戶，會發生什麼？

格式邊緣案例。 具有不尋常格式的輸入——全大寫、無標點、大量使用表情符號、markdown、代碼塊。

邊緣案例評分

對於每個邊緣案例，以 3 分制對輸出評分：

• 通過： 模型適當地處理了它（正確答案、優雅的拒絕、合理的澄清請求）
• 軟失敗： 模型的輸出是次優的，但沒有害（冗長的拒絕、稍微偏題但沒有錯誤）
• 硬失敗： 模型產生了有害的、危險的或完全錯誤的輸出

目標：零硬失敗，軟失敗低於 10%。任何硬失敗都需要在交付前解決——通過額外的訓練資料、提示工程或護欄。

第三階段：人工專家審查（1–2 小時）

自動化指標和邊緣案例測試仍然會錯過領域專家幾秒鐘就能發現的問題。這個階段是關於定性評估的。

審查協議

選擇 20–30 個代表現實生產使用的輸入。不是您的測試集——是模擬客戶用戶實際發送內容的新輸入。包含以下混合：

• 10 個典型的、日常的請求
• 10 個中等複雜的請求
• 5–10 個需要細微差別或判斷的請求

讓一位領域專家（理想情況下是熟悉客戶業務的人）審查每個輸出：

事實正確性。 信息是否準確？是否有自動化指標可能錯過的細微錯誤？

語氣和聲音。 輸出聽起來像客戶的品牌嗎？如果客戶是律師事務所，模型不應該聽起來隨意。如果是消費者應用，它不應該聽起來像法律文書。

完整性。 模型是否解決了問題的所有部分？還是它回答了容易的部分而忽略了困難的部分？

安全性。 是否有任何輸出可能為客戶創造責任？不正確的醫療建議、錯誤的法律解釋、歧視性語言？

記錄發現

對於發現的每個問題，記錄：

• 觸發它的輸入
• 模型說了什麼
• 它應該說什麼
• 嚴重性（嚴重、主要、次要）
• 建議的修復（更多訓練資料、提示調整、護欄）

嚴重和主要問題必須在交付前解決。次要問題記錄為已知限制。

第四階段：客戶驗收測試（1–2 小時）

這是交接。客戶第一次看到他們的模型（或看到更新版本），您一起走過它。

結構化演示

不要只是給客戶一個連結說「試試看」。構建演示：

1. 準備好的示例（15 分鐘）。 走過您預先選定的 5–7 個示例，展示模型的能力。至少包含一個客戶在範圍界定期間特別詢問過的示例。

2. 現場測試（20 分鐘）。 讓客戶輸入他們自己的輸入。這是他們測試對他們重要的事情的地方——您可能沒有想到要測試的事情。

3. 邊緣案例討論（10 分鐘）。 展示 2–3 個邊緣案例，解釋模型如何處理它們。坦誠說明限制：「如果有人問 X，模型會禮貌地拒絕，因為那超出了它的訓練範圍。」

4. 指標審查（10 分鐘）。 走過評估結果。展示與基準的比較。用實際術語解釋這些數字的含義。

5. 問答和反饋（15 分鐘）。 客戶會有問題。一些是技術性的（「我們可以增加上下文視窗嗎？」），一些是業務性的（「我們的產品目錄更改時會發生什麼？」）。誠實回答。

設定通過/失敗標準

在演示之前，商定明確的驗收標準：

如果模型滿足所有自動化閾值，但客戶的利益相關者不滿意，它不通過。客戶的主觀評估很重要，因為他們比您的指標更了解他們的領域。

QA 報告

完成所有四個階段後，將結果編譯成客戶的 QA 報告：

# QA 報告：[客戶] [模型] v[X.Y.Z]
日期：[日期]
QA 負責人：[姓名]

## 方法論
- 自動化評估：[N] 個測試案例，[計算的指標]
- 邊緣案例測試：[N] 個對抗性輸入
- 人工審查：[N] 個類生產輸入，由 [專家姓名] 審查
- 客戶驗收：[日期]，與 [利益相關者姓名]

## 結果摘要
| 指標              | 分數   | 閾值      | 狀態 |
|---------------------|--------|-----------|--------|
| 精確度            | 95.1%  | 超過 90%  | 通過   |
| 幻覺率            | 2.8%   | 低於 5%   | 通過   |
| 格式符合度        | 99.4%  | 超過 99%  | 通過   |
| P95 延遲          | 1.3 秒 | 低於 2 秒 | 通過   |

## 已知限制
1. [具有上下文和解決方案的具體限制]
2. [具有緩解計劃的具體限制]

## 建議監控
- 每週追蹤 [特定指標] 以查漂移
- 如果 [特定條件] 改變，重新評估
- 計劃再訓練：[日期] 或在 [觸發條件] 後

這份報告成為模型版本歷史的一部分。它也是強大的銷售工具——看到這種嚴謹程度的客戶不會質疑您的收費。

時間預算

完整的 QA 流程每個模型需要 4–8 小時：

對於變化是增量性的月度再訓練週期，您通常可以通過重用現有的邊緣案例測試並針對變化進行更短的人工審查，將時間壓縮到 2–4 小時。

4–8 小時很多嗎？與交付糟糕模型的成本相比：客戶升級、緊急再訓練、潛在合同損失、聲譽損失。QA 是您能買到的最便宜的保險。

將 QA 整合到您的工作流程中

不要將 QA 視為一次性的關卡。將它構建到您的標準作業程序中：

1. 每次再訓練後： 完整的 4 階段 QA
2. 配置更改後： 第一階段（自動化評估）+ 第二階段（邊緣案例）
3. 生產中每週： 針對一個小型輪換測試集的自動化評估，以捕捉漂移
4. 每月： 審查 QA 流程本身——更新邊緣案例，刷新測試集，校準閾值

建立嚴格 QA 流程的代理商是那些讓客戶保持數年的。跳過它的代理商讓客戶保持數月。

---

有關模型品質的更多信息，請查看我們的微調品質清單和評估微調模型指南。