CN111523811A - 模型验证和监控方法及系统、设备、存储介质 - Google Patents

Abstract

本发明公开一种模型验证和监控方法及系统、设备、存储介质，其中方法主要包括以下步骤：配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；基于对模型报告的配置和定义自动生成验证报告；在仪表板中输出展示至少一个验证模型的相关信息，该相关信息包括模型的基本信息、验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。采用本发明，可以实现自动化、周期性的验证报告生成工作，根据配置预警规则反馈模型亏损报警，做到及时干预，最后通过仪表板集中监测系统中模型的性能表现，全局掌控模型的健康状况。

Description

模型验证和监控方法及系统、设备、存储介质

技术领域

本发明涉及模型管理技术领域，尤其涉及一种模型验证和监控方法及系统、设备、存储介质。

背景技术

在当今世界各国的各类金融机构中，模型被广泛地开发和应用于营销、风控、决策等场景，成为包括信贷业务在内的各种金融业务中不可或缺的重要工具。但是，由于模型本身的错误或使用的不当，也会带来风险，这就是模型风险。例如，从1998年长期资本管理(LTCM)的崩溃、2007年美国次贷危机、2012年摩根大通(JP Morgan chase)“伦敦鲸”事件等都与模型风险有关，这表明模型风险仅作为一种操作风险就已经具备巨大的破坏力，而一个机构乃至一个国家的模型风险管理体系缺失，将给该机构或国家带来破坏力不可估量的系统性风险。

模型风险管理是一项长期性、系统性、复杂且细致的工作，在缺乏高效率方法和工具的情况下，必定会占用大量的人力资源，且工作的时效性和质量可能仍难以保障。

现有的模型管理中随着业务线多样化、业务场景类型复杂化，机构内模型数量和模型工作任务迅速增加。对于机构内模型的验证和监控就显得尤为重要，若模型所处状态无法及时了解，将导致无法有效跟踪模型工作状态造成拖延，或者无法及时知悉模型性能亏损导致经营亏损，若模型投产后验证机制缺乏，缺乏周期性的验证计划，花费大量人力资源生成报告，将存在模型报告不规范，无法及时发现和定位模型问题等情况的发生。

发明内容

本发明实施例提供一种模型验证和监控方法及系统、设备、存储介质，实现自动化、周期性的验证报告生成工作，根据配置预警规则反馈模型亏损报警，做到及时干预，最后通过仪表板集中监测系统中模型的性能表现，全局掌控模型的健康状况。

本发明实施例第一方面提供了一种模型验证和监控方法，可包括：

配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

基于对模型报告的配置和定义自动生成验证报告；

在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

本发明实施例第二方面提供了一种模型验证和监控系统，可包括：

初始设置模块，用于配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

报告生成模块，用于基于对模型报告的配置和定义自动生成验证报告；

结果展示模块，用于在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

本发明实施例第三方面提供了一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行以下步骤：

配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

基于对模型报告的配置和定义自动生成验证报告；

在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

本发明实施例第四方面提供了一种设备，可包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行以下步骤：

配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

基于对模型报告的配置和定义自动生成验证报告；

在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

本发明的有益效果：

通过构建企业级的模型资产管理平台，模型运行状态或者模型工作所处阶段根据配置好的模型仪表板能够实时了解，机构能够及时了解模型工作进程，跟进工作流里需要的人为审批等决策环节，对于已投产模型，当发生模型亏损或者异常状况时，报警规则被触发且实时反馈到模型仪表板内，用户能够早期介入进行模型调查工作。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种模型验证和监控方法的流程示意图；

图2是本发明实施例提供的另一种模型验证和监控方法的流程示意图；

图3是本发明实施例提供的一种模型验证和监控系统的架构图；

图4是本发明实施例提供的一种企业级模型管理系统的结构示意图；

图5是本发明实施例提供的另一种企业级模型管理系统的结构示意图；

图6是本发明实施例提供的一种企业级模型管理系统的架构图；

图7是本发明实施例提供的模型表单、模型工作流、模型登记功能依赖关系图；

图8是本发明实施例提供的流程引擎的架构图；

图9是本发明实施例提供的模型评估服务的架构图；

图10是本发明实施例提供的数据回流服务的架构图；

图11是本发明实施例提供的另一种模型验证和监控系统的结构示意图；

图12是本发明实施例提供的一种设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

此外，术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如，可以是固定连接，可拆卸连接，或整体式构造；可以是机械连接，或电连接；可以是直接相连，或者是通过中间媒介间接相连，又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

