A/B 测试陷阱：为什么标准实验设计在 AI 功能中会失效

一个团队上线了一个改进的 LLM 提示词。A/B 测试运行了两周。指标上升了 1.2%，p=0.03。他们将其视为胜利并向所有人发布。六个月后，一次客户审计发现，新提示词一直产生细微的错误摘要——这种语义偏移是点击率和会话时长无法察觉的。A/B 测试并没有完全撒谎。它用一种从未针对 LLM 特性设计的评估方法测量了错误的东西。

标准的 A/B 测试是为确定性系统构建的：按钮更改颜色、页面加载变快、推荐算法调整排名。在给定相同输入的情况下，输出是稳定的，方差较小且易于理解，教科书中的样本量计算公式也适用。然而，对于由 LLM 驱动的功能，这些属性都不成立。如果团队不考虑这一点，他们就不是在进行实验——而是在产生带有统计显著性标签的噪声。

三个失效的假设

经典的实验设计基于三个假设，而 LLM 同时违反了这三个假设。

确定性。 在传统的特性测试中，向用户展示变体 B 时，对于每个相同的输入都会产生相同的结果。LLM 并非如此。关于推理非确定性的研究发现，即使在 temperature=0（团队为了获得“可靠”输出而选用的设置）下，在相同的提示词上，约 24% 的 GPT-4o-mini 运行产生的输出与第一次运行不同。这并非舍入误差：推理基础设施中的连续批处理（continuous batching）和前缀缓存（prefix caching）引入了提示词设置无法消除的随机性。你不是在测试一种处理方式；你是在从一个分布中采样。

同方差性。 标准的效能计算（power calculations）假设方差在你处理的输入范围内大致恒定。LLM 的输出方差是异方差的（heteroskedastic）：它随任务难度而变化。简单的查询在不同运行中显示出 5–10% 的输出差异；复杂的推理任务则显示出 40–60% 的差异。基于聚合方差估算的样本量，对于最难的查询（即正确答案最重要的部分）将是完全错误的。

独立性。 A/B 测试单元应该是独立的：一个用户的体验不应影响另一个用户，并且用户的变体分配在交互过程中应保持稳定。对话式 LLM 系统打破了这两点。第一轮中糟糕的回答会影响用户在第二轮中的提问。如果你的分配逻辑在整个会话中不是确定性的，同一个用户可能会体验到两个变体——这违反了 SUTVA（稳定单位处理值假设），从而破坏了你的处理效应评估。

方差问题比你想象的更严重

确定性特性的标准 A/B 测试需要大样本，但它们的扩展是可预测的。对于 LLM 功能，由于输出方差非常高，达到同等统计效能所需的样本量通常要大 3–5 倍。数学是严酷的：将最小可探测效应减半需要四倍的样本量。在 LLM 功能上进行为期两周实验的团队，除非他们针对特定任务测量的 LLM 方差明确重新计算了所需的样本量，否则其效能几乎总是不足的。

延迟混杂因素（latency confound）加剧了这一问题。新的模型版本或重组后的提示词通常会用质量换取速度，反之亦然。如果一个回答质量提升了 20%，却带来了 40% 的延迟增加，导致用户在看到回答前就放弃了，那么这种提升就毫无意义。如果团队在没有护栏指标（如延迟、Token 成本、拒绝率）的情况下优化单一结果指标，通常会发布实际上是负向影响的“改进”。

表面指标会欺骗你

更隐蔽的问题是，团队衡量的结果并不能捕捉到 LLM 实际产生的内容。

考虑点击率、会话时长或点赞反馈——这些是团队在 A/B 测试中常用的标准产品指标。这些指标可能保持不变甚至有所改善，而 LLM 输出的语义质量却在显著下降。一个更简短、听起来更自信的回答即使准确度较低，也可能获得更好的参与度。产生更一致输出的提示词更改如果让用户觉得缺乏变化很无聊，可能会降低评分。

反之亦然，同样危险。研究记录了一种“更好的提示词反而有害”的现象：一个通用的“有用助手”包装提示词使 Llama 3 的特定任务提取准确率降低了 10%，RAG 合规性降低了 13%——同时却提高了 13% 的指令遵循得分。聚合指标会将此视为功过相抵。按任务类型进行的细分分析揭示了这种损害。如果没有按意图和内容类型细分的语义级评估，你就无法区分改进与权衡。

传统的字符串匹配指标让情况变得更糟。像 BLEU 这样的指标会惩罚语义正确但表述不同的输出。一个说“我们今天将处理你的订单”的模型与一个说“你的订单将立即被处理”的模型得分不同——尽管这些回答是等效的。基于嵌入的语义相似度（输出嵌入上的余弦相似度）是最小可行替代方案，而不是什么科研好奇心。

