4、在线推理架构设计：请求入口、特征服务、模型引擎、结果返回、高可用与容错设计

信用评分 PD 模型的在线推理架构需要支撑高并发、低延迟、高可用的实时评分请求。本章将详细拆解从请求进入系统到最终返回评分结果的完整链路，并重点阐述高可用与容错设计的关键策略。

4.1 整体架构总览

一个典型的在线推理架构采用分层解耦设计，主要包含以下四个核心模块：请求入口、特征服务、模型引擎、结果返回。各模块通过异步消息或轻量级 RPC 进行通信，实现高内聚低耦合。

4.2 请求入口层

请求入口是系统的门面，负责接收外部客户端的评分请求。它通常由 API Gateway 和 负载均衡器 组成。

4.3 特征服务层

特征服务是推理链路中最复杂、最易出错的环节。它需要从多个异构数据源（如 HBase、Redis、Kafka）中获取原始数据，并实时计算成模型可用的特征向量。

4.3.1 特征服务核心流程

1. 特征路由： 根据请求中的用户 ID 或设备 ID，确定需要拉取哪些特征组。
2. 数据获取： 并行调用多个数据源（如用户基础信息、近 30 天交易统计、外部征信数据）。
3. 特征计算： 执行特征工程逻辑，如 WOE 编码、分箱映射、缺失值填充、归一化。
4. 特征组装： 将计算好的特征按照模型输入顺序组装成特征向量（如 JSON 或 Protobuf 格式）。

4.3.2 特征缓存策略

为降低延迟，对高频访问且变化不频繁的特征（如用户性别、年龄区间）进行本地缓存或分布式缓存（如 Redis）。

4.4 模型引擎层

模型引擎是推理的核心，负责加载 PD 模型并执行前向计算。它需要支持热加载、多模型版本管理，并保证计算的高效性。

4.4.1 模型引擎架构

模型引擎通常采用 微服务 + 模型容器 的部署模式。每个模型实例是一个无状态的服务，通过 gRPC 或 RESTful API 对外提供推理接口。

4.4.2 模型推理性能优化

• 模型量化： 将模型权重从 FP32 转换为 INT8，推理速度提升 2-4 倍，精度损失可控。
• 批处理： 将多个请求的特征向量合并为一个批次（Batch），利用 GPU 或 SIMD 指令并行计算。
• 模型剪枝： 移除对最终预测贡献较小的树节点或神经元，减小模型体积。

4.5 结果返回层

模型引擎输出的原始违约概率（PD 值）需要经过后处理，才能返回给业务方。结果返回层负责封装、策略映射和日志记录。

4.5.1 结果处理流程

1. 评分映射： 将 PD 值通过预设的映射函数转换为标准信用评分（如 300-850 分）。
2. 策略决策： 根据评分和业务规则（如黑名单、多头借贷阈值）生成决策建议（通过/拒绝/人工审核）。
3. 拒绝原因码： 如果拒绝，返回具体的拒绝原因码（如“R01：收入不满足最低要求”），便于后续优化。
4. 异步日志： 将完整的请求-响应链路日志写入 Kafka 或 Elasticsearch，用于离线分析和模型监控。

{
  "code": 0,
  "message": "success",
  "data": {
    "score": 680,
    "pd": 0.023,
    "decision": "approve",
    "reason_codes": [],
    "request_id": "req_20231027_001"
  }
}

4.6 高可用与容错设计

在线推理系统必须保证 99.9% 以上的可用性。高可用设计贯穿整个架构，从基础设施到应用层都需要考虑容错。

4.6.1 高可用策略矩阵

4.6.2 容错设计细节

• 超时控制： 每个下游调用设置严格的超时时间（如特征服务 50ms，模型推理 100ms），避免线程阻塞。
• 重试机制： 对幂等操作（如特征查询）设置最多 2 次重试，重试间隔递增（退避策略）。
• 降级方案： 当特征服务完全不可用时，使用用户最近一次缓存的评分结果，或返回一个保守的默认评分。
• 优雅关闭： 服务停止时，先停止接收新请求，等待正在处理的请求完成（Graceful Shutdown），再销毁资源。

4.7 架构设计总结

一个健壮的在线推理架构，需要在 性能、可用性 和 可维护性 之间取得平衡。通过清晰的模块划分、合理的缓存策略、完善的容错机制，可以构建一个能够应对生产环境复杂挑战的信用评分系统。