需要说明的是，本申请实施例提供的模型验证和监控方法主要的应用场景是：企业管理者或者非技术研发人员需要对企业内所有模型或部分模型进行统一监控、查看验证报告、查看模型健康状态等相关处理的应用场景。

本发明实施例涉及的设备可以是大型计算机、PC机、等其他具备数据处理能力的计算机处理设备。

如图1所示，在本申请的第一个实施例中，模型验证和监控方法至少包括以下步骤：

S101，配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准。

需要说明的是，在进行模型验证和监控前需要对展示验证结果的仪表板进行配置，同时需要对模型验证过程中模型的验证计划、标准化的模型报告、以及预警规则进行配置；另外，还可以定义模型验证频率、数据的周期范围及基准等参数。其中，预警规则可以根据验证指标的阀值判断模型的性能状况，一旦触发，及时反馈到仪表盘中和通知相关模型工作者。

具体实现中，当模型上线后，模型会被储存为一个.pmml、.pkl等格式的文件。模型文件会储存或配置在该模型所属的模型工作环境里面，在验证报告生成的时候等待被调用。生成的验证报告根据报告类型，可能需要识别模型的样子，调用模型文件的目的是为了识别模型的样子，模型里面的特征，单个特征是如何分箱等等。同时系统需要定义报告生成的频率，定义报告的数据周期范围，定义报告的基准参考月份，从生成的报告中，验证模型的有效性和准确性。例如，一个月一次的生成周期，报告的数据时间范围可以是包括前6个月的数据。其中，在配置验证报告时可以根据模型的类别配置标准化报告，例如，当模型运用了逻辑回归算法且预测目标是为二分类目标，一般需要配置的标准化报告为数据打印报告、单个变量统计报告、人群稳定性报告、特征稳定性报告， KS报告、ROC报告，若机构需要拓展报告的范围，则机构可以根据自己需求自己撰写报告的代码，代码由系统管理员配置到系统里面，该自定义报告就可以在系统里面配置报告的时候被调用。

S102，基于对模型报告的配置和定义自动生成验证报告。

需要说明的是，模型的验证报告由系统统一进行自动化生成。所有的模型的报警状态，健康状态实时反映在一个仪表板上，做模型集中话的监控。当需要深入到单个模型，查看其详细状态时，可以从模型仪表板中选定其中一个进入到该模型的工作环境，查看其验证结果和报警规则，单独进行下一步工作。

在一种可选的实现方式中，系统需要进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。具体的，系统平台里的模型验证结果页面用于查看已经部署了的模型验证计划结果，用户可以查看验证表格里的不同衡量指标和每个指标背后的完整验证报告。验证结果可以以不同的方式展现，方便用户理解，例如，以图表的方式，以表格的方式，以报告的方式，或者以报警个数的方式。针对二分类和连续性的模型目标，系统平台配置的标准化报告有，特征分析报告、人群稳定性报告、单变量统计报告、频率分布报告、KS报告、ROC报告。对于其他的报告类型，用户根据需求可以进一步配置。报告的格式主要分为.pdf，.xlsx，.html。一般来说，报告的标题会涵盖如下信息，模型名称、模型所处切割组、模型目标、时间窗口等。报告标题中的信息变量可以根据需求进行自定义调整。

S103，在仪表板中输出展示至少一个验证模型的相关信息。

需要说明的是，模型仪表板显示所有已经注册了的模型的目前状态，用户可以在仪表板内进行模型筛选操作定位到模型进行进一步操作。在仪表板内点击任意模型可以导航至该模型相关的验证结果页面，验证结果一般可以以扇形统计图，条形统计图，表格、或其他形式显示。

可选的，模型仪表板上显示的跟模型状态相关的变量和验证结果的表达方式可以根据用户需求进行自定义调整。一般来说，模型仪表板会显示模型名称，模型所处的切割组，模型所属的工作环境，模型报警级别和报警规则触发数目，模型总的健康概况，模型所处工作阶段，模型离上次验证日期天数，等其他信息。

在一种可选的实现方式中，系统可以通过对比验证报告和模型仪表板内配置的报警规则和健康等级划分规则显示报警状态和健康状态在仪表板上。例如，系统平台根据定义好的报警规则和验证结果指标，产生报警信号/事件并且反馈到模型仪表板。用户可以查看模型的单条报警或者全部报警追踪报警缘由和安排下一步工作。用户可以修改当前的报警规则，也可以添加更多的报警规则。模型所属人员可以根据验证结果更改模型健康状态并附加评论。模型健康状态等级可以分为，健康，注意-轻微，注意-中等，注意-紧急，需要立即处理。

