3. 流量分配核心原则:随机性、独立性、样本量充足性、统计显著性

授信引擎的 A/B 测试本质上是一场受控实验。流量分配的质量直接决定实验结论的可靠性。若分配过程存在系统性偏差,后续所有统计推断都将失去意义。本章围绕四个核心原则展开,它们共同构成了流量分配的“黄金基线”。

3.1 原则一:随机性

随机性是 A/B 测试的基石。它确保每个用户进入实验组或对照组的概率相等,从而在理论上消除已知和未知的混淆变量(如用户历史信用分、收入水平、地域差异)对实验结果的干扰。

  • 实现方式:使用密码学安全的伪随机数生成器(CSPRNG),基于用户 ID 或设备 ID 进行哈希分桶。
  • 常见误区:按用户注册时间奇偶、按用户 ID 尾号、按地域轮询分配。这些方法极易引入时间或空间上的系统性偏差。
  • 验证方法:在实验启动前,对分配结果进行卡方检验,确认各组用户的关键画像特征(如年龄、历史逾期率)无显著差异。
工程提示:在分布式授信系统中,务必使用一致性哈希算法分配流量,避免因服务扩缩容导致用户在不同实验组间“漂移”。
随机性分配流程示意图 随机性分配流程 用户请求 CSPRNG 哈希分桶 对照组(A组) 实验组(B组) 确保无系统性偏差

3.2 原则二:独立性

独立性要求实验组与对照组的用户行为互不干扰,且同一用户在不同实验中的表现相互独立。在授信场景中,独立性极易被“网络效应”或“用户重叠”破坏。

破坏类型 授信场景示例 后果
网络效应 同一家庭或企业的多个成员被分到不同组,共享授信额度或担保关系 组间污染,低估或高估模型效果
用户重叠 同一用户同时参与“额度提升”和“利率折扣”两个实验 交互效应干扰,无法归因单一策略
时间重叠 用户在实验期间重复申请,被多次重新分配 破坏独立同分布假设,方差膨胀
避坑指南:在授信引擎中,建议对用户维度进行“锁定分配”。一旦用户进入某实验组,在整个实验周期内(通常为 30-90 天)不得变更分组。同时,建立实验互斥层,确保同一用户不会同时命中多个冲突实验。

3.3 原则三:样本量充足性

样本量不足会导致统计功效(Statistical Power)过低,即使策略真实有效,也无法被检测出来。样本量计算需基于以下参数:

  • 基线转化率(p1):对照组当前的授信通过率或逾期率。
  • 最小可检测效应(MDE):业务上认为有意义的最小变化幅度(如通过率提升 2%)。
  • 显著性水平(α):通常取 0.05。
  • 统计功效(1-β):通常取 0.80。

常用样本量计算公式(两组等比例):

n = ( (Z_α/2 + Z_β)^2 * (p1*(1-p1) + p2*(1-p2)) ) / (p2 - p1)^2

其中:
  p1 = 对照组基线率
  p2 = 实验组预期率
  Z_α/2 = 1.96(对应 α=0.05)
  Z_β = 0.84(对应 β=0.20,功效 0.80)
实战建议:在授信场景中,由于逾期率通常较低(如 1%-5%),检测逾期率下降 0.5% 可能需要数十万甚至上百万样本。建议在实验设计阶段使用模拟工具(如 Python 的 statsmodels 库)预先计算所需样本量,并预留 20% 的余量应对用户流失。

3.4 原则四:统计显著性

统计显著性用于判断观察到的组间差异是否真实存在,而非由随机波动引起。核心指标为 p 值,通常以 p < 0.05 作为显著性阈值。

在授信 A/B 测试中,常用的显著性检验方法包括:

指标类型 推荐检验方法 适用场景
二分类指标(通过率、逾期率) Z 检验 / 卡方检验 授信通过率、首期逾期率
连续指标(授信额度、利率) 独立样本 t 检验 / Mann-Whitney U 检验 平均授信额度、平均利率
比率指标(风险调整后收益) Delta 方法 / Bootstrap RAROC、风险调整后净现值
重要提醒:统计显著 ≠ 业务显著。当样本量极大时(如千万级),即使 0.1% 的微小差异也可能达到统计显著,但该差异可能不具备业务落地价值。务必结合效应量(Effect Size)和业务成本综合决策。
统计显著性决策流程 统计显著性决策流程 计算 p 值 p < 0.05 ? 统计显著 拒绝原假设,差异非随机 统计不显著 无法拒绝原假设 注意:统计显著后仍需评估效应量(Cohen's d / 风险差)是否达到业务阈值

3.5 四原则联动关系

四个原则并非孤立存在,而是相互依赖、层层递进:

  1. 随机性 是前提,保证组间可比性;
  2. 独立性 是保障,防止组间污染;
  3. 样本量充足性 是基础,确保统计检验有足够“能量”发现差异;
  4. 统计显著性 是结论,为业务决策提供量化依据。

任何一个原则被违反,都可能导致实验结论失效。在授信引擎的流量分配系统中,建议将这四个原则作为上线前的强制检查项,并固化到自动化测试流程中。