17 篇博文 含有标签「experimentation」

一项提示词变体（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% 的流量。另外两组的比例小到几乎可以忽略不计。

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

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

我曾合作过的一个团队发布了一次 prompt 变更，将输出 token 减少了 22%。实验仪表盘上一片绿意——方差极小，p 值非常清晰，外推后的成本节省每年高达六位数。两周后，一位研究转化漏斗的产品分析师指出，在同一时间段内，下游任务完成率下降了 11%。较短的输出省略了一个澄清步骤，而用户一直默默依赖该步骤来了解下一步该点击哪里。

实验平台没有撒谎。它报告的正是团队配置的核心指标，而且该指标确实朝着正确的方向移动了。问题在于，该指标衡量的是团队实际上并不关心的东西。Token 统计成本低，实验基础设施对其有现成的集成，而衡量结果却很难——因此团队选择了平台提供的便捷方案。结果是仪表盘上的完胜，却是产品层面的退化。

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 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”。结果是受污染的联合分布的平均值，而发布则是回归到了同一曲面上的另一个点。

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

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

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

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

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

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

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

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