1. 课程导入
在金融机构的日常运营中，模型早已不只是“算出一个数”的工具。无论是信用评分、市场风险计量、反洗钱监测，还是资产配置与压力测试，模型都深度嵌入业务流程、监管报送和经营决策。然而，很多团队把注意力集中在“把模型建出来”，却忽略了模型从诞生到退出的完整生命周期。结果往往是：模型上线后缺乏监控，参数漂移无人察觉，版本混乱，退役时没有留痕，最终在监管检查或业务损失面前陷入被动。本课程的第一节，就是要帮助大家建立一张完整的“模型全生命周期地图”，并重点理解退役管理为什么是这张地图上不可缺失的一环。
一、学习目标：从“会建模型”走向“会管模型”
本课程的学习目标可以概括为三个层次。第一，建立全局视角：理解金融模型从需求提出、开发验证、上线部署、监控预警、定期重检到最终退役的完整链条，知道每个阶段的关键交付物和责任人。第二，掌握退役管理的核心方法：包括退役触发条件、影响评估、替代方案、数据与文档归档、监管沟通以及系统下线操作。第三，形成实战能力：能够结合真实场景，识别模型生命周期中的常见风险点，并设计可落地的退役管理流程。
核心转变：从“模型是一次性项目”转变为“模型是持续演进的资产”。资产有生命周期，就必然有退出机制。没有退役管理的模型生命周期，是不完整的。
二、核心概念：生命周期、退役与治理边界
金融模型生命周期，是指模型从业务需求触发到最终停止使用的全过程。它通常包括六个阶段：需求与立项、开发与验证、上线与部署、运行监控、定期重检、退役与归档。每个阶段都有明确的准入准出条件，而不是“建完就扔给IT上线”。
退役管理，则是指当模型不再满足业务需求、监管要求或技术条件时，有计划、有步骤地将其从生产环境中移除，并完成相关数据、文档、权限和依赖关系的清理与归档。退役不等于“删除”，更不等于“不管”。它是一次受控的、可审计的、有替代方案的状态迁移。
这里需要区分三个容易混淆的概念：模型停用是业务上不再使用该模型输出；模型下线是技术上将模型从生产系统移除；模型退役是包含业务停用、技术下线、文档归档和监管报备的完整治理动作。三者层层递进，缺一不可。
三、整体框架：六阶段闭环与退役触发条件
把生命周期画成一条直线并不准确，因为模型管理是一个闭环：退役后的复盘经验会反馈到新模型的需求与开发中。因此，我们更推荐用“六阶段闭环 + 退役触发”的框架来理解。
退役触发条件通常来自四个方面：监管要求变化，例如新规明确某类模型不得再用于授信决策；业务需求消失，例如某产品线停售，对应评分卡不再需要；模型性能持续不达标，例如KS值连续多个季度低于阈值，且重检后仍无法修复；技术架构淘汰，例如底层计算平台下线，模型无法继续运行。识别触发条件是退役管理的第一步，也是最容易被忽视的一步。
| 阶段 | 核心任务 | 关键交付物 | 常见风险 |
|---|---|---|---|
| 需求与立项 | 明确业务目标与边界 | 模型需求说明书 | 目标模糊、数据不可得 |
| 开发与验证 | 建模、测试、独立验证 | 模型开发报告、验证报告 | 过拟合、验证不独立 |
| 上线与部署 | 系统集成、权限配置 | 上线审批单、部署清单 | 版本错配、权限过宽 |
| 运行监控 | 性能跟踪、漂移预警 | 监控报表、预警日志 | 指标缺失、告警无人处理 |
| 定期重检 | 年度/季度重检与优化 | 重检报告、优化方案 | 重检流于形式 |
| 退役与归档 | 停用、下线、归档、报备 | 退役审批、归档清单 | 无替代方案、文档丢失 |
四、实战价值与常见误区复盘
为什么退役管理值得单独拿出来讲？因为它在实战中直接关系到三件事：合规安全、成本控制和决策质量。一个未受控退役的模型，可能仍在某个报表中被引用，导致监管报送数据错误；也可能因为文档缺失，导致审计时无法解释历史决策依据。反过来，规范的退役管理可以释放计算资源、降低维护成本，并为新模型提供清晰的历史基线。
实战场景：某银行信用卡评分卡因业务调整需要退役。团队提前三个月启动影响评估，发现该模型还被用于两个下游报表和一个反欺诈规则。于是先完成替代模型切换，再逐步停用旧模型输出，最后归档开发文档、验证报告和监控记录，并向监管报备。整个过程没有出现数据断档，审计时也能完整追溯。
常见误区：第一，把“退役”等同于“删除”，导致历史数据无法追溯；第二，没有替代方案就匆忙停用，造成业务中断；第三，只关注技术下线，忽略监管报备和文档归档；第四，退役决策没有留痕，事后无法说明“为什么退、何时退、谁批准”。这些误区在监管检查中往往会被重点追问。
本节的核心结论是：金融模型生命周期管理不是可选项，而是模型治理的基础设施；退役管理不是终点，而是新一轮模型建设的起点。只有把退役纳入整体框架，模型资产才能真正做到“可解释、可追溯、可控制”。