AI 模型 A/B 测试应该怎样设计，技术指标和模型效果如何分别衡量

AI模型A/B测试的核心，并不是简单地把用户随机分成两组，然后比较两个数字谁更高，而是建立一套能够回答“模型变化是否真正造成了结果变化”的受控实验体系。一个完整的实验至少涉及随机分流、实验隔离、指标定义、统计分析、数据质量检查以及异常回滚几个环节。尤其对于推荐系统、广告模型和大语言模型，用户行为本身存在较大波动，如果实验设计不严谨，即使最终得到一个漂亮的提升百分比，也未必代表模型真的变好了。

首先需要确定实验单位，也就是究竟按照用户、设备、会话还是请求进行随机分配。对于推荐系统和大多数具有连续用户行为的场景，通常应该优先考虑用户级随机化，并让同一个用户在整个实验期间稳定进入同一实验组。实际工程中可以使用稳定哈希，例如对用户ID和实验ID组合后进行哈希，再将结果映射到预先定义的实验桶中。这样做的重点是获得稳定、可重复的随机分配，而不是简单使用某个哈希值的前几位作为“桶位”。哈希本身通常具有较好的分布特性，普通哈希碰撞也不会自然造成某些桶出现异常负载，因此不能把哈希碰撞直接等同于流量失衡。真正需要监控的是计划流量比例与实际流量比例是否一致，以及不同实验组的用户特征是否出现异常偏差。

实验开始以后，还需要检查Sample Ratio Mismatch，也就是样本比例异常。如果实验设计为50%对50%，实际进入两组的用户却长期明显偏离预定比例，就应该首先检查分流逻辑、埋点、过滤条件、缓存、登录状态以及数据管道，而不能直接进入效果分析。在线实验平台通常会把实际分流比例与设计比例进行统计检验，将严重的比例异常作为实验数据质量问题处理。Kohavi等关于在线受控实验的实践总结也特别强调了SRM检查，因为分流错误可能让后面的统计显著性分析失去意义。

实验隔离与流量分配则是两个不同的问题。A/B测试需要让A模型和B模型能够同时运行，并确保用户确实获得自己所属实验组对应的模型版本。工程上可以通过独立Deployment、服务版本、模型路由层或者特征开关实现，并不要求一定使用Kubernetes命名空间。命名空间主要提供Kubernetes资源和权限层面的逻辑隔离，并不等同于完整的计算资源隔离。如果两个模型仍然争抢同一组GPU、CPU或显存，单纯创建不同Namespace并不能解决资源竞争问题。

同样，TensorFlow Serving、Kubernetes Service、Service Mesh和gRPC解决的是不同层面的问题。模型服务可以使用独立服务版本，再由网关、实验平台或应用层完成流量路由；是否采用Service Mesh，应根据系统规模和网络治理需求决定。gRPC也不能简单理解为“避免额外网络延迟”，它本身仍然涉及网络通信，流式RPC主要适用于需要持续传输数据或流式返回结果的场景，并不是A/B测试的必选技术。

真正困难的部分通常是指标设计。模型技术指标和业务指标必须分开定义。技术指标回答的是“模型本身发生了什么变化”，业务指标回答的是“这种变化是否影响了用户和业务”。

对于分类模型，可以根据任务选择Precision、Recall、F1、ROC-AUC、PR-AUC、Log Loss、校准误差等指标。推荐系统可以使用离线排序指标，例如NDCG、MRR、Recall@K，同时在线观察点击率、转化率、加购率、订单金额等指标。生成模型和大语言模型则更加复杂，Perplexity可以反映模型在特定语言建模任务上的概率预测表现，BLEU适合某些机器翻译等任务，但它们不能直接代表一个通用聊天模型的整体回答质量。实际A/B实验还需要结合人工评价、任务完成率、事实性、拒答准确性、用户反馈以及成本等指标。

对于在线服务，还必须把系统指标纳入实验。模型效果提升如果伴随着P95或P99延迟明显增加、GPU显存不足、吞吐量下降、错误率上升或者推理成本大幅增加，最终是否值得上线就不能只看业务指标。因此，一个成熟的实验通常会设置Primary Metric，也就是主要评价指标，同时设置Secondary Metrics和Guardrail Metrics，用于观察副作用。实验平台的标准做法也是预先定义假设、主要指标和用于监控负面影响的指标，而不是实验结束以后从大量指标中挑一个最好看的结果。