在一种可选的实现方式中，每个模型的相关人员可以添加相关评论以记录对模型的观察，同时可以查看模型的历史活动。

在本申请的第二个实施例中，如图2所示，模型验证和监控方法至少包括以下步骤：S201，构建企业级别模型资产库，将所有模型及相关文档注册至同一管理平台。

具体实现中，本系统首先需要将企业内的所有模型集中到系统平台上进行管理，打破业务部门之间数据、模型的屏障，使资产共享和复用变为可能，进而才能进行企业级别的管理。对于企业内的任一个模型，需要将该模型和相关的文档注册到上述平台。

下面将举例说明在新业务上也就是冷启动的场景下，构建企业级模型资产库进行模型管理的好处：在业务冷启动的场景下，往往因为没有数据而没有办法开发新业务对应的模型，对于信贷业务中相同的环节，可以考虑把其他业务中已经在用的模型复用到新业务中，此做法可能不一定完美，但套用相同环节的不同业务的模型多少会赋予新业务一定的风控能力。具体的，新业务相关的工作人员可以获取到系统赋予的对应的权限，该工作人员可以登录到系统上查看别的业务的模型看是否适用并且复用到新业务的决策流程当中，该工作人员可以把可用模型相关的一些人工分析部件拷贝一份并部署到新业务的生产环境中，同时该工作人员也需要在系统内创建新的模型定义和模型需求等。

在一种具体的实现方式中，模型注册的过程可以包括以下步骤：

1)创建模型定义：模型名称，模型描述，模型对应的数据库和数据表单。

2)定义模型元数据：模型名称，模型描述，模型所属业务，模型使用的业务场景，模型类型，模型输出类型，模型归属人员，模型开发中的样本窗口，模型发布日期，等等。

3)连接模型所对应的外部数据库和该模型的数据表单。

4)在平台里对数据表单选取模型使用的变量用于生成模型验证报告，并且给这些变量赋予报告角色，如定义某变量为模型使用的特征：识别模型使用的变量并赋予模型特征的角色，识别报告所需要用到的其他变量并赋予相关角色，报告角色有模型调用日期角色，模型分数角色，样本权重角色，模型目标角色，等等。

5)配置模型，上传模型文件，例如模型的实际文件格式为.pmml或.pkl，模型文件将在生成报告时被调用，调用的目的在于平台在生成报告时需要识别模型的样子；定义数据窗口和基准，定义模型预测目标并且赋予报告角色-目标，定义分数分布和模型所属切割组。

6)可选的，可以同时上传模型相关的支持性文件。

7)可选的，可以附加模型相关的评论。

S202，在管理平台中配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准。

S203，进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。S204，在仪表板中输出展示至少一个验证模型的相关信息。

需要说明的是，本实施例中的模型验证和监控方法中的待验证模型均存在与同一企业级的模型管理平台中，过程中涉及的与实施一一致的步骤，此处不再详述。

在本申请实施例中，通过构建企业级的模型资产管理平台，模型运行状态或者模型工作所处阶段根据配置好的模型仪表板能够实时了解，机构能够及时了解模型工作进程，跟进工作流里需要的人为审批等决策环节，对于已投产模型，当发生模型亏损或者异常状况时，报警规则被触发且实时反馈到模型仪表板内，用户能够早期介入进行模型调查工作。

在本申请的第三个实施例中，提供了模型验证和监控的详细实现过程，验证和监控架构如图3所示：

需要说明的是，在图3所示的验证和监控过程中，报告的生成依赖数据的可得性，报告的维度依赖数据的丰富性。模型的验证和监控离不开数据，需要外部了解数据库，每个模型的工作环境需要连接到处在数据库里面对应的该模型所属的那张数据表，数据表里面可能涵盖的有模型的特征数据，模型被调用后的结果(回流到此数据表内)，模型被调用后产生结果的对应日期。当该模型的工作环境成功连接到该数据表后，在该模型的工作环境内就可以查阅数据表中的字段，针对验证报告的生成，在模型工作环境内需要给字段赋予验证角色，例如把某来自该模型数据表的字段定义为模型特征角色，这是为了在报告生成的时候，报告能识别需要做分析的模型特征；又例如模型被调用后生成的分数需要被定义为验证角色-模型分数，在生成报告的时候，报告才能知道该模型分数是该模型的预测输出，俗称反应变量。

