对非确定性 AI 功能进行 A/B 测试：为何你的实验框架假设了错误的零假设

你的 A/B 测试框架是为按钮和横幅颜色而生的。它假设当你向用户展示变体 B 时，变体 B 每次的行为都相同。这个假设是如此根本，以至于没有人费心去明说它。然而对于 AI 功能而言，这个假设完全是错的。

当处理本身是非确定性的——当同一个提示每次请求都会产生不同的输出时——你试图测量的方差被你无意中制造的方差所掩盖。大多数团队都是经历了惨痛教训才意识到这一点：本应在一周内达到显著性的实验跑了一个月；周二看起来显著的结果到周四又逆转了；而"获胜"的变体在推广到 100% 流量后却毫无提升。

这不是一个小小的统计干扰问题，而是实验平台的工作方式与 LLM 驱动功能的实际行为之间的结构性错配。

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

传统 A/B 测试假设处理是一种固定干预。把按钮从蓝色改为绿色不会引入任何额外的方差——处理组中的每个用户都看到同样的绿色按钮。唯一的方差来源是用户之间的差异。

LLM 驱动的功能打破了这一假设。同一个用户，用同样的查询，在同一天，每次请求都可能得到截然不同的回复。这是由以下几个相互叠加的原因造成的：

• 温度与采样：即使很小的温度值也会在 token 层面引入随机性，并在整个回复中级联放大
• 提供方侧的非确定性：多项研究已证实，即使温度为零，LLM API 也无法保证逐位相同的输出，这源于批量计算中的浮点数非确定性
• 上下文窗口敏感性：对话轮次、检索结果或系统提示顺序的细微差异，都可能改变整个输出分布
• 模型版本漂移：提供方会静默更新模型，导致同一实验中周一和周三的输出分布发生偏移

实际结果是：你的实验现在有两个方差来源——用户间方差（框架能处理）和处理内方差（框架无法处理）。处理内方差会膨胀你的标准误，这意味着你的功效计算是错的。你用的那个样本量计算器假设处理是确定性的。你需要更多样本——有时多得多——才能检测出同等效应量。

举个具体例子：在确定性功能中，从 0.82 的基线检测 3% 的提升可能大约需要每个变体 1,400 个样本。加上 LLM 功能的处理内方差，这个数字可能翻倍甚至三倍，取决于模型引入了多大的输出方差。

你的随机化单元很可能是错的

大多数实验平台以用户为单位进行随机化：用户 47291 被分配到处理组，在实验期间他们的每次交互都使用处理变体。这对静态干预非常有效。

对于多轮 AI 功能，用户级随机化会产生一种微妙的混淆。考虑一个聊天机器人实验，你正在测试两种不同的系统提示。用户 A 在变体 B 下进行了三轮对话。第一次回复会塑造第二个问题，第二个问题会塑造第二次回复，而第二次回复又会塑造第三个问题。到第三轮时，你测量的已不再是系统提示的效果，而是系统提示加上前两次非确定性回复的累积影响。

对话轨迹变得路径依赖，同一处理组中的不同用户可能处于截然不同的路径上。这不是会被平均掉的随机噪声——而是由轮次间非确定性交互引入的系统性方差。

两种显而易见的修复方案都不够干净：

• 会话级随机化意味着同一用户可能早上看到变体 A，下午看到变体 B。任何跨会话聚合的指标（留存率、周活跃使用量）都会因交叉效应而受到污染。
• 请求级随机化对于多轮功能更糟糕，因为这意味着用户在对话中途经历不同的变体，这会以混淆测量的方式影响其行为。

对于多轮 AI 功能，最不坏的方法是用户级随机化结合对话级分析。使用基于确定性哈希的分配来持久分配用户，但将每次完整的对话作为分析单元，而不是单个回复。这既保留了用户所需的一致性，也给你足够多的每用户独立观测来估计用户内方差。

真正有效的指标

经典的实验手册告诉你选一个主要指标，定义最小可检测效应，然后计算样本量。对于 AI 功能，这份手册有一个空缺：你到底要测量什么？

传统产品指标（点击率、转化率、页面停留时间）仍然重要，但它们遗漏了 AI 功能最主要的失败模式。一个聊天机器人可以执行得完美无缺——低延迟、无错误、无崩溃——却给出了一个完全错误的答案。你的监控显示一切正常，而你的用户却怒火中烧。

你需要同时运行两层指标：

自动化质量指标，可以对每个回复进行程序化评估：

• 忠实度：回复是否基于所提供的上下文？
• 检索质量：RAG 功能的平均倒数排名（MRR）和归一化折损累积增益（NDCG）
• 护栏通过率：回复是否满足安全性和格式约束？
• 回复连贯性和引用准确性

行为信号，需要观察用户收到回复后的行为：

• 重新生成率：用户点击"再试一次"的频率？
• 后续模式：用户是否提出了澄清性问题（部分失败的信号），还是转向了新话题（成功的信号）？
• 任务完成率：用户是否达成了他们的目标？
• 会话放弃时机

关键洞察在于：自动化质量指标数量大但测量的是代理指标，而行为指标测量的是你真正关心的东西，但信号密度较低。你两者都需要，并且需要在启动实验之前预先注册哪个是主要决策指标。否则，你最终会挑选任何发生变化的指标——这是一种 p-hacking，当实验花费的时间超出预期时，这种诱惑尤为强烈。

贝叶斯方法对高方差处理收敛更快

