模型AB部署：用分流验证模型价值

可视化演示

动态演示模型AB部署的核心机制，通过基础/核心/应用/扩展四种模式展示关键概念与交互流程。

初识AB部署——新旧模型同台竞技

老张的餐厅经营了五年，主厨手艺稳定，但客人最近总说“菜式有点腻”。一位新主厨带着时髦的创意菜来应聘，试菜时让老张眼前一亮。可老张不敢直接换人——万一客人不买账，招牌就砸了。他想了个办法：接下来一个月，让新主厨负责30%客人的菜，其余70%仍由老主厨做，月底比较两拨客人的满意度，再决定去留。这个“同时用两位厨师、对比评价再决策”的思路，就是AB部署的雏形。

老张的这个办法，在AI领域有一个专门的名字：模型AB部署。当一个训练好的新模型准备上线时，我们不会冲动地把线上流量全部交给它，而是把它和正在服务的旧模型“同时摆上桌”：一部分线上请求继续走旧模型，称为对照组；另一部分请求走新模型，称为实验组。跑一段时间，通过真实业务指标对比两组表现，让数据来回答“新模型到底值不值得全量替换”。

AB部署的核心要素可以拆解为三点：新旧模型同台、流量按组切分、数据对比决策。新旧同台意味着旧模型服务不能下线，而是保留为新模型的“参照系”；流量按组切分要求有一条稳定的分流规则，让用户被确定性地分到某一组；数据对比决策则要求我们提前定义好衡量指标，比如点击率、转化率、响应延迟等，并设定统计显著性的判断标准，而不是凭感觉拍板。

回到老张的餐厅。月底店长统计了两拨客人的复购率：老主厨是40%，新主厨是46%。代入提升率公式，(46%-40%)÷40%=15%——新主厨确实更有吸引力。有了这个数字，老张心里有底，决定开始规划后面的“渐进式换主厨”方案。这就是AB部署给工程师的底气：不靠感觉赌上线，而是靠分流后的真实数据，稳稳地验证模型价值。

流量分流设计——把客人公平分给两位厨师

要让这场比试公平，老张必须先解决一个问题：怎么把客人分给两位厨师？如果让服务员凭喜好推荐，回头客全跑去老主厨那边，比试就失去了意义。老张用取号牌做文章：每位客人进门取一个号，号码尾数小于3的去新主厨那边，其余留给老主厨。这样客人被分到哪组，完全取决于号码，而不是任何人的偏好。

在线上系统中，“取号牌”就是用户ID的哈希分桶。分流规则要满足两个条件：确定性——同一用户每次请求都应进入同一组；均匀性——两组用户特征大致相似。最简单有效的做法是计算 bucket = hash(user_id + salt) % 100，然后规定桶号小于某个阈值（比如30）的请求进入实验组。

为什么用哈希而不是直接随机？因为“随机”对同一用户每次请求都可能不同，导致用户一会儿被新模型服务、一会儿被旧模型服务，体验错乱且效果被稀释。哈希则保证了同一个用户永远落进同一个桶，行为可复现。加盐（salt）是为了防止某些特定ID因为哈希规律天然聚集在某一组；权重的调整也很简单——把阈值从30改成50，新模型流量就从30%升到50%，不需要重新部署模型。

老张的取号规则后来也升级了：不按简单的尾号，而是把号码做一次随机打散再取最后两位，就算客人扎堆来，也能均匀分成两组。服务员只需记住一条规则：分配结果由号码决定，永不改变。这套规则，就是线上分流系统的雏形。

实验组隔离——杜绝厨房里的“串味”

两位厨师共用一间厨房，最容易出问题：新主厨熬的酱汁不小心洒进了老主厨的锅里，客人会抱怨“今天的鱼味道不对”。实验组隔离要杜绝的，就是这种“串味”。它要求两组实验互不干扰，各自独立运行，否则得出的结论就像被酱汁污染过的菜——说不清是主厨的手艺问题还是食材串味的问题。

