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

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

实验组之所以上线，是因为仪表盘显示“转化率 +4%，p < 0.01，n = 2.3M”。但在全球推行 6 周后，这一增长消失了。由于没有其他合理解释，团队将这次复盘报告归类为“规模效应”。然而，真正的原罪一直潜伏在提示词组装器（prompt assembler）中：决定实验分组的路由哈希（routing hash）派生自一个用户层级（user-tier）属性，而三行代码后，同样的属性被插值到了提示词模板中。模型直接在带内（in band）读取了分组分配。所谓的“实验干预”（treatment）并非提示词的改变，真正的干预是提示词改变后所吸引的用户群体。

这是一种在团队从 Web 时代继承的实验手册中并不存在的失效模式。按钮颜色不会读取用户层级并决定表现不同，但提示词会。一旦你的实验干预是一个由模型解释的字符串，那么任何触及路由决策且同时触及提示词的输入，都会变成实验无法关闭的后门。

你运行了职业生涯中最干净的一次 A/B 测试。流量分配是 50/50，哈希函数看起来没问题，指标流水线没有造假，留存样本（holdout）得到了保留，经过三周的分析，得出了一个明确的胜者：变体 B 将任务完成率提升了 4 个点，统计团队对 p 值也没有异议。你将其 100% 发布了。发布两周后，你启动时所依据的核心指标却漂回了基准线，而且没人能解释原因。

这就是那个花了一些时间才看清的部分。两个变体都在向同一个长期记忆库写入并从中读取。变体 A 中的用户写入了一条记忆，比如 “该客户更喜欢直截了当的总结”，第二天，当同一个用户恰好处于变体 B 时，变体 B 的 Agent 加载了该记忆并将其读入其提示词（prompt）中。反向的情况也在另一个方向发生。实验并不是在比较提示词 A 与提示词 B。它是在比较 “读取提示词 B 形状记忆的提示词 A” 与 “读取提示词 A 形状记忆的提示词 B”。结果是受污染的联合分布的平均值，而发布则是回归到了同一曲面上的另一个点。

用户落到一个搜索结果页面。A 团队的智能摘要在顶部横幅里弹出:"这是要点 —— 跳过列表吧。"B 团队的内嵌助手在侧边脉冲跳动:"留在这里,我陪你继续阅读。"两个提示争夺同一段 800 毫秒的注意力,用户被惹烦了,关掉了标签页。第二天早上,A 团队报告摘要点击率提升 6%;B 团队报告助手打开率提升 4%;会议室里没有人是错的,而产品却比一个季度前更糟。

这就是那种"独立功能团队 + 单一功能 A/B 测试"的标准打法看不见的失败模式。每个团队都针对自己的指标做了局部最优。用户 —— 只有一份注意力预算、一份心智模型、一次可以给出的点击 —— 替两个团队都不愿做的整合,买了单。

你在实验中上线了一个模型替换。两周过去了，控制面板只变动了 0.1%，读数显示“无显著差异”。你得出结论，新模型与旧模型基本相同，然后继续进行其他工作。

它们并不相同。你的指标从未敏感到足以区分它们。

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

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

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

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

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

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

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

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

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

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

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

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