在生產環境中 A/B 測試你的微調模型與 GPT-4

你已經在領域資料上微調了一個模型。評估結果看起來很有前景。離線測試顯示在你的特定任務上準確率與 GPT-4 匹配。但部署到生產環境感覺有風險——如果它在你的評估資料集未捕捉到的方面對真實使用者更差怎麼辦？

答案不是猜測。而是 A/B 測試。將一定比例的生產流量路由到你的微調模型，衡量結果，並隨著信心建立逐步遷移。

路由架構

最簡單的實作：一個 API 閘道器，根據分流比例將請求路由到你的雲端 API 或本地微調模型。

User Request
     ↓
API Gateway (router)
     ↓
┌─────────────────────┐
│  10% → Ollama       │  (fine-tuned model, local)
│  90% → OpenAI API   │  (GPT-4o, cloud)
└─────────────────────┘
     ↓
Log: model_used, input, output, metrics
     ↓
Response to User

實作選項：

簡單： 每個請求隨機分配（Math.random() 不到 0.1 → Ollama，否則 → OpenAI）
更好： 按使用者工作階段一致分配（同一使用者在工作階段中始終獲得相同模型，防止不一致行為）
最佳： 功能旗標服務（LaunchDarkly、PostHog、自定義），讓你無需部署即可調整分流

Ollama 和 OpenAI 都暴露 OpenAI 相容的 API，所以路由器的工作只是 URL 切換。請求格式完全相同。

衡量什麼

主要指標（業務成果）

這些告訴你微調模型是否產生與 GPT-4 相同的使用者成果：

指標	衡量什麼	如何捕捉
任務完成率	使用者是否完成了他們要做的事？	追蹤下游操作（例如使用者在支援回應後點擊「已解決」）
使用者滿意度	使用者對 AI 輸出滿意嗎？	對回應按讚/倒讚、NPS 或 CSAT
錯誤率	模型是否產生了需要人工修正的輸出？	追蹤手動覆蓋或修正
轉換影響	AI 功能是否驅動了期望的業務行為？	追蹤 AI 互動下游的轉換事件

次要指標（模型品質）

這些告訴你模型的技術效能：

指標	衡量什麼
回應延遲	從請求到完成回應的時間（本地應更快）
格式合規性	符合預期輸出結構的回應百分比
幻覺率	回應中的事實錯誤（需要抽查審查）
備用率	模型產生非回應或錯誤的頻率

成本指標

指標	GPT-4o	微調本地模型
每次請求成本	$0.003-0.01	約 $0
月成本（測試流量下）	追蹤實際支出	硬體成本（固定）
100% 時的預估月成本	從測試推算	相同的固定成本

需要多少查詢

A/B 測試需要統計顯著性。所需的查詢數量取決於你試圖偵測的差異和你目前的指標：

經驗法則： 要以 95% 的信心偵測任務完成率 5% 的差異：

如果目前比率是 80%：每個變體約 1,500 個查詢
如果目前比率是 90%：每個變體約 3,500 個查詢
如果目前比率是 95%：每個變體約 7,300 個查詢

每天 500 個查詢，10% 的分流每天向微調模型發送約 50 個查詢。以這個速度：

偵測 5% 的差異：約 30-70 天
偵測 10% 的差異：約 7-18 天

實務建議： 無論流量如何，至少運行測試 2 週，以捕捉星期幾和時段的模式。

漸進遷移路徑

階段 1：驗證（10% 流量，2-4 週）

將 10% 的流量路由到微調模型。監控所有指標。目標不是證明微調模型更好——而是證明它沒有顯著更差。

通過標準：

任務完成率在 GPT-4 的 3% 以內
錯誤率沒有增加
使用者投訴沒有增加
格式合規性達到你的門檻

如果微調模型未達這些標準，不要放棄它。調查失敗原因，為失敗模式添加訓練範例，重新訓練，然後再次測試。

