生產環境 A/B 測試：雲端 API vs 裝置端 AI

您在生產環境中有一個雲端 AI 功能。您有一個微調好的裝置端模型準備部署。在將所有使用者遷移之前，您需要證據表明裝置端模型的品質能達到或超過雲端模型。

生產環境中的 A/B 測試可以在真實使用者、真實查詢和真實行為上提供這些證據。

測試什麼

目標不是證明裝置端模型「和」雲端模型一樣好。目標是衡量使用者是否注意到或在意任何差異，並量化營運方面的改進（延遲、成本、離線能力）。

主要指標

次要指標

應避免的指標

模型品質分數（困惑度、BLEU、ROUGE）： 使用者不關心困惑度。他們關心功能是否解決了問題。自動化品質指標在開發中有用，但不適合作為 A/B 測試的主要指標。

回覆長度： 更長不代表更好。更短不代表更差。長度不能代表任何有用的資訊。

分組設計

隨機分配

在首次 AI 互動時將使用者分配到組：

fun getAiCohort(userId: String): AiCohort {
    // 確定性雜湊確保同一使用者始終在同一組
    val hash = userId.hashCode().absoluteValue
    return if (hash % 100 < 50) AiCohort.CLOUD else AiCohort.ON_DEVICE
}

使用使用者 ID 雜湊（而非隨機數），這樣每個使用者在各次工作階段中始終保持在同一組。

分組大小

在 10K MAU 下 50/50 分組，每組 5,000 使用者。兩週可以得到 5% 以上差異的統計顯著結果。

漸進式發布

從保守開始：

1. 第 1 週： 10% 裝置端，90% 雲端（捕捉當機和關鍵問題）
2. 第 2 週： 25% 裝置端，75% 雲端（收集初步指標）
3. 第 3-4 週： 50/50（具有統計功效的完整 A/B 測試）
4. 結果出來後： 如果指標通過則推進到 100% 裝置端

實作架構

AI 提供者抽象

兩種變體應透過相同的介面：

interface AiProvider {
  generate(prompt: string, options: GenerateOptions): Promise<AiResponse>;
  isAvailable(): boolean;
}

class CloudProvider implements AiProvider {
  async generate(prompt, options) {
    const response = await callCloudAPI(prompt, options);
    return { text: response.text, source: "cloud", latencyMs: response.latency };
  }
  isAvailable() { return navigator.onLine; }
}

class OnDeviceProvider implements AiProvider {
  async generate(prompt, options) {
    const response = await llamaGenerate(prompt, options);
    return { text: response.text, source: "on_device", latencyMs: response.latency };
  }
  isAvailable() { return this.modelLoaded; }
}

路由

function getProvider(userId: string): AiProvider {
  const cohort = getAiCohort(userId);

  if (cohort === "on_device" && onDeviceProvider.isAvailable()) {
    return onDeviceProvider;
  }

  // 如果裝置端模型尚未載入，回退到雲端
  return cloudProvider;
}

事件記錄

記錄每次 AI 互動的分組和指標：

function logAiInteraction(event: AiInteractionEvent) {
  analytics.track("ai_interaction", {
    cohort: event.cohort,           // "cloud" 或 "on_device"
    action: event.action,           // "generate", "accept", "retry", "abandon"
    latency_ttft_ms: event.ttft,    // 首個 token 時間
    latency_total_ms: event.total,  // 總回應時間
    tokens_generated: event.tokens,
    user_action: event.userAction,  // 使用者之後的操作（傳送、編輯、關閉）
    offline: !navigator.onLine,
    device_model: getDeviceModel(),
    timestamp: Date.now(),
  });
}

分析結果

統計顯著性

對比率指標（完成率、重試率）使用卡方檢驗，對連續指標（延遲、操作時間）使用 t 檢驗。

最低置信水準：95%（p 值小於 0.05）。對於關鍵指標，使用 99%。

預期結果

基於典型的裝置端 vs 雲端遷移案例：

何時發布裝置端版本

如果：

• 任務完成率在雲端的 3% 以內（沒有統計顯著性地更差）
• 當機率沒有增加
• 延遲明顯更好（預期如此）
• 功能參與度穩定或改善

不要發布如果：

• 任務完成率顯著下降（超過 5% 的下降）
• 當機率增加（某些裝置上的記憶體問題）
• 裝置端組的使用者滿意度明顯更低

何時迭代

如果裝置端模型在任務完成率上表現不佳但在延遲和參與度上獲勝，那麼模型品質需要改進。選項：

• 新增更多訓練資料並重新訓練
• 切換到更大的模型（1B 到 3B）
• 改進微調（更多 epoch、不同的超參數）
• 擴展訓練資料以涵蓋失敗的場景

用改進後的模型重新執行 A/B 測試。

邊界情況

裝置端模型尚未下載

裝置端組中尚未下載模型的使用者應回退到雲端。追蹤裝置端組完全啟用（所有使用者都有模型）所需的時間。

裝置能力不匹配

某些使用者的裝置可能不支援裝置端模型（RAM 不足）。這些使用者無論分組如何都應使用雲端。追蹤裝置端組中回退到雲端的百分比以及對應的裝置型號。

離線對比

裝置端組有一個雲端組沒有的能力：離線 AI。單獨追蹤離線 AI 使用。這是增量價值，不會出現在直接的品質對比中。

商業論證

A/B 測試為遷移決策提供資料：

• 品質差異：使用者體驗是否相當？
• 成本差異：雲端組每月花費多少？
• 參與度差異：使用者是否更多地與更快的 AI 互動？
• 新增能力：離線 AI 使用有多少？

對於大多數微調良好的模型，A/B 測試證實了工程團隊的預期：相當的品質、更好的延遲、零成本，加上離線能力。資料使遷移決策變得簡單直接。

微調品質是關鍵變數。Ertas 等平台支援快速迭代：用改進的資料重新訓練，匯出 GGUF，部署到裝置端組，再次衡量。