AI 功能不会像一个按钮那样出错。它的输出随输入而变，延迟随负载漂移，单次成本随 prompt 长度浮动，偶尔还会说出不该说的话。因此，对 AI 功能做 A/B 测试，与其说是一次优化，不如说是一道闸门：测试结束时读到的那几个数字，决定这个模型是否足够安全、足够有用、足够便宜到可以全量上线。本文讲的就是这道决策层：哪些指标真正能拍板上线或暂缓，以及如何在结果诱惑你之前先把阈值定好。
四个维度必须同时成立
四件事要同时站得住，而它们往往互相拉扯：模型要表现稳定（精确率、幻觉率、延迟），用户要真正获益，规模化后的单位经济要撑得住，安全与合规不能有任何回退。一个抬高了任务完成率却悄悄让服务成本翻倍、或在提升转化的同时抬高了有害输出比例的变体，都不算赢。PM 的职责，是把模型行为、用户价值、商业经济性、安全合规这四条验证路径整合进同一个统计上站得住的实验里，不让某一项的漂亮数字掩盖另一项的失败。
写一个能被证伪的假设
留存或转化这类目标对概率性系统来说太粗了。因为输出本身在波动，假设必须描述一个可接受的行为区间，而不是一个孤立的点：预期的延迟范围、目标幻觉减少幅度、排序相关性的改善幅度，以及你能容忍的错误模式或置信度阈值。没有这些区间，结果落地时你就分不清那是真实效应还是模型噪声。
把模型能力和用户结果连起来，并写清机制。例如：如果模型能更准确地分类客服工单，那么解决效率会提升，因为更精准的分流减少了内部交接。这个"因为"是结果可解释的关键，如果解决效率没动，你就知道该去查分流准确率到底有没有提升，还是交接根本不是瓶颈。
然后写下什么情况会让你叫停：禁止出现的错误类型、幻觉率上限、单次成本上限，以及触发回滚的安全条件。趁自己还中立时把这些定下来才是要点；一旦看到一个诱人的提升，每条阈值都会突然变得可以商量。
区间该怎么定，本身就是个需要提前想清楚的判断。以"目标幻觉减少幅度"为例，写"降低幻觉"没用，要写成类似"在 golden set 上幻觉率从 6% 降到 4% 以下，同时精确率不低于当前水平"这样一对绑定的条件，因为幻觉和覆盖率往往此消彼长，一个只报单边的目标很容易被"什么都不敢答"的退化变体骗过去。同理，延迟区间要写成尾部而非均值的约束，成本上限要写成按预期流量结构加权后的每请求成本。区间定得越具体，结果落地时的争论空间就越小。
挑出真正拍板的两三个数字
与其追一个北极星，不如让三类指标并行运行，各回答不同的问题，谁也代替不了谁。结果指标衡量用户与业务价值，是这个功能存在的理由，覆盖任务完成率、留存与参与度的提升、工作流里省下的时间、转化率的变化、输出质量评价，以及客服处理时长。这些数字回答的是同一个问题，用户和业务有没有因为这个功能过得更好，只是从任务、时间、转化和质量几个不同侧面切进去，任何一个单独看都容易骗人。
模型性能指标与产品结果相互独立，常常各走各的：精确率与召回率、幻觉率、排序相关性、延迟分布（不只是均值）、单次推理成本、置信度校准，以及漂移指标。一个变体可能过了产品阈值，却在模型阈值上悄悄栽了跟头，这正是产品与模型两道闸门并存的原因。换句话说，产品指标告诉你用户是否受益，模型指标告诉你这份受益是不是建立在一个你敢长期依赖的系统上。
护栏指标专抓那种"某个头条数字改善、却牺牲了你绝不愿交换的东西"的情形：有害内容比例、偏见指标、不安全或毒性响应、用户挫败感、系统错误，以及计算成本骤升。它们定义回滚条件，并且可以单凭自己否决一个看似正向的结果，不需要和结果指标讨价还价。
延迟、校准与兜底：模型层最容易被平均数掩盖的三件事
模型性能指标里最容易被均值掩盖的是延迟。推理延迟几乎从不是正态分布：大多数请求落在一个较窄的区间，少数长上下文、长输出或撞上冷缓存的请求会拖出一条很长的尾巴。如果你只报均值，一个把 p50 从 900 毫秒压到 700 毫秒、却把 p99 从 3 秒推到 6 秒的变体，看起来是净改善，实际上把最没耐心、往往也最高价值的那批用户推向了放弃。真正决定体验的是 p95 与 p99，以及超过某个绝对阈值（比如 4 秒）的请求占比，而这几个数字才对应用户真实感受到的"这功能到底卡不卡"。
把延迟拆开看还能顺带告诉你成本往哪走。长尾请求通常就是 token 最多、上下文最长的那批，它们既贵又慢，两条曲线的尾巴其实是同一批请求造成的。所以监控时把延迟分布和单请求成本按同一维度切开（按输出 token 数分桶）你往往会发现 5% 的请求吃掉了三成的推理开销，而这 5% 恰恰是均值永远不会替你报警的地方。
与延迟并列的另一个易被掩盖的信号是置信度校准。很多 AI 功能的价值不在于模型偶尔答得多漂亮，而在于它能不能诚实地说"我不确定"，从而让系统把高置信度的输出自动放行、把低置信度的转人工或走 fallback。这条自动化程度直接决定单位经济：能自动放行的比例越高，人工兜底的成本就越低。而它成立的前提是置信度校准：模型标称九成把握的那批预测，实际正确率是不是真的接近九成。
校准和准确率是两回事。一个整体准确率很高的模型也可能系统性地过度自信，把一堆其实只有七成把握的答案标成九成五。衡量它常用可靠性曲线和期望校准误差（ECE）：把预测按置信度分桶，比较每桶的标称置信度与实测正确率，两者的加权平均差距就是 ECE。如果新变体准确率涨了、ECE 却变差，你本质上是在拿一个更自信、也更会骗自己的模型换掉旧的，自动放行阈值一旦按旧校准设定，错误就会从你以为安全的高置信度区间里漏出去。所以校准应该和精确率、幻觉率并列进模型闸门，而不是等出了事才想起它。
校准解决的是"什么时候可以自动放行"，兜底路径解决的则是"放不了的时候会发生什么"，两者是同一枚硬币的两面。没有哪个概率系统会一直对，所以真正决定体验的往往不是模型答对时有多好，而是它答错或不确定时会发生什么。一个设计良好的 AI 功能会在低置信度时收敛到安全的兜底（转人工、给出保守的默认答案、或者干脆坦白"这个我不确定"）而这条兜底路径被触发的频率，本身就是一个应该盯的指标。它太高，说明模型覆盖不了真实场景，产品价值被稀释；它低到反常，往往意味着模型在该示弱的时候硬撑，把错误当成自信答案抛给了用户。
所以比较新变体时，别只比"答对率"，还要比兜底触发率以及兜底之后的用户结果：走了人工的工单最终解决得怎么样，看到保守默认值的用户有没有继续用下去。一个把兜底率压低、却让漏出来的错误变多的变体，是在用一个看不见的护栏损失换一个看得见的覆盖率提升，而这正是护栏指标该拦下来的那种交易。
样本量、统计功效与容易误读的效应
AI 实验通常需要比确定性功能更大的样本，因为效应本身会随 prompt 结构、用户查询分布、数据多样性和模型的置信区间而变，因为方差叠在常规抽样噪声之上。最小样本量、统计功效计算、效应量如何解读，都要在开流量之前定好，而不是等看到第三天的数字再说。
把"更大的样本"说具体一点：功效计算里，所需样本量大致与指标方差成正比、与最小可检测效应的平方成反比。假设一个确定性 UI 改动要检出 2% 的转化提升需要每组 3 万人，而同样幅度的效应放到一个输出会波动的 AI 功能上，指标方差因为逐用户的生成差异高出六成，那么在相同的功效和显著性水平下，每组样本量也要相应上抬约六成，逼近 5 万。这不是保守，而是因为每个用户携带的关于"变体平均效应"的信息更少。低估这一步的代价很实在：你会在功效不足的情况下跑出一个不显著的结果，然后误判功能没用，而其实是实验根本没有能力看见它。
在开流量之前，先走完离线验证的五关，缺一不可：
- 对标注集评估精确率与召回率
- 用 golden set 检验幻觉行为
- 与 baseline 比对排序相关性
- 确认安全分类过关
- 核实单次请求成本可行
只有五关都过的候选才配拿到线上流量，而线上测试要测的正是离线测不出的东西：真实用户行为和真实可靠性。这也是为什么离线永远替代不了线上，它只负责把明显不行的候选挡在门外，真正能不能上线，还得看真实流量下的表现。
流量一旦跑起来，可靠性大半来自把条件按住不动：一致的预处理、锁定版本的 prompt、统一的缓存策略、协调一致的置信阈值、稳定的流量分配。其中任何一项在测试中途漂移，都会带来你日后容易误当成信号的方差。
样本量给够、条件锁死之后，剩下的风险来自三个容易被误读的效应。第一个是新鲜感：AI 功能上线初期常有一段虚高的参与度，因为用户在试探这个新东西能做什么，而不是因为它稳定地更有用。这种新鲜感效应会在头几天把曲线抬高，然后随着好奇心耗尽回落。如果你在第三天就读数拍板，很容易把一次探索热潮当成真实提升。对策是把实验跑到指标趋稳，并单独看老用户分群的行为，因为新鲜感对熟悉产品的老用户影响可能较小，他们的曲线更接近功能的长期真值。
与之相关的是窥视偏差。每天盯着中间结果、一看到显著就想停，会大幅抬高假阳性率，因为你实际上做了很多次检验，却只按单次检验的阈值判断。运行中的中间比较只能当探索性参考，真正的判定要么等到预定样本量，要么改用序贯检验这类为反复查看而设计的方法，把多次窥视的代价算进显著性里。
第三个是异质效应。一个平均下来微弱为正的结果，底下可能藏着一批用户大幅获益、另一批被明显拖累，两股力量在均值里抵消。这在 AI 功能上尤其常见，因为模型对不同查询分布、不同熟练度用户的表现天差地别。上线前按关键分群（新老用户、查询复杂度、语言、平台）拆一遍结果，你才不会用一个安全的均值盖住某个群体正在经历的回退，而那个回退往往就是上线后最先冒出来的投诉。
离线与线上打架时的排查顺序
最让人头疼的情形，是离线指标全绿、线上结果却平平，或者反过来。这时候别急着下"模型不行"或"用户不买账"的结论，而是按一条固定顺序往下查，因为断点几乎总在其中一环。先看流量分布：线上真实请求的长度、语言、意图分布，和你离线评估用的数据集是不是一致，也就是离线用的是精心挑选的 golden set，线上却是脏得多的真实查询，模型在前者上的优势可能根本不覆盖后者的高频场景。
分布对得上，就看体验层有没有真正改变：模型答得更准，不代表用户能察觉，如果新输出被塞进同一个不起眼的位置、或者用户早就学会跳过那块 UI，模型层的收益就到不了行为层。再往下才是意图层：你优化的那一步是不是用户真正卡住的地方。前面"因为更精准的分流减少内部交接"那条假设，如果分流准确率确实涨了、解决效率却没动，那答案往往是交接从来不是瓶颈，模型解决了一个不痛的问题。按这个顺序查，你每次都能定位到具体哪一层断了，而不是对着一个平坦的转化数字干瞪眼。
谁来签字，凭什么证据
AI 实验牵涉的面足够广，签字天然是跨团队的：产品、数据科学、ML 工程、法务与合规、数据治理、以及负责 AI UX 的设计。PM 的角色是把他们协调到一起，而不是排成一条几个月的审批队列。他们签字签的是一份成文记录：假设与预期的行为区间、离线评估结果、实验指标与护栏阈值、样本量论证，以及回滚条件。这份记录的价值在于把上线标准从口头共识变成白纸黑字，等结果出来、有人想放宽某条阈值时，要改的是一份有据可查的文档，而不是各自的记忆。
与之并列的是 AI 特有的合规面：PII 处理、必要时的可解释性要求、内容风险等级、数据来源合法性、幻觉风险暴露评估。把这些并入上线前的检查，比上线后才发现要便宜得多。
何时发布、重训或终止
四条规则能解决大多数决策。只有当结果指标改善、模型指标达标、服务成本可控三者同时成立时才发布，因为AI 的可变成本结构意味着经济性要在事前建模，而非事后补算。任何护栏回退（有害输出、幻觉、偏见、安全风险）都强制回滚，即便主要指标在涨；这道否决权不容商量，所以才要早早定好。
第三条关乎规模，而它最容易被一个均值掩盖。假设某变体每次请求多一次推理调用，单次只多几厘钱，在表现规矩的测试样本上跑出漂亮的参与度提升和舒服的混合成本。可一旦上线，测试里只占 3% 流量的长上下文请求，在某个大企业客群里其实占了 20%，而这些请求每次的成本是均值的好几倍，"单位成功任务成本"就在全量后悄悄翻倍。参与度数字从头到尾没报过警，因为承压的从来不是它。所以在信任今天的利润之前，先模拟用户量增长、成本峰值、长上下文请求和多 agent 工作流，因为在 5% 流量下成立的数字，到 100% 可能就翻了。
把这条经济性算到 token 一级会更清楚。假设基线变体每次请求平均消耗 800 个输入 token 和 200 个输出 token，新变体为了提升相关性给 prompt 塞进了检索到的上下文，输入涨到 2600 token、输出到 400 token。按输出 token 通常数倍于输入的定价结构，单次成本可能不是涨了两三成，而是翻倍还多。在均值上这被高频的短请求稀释得看不太出来，可一旦某个客群集中在长上下文场景，他们那一侧的每请求成本就贴着最坏情况跑。所以成本建模不能只看一个混合均价，要按请求类型分层，再用真实流量里各层的占比加权，尤其是那些在测试样本里被低估、在真实大客户里却是主流的重负载请求。
第四条是可重复性：一个变体只有在离线与线上结果一致、行为可预测、漂移敏感性可接受时才可发布。当它们发生分歧，答案通常是重训或调整架构，而不是扩大发布。这里的"一致"要落到具体阈值：比如离线相关性提升 8% 时，线上核心漏斗的改善不应低于某个事先约定的下限，否则说明模型在真实意图上并未如离线那样奏效，值得先诊断再决定去留。
发布之后并不等于世界停住。模型面对的输入分布会漂移：季节、新产品、一次营销活动都可能改变用户查询的构成，而模型是在旧分布上验证的。漂移通常先于指标下滑出现，所以值得在实验期间就监控输入侧的分布变化，比如用群体稳定性指数（PSI）或 embedding 空间的偏移来预警，而不是等结果指标掉下来才回头找原因。一个上线时表现优秀的模型，可能仅仅因为三个月后用户问的问题变了就悄悄退化，这类退化只有把漂移当常规监控项才抓得住。
结果分析时，另一个容易偷懒的地方是把错误当成一个数字看。两个变体的总错误率可能一样，但错误的种类完全不同：一个更容易漏报，一个更容易误报，而这两类错误在业务上的代价往往差好几个量级。医疗、风控、审核这类场景里，一次漏报的成本可能远高于十次误报。所以结束后要对着错误分类逐类检查模型行为，按业务代价加权，而不是比总量，也就是一个总错误率略高、却把高代价错误压下去的变体，通常才是该发布的那个。
最后，把回滚条件写进文档只是一半，另一半是真到那一刻能不能立刻执行。护栏的意义建立在回滚是廉价、可逆、几秒钟就能生效的前提上，如果切回旧模型要重新部署、要等一轮发布，那么当有害输出比例在半夜爬上阈值时，团队会本能地先观望、先商量，而观望本身就是敞口。所以上线前就该把变体挂在功能开关后面，让回滚变成翻一个 flag，而不是发一次紧急版本。与之配套的是灰度：先把新变体放在小比例流量和影子模式下跑，让它对真实请求打分却不真正对用户生效，用于观察真实请求下的表现，同时控制数据隐私、额外负载和成本风险，再逐步放量。这样当护栏报警时，你影响的是 5% 而不是 100%，回滚的代价和心理门槛都低得多。闸门定得再漂亮，如果没有一个能立刻按下的开关兜底，真到该回滚的时候也容易犹豫。
把规则绑到测试的各个阶段
上述规则只有绑到测试的具体时刻才真正可用：开流量前固定什么、运行中盯住什么、结束后记录什么。
开流量前需要固定的：
- 明确用户与模型假设
- 选定结果、模型与护栏指标
- 完成离线评估并核实经济可行性
- 取得治理审批
- 定好样本量与实验时长
运行中需要盯住的：
- 每日监测护栏
- 跟踪成本走势
- 验证数据质量
- 确认 prompt 版本与推理一致性
- 把任何中间指标比较都只当作探索性参考
结束后需要记录的：
- 检验统计显著性
- 分析方差来源
- 对照错误分类检查模型行为
- 模拟规模化经济性
- 记录决策与后续计划
一个走完四道闸门的例子
把这些规则拼起来，看一个具体的功能：给客服工单做自动分类与建议回复。假设是：如果模型能把工单准确归到正确队列并起草初稿，那么平均处理时长下降、首次解决率上升，因为坐席省下了判断归属和从零起草的时间。四类指标据此定下来：结果侧看平均处理时长和首次解决率，模型侧看分类精确率召回率、初稿被坐席原样采用的比例、幻觉率，护栏侧看错误升级率和把工单误路由到错误队列的比例，经济侧看每张工单的推理成本。
离线阶段先在一批人工标注好的历史工单上跑：分类 F1 从基线的 0.71 升到 0.82，草稿在 golden set 上的事实性抽检通过率达标，单张工单成本估算落在可接受区间。五关都过，才放到 5% 流量上线。线上两周，平均处理时长下降、坐席对初稿的采用率稳定，看起来是个干净的胜利。但护栏指标里有一格在闪：被误路由到错误队列的工单比例，从 1.1% 涨到 2.4%，其中绝大多数集中在多语言工单上，离线 golden set 里这类样本太少，掩盖了模型在非英语工单上的分类退化。
按规则，这是一次护栏回退，它凌驾于向好的处理时长之上，所以不是全量，而是回去补多语言训练数据、重训、再测。这个例子的意义不在于结论本身，而在于顺序：假设先写死了误路由的红线，离线先筛掉了明显不行的候选，护栏在均值报喜的时候独立报了警，而分群拆解告诉你到底是哪批工单在受损。少了任何一步，这个功能都会带着一个只在特定客群暴露的回退被全量推出去。
还有一个所有指标体系都躲不开的陷阱：一旦某个数字被定成上线标准，团队就会有意无意地朝它优化，而它一旦成了目标，往往就不再是个好的度量。比如把"初稿采用率"设成硬指标，模型可能学会生成更短、更保守、更容易被原样采纳、信息量却更低的草稿，采用率涨了，真实价值反而缩水。对策是让结果指标和护栏指标互相牵制，也就是采用率要和最终解决率、返工率放在一起看，任何单一数字都不能独自决定发布，这也是前面坚持多指标并行、而非追一个北极星的原因。
团队最常提出的疑问
为什么 AI 的 A/B 测试更难？因为输出随上下文、查询分布和模型状态而变，同一个变体在不同用户身上会给出不同结果。这份额外的噪声，加上安全与成本两个维度，使它需要比 UI 测试更深的评估与治理。
该做线下还是线上实验？两者都要，且有先后：离线在固定数据上廉价地验证模型质量与安全性，线上再测只有真实流量才暴露的行为、经济性与可靠性。
如果提升了价值但增加了成本怎么办？在多个规模化情景下做成本与价值的权衡。若流量增长后利润崩塌，那么无论当前提升多好，模型都还没准备好，这笔账要按请求类型分层算，而不是信一个混合均价。
护栏出现回退怎么办？它有一票否决权。安全或合规回退强制回滚，即便主要指标在改善。
PM 需要哪些能力？足以读懂性能指标的模型素养、统计判断力、指标设计、经济建模，以及推动这一切走完签字流程的跨团队协调能力。
在看到数字之前先定好阈值
把可靠的 AI 实验和一厢情愿的实验区分开的，就一个习惯：事先定好那条线（算数的价值提升、能否决的护栏红线、规模化后仍要守住的成本上限），然后拿结果去对照它，而不是绕着它找说法。持续这样做，实验就不再是从数据里找故事，而是变成整个组织都信得过、真正用来拍板的那件东西。