一种金融知识图谱弹性框架构建方法与流程

1.本发明涉及金融领域，尤其涉及一种金融知识图谱弹性框架构建方法。


背景技术：

2.知识图谱的资源信息往往需要引导客户参照本体层框架进行构建，但是目前市面上的实现知识图谱的构建技术的应用产品或者主流的技术都没有实现本体层的灵活设计、灵活维护与灵活查询展示，无法快速适应知识来源的变化与场景端的敏捷需求，甚至每一次的本体迭代可能都要重新进行页面端的开发，生产效率极低。
3.在知识存储层面上，传统意义上的图谱存储适合做多关联的实体存储，能够很好地去描述事务的最终状态。而对于事务的中间态描述有所缺失，比如事务的历史版本。目前的主流技术很难有效地在一个整体的知识图谱体系内对某一具体的领域进行细分子图管理维护，更缺乏对细分领域子图的版本控制、权限控制以及外部关联控制，导致无法保证对知识图谱适中的维护粒度,进而导致在业务场景端中很难保证知识图谱数据迭代的有效性、可靠性以及可溯源性。
4.目前现有技术方案中，隐含关系发现普遍是通过在获取知识内容时进行文本描述匹配的方式实现的，普遍缺乏隐含关系推断的回溯补充，这种先期一次性地推断方式极其容易造成隐含关系的遗漏，并且限制了可发现隐含关系的深度。


技术实现要素：