另外，数据表内的数据一般可以看作两部分，输入数据和输出数据，输入数据为跑模型所需要的数据，如果没有输入数据则模型没有办法产生有效的输出，输出数据可以理解为模型被调用后生成的结果。对于验证报告的生成来说，对输入数据和输出数据都需要。输入数据可能是由机构系统外部通过渠道进入到模型决策平台，输出数据由模型被调用后在决策平台上生成，这些数据都需要回流到一个与模型验证系统连接的一个数据库，这样子数据才能被利用起来进行验证工作。

可选的，验证报告的本质其实可以看作是一段代码，每个报告也就是一段代码，每段代码的运行结果可能是不一样的根据报告的类型。报告代码可以决定报告的最后输出格式，例如模型验证报告的最后格式可以为.html,.x l sx,.pdf等等。

需要说明的是，验证报告根据模型类型，输出的统计结果不一样。例如， KS/ROC报告输出的是一个KS的值(是一个数)或者是一个ROC的值(是一个数)，他们的值的大小被用来衡量模型的有效性和区分度。针对这些值，只有当他们被定义在什么范围内为合理，在什么范围外为偏差，才会有意义，因此可以针对报告输出的度量进行报警规则的撰写。关于报告输出的统计度量如何取值，每跑一次报告生成的对应的报告度量结果，例如KS的值或者ROC的值，会被储存在系统里面对应的该模型所属的一个数据表。

可选的，一般模型表现作者(归属于模型作者)会根据产生的报告度量或模型的类型撰写报警规则，例如定义“当KS小于40，报警且模型健康状态更改为需要注意”，“当KS小于25，报警且模型健康状态更改为紧急”。该模型的报警状态和模型的健康状态都会反映在系统大仪表盘内，因此系统用户实际上不需要钻到每一个模型所属的工作环境里面才知道模型的状况，用户在仪表板上就能一览无遗，如果发现个别模型有报警情况再针对该模型进行深度调查。

可选的，当维护模型的人员对单个有报警情况的模型进行深度调查后，他可以决定下一步工作，可能是发起模型的校准需求，模型的线下验证，该模型因为效果欠佳进行下下线退役，或者该模型的重新开发，等等。

可选的，当所有单个模型的验证和监控都配置妥当后，在系统总的大盘上就能看到所有模型的基本状况，包括模型的信息，目前模型所处的阶段，报警情况，健康状态，等等信息，仪表板内需要反应的信息可以自定义，但是自定义的字段一定要能被系统所取到，此时即实现了模型的集中化验证和监控。

如图4所示，在本申请的第四个实施例中，企业级模型管理架构中的角色权限管理主要用于管理不同业务团队内，不同角色在系统平台中的权限，各个角色根据各自匹配的权限可以通过仪表板查看感兴趣的数据，例如，可以通过仪表板1进行集中化管理，查看模型清单中的内容，通过仪表板2进行验证和监控，查看单个或多个模型的验证和监控结果。另外，模型清单以及单个或多个模型的验证和监控结果可以共享复用至不同的业务团队。

需要说明的是，工作流中或者说系统中的不同角色至少可以包括模型所属人、工作流作者、模型作者、模型审批人员和系统管理员。其中：

模型所属人：该模型的拥有者，新模型需求的具体发起人，模型所属人可以拥有除系统管理员之外的所有系统角色权限，可以对自己有查看权限的模型进行删除，修改，等操作。

工作流作者：工作流作者在平台系统中创建和发布模型工作流，根据模型工作任务定义工作流中的子任务把工作流中的子任务指派到负责人，工作流作者与模型所属人可以为同一个人，但一般来说，工作流作者需要对模型工作细节有一定经验且具备一定的知识基础。

模型作者：模型作者负责完成模型工作流当中的子任务，模型作者可以按照使用机构的内部岗位不同继续细分为数据分析人员、模型开发人员、模型验证人员、模型部署人员，等除了模型审批人员之外的模型工作相关人员，模型作者负责创建模型定义，配置模型元数据，相关模型变量和变量角色，开发模型，创建模型验证计划和撰写报警规则等。

模型审批员：区别于模型作者，模型审批员一般不具体负责模型工作的实际操作，模型审批员对模型工作流中的审批子任务负责，负责审批模型作者的产出和完成审批子任务。

系统管理员：系统管理员负责权限管理，配置外部数据库和每个模型对应的数据表，部署已发布的工作流，和配置自定义模型仪表板和自定义模型验证报告。

自定义角色：根据模型工作需求，机构可通过系统管理员创建自定义的角色。

在具体的实现场景中，不同角色对应的权限，完成的任务不同，例如：

