生产环境 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，部署到端侧组，再次测量。