“串味”在AB部署里有三种典型形态：用户级串组、特征不一致、数据链路串扰。用户级串组指同一用户在不同请求中被分配到不同模型；特征不一致指新模型在离线训练时的输入特征与线上推理时不一致，导致实验指标失真；数据链路串扰指两组的埋点日志互相污染，统计时无法区分来源。

用户级隔离的解法是确定性哈希：同一用户在任何时刻都映射到同一个桶。特征一致性要求特征计算逻辑在训练和上线时保持完全一致，最好使用同一个特征服务。数据链路隔离要求两组的日志带上组ID，并在统计层按组ID聚合，不允许交叉读取。这三层隔离做扎实了，AB实验的结论才是“干净”的。

厨房管理手册写清楚了：老主厨用自己的灶台和锅铲，新主厨用自己的，食材和菜单虽然共享，但每一道菜出自哪口锅都有记录。客人满意度的回访表上也印了“厨师编号”，数据不会混在一起。老张看到这些规矩，才放心让两位厨师同时开工。

效果评估体系——让运气和实力各归其位

实验跑了两周，老张手里有两堆评价卡：新主厨这边“非常满意”占46%，老主厨这边是40%。看起来多了6个百分点，但老张不敢马上下结论——万一只是这周来了一批刚好爱吃创意菜的客人呢？这里的问题，正是AB评估中的核心：统计显著性。两组指标的差异可能来自真实效果，也可能来自随机波动。

要区分二者，我们需要三样东西：明确的业务指标、足够的样本量、显著性检验。业务指标要具备可衡量性与稳定性，例如转化率、点击率、留存率。然后利用双样本比例检验计算z分数：若|z|大于1.96，说明在95%置信水平下两组差异不是单纯随机波动，新模型的领先是“统计显著”的；若|z|小于1.96，则需要继续积累数据或承认当前证据不足。

老张找来学统计的表妹帮忙。表妹把两堆评价卡的数据代入公式，算出z分数是2.3，松了一口气：“这个差异不是运气，你的新主厨确实有两下子。”老张问样本量够不够、观察期会不会太短，表妹说这就是显著性检验存在的意义——让运气和实力各归其位。

部署架构方案——双厨并行的后厨工程

决定给新主厨更多机会后，老张发现后厨不是添一口锅那么简单。两位厨师都需要备菜台、调料架和出菜口，菜单和采购单要共享，还要有个店长统一调度，免得客人点的菜被两位厨师重复做。工程上的AB部署，同样是一场“后厨改造”。

部署架构的目标是：在不重启、不迁移线上服务的前提下，让新旧两个模型并行服务，并支持随时调整流量比例。典型架构包含三部分：网关分流、模型服务层、配置中心。网关根据分桶结果把请求路由到旧模型服务或新模型服务；两个模型服务独立部署、互不依赖；配置中心保存分流比例，修改配置即可动态调流。

监控与告警是这位“店长”的眼睛。需要实时观测两组模型的响应延迟、错误率、资源占用和核心业务指标；当实验组错误率明显升高时，告警应立即触发，甚至可以联动配置中心自动把流量切回旧模型。有了这套架构，线上的“双厨并行”才称得上安全可控。

老张站在后厨门口，看到每位客人的订单上都有店长填写的“厨师分配表”，出菜口有两个，监控屏上实时显示两位厨师各接了多少单、退菜率是多少。他手里的“调流旋钮”轻轻一转，新主厨接单比例就从30%变成50%——餐厅安然运转。这套后厨系统，就是他敢继续实验的底气。

上线演进策略——从试菜到正式换主厨

第二个月，新主厨的复购率依然领先。老张决定让他正式接班，但依旧没有搞“一夜换人”。他先用10%的客人试运行一周，确认稳定后调到30%，再过一周调到60%，最后才100%交给新主厨。每一步都盯着退菜率和客人投诉。这种逐步放量的过程，在工程上叫作灰度发布，是AB部署的“下半场”。