模型所属人：模型所属人进入平台系统查询目前自己管理的所有模型的状态，针对某个模型的具体历史活动或者目前的模型表现状况可以进入该模型的工作环境进行查询。

工作流作者：工作流作者进入平台系统的工作流管理页面根据新的模型任务创建模型工作流，对于例如新模型开发任务，工作流作者也可以选择对应新模型开发的通用工作流，一般来说，该工作流将涵盖模型开发-模型测试-模型审批-模型部署-模型上线-模型验证等子任务环节，工作流作者在系统内，对每个子任务指派到人，定义每个子任务中需要的交付物，创建完毕后需要上传该工作流，等待系统管理部署。

模型作者：在工作流正式部署并生效之后，随着工作流推进，当前第一个子任务的模型作者会收到来自系统的任务邮件和系统连接。例如对于子任务-模型开发环节来说，模型开发人员在系统平台内拥有模型作者此角色对应的权限，根据该子任务的要求，模型开发人员完成数据清理生成数据质量报告，进行指标衍生和特征筛选工作生成特征报告，进行模型开发和测试并生成报告，统一上传到该子任务内并提交该子任务。

模型审批员：对于新模型上线前，模型需要进行测试和验证，模型审批人员查看模型开发、模型开发、模型验证阶段的报告的规范性和合理性，给予是否审批通过的批示。只有当模型审批员批准后，模型工作才能继续移动到下一个环节。

系统管理员：当工作流作者创建并上传了工作流之后，系统管理员需要部署该工作流，只有工作流部署了，工作流才会真正生效，在仪表板的显示。针对工作流中子任务指派的负责人，系统管理员赋予他们相对应的系统角色和相关权限。

本实施例中，内容管理信息库可以相当于上述实施例中的企业级别的模型资产库。内容管理信息库中模型注册的过程如下：首先不同的业务团队创建各自的模型定义；进而定义模型元数据，主要包括所属的业务线、业务场景、模型类型、输出类型、模型归属人员、样本窗口和发布日期等；然后连接模型对应数据库和数据表，再配置模型，设置验证定义。其中，所定义的模型元数据和创建的模型定义可以体现在模型清单中。在对单个或多个模型进行验证和监控时，主要是验证监控模型对应的数据库和数据表、模型的配置和配置验证的定义。

在本申请的第五个实施例中，从原理功能的角度将企业及模型管理系统划分为模型管理平台、工作流管理系统、模型验证/评估系统四个重要模块，不同模块之间在模型风险管理中的工作关系如图5所示：

关系线a：模型组件-模型作者-模型工作环境-内容管理系统

对于已存在的模型，模型作者在模型工作环境中创建模型定义，上传该模型相关的部件和相关文档，模型的部件和相关文档会被储存在模型风险管理平台的内容管理系统。

关系线b：模型作者-自定义报告-系统管理员-系统管理-仪表板

一般来说，自定义报告的模板在模型风险管理平台之外由模型作者设计好后，由系统管理员统一管理和配置到平台内，当配置完成后，模型作者可以在模型工作环境中利用该报告进行验证与监控工作，验证与监控的结果会反馈到仪表板。

关系线c；工作流作者-工作流管理-仪表板

工作流作者在工作流管理内创建和维护工作流，当工作流发布并且部署后，工作流的状态会汇总到仪表板内，除此之位，根据工作流里的工作任务和负责人，工作流会督促模型作者进入模型工作环境完成任务。

关系线d：系统管理员-系统管理/权限管理系统管理员负责日常系统平台的管理，维护平台环境，协助工作流作者进行工作流部署，日常平台日志维护，还有管理平台的角色和角色所对应的权限。

关系线e：模型生产环境(非平台环境范围)-模型回流数据(非平台环境范围)-模型管理平台数据库(非平台环境范围)-模型验证/监控工作-验证报告和结果-内容管理系统-模型工作环境

模型在生产环境被调用产生模型回流数据，回流数据经过ETL等处理回流到模型风险管理平台外接的数据库，当模型作者在平台内进行模型验证和监控等工作，平台内的验证和监控引擎调取外接数据库里模型对应的数据，结合平台内的模型定义、变量和验证报告角色等信息，生成验证报告和结果，储存到内容管理系统，模型作者此时就可以在模型工作环境内查看到验证报告和结果。

关系线f：模型工作环境-内容管理系统-工作流管理系统(工作流引擎) 当模型作者在模型工作环境中完成相应的工作或任务，完成的工作或操作储存到内容管理系统，内容管理系统与工作流管理系统互相交流，工作流系统识别下一步行动，往前推进工作流进度，返回给内容管理系统。

