3. 精算模型Serving架构设计：离线训练与在线推理的分离
在生产环境中，精算模型的生命周期必须严格划分为离线训练与在线推理两个独立阶段。这种分离架构是保障模型稳定性、可追溯性与高性能服务的基础。
3.1 离线训练与在线推理的分离原则
| 维度 | 离线训练 | 在线推理 |
|---|---|---|
| 触发方式 | 定时调度（每日/每周）或事件触发 | 实时API请求（毫秒级响应） |
| 数据范围 | 全量历史数据（TB级） | 单条或小批量请求数据 |
| 计算资源 | Spark/GPU集群，高吞吐 | CPU/内存优化，低延迟 |
| 模型产物 | 序列化模型文件（.json/.pkl） | 加载到内存的模型对象 |
| 特征工程 | 批处理ETL，可包含复杂聚合 | 实时特征计算，轻量级 |
| 版本管理 | 模型注册中心记录版本 | 按版本号加载指定模型 |
核心原则：离线训练产生的模型文件是离线与在线之间的唯一契约。在线推理服务不执行训练逻辑，只加载已训练好的模型进行预测。
3.2 Serving系统的核心组件
一个完整的精算模型Serving系统由三个核心组件构成：模型加载器、特征工程引擎和推理引擎。三者协同工作，将离线训练的XGBoost模型转化为高可用的在线API服务。
3.2.1 模型加载器
- 启动加载：服务启动时从模型仓库（如S3、HDFS或本地路径）加载指定版本的XGBoost模型文件。
- 热更新：支持在不重启服务的情况下，通过信号或配置中心触发模型重载。
- 版本回滚：当新模型效果异常时，快速回退至上一稳定版本。
- 内存管理：多模型共存时，使用LRU缓存策略控制内存占用。
3.2.2 特征工程引擎
- 特征对齐：确保在线特征计算逻辑与离线训练时完全一致（包括缺失值填充、分箱映射、编码方式等）。
- 实时计算：对请求中的原始字段进行轻量级变换，如年龄计算、保费率换算、风险因子组合。
- 特征缓存：对高频使用的派生特征（如历史赔付均值）使用Redis等缓存加速。
3.2.3 推理引擎
- 批量推理：支持单条请求与批量请求（最多100条/次）两种模式。
- 结果后处理：将XGBoost输出的原始分数转换为精算业务指标（如赔付率、风险等级、建议费率）。
- 性能监控：记录每次推理的延迟、QPS、模型输出分布，用于告警与容量规划。
3.3 架构图：精算模型Serving系统
下图展示了离线训练与在线推理分离后的完整Serving架构，以及核心组件之间的数据流关系。
3.4 架构设计要点
设计要点一：无状态服务 — Serving节点不存储任何训练数据或中间状态，所有状态（模型版本、特征配置）由外部配置中心管理。这使得服务可以水平扩展，任意节点故障不影响整体可用性。
设计要点二：特征一致性校验 — 在线特征工程引擎必须包含与离线训练相同的特征变换逻辑。建议将特征变换代码封装为独立库，在训练流水线和Serving服务中共享使用，避免因特征不一致导致模型效果偏差。
3.5 请求处理流程
- 客户端发起请求：通过API网关发送JSON格式的原始保单数据。
- API网关鉴权与路由：验证API Key，根据请求路径路由到对应的模型服务。
- 特征工程引擎处理：对原始字段进行实时特征变换，生成与训练时完全一致的特征向量。
- 推理引擎执行预测：将特征向量输入XGBoost模型，获取原始预测分数。
- 结果后处理与返回：将分数映射为精算业务指标（如预期赔付率、风险等级），封装为JSON响应返回客户端。
- 异步监控记录：将请求参数、特征值、预测结果、处理耗时写入监控系统与日志中心。
3.6 架构图：请求处理时序
下图以时序图形式展示一次完整推理请求在Serving系统各组件间的交互过程。
3.7 架构决策总结
| 决策项 | 推荐方案 | 理由 |
|---|---|---|
| 模型序列化格式 | XGBoost原生JSON | 跨语言兼容，支持模型版本对比 |
| 特征库共享 | Python包 + C++扩展 | 保证离线/在线特征一致性 |
| API协议 | gRPC (内部) + RESTful (外部) | 内部低延迟，外部易集成 |
| 模型热更新 | 信号量 + 原子文件替换 | 零停机部署，快速回滚 |
| 监控告警 | Prometheus + Grafana | 开源生态，与K8s原生集成 |
架构核心思想：离线训练负责“生产模型”，在线Serving负责“消费模型”。两者通过模型文件与特征配置契约解耦，使得训练团队与工程团队可以独立迭代，同时保障线上服务的稳定性与性能。