2. 实时评分系统核心指标
实时反欺诈评分系统作为风控决策的中枢，其性能与效果直接决定了业务损失与用户体验。本章围绕四个核心维度展开：响应延迟、吞吐量、准确率与召回率、系统可用性。这些指标不仅是架构设计的约束条件，也是API发布时的SLA承诺依据。
2.1 响应延迟：P99与P999
响应延迟衡量从请求到达系统到返回评分结果的时间间隔。在反欺诈场景中，用户支付、登录等操作通常要求毫秒级响应。常用百分位指标包括：
- P99：99%的请求在X毫秒内完成，代表绝大多数用户体验。
- P999：99.9%的请求在Y毫秒内完成，用于捕捉极端尾部延迟。
架构启示： 实时评分系统应优先优化P99而非平均值。平均值容易被少量极快请求拉低，无法反映真实瓶颈。P999则暴露了缓存穿透、GC暂停或网络抖动等异常。
| 指标 | 典型目标值 | 监控重点 |
|---|---|---|
| P99 | < 100ms | 规则引擎执行、特征计算、模型推理 |
| P999 | < 500ms | 缓存失效、数据库慢查询、外部依赖超时 |
| 平均延迟 | < 30ms | 整体健康度参考，不作为SLA核心 |
实践建议： 在API网关层记录每个请求的百分位延迟，并按照业务线、渠道、特征版本进行维度下钻，快速定位慢请求根因。
2.2 吞吐量：TPS与QPS
吞吐量反映系统在单位时间内能处理的请求数量。在反欺诈评分系统中，通常使用以下两个指标：
- TPS (Transactions Per Second)：每秒完成的事务数，一个事务通常包含一次完整的评分请求-响应周期。
- QPS (Queries Per Second)：每秒查询数，在评分场景中常与TPS混用，但更侧重于查询类接口。
关键区别： TPS强调事务完整性（含数据库写入、消息发送等），QPS侧重查询读取。实时评分系统通常以TPS作为容量规划基准。
| 业务场景 | 目标TPS | 峰值TPS | 扩容策略 |
|---|---|---|---|
| 支付评分 | 5,000 | 15,000 | 水平扩展评分节点 |
| 登录评分 | 2,000 | 8,000 | 缓存热点特征 |
| 注册评分 | 500 | 2,000 | 异步化设备指纹 |
压测方法： 使用渐进式加压，从1,000 TPS开始，每30秒增加500，直到P99超过200ms或错误率超过1%。记录此时的TPS作为系统瓶颈点。
2.3 准确率与召回率
这两个指标衡量评分模型对欺诈交易的识别能力，是反欺诈效果的核心度量。
- 准确率 (Precision)：被判定为欺诈的交易中，真正欺诈的比例。高准确率意味着误伤少。
- 召回率 (Recall)：真实欺诈交易中，被系统成功拦截的比例。高召回率意味着漏网少。
权衡陷阱： 准确率和召回率通常呈反比关系。过度追求召回率会导致大量误拦截（低准确率），影响用户体验；过度追求准确率则可能放过大量欺诈（低召回率）。架构设计应支持动态阈值调整。
| 指标 | 计算公式 | 反欺诈含义 | 典型目标 |
|---|---|---|---|
| 准确率 | TP / (TP + FP) | 拦截的订单中真正欺诈的比例 | > 90% |
| 召回率 | TP / (TP + FN) | 真实欺诈中被拦截的比例 | > 85% |
| F1分数 | 2 * (P * R) / (P + R) | 准确率与召回率的调和平均 | > 0.87 |
2.4 系统可用性：SLA 99.99%
系统可用性衡量评分服务在约定时间内的正常运行比例。99.99%的SLA意味着全年不可用时间不超过52.56分钟。
架构要求： 99.99%的可用性需要多活部署、自动故障转移、优雅降级和熔断机制。单点故障必须消除，任何依赖（数据库、缓存、外部API）都应有备用方案。
| SLA等级 | 年不可用时间 | 月不可用时间 | 典型架构 |
|---|---|---|---|
| 99.9% | 8.76小时 | 43.8分钟 | 单活 + 冷备 |
| 99.99% | 52.56分钟 | 4.38分钟 | 双活 + 自动故障转移 |
| 99.999% | 5.26分钟 | 26.3秒 | 多活 + 单元化 + 秒级切换 |
监控维度： 除了整体可用性，还应监控每个API端点的可用性、每个依赖服务的可用性、以及每个可用区的可用性。使用SLO告警提前干预。
2.5 核心指标关联矩阵
四个核心指标并非孤立存在，它们之间存在相互影响和约束。架构设计需要全局权衡：
| 指标 | 影响其他指标的方式 | 常见冲突 |
|---|---|---|
| 响应延迟 | 延迟过高会降低有效TPS，触发超时重试 | 低延迟 vs 高准确率（复杂模型推理慢） |
| 吞吐量 | 高TPS可能增加排队延迟，影响P99 | 高吞吐 vs 低延迟（资源争抢） |
| 准确率/召回率 | 复杂规则和模型增加计算开销，影响延迟 | 高召回 vs 低误伤（阈值调整） |
| 系统可用性 | 冗余部署增加成本，但保障持续服务 | 高可用 vs 低成本（资源投入） |
架构决策提醒： 不要试图在所有指标上同时达到极致。根据业务场景确定优先级：支付场景优先低延迟和高可用；审核场景优先高准确率；风控探索期优先召回率。明确优先级后再进行技术选型。