AB实验：给推荐系统办一场公平的味觉评比大赛

可视化演示

展示用户随机分组与流量分割、显著性检验判定，以及辛普森悖论的分层分析，可切换三种模式观察。

实验分组随机化

面馆老板深知，想让味觉评比公平，就不能让客人自己选窗口——年轻食客偏向浓香新汤，老食客钟情清淡老汤，若是客人自由选择，最后无论哪个窗口胜出，你都分不清是汤的功劳还是客群偏好的功劳。于是，老板规定：顾客进门后，单号进左门，双号进右门，互不串门。这就是AB实验的第一块基石——分组随机化。

在推荐系统中，分组随机化意味着把每个到达的用户，通过一个不可预测但又可复现的规则，均匀地分配到对照组（A组，体验旧策略）或实验组（B组，体验新策略）。随机化的魔力在于：当样本量足够大时，两组用户的年龄、性别、活跃度、历史偏好等所有已知和未知的特征，在统计意义上都会趋于一致。这样，实验结束时两组指标的差异，就只能归因于策略改动本身。

实际工程中，常用哈希分流算法实现随机化：取用户的唯一标识（如 user_id），对其做哈希运算后取模，根据模值落入不同的实验组。这保证了同一个用户始终进入同一组，避免反复横跳。

样本量估算是另一门学问。如果实验组只有10个用户，哪怕新策略真的有效，统计上也看不出来——就像拿一勺汤去判断整锅汤的咸淡。实践中用“最小可检测效应”来推算所需样本量：你想捕捉的最小提升幅度越小，需要的样本量就越大。

回到面馆：随机化保证了两拨客人的“底子”一样，之后无论哪碗汤卖得更好，你都可以安心地归功于汤本身。这就是随机化的价值——把“人的差异”这件麻烦事，用概率的魔法抹平了。

指标体系设计

面馆老板开始记录数据，但他很快发现“营业额”这个指标不够用。新汤虽然卖得多，但客人剩碗底的比例也高了——销量上涨靠的是猎奇尝鲜，回头客可能并没有变多。他需要一套更精细的指标层级：主指标看“是否值得做”，护栏指标看“做了有没有副作用”，辅助指标解释“为什么有效”。

推荐系统的指标体系同样讲究分层设计。主指标是全村的希望，通常选择与业务核心目标直接对齐的指标，比如电商场景的“成交转化率”、短视频场景的“人均观看时长”、广告场景的“千次曝光收益”。主指标只有一个，避免多头决策。

护栏指标是安全气囊。策略改动不能让主指标涨了、体验却崩了。例如：推荐算法改版后点击率升了，但用户退货率也飙升——这是典型的“饮鸩止渴”。所以必须设置护栏指标，如“人均退货率”“投诉率”“次日留存率”，一旦护栏指标显著变差，实验立即叫停。

辅助指标则负责解释“为什么”。当主指标上涨时，辅助指标能告诉你上涨来自哪里：是年轻用户贡献的？是推荐位第2到第5位的点击率提升了？这些信息帮助团队理解策略的作用机制，积累可复用的经验。

面馆老板最终确定了三重指标：卖掉碗数（主）、回头客比例（护栏）、年轻客人占比变化（辅助）。有了这套体系，他就不会因为“今天卖得多”而高兴得太早——也许那只是隔壁商场搞活动带来的虚假繁荣。

显著性检验

实验跑了一周，老板发现新汤窗口的“碗底朝天率”是 62%，老汤窗口是 55%。表面上看新汤赢了 7 个百分点，但老板不敢轻举妄动：万一是这一周来吃面的客人恰好偏重口味呢？万一是下雨天影响了客人的味觉呢？统计学给他提供了一把尺子——显著性检验。

显著性检验的核心思想是反证法：先假设“新汤和老汤其实没有差别”（原假设 H₀），然后计算在 H₀ 成立的条件下，观察到当前差异（或更极端差异）的概率——这个概率就是 p 值。如果 p 值很小（通常小于 0.05），说明“假设没差别”这件事本身就站不住脚，于是拒绝 H₀，认为新汤确实更好。

