跳到主要内容

5 篇博文 含有标签「ab-testing」

查看所有标签

稀疏信号问题:当无法进行 A/B 测试时如何衡量 AI 功能质量

· 阅读需 11 分钟
Tian Pan
Software Engineer

你向企业客户上线了一个 AI 写作助手。每天使用它的人只有二十三个。产品经理在问:新的摘要模型是否真的比旧的更好?距离下一个迭代周期只剩两周,你需要给出一个决定。

于是你想到了 A/B 测试——然后立刻发现数学跑不通。要在 20% 的任务完成率基准上检测出 10% 的相对提升,在 80% 统计功效下,每个实验组大约需要 1,570 名用户。按每天 23 个用户算,你需要 136 天才能积累足够的数据。功能早就被弃用了,实验还没结束。

这就是稀疏信号问题。它并非 B2B 初创公司的特有困境。大多数 AI 功能——即便在成熟产品中——也只有一小部分用户在使用,而且都是执行特定高价值任务的用户。适用于大规模消费者推荐引擎的评估方法,在这种环境下完全失效。接下来,本文将介绍如何构建一套在无法进行 A/B 测试时依然有效的评估体系。

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

当你的评测结果不一致时:在数据互相矛盾时的一套信号优先级体系

· 阅读需 14 分钟
Tian Pan
Software Engineer

这是周二的早晨,也就是 Prompt 更改上线到一半流量后的那一周。你打开四个仪表板。LLM 评审员(LLM judge)评分的留存黄金集显示 +8%。每周对生产流量进行抽样的真人评估小组显示无变化。下游转化率的 A/B 测试显示 -2%。点赞率(thumbs-up rate)持平。四个信号,四个结论,而十五分钟后就有一个站会,会上有人会问你到底是发布这个 Prompt 还是回滚。

你很容易倾向于选择那个能证实你原本意图的数字——团队也会这样做,因为会议上没有人拥有一套关于哪个信号获胜的书面规则。这种不一致并非测量错误。这是一个在没有层级体系的情况下强行把四个评估器凑在一起的系统的必然产物。缺乏这种体系的代价是,每个发布周都会变成一场关于该信任谁的数据的辩论。

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

· 阅读需 12 分钟
Tian Pan
Software Engineer

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

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

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