1. 反洗钱推理链路概述
1.1 反洗钱业务场景
反洗钱（AML）系统是金融机构合规体系的核心组件，其业务场景覆盖客户全生命周期中的资金异常行为监测。典型的 AML 业务场景包括：
- 客户身份识别（KYC）：开户时验证客户身份信息，比对制裁名单、政治公众人物（PEP）名单。
- 交易监控：对实时或准实时的交易流水进行规则引擎与机器学习模型双重筛查，识别可疑交易。
- 可疑交易报告（STR）：当交易评分超过阈值时，自动生成可疑交易报告并提交监管机构。
- 客户风险评级：基于交易行为、地域、行业等维度动态调整客户洗钱风险等级。
- 回溯调查与审计：对历史交易进行批量推理，支持监管回溯与内部审计。
关键指标：大型银行每日交易量可达数千万笔，推理链路需要在秒级内完成单笔交易的评分与决策，同时保证 99.99% 以上的可用性。
1.2 推理链路定义
反洗钱推理链路是指从交易数据进入系统到输出风险决策结果的全流程处理管道。一条完整的推理链路通常包含以下阶段：
| 阶段 | 功能描述 | 典型耗时占比 |
|---|---|---|
| 数据接入 | 接收交易消息，解析协议，校验格式，写入消息队列 | 5% |
| 特征提取 | 从交易上下文、客户画像、历史行为中提取结构化特征 | 20% |
| 规则引擎 | 执行预定义的专家规则（如单笔金额阈值、高频交易检测） | 15% |
| 模型推理 | 调用机器学习模型（如 XGBoost、图神经网络）进行风险评分 | 35% |
| 决策融合 | 综合规则与模型结果，执行最终决策逻辑（通过/预警/阻断） | 10% |
| 结果回写 | 将决策结果写入数据库、通知下游系统、记录审计日志 | 15% |
推理链路的设计目标是在保证准确率的前提下，最小化端到端延迟（P99 < 500ms），并支持水平扩展以应对业务峰值。
1.3 API 性能瓶颈分析
在实际生产环境中，反洗钱推理链路的 API 性能瓶颈通常集中在以下五个维度：
- 特征提取 I/O 密集：每次推理需要从多个数据源（Redis、HBase、关系数据库）拉取客户画像与历史交易，网络延迟与连接池争用成为首要瓶颈。
- 模型推理计算密集：深度学习模型或大规模集成树模型在 CPU 上推理耗时高，GPU 资源不足时容易导致请求排队。
- 规则引擎匹配爆炸：当规则数量超过数千条时，线性匹配策略导致单次推理的规则评估时间呈线性增长。
- 序列化/反序列化开销：跨服务调用时，Protobuf/JSON 的序列化与反序列化在吞吐量高时成为隐藏瓶颈。
- 数据库写入竞争：结果回写阶段的高并发写入导致数据库锁竞争与 WAL 日志压力，影响端到端延迟。
优化切入点：根据实际压测数据，特征提取与模型推理两个阶段通常占据链路总耗时的 55%~70%，是性能优化的首要目标。
1.4 瓶颈根因分析
针对上述五大瓶颈，进一步分析其根因：
| 瓶颈维度 | 根因 | 影响指标 |
|---|---|---|
| 特征提取 I/O 密集 | 多数据源串行查询、连接池配置过小、缓存命中率低 | P99 延迟、吞吐量 |
| 模型推理计算密集 | 模型参数量大、未使用批处理推理、CPU 指令集未优化 | P99 延迟、CPU 使用率 |
| 规则引擎匹配爆炸 | 规则未做索引化、存在大量冗余规则、匹配算法为 O(n) | 单次推理耗时 |
| 序列化/反序列化开销 | 跨服务调用频繁、数据体积大、未使用零拷贝技术 | 网络带宽、CPU 使用率 |
| 数据库写入竞争 | 单表写入热点、未做分库分表、事务隔离级别过高 | 写入延迟、锁等待时间 |