其中 \hat{p}_A 和 \hat{p}_B 分别是两组观测到的点率，\hat{p} 是两组合并的点率。这个 z 分数衡量的是“差异相对于随机波动的倍数”。

只盯着 p 值还不够，专业人士还看置信区间——它告诉你真实差异大概落在哪个范围。比如 95% 置信区间是 [1.2%, 6.8%]，说明新汤的优势至少有 1.2 个百分点，最多 6.8 个百分点，下限大于 0 才真正稳了。

老板看着 p = 0.03 的报告，心里踏实了：这把尺子告诉他，如果新汤和老汤其实一样好，那么仅仅靠运气观察到这么大差异的概率只有 3%，还不到 5% 的阈值。他决定：换汤！

实验互斥设计

面馆生意越做越大，老板开始同时试验多项改进：新汤底、新面条、新桌布、新音乐。问题来了——如果新汤底和新桌布同时在跑，到了评定时，你如何知道客人满意度上升是汤的功劳还是桌布的功劳？两个实验的流量互相交叉，结论就成了一笔糊涂账。

这就是实验互斥与正交要解决的问题。互斥实验是指两个实验不共享用户——用户参加了实验A，就不能参加实验B。正交实验则相反：两个实验可以共享用户，但通过分层设计确保两个实验的流量分配互不干扰。

成熟的推荐系统实验平台采用“层”（Layer）与“域”（Domain）的概念。整个用户流量被复制成多个“域”，每个域拥有 100% 的流量，域与域之间是正交的。每个域内部又划分为多个“层”，同一层内的实验必须互斥，不同层的实验可以正交。比如：一个用户在“推荐排序层”参与实验A，同时还可以在“首页样式层”参与实验B——两个实验各看各的指标，互不污染。

老板的解决方案：把食客分为“口味测试组”和“环境测试组”，老汤/新汤的对比只在口味组里进行，老桌布/新桌布的对比只在环境组里进行。两拨人互相看不见，实验结论互不干扰。他甚至在同一个食客身上同时测口味和环境——通过精妙的安排，一份客流量出了两份实验结论。

实验污染防护

面馆的评比刚进行到第三天，老板发现了一个诡异现象：有几位客人今天在左门吃新汤，明天又出现在右门吃老汤。一问才知道，这几位客人是隔壁公司的程序员，午休时间多，喜欢两边的面都尝一遍。老板心想：这批“穿越用户”的数据混在实验里，岂不是把新汤的真实效果给稀释了？

这就是实验污染中的用户穿越问题：用户在不同实验组之间流动，导致对照组用户实际上体验过新策略，实验组用户也体验过旧策略，组间差异被抹平。在推荐系统中，用户穿越的典型场景是：同一个用户在不同设备上登录，有的设备被分到A组，有的被分到B组，造成了策略的交叉暴露。

另一种常见的污染是新奇效应：用户刚看到新界面时，出于好奇会多点击几下，造成实验组指标虚高。但这种新鲜感消退后，指标可能回落到与对照组无异甚至更低。如果不设“预跑期”（预热期），在前几天就下结论，很容易被虚假繁荣欺骗。

最阴险的污染当属辛普森悖论——分组数据各说各话，汇总数据却得出完全相反的结论。比如新策略对高活跃用户和低活跃用户分别都更优，但因为实验组里低活跃用户占比更高（随机化出了偏差），汇总后反而显示新策略更差。这不是策略的问题，是分组比例失调的幻觉。

老板把“穿越客人”的数据单独标记出来，在分析时剔除；把新汤实验的前两天设为“蜜月观察期”不做决策；还把客人按年龄分层，分别看年轻人和老年人的反馈，避免辛普森悖论。有了这三重防护，他的味觉评比才算真正“干净”。

生产落地实践

面馆老板的实验方法论逐渐成熟，但他很快意识到：每次实验都要手动分组、手动记录、手动算显著性，效率太低不说，还容易出错。他开始把整套流程平台化：进门的取号机自动完成分流，每碗面的销售数据自动上传，后台程序自动算 p 值并发送实验报告。这就是实验平台的雏形。

