生产环境 A/B 测试：云端 API vs 端侧 AI

您在生产环境中有一个云端 AI 功能。您有一个微调好的端侧模型准备部署。在将所有用户迁移之前，您需要证据表明端侧模型的质量能达到或超过云端模型。

生产环境中的 A/B 测试可以在真实用户、真实查询和真实行为上提供这些证据。

测试什么

目标不是证明端侧模型"和"云端模型一样好。目标是衡量用户是否注意到或在意任何差异，并量化运营方面的改进（延迟、成本、离线能力）。

主要指标

指标	为什么重要	如何衡量
任务完成率	用户是否得到了所需内容？	导致用户操作（发送、保存、接受）的 AI 交互百分比
功能参与度（D7/D30）	用户是否持续使用 AI 功能？	7/30 天内回到 AI 功能的比率
首次操作时间	UX 是更快还是更慢？	从查询到用户下一个操作的时间
错误/重试率	AI 是否失败或令人沮丧？	用户重试或放弃的交互百分比

次要指标

指标	为什么重要
延迟（TTFT，完整响应）	端侧应该更快，但需验证
每用户成本	云端组有 API 成本；端侧约 $0
离线使用	端侧组应在离线条件下展示 AI 使用
应用崩溃率	端侧模型加载可能导致内存问题
电池影响	端侧推理使用设备资源

应避免的指标

模型质量分数（困惑度、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 哈希（而非随机数），这样每个用户在各次会话中始终保持在同一组。

分组大小

测试时长	每组用户数	可检测效应大小
1 周	500	10% 以上的差异
2 周	1,000	5-7% 的差异
4 周	2,500	3-5% 的差异

在 10K MAU 下 50/50 分组，每组 5,000 用户。两周可以得到 5% 以上差异的统计显著结果。

渐进式发布

从保守开始：

第 1 周： 10% 端侧，90% 云端（捕捉崩溃和关键问题）
第 2 周： 25% 端侧，75% 云端（收集初步指标）
第 3-4 周： 50/50（具有统计功效的完整 A/B 测试）
结果出来后： 如果指标通过则推进到 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 云端迁移案例：

指标	预期云端	预期端侧	方向
延迟（TTFT）	500-2,000ms	50-200ms	端侧明显更优
任务完成率	基线	-2% 到 +3%	通常相当
功能参与度（D7）	基线	+0% 到 +10%	端侧常更优（更快=更多使用）
重试率	基线	-5% 到 +2%	通常相当或更优
离线 AI 使用	0%	5-15% 的会话	新增能力
每用户成本	$0.05-0.10	约 $0.00	端侧更优

何时发布端侧版本

如果：

任务完成率在云端的 3% 以内（没有统计显著性地更差）
崩溃率没有增加
延迟明显更好（预期如此）
功能参与度稳定或改善

不要发布如果：

任务完成率显著下降（超过 5% 的下降）
崩溃率增加（某些设备上的内存问题）
端侧组的用户满意度明显更低

何时迭代

如果端侧模型在任务完成率上表现不佳但在延迟和参与度上获胜，那么模型质量需要改进。选项：

添加更多训练数据并重新训练
切换到更大的模型（1B 到 3B）
改进微调（更多 epoch、不同的超参数）
扩展训练数据以覆盖失败的场景

用改进后的模型重新运行 A/B 测试。

边缘情况

端侧模型尚未下载

端侧组中尚未下载模型的用户应回退到云端。跟踪端侧组完全激活（所有用户都有模型）所需的时间。

设备能力不匹配

某些用户的设备可能不支持端侧模型（RAM 不足）。这些用户无论分组如何都应使用云端。跟踪端侧组中回退到云端的百分比以及对应的设备型号。

离线对比

端侧组有一个云端组没有的能力：离线 AI。单独跟踪离线 AI 使用。这是增量价值，不会出现在直接的质量对比中。

商业论证

A/B 测试为迁移决策提供数据：

质量差异：用户体验是否相当？
成本差异：云端组每月花费多少？
参与度差异：用户是否更多地与更快的 AI 交互？
新增能力：离线 AI 使用有多少？

对于大多数微调良好的模型，A/B 测试证实了工程团队的预期：相当的质量、更好的延迟、零成本，加上离线能力。数据使迁移决策变得简单直接。

微调质量是关键变量。Ertas 等平台支持快速迭代：用改进的数据重新训练，导出 GGUF，部署到端侧组，再次测量。