A/B 测试 AI 功能

测试一个按钮的颜色很简单：两个变体、一个指标、足够的流量。测试 prompt 改动要难得多，原因有三个。

输出是不确定的：同一个变体，同样的输入，给出的回答却不一样。质量往往很主观，没有点击量可数。而你真正在意的指标——这次改动到底有没有帮到用户——通常离模型调用隔了好几层。

先跑离线评测

线上实验慢，还会让用户撞上回归。大多数改动应该在推到流量之前就有结论。

你的评测集几分钟就能回答大部分问题。只有当评测显示有提升，或者分不清两个变体时，才值得把改动上线——而第二种情况很常见，这也正是线上测试能值回成本的时候。

行之有效的顺序：评测 → 影子模式 → 小比例流量 → 全量发布。

影子模式

两个变体都在真实流量上跑，两份输出都记日志，但只对外返回原有版本。

你拿到的是真实生产输入上的对比——包括评测集里没有的那些脏输入——用户风险为零。然后离线判断这些成对的日志：抽样做人工评审，或者让模型裁判做两两比较。

这一步被用得太少，却是整条链路里价值最高的一步。它能抓住只在真实输入分布上才出现的那类失效。

代价是影子流量上的推理成本翻倍，所以抽样就好，别把全部流量都走影子。

线上该测什么

优先选那些不需要判断质量的指标。

行为信号。 用户接受了建议、复制了输出、大改了一遍、重试、换个说法再问，还是直接放弃？刚给出回答就重试是很强的负面信号，而且埋点几乎不花成本。

任务完成。 他们本来要做的事做完了吗？这才是真正重要的指标，通常也最难归因。

追问次数。 澄清性的来回越少，通常说明第一次回答越好——但也可能是用户放弃了，所以要跟放弃率一起看。

升级率。 对客服系统来说，就是转接到人工的请求比例。干净、不含糊。

显式反馈。 点赞和点踩。量少，而且严重偏向不满情绪，但作为方向性信号仍然有用——每个差评配上它的调用链，就是一个免费的评测用例。

成本与延迟。 永远要测。质量提升如果让成本翻三倍，那是一个需要拍板的权衡，不是胜利。

这里要紧的设计细节

按用户随机分组，不要按请求。 同一次会话里表现不一致，会让用户困惑，也污染测量。一个用户在对话中途先拿到变体 A 又拿到变体 B，等于两个都没体验到。

实验全程让变体保持稳定。 测试中途改 prompt 会让实验作废。给两个变体都做版本管理，并记录每个回答出自哪个版本——见 Prompt 版本管理。

做好需要比平时更多流量的准备。 回答的方差大，效应更嘈杂，达到显著也更慢。

看分布，不只看均值。 一个改动如果让典型回答变好，同时让一小部分明显变差，在总量上看起来可能毫无变化。按输入类型分群——效果在不同问题类别之间经常是不均匀的。

锁定模型版本，实验期间从头到尾。供应商在实验中途更新模型会混淆一切，而且不会有任何通知。

常规做法在哪里失效

反馈回路太长。 如果价值要几天后才显现——agent 写的代码有没有通过评审——归因是真的难。务实的答案是代理指标，但得挑得仔细。

新鲜感效应。 用户会对变化本身产生反应。实验要跑得够久，等这层反应消退。

与检索的交互。 改 prompt 的同时 RAG 语料也在变，等于同时动了两个变量。能冻结的都冻结。

流量太小。 很多 AI 功能根本没有能撑起统计显著性的量。那就老老实实做离线评测，再仔细人工评审影子输出——装作有办法，比承认这一点更糟。

要点回顾

• 大多数改动用离线评测定夺；线上测试留给评测分不清变体的时候。
• 影子模式——两个都跑、只发一个、离线判断——是价值最高的一步，也是被跳过最多的一步。
• 测行为（重试、编辑、接受、升级），而不是试图在线上给质量打分。
• 按用户随机分组，变体和模型版本都保持稳定，并预期需要比平时更多的流量。
• 按输入类型分群；总量均值会掩盖那种「帮了大多数、却重创一小撮」的改动。

下一篇： 在模型之间迁移