在本申请的第六个实施例中，企业级模型管理系统的架构如图6所示，包括展示层、接入网关层、系统应用业务层和基础能力层。其中：

展示层：主要用于用户使用的登录和系统的前端操作界面可视化展现。

接入网关层：

1.nginx网关：实现网络隔离，API的统一管理，对外暴露公网服务，对内进行内网流量分流和转发，支持API请求协议转换，请求的负载均衡分发，提高系统的高可用和统一化安全入口管理。

2.访问鉴权：对API访问进行访问鉴权。防止非法请求操作。

系统应用业务层：

模型资产管理平台:

a)模型表单：模型登记中最基本的单元模块，由多个字段组成，代表字段的归类组合，可以根据业务自定义扩展，为工作流模型节点引用。

b)模型工作流：为模型登记过程中的载体，定义了模型生命周期管理流程环节。

c)模型登记：登记模型实例信息，存储模型登记详情，包含模型的内容、关联文件。

其中，模型表单、模型工作流、模型登记功能依赖关系如图7所示：模型表单可以根据业务场景需要自定义和可扩展，不同的表单结合工作流最终构成模型登记的整一个过程。工作流中的模型节点需引用某一个模型表单。模型工作流结合模型表单产生模型登记处理过程，模型登记的整一个处理过程中节点的变化需要调用模型工作流处理。模型登记处理过程中，会实例化模型数据，完善模型的需求信息、开发信息、验证信息等，模型登记完成，模型的实例化数据也完成。

数据报表：

a)跟模型相关的操作和运行历史记录，例如模型(pmml、pdf、excel、.pkl)，数据报告(.xlsx，.doc，.pdf，.r)，验证报告(.doc，.pdf，模型code)等，会分别存入文件对象系统OSS和大数据平台，定时任务job会根据业务需求，生成业务需要的BI报表，并且通过邮件等渠道发送。

b)模型运行平台根据生产真实的实时调用情况，会产生的分数等维度数据落地数据库，模型管理平台会从数据库中多维度获取数据库中变量和数据，结合动态脚本代码，生成不同维度报表，形成模型验证或监督报告。

流程引擎：

模型管理的核心功能，实现对模型生产，模型登记、模型审批等进行流程化规范化管理，他是驱动模型全生命周期管理的引擎，可以支持业务的配置化和可扩展，与业务模型工厂和模型运行平台进行环境打通衔接，支持模型自迭代。流程引擎的架构如图8所示：其中，内嵌activiti开源流平台，开发一个无状态的springboot应用，以MySQL作为状态存储层，以独立应用集群的方式部署，对外暴露统一的域名。符合BPMN标准，实现公司定制化的通用流程平台。流程节点支持触发外部HTTP接口，对外可以暴露流程相关的restful接口，业务上层可以直接调用。提供web版控制台，可视化的流程拖拽编辑页面，该编辑器支持创建或编辑activiti流程档案(activiti特有的一种流程文件格式，本质上是一个ZIP包，内包含了标准的BPMN流程定义XML文件和相关资源文件如图标等)，以及流程实例查询接口(API)。校验完成后，将流程档案部署到当前的activiti引擎中。流程引擎的流程节点可调用服务包内指定的服务接口，这些接口本身需要做鉴权处理以防止非法访问，确保服务调用安全。

模型评估及模型验证/监控服务：

模型预测评估在模型资产系统中支持标准通用的模型文件的预测评估，目前设计支持pmml，py模型文件类型预测评估。整体的评估架构如图9所示：

前端页面上送模型编码、模型数据文件或者指定模型数据源到模型评估服务中。模型评估服务根据前端上送的内容，从模型资产管理服务获取模型文件、模型报告模板，并且如指向数据源方式，则从现有配置的数据源中获取数据。模型评估服务对模型文件进行解析并且运行，运行完毕后产出模型运行报告。模型评估服务发送模型运行报告到模型资产管理服务，并由模型资产管理服务下发通知到指定邮箱。模型评估服务调用大数据云平台的采集接口，下发模型运行数据到大数据云平台。

