3. A/B测试基础
A/B测试并不是互联网行业凭空发明的“增长黑科技”,它的思想源头是医学与农业中的随机对照试验(Randomized Controlled Trial, RCT)。理解这一点,对风控场景尤其重要:因为风控的A/B测试,本质上是一次“带约束的因果推断实验”,而不是简单的“两个版本比大小”。
一、核心原理:随机化、对照与因果推断
A/B测试的基本逻辑可以拆成三步:随机分流 → 对照实验 → 统计比较。其目标是回答一个因果问题:“如果只改变策略A为策略B,指标会如何变化?”
- 随机化:将流量随机分配到实验组和对照组,使两组在统计上“同质”,从而消除选择偏差。
- 对照组:保留原有策略作为基准,避免把自然波动误判为策略效果。
- 统计推断:通过假设检验或置信区间判断差异是否显著,而不是只看绝对数值。
在风控中,随机化通常不是“用户级随机”,而是“请求级随机”或“设备级随机”。例如,同一用户在短时间内可能产生多次请求,如果按请求随机,会导致同一用户同时进入两组,产生污染效应。因此,风控A/B测试更强调分流单元的选择。
核心公式:实验效果 = 实验组指标 − 对照组指标。但真正要估计的是“处理效应”,即同一批流量在两种策略下的差异。随机化让这个差异可被无偏估计。
二、方法流程:从假设到决策
一个可落地的风控A/B测试流程通常包含以下步骤:
- 提出假设:例如“新规则将欺诈通过率降低2%,同时不显著提升误杀率”。
- 定义指标:核心指标(欺诈率、误杀率)、护栏指标(通过率、响应时间)、观测指标(规则命中率)。
- 确定分流单元:用户ID、设备ID、请求ID或会话ID,需保证同一单元不跨组。
- 计算样本量:根据基线指标、最小可检测效应(MDE)、显著性水平和统计功效反推所需样本。
- 实施分流:通过哈希或配置中心将流量稳定分配到实验组与对照组。
- 运行与监控:检查分流均衡性、指标异常、数据延迟。
- 统计分析与决策:判断显著性、置信区间、业务意义,决定全量、迭代或回滚。
下面是一个典型的风控分流配置示例,使用哈希取模保证同一设备始终进入同一组:
{
"experiment_id": "risk_rule_v2",
"salt": "2024Q3_risk",
"unit": "device_id",
"groups": {
"control": 50,
"treatment": 50
},
"metrics": [
"fraud_rate",
"false_positive_rate",
"pass_rate",
"latency_p99"
]
}
分流代码通常如下:
def assign_group(device_id, salt, groups):
h = hash(device_id + salt) % 100
if h < groups["control"]:
return "control"
return "treatment"
三、风控场景的特殊性
与推荐、搜索、广告等场景相比,风控A/B测试有三个显著不同:
| 维度 | 普通A/B测试 | 风控A/B测试 |
|---|---|---|
| 指标反馈 | 点击、转化,反馈快 | 欺诈、误杀,反馈慢且稀疏 |
| 样本量 | 通常较大 | 欺诈样本极少,需长周期 |
| 风险成本 | 低,失败可回滚 | 高,误杀或漏杀有直接损失 |
| 分流单元 | 用户级为主 | 设备、请求、会话级混合 |
| 干扰因素 | 较少 | 黑产对抗、策略联动、延迟标签 |
此外,风控策略之间往往存在联动效应。例如,实验组放宽了某条规则,可能导致下游规则命中率上升,从而掩盖真实效果。因此,风控A/B测试需要关注全局指标,而不仅是单条规则的局部指标。
实践建议:在风控A/B测试中,建议同时设置“业务护栏”和“风险护栏”。业务护栏如通过率、客诉率;风险护栏如欺诈率、资损率。任何一项突破阈值,都应触发人工介入或自动回滚。
四、常见误区与复盘
即使理解了原理,风控A/B测试仍容易踩坑。以下是四个高频误区:
- 误区一:用请求级随机代替设备级随机。同一设备多次请求被分到不同组,导致策略效果被稀释或污染。
- 误区二:只看显著性,不看业务意义。欺诈率下降0.01%可能统计显著,但资损减少不足以覆盖误杀成本。
- 误区三:忽略延迟标签。欺诈标签往往在事后数天甚至数周才确认,过早下结论会误判。
- 误区四:实验组与对照组策略互相干扰。例如实验组放宽规则后,黑产转向攻击对照组,造成对照组指标恶化。
复盘要点:风控A/B测试的失败,多数不是统计方法错误,而是分流单元、指标定义或实验周期设计不合理。建议在实验前进行AA测试,验证分流均衡性和指标稳定性。
最后,用一句话总结风控A/B测试的本质:它是在高风险、低样本、强对抗环境下,用随机化手段逼近因果真相的工程实践。只有把随机化、对照思想和风控业务约束结合起来,才能让增量效果评估真正可信。