如今，用机器学习、数据智能代替人进行预测和自动化决策已越来越普及。但随着其在金融业的深入发展与广泛应用，带来的风险也开始逐步暴露。为此，银保监会发布的《银行业保险业数字化转型指导意见》中提到，要进行模型的全流程管理与风险管理。本文以中国光大银行为例，着重阐述如何进行模型全流程管理。
中国光大银行 信息科技部 李成
模型、策略、算法、特征的定义
为了清晰地阐述模型的全流程管理，我们首先要对模型及其周边概念进行清晰界定，以便能够清楚地说明问题并有助于讨论和后续管理实践。从国内外监管出发，我们对其定义如下。
模型定义：本质上是一个函数，在一定的业务场景下，模型从输入通过函数式计算逻辑得到定量的结果。模型可通过算法训练得到或由专家规则确定，在训练完成或由专家生成固定模型的参数后，再经过验证、评审，部署于模型运行管理平台。部署的模型具有稳定的计算逻辑、客观性的解释说明、适用范围等属性。模型运行于模型运行管理平台。
特征定义：模型的输入字段。为了能够更好地沉淀特征知识，提高特征复用率，特征的易变动的个性化加工逻辑归属于模型（例如：特征的分箱加工会沉淀在模型中）。从而保证特征平台的特征具备稳定的加工口径、无歧义的业务含义和高复用率。特征一般具有客观性、量化性的特点。特征加工位于特征平台，成为模型运行在列维度的输入。
策略定义：业务场景下进行的决策及其决策逻辑，对应着真实业务行为。业务人员根据实际的业务需求在决策引擎上频繁地进行策略调整来实现业务目标。相较于模型来说其具有动态性、主观性，对应着业务行为，在系统上对应着策略平台/中台。如客群筛选（筛选后调用模型预测），根据模型结果进行触达，往往基于对模型的输入输出进行裁剪，并付诸行动。策略运行于各策略平台。
算法定义：狭义的描述性定义是逻辑回归、XGBOOST、神经网络、聚类、协同过滤等，用于生产成模型，类似协同过滤，其本身确定参数后即成为模型。无落地实体。
标签：标签的定义往往最宽泛，在机器学习领域通常将模型要预测的y作为label。在画像领域，客户属性被称为标签。为了便于管理实践，作如下约束定义，即和特征相对的、定性的或主观的属性。
模型全流程管理的基础是架构边界
上文中定义的目的是为了更好地划分清楚系统的功能和边界。只有系统功能和边界确定，才能在其基础上进一步管理和治理。
通过上文的相关定义，我们可以把相关系统归为五类。其中模型相关的三类中台型系统有：一是建模实验室；二是特征平台；三是模型运行管理。而基于客户特征进行分箱组合形成的客群划分与分析类画像系统，配套执行如触达营销或风险监控、业务调整等业务策略的策略平台，这两类应用向上归为领域类业务应用。
对于模型全流程管理来说，其最大的风险是机器学习技术本身的预测性质和黑盒性质带来的，虽然说当前拥有了很多的模型解释方法，但是根本上这个技术是更加偏重预测准确性，是基于相关性的，对于量化因果并不是那么看重。举例来说，一个逻辑回归模型，如果只有几个变量，那固然可以“解释一下”，但是如果是时下流行的所谓高维逻辑回归，动辄成千上万的变量，即便可以解释，也非人力可以看懂。而画像分析、策略执行往往人工干预较深，无法进行通用评价。对于此二类系统，强行将其纳入管理会适得其反。
光大银行基于数据资产管理框架的
模型全流程管理
机器学习由于其特殊性，往往在不经意间被“神秘化”。但是我们仍然可以找到一个切入角度，将其纳入标准化的管理流程。这个切入点就是数据资产管理。那么模型的资产又如何规定呢？
机器学习，顾名思义即机器通过大量的数据进行自动学习，故其一定会有一个学习目标存在。因此，我们规定，只要是同一个预测目标，亦即同一个y，就是同一个模型；而模型的迭代，不管是因使用的数据集更新而更新模型参数，还是因算法的更新，都只算作模型的不同版本。如聚类、协同过滤等非监督类的模型，其实也是存在目标的，只不过其评价方法比较特殊，需要单独确定，因此不影响模型资产化管理。
设计管理流程如下：一是在一个业务需求到来时，首先进行模型的需求评审，需要准确描述预测目标、评价方法。通过和模型资产库中的模型进行比对，确定是否已有同一个模型存在，如果不存在则新建模型资产，如果存在已有模型，则根据评审决定是复用模型还是升级为效果更优的模型，一旦选择升级则定义本次模型升级为同一个模型的下一个版本。二是待模型完成建设后，进行模型封版上传，包括模型所使用的数据集、建模脚本、模型环境（如使用的库等）、模型本身，以便完整地还原模型。三是进行必要的模型独立验证。四是模型上线评审。五是模型上线投产。六是模型持续监控、定期重检。其中，模型评价、持续监控、定期重检，本质上皆为模型全面风险管理要求（见图1）。
图1 模型开发上线管理流程
模型运行管理平台设计
为满足模型全流程管理的落地及模型运行的特殊技术要求，以及模型全面风险管理要求，光大银行建设了模型运行管理平台。该平台可以将上述过程全面落地，并在技术层面持续迭代满足运行技术要求。
模型运行平台的整体结构设计为两层，一层为管理层，一层为运行层，整体为微服务方式设计，管理层宕机不会影响模型的运行（见图2）。
图2 模型运行管理平台功能架构
对于管理层，除必要的流程管理、角色管理等内容，主要功能分为两个：一个模块为模型清单，可以理解为模型领域的“管理驾驶舱”，用于管理人员对全行的模型资产及其表现有直观了解。另一模块为模型实施，该模块功能具有重要意义。当前由于数据安全的要求越来越高，在光大银行，所有的建模工作全部在受控的位于生产域的实验室环境产生，因此模型四要素也位于生产环境。以往的工作方式会将模型要素及数据进行脱敏后，在开发测试环境进行打包，并以传统方式进行投产上线，存在安全性、便捷性等诸多问题。但是机器学习模型开发具有特殊性，即模型运行所依赖的环境和工程方法具备通用性，可以将其收敛至有限的工程方法并以低代码方式在线打包，类似开发领域的持续集成，一旦模型要素确定，就可以使用可视化非侵入的方式将模型打包为具有输入输出的微服务。对于批量模型，只需要增加工作流编排功能，则可将模型微服务配合输入数据集形成批量作业。模型实施产生的微服务和批量作业皆以镜像、批量任务的方式保存。
在模型实施完成，并通过测试、上线评审后，会由相应的角色进行模型上线。该步骤选定模型实施中生成的微服务镜像及批量任务图即可完成上线。其中批量任务也是通过批量转API的方式调用模型微服务，这样可以保证模型本身的健壮性和任务的可扩展性。
最后，因为模型都是以标准化的方式进行上线，可以以边车等非侵入的模型进行模型输入输出地抽取，并通过ELK等方式进行保存，留待模型报告生成时根据模型上线所确定的评价方式进行报告生成，以及监控告警（见图3）。
图3 模型运行管理平台技术架构
光大银行通过上述方案，将模型流程管理和模型风险管理在该平台落地，形成有效的管理与技术的整合。
模型全流程管理的实质是治理
在《数字化转型指导意见》中，未提及模型的治理，如果对全面风险管理及全流程管理的要求配套了完善的组织流程、权责分配，就能华丽转身为治理。为了避免“先发展后治理”的窠臼，在管理时即落地治理，是最优的选择。而选择使用数据资产角度，并利用中台思想剥离含义模糊的部分，可以有效提升机器学习带来的效能并最大程度降低模型风险，实现模型治理。
文章来源：“金融电子化”微信公众号