其中，数据回流服务主要提供三方模型工厂和模型运行平台的运行数据回流，支持实时同步回流和离线批量文件回流两种方式，为模型监督提供数据来源，如图10所示主要是为模型开发评估和回流效果评估提供数据来源。图10 中，模型开发环境(即模型开发建模工厂)产生的建模相关数据与模型运行环境，即模型生产的实时数据运行，模型管理平台产出的一些配置数据和工作流数据，通过数据生产的方式传递到消息中间件kafka或者类似数据总线。数据回流服务：消费消息中间件或类似数据总线产生的业务数据，进行格式转换统一处理，业务指标的相关前置处理。数据流入大数据平台。大数据平台运行报表任务，进行spark和hive等定时计算，结果在模型管理平台进行可视化查看和展现。作流相关的流程审批信息以及BI报表可以实时通过三方信息通道触达用户终端。

基础能力层：

1)大数据平台：支持大数据场景的数据存储和实时spark流计算和hive 等基础存储和计算能力。

2)MySQL：支持模型表单、模型登记等基础对象字段以及流程引擎和模型流转状态等存储和业务查询等操作。

3)ELK：支持日志数据的存储，基于一些规则的操作，监控和可视化查看能力。

4)OSS：支持模型相关的文件对象存储。

5)Kafka：支持系统间数据的消息异步化流转，系统间松耦合。

业务监控：

模型运行情况，线上异常API调用或异常模型管理流程操作，进行实时脚本化计算和告警。

在本申请的第七个实施例中，为本发明实施例提供了另一种模型验证和监控系统。如图11所示，本实施例的所述模型验证和监控系统10可以包括：初始设置模块101、报告生成模块102、结果展示模块103、显示调整模块104和评论获取模块105。

初始设置模块101，用于配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准。

报告生成模块102，用于基于对模型报告的配置和定义自动生成验证报告。

在可选实施例中，报告生成模块102具体用于进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。

需要说明的是，针对二分类和连续性的验证模型，所述验证报告至少包括标准化报告有，特征分析报告、人群稳定性报告、单变量统计报告、频率分布报告和KS/ROC报告中的一个或多个。

结果展示模块103，用于在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

在可选实施例中，结果展示模块103具体用于对比验证报告和模型仪表板内配置的报警规则和健康等级划分规则显示报警状态和健康状态在仪表板上。

需要说明的是，模型仪表板上显示所有已注册模型的当前状态，并以预设的显示形式显示针对所选模型的验证结果，显示形式包括扇形统计图、条形统计图或表格中的一个或多个。

显示调整模块104，用于根据用户需求调整模型仪表板上显示的模型状态或验证结果的表达方式。

评论获取模块105，用于获取并记录针对验证模型的评论数据。

需要说明的是，上述系统中各模块和单元的详细执行过程可以参见上述实施例中的描述，此处不再赘述。

在本发明实施例中，通过定位于企业级别，协助机构建立企业级的模型资产库，对运用在不同业务场景中的模型进行集中化管理，所有模型及其相关文档全部注册到同一个平台上；模型运行状态或者模型工作所处阶段根据配置好的模型仪表板能够实时了解，机构能够及时了解模型工作进程，跟进工作流里需要的人为审批等决策环节，对于已投产模型，当发生模型亏损或者异常状况时，报警规则被触发且实时反馈到模型仪表板内，用户能够早期介入进行模型调查工作；根据赋予的平台权限，用户能够在平台上轻易的找到需要的模型资产，实现模型资产在机构内部共享和复用，互相借鉴促进智能化发展；基于模型生命周期，定义一个通用版本的模型工作流，让所有的模型工作能够遵循相对一致的流程进行，工作流的每个环节指派到具体负责人，且根据环节不同，定义好需要上传的工作结果并根据需要在工作流里配置审批环节，从而在单个模型工作流里保证每个工作环节的工作质量，工作流与工作流之间，模型工作质量要求统一。

本发明实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图1-图10所示实施例的方法步骤，具体执行过程可以参见图1-图10所示实施例的具体说明，在此不进行赘述。

