2. 金融模型基础

在进入模型压缩与部署之前，必须先建立对金融模型本身的系统认知。金融模型并非单一技术产物，而是业务目标、数据形态、监管约束与工程条件的交汇点。不同类型的金融模型在输入特征、输出形式、更新频率和性能要求上差异显著，这直接决定了后续压缩策略与部署架构的选择。本节围绕四类常见金融模型、模型生命周期以及部署场景与性能要求展开，为后续实战打下基础。

一、四类常见金融模型及其核心特征

金融业务场景高度分化，模型类型也由此形成明显分工。理解每类模型的核心任务与约束，是判断“该不该压缩、如何压缩”的前提。

• 信用评分模型：典型任务是预测借款人违约概率，输出通常为分数或概率。特征以结构化数据为主，如收入、负债比、历史还款记录。模型多为逻辑回归、梯度提升树（如XGBoost、LightGBM）。特点是可解释性要求高，监管往往要求给出拒绝理由，因此模型不能是纯黑箱。
• 欺诈检测模型：任务是在极短时间内判断交易是否异常。数据高度不平衡，正样本极少，且欺诈模式会快速演变。常用模型包括孤立森林、Autoencoder、图神经网络以及集成树模型。核心挑战是低延迟与高召回率的平衡，误杀正常交易会直接影响用户体验。
• 量化交易模型：用于生成买卖信号、仓位建议或价格预测。输入包括行情序列、订单簿、因子数据等。模型可能是线性因子模型、时序模型（LSTM、Transformer）或强化学习策略。对推理延迟极其敏感，微秒级差异可能直接转化为盈亏。
• 风险预测模型：覆盖市场风险、信用风险、操作风险等，常见任务包括VaR预测、压力测试、波动率建模。模型形式包括GARCH族、蒙特卡洛模拟、Copula等。计算量大，常需批量运行，对吞吐量要求高于单次延迟。

二、模型生命周期：从训练到退役的完整链路

金融模型不是“训练完就结束”，而是一个持续演进的闭环。完整生命周期通常包括以下阶段：

1. 问题定义与数据准备：明确预测目标、标签定义、时间窗口与合规边界。金融数据常存在幸存者偏差、前视偏差和样本不平衡。
2. 特征工程与模型训练：构建特征管道，选择算法，进行交叉验证。金融时序数据必须按时间切分，不能随机打乱。
3. 模型验证与合规审查：除统计指标外，还需通过稳定性检验、公平性审查和监管报备。信用评分模型常需提供评分卡映射。
4. 部署与监控：模型上线后需持续监控输入分布、输出分布和业务指标。数据漂移和概念漂移是金融场景的常态。
5. 再训练与退役：当监控指标触发阈值时，启动再训练或回滚。旧模型需保留版本记录以满足审计要求。

三、部署场景与性能要求

部署场景决定了模型的运行环境和性能边界。常见场景包括：

性能要求通常围绕四个维度：延迟、吞吐、内存占用和数值精度。压缩技术正是在这四个维度之间做权衡。例如，量化交易场景可能接受一定精度损失以换取微秒级延迟；而信用评分场景则可能更关注可解释性和稳定性，压缩空间相对有限。

# 典型在线推理性能日志片段
[2024-06-01 10:23:45] model=fraud_v3 latency_p50=8ms latency_p99=42ms
[2024-06-01 10:23:45] model=fraud_v3 throughput=1200 req/s memory=512MB
[2024-06-01 10:23:46] model=credit_v2 batch_size=10000 elapsed=95s cpu=78%

四、误区与复盘：金融模型部署中的常见陷阱

在实际项目中，团队常因忽视金融场景的特殊性而踩坑。以下是最典型的几类误区：

• 用离线指标代替在线表现：AUC提升不代表线上收益提升。金融场景中，阈值选择、成本敏感度和业务规则往往比模型本身影响更大。
• 忽视数据漂移：欺诈和量化场景中，数据分布变化极快。压缩后的模型如果缺乏漂移检测，可能迅速失效。
• 过度压缩导致可解释性丧失：信用评分模型若被压缩成难以解释的形式，可能无法通过合规审查。
• 忽略数值稳定性：风险预测模型涉及大量浮点运算，压缩后可能引入数值误差，导致VaR估计偏差。
• 部署环境与训练环境不一致：训练用Python，部署用C++或FPGA，特征管道未对齐会导致线上效果骤降。

五、本节核心关系图

下图将四类金融模型、生命周期阶段与部署性能要求整合在一起，帮助建立整体认知框架。