模型生命周期管理方法及系统、设备、存储介质
技术领域
本发明涉及模型管理技术领域,尤其涉及一种模型生命周期管理方法及系统、设备、存储介质。
背景技术
在当今世界各国的各类金融机构中,模型被广泛地开发和应用于营销、风控、决策等场景,成为包括信贷业务在内的各种金融业务中不可或缺的重要工具。但是,由于模型本身的错误或使用的不当,也会带来风险,这就是模型风险。例如,从1998年长期资本管理(LTCM)的崩溃、2007年美国次贷危机、2012年摩根大通(JP Morgan chase)“伦敦鲸”事件等都与模型风险有关,这表明模型风险仅作为一种操作风险就已经具备巨大的破坏力,而一个机构乃至一个国家的模型风险管理体系缺失,将给该机构或国家带来破坏力不可估量的系统性风险。
模型风险管理是一项长期性、系统性、复杂且细致的工作,在缺乏高效率方法和工具的情况下,必定会占用大量的人力资源,且工作的时效性和质量可能仍难以保障。
现有的模型管理中随着业务线多样化、业务场景类型复杂化,机构内模型数量和模型工作任务迅速增加。一般来说,由于不同业务部门之间关于模型工作的流程不统一,模型工作有可能过于谨慎或者过于粗糙,导致模型工时不合理或模型质量参差不齐,时效性低,模型工作流程的每个环节责任模糊,无法定位到具体负责人,影响模型工作进度;模型投产后验证机制缺乏,缺乏周期性的验证计划,花费大量人力资源生成报告,模型报告不规范,无法及时发现和定位模型问题等。
发明内容
本发明实施例提供一种模型生命周期管理方法及系统、设备、存储介质,通过构建企业级的模型管理平台,可以解决模型管理中流程化和统一化的相关问题。
本发明实施例第一方面提供了一种模型生命周期管理方法,可包括:
基于模型生命周期定义通用版本的模型工作流;
根据不同的模型任务需求在通用模型工作流上进行模型任务处理,模型任务至少包括模型需求发起、模型开发、模型验证、模型实施和部署、模型审批、模型上线、投产后持续验证和监控子任务中的一个或多个。
本发明实施例第二方面提供了一种模型生命周期管理系统,可包括:
工作流创建模块,用于基于模型生命周期定义通用版本的模型工作流;
工作流处理模块,用于根据不同的模型任务需求在通用模型工作流上进行模型任务处理,模型任务至少包括模型需求发起、模型开发、模型验证、模型实施和部署、模型审批、模型上线、投产后持续验证和监控子任务中的一个或多个。
本发明实施例第三方面提供了一种计算机存储介质,所述计算机存储介质存储有多条指令,所述指令适于由处理器加载并执行以下步骤:
基于模型生命周期定义通用版本的模型工作流;
根据不同的模型任务需求在通用模型工作流上进行模型任务处理,模型任务至少包括模型需求发起、模型开发、模型验证、模型实施和部署、模型审批、模型上线、投产后持续验证和监控子任务中的一个或多个。
本发明实施例第四方面提供了一种设备,可包括:处理器和存储器;其中,所述存储器存储有计算机程序,所述计算机程序适于由所述处理器加载并执行以下步骤:
基于模型生命周期定义通用版本的模型工作流;
根据不同的模型任务需求在通用模型工作流上进行模型任务处理,模型任务至少包括模型需求发起、模型开发、模型验证、模型实施和部署、模型审批、模型上线、投产后持续验证和监控子任务中的一个或多个。
本发明的有益效果:
基于模型生命周期,定义一个通用版本的模型工作流,让所有的模型工作能够遵循相对一致的流程进行,工作流的每个环节指派到具体负责人,且根据环节不同,定义好需要上传的工作结果并根据需要在工作流里配置审批环节,从而在单个模型工作流里保证每个工作环节的工作质量,工作流与工作流之间,模型工作质量要求统一。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种模型生命周期管理方法的流程示意图;
图2是本发明实施例提供的一种企业级模型管理系统的结构示意图;
图3是本发明实施例提供的另一种企业级模型管理系统的结构示意图;
图4是本发明实施例提供的一种企业级模型管理系统的架构图;
图5是本发明实施例提供的模型表单、模型工作流、模型登记功能依赖关系图;
图6是本发明实施例提供的流程引擎的架构图;
图7是本发明实施例提供的模型评估服务的架构图;
图8是本发明实施例提供的数据回流服务的架构图;
图9是本发明实施例提供的一种模型生命周期管理系统的结构示意图;
图10是本发明实施例提供的工作流创建模块的结构示意图;
图11是本发明实施例提供的注册建库模块的结构示意图;
图12是本发明实施例提供的一种设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形,意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元,而是可选地还包括没有列出的步骤或单元,或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。
此外,术语“安装”、“设置”、“设有”、“连接”、“相连”、“套接”应做广义理解。例如,可以是固定连接,可拆卸连接,或整体式构造;可以是机械连接,或电连接;可以是直接相连,或者是通过中间媒介间接相连,又或者是两个装置、元件或组成部分之间内部的连通。对于本领域普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含义。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
本发明实施例涉及的设备可以是大型计算机、PC机、等其他具备数据处理能力的计算机处理设备。
如图1所示,在本申请的第一个实施例中,模型生命周期管理方法至少包括以下步骤:
S101,基于模型生命周期定义通用版本的模型工作流。
需要说明的是,系统可以基于任一模型工作需求或模型工作任务创建通用模型工作流,让所有的模型工作能够遵循相对一致的流程进行,工作流的每个环节指派到具体负责人,且根据环节不同,定义好需要上传的工作结果并根据需要在工作流里配置审批环节,从而在单个模型工作流里保证每个工作环节的工作质量,工作流与工作流之间,模型工作质量要求统一。
具体实现中,针对模型开发、模型验证、模型维护、模型部署、模型优化、等单个工作任务或多个工作任务组合在一起,都可以建立一个对应的工作流定义相应的工作范围和所需要进行的子工作环节。工作流作者定义工作流中所需的子任务环节和把子环节指派到具体负责人或负责团队。可以理解的是,所有此工作流相关的模型工作用户(包括子任务环节负责人或负责团队)都可以在各自系统内看到各自所需完成的任务,并且用户还可以看到自己所负责的任务环节处于整个模型工作流的哪个位置,提前安排出时间,促进环节负责人间的沟通。
在一种优选的实现方式中,某一模型工作需求或模型工作任务创建模型工作流的步骤可以包括以下过程:
1)工作流作者创建工作流和定义工作流中的子任务,当工作流作者创建工作流时,他需要定义工作流的名称,工作流的类型,和对应的通用工作流模板;在定义子任务时,工作流作者需要清楚模型任务所需要的子任务,并且在创建工作流时就把子任务指派到人。
2)工作流作者发布此工作流,系统管理员审核无误后部署工作流,工作流根据定义好的任务环节和负责人自动推进。
3)工作流根据进度给下一个子任务的负责人发送邮件,该任务的相关工作人员收到邮件提醒和系统登陆链接,同时获得符合该工作人员的对应系统权限,可以进行模型查阅、修改、和其他模型相关工作权限。
4)当负责该子任务的工作人员完成并上传该任务所要求的文档时,该子任务就算是完成了,工作流自动推进到下一个子任务并通知相关负责人。工作流重复步骤3和4直至该工作流所有子任务被完成,工作流作者可以根据工作质量和工作流进度决定是否关闭工作流,并打完成标签。
5)所有有权限查阅该模型或该工作流的用户都可以在工作流生效期间查阅所有的历史活动和相关记录。
6)若工作流作者在工作流生效期间进行了工作流修改或更新,则工作流根据更新,则工作流需要重新发布,系统管理员需要重新部署,工作流将从最近的未完成的子任务重启,往后推进工作。
S102,根据不同的模型任务需求在通用模型工作流上进行模型任务处理。
具体实现中,将任一个任务放入一个通用的模型工作流中,模型工作流涵盖多个模型工作的子环节,对于不同的模型任务需求,工作流作者可以在通用模型工作流的基础上进行自定义修改,确保所有模型工作遵循一定的规范性但也根据各自的模型工作需求提供灵活性。当工作流发布且被激活,工作流将自动跟进工作进度,自动提醒子环节负责人完成任务。
在本申请的第二个实施例中,系统可以构建企业级别模型资产库,将所有模型及相关文档注册至同一管理平台,然后根据预先配置的模型仪表板实时监控模型资产库中各模型在生命周期内的模型工作状态和性能指标。
具体实现中,本系统首先需要将企业内的所有模型集中到系统平台上进行管理,打破业务部门之间数据、模型的屏障,使资产共享和复用变为可能,进而才能进行企业级别的管理。对于企业内的任一个模型,需要将该模型和相关的文档注册到上述平台。可选的,企业也可以将历史模型和相关的文件通过接口的方式传入统一管理平台中,以便对一个企业中的所有的模型进行统一管理。下面将举例说明在新业务上也就是冷启动的场景下,构建企业级模型资产库进行模型管理的好处:在业务冷启动的场景下,往往因为没有数据而没有办法开发新业务对应的模型,对于信贷业务中相同的环节,可以考虑把其他业务中已经在用的模型复用到新业务中,此做法可能不一定完美,但套用相同环节的不同业务的模型多少会赋予新业务一定的风控能力。具体的,新业务相关的工作人员可以获取到系统赋予的对应的权限,该工作人员可以登录到系统上查看别的业务的模型看是否适用并且复用到新业务的决策流程当中,该工作人员可以把可用模型相关的一些人工分析部件拷贝一份并部署到新业务的生产环境中,同时该工作人员也需要在系统内创建新的模型定义和模型需求等。
在一种具体的实现方式中,模型注册的过程可以包括以下步骤:
1)创建模型定义:模型名称,模型描述,模型对应的数据库和数据表单。
2)定义模型元数据:模型名称,模型描述,模型所属业务,模型使用的业务场景,模型类型,模型输出类型,模型归属人员,模型开发中的样本窗口,模型发布日期,等等。
3)连接模型所对应的外部数据库和该模型的数据表单。
4)在平台里对数据表单选取模型使用的变量用于生成模型验证报告,并且给这些变量赋予报告角色,如定义某变量为模型使用的特征:识别模型使用的变量并赋予模型特征的角色,识别报告所需要用到的其他变量并赋予相关角色,报告角色有模型调用日期角色,模型分数角色,样本权重角色,模型目标角色,等等。
5)配置模型,上传模型文件,例如模型的实际文件格式为.pmml或.pkl,模型文件将在生成报告时被调用,调用的目的在于平台在生成报告时需要识别模型的样子;定义数据窗口和基准,定义模型预测目标并且赋予报告角色-目标,定义分数分布和模型所属切割组。
6)可选的,可以同时上传模型相关的支持性文件。
7)可选的,可以附加模型相关的评论。
进一步的,当每个模型的模型注册和配置完成后,所有模型都已经被集中到了系统平台上,此时可以开始监控所有模型的表现即各模型的工作状态和性能指标等。本系统在集中化监控方面主要以模型仪表板的方式集中反映模型所处工作状态和模型性能指标。
需要说明的是,本系统中仪表板可以显示所有已经注册了的模型目前状态,用户可以在仪表板内进行模型筛选操作定位到需要进一步操作的模型。在仪表板内点击任意模型可以导航至模型相关的验证结果页面,验证结果一般可以以扇形统计图,条形统计图,或表格的形式显示。验证结果(通常是一个指标) 背后运行的完整报告可以从系统平台上下载下来,提供.pdf、.xlsx、.html文件格式。
可选的,模型仪表板上显示的模型状态变量和验证结果的表达方式可以根据用户需求进行自定义调整。一般来说,模型仪表板会显示模型名称,模型所处的切割组,模型所属的工作环境,模型报警级别和报警规则触发数目,模型总的健康概况,模型所处工作阶段,模型离上次验证日期天数,等其他信息。
可选的,系统平台可以根据定义好的报警规则和验证结果指标,产生报警信号/事件并且反馈到模型仪表板。用户可以查看模型的单条报警或者全部报警追踪报警缘由和安排下一步工作。用户可以修改当前的报警规则,也可以添加更多的报警规则。
可选的,模型所属人员可以根据验证结果更改模型健康状态并附加评论。模型健康状态等级可以分为,健康,注意-轻微,注意-中等,注意-紧急,需要立即处理等。
可选的,每个模型的相关人员可以添加相关评论以记录对模型的观察同时可以查看模型的历史活动。
在上述实施例中,通过建立一套基于生命周期的、利用可配置化和自动化工作流的企业级管理方法和系统能够让机构的风险、分析人员在持续开发具备竞争优势的前沿模型和策略的同时,遵循设计好的工作流程,把所有模型相关的信息、产出、和重要文件都统一到一个库。通过设定角色权限,使不同人员和部门可以恰当地使用和共享库里的信息,从而在最节约人力资源的情况下,满足来自机构内部的需求。对模型开发的工作场景而言,工作流通过标准化的记录行动和决策的流程来指导用户。它通过自动获取细分标准、测试结果,以及其它关键信息来避免人工数据录入。此外,工作流还能协调跨部门的模型审核,及时通知相关人员,并确保当前子任务在获得审批通过后才进行下一步的子任务。工作流的仪表盘还可以为所有模型的进度提供一目了然的实时状态。在应对监管和内部的报告或查询需求上,工作流通过将模型生命周期过程中的所有数据汇入到一个集中的库里。在这样一个包含了所有模型相关信息的统一平台上,用户为审计做准备或为响应查询的报告编写工作会变得更快和更有效。例如,他们可以非常快速地检查某个模型最近的验证测试,也可以同样容易地细读整个过程的历史,包括对在该模型在做过的每个验证,以及每个实例中的结果和后续操作。
综上所述,基于自动化、可配置的工作流的企业级模型管理平台能够实现模型管理集中化,让工作人员快速了解每个模型的开发(开发数据/模型开发/模型验证)、部署(模型的复杂度/运行要求/运行测试)、维护(模型投产后验证 /修改/迭代)的所有历史。同时,还能够确保银行保留所有的模型相关的信息和支持相关决定的依据,从最大程度上满足来自银行内部的需求和外部监管的质询。另外,除了内置的工作流以外,该平台能够同时进行模型周期性的自动化验证,并依据模型的性能指标的变动对模型的表现作出标记。这能让银行更及时的了解模型的状态,更容易维护运行中的模型,并保证其处于高性能的表现水平。
如图2所示,在本申请的第三个实施例中,企业级模型管理架构中的角色权限管理主要用于管理不同业务团队内,不同角色在系统平台中的权限,各个角色根据各自匹配的权限可以通过仪表板查看感兴趣的数据,例如,可以通过仪表板1进行集中化管理,查看模型清单中的内容,通过仪表板2进行验证和监控,查看单个或多个模型的验证和监控结果。另外,模型清单以及单个或多个模型的验证和监控结果可以共享复用至不同的业务团队。
需要说明的是,工作流中或者说系统中的不同角色至少可以包括模型所属人、工作流作者、模型作者、模型审批人员和系统管理员。其中:
模型所属人:该模型的拥有者,新模型需求的具体发起人,模型所属人可以拥有除系统管理员之外的所有系统角色权限,可以对自己有查看权限的模型进行删除,修改,等操作。
工作流作者:工作流作者在平台系统中创建和发布模型工作流,根据模型工作任务定义工作流中的子任务把工作流中的子任务指派到负责人,工作流作者与模型所属人可以为同一个人,但一般来说,工作流作者需要对模型工作细节有一定经验且具备一定的知识基础。
模型作者:模型作者负责完成模型工作流当中的子任务,模型作者可以按照使用机构的内部岗位不同继续细分为数据分析人员、模型开发人员、模型验证人员、模型部署人员,等除了模型审批人员之外的模型工作相关人员,模型作者负责创建模型定义,配置模型元数据,相关模型变量和变量角色,开发模型,创建模型验证计划和撰写报警规则等。
模型审批员:区别于模型作者,模型审批员一般不具体负责模型工作的实际操作,模型审批员对模型工作流中的审批子任务负责,负责审批模型作者的产出和完成审批子任务。
系统管理员:系统管理员负责权限管理,配置外部数据库和每个模型对应的数据表,部署已发布的工作流,和配置自定义模型仪表板和自定义模型验证报告。
自定义角色:根据模型工作需求,机构可通过系统管理员创建自定义的角色。
在具体的实现场景中,不同角色对应的权限,完成的任务不同,例如:
模型所属人:模型所属人进入平台系统查询目前自己管理的所有模型的状态,针对某个模型的具体历史活动或者目前的模型表现状况可以进入该模型的工作环境进行查询。
工作流作者:工作流作者进入平台系统的工作流管理页面根据新的模型任务创建模型工作流,对于例如新模型开发任务,工作流作者也可以选择对应新模型开发的通用工作流,一般来说,该工作流将涵盖模型开发-模型测试-模型审批-模型部署-模型上线-模型验证等子任务环节,工作流作者在系统内,对每个子任务指派到人,定义每个子任务中需要的交付物,创建完毕后需要上传该工作流,等待系统管理部署。
模型作者:在工作流正式部署并生效之后,随着工作流推进,当前第一个子任务的模型作者会收到来自系统的任务邮件和系统连接。例如对于子任务-模型开发环节来说,模型开发人员在系统平台内拥有模型作者此角色对应的权限,根据该子任务的要求,模型开发人员完成数据清理生成数据质量报告,进行指标衍生和特征筛选工作生成特征报告,进行模型开发和测试并生成报告,统一上传到该子任务内并提交该子任务。
模型审批员:对于新模型上线前,模型需要进行测试和验证,模型审批人员查看模型开发、模型开发、模型验证阶段的报告的规范性和合理性,给予是否审批通过的批示。只有当模型审批员批准后,模型工作才能继续移动到下一个环节。
系统管理员:当工作流作者创建并上传了工作流之后,系统管理员需要部署该工作流,只有工作流部署了,工作流才会真正生效,在仪表板的显示。针对工作流中子任务指派的负责人,系统管理员赋予他们相对应的系统角色和相关权限。
本实施例中,内容管理信息库可以相当于上述实施例中的企业级别的模型资产库。内容管理信息库中模型注册的过程如下:首先不同的业务团队创建各自的模型定义;进而定义模型元数据,主要包括所属的业务线、业务场景、模型类型、输出类型、模型归属人员、样本窗口和发布日期等;然后连接模型对应数据库和数据表,再配置模型,设置验证定义。其中,所定义的模型元数据和创建的模型定义可以体现在模型清单中。在对单个或多个模型进行验证和监控时,主要是验证监控模型对应的数据库和数据表、模型的配置和配置验证的定义。
在本申请的第四个实施例中,从原理功能的角度将企业及模型管理系统划分为模型管理平台、工作流管理系统、模型验证/评估系统四个重要模块,不同模块之间在模型风险管理中的工作关系如图3所示:
关系线a:模型组件-模型作者-模型工作环境-内容管理系统
对于已存在的模型,模型作者在模型工作环境中创建模型定义,上传该模型相关的部件和相关文档,模型的部件和相关文档会被储存在模型风险管理平台的内容管理系统。
关系线b:模型作者-自定义报告-系统管理员-系统管理-仪表板
一般来说,自定义报告的模板在模型风险管理平台之外由模型作者设计好后,由系统管理员统一管理和配置到平台内,当配置完成后,模型作者可以在模型工作环境中利用该报告进行验证与监控工作,验证与监控的结果会反馈到仪表板。
关系线c;工作流作者-工作流管理-仪表板
工作流作者在工作流管理内创建和维护工作流,当工作流发布并且部署后,工作流的状态会汇总到仪表板内,除此之位,根据工作流里的工作任务和负责人,工作流会督促模型作者进入模型工作环境完成任务。
关系线d:系统管理员-系统管理/权限管理
系统管理员负责日常系统平台的管理,维护平台环境,协助工作流作者进行工作流部署,日常平台日志维护,还有管理平台的角色和角色所对应的权限。
关系线e:模型生产环境(非平台环境范围)-模型回流数据(非平台环境范围)-模型管理平台数据库(非平台环境范围)-模型验证/监控工作-验证报告和结果-内容管理系统-模型工作环境
模型在生产环境被调用产生模型回流数据,回流数据经过ETL等处理回流到模型风险管理平台外接的数据库,当模型作者在平台内进行模型验证和监控等工作,平台内的验证和监控引擎调取外接数据库里模型对应的数据,结合平台内的模型定义、变量和验证报告角色等信息,生成验证报告和结果,储存到内容管理系统,模型作者此时就可以在模型工作环境内查看到验证报告和结果。
关系线f:模型工作环境-内容管理系统-工作流管理系统(工作流引擎)
当模型作者在模型工作环境中完成相应的工作或任务,完成的工作或操作储存到内容管理系统,内容管理系统与工作流管理系统互相交流,工作流系统识别下一步行动,往前推进工作流进度,返回给内容管理系统。
在本申请的第五个实施例中,企业级模型管理系统的架构如图4所示,包括展示层、接入网关层、系统应用业务层和基础能力层。其中:
展示层:主要用于用户使用的登录和系统的前端操作界面可视化展现。
接入网关层:
1.nginx网关:实现网络隔离,API的统一管理,对外暴露公网服务,对内进行内网流量分流和转发,支持API请求协议转换,请求的负载均衡分发,提高系统的高可用和统一化安全入口管理。
2.访问鉴权:对API访问进行访问鉴权。防止非法请求操作。
系统应用业务层:
模型资产管理平台:
a)模型表单:模型登记中最基本的单元模块,由多个字段组成,代表字段的归类组合,可以根据业务自定义扩展,为工作流模型节点引用。
b)模型工作流:为模型登记过程中的载体,定义了模型生命周期管理流程环节。
c)模型登记:登记模型实例信息,存储模型登记详情,包含模型的内容、关联文件。
其中,模型表单、模型工作流、模型登记功能依赖关系如图5所示:模型表单可以根据业务场景需要自定义和可扩展,不同的表单结合工作流最终构成模型登记的整一个过程。工作流中的模型节点需引用某一个模型表单。模型工作流结合模型表单产生模型登记处理过程,模型登记的整一个处理过程中节点的变化需要调用模型工作流处理。模型登记处理过程中,会实例化模型数据,完善模型的需求信息、开发信息、验证信息等,模型登记完成,模型的实例化数据也完成。
数据报表:
a)跟模型相关的操作和运行历史记录,例如模型(pmml、pdf、excel、.pkl),数据报告(.xlsx,.doc,.pdf,.r),验证报告(.doc,.pdf,模型code)等,会分别存入文件对象系统OSS和大数据平台,定时任务job会根据业务需求,生成业务需要的BI报表,并且通过邮件等渠道发送。
b)模型运行平台根据生产真实的实时调用情况,会产生的分数等维度数据落地数据库,模型管理平台会从数据库中多维度获取数据库中变量和数据,结合动态脚本代码,生成不同维度报表,形成模型验证或监督报告。
流程引擎:
模型管理的核心功能,实现对模型生产,模型登记、模型审批等进行流程化规范化管理,他是驱动模型全生命周期管理的引擎,可以支持业务的配置化和可扩展,与业务模型工厂和模型运行平台进行环境打通衔接,支持模型自迭代。流程引擎的架构如图6所示:其中,内嵌activiti开源流平台,开发一个无状态的springboot应用,以MySQL作为状态存储层,以独立应用集群的方式部署,对外暴露统一的域名。符合BPMN标准,实现公司定制化的通用流程平台。流程节点支持触发外部HTTP接口,对外可以暴露流程相关的restful接口,业务上层可以直接调用。提供web版控制台,可视化的流程拖拽编辑页面,该编辑器支持创建或编辑activiti流程档案(activiti特有的一种流程文件格式,本质上是一个ZIP包,内包含了标准的BPMN流程定义XML文件和相关资源文件如图标等),以及流程实例查询接口(API)。校验完成后,将流程档案部署到当前的activiti引擎中。流程引擎的流程节点可调用服务包内指定的服务接口,这些接口本身需要做鉴权处理以防止非法访问,确保服务调用安全。
模型评估及模型验证/监控服务:
模型预测评估在模型资产系统中支持标准通用的模型文件的预测评估,目前设计支持pmml,py模型文件类型预测评估。整体的评估架构如图7所示:
前端页面上送模型编码、模型数据文件或者指定模型数据源到模型评估服务中。模型评估服务根据前端上送的内容,从模型资产管理服务获取模型文件、模型报告模板,并且如指向数据源方式,则从现有配置的数据源中获取数据。模型评估服务对模型文件进行解析并且运行,运行完毕后产出模型运行报告。模型评估服务发送模型运行报告到模型资产管理服务,并由模型资产管理服务下发通知到指定邮箱。模型评估服务调用大数据云平台的采集接口,下发模型运行数据到大数据云平台。
其中,数据回流服务主要提供三方模型工厂和模型运行平台的运行数据回流,支持实时同步回流和离线批量文件回流两种方式,为模型监督提供数据来源,如图8所示主要是为模型开发评估和回流效果评估提供数据来源。图8中,模型开发环境(即模型开发建模工厂)产生的建模相关数据与模型运行环境,即模型生产的实时数据运行,模型管理平台产出的一些配置数据和工作流数据,通过数据生产的方式传递到消息中间件kafka或者类似数据总线。数据回流服务:消费消息中间件或类似数据总线产生的业务数据,进行格式转换统一处理,业务指标的相关前置处理。数据流入大数据平台。大数据平台运行报表任务,进行spark和hive等定时计算,结果在模型管理平台进行可视化查看和展现。作流相关的流程审批信息以及BI报表可以实时通过三方信息通道触达用户终端。
基础能力层:
1)大数据平台:支持大数据场景的数据存储和实时spark流计算和hive 等基础存储和计算能力。
2)MySQL:支持模型表单、模型登记等基础对象字段以及流程引擎和模型流转状态等存储和业务查询等操作。
3)ELK:支持日志数据的存储,基于一些规则的操作,监控和可视化查看能力。
4)OSS:支持模型相关的文件对象存储。
5)Kafka:支持系统间数据的消息异步化流转,系统间松耦合。
业务监控:
模型运行情况,线上异常API调用或异常模型管理流程操作,进行实时脚本化计算和告警。
在本申请的第六个实施例中,为本发明实施例提供了一种模型生命周期管理系统。如图9所示,本实施例的所述模型生命周期管理系统10可以包括:工作流创建模块101、工作流处理模块102、查阅反馈模块103、更新重启模块104、注册建库模块105、仪表板监控模块106和仪表板调整模块107。其中,工作流创建模块101如图10所示,包括子任务创建单元1011、工作流部署单元1012、子任务处理单元1013和子任务推进单元1014。注册建库模块105如图11所示,包括模型定义创建单元1051、元数据定义单元1052、数据连接单元1053、报告处理单元1054、模型配置单元1055和资产库形成单元1056。
工作流创建模块101,用于基于模型生命周期定义通用版本的模型工作流。
具体实现中,工作流创建模块101可以包括以下单元:
子任务创建单元1011,用于定义工作流中的子任务。
工作流部署单元1012,用于在审核无误后,对工作流作者提交工作流进行部署,以使工作流根据预先定义的任务环节和负责人自动推进。
子任务处理单元1013,用于工作流根据当前的进度给下一个子任务对应的负责人发送提醒信息,并赋予该负责人对应的模型任务环节的相关系统权限,其中提醒信息至少包括邮件提醒和系统登陆链接中的一个或多个。
子任务推进单元1014,用于在一个子任务完成后,工作流自动推进至下一个子任务。
工作流处理模块102,用于根据不同的模型任务需求在通用模型工作流上进行模型任务处理,模型任务至少包括模型需求发起、模型开发、模型验证、模型实施和部署、模型审批、模型上线、投产后持续验证和监控子任务中的一个或多个。
查阅反馈模块103,用于在工作流生效期间,根据符合工作流查阅权限的查阅请求反馈工作流的历史活动和相关记录。
更新重启模块104,用于在工作流生效期间,若工作流需要进行修改或模型任务的添加、删减、更新时,工作流重新发布,从最近的未完成子任务处进行任务重启。
注册建库模块105,用于构建企业级别模型资产库,将所有模型及相关文档注册至同一管理平台。
具体实现中,注册建库模块105可以包括以下单元:
模型定义创建单元1051,用于创建模型定义。
元数据定义单元1052,用于定义模型元数据。
数据连接单元1053,用于连接模型对应的外部数据库和该模型的数据表单。
报告处理单元1054,用于根据数据表单选取模型使用的变量生成模型验证报告,并给上述变量赋予报告角色。
模型配置单元1055,用于配置模型,上传模型对应的模型文件,定义数据窗口和基准,定义模型预测目标并赋予该目标所属的报告角色-目标,定义分数分布和模型所属切割组。
资产库形成单元1056,用于将所有注册的模型保存至企业级别模型资产库中。
仪表板监控模块106,用于根据预先配置的模型仪表板实时监控模型资产库中各模型在生命周期内的模型工作状态和性能指标。
在可选实施例中,模型仪表板上显示所有已注册模型的当前状态,并以预设的显示形式显示针对所选模型的验证结果,显示形式包括扇形统计图、条形统计图或表格中的一个或多个。
仪表板调整模块107,用于根据用户需求调整模型仪表板上显示的模型状态或验证结果的表达方式。
需要说明的是,上述系统中各模块和单元的详细执行过程可以参见上述实施例中的描述,此处不再赘述。
在本发明实施例中,通过定位于企业级别,协助机构建立企业级的模型资产库,对运用在不同业务场景中的模型进行集中化管理,所有模型及其相关文档全部注册到同一个平台上;模型运行状态或者模型工作所处阶段根据配置好的模型仪表板能够实时了解,机构能够及时了解模型工作进程,跟进工作流里需要的人为审批等决策环节,对于已投产模型,当发生模型亏损或者异常状况时,报警规则被触发且实时反馈到模型仪表板内,用户能够早期介入进行模型调查工作;根据赋予的平台权限,用户能够在平台上轻易的找到需要的模型资产,实现模型资产在机构内部共享和复用,互相借鉴促进智能化发展;基于模型生命周期,定义一个通用版本的模型工作流,让所有的模型工作能够遵循相对一致的流程进行,工作流的每个环节指派到具体负责人,且根据环节不同,定义好需要上传的工作结果并根据需要在工作流里配置审批环节,从而在单个模型工作流里保证每个工作环节的工作质量,工作流与工作流之间,模型工作质量要求统一。
本发明实施例还提供了一种计算机存储介质,所述计算机存储介质可以存储有多条指令,所述指令适于由处理器加载并执行如上述图1-图8所示实施例的方法步骤,具体执行过程可以参见图1-图8所示实施例的具体说明,在此不进行赘述。
请参见图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还用于执行以下操作:
构建企业级别模型资产库,将所有模型及相关文档注册至同一管理平台;
根据预先配置的模型仪表板实时监控所述模型资产库中各模型在生命周期内的模型工作状态和性能指标。
在一些实施例中,处理器1001在构建企业级别模型资产库,将所有模型及相关文档注册至同一管理平台时,具体执行以下操作:
创建模型定义;
定义模型元数据;
连接模型对应的外部数据库和该模型的数据表单;
根据数据表单选取模型使用的变量生成模型验证报告,并给上述变量赋予报告角色;
配置模型,上传模型对应的模型文件,定义数据窗口和基准,定义模型预测目标并赋予该目标所属的报告角色-目标,定义分数分布和模型所属切割组;
将所有注册的模型保存至企业级别模型资产库中。
在一些实施例中,模型仪表板上显示所有已注册模型的当前状态,并以预设的显示形式显示针对所选模型的验证结果,所述显示形式包括扇形统计图、条形统计图或表格中的一个或多个。
在一些实施例中,处理器1001还用于执行以下操作:
根据用户需求调整所述模型仪表板上显示的模型状态或验证结果的表达方式。
本发明的模型生命周期管理方法基于模型管理系统实现,该模型管理系统包括如下设备:模型统一管理设备、模型开发设备、模型运行设备和模型监控设备,其中模型监控设备可以和模型统一管理设备集成为一体。以上设备可以理解为单一的计算机设备也可以为计算机集群,根据具体应用需求设置即可。
模型开发设备用于进行模型开发。模型运行设备可以理解为将由模型开发设备开发完成的模型置入业务环境中运行完成业务需求的设备。模型开发设备与模型统一管理设备通信连接,模型统一管理设备根据模型开发设备的开发需求为其配置工作流,模型开发设备基于该工作流向模型统一管理平台上传各任务的完成结果。可见,在工作流成中模型数据会直接上传至模型统一管理设备,一方面能够保证模型开发流程的规范化,一方面在上传至模型统一管理设备的模型可以允许共享和复用。
模型监控设备与模型运行设备和模型统一管理设备通信连接,通过模型统一管理设备进行监控需要配置,并根据配置的监控需求从模型运营环境设备获取包括但不限于模型生产数据的模型参数进行模型状态监控。为便于展示监控结果,模型监控设备通过仪表盘显示各个模型的参数。通常由于各个模型具有各自模型的数据协议和借口。本发明的模型的集中化管理方法中通过构建统一的管理系统,从模型的开发过程中就开始进行,直至模型的注销失效便于进行统一,另一方面,通过设定在模型监控设备配置有进行协议统一的中间件,以对数据进行格式调整以适配模型监控设备。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory, ROM)或随机存储记忆体(Random AccessMemory,RAM)等。
以上所揭露的仅为本发明较佳实施例而已,当然不能以此来限定本发明之权利范围,因此依本发明权利要求所作的等同变化,仍属本发明所涵盖的范围。