知识图谱构建(入门) (3)

接下来再看一下下面的图,跟之前的区别在于我们把申请人从原有的属性中抽取出来并设置成了一个单独的实体。在这种情况下,整个业务逻辑就变得很清晰,我们很容易看出张三申请了两个贷款,而且张三拥有两个手机号,在申请其中一个贷款的时候他填写了父母的电话号。总而言之,一个好的设计很容易让人看到业务本身的逻辑。

108

接下来再看一个原则叫做效率原则(Efficiency Principle)。 效率原则让知识图谱尽量轻量化、并决定哪些数据放在知识图谱,哪些数据不需要放在知识图谱。在这里举一个简单的类比,在经典的计算机存储系统中,我们经常会谈论到内存和硬盘,内存作为高效的访问载体,作为所有程序运行的关键。这种存储上的层次结构设计源于数据的局部性 -“locality”,也就是说经常被访问到的数据集中在某一个区块上,所以这部分数据可以放到内存中来提升访问的效率。 类似的逻辑也可以应用到知识图谱的设计上:我们把常用的信息存放在知识图谱中,把那些访问频率不高,对关系分析无关紧要的信息放在传统的关系型数据库当中。 效率原则的核心在于把知识图谱设计成小而轻的存储载体。

109

比如在下面的知识图谱中,我们完全可以把一些信息比如“年龄”,“家乡”放到传统的关系型数据库当中,因为这些数据对于:a. 分析关系来说没有太多作用   b.  访问频率低,放在知识图谱上反而影响效率。

110

另外,从分析原则(Analytics Principle)的角度,我们不需要把跟关系分析无关的实体放在图谱当中;从冗余原则(Redundancy Principle)的角度,有些重复性信息、高频信息可以放到传统数据库当中。

6.4 把数据存入知识图谱

存储上我们要面临存储系统的选择,但由于我们设计的知识图谱带有属性,图数据库可以作为首选。但至于选择哪个图数据库也要看业务量以及对效率的要求。如果数据量特别庞大,则 Neo4j 很可能满足不了业务的需求,这时候不得不去选择支持准分布式的系统比如 OrientDB, JanusGraph 等,或者通过效率、冗余原则把信息存放在传统数据库中,从而减少知识图谱所承载的信息量。 通常来讲,对于 10 亿节点以下规模的图谱来说 Neo4j 已经足够了。

6.5 上层应用的开发

等我们构建好知识图谱之后,接下来就要使用它来解决具体的问题。对于风控知识图谱来说,首要任务就是挖掘关系网络中隐藏的欺诈风险。从算法的角度来讲,有两种不同的场景:一种是基于规则的;另一种是基于概率的。鉴于目前 AI 技术的现状,基于规则的方法论还是在垂直领域的应用中占据主导地位,但随着数据量的增加以及方法论的提升,基于概率的模型也将会逐步带来更大的价值。

6.5.1 基于规则的方法论

首先,我们来看几个基于规则的应用,分别是不一致性验证、基于规则的特征提取、基于模式的判断。

不一致性验证

为了判断关系网络中存在的风险,一种简单的方法就是做不一致性验证,也就是通过一些规则去找出潜在的矛盾点。这些规则是以人为的方式提前定义好的,所以在设计规则这个事情上需要一些业务的知识。比如在下面的这个图中,李明和李飞两个人都注明了同样的公司电话,但实际上从数据库中判断这俩人其实在不同的公司上班,这就是一个矛盾点。 类似的规则其实可以有很多,不在这里一一列出。

111

基于规则提取特征

我们也可以基于规则从知识图谱中提取一些特征,而且这些特征一般基于深度的搜索比如 2 度,3 度甚至更高维度。比如我们可以问一个这样的问题:“申请人二度关系里有多少个实体触碰了黑名单?”,从图中我们很容观察到二度关系中有两个实体触碰了黑名单(黑名单由红色来标记)。等这些特征被提取之后,一般可以作为风险模型的输入。在此还是想说明一点,如果特征并不涉及深度的关系,其实传统的关系型数据库则足以满足需求。

112

基于模式的判断

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwwwzg.html