4. 模型退役的常见类型

在模型全生命周期管理中，退役并不是一个单一动作，而是一组具有不同触发条件、影响范围和治理要求的决策集合。很多团队把“下线模型”简单理解为关停接口，结果导致下游报表断裂、合规审计缺失、历史结果无法复现。要避免这些问题，首先必须准确区分五类常见退役形态：完全退役、部分退役、临时停用、强制退出与自然淘汰。它们的核心差异在于“退出范围”和“退出可逆性”两个维度。

一、核心原理：用两个维度定位退役类型

退役类型的选择，本质上由两个问题决定：第一，模型是整体退出还是局部退出；第二，退出是永久性的还是可恢复的。将这两个维度组合，就能得到清晰的分类框架：

退役类型	退出范围	可逆性	典型触发原因	适用场景
完全退役	整体	不可逆	业务终止、监管禁止、技术栈淘汰	产品下线、监管明令停用
部分退役	局部（客群/区域/产品线）	通常不可逆或需重新审批	局部效果不达标、区域合规差异	某地区停用、某客群停用
临时停用	整体或局部	可逆	数据异常、系统故障、监管问询	短期风险处置、等待修复
强制退出	整体	不可逆	重大缺陷、合规红线、严重偏差	监管处罚、重大事故
自然淘汰	整体	不可逆（渐进）	新模型替代、业务量自然萎缩	版本迭代、业务迁移完成

二、五类退役的区分与适用场景

1. 完全退役

完全退役指模型在所有业务场景、所有客群、所有区域中永久停止使用，且不再保留生产调用入口。它通常发生在业务线整体关闭、监管明确禁止该类模型、或底层技术栈已无法维护时。完全退役必须完成模型卡归档、参数与训练数据版本封存、下游依赖清理和监管报备。

2. 部分退役

部分退役是“模型仍在运行，但退出某些局部范围”。例如某评分模型在A地区因合规要求停用，但在B地区继续使用；或某推荐模型对未成年客群停用，对其他客群保留。部分退役的难点在于路由与隔离：必须确保停用范围不会通过间接调用被重新命中。

3. 临时停用

临时停用是可逆的，通常由数据质量骤降、系统故障、监管问询或短期市场异常触发。它的目标不是永久退出，而是“先止血、再修复”。临时停用必须设定明确的恢复条件和最长停用期限，否则会演变为事实上的完全退役。

4. 强制退出

强制退出是由外部或高层治理力量驱动的不可逆退出，常见于重大合规违规、模型严重歧视、重大财务损失或监管处罚。强制退出往往伴随时间压力，需要立即切断调用、冻结版本、启动追溯与整改报告。

5. 自然淘汰

自然淘汰是渐进式的：新模型上线后逐步承接流量，旧模型调用量自然降至零，最终关闭。它通常风险最低，但容易被忽视——很多团队以为“没人用了”就等于已退役，实际上旧模型可能仍被某个遗留脚本调用。

三、方法流程：从识别到执行的五步法

1. 识别触发信号：监控指标越界、合规通知、业务下线计划、替代模型上线。
2. 判定退役类型：依据范围与可逆性两个维度，对照上表确定类型。
3. 影响面分析：梳理下游系统、报表、API调用方、监管报送依赖。
4. 执行退出动作：关闭入口、切换路由、冻结版本、通知干系人。
5. 归档与复盘：保存模型卡、参数、日志、决策记录，完成事后复盘。

# 退役决策伪代码示例
def classify_retirement(scope, reversible, trigger):
    if trigger == "regulatory_ban" or trigger == "major_incident":
        return "强制退出"
    if reversible and scope in ("global", "partial"):
        return "临时停用"
    if scope == "partial":
        return "部分退役"
    if trigger == "replacement_complete":
        return "自然淘汰"
    return "完全退役"

四、案例与场景：同一模型的不同退役路径

假设某银行有一个信用评分模型M。某天监管通知：该模型在A省存在合规问题。此时可能的处理路径包括：

• 路径一：仅在A省停用，其他省继续——这是部分退役。
• 路径二：全行临时停用，等待合规整改——这是临时停用。
• 路径三：监管认定严重违规，要求永久停用——这是强制退出。
• 路径四：新模型M2上线，M逐步减量至零——这是自然淘汰。
• 路径五：该信用评分业务整体取消——这是完全退役。

同一个模型，因触发原因和治理决策不同，会走向完全不同的退役类型。因此，退役管理的第一步不是执行，而是准确定性。

五、误区与复盘

复盘时应重点检查三件事：退役类型判定是否有依据、影响面是否完整覆盖、归档材料是否可支撑未来审计与复现。只有把类型区分清楚，后续的模型风险退出管理才有稳定的治理基础。