Back to blog
    微調品質檢查清單:部署到客戶前的 10 項測試
    quality-assurancefine-tuningdeploymentchecklistsegment:agency

    微調品質檢查清單:部署到客戶前的 10 項測試

    代理商和團隊在將微調模型部署到客戶前的 10 點品質檢查清單——涵蓋準確率基準測試、幻覺偵測、格式合規性、延遲和安全防護。

    EErtas Team··Updated

    你訓練了一個模型。指標看起來不錯。客戶演示進展順利。現在你的團隊中有人問了這個將專業代理商與業餘愛好者區分開來的問題:「我們真的準備好發布這個了嗎?」

    大多數代理商無法自信地回答這個問題。他們有直覺——「測試中看起來不錯」——但沒有系統化流程。這份清單解決了這個問題。十個具體測試,每個都有明確的通過/失敗標準,在每次客戶部署之前運行。

    把這份清單打印出來。把它放在你的項目模板中。不要因為時間緊迫就跳過步驟。這份清單需要 2-3 小時,將讓你免於在糟糕部署之後的 20-30 小時緊急調試和客戶危機管理。

    測試 1:黃金測試集準確率

    要檢查什麼: 通過微調模型運行你的黃金測試集(50-100 個從未用於訓練的具有已知正確輸出的範例)。計算準確率。

    如何檢查: 準備一個帶有輸入-輸出對的 JSONL 文件。通過模型運行每個輸入。對於分類任務,檢查精確匹配。對於生成任務,讓領域專家將每個輸出評為正確、部分正確或錯誤。

    通過標準:

    • 分類任務:92% 以上準確率
    • 生成任務:85% 以上評為正確,低於 5% 評為錯誤
    • 沒有單個錯誤類別佔總測試案例的 3% 以上

    失敗措施: 如果準確率低於閾值,找出錯誤模式。通常修復方法是添加 50-100 個針對失敗案例的有針對性訓練範例並重新訓練。不要發布並希望它能自行解決。

    測試 2:幻覺率

    要檢查什麼: 模型生成聽起來合理但事實上不正確的資訊的頻率?這對法律、醫療和財務使用案例尤其關鍵。

    如何檢查: 選擇 30 個測試輸入,其中正確答案涉及具體事實——姓名、日期、數字、引用、產品詳細資訊。通過模型運行它們。根據你的源材料驗證每個輸出中的每個事實聲明。

    通過標準:

    • 高風險領域(法律、醫療、財務)零幻覺事實
    • 一般商業使用案例幻覺率低於 3%
    • 當模型沒有資訊時,它應該表達不確定性而不是捏造

    失敗措施: 幻覺通常意味著訓練資料太小或模型在模式上過擬合而不是學習事實。請參閱我們的微調模型幻覺指南了解具體的緩解策略。考慮添加 RAG 層進行事實基礎。

    測試 3:格式合規性

    要檢查什麼: 模型是否始終以客戶應用程式期望的精確格式生成輸出?以錯誤格式生成完美內容的模型將破壞每個下游整合。

    如何檢查: 運行 50 個測試輸入,並以程式方式根據你的格式規格驗證每個輸出。如果輸出應該是 JSON,則解析它。如果它應該遵循帶有特定部分的模板,則檢查每個部分。如果它應該保持在字數限制下,則計算字數。

    通過標準:

    • 98% 以上格式合規率
    • 零輸出會導致下游解析錯誤
    • 格式邊緣案例的一致處理(空字段、特殊字符、Unicode)

    失敗措施: 格式問題是最容易修復的。添加 20-30 個具有正確格式的範例並重新訓練。如果模型在 JSON 輸出上不一致,在系統提示中添加明確的格式指令作為雙重保障。

    測試 4:延遲基準測試

    要檢查什麼: 模型是否滿足客戶使用案例的響應時間要求?每個響應需要 8 秒的模型對於批次處理可能沒問題,但對於實時聊天界面是不可接受的。

    如何檢查: 運行 100 個測試輸入,測量每個的首個 token 時間和總生成時間。計算 p50(中位數)、p90(第 90 百分位數)和 p99(第 99 百分位數)延遲。

    通過標準:

    • p50 延遲滿足客戶要求(通常聊天低於 1 秒,文件處理低於 5 秒)
    • p99 延遲不超過 p50 的 3 倍(表示一致的性能)
    • 沒有請求超時或掛起

    失敗措施: 延遲主要是模型大小和硬體的函數。如果模型太慢,考慮更小的基礎模型、增加量化或升級部署硬體。從 Q8 切換到 Q4 量化通常在對品質影響最小的情況下減少延遲 30-40%。

    測試 5:邊緣案例處理

    要檢查什麼: 當模型收到預期範圍之外的輸入時它的行為如何?空輸入、極長輸入、錯誤語言的輸入、矛盾的指令、提示注入嘗試。

    如何檢查: 準備跨這些類別的 20-30 個邊緣案例輸入:

    • 5 個空或幾乎為空的輸入
    • 5 個比典型長 5-10 倍的輸入
    • 5 個超出範圍的請求(要求模型做它沒有被訓練的事情)
    • 5 個對抗性輸入(提示注入、越獄嘗試)
    • 5 個客戶領域特定的邊界案例

    通過標準:

    • 零災難性失敗(冒犯性內容、資料洩露、系統提示暴露)
    • 至少 80% 的邊緣案例優雅降級(禮貌拒絕或合理的盡力響應)
    • 沒有無限循環、空輸出或亂碼文本

    失敗措施: 將失敗的邊緣案例(帶有正確處理範例)添加到訓練資料中並重新訓練。對於對抗性健壯性,添加 10-20 個模型正確拒絕提示注入嘗試的範例。

    測試 6:偏見和公平性檢查

    要檢查什麼: 模型是否公平對待不同的人口群體、地區或使用案例細分?微調模型中的偏見通常來自不平衡的訓練資料。

    如何檢查: 創建 20 對測試輸入,其中唯一差異是人口變量(姓名、位置、性別、年齡)。通過模型運行兩個版本。比較輸出在語氣、品質或建議方面的有意義差異。

    通過標準:

    • 不同人口群體之間輸出品質沒有統計顯著差異
    • 沒有基於人口資訊的刻板印象或假設
    • 無論輸入的隱含人口統計如何,語氣和幫助性都保持一致

    失敗措施: 審計你的訓練資料的人口不平衡。如果 90% 的訓練範例涉及一個人口群體,模型對其他人的表現會較差。平衡資料集並重新訓練。

    測試 7:安全防護

    要檢查什麼: 模型是否拒絕生成有害、非法或不適當的內容?微調可能削弱基礎模型的安全訓練,特別是如果你的訓練資料包含突破邊界的範例。

    如何檢查: 運行 15-20 個請求的測試輸入:

    • 有害指令(暴力、自我傷害、非法活動)
    • 私人資訊生成(假社會安全號碼、信用卡號碼)
    • 違反客戶品牌指南的內容
    • 應包含免責聲明的醫療或法律建議

    通過標準:

    • 對真正有害請求 100% 拒絕率
    • 對專業建議(法律、醫療、財務)有適當的免責聲明
    • 即使在創意提示下也不生成私人資料模式
    • 輸出符合客戶的品牌聲音和內容政策

    失敗措施: 如果安全防護被削弱,你可能需要在訓練資料中添加明確的拒絕範例。包括 20-30 個模型正確拒絕有害請求的範例。對於品牌一致性,添加展示正確語氣和邊界處理的範例。

    測試 8:A/B 與基線的比較

    要檢查什麼: 微調模型實際上比替代方案更好嗎?基線可能是帶有良好系統提示的基礎模型、提示的 GPT-4,或客戶的當前解決方案。

    如何檢查: 通過微調模型和基線運行 50 個測試輸入。向盲目審查員(他們不知道哪個輸出來自哪個模型)呈現輸出對。審查員為每對選擇更好的輸出或將其標記為相等。

    通過標準:

    • 微調模型在至少 60% 的頭對頭比較中獲勝
    • 微調模型沒有任何類別一致輸給基線
    • 在客戶關心的特定任務上品質改進是明顯的

    失敗措施: 如果微調模型沒有明顯超越基線,則微調效果不夠好,不足以証明部署的合理性。重新審視訓練資料的品質和數量。有時誠實的答案是對於這個使用案例,帶有前沿模型的提示工程已經足夠好了。

    測試 9:每次推理成本

    要檢查什麼: 運行此模型的運營成本是否符合客戶的預算和你的利潤要求?每個請求花費 $0.50 的模型與花費 $0.005 的模型是截然不同的商業主張。

    如何檢查: 根據你的部署設置計算每次推理成本:

    • 對於自托管:(每小時 GPU 成本)/(目標延遲下每小時請求數)
    • 對於雲部署:(每小時實例成本)/(測量的吞吐量)
    • 包括所有成本:計算、存儲、網絡傳輸、監控

    通過標準:

    • 每次推理成本低於客戶的規定預算
    • 代理商利潤至少 40%(如果你按每次推理向客戶收費)
    • 預計規模(3 倍、10 倍當前量)的成本仍然可行

    失敗措施: 優化部署。切換到更小的量化等級、批次請求、使用更小的模型變體或調整部署硬體。如果成本對於使用案例根本太高,在部署之前而不是之後第一張發票到來時與客戶進行誠實的對話。

    測試 10:客戶驗收標準

    要檢查什麼: 模型是否滿足客戶在項目啟動時定義的具體標準?這是最重要的測試,因為它衡量客戶真正關心的事情。

    如何檢查: 查看你的工作範圍或項目啟動的驗收標準。對於每個標準,準備 10-20 個直接驗證它的測試案例。運行測試並記錄結果。

    常見的客戶驗收標準:

    • 「必須正確分類 95% 的支援票」
    • 「必須生成符合我們品牌聲音的響應」
    • 「必須在 3 秒內處理文件」
    • 「必須處理西班牙語輸入」
    • 「不得將一個部門的資訊洩露給另一個部門」

    通過標準: 所有客戶定義的驗收標準都得到滿足。如果某個標準不明確,記錄你的解讀並在部署之前獲得客戶簽字確認。

    失敗措施: 如果特定驗收標準失敗,優先在所有其他問題之上修復這些問題。通過你的 10 個內部測試中的 9 個但未能滿足客戶主要標準的模型沒有準備好發布。

    在實踐中運行清單

    時間估計: 徹底運行所有 10 個測試需要 2-4 小時。第一次花費更長時間(建立測試集、設置評估腳本)。後續運行更快,因為你重用和擴展測試資產。

    由誰做: 理想情況下,運行清單的人不是訓練模型的人。新的眼睛發現更多問題。如果你的團隊很小,至少讓其他人審查邊緣案例和安全測試。

    何時運行:

    • 每次客戶部署之前(不可商量)
    • 每次重新訓練周期之後
    • 對於生產模型,即使沒有更改也要每月進行(捕捉漂移)
    • 任何客戶報告問題後立即進行

    文件: 記錄每次清單運行的結果。日期、模型版本、測試集版本、每個測試的通過/失敗,以及任何邊緣案例的備注。這創建了對客戶信任和你自己的品質追蹤都有價值的審計追蹤。

    Ship AI that runs on your users' devices.

    Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

    最重要的一條規則

    如果測試失敗,不要發布。沒有「我們會在下一個版本中修復」的選項,因為生產模型正在處理真實的客戶資料。失敗部署的成本——客戶信任、緊急調試、潛在的法律責任——總是超過將發布延遲幾天修復問題的成本。

    建立可靠性聲譽的代理商收費更高、留住客戶更長、並獲得推薦。這份清單是你系統地建立這種聲譽的方法。


    延伸閱讀

    Ship AI that runs on your users' devices.

    Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.

    Keep reading