真正有效的方法

方法论上的修正并不深奥，但它们要求改变实验设计的标准操作流程。

在进行正式 A/B 测试之前，先运行影子部署（Shadow deployments）。 在将用户暴露给新变体之前，先在生产流量上静默运行候选模型——输入与在线系统相同，但不产生用户可见的输出，记录响应以供对比。影子测试能以零用户影响捕捉到明显的失败（延迟激增、系统性拒绝、架构违规）。只有通过影子验证的模型才应进入正式 A/B 测试。典型的节奏是在开启正式测试前进行 3 到 7 天的影子流量测试。

使用基于嵌入（Embedding-based）的评估作为主要质量信号。 设置一个自动化评估器，计算生产输出与金标准参考集（gold-standard reference set）之间的语义相似度，或者计算在相同输入下变体 A 和变体 B 输出之间的相似度。余弦相似度高于 0.95 表示语义等价；显著下降则标志着质量退化，即使参与度指标看起来不错。这应该作为 CI 流水线的一部分运行，而不只是在生产实验中。

运行配对分析（Paired analysis），而非独立样本。 在比较两个大语言模型（LLM）变体时，应在同一组测试案例上评估两个变体，而不是将不同的用户路由到每个变体并比较分布。与相同规模的独立样本相比，配对分析利用了对相同输入的响应之间的相关性，能将方差降低 30–50%。这会大幅缩短所需的实验周期。

按任务类型和用户细分进行分层评估。 聚合指标掩盖了切片级（slice-level）分析所能揭示的权衡。如果整体质量的提升是以损害高价值用户细分（高级用户、企业账户、安全关键型查询）为代价的，那这就不是提升——但只有当你分别衡量这些细分市场时，你才会知道这一点。LLM API 的质量波动会首先在特定人群（cohorts）中显现；聚合指标最后才会捕捉到它们。

根据测得的 LLM 方差设定样本量要求，而非套用教科书公式。 在对 LLM 功能运行任何正式实验之前，先衡量特定任务的输出方差，并据此计算所需的样本量。相对于确定性功能，样本量通常需要增加 3–5 倍。如果实验时间线不允许在所需的最小可检测效应（MDE）下达到足够的样本量，那么你进行的就不是一个有效的实验——而是一个披着统计外衣的猜测。

针对最重要的案例使用人工评估小组。 对于语义正确性至关重要的高风险功能（法律摘要、医疗信息、财务建议），仅凭自动化指标是不够的。使用最大差异法（maximum discrepancy methods）进行样本高效的人工评估——即仅评估变体差异最大的测试案例——可以用全语料库复审所需的一小部分标注量实现可靠的排名。在将评估小组的结果视为信号之前，先通过准则对齐会议校准评估员，并衡量评估员间的一致性（目标 κ > 0.6）。

LLM 团队需要的测试流水线

正确的思想模型不是“运行一个 A/B 测试”，而是一个分阶段的验证流水线，每个阶段在推进之前都有明确的通过/失败标准：

1. 线下评估：在固定的黄金数据集（100–500 个示例）上进行：确认基础能力、语义质量、约束遵循和安全性。速度快、成本低，在每次变更时运行于 CI 中。
2. 影子部署：在生产流量上运行（3–7 天）：捕捉线下数据中不可见的延迟退化、API 失败和行为漂移。
3. 正式 A/B 测试：采用语义评估、分层抽样、防护栏指标（guardrail metrics），并根据测得的 LLM 方差计算样本量。
4. 发布后的持续监控：LLM 供应商会静默更新模型；在实验窗口内正确的输出可能会在几周后退化。

大多数团队跳过了第一步和第二步，直接进行正式测试，这就是为什么他们的实验长期效能不足（underpowered），衡量的是错误的东西，并遗漏了真正对用户产生影响的失败。

搞错这些的代价

A/B 测试陷阱非常微妙，因为它不会发出巨大的失败警报。实验运行了，p 值过了阈值，指标向正确的方向移动，功能上线了。退化会出现在支持工单、流失率或季度输出质量评估中——而这发生在 A/B 测试被宣告成功、团队已经转向新任务很久之后。

标准的实验基础设施并非为具有非确定性输出、异构方差以及参与度指标无法捕捉语义质量的系统而设计的。不加批判地将其应用于 LLM 功能并不能带给你严谨性——它只会给你虚假的信心，而这种信心比根本不做实验更难被察觉。解决办法不是放弃实验；而是建立一个能够真正看到 LLM 功能产生什么的评估栈，并以这些系统所需的样本量和指标运行实验。