1. 课程导论：模型 serving 与流式决策在额度定价中的核心价值
1.1 为什么额度定价需要“流式决策”？
在传统信贷场景中，额度定价通常依赖离线批处理模型——每日或每小时更新一次用户风险评分，再基于评分卡给出固定额度。这种模式在应对“双十一”大促、实时交易拦截、动态调额等高频场景时，暴露出三个致命短板：
- 时效性滞后：用户行为发生后数小时甚至隔天才能反映在额度上，错过最佳营销或风控窗口。
- 决策粒度粗：所有用户共享同一套定价模板，无法针对个体实时行为（如刚还款、刚提额）做差异化调整。
- 系统耦合高：模型训练、特征工程、决策引擎分属不同团队，一次定价策略变更需要数周联调。
流式决策（Streaming Decision）将模型 serving 从“批处理”升级为“事件驱动”：每当用户触发关键事件（申请、交易、还款、逾期标记），系统在毫秒级完成特征计算、模型推理、策略编排，并直接输出额度与利率。这不仅是技术架构的升级，更是风控与增长效率的质变。
核心观点：额度定价的本质是在“风险-收益”曲线上为每个用户找到最优落点。流式决策让这个落点可以随用户实时状态动态漂移，而非固定不变。
1.2 模型 serving 在额度定价中的角色
模型 serving 是流式决策的“计算引擎”。在额度定价链路中，它承担三个关键职责：
| 职责 | 传统做法 | 流式 serving 做法 |
|---|---|---|
| 特征计算 | 离线 Hive/Spark 跑 T+1 特征宽表 | 实时特征管道（Flink + Redis）秒级聚合 |
| 模型推理 | PMML 或 pickle 模型定时加载，批量评分 | 容器化模型服务（gRPC/REST），单样本 < 50ms |
| 策略编排 | 硬编码规则 + 离线回测 | 可视化决策流 + A/B 实验动态切换 |
从技术栈看，模型 serving 需要同时满足低延迟（P99 < 100ms）、高吞吐（单机 QPS > 2000）、模型热更新（不重启服务）三个硬约束。这也是本课程后续章节重点攻克的技术难点。
1.3 课程目标与学习路径
本课程面向金融风控与机器学习工程交叉岗位的从业者，目标是在 30 章内构建一套完整的“模型 serving + 流式决策”知识体系，并落地到额度定价场景。具体目标拆解如下：
- 理解流式决策架构：掌握事件驱动、实时特征、决策流编排的核心设计模式。
- 掌握模型 serving 工程：从模型序列化、容器化部署、到性能压测与监控告警。
- 实现额度定价策略：基于实时风险评分、资金成本、用户生命周期价值（LTV）动态计算最优额度与利率。
- 具备生产级交付能力：包括灰度发布、降级熔断、数据一致性保障等 SRE 最佳实践。
学习路径按“基础-进阶-实战”三阶段组织：
学习建议：前 10 章侧重架构与原理，中间 10 章深入模型 serving 工程细节，最后 10 章为完整额度定价项目实战。建议每章结束后完成配套的代码实验（课程提供 Docker 沙箱环境）。
1.4 课程核心架构概览
整个课程围绕一个统一的参考架构展开，该架构将额度定价拆解为四个层次：
- 事件接入层：Kafka / Pulsar 接收用户行为事件，保证至少一次投递与低延迟。
- 特征计算层：基于 Flink 的实时特征工程，支持滑动窗口、累计值、比率等常用算子。
- 模型推理层：模型容器化部署（Docker + K8s），支持 XGBoost / LightGBM / 深度学习模型的热加载。
- 决策执行层：规则引擎 + 策略编排，输出最终额度与利率，并记录决策日志用于离线分析。
以下架构图展示了各层之间的数据流与依赖关系：
1.5 课程适用人群与前置知识
| 角色 | 关注点 | 前置要求 |
|---|---|---|
| 风控算法工程师 | 模型如何上线、延迟如何优化、特征实时性对 AUC 的影响 | 熟悉 Python/ML 框架，了解基本风控指标 |
| 机器学习平台工程师 | 模型 serving 架构、容器化部署、性能压测与监控 | 熟悉 Docker/K8s，有后端开发经验 |
| 数据架构师 / 技术负责人 | 流式决策整体方案选型、成本与 SLA 评估 | 了解大数据生态，有系统设计经验 |
⚠️ 避坑提示：本课程不涉及模型训练算法本身（如 XGBoost 调参），而是聚焦“训练好的模型如何高效、稳定地服务于线上决策”。如果你期望学习模型训练，建议先补充相关基础。
1.6 本章小结
本章作为课程导论，明确了三个核心认知：
- 流式决策是额度定价从“静态”走向“动态”的关键技术路径。
- 模型 serving 是流式决策的计算核心，需要同时满足低延迟、高吞吐、热更新三大工程约束。
- 本课程按“架构 → 工程 → 实战”三阶段组织，最终交付一个可运行的额度定价系统。