1. 课程导论：可疑交易推理链路概述、课程目标与学习路径、Serving系统在风控中的核心地位
1.1 可疑交易推理链路全景
在金融风控领域，可疑交易推理链路是指从原始交易日志流入开始，经过特征工程、模型推理、规则融合、决策输出，最终生成预警或阻断动作的完整数据管道。这条链路不是单一模型的调用，而是多个异构模型（图模型、时序模型、文本模型）与规则引擎、知识图谱协同工作的推理编排系统。
核心挑战： 单笔交易必须在 50ms～200ms 内完成全链路推理，且需支持每日千万级甚至亿级请求的峰值吞吐。
下图展示了可疑交易推理链路的核心阶段与数据流向：
1.2 课程目标与学习路径
本课程旨在培养学员从零到一构建生产级可疑交易推理链路 Serving 系统的能力。课程不局限于算法原理，而是聚焦于工程落地——如何将训练好的模型高效、稳定、可扩展地部署到线上环境。
| 模块 | 核心内容 | 实战产出 |
|---|---|---|
| 基础篇（第1-5章） | 推理链路架构、Serving 系统设计、特征存储选型 | 链路架构设计文档 |
| 模型篇（第6-12章） | XGBoost/TensorRT/ONNX 模型导出与优化、图模型 Serving | 多模型推理引擎 |
| 工程篇（第13-20章） | 高并发网关、降级熔断、灰度发布、监控告警 | 生产级 Serving 集群 |
| 进阶篇（第21-25章） | 特征一致性校验、AB实验平台、推理链路可观测性 | 全链路可观测平台 |
| 实战篇（第26-30章） | 端到端项目：从原始交易到决策输出的完整 Serving 部署 | 可演示的推理链路系统 |
学习建议： 建议学员具备 Python 后端开发基础（Flask/FastAPI）、熟悉 Docker/K8s 基本操作、了解机器学习模型导出流程。每章均提供可运行的代码示例与配置文件。
1.3 Serving系统在风控中的核心地位
在风控技术栈中，Serving 系统处于模型训练与业务决策之间的桥梁位置。训练环节追求 AUC/Recall 等指标，而 Serving 环节追求的是稳定性、低延迟、高吞吐、可观测性。一个优秀的模型如果没有可靠的 Serving 系统支撑，在线上环境中几乎无法发挥价值。
下表对比了模型训练环境与 Serving 生产环境的核心差异：
| 维度 | 训练环境 | Serving 生产环境 |
|---|---|---|
| 数据 | 离线全量数据，T+1 更新 | 实时流数据，毫秒级响应 |
| 性能要求 | 吞吐优先，延迟容忍 | P99 延迟 < 200ms，QPS 万级 |
| 容错 | 任务失败可重跑 | 单点故障不影响整体，自动熔断 |
| 模型更新 | 手动调参重训 | 灰度发布、A/B 测试、热加载 |
| 监控 | 训练日志、指标曲线 | 实时延迟、错误率、特征漂移告警 |
Serving 系统的核心职责可以概括为以下四点：
- 模型编排： 按 DAG 顺序调用多个模型（如先跑轻量规则过滤，再跑图模型深度检测），管理依赖与超时。
- 特征供给： 实时从 Redis/MySQL/特征存储中拉取用户画像、设备指纹、关系图谱等特征，并保证特征时效性。
- 决策融合： 将模型分数与业务规则（如黑名单、金额阈值）进行加权或优先级融合，输出最终决策。
- 可观测性： 记录每一笔交易的推理链路日志，支持事后回溯、特征一致性校验、模型效果监控。
常见误区： 很多团队将 Serving 简单理解为“模型 API 封装”，忽略了特征对齐、版本管理、降级策略等工程细节，导致线上模型效果远低于离线评估。本课程将逐一拆解这些工程陷阱。
下图展示了 Serving 系统在风控整体架构中的位置与交互关系：
从架构图中可以看出，Serving 系统是风控决策的中枢神经——它向上承接交易系统的实时请求，向下驱动决策执行，同时横向依赖特征存储、模型仓库、规则引擎等多个基础设施。任何一个环节的抖动都会直接影响风控效果与用户体验。
课程核心承诺： 学完本课程，你将能够独立设计并实现一个支持多模型编排、毫秒级响应、可灰度发布、可全链路追踪的生产级可疑交易推理链路 Serving 系统。