2. 金融AI服务化基础

在金融行业，模型从实验室走向生产环境，真正的门槛往往不在算法本身，而在于如何把模型稳定、合规、可审计地交付给业务系统。Serving API、批量推理与版本编排，正是金融AI服务化的三块基石。理解它们的定义、价值与协作关系，是后续实战的前提。

一、核心概念：三种服务形态的定位

Serving API（在线推理服务接口）面向实时请求场景，将模型封装为低延迟、高可用的HTTP/gRPC服务。它强调单次或小批量请求的响应时间、并发吞吐与稳定性，典型形态如风控评分接口、智能客服意图识别接口。

批量推理（Batch Inference）面向离线或准实时场景，对海量样本一次性或分片执行预测。它关注吞吐量、任务调度、失败重试与结果落库，典型形态如每日信贷客户风险重算、反洗钱可疑交易批量筛查。

版本编排（Version Orchestration）是贯穿前两者的治理层，负责模型版本注册、灰度发布、流量切换、回滚与依赖管理。它解决的是“多个模型版本如何共存、如何安全演进”的问题。

二、方法流程：从模型到服务的标准路径

金融AI服务化的落地通常遵循以下流程：

1. 模型注册：将训练完成的模型文件、特征配置、评估指标登记到模型仓库，生成唯一版本号。
2. 服务封装：为在线场景编写Serving API，定义输入输出Schema、超时、限流与鉴权策略。
3. 批量任务编排：为离线场景配置批量推理任务，指定数据源、分片策略、并发度与结果表。
4. 版本发布：通过版本编排层执行灰度发布，先切5%流量验证，再逐步全量。
5. 监控与回滚：持续采集延迟、错误率、特征漂移指标，异常时自动回滚至上一稳定版本。

三、典型应用场景与行业趋势

不同业务对服务形态的选择差异明显。以下清单对比了三类场景的关键特征：

行业趋势方面，三个方向值得关注：一是服务网格化，将模型推理作为独立微服务纳入Service Mesh，统一治理流量与安全；二是批流一体，同一模型同时支持在线与离线推理，减少重复开发；三是版本编排与合规审计深度融合，监管要求模型决策可追溯，版本编排层需完整记录每次发布、切换与回滚的操作日志。

四、常见误区与复盘要点

误区二：批量推理不需要版本管理。批量任务往往跑在夜间，若模型版本与特征版本不匹配，可能产生大面积错误结果，且次日才发现。建议批量任务启动时锁定版本号并记录到任务元数据。

误区三：灰度发布只看流量比例。金融场景还需关注客群分布，例如先对低风险客群灰度，再逐步扩大。以下是一个灰度配置示例：

canary:
  model: risk_score_v3
  baseline: risk_score_v2
  traffic:
    - segment: low_risk_customers
      weight: 0.10
    - segment: medium_risk_customers
      weight: 0.05
  rollback:
    error_rate_threshold: 0.02
    latency_p99_threshold_ms: 300
    auto_rollback: true

复盘时建议重点检查：版本切换是否有审批记录、批量任务是否绑定版本快照、监控指标是否覆盖特征漂移、回滚是否经过演练。只有把这三层能力打通，金融AI服务化才能真正支撑业务规模化。