4. Serving架构模式
在金融模型从训练走向生产的过程中，Serving（模型服务）架构决定了预测结果以多快速度、多大粒度、何种一致性交付给业务。金融场景对时效、合规与可解释性要求极高，因此不能简单照搬互联网推荐系统的Serving方案。本节围绕四种主流Serving模式展开对比，并给出金融场景的选型原则。
一、核心原理：四种Serving模式的本质差异
四种模式的根本区别在于触发时机、数据边界与模型更新方式三个维度。
- 批处理Serving：按固定周期（如每日收盘后）对全量样本批量打分，结果写入特征库或结果表。模型在批次间保持不变，延迟以小时或天计。
- 实时Serving：请求到达时即时调用模型，基于请求携带或在线特征库拉取的特征完成单条或小批量推理，延迟通常在毫秒到百毫秒级。
- 流式Serving：以事件流为输入，模型持续消费消息队列中的记录并输出打分，强调吞吐与持续处理，而非单次请求响应。
- 在线学习Serving：模型在服务过程中持续接收反馈标签并增量更新参数，预测与训练交织，追求对概念漂移的快速适应。
关键认知：批处理与实时并非对立，而是同一特征体系下的两种交付通道。金融生产系统常见“批处理生成离线特征 + 实时Serving拼接在线特征”的混合架构。
二、方法流程与关键参数
以实时Serving为例，典型链路为：请求接入 → 特征组装 → 模型推理 → 后处理 → 返回。特征组装阶段需区分请求内特征与远程特征，后者通过特征存储（Feature Store）拉取，是延迟的主要来源。
# 实时Serving伪配置示例
serving:
mode: realtime
max_batch_size: 32
timeout_ms: 80
feature_source:
- name: user_profile
type: redis
ttl_s: 300
- name: tx_stats_1h
type: feature_store
freshness_s: 60
model:
path: /models/credit_risk/v12
framework: onnx
流式Serving通常基于Flink或Kafka Streams实现，需关注水位线（watermark）与状态后端；在线学习则需引入参数服务器或增量梯度更新组件，并设置回滚快照。
三、金融场景选型原则
选型应遵循“业务时效倒推、合规约束优先、成本可控”三条主线。下表给出典型金融场景的匹配建议。
| 场景 | 推荐模式 | 延迟要求 | 关键约束 |
|---|---|---|---|
| 日终信贷风险评分 | 批处理 | 小时级 | 可追溯、可复算 |
| 信用卡反欺诈 | 实时Serving | <100ms | 特征新鲜度、降级策略 |
| 实时行情异常监测 | 流式Serving | 秒级 | 高吞吐、乱序处理 |
| 高频交易信号 | 在线学习 | 微秒级 | 模型稳定性、风控熔断 |
| 客户流失预警 | 批处理+实时混合 | 小时级+分钟级 | 特征一致性 |
选型口诀：能批不流、能流不学。在线学习引入的复杂度和风险最高，仅在概念漂移显著且反馈闭环可靠时才采用。
四、案例与误区复盘
某券商在智能投顾场景中，初期直接采用在线学习Serving，结果因反馈标签延迟且噪声大，模型在两周内出现严重漂移，导致推荐组合回撤扩大。复盘后改为“批处理训练 + 实时Serving推理 + 每日增量更新”的折中方案，既保证了时效，又保留了人工审核窗口。
常见误区包括：
- 把流式当实时：流式强调吞吐，单条延迟未必低于实时Serving，反欺诈场景需明确区分。
- 忽视特征一致性：离线训练与在线Serving特征口径不一致，是金融模型线上效果衰减的首要原因。
- 在线学习无熔断：缺少模型回滚与异常检测，一旦数据管道污染，损失会迅速放大。
- 过度追求低延迟：在日终评分场景强行上实时架构，徒增运维成本而无业务收益。
综上，金融Serving选型不是追求最先进，而是追求与业务时效、合规要求和运维能力最匹配。理解四种模式的本质差异，才能在架构评审中做出可落地的决策。