跳到主要内容

5 篇博文 含有标签「experimentation」

查看所有标签

方差正在吞噬实验:为什么传统的 A/B 测试功效计算不适用于 LLM 功能

· 阅读需 12 分钟
Tian Pan
Software Engineer

模型团队可以演示新功能并展示十个令人信服的并排对比获胜案例。增长团队将其作为为期两周的 A/B 测试运行,得到 p = 0.31,读数显示“无显著效果”。两个团队都是正确的。实验是错误的。

这种模式在每个将 LLM 强行接入产品但未重建其实验栈的组织中不断重复。增长团队使用的数学模型是为按钮颜色、排名变化和定价页面设计的——这些功能的输出在给定用户和上下文的情况下是确定性的。LLM 功能打破了该数学模型赖以生存的两个假设,而标准的 80% 效能、5% 显著性、两周扩量模板在两个方向上都系统性地输出了错误的判断:真实的获胜被读取为无效结果,而噪声则被读取为置信的获胜。

缺失的实验组:你的 AI 实验缺少 “关闭 AI” 的对照组

· 阅读需 10 分钟
Tian Pan
Software Engineer

看看你的团队最近发布的六份关于 AI 功能的实验报告。实验组都有哪些?很可能你测试的是“新提示词 vs. 旧提示词”、“GPT-5 路由 vs. GPT-4 备选”、“推理模型 vs. 快速模型”或者“有检索 vs. 无检索”。你报告了参与度、任务完成度或会话时长的提升。你称之为产品影响力。一个季度过去了。推理成本不断攀升。没人停下来问一个首席财务官 (CFO) 最终会问的问题:如果这个功能根本不存在,会发生什么?

这个问题就是那个缺失的实验组。你的实验不断衡量的提升是“更好的 AI vs. 较差的 AI”,但支撑你业务的是“AI vs. 什么都没有”——或者更尴尬的是,“AI vs. 我们从未记录下来的三行启发式代码”。这是结论完全不同的两种实验,而 2026 年大多数 AI 产品项目只运行过第一种。第二种实验才能告诉你,该功能是否配得上它的推理账单。

当处理方案不确定时如何对 AI 功能进行 A/B 测试

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的团队上线了一个基于 LLM 的新功能,进行了为期两周的干净 A/B 测试,并看到了具有统计显著性的提升。你将其全量发布。三周后,留存指标毫无变化,客服工单却在攀升。究竟哪里出了问题?你用教科书式的实验方法去测试了一个不符合教科书假设的处理方案——"处理方案是稳定的"这一前提,在无声无息中已然被打破。

标准 A/B 测试是为确定性或近确定性的处理方案而设计的:按钮颜色变更、参数固定的排序算法、结账流程。而 LLM 功能几乎违反了使经典频率派实验可靠的所有假设。处理方案的方差很高,处理方案本身会因服务商推送模型更新而在实验进行中途发生变化,"成功"难以被清晰量化,而且新鲜感效应足够强烈,足以产生在用户适应后就烟消云散的实验结果。

本文将介绍在这些挑战下使实验仍然有效的调整方法。

为什么 A/B 测试对 AI 功能失效(以及应该改用什么)

· 阅读需 10 分钟
Tian Pan
Software Engineer

你的 AI 功能上线了。A/B 测试运行了两周。处理组看起来更好——参与度提升 4%,p 值低于 0.05。你将其全量发布。

六周后,收益消失了。参与度回到了原点,甚至更低。你的实验说了一件事;现实说了另一件事。

这不是偶发案例,而是将标准双样本 A/B 测试应用于 AI 功能时的默认结果——你没有考虑这种方法论中内嵌假设被打破的方式。这些失败模式是结构性的,而非统计性的——你可以按教科书完美地运行实验,却仍然得到错误答案。

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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