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

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

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

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

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

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