3. 推理链路概念：什么是推理链路、单模型 vs 多模型链路、串行与并行推理、DAG 在链路中的应用
3.1 什么是推理链路
在可疑交易检测场景中，推理链路是指将多个数据处理步骤、特征计算、模型评分与规则判断按特定顺序编排，形成一条从原始交易输入到最终风险决策输出的完整执行路径。它并非单一模型的简单调用，而是涵盖数据清洗、特征工程、模型推理、后处理、阈值比较、人工复核触发等多个环节的组合逻辑。
核心观点：推理链路将“数据 → 特征 → 模型 → 决策”的端到端流程显式建模为可编排、可观测、可热更新的执行图，是生产级风控系统的关键基础设施。
一条典型的可疑交易推理链路包含以下阶段：
| 阶段 | 说明 | 示例 |
|---|---|---|
| 数据接入 | 接收原始交易报文，解析字段 | 交易金额、时间、对手方、设备指纹 |
| 特征计算 | 基于历史与上下文生成特征 | 近1小时同设备交易次数、金额Z-score |
| 模型评分 | 调用一个或多个模型输出风险分 | XGBoost 输出 0.87，GNN 输出 0.92 |
| 规则后处理 | 叠加硬规则或阈值过滤 | 金额 > 5万 且 模型分 > 0.8 → 直接拒绝 |
| 决策输出 | 生成最终动作：通过/拒绝/人工审核 | 返回 code=REJECT，reason=“高风险团伙交易” |
3.2 单模型 vs 多模型链路
推理链路按模型数量可分为单模型链路与多模型链路，两者在架构复杂度、延迟要求、可解释性方面差异显著。
| 对比维度 | 单模型链路 | 多模型链路 |
|---|---|---|
| 模型数量 | 1 个 | 2 个及以上 |
| 适用场景 | 简单规则替代、单一风险维度 | 团伙检测、时序异常、多视角融合 |
| 延迟 | 低（通常 < 10ms） | 较高（需协调多个模型调用） |
| 可解释性 | 容易追溯单模型输出 | 需链路级归因，复杂度高 |
| 部署维护 | 简单，单容器即可 | 需链路编排引擎，版本管理复杂 |
| 典型例子 | 单 XGBoost 模型判断交易欺诈概率 | GNN 团伙分 + LSTM 时序分 + 规则融合 |
生产建议：在初期阶段优先使用单模型链路快速上线，当出现“单一模型无法覆盖所有风险模式”时，再逐步演进为多模型链路。切忌一开始就设计过于复杂的多模型拓扑。
3.3 串行与并行推理
推理链路中模型与节点的执行方式分为串行与并行两种基本模式，实际生产链路通常是两者的混合。
- 串行推理：节点按顺序执行，前一个节点的输出是后一个节点的输入。优点是逻辑清晰、易于调试；缺点是整体延迟等于各节点延迟之和，不适合延迟敏感场景。
- 并行推理：多个节点同时执行，互不依赖。优点是显著降低整体延迟；缺点是需要协调结果合并，且对资源消耗较大。
以下对比表总结了两种模式的关键差异：
| 特性 | 串行推理 | 并行推理 |
|---|---|---|
| 执行顺序 | 严格先后 | 同时进行 |
| 总延迟 | 各节点延迟之和 | 最慢节点延迟 |
| 资源占用 | 低（单线程） | 高（多线程/多进程） |
| 依赖管理 | 天然有序 | 需显式声明依赖关系 |
| 适用场景 | 特征依赖链、规则链 | 独立模型评分、独立特征计算 |
避坑提醒：并行推理并非总是更快。当节点间存在大量数据传输或共享资源争抢时，并行带来的收益可能被上下文切换开销抵消。务必在压测环境下验证并行 vs 串行的实际延迟。
3.4 DAG（有向无环图）在链路中的应用
DAG（Directed Acyclic Graph，有向无环图）是描述推理链路最自然的数学结构。每个节点代表一个处理单元（特征计算、模型推理、规则判断），每条有向边代表数据依赖关系。DAG 天然支持：
- 依赖解析：自动确定节点的执行顺序，保证前驱节点完成后才执行后继节点。
- 并行调度：无依赖关系的节点可被调度器并行执行，最大化资源利用率。
- 可观测性：每个节点可独立埋点、监控、重试，便于链路追踪与故障定位。
- 热更新：新增或替换某个节点时，不影响其他节点的拓扑结构。
下图展示了一个典型的可疑交易推理链路 DAG 结构：
上图展示了 DAG 如何显式表达节点间的依赖关系：
- 并行区域：特征计算 A、B、C 之间无连线，可同时执行；XGBoost、GNN、LSTM 三个模型同样可并行推理。
- 串行边界：数据接入 → 特征计算 → 模型评分 → 融合 → 决策，形成清晰的阶段串行依赖。
- 无环保证：所有边方向一致向下，不存在回路，确保链路最终收敛到决策输出。
3.5 链路编排的工程实现要点
将 DAG 概念落地到生产系统时，需关注以下关键设计：
| 设计维度 | 推荐方案 | 避坑点 |
|---|---|---|
| DAG 定义 | 使用 YAML/JSON 声明节点与边，支持热加载 | 避免硬编码拓扑在代码中，否则每次修改需重新部署 |
| 调度引擎 | 基于拓扑排序 + 线程池/协程池实现并行调度 | 注意线程安全，模型加载与特征计算需隔离资源 |
| 超时控制 | 每个节点设置独立超时，链路整体设置兜底超时 | 单个节点超时不阻塞整个链路，应降级或跳过 |
| 链路追踪 | 为每次推理请求生成唯一 trace_id，记录每个节点耗时与输出 | 日志量可能很大，需采样策略（如 1:100 全量，其余按风险分采样） |
| 降级与熔断 | 当某个模型节点连续失败时，自动降级为备用模型或规则 | 降级策略需在 DAG 定义中显式声明，而非运行时临时判断 |
生产案例：某支付平台在双十一期间将推理链路从串行改为 DAG 并行调度后，p99 延迟从 85ms 降至 32ms，同时支持了 3 个独立模型（交易模型、设备模型、社交模型）的并行评分，风控召回率提升 12%。