跳到主要内容

8 篇博文 含有标签「experimentation」

查看所有标签

撒谎的 AI A/B 测试:LLM 实验中的新奇效应、结转偏差与锚定偏差

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的 AI 功能在信心满满中上线了。A/B 测试显示用户参与度有了 12% 的统计学显著提升。置信区间没有重叠。样本量大小合适。p 值远低于 0.05。六周后,指标回落到了基准线。三个月后,它实际上已经低于基准线。实验告诉你该功能有效,但实验撒了谎。

这并不是你统计工具的 bug。这是标准 A/B 测试所测量的指标,与人类随着时间的推移与概率性 AI 系统互动之间存在的根本性错配。三种特定的偏差——新奇效应膨胀、锚定偏差和结转偏差——共同导致了每个 AI 功能实验的虚高,而增加留置组(holdout group)的常规补救措施并不能解决其中的任何一个问题。

为什么 AI 功能会让 A/B 测试失效(以及不会撒谎的因果推断方法)

· 阅读需 12 分钟
Tian Pan
Software Engineer

你上线了一个 AI 功能,运行了一次干净的两周 A/B 测试,看到参与度提升了 4%,然后宣告成功。六个月后,功能全量发布,参与度却持平甚至下滑。测试结果不是因为噪声——而是根本就在衡量错误的东西。

A/B 测试建立在一个假设之上:实验组和对照组的用户在统计上是相互独立的。而 AI 功能会系统性地打破这一假设。用户相互交流、从彼此的行为中学习,并共享 AI 工具的输出结果。当真正的机制是长期的行为适应时,两周内处理效应并不会趋于稳定。忽视这一点,你的实验会给出一个内部自洽却因果无意义的数字。

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

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

方差正在吞噬实验:为什么传统的 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 驱动功能的实际行为之间的结构性错配。