频率主义 A/B 测试要求你预先承诺一个样本量，然后等到达到它为止。你不能提前查看结果，否则会膨胀你的假阳性率。这对所有实验都很痛苦，但当你的处理具有较高的内在方差时尤为痛苦，因为所需样本量很大，而在 AI 功能上运行慢速实验的机会成本很高。

贝叶斯方法为非确定性 AI 功能提供了三个具体优势：

无需固定样本量。 贝叶斯测试持续积累证据。你定义一个决策阈值（例如"当变体 B 更好的概率达到 95% 时发布"），一旦达到就停止。这自然地适应你特定功能的方差——高方差功能收集更多数据，低方差功能快速收敛。

层次建模处理分组方差。 层次贝叶斯模型可以解释这样一个事实：你的 AI 功能在不同查询类型、用户群体或对话场景中表现不同。模型在估计各组内效应的同时，在组间共享统计能力，而不是运行一个大型测试。

这特别有价值，因为 AI 功能在不同用例中往往表现差异很大——你的聊天机器人可能擅长事实性查询，却在开放式建议上表现糟糕，而平铺的 A/B 测试会将这些平均在一起。

后验概率是可操作的。 你得到的不是"p = 0.03，小于 0.05，因此拒绝零假设"，而是"变体 B 在用户引导提示上优于变体 A 的概率为 93%，预期提升 4.2 个百分点"。产品经理和工程负责人可以直接根据这一陈述做出决策，无需统计学入门教程。

构建对话式 AI 智能体的团队发现，在对话场景上进行部分汇聚的层次贝叶斯框架，比朴素的频率主义测试产生更保守、更准确的估计。部分汇聚防止了少数极端场景主导结果——模型认识到组间存在自然变异，并相应调整。

方差缩减：借鉴受控实验的技术

即使有了正确的统计框架，你仍然希望减少不必要的方差，以便实验更快收敛。AI 实验社区在采用 Web 实验中已成标准的技术方面一直行动迟缓，这是一个错失的机会。

CUPED（使用实验前数据的受控实验） 使用实验前行为来解释与处理无关的方差。如果一个用户在实验开始前参与度很高，无论他们看到哪个变体，在实验期间参与度也可能很高。CUPED 对此进行调整，Web 实验团队报告实验速度因此提升了 65%。没有理由不将这一技术应用于 AI 功能实验。

分层随机化 确保已知的方差来源在处理组和对照组之间保持平衡。如果你知道查询难度是结果方差的主要驱动因素，就按查询难度层级对你的随机化进行分层，使两组都获得平衡的混合。

多次运行平均 直接解决处理内方差。对于你能负担得起计算成本的自动化质量指标，对相同输入在同一变体下评估多次，并对分数取平均。对每个输入进行三次评估可以大幅降低采样随机性带来的噪声。这对行为指标没有帮助（你不能向同一用户展示对同一查询的三种不同回复），但它让你的自动化质量信号更加清晰。

预注册停止标准 本身不是方差缩减技术，但它防止了 AI 实验中最常见的假阳性来源：当结果看起来不错时就停止。在启动前定义你的决策标准、样本量估计和分析计划。LLM 实验特别容易受到提前停止的影响，因为高方差意味着结果在最初几天内剧烈波动。

细分盲区陷阱

这是 AI 功能特有的一种失败模式：实验显示出统计显著的整体改善，你发布了，然后特定用户群体经历了显著的回退，而这被聚合结果所掩盖。

这是因为 AI 功能在不同输入类型上具有异质性效应。一个新的系统提示可能极大地改善事实性查询的表现，同时降低开放式创意任务的表现。如果你 80% 的流量是事实性查询，即使 20% 的用户体验变差了，聚合指标也会上升。

始终按以下维度对结果进行细分：

• 查询类型或意图类别
• 用户经验水平（新用户与回访用户）
• 对话长度（单轮与多轮）
• 输入复杂度或难度层级

如果你看到积极的聚合结果，但任何有意义的细分中出现了负面结果，不要发布。调查这种回退是否真实，如果是，考虑是否可以有选择性地将处理应用于它有帮助的细分群体。

实践中真正有效的方法

在应对所有这些复杂性之后，对非确定性 AI 功能进行 A/B 测试的实践手册归结为几条原则：

1. 将样本量估计翻倍。 无论你的功效计算器给出什么数字，它都假设处理是确定性的。为处理内方差添加缓冲。如果你能实证估计输出方差（用相同输入运行 10 次并测量分布范围），就直接用它来调整你的功效计算。

2. 使用基于确定性哈希的用户分配。 这确保了一致性，同时不需要状态管理。同一用户在不同会话中始终看到同一变体。

3. 预注册一个主要指标，并分析细分群体。 在启动前决定你要优化什么，并承诺在发布前检查细分级别的结果。

4. 行为实验至少运行两周。 新奇效应是真实存在的——用户与新 AI 功能的交互方式不同，仅仅因为它是新的。短期实验系统性地高估了提升效果。

5. 如果你的流量有限，考虑贝叶斯方法。 如果你没有足够的流量来以所需样本量运行频率主义测试，带层次建模的贝叶斯框架会更快给你可操作的答案。

6. 永远不要跳过发布后验证。 发布后，将全量发布的指标与实验预测的结果进行比较。如果出现偏差，你的实验存在你没有考虑到的偏差——你需要在下次实验之前找到它。

在 AI 功能 A/B 测试上做得好的团队，不是那些拥有最花哨统计方法的团队。而是那些深刻理解了他们的处理不是一个按钮颜色——而是一个随机过程——并相应地调整了实验工作流程每个步骤的团队。