階段 2：擴展（50% 流量，2-4 週）

如果階段 1 通過，增加到 50%。在這個流量下，你會看到更罕見的邊界案例出現。監控相同的指標。

這個階段也測試基礎設施：你的本地硬體能處理 50% 的生產流量嗎？負載下有延遲問題嗎？Ollama 在持續請求量下表現良好嗎？

階段 3：大多數（90% 流量，1-2 週）

翻轉比例：90% 微調，10% GPT-4。GPT-4 路徑作為控制組和備用。這是你的「軟啟動」——微調模型處理絕大多數流量，但你仍有安全網。

階段 4：完全遷移（100% 流量）

停用 GPT-4 路徑。所有流量通過你的微調模型。保持 GPT-4 憑證處於啟用狀態以便緊急回滾。

總遷移時間線： 從第一次測試到完全遷移需要 6-12 週。這個時間線感覺很慢，但你獲得的信心值得耐心等待。將糟糕的模型推送給 100% 的使用者比多花一個月測試要昂貴得多。

常見 A/B 測試結果

基於典型的 fine-tuning 結果：

結果 1：微調模型在領域任務上獲勝

最常見的結果。微調模型在你的特定領域任務上超越 GPT-4——更好的準確率、更一致的格式、更少關於你產品的幻覺。

行動： 遷移到微調模型。成本節省是品質提升之上的額外獎勵。

結果 2：微調模型與 GPT-4 匹配

微調模型產生等效的結果。指標在彼此的雜訊範圍內。

行動： 遷移到微調模型。以大幅降低的成本獲得相同品質是一個簡單的決定。

結果 3：微調模型在特定場景上落後

微調模型處理 90% 的案例很好，但在特定子集上有困難——不尋常的查詢、複雜的多步驟推理，或訓練資料中代表不足的場景。

行動： 兩個選項：

為失敗場景添加訓練範例並重新訓練
使用混合方法：微調模型處理 90%，GPT-4 備用處理 10%（仍有大量成本節省）

結果 4：微調模型顯著更差

當你先做了適當的離線評估時，這很少發生。如果發生了：

檢查你的訓練資料品質（資料品質檢查清單）
驗證量化是否導致問題（測試 Q8_0 而非 Q4_K_M）
確保基礎模型適合你的任務
考慮你的任務是否真正需要前沿智能（何時不該 fine-tune）

實作建議

記錄一切

記錄兩個變體的每個請求和回應。你需要這些資料來：

除錯微調模型的失敗
為下一個重新訓練週期建立訓練資料
向利害關係人證明遷移是資料驅動的

使用相同的 Temperature

在測試期間為兩個模型設定 temperature = 0（或固定的低值）。可變的 temperature 引入雜訊，使比較更困難。

測試完整的流程

不要只測試模型輸出品質。測試完整的流程：請求 → 模型 → 回應解析 → 下游操作。一個以略有不同的格式產生正確輸出的模型可能會破壞你的解析器。

準備回滾計畫

即使在完全遷移後也保持 GPT-4 路徑可運作。如果生產環境出了問題，你應該能在幾分鐘內切換回 GPT-4。這是配置變更，不是部署。

與團隊溝通

讓客服、業務和其他團隊知道測試。如果使用者回報品質差異，支援人員需要知道哪個模型提供了回應（檢查你的日誌）。

開始使用

在 Ertas 上 fine-tune 你的模型，並用你的評估資料集進行離線驗證
通過 Ollama 部署，與你現有的 OpenAI 整合並行
實作簡單的路由器（10% Ollama / 90% OpenAI）
添加所有指標的日誌（任務完成率、滿意度、錯誤、延遲、成本）
運行階段 1 持續 2-4 週
分析結果，如有需要調整訓練，然後推進各階段

A/B 測試消除了遷移的風險。你不是在猜測你的微調模型是否夠好——你是在衡量它。在大多數情況下，資料顯示：它更好且更便宜。