请参见图12，为本发明实施例提供了一种设备的结构示意图。如图12所示，所述设备1000可以包括：至少一个处理器1001，例如CPU，至少一个网络接口1004，用户接口1003，存储器1005，至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口 (如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及模型验证和监控应用程序。

在图12所示的设备1000中，用户接口1003主要用于为用户提供输入的接口，获取用户输入的数据；网络接口1004用于与用户终端进行数据通信；而处理器1001可以用于调用存储器1005中存储的模型验证和监控应用程序，并具体执行以下操作：

配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

基于对模型报告的配置和定义自动生成验证报告；

在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

在一些实施例中，处理器1001还用于执行以下操作：

进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。

在一些实施例中，处理器1001还用于执行以下操作：

对比验证报告和模型仪表板内配置的报警规则和健康等级划分规则显示报警状态和健康状态在仪表板上。

在一些实施例中，模型仪表板上显示所有已注册模型的当前状态，并以预设的显示形式显示针对所选模型的验证结果，显示形式包括扇形统计图、条形统计图或表格中的一个或多个。

在一些实施例中，处理器1001还用于执行以下操作：

根据用户需求调整模型仪表板上显示的模型状态或验证结果的表达方式。

在一些实施例中，针对二分类和连续性的验证模型，所述验证报告至少包括标准化报告有，特征分析报告、人群稳定性报告、单变量统计报告、频率分布报告和KS/ROC报告中的一个或多个。

在一些实施例中，处理器1001还用于执行以下操作：

获取并记录针对验证模型的评论数据。

本发明的模型验证和监控方法基于模型管理系统实现，该模型管理系统包括如下设备：模型统一管理设备、模型开发设备、模型运行设备和模型监控设备，其中模型监控设备可以和模型统一管理设备集成为一体。以上设备可以理解为单一的计算机设备也可以为计算机集群，根据具体应用需求设置即可。

模型开发设备用于进行模型开发。模型运行设备可以理解为将由模型开发设备开发完成的模型置入业务环境中运行完成业务需求的设备。模型开发设备与模型统一管理设备通信连接，模型统一管理设备根据模型开发设备的开发需求为其配置工作流，模型开发设备基于该工作流向模型统一管理平台上传各任务的完成结果。可见，在工作流成中模型数据会直接上传至模型统一管理设备，一方面能够保证模型开发流程的规范化，一方面在上传至模型统一管理设备的模型可以允许共享和复用。

模型监控设备与模型运行设备和模型统一管理设备通信连接，通过模型统一管理设备进行监控需要配置，并根据配置的监控需求从模型运营环境设备获取包括但不限于模型生产数据的模型参数进行模型状态监控。为便于展示监控结果，模型监控设备通过仪表盘显示各个模型的参数。通常由于各个模型具有各自模型的数据协议和借口。本发明的模型的集中化管理方法中通过构建统一的管理系统，从模型的开发过程中就开始进行，直至模型的注销失效便于进行统一，另一方面，通过设定在模型监控设备配置有进行协议统一的中间件，以对数据进行格式调整以适配模型监控设备。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory， ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (10)

1.一种模型验证和监控方法，其特征在于，所述方法包括：

配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

基于对模型报告的配置和定义自动生成验证报告；

在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

2.根据权利要求1所述的模型验证和监控方法，其特征在于，所述方法还包括：

进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。

3.根据权利要求1所述的模型验证和监控方法，其特征在于，所述方法还包括：

对比验证报告和预先配置的报警规则、健康等级划分规则在仪表板上显示相应模型报警状态和健康状态。

4.根据权利要求1所述的模型验证和监控方法，其特征在于，所述模型仪表板上显示所有已注册模型的当前状态，并以预设的显示形式显示针对所选模型的验证结果，所述显示形式包括扇形统计图、条形统计图或表格中的一个或多个。

5.根据权利要求4所述的模型验证和监控方法，其特征在于，所述方法还包括：

根据用户需求调整所述模型仪表板上显示的模型状态或验证结果的表达方式。

6.根据权利要求1所述的模型验证和监控方法，其特征在于，针对二分类和连续性的验证模型，所述验证报告至少包括标准化报告有，特征分析报告、人群稳定性报告、单变量统计报告、频率分布报告和KS/ROC报告中的一个或多个。

7.根据权利要求1所述的模型验证和监控方法，其特征在于，所述方法还包括：

获取并记录针对验证模型的评论数据。

8.一种模型验证和监控系统，其特征在于，所述系统包括：

初始设置模块，用于配置模型仪表板中模型的验证指标、设置模型的验证计划、标准化的模型报告、以及预警规则，并定义模型验证频率、数据的周期范围及基准；

报告生成模块，用于基于对模型报告的配置和定义自动生成验证报告；

结果展示模块，用于在所述仪表板中输出展示至少一个验证模型的相关信息，所述相关信息包括模型的基本信息、所述验证报告相对于所述验证指标的结果信息、模型预警规则的触发数目、模型的整体健康状况。

9.根据权利要求8所述的模型验证和监控系统，其特征在于，所述报告生成模块，具体用于：

进入当前验证模型的模型生产环境，查看其验证结果和报警规则，并据此输出验证报告。

10.根据权利要求8所述的模型验证和监控系统，其特征在于，所述结果展示模块，具体用于：

对比验证报告和模型仪表板内配置的报警规则和健康等级划分规则显示报警状态和健康状态在仪表板上。

Images