5.鉴于上述问题，提出了本发明以便提供克服上述问题或者至少部分地解决上述问题的一种金融知识图谱弹性框架构建方法。
6.根据本发明的一个方面，提供了一种金融知识图谱弹性框架构建方法，所述构建方法包括：
7.健全知识图谱的本体架构，采用自顶向下的构建方式为所述知识图谱构建本体层框架，获得知识图谱的整体设计框架；
8.根据知识图谱的整体设计框架，维护与抽取图谱数据；
9.对所述图谱数据进行分仓设计与存储。
10.可选的，所述健全知识图谱的本体架构，采用自顶向下的构建方式为所述知识图谱构建本体层框架，获得知识图谱的整体设计框架具体包括：
11.获取实体属性，每个所述实体具有多个特性；
12.获取不同所述实体间存在的不同的关系，关系的内容包括关系名称、方向、条件、关系属性；
13.根据实体间存在的关系建立知识图谱的整体设计框架图。
14.可选的，所述根据知识图谱的整体设计框架，维护与抽取图谱数据具体包括：
15.页面端动态加载本体层；
16.根据所述本体层进行大规模数据导入。
17.可选的，所述页面端动态加载本体层具体包括：
18.根据页面入口请求标识查询本体层数据库，获取根实体分仓内全部本体实体类型与属性；
19.根据页面入口请求标识查询本体层数据库，获取根实体分仓内全部关系类型与属性，返回本体查询结果；
20.根据本体层的查询结果获得实体属性构建页面，实体属性中包含了该属性在页面中展现的页面控件、页面触发事件、默认赋值方式、输入检查以及实体列表展示时的展示效果；
21.根据实体属性拼接页面组件生成页面文件，基于本体层的关系查询结果，进行页面层级的编排，每个实体都拥有独立页面，关联实体之间通过列表展示上的关联实体之间通过列表展示上的crud操作进行串联，上级实体会有下级实体的列表展示页面，通过下级实体的列表上的新增、查询、编辑等按钮进入下级实体自身的展示维护页面，当然这个过程需要进行权限的检查，如果是创建一个新的图谱数据，则页面渲染完成；
22.根据页面请求的图数据实体i d查询图谱实体数据，填充对应实体的页面数据项；
23.对于部分关系上存在属性的情况，也会根据页面请求的图数据实体id查询图谱关系数据，填充对应关系的页面数据项；
24.完成页面的加载。
25.可选的，所述根据所述本体层进行大规模数据导入具体包括：
26.在获取到大规模数据之后先进行数据抽取，获取到对应实体要素，识别实体类型，获取根实体分仓内全部本体实体类型与属性；
27.根据前一步识别到的根实体类型，获取根实体分仓内全部关系类型与属性；返回本体查询结果；
28.进行本体层匹配，将本体层模板与抽取的数据进行匹配，通过依赖nlp技术包括，采用word2voc进行语义相似度判断、cnn卷积神经网络识别语义模式以及其他句法构成分析算法等实现模型维度训练匹配，基于指定标记模板的方式进行本体层匹配；
29.基于匹配结果调用分仓的操作服务，实现分仓图谱数据的批量操作。
30.可选的，所述对所述图谱数据进行分仓设计与存储具体包括：
31.关系型数据存储包括存储字典数据、关联性元数据、配置类基础数据、本体信息和约束；
32.图数据，存储全部图谱下的所有实体节点信息和关系信息，实体节点与关系的全部属性信息以键值对的形式保存在图数据中；
33.分仓与全图的设计，从页面中进行数据采集后，基于本体层进行分仓的构建，每个分仓都是基于实际业务数据进行根实体实例化，同时构建根实体周边的关联关系和实体节点。
34.本发明提供的一种金融知识图谱弹性框架构建方法，具体包括：健全知识图谱的本体架构，采用自顶向下的构建方式为所述知识图谱构建本体层框架，获得知识图谱的整体设计框架；根据知识图谱的整体设计框架，维护与抽取图谱数据；对所述图谱数据进行分仓设计与存储。提供了一套灵活设计，实时生效的本体层的构建方案，用户可以在页面端直接维护本体层模板，能够实现快速的知识抽取、知识融合以及知识存储。弹性构建知识图谱
节点与关系详情的展示页面，对于数据业务端的需求，能够快速响应。
35.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
36.为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
37.图1为本发明实施例提供的e
‑
r
‑
e关系模型图；
38.图2为本发明实施例提供的本体层框架的示意图；
39.图3为本发明实施例提供的mvc层次介绍示意图；
40.图4为本发明实施例提供的web页面采用的动态加载方案流程示意图；
41.图5为本发明实施例提供的对于大规模数据导入场景的流程图；
42.图6为本发明实施例提供的。
具体实施方式
43.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
44.本发明的说明书实施例和权利要求书及附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。
45.下面结合附图和实施例，对本发明的技术方案做进一步的详细描述。
46.本体层框架设计如图1所示，本体是对概念进行建模的规范，是描述客观世界的抽象模型，以形式化方式对概念及其之间的联系给出明确定义.本体是同一领域内的不同主体之间进行交流的语义基础。本体是树状结构，这种单纯的关系有助于知识推理，但却不利于表达概念的多样性。在知识图谱中，本体位于模式层，用于描述概念层次体系是知识库中知识的概念模板。在知识图谱构建之初，应优先健全知识图谱的本体架构，采用自顶向下的构建方式为图谱搭建骨架,在前期的工作中需要对一些基础的本体类的核心实体进行识别和关系的确定，该过程是一个重要的框架设计，是后期知识图谱建设范围和方向的指导，所以需要专家组对核心实体进行人工识别和定义。而本体层具体产物就是实体关系三元组(e
‑
r
‑
e)关系图谱。
47.实体属性和关系属性则描述了每个实体和关系的个性特征，使整个模型成为现实世界中金融行业的映射。
48.实体指的是具有可区别性且独立存在的某种事物。如某一个人、某一个城市、某一种植物、某一种商品。实体是知识图谱中的最基本元素，不同的实体间存在不同的关系。进一步通过一系列的属性描述这个实体，用以描述实体间的差别。
49.实体属性指用来描述实体特征的指向，每一个实体都具有多个特性，每一个特性称为属性。一个实体的实例是由属性指向它的属性值而形成，例如“客户姓名”是“客户”的一个属性，而这个属性指向”张三“这个明确的属性值，其数据类型可以是整数型、日期型、字符串型。
50.数据对象彼此之间相互连接的方式称为关系，也称为联系。实体关系是为展现孤立的实体节点之间复杂而多样的拓扑结构而构建的网络。
51.实体识别完成后，则可以进一步建立实体间关系，关系的内容包括：关系名称、方向、条件、关系属性等。通过对不同实体的识别和划分，从而明确实体间的关系类型，建立对应的实体间关系。各类实体间关系定义见附录1，其中“派生”关系是参考面向对象设计理论中“继承”机制而设计，即新的子实体从已有的父实体中“派生”而来，进一步明确了实体的范围，展现的是实体间纯粹的层次关系。而其他实体类之间的关系则是在表现现实世界中实体间建立的网络联系，如“客户”“持有”“凭证”办理业务，其中“客户”和“凭证”则是这条关系中两端的节点，而“持有”则是这条关系的类型。
52.关系属性指用来描述实体间关系的特征。不同的关系之间存在一定程度上共性特征和个性特征，然而对于建立在不同实体之间相同的关系也存在着个性特征。如果说当实体拥有了明确存在着的实例时，实体属性才存在明确的值；那么对于关系而言，实体间关系一旦建立就是建立了这个关系的一个实例，那么相应的，这个关系实例的属性也有了明确的值。
53.所以本体层作为知识图谱构建的核心框架，会预先设计好每一个事实要素的逻辑实体模板和关联关系模板，形成基础的e
‑
r
‑
e关系模型，如：
54.(应用系统)
‑
【调用】
→
(接口)
55.表示：在一个架构体系中，一个“应用系统”可以“调用”某一个“接口”，“调用”就是应用系统与接口之间的关联关系：
56.同时，可以通过描述逻辑实体的具体属性在设计时突出每个本体对象实例的特征，如
57.(应用系统{name：名称；id：标识；})
58.表示，“应用系统”应该具备“名称”、“标识”等属性，类似的关系内部也可以存储属性，用来表示关系的特异性，如
59.【调用{unique：唯一性；connect：方式；}】，
60.表示“调用”关系可能会存在“是否唯一”和“通讯方式”等属性
61.最终，通过本体层设计中将会包含全部领域知识的事实以逻辑实体的形式进行管理，而它们通过关联关系进行串联，通过相关属性进行细节描述。所以图谱构建的实施之初必须进行本体层构建工作，产物为本体层实体清单和关系清单，相关内容存储在关系型数据库中，涉及表：实体表、实体属性表、关系表、关系属性表。
62.实体表的主要内容包括：
63.实体分层，用于描述实体间的层次关系，也是后续存储子图分仓的边界；
64.实体类型名称，用于定义实体的标准名称，需要具有唯一性；
65.实体说明，以进行实体的匹配和对齐；
66.唯一根节点则用来表示该实体是否为一个子图分仓的根节点；
67.此外还包括方便实体存储的实体id生成方式等字段标志以及用来进行展示控制的实体icon图标、展示位置等信息。
68.表1实体表
[0069][0070]
实体属性表主要是用来描述某一实体具体的属性信息，包括每一个实体定义的具体的属性名、属性类型等，具体内容包括：
[0071]
属性名，一个属性的唯一命名；
[0072]
值备注，属性的值来源与值描述，不同类型的属性的属性值表述会有所不同，如：
枚举值型属性，可以直接定义枚举值选项如下表中的属性“接口性质”的枚举值【金融；非金融；查询】，或从数据库表中获取枚举值选项，如下表中的属性“业务能力标签”的枚举值选项来源自静态表“业务能力列表”；表单型属性的属性值则是表单的表头，如下表中属性“接口入参n”的表头为【属性名|中文名称|数据类型|数据格式|节点类型|节点位置|是否必输|备注】，当然同时该表还会同时关联静态表单{关联静态表：元数据字典}。
[0073]
属性类型，表示属性的输入或展示方式；
[0074]
属性分组，是属性的归属分类；
[0075]
唯一性类型，表述该属性是否唯一；
[0076]
表单输入限制，表示该属性在表单中如何进行控制，包括输入，是否必输，是否可编辑以及大小驼峰、数字等输入检查；
[0077]
关联表单查询赋值，表示该属性需要触发的默认赋值查询事件，以及该属性需要查询的表单以及赋值方向；
[0078]
列表单性质，表示该属性在实体列表查询展示时的展示效果，包括是否在列表显示，是否可以作为检索条件等
[0079]
表2实体属性表
[0080]
[0081]
[0082]
[0083]
[0084]
[0085]
[0086][0087]
关系表示实体间的关联关系，具体内容包括：
[0088]
出发左实体，表示关系的出发实体类型；
[0089]
关系名称，关系的命名，但是关系的命名并不是唯一的制定两个实体间才能包含唯一的关系类型；
[0090]
关系右实体，表示关系的结束节点，也就是关系指向的节点；
[0091]
关系说明，对关系的描述，用于关系的文本匹配；
[0092]
正关关系比例，表示从左到右的实体数量比例，是1:1,1:n,n:n,或n:1；
[0093]
正向关系必要性，在左节点存在时是否必须要存在相关关系；
[0094]
反向关系比例，表示从右到左的实体数量比例，是1:1,1:n,n:n,或n:1；
[0095]
反向关系必要性，在右节点存在时是否必须要存在相关关系；
[0096]
内涵关系推导，表示该关系是一个隐含关系，需要从其他关联关系中进行推导计算得到，如下表中的(应用1)
‑
【依赖】
‑
>(应用2)，由(应用1)
‑
【提供】
‑
>(接口)和(应用2)
‑
【调用】
‑
>(接口)两条关系推导出来的；内涵关系可能还是多层推导关系推导得出的；
[0097]
表3关系表
[0098]
[0099][0100]
关系属性表表示对关系的描述，包括每一个关系定义的具体的属性名、属性类型等，具体内容和表示方法与实体属性表相同，介绍从略；
[0101]
表4关系属性表
[0102][0103]
最终通过本体层的设计，形成知识图谱的整体设计框架，设计框架如图2所示，是后续知识抽取、融合和存储的核心方案。
[0104]
为了灵活、快捷、高效地维护知识图谱，本技术提供了一个可以通过维护本体层设计实现图谱数据的快速维护与抽取，快速应对数据源的变化和场景端的需求。实现方法如下：
[0105]
如图3所示，在架构层面上，为了便于理解，本例以常见的mvc层次进行介绍：
[0106]
存储层包括一部分在图数据库中保存的图数据，包括分仓子图与架构全图数据，另一部分是在关系型数据库中保存的本体层数据。
[0107]
服务层中图谱服务(graphservcie)封装了对图谱全部操作，包括对分仓节点的操作、分仓关系的操作、分仓查询、分仓子图提交以及分仓全图查询等，而架构服务(archservice)则封装了对本体层的操作和控制，具体包括实体节点类型和属性查询，关系的类型与属性查询以及本体层维护。在本例中两个服务基于springcloud框架独立部署，彼此之间通过rpc方法调用，但是该方案不是本技术必须依赖的实现方案。
[0108]
在展现层上，无论是通过人工图谱数据录入还是批量的数据源导入，过程都优先查询本体层设计模板，基于本体层设计模板生成维护展示页面或数据抽取识别规则，然后基于本体层模板生成图谱的三元组，并生成对应的图数据存储语句进行后端图数据的存储落地。另外，本技术对于本体层本身也会开放维护页面以供用户对本体层进行管理和设计，该页面通过请求架构服务进行本体层维护并且实时生效。
[0109]
如图4所示，页面端动态加载本体层，在用户场景端进行图谱的维护，web页面采用的动态加载方案流程如下：
[0110]
基于页面入口请求标识(根实体类型)查询本体层数据库，获取根实体分仓内全部本体实体类型与属性；
[0111]
基于页面入口请求标识(根实体类型)查询本体层数据库，获取根实体分仓内全部关系类型与属性；返回本体查询结果；
[0112]
基于本体层的查询得到实体属性构建页面，实体属性中包含了该属性在页面中展现的页面控件、页面触发事件、默认赋值方式、输入检查以及实体列表展示时的展示效果，基于上述信息拼接页面组件生成页面文件；
[0113]
基于本体层的关系查询结果，进行页面层级的编排，一般来说每个实体都拥有独立页面，关联实体之间通过列表展示上的crud操作进行串联，即上级实体会有下级实体的列表展示页面，通过下级实体的列表上的新增、查询、编辑等按钮进入下级实体自身的展示维护页面，当然这个过程需要进行权限的检查，如果是创建一个新的图谱数据，则页面渲染完成；
[0114]
根据页面请求的图数据实体id查询图谱实体数据，填充对应实体的页面数据项；
[0115]
对于部分关系上存在属性的情况，也会根据页面请求的图数据实体id查询图谱关系数据，填充对应关系的页面数据项；最终完成页面的加载；
[0116]
相应的当用户在页面端完成实体创建、关系创建、实体维护、关系维护等图数据操作之后调用图谱服务中相关分仓操作，而分仓的相关操作也会基于页面提交数据进行本体层匹配，进而生成相应图数据库操作语句，将对应的三元组数据存入图数据库中。
[0117]
如图5所示，对于基于大规模数据导入场景，具体流程如下：
[0118]
在获取到大规模数据之后先进行数据抽取，获取到对应实体要素，识别实体类型，获取根实体分仓内全部本体实体类型与属性；
[0119]
根据前一步识别到的根实体类型，获取根实体分仓内全部关系类型与属性；返回本体查询结果；
[0120]
进行本体层匹配，即将本体层模板与抽取的数据进行匹配，可通过依赖nlp技术包括，采用word2voc进行语义相似度判断、cnn卷积神经网络识别语义模式以及其他句法构成分析算法等实现模型维度训练匹配，同时，也可以基于指定标记模板的方式进行本体层匹配；
[0121]
基于匹配结果调用分仓的操作服务，实现分仓图谱数据的批量操作。
[0122]
存储设计上，整体存储主要包含两个部分，一部分是关系型数据存储，主要存储字典数据、关联性元数据(例如：接口的具体输入参数描述等信息)、以及配置类基础数据(例如：技术产品清单)、本体信息及约束，本例采用mysql作为落地方案，其他关系型数据库也可以实现相关能力；另一部分就是图数据，存储全部图谱下的所有实体节点信息和关系信息，同时实体节点与关系的全部属性信息以键值对的形式保存在图数据中，本例采用neo4j作为落地实现的图数据库选型，其他图数据库也可以实现相关能力。
[0123]
分仓与全图设计，第一，分仓与全图的关系，分仓是由本体设计产生的，本体层设计中实体分层就是每一个分仓的对象。在从页面或导入的数据中进行数据采集之后就会基于本体层进行分仓的构建，每个分仓都基于实际业务数据进行根实体实例化，同时构建这个根实体周边的关联关系和实体节点，而这个构建过程也是通过获取本体层模型进行的；另外分仓之间也会存在关联关系，这就需要分仓获取全图中的节点信息进行拷贝，复制到
分仓本地，并在本地建立外部关联。
[0124]
当每个分仓构建完成之后就会将分仓信息汇总到总图上，总图则会基于这些分仓进行跨分层的实体与关系整合；当每个分仓发生数据变更的时候，分仓会进行版本复刻保留一个历史版本的分仓，同时将新版本的分仓提交全图；而当需要对图数据进行部分回退时，也会将全图数据按照分仓进行全图数据分割，并进行回退。
[0125]
在此过程中产生了：分仓子图、架构全图、分仓历史、分仓拷贝这四种图谱的数据状态。
[0126]
分仓子图状态:用于存储当前用户正在编辑或外部来源正在控制的版本；
[0127]
分仓拷贝状态:用来存储跨分仓关联时从架构全图拷贝的实体节点状态；
[0128]
分仓历史状态：每个分仓进行提交时都会产生一个分仓的历史版本；
[0129]
架构全图状态:图谱的最终状态，也就是最终图谱整合的产物。
[0130]
分仓维护与提交全图过程中，分仓处于三种状态中转移，分别是未提交、待提交和已提交。
[0131]
在每次提交之前都会进行分仓锁定，以保证数据一致性和可靠性所以分仓的维护与提交流程如下：
[0132]
(1)分仓状态探测
[0133]
用户在页面端或数据源端导入或维护数据之后提交数据，图数据加载器会优先进入分成拦截切面判断当前分仓的锁定状态，如果当前分仓已锁定，则禁止分仓提交；如果当前分仓未锁定，则进入分仓操作，同时在拦截切面锁定分仓状态。
[0134]
(2)分仓提交状态检查与正式提交
[0135]
在分仓维护完成之后，如果用户希望将分仓数据发布全图，进入分仓提交流程，首先会进入分仓拦截切面，判断分仓是否为待提交状态，如果不是待提交状态则会返回页面进行拒绝操作，如果处于待提交状态，则会进入异步分仓请求，优先锁定分仓。然后进入分仓数据维护阶段：
[0136]
先获取待提交分仓数据以及待提交分仓在架构全图的架构全图的数据；
[0137]
然后进行分仓全量比对，判断哪些实体节点或关系需要新增、删除以及更新；
[0138]
然后创建新的分仓历史版本；
[0139]
进行隐含关系推断，提交合并架构全图；
[0140]
在完成分仓数据维护之后解锁分仓。
[0141]
图谱的隐含关系推断采用规则配置+递归检查的方式。在本体层的关系表中配置关系的推断规则，以及触发条件，项目启动时加载到内存，生成推断上下文。在上文提到分仓维护提交过程中过滤提交架构全图的关系，根据已经加载的推断规则反射生成推断结果；并递归此过程。累计收集推断结果，并把推断结果添加到提交结果中去。如图6所示：
[0142]
其中一个应用所包含服务组件对外发布一个接口，则这个应用在提交分仓时，触发推断规则，推断出隐含关系(应用)
‑
【提供方】
‑
>(接口)。而另一个应用所包含服务组件恰好远程调用这个接口，则这个应用在提交分仓时，触发推断规则，推断出隐含关系(应用)
‑
【消费方】
‑
>(接口)，而由于这个关系创建，在递归的推断关系检查中又触发新的推断规则，从而构建这个应用依赖前一个应用的关系(应用)
‑
【依赖】
‑
>(应用)，通过这种中不断递归的过程不断发掘层次更深的隐含关系，直到没有新的关系被创建出来为止。
[0143]
有益效果：
[0144]
本技术提供了一套灵活设计、实时生效的本体层构建方案，用户可以在页面端直接维护本体层模板，对于新领域的知识，实现快速的知识抽取、知识融合以及知识存储。弹性构建知识图谱节点与关系详情的展示页面，对于数据业务端的需求，快速响应，零代码开发。
[0145]
传统意义上的图数据存储适合做多关联的实体存储，能够很好的去描述事务的最终状态，从而产生结果。而对于事务的中间态描述有所缺失，比如事务的历史版本。基于此考虑，在本技术中提出对知识图谱的存储参考本体层进行逻辑划分。把维护态和最终态分别开来，实现子图分仓分割管理，并且提供历史可追溯，同时很好地实现了子图数据回退，保证了图数据的可靠性。
[0146]
本技术提供图谱隐含关系推断采用规则配置+递归检查的方式。在本体层的关系表中配置关系的推断规则，以及触发条件。在分仓维护提交过程中过滤提交架构全图的关系，根据已经加载的推断规则反射生成推断结果；并递归此过程。累计收集推断结果，通过这种不断递归的过程不断发掘层次更深的隐含关系，使得关系推断发现更加全面。
[0147]
以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。