4. 注册治理入门
在金融模型的生命周期中，模型不是一次性交付物，而是持续演进的“受控资产”。当模型数量从几个增长到几十、上百个时，真正的问题不再是“模型准不准”，而是“我们是否知道有哪些模型、它们分别是什么版本、谁批准过、当前生产上跑的是哪一个”。注册治理就是回答这些问题的制度与技术组合。本节从五个基本概念入手，建立后续实战所需的共同语言。
一、核心原理：注册治理是模型的“身份与档案系统”
注册治理的本质，是为每一个模型建立唯一身份，并围绕这个身份维护其全生命周期的可信记录。它由五个相互咬合的构件组成：模型注册表是存放模型身份与状态的中央台账；元数据管理定义每个模型“需要被记录什么”；版本控制保证模型变更可追溯、可复现；审批流程决定模型能否从开发态进入生产态；治理框架则是把前四者组织成角色、职责与规则的顶层制度。
可以用一个类比理解：注册表是“户籍系统”，元数据是“档案字段”，版本控制是“变更履历”，审批流程是“签证与放行”，治理框架是“法律法规”。缺少任何一环，模型资产就会退化为散落在个人电脑和共享盘里的文件。
二、方法流程：从模型提交到生产放行的标准路径
一个可落地的注册治理流程通常包含以下步骤，每一步都产生可审计的记录：
- 模型登记：开发人员向注册表提交模型，系统分配全局唯一ID，并写入基础元数据（名称、业务用途、负责人、开发环境）。
- 元数据补全：补充训练数据来源、特征清单、评估指标、假设与限制、依赖库版本等字段。
- 版本冻结：将模型文件、代码、配置、数据快照打包为不可变版本，打上语义化版本号。
- 审批提交：发起审批请求，触发模型验证、合规检查与业务确认。
- 评审与放行：评审人依据清单逐项确认，通过后状态变更为“已批准”，并记录审批人与时间戳。
- 部署与监控：生产环境只允许加载“已批准”版本，运行期指标回写注册表，形成闭环。
三、元数据管理：注册表的“字段设计”决定治理深度
元数据不是越多越好，而是要覆盖“识别、追溯、合规、运维”四类需求。以下是一份最小可用元数据清单，可作为注册表字段设计的起点：
| 类别 | 字段示例 | 用途 |
|---|---|---|
| 身份标识 | 模型ID、名称、业务域、负责人 | 唯一识别与责任归属 |
| 技术描述 | 算法类型、框架版本、输入输出Schema | 复现与集成 |
| 数据血缘 | 训练数据源、特征版本、采样区间 | 可追溯与偏差分析 |
| 评估记录 | 指标值、测试集、验证报告链接 | 准入判断与审计 |
| 合规信息 | 审批人、审批时间、限制条件 | 监管检查与责任界定 |
| 运维状态 | 当前版本、部署环境、监控指标 | 生产运行与告警 |
元数据应尽量结构化存储，避免自由文本。例如，模型版本建议采用语义化版本：
model_id: CRD-SCORE-001
version: 2.3.1
stage: production
approved_by: risk_committee
approved_at: 2025-03-12T10:30:00Z
training_data: dw.customer_credit_v4
metrics:
auc: 0.812
ks: 0.347
四、案例与场景：一次版本回滚暴露的治理缺口
某消费金融团队在季度末上线了一个新评分模型 v3.0，两周后监控发现通过率异常上升。排查时团队发现：生产环境加载的模型文件没有版本标记，注册表中 v3.0 的元数据只写了“算法：XGBoost”，没有记录训练数据区间和特征版本；审批记录是一封邮件，没有正式审批人签名。结果团队无法判断是模型本身问题还是数据漂移，只能整体回滚到 v2.9，但 v2.9 的模型文件也已被覆盖，最终花费三天从备份中恢复。
复盘结论很清晰：没有版本控制的注册表只是通讯录，没有审批记录的元数据只是备注。治理缺口往往不在算法层，而在“谁在什么时候批准了什么版本进入生产”这一条链路上。
五、治理框架：把流程固化为角色与规则
治理框架回答“谁对什么负责”。一个轻量但完整的框架通常包含三类角色和四条规则：
- 模型所有者：对模型业务表现负责，发起审批并维护元数据。
- 模型验证人：独立评估模型指标、假设与限制，出具验证意见。
- 审批委员会：由风险、合规、业务代表组成，决定是否放行。
四条基本规则：任何模型必须有唯一ID；任何生产版本必须经过审批；任何变更必须产生新版本；任何退役必须保留历史记录。把这四条规则写入注册表的校验逻辑，治理就从“靠人自觉”变成“系统强制”。
注册治理不是一次性的项目，而是模型资产化的基础设施。理解注册表、元数据、版本、审批与框架这五个概念之间的关系，是后续动手搭建治理环境的前提。