一个成熟的实验平台至少包含四大模块：分流模块负责哈希分桶与参数下发，保证实验参数能实时配置到推荐服务；数据模块负责埋点采集与指标计算，打通“用户行为 → 实验日志 → 指标报表”的全链路；分析模块内置显著性检验、置信区间计算、分层分析等统计工具；决策模块则负责实验的启动、停止、上线与回滚，并支持设置止损条件。

工程实践中有几个关键经验。一是实验参数的动态配置：新的策略往往涉及复杂的模型或规则，需要将实验参数化并通过配置中心下发给线上服务，而不是改代码发版。二是数据的“预跑期”机制：实验启动后先观察 24-48 小时的“分流均匀性”，确认两组用户的关键特征分布大致相同后，再正式启用实验数据。三是统一的实验报告模板：让每个实验的结论都以相同的格式呈现，方便横向对比和归档。

面馆老板的实验平台上线后，他不再需要每次亲自盯着收银台。他给每项改进设定了自动停机的止损阈值，一旦护栏指标跌破红线，系统自动回滚到旧汤配方。他陆续验证了“新汤底有效”“细面条受欢迎”“轻音乐提高翻台率”，每一项决策都有数据背书。他恍然大悟：AB实验不仅是一次性的评测工具，更是一种可复制、可积累的工程能力——每一次实验都在为下一次实验铺路。

AI 应用场景

Python 演示

"""模拟AB实验：比较两组点击率是否有显著差异功能：生成对照组和实验组的模拟点击数据，计算z分数与p值"""import numpy as npfrom math import sqrt, erfc def simulate_ab(n_control=10000, n_treat=10000, p_control=0.20, p_treat=0.24, seed=42):    """模拟AB实验数据并计算显著性"""    rng = np.random.default_rng(seed)    # 生成二项分布点击数据: 1表示点击, 0表示未点击    clicks_control = rng.binomial(1, p_control, n_control)    clicks_treat = rng.binomial(1, p_treat, n_treat)    # 计算两组点击率    p_hat_control = clicks_control.mean()    p_hat_treat = clicks_treat.mean()    print(f"对照组点击率: {p_hat_control:.4f} (n={n_control})")    print(f"实验组点击率: {p_hat_treat:.4f} (n={n_treat})")    diff = p_hat_treat - p_hat_control    # 合并点击率, 用于计算标准误    total_clicks = clicks_control.sum() + clicks_treat.sum()    total_users = n_control + n_treat    p_pool = total_clicks / total_users    # 计算标准误: sqrt(p_pool*(1-p_pool)*(1/n1+1/n2))    se = sqrt(p_pool * (1 - p_pool) * (1 / n_control + 1 / n_treat))    z_score = diff / se    # 双侧p值: erfc(|z|/sqrt(2)) 为标准正态分布的尾概率    p_value = erfc(abs(z_score) / sqrt(2))    print(f"差异: {diff:.4f}, z分数: {z_score:.3f}")    print(f"p值: {p_value:.6f}")    alpha = 0.05    if p_value < alpha:        print("结论: 差异显著, 拒绝原假设, 新策略有效!")    else:        print("结论: 差异不显著, 无法证明新策略有效")    return p_value, z_score if __name__ == "__main__":    # 参数说明: 对照组1万人基准点击率20%, 实验组1万人点击率24%    simulate_ab(n_control=10000, n_treat=10000,                p_control=0.20, p_treat=0.24, seed=42)

1. rng.binomial(1, p_control, n_control)模拟每个用户是否点击，这是伯努利试验，返回 0/1 数组
2. clicks_control.mean()计算对照组点击率，就是点击人数除以总人数
3. p_pool = total_clicks / total_users合并点击率，它是“如果两组其实没差别”时的基准估值
4. se = sqrt(p_pool*(1-p_pool)*(1/n_control+1/n_treat))标准误，衡量差异的随机波动幅度
5. z_score = diff / sez分数，差异是波动的多少倍
6. erfc(abs(z_score)/sqrt(2))用互补误差函数算标准正态分布尾概率，即 p 值
7. if p_value < alpha:显著性判断，p 值小于 0.05 就认为差异不是运气

常见误区

面试题