统计设计同样不能简单规定“低于1%的流量就没有统计意义”。究竟需要多少用户，取决于基线指标、希望检测的最小效果差异，也就是MDE、指标方差、显著性水平、统计功效以及实验单位等因素。一个流量很大的系统，即使很小的流量比例也可能积累足够样本；一个用户量很小的系统，即使分配较高比例，也可能无法检测较小的模型差异。因此，实验开始前应该根据历史数据进行样本量和实验周期估算，而不是采用固定的1%、5%或者10%作为普遍标准。

如果用户之间存在明显的历史行为差异，可以采用分层随机化或者在分析阶段使用协变量调整来降低方差。例如，根据用户历史活跃度、地区或既有业务特征进行分层，然后在每个层内随机分配实验组和对照组。CUPED也是在线实验中常见的方差降低方法，它利用实验开始以前的用户行为作为协变量，减少结果指标中的可解释波动，从而提高实验敏感度。

统计检验不能一概使用ANOVA。只有两个独立实验组时，通常可以根据指标类型使用两样本检验、比例检验或回归模型；如果存在多个实验组，ANOVA才可能成为合适的方法之一。对于转化率、订单金额、留存率等不同类型指标，还需要考虑数据分布、实验单位、重复观测、聚类效应以及比例指标的统计方法。真正重要的不是“使用了某一种统计检验”，而是检验方法必须与实验单位和指标的数据结构相匹配。

实验期间还要防止所谓的“偷看数据”。如果每天看到结果就决定继续、停止或者修改实验，而仍然按照一次固定终点实验的统计阈值解释P值，就可能提高假阳性风险。传统固定样本量实验应该在实验开始前确定主要指标、MDE、样本量和分析方法。如果业务确实需要持续查看结果，可以采用序贯检验、Alpha Spending或者SPRT等预先设计的序贯分析方法，而不是边看结果边改变停止条件。

模型效果归因也需要更加谨慎。通过请求ID、用户ID、实验版本和事件时间戳，把一次模型请求与后续点击、购买或其他行为连接起来，是建立实验数据链路的基础，但这并不意味着已经计算出了“某一次预测对用户行为贡献了多少”。A/B测试主要识别的是实验组与对照组之间的平均处理效果，而单次推荐、单个Token或者单个预测结果的因果贡献，需要额外的因果推断或归因模型，不能仅靠事件关联得出。

对于具有状态的模型服务，还要防止实验污染。例如同一个用户今天进入A模型，下一次请求却因为路由变化进入B模型，或者实验期间修改了Prompt、特征工程、检索数据、模型权重和后处理逻辑，这些变化都可能混入实验结果。特别是大语言模型，Prompt、RAG数据、系统指令、模型版本和采样参数任何一个发生变化，都可能改变输出结果，因此实验期间应该尽量冻结无关变量。对于存在会话状态的系统，还需要考虑会话级路由、缓存以及KV Cache等因素，否则不同版本之间可能出现无法解释的状态差异。

A/B测试和灰度发布也不应混为一谈。灰度发布主要解决“如何控制新版本上线风险”，A/B测试解决的是“两个版本的差异是否产生了可测量的效果”。二者可以结合使用，但目标不同。实际部署中可以先完成模型功能验证和小规模灰度，再进入正式实验；实验过程中持续监控错误率、延迟、GPU资源、成本和业务指标，一旦触发预先定义的安全阈值，就停止继续扩大流量或执行回滚。

对于金融风控、医疗辅助、内容安全等高风险模型，还需要加入业务规则、合规要求、安全测试和人工审核等额外约束。对于推荐和广告系统，则可能更加重视长期留存、收入、用户体验和内容生态等指标。大语言模型还需要观察Token消耗、响应长度、拒答率、事实性、任务完成率以及人工评价等因素。

真正成熟的AI模型A/B测试，并不是寻找一个“胜率最高”的模型，而是建立从随机分流到数据采集、从模型效果到系统性能、从统计检验到风险控制的完整证据链。模型离线指标可以告诉工程团队模型本身发生了什么变化，在线A/B测试可以进一步检验这种变化是否真正影响用户和业务，而性能、成本和安全指标则决定这种提升能否在生产环境长期运行。只有把这几层指标放在同一个实验框架中，模型迭代才不会变成一次又一次凭感觉上线。