2. 回放对比概念
2.1 为什么需要回放对比
在风控网关的迭代过程中，每一次规则调整、模型更新或策略配置变更，都可能对线上流量产生不可预知的影响。传统的测试手段（如单元测试、集成测试）只能验证“预期输入→预期输出”的有限路径，无法覆盖线上真实流量的多样性、时序性和并发特征。回放对比正是为了解决这一核心矛盾而诞生的技术手段。
核心痛点： 风控策略的“蝴蝶效应”——一个看似微小的规则阈值调整，可能导致大量正常交易被误杀，或让恶意请求绕过检测。回放对比通过“用真实流量验证真实逻辑”，将这种风险在发布前暴露。
回放对比的核心价值体现在以下三个维度：
- 真实流量覆盖： 使用线上录制的真实请求流量进行回放，覆盖长尾场景和边界条件，远超人工构造的测试用例。
- 行为差异捕获： 自动对比新旧版本对同一请求的处理结果（通过/拒绝/人工审核）、响应耗时、返回码、风险评分等关键字段，精准定位差异。
- 回归风险量化： 将“是否有影响”从定性判断转化为定量指标（如差异率、误杀率、漏放率），为发布决策提供数据支撑。
2.2 回放对比与回归测试的区别
很多团队容易将回放对比与传统的回归测试混为一谈。虽然两者目标都是“保障变更质量”，但在技术原理、数据来源、验证方式和覆盖范围上存在本质差异。下表从六个关键维度进行对比：
| 对比维度 | 回归测试 | 回放对比 |
|---|---|---|
| 数据来源 | 人工构造的测试用例集 | 线上录制的真实请求流量 |
| 覆盖范围 | 有限路径 + 边界值 | 全量线上请求（含长尾） |
| 验证方式 | 预期结果 vs 实际结果（断言） | 旧版本结果 vs 新版本结果（差异分析） |
| 环境依赖 | 测试环境 + 测试数据 | 可复用线上环境或隔离沙箱 |
| 执行频率 | 每次代码提交 / 发布前 | 策略变更 / 模型更新 / 重大发布前 |
| 输出结果 | 通过 / 失败 + 日志 | 差异报告 + 差异明细 + 影响面分析 |
实践建议： 回放对比不能完全替代回归测试。回归测试用于验证“功能正确性”，回放对比用于验证“线上行为一致性”。两者是互补关系，建议在风控迭代流程中同时保留。
2.3 回放对比在风控迭代中的价值
风控系统的迭代具有高风险、高敏感、高实时性的特点。一次策略误调可能导致数百万的资损或大量用户投诉。回放对比在风控迭代全生命周期中扮演着“安全网”的角色，具体价值体现在以下四个阶段：
- 开发阶段： 策略开发人员可以在本地或测试环境快速回放一小段线上流量，验证新策略的逻辑是否符合预期，缩短“编码→验证”的反馈周期。
- 测试阶段： QA 团队使用全量回放对比，自动生成差异报告，精准定位新旧版本的行为差异点，避免人工逐条比对的低效和遗漏。
- 预发布阶段： 在灰度发布前，使用回放对比对预发布环境进行“影子运行”，确保新版本在真实流量压力下表现稳定，且与线上版本行为一致。
- 发布后监控： 发布后持续进行小流量回放对比，作为线上监控的补充手段，快速发现因数据漂移或环境差异导致的隐性不一致。
常见误区： 不要认为回放对比只适用于“大版本发布”。在风控领域，即使是单条规则的阈值微调（如将“单日交易次数上限”从5次改为3次），也可能对特定用户群体产生重大影响。建议将回放对比纳入日常的“策略变更 checklist”，作为发布前的必选步骤。
2.4 回放对比的核心指标
为了量化回放对比的结果，需要定义一组核心指标。这些指标帮助团队快速判断变更的风险等级：
| 指标名称 | 计算公式 | 含义说明 | 风险阈值参考 |
|---|---|---|---|
| 差异率 | 差异请求数 / 总回放请求数 | 新旧版本处理结果不一致的比例 | < 0.1% 低风险；0.1%~1% 需人工审核；> 1% 阻断发布 |
| 误杀率 | 新版本拒绝但旧版本通过的请求数 / 旧版本通过的请求总数 | 新版本是否错误地拒绝了正常请求 | < 0.05% 可接受；> 0.05% 需评估影响 |
| 漏放率 | 新版本通过但旧版本拒绝的请求数 / 旧版本拒绝的请求总数 | 新版本是否放过了原本被拦截的风险请求 | 原则上应为 0%，任何漏放都需严格审查 |
| 耗时偏差 | 新版本平均耗时 - 旧版本平均耗时 | 新版本是否引入了额外的性能开销 | < 10ms 正常；10~50ms 需优化；> 50ms 阻断发布 |
指标使用建议： 不要孤立地看单一指标。例如，差异率很低但漏放率不为 0，说明虽然整体影响面小，但存在严重的安全漏洞，必须阻断发布。建议建立“指标组合决策矩阵”，综合评估变更风险。