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

一项提示词变体（prompt-variant）实验在某款 AI 辅助搜索产品的生产流量上运行。成功指标是点击响应中的任何建议操作。变体 B 交付的响应长度增加了大约 40%，且包含更多列举出的选项。点击率（CTR）高出 11%，且具有三个九（99.9%）的统计显著性。该实验被判定为获胜并上线。

一个月后，每周客户满意度调查下降了两个点。没人将其与上线联系起来，因为实验已被记录为成功，团队已经转向其他工作。季度复盘最终将满意度下降追溯到提示词的更改，诊断结果令人难以接受：变体 B 胜出并不是因为它给了用户更好的答案，而是因为更长的回答包含了更多的点击表面（clickable surfaces）。点击处理器在每次展示中触发得更频繁，是因为有更多可点击的内容，而不是因为你阅读的内容更值得采取行动。

一个发布团队在百分比旗标（percentage flag）的保护下发布了一个新模型。分桶计算公式为 hash(user_id) % 100，金丝雀（canary）测试覆盖 0–4 桶。在两周内，人均参与度的提升显著且稳定，于是团队将比例提升到 20%，随后是 50%，最后推向全球。在 50% 到全量发布的某个阶段，这种提升突然消失了。事后复盘（post-mortem）发现问题出在金丝雀人群（canary cohort）。实验变量并没有真正改变指标。金丝雀组的样本是一个特殊的群体。

团队以为自己是在对用户进行采样，实际上它是在对 ID 进行采样。

事后分析会以一句房间里所有人都希望是真的话开头：新模型在满意度上赢得了 4 %，p 小于 0.01，发布吧。一个月后，一项更冷静的分析发现，这种提升其实是一个混杂因素，模型表现实际上持平或略差，而团队在中间几周一直在争论哪个 prompt 更改“导致”了这一胜利。模型本身并没有导致任何结果。实验衡量错了对象，因为标志服务（flag service）和分析流水线在静默状态下对“分群（cohort）”的定义产生了分歧。

这是 A/B 测试中最昂贵的故障模式之一，因为系统中没有任何东西是损坏的。标志服务工作正常。实验追踪器工作正常。仪表板能正常渲染。统计数据是根据接收到的数据正确计算的。故障存在于三个组件之间的缝隙中，每个组件对身份都有不同的假设，而且除非你主动寻找，否则这个缝隙是不可见的。

我最近接触的一个产品团队针对回复人格设定（简洁、详尽、对话式）进行了一项为期三周的 A/B 测试，覆盖了所有用户群组。系统提示词描述了这三种设定，并要求模型选择最匹配用户的那一种。当他们打开数据集编写分析报告时，一个数字让他们愣住了：“详尽”组占据了 91% 的流量。另外两组的比例小到几乎可以忽略不计。

他们的实验平台没有标记任何异常。没有触发任何警报。流水线完全按照他们的指令运行。三周所谓的“多人格测试”产生了一个只能告诉他们关于“详尽”信息的数据集。另外两组样本太少，根本无法进行任何统计推断。

房间里的第一直觉是提示词需要改进——更好的指令、更清晰的人格区分、为对话式场景提供更刻意的示例。如果是在十年前基于规则的路由器中，这个诊断是正确的。但对于模型来说，它是错误的。提示词不是变量，路由器才是。

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 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% 显著性、两周扩量模板在两个方向上都系统性地输出了错误的判断：真实的获胜被读取为无效结果，而噪声则被读取为置信的获胜。