当实验数据证明新模型显著优于旧模型后，我们会按阶梯把流量从实验比例逐步提升：常见节奏是1%→5%→25%→50%→100%。每一档停留若干天，观察指标是否随放量持续保持优势。为什么要这么慢？因为AB实验的小流量结论，未必能完全代表全量场景下的复杂情况，比如缓存命中率变化、负载冲击、用户群体结构差异。

放量不是不可逆的。如果放量过程中任何指标触及红线，例如转化率相对旧模型下降超过2%，或错误率超过5%，系统应自动触发回滚，把流量瞬间切回旧模型。回滚速度远比“修Bug再发布”快，因为它只是把配置中心的阈值改回0%，旧模型服务一直在线待命。

第三个月的某天，菜单上所有菜品都换成了新主厨的版本，老主厨正式退休。但老张没有拆掉老主厨的灶台——万一新主厨因为季节食材变化发挥失常，他随时可以再把老主厨请回来，重新开启“双厨并行”。这就是AB部署留给团队的安全绳：新老模型永远保留一键切换的能力，业务价值在分流验证中被稳稳地实现。

AI 应用场景

Python 演示

import hashlibimport mathimport random SALT = "ab_test_v1" def bucket(user_id, num_buckets=100):    # 按用户ID哈希, 映射到0-99号桶    digest = hashlib.md5((SALT + str(user_id)).encode("utf-8")).hexdigest()    return int(digest[:8], 16) % num_buckets class ABTester:    def __init__(self, new_ratio=0.3, old_cvr=0.05, new_cvr=0.065):        self.new_ratio = new_ratio        self.old_cvr = old_cvr        self.new_cvr = new_cvr        self.old_imp = 0        self.old_conv = 0        self.new_imp = 0        self.new_conv = 0     def serve(self, user_id):        bucket_id = bucket(user_id)        is_new = bucket_id < self.new_ratio * 100        base = self.new_cvr if is_new else self.old_cvr        convert = random.random() < base        if is_new:            self.new_imp += 1            if convert:                self.new_conv += 1        else:            self.old_imp += 1            if convert:                self.old_conv += 1     def report(self):        old_p = self.old_conv / self.old_imp if self.old_imp else 0        new_p = self.new_conv / self.new_imp if self.new_imp else 0        se = math.sqrt(old_p * (1 - old_p) / self.old_imp + new_p * (1 - new_p) / self.new_imp)        z = (new_p - old_p) / se if se else 0        lift = (new_p - old_p) / old_p * 100 if old_p else 0        return old_p, new_p, z, lift def main():    random.seed(42)    tester = ABTester(new_ratio=0.3)    for uid in range(10000):        tester.serve(uid)    old_p, new_p, z, lift = tester.report()    print("对照组转化率: %.4f" % old_p)    print("实验组转化率: %.4f" % new_p)    print("提升率: %.2f%%" % lift)    print("z分数: %.3f" % z)    if abs(z) > 1.96:        print("结论: 差异显著, 建议全量上线新模型")    else:        print("结论: 差异不显著, 继续实验") if __name__ == "__main__":    main()

1. SALT = "ab_test_v1"固定盐值给哈希加佐料，防止特定ID扎堆进同一组。
2. return int(digest[:8], 16) % num_buckets取哈希前8位转整数再对100取模，得到0-99的稳定桶号。
3. is_new = bucket_id < self.new_ratio * 100桶号小于阈值就算实验组，阈值即新模型流量占比。
4. base = self.new_cvr if is_new else self.old_cvr给不同组分配不同的真实转化率，模拟模型效果差异。
5. self.new_imp += 1累计实验组样本量，供后续统计计算。
6. se = math.sqrt(...)计算两组转化率之差的标准误。
7. z = (new_p - old_p) / se if se else 0z分数越大，越说明差异不是随机波动。
8. if abs(z) > 1.96:95%置信水平下判定差异显著。

常见误区

面试题