[人工智能]信贷风控三：如何搭建知识图谱，赋能信贷业务

一、如何构建知识图谱

1、搭建知识图谱需要哪些数据

搭建知识图谱的目的之一在于完全挖掘出客户间各种错综复杂的关联关系，所以原则上就需要把各种有关联可能的数据都纳入进来。另一方面，我们同样需要把客户的身份标识数据、重要属性特征也纳入进来，便于后续我们对客户关系的分析、回溯及关联变量的加工。所以我们从关联数据、重要属性两个维度展开来讲。

关联数据主要包括这几个维度：

• 手机号码类：包括客户的注册手机号、用款手机号、紧急联系人手机号、配偶手机号、亲属手机号、公司电话、家庭电话、人行报告中近期曾使用电话，以及现在变得异常敏感的通讯录手机号、通话记录手机号等等。这些号码类数据放入知识图谱中便能将客户之间的亲属关系、同单位情况、平时联系紧密度情况反映出来。这些数据放入知识图谱前就要注意号码格式的对齐和脏数据的清洗。
• 银行卡数据：现在信贷业务都会进行n要素验证，一般银行卡都是本人使用，不会出现多人共用一张银行卡的情况，那为什么还要放银行卡数据呢？这要看怎么放，我们在以往的业务中发现了以这样一个团伙欺诈案例，团伙中的几人同时在同一银行各自新办了银行卡用于贷款发放，这就导致这几人申请时的银行卡号是连号的。如果我们将银行卡末几位去掉之后再放到知识图谱里，这种异常银行卡聚集特征就能显现在图谱中了。
• 设备类数据：主要包括注册申请设备和用款设备两类，当然也可以进一步细化到申请每个环节，包括注册首页设备、人脸识别设备、提交申请页设备等等。申请人共用设备是团伙欺诈的一种典型特征，所以是防范欺诈要关注的十分重要的一个维度。
• 单位类数据：包括申请时填写单位、配偶单位、公积金缴纳单位、人行报告中近期曾任职的单位等等，单位类数据虽然包含重要的关联信息，但综合考量也可以不放，主要是这样两个原因，一是内容多为手写，格式混乱，对齐难度很大；二是申请客户在单位上聚集很多不是异常，比如客户经理到一个大企业展业，一段时间搞定十几、几十个客户也很正常。
• 位置类数据：包括申请时的GPS打点位置、用款时的打点位置、单位地址位置、家庭地址位置等等。一般我们会将各种位置转化为同一坐标系下的经纬度，并使用geohash算法将经纬度转化为地理网格后在放入图谱，一般的网格大小为百米乘以百米量级，当然也要根据数据精度和业务需要来确定。
• WIFI数据：包括申请、用款或各个环节埋点取到的WIFI信息，可以将WIFI的bssid做主键放入图谱。
• IP数据：IP数据是否可用仍需调研，一是地址可以自由配置，二是用流量和用WIFI会发生IP变动也不能说明什么，三是之前调研过一些共IP的客户案例，发现并没有实际关联。所以IP可用与否有待考量。
• 其它还包括邮箱地址数据等。

重要属性数据主要包括：

• 身份信息及主键：包括身份证号、姓名、客户申请号、用款号等等。用于我们定位、查询每个客户。
• 时间信息：非常重要！！主要包括申请时间、用款时间。后期需要对图谱及关联变量进行回溯就是要依赖这些时间信息。
• 特征偏好信息：比如年龄、性别、职业、收入、爱好等各种画像标签等等。可用于刻画整个团簇的属性特征，比如一个团簇聚集的几个人都有午夜活跃、网络游戏的特征，那是不是值得我们特别关注一下呢。
• 逾期类信息：包括逾期天数、逾期笔数、当前是否逾期等等。是我们定性聚集团簇性质的重要维度。
• 申请状态及原因：包括通过、放弃、拒绝等状态以及拒绝原因，比如欺诈拒绝、多头拒绝、信用评分拒绝等等，也是刻画团簇性质的重要维度。
• 黑、灰名单信息：包括信用黑名单、营销黑名单、欺诈黑名单等等，维度包括手机号、身份证、设备，甚至WIFI、位置都可以。后期也可以根据知识图谱发现异常团簇去更新黑名单信息。

2、如何设计知识图谱结构

2.1 隐性申请节点结构

图谱三要素包括：节点、边和属性，所以设计知识图谱结构就是确定三个问题：哪些数据做节点、设计哪些关联边、哪些数据做属性放到哪些位置上。基本可以遵循这样一个原则：会产生关联关系的基本实体做节点，发生的动作作为关联边，补充信息做属性。比如张三用133445的手机号在3月12日提交了一笔申请，李四用188888的手机在3月15日进行了申请，填写的亲属手机号为133445。问题一，节点设置：这里张三、李四、申请手机号、亲属手机号都是基本实体，可以设计为节点；问题二，边设置：使用某某手机号申请，填写亲属手机号为某某是两个动作，可以设计为边，问题三，属性设置：申请时间是补充信息，可以作为属性，属性放到哪里呢，这里建议放到申请手机号的边上面，因为如果放到客户节点上，假如这个客户多次用不同手机号申请就容易产生混淆，由此我们就可以得到下图左边这样一个简单的图谱结构。依照这样的逻辑，代入所有数据，我们就能得到基本结构如下图右边所示的知识图谱。这种结构的图谱更强调的是客户——关联节点——客户这种关联关系的简洁呈现。对于客户的各种申请动作都通过增加边关系来表达，如果客户多次申请，就会如图中所示，使得每个节点对之间的关联边变得纷繁复杂，而且条关联边上面都应该带着时间属性，以对多次申请进行区分。

2.2 显性申请节点结构

想要不把节点对之间的关联边搞得这么复杂，而且期望将客户的申请动作表现得更清楚，我们还有第二种结构设计方案，即把客户的每次申请都用一个显性的节点表示出来，这种结构可以称为显性申请节点结构。按照这种结构将上面的知识图谱重构就得到了如下图所示的结构。这种结构下，节点对的边关系就简化了很多，像是申请时间、逾期状况等属性我们就都可以附加在申请节点上面，能更清晰地看到客户两次申请之间的差异。

2.3 两种知识图谱结构的特点对比

两种图谱结构各有优势，我们通过以下两个方面对比一下他们各自的特性：
一是契合不同的业务场景。有些信贷业务模式较为简单，没有循环额度，单次授信，单次用款，授信申请、用款申请不做明显区分。这样的业务场景就更适合于隐性申请结构的构建；而有些业务模式稍微复杂一些，设置循环额度，一次授信，后续可多次申请用款，这就导致客户的申请较为复杂，要区分授信申请和用款申请，如果再加之多渠道，多产品申请，客户的申请行为的复杂度就更甚，这个时候，用显性申请节点结构来构建知识图谱就能较为清楚地表现出客户的多次申请行为；其次，有了申请节点，就可以将很多属性只归纳到申请节点上，比如申请时间，从而将边上属性大大简化，最后，申请节点可以更具体地呈现每一次申请的不同属性状态，比如每次申请的逾期状态、用款笔数等等。
二是计算关联度数复杂程度不同。对于隐性申请节点结构，从一个客户关联到另一个客户最短只需要两度，即客户——关联节点——客户；而对于显性申请节点结构，从一个客户关联到另一个客户最少需要四度，即客户——申请——关联节点——申请——客户，这就导致在做图计算的时候两种结构有所差异。比如计算一个客户直接关联客户数、间接关联客户数，在隐性申请节点结构中只需要执行3度和5度的计算；而在显性申请节点结构中，则增加到4度和8度的计算，这也会直接导致计算资源和计算时间的差异。

最后，我们以显性申请节点结构为例，把一个较为完整的图谱架构总结如下：

最后，图谱放哪些数据，如何架构也要从更高的层面考虑。放眼整个数据产品体系，图谱也仅仅是其中的一环，所以很多业务信息有没有必要都放到图谱中值得商榷，图谱设计得大而全，就会一定程度上拖累其运算和使用速度。图谱的特点和优势在于聚集关系的发现和欺诈风险的防控，其它业务问题完全可以放到其它产品体系中去解决。最终的目的也是想要让图谱和整个数据体系中的其它产品形成良性互补，而非相互冗余。

二、知识图谱的优势

知识图谱可以被看做是一种数据存储方式，如果仅从数据存储的角度来看待它，那相较于传统的数据库，它并没有带来任何新的信息，只是将原有的信息换了一种更侧重关系的方式进行存储。正是基于这样的原因，我们在启动知识图谱项目的时候，往往会被质问，搭建知识图谱的必要性在哪里，业务中究竟遇到了什么样的困境，是传统数据库无法解决而一定要用到知识图谱的呢？我们就以一个实际的业务案例，对这个问题进行一个简单阐述。

上图展示的是我们在真实信贷业务中遇到的一个可疑团伙案例。18个客户之间通过用款设备、注册电话、公司电话、亲属电话、配偶电话等关系有着错综复杂的连接，形成一个关系紧密的小团体。18个客户之中有13个客户借款后发生了逾期，整个小团体的客户逾期率达到了72.2%。业务中，及时、全面地发现这样性质异常的团簇对于降低整个信贷业务欺诈率、保障资产质量都有着重要的意义。那仅使用传统数据库，能不能及时、有效地发现并阻拦这样的团簇呢？

1、提高聚集变量计算效率

首先，仅使用传统数据库，我们可以用一种更简化的方式来发现客户异常聚集行为，即开发聚集性变量，比如同设备不同申请客户数，同手机号不同申请客户数等等。对于这样关系确定且关联深度仅为一度的聚集性变量，使用传统数据库开发难度不大，很容易实现。但如果我们想要获得更深度的关联关系，那传统数据库实现起来就有些麻烦了，比如我们以上图中的O客户为例，想要获取从O的注册手机号出发，二度关联的逾期客户数，那使用传统数据库来计算，过程就如下图所示：

首先，从客户O出发，我们需要和全量申请信息表进行六次关联匹配运算，每次分别使用申请表中的注册手机号、亲属手机号、配偶手机号、紧急联系人手机号、公司电话、直系亲属电话和客户O的注册手机号进行匹配。在完成6次全量扫描匹配后，我们才能穷尽客户O申请手机号的共用关系，才能发掘出所有在手机号关系上和O有关联的客户（在此案例中即客户G），至此，我们完成了从客户O出发的一度关联关系的挖掘，第二步，二度关系挖掘，我们需要从客户G出发，遍历所有关联关系，找到与客户G一度关联的客户，为此，我们需要用客户G的注册电话和申请表的注册、亲属、配偶、紧急联系人…电话进行关联匹配，再用G的亲属手机号和申请表的注册、亲属、配偶、紧急联系人…电话进行关联匹配，以此类推，再用客户G的配偶手机号、紧急联系人手机号、公司…电话分别进行遍历，在完成36次遍历匹配后，客户G手机关系则就穷尽完了。但还没有结束，接下来，我们还需要对客户G的注册单位、公积金单位、配偶单位、各种地址、邮箱等关系进行遍历关联匹配，然后到埋点信息表中，对客户G的注册、登录、用款等设备，WIFI、IP、GPS等关系进行遍历匹配，当这些关系都遍历完成后，我们才完全穷尽了从客户G出发的一度关联关系，也就完成了从客户O注册手机号出发的二度关联关系，至此，我们也就找到了客户A、B、C、D、E、F，然后判断这些客户中有多少是逾期客户，也就实现了“通过注册手机号二度关联的逾期客户数”这样一个变量的运算。由此，我们也就可见一斑，在进行这样二度关联关系变量运算时，使用传统数据库是多么的冗长和繁复，对计算资源和时间是多么大的浪费。如果我们搭建了知识图谱这样一种基于关系的数据存储库，计算这样的二度关联变量就会非常简单省力，简单来说，计算时如图中所示，客户O伸展出来多少关联边，在运算中就只需要进行多少次基础运算，相对传统数据库来讲，效率可谓是革命性的提升。

2、实现异常团簇的敏捷识别

诚如刑侦破案一样，当我们锁定一个嫌疑人之后，我们希望通过这个嫌疑人及关联线索，能够把其背后的整个犯罪团伙全部揪出来。同样在信贷业务中，我们也希望能够看到每一个异常申请客户背后紧密关联的群体，及整个群体的特征性质。以此案为例，如果我们希望找到和客户I相关联的整个客户群，使用传统数据库要如何实现呢？

如图中所示，首先要从客户I出发，找到与之一度关联的所有客户，这就需要如前所述将整个申请表和埋点表用所有相关关系进行遍历，才能穷尽找到（此例中的H、J、K、L、E客户），然后再对每一个一度关联的客户，同样进行所有相关关系的遍历匹配，才能发现与客户I二度关联的所有申请客户（此例中的A、B、C、D、F、G），如此循环往复下去，直到所有客户都被找到。但在传统数据库中，如何确定这样的边界条件呢？即我们怎么知道要进行几次遍历匹配才能把和I相关的客户都找出来呢？这在传统数据库中是很难确定或很难实现的。而在知识图谱数据库中，基于关系找到紧密连接的团簇是很简单的事情，不仅运算量小，实现也极为方便，一些开源平台如neo4j直接提供了完整封装的图算法来实现，发现这样一个团簇，运算时间只有秒级。

3、为关联关系的深度挖掘提供平台

• 社区发现：有时，基于所有关联关系挖掘出的团簇对我们而言有些冗余，一些我们看来关系并不紧密的连接也被连带在里面。那除了业务上自定义紧密关系外，有没有一种技术手段，通过科学计算找到真正紧密连接的团簇呢？这种技术手段就是社区发现算法，比如louvain算法、label propagation算法等等，这些算法考虑边的权重，通过循环迭代能够找到真正紧密聚集的团簇。
• 中心度：业务中往往有通过中介进行团伙欺诈的案例，在一个维度全面的知识图谱中，中介在一个欺诈团伙中的核心关联位置就很容易凸显出现，那有没有一种算法能帮我们批量地，快速地找到所有管理核心节点，以便我们发现团伙中介呢？就可以使用中心度算法来实现，比如pagerank、article rank算法等等。
• 最短路径：业务中如果我们发现两个可疑客户，想要迅速定位出这两个可疑客户间有没有关联关系，如果有多种关联方式，那其中最紧密的关系，即两个节点间的最短关联路径是什么样的？这样的需求就可以使用最短路径算法来实现。
  以上种种对客户关联关系的深度挖掘算法都需要首先基于知识图谱这样一个平台才能实现。而一旦有了这样一个知识图谱平台，这些算法都可以轻易实现，比如我们常用的开源平台neo4j就提供了整合这些图计算的算法包graph-data-science包，以上所有算法都高度封装，基本一句语句解决问题，这里放上算法包的开源网址供学习查阅：Neo4j Graph Data Science。

三、知识图谱如何应用及常见问题

1、图谱应用方式

知识图谱在信贷风控业务中的应用大体可以分为两种方式，如下图所示：

其中应用方式一对图谱的实时性要求不高，即便图谱按T+1时效更新，也不影响这种的应用方式，只是当天申请的团案客户没法防范。
应用方式二可以说是知识图谱的高阶用法，防范团案欺诈及时性高，但要求图谱要能做到实时更新和变量的实时计算和反馈。这就要求知识图谱、决策引擎、关系数据库三者之间能够实时互动，快速反馈，这对技术架构的能力要求还是不低的，很多机构对知识图谱的应用都难以达到这种程度。

2、知识图谱回溯问题

想要将图谱中计算出的团簇变量放入到贷前风控模型中进行实时决策，就要先训练一个带有图谱变量的风控模型，这就要求我们能够对图谱类变量进行回溯，即每个客户的图谱类变量应该是根据其申请时点的图谱状态计算出来的，而不是根据当前图谱状态去计算，我们举例来看：

比如3月15日，A客户和B客户通过手机号关联起来，形成一个小团簇，而D客户和E客户通过设备关联起来，形成另外一个团簇，两个团簇之间并没有任何关联。此时，如果我们要计算客户A在申请时刻所在团簇的客户数，我们只需要以客户A为起点，执行社区发现算法，找到所有与A关联的客户，再剔除这些关联客户中申请时间在A之后的客户即可，这时候很容易计算出A在申请时刻所在团簇的客户数为1（不含自身）。
但当到了3月16号，另外一个新申请客户C的出现将之前两个不相关的团簇联系起来了，让A、B、C、D、E客户聚集成了一个大团簇。此时，我们再想要回溯客户A在申请时刻所在团簇的客户数，那简单应用上述方法就有问题了：首先从A出发执行社区发现算法找打所有关联客户B、C、D、E，再剔除申请时间在A之后的客户C，得到变量值变为了3。明显这个方法得到的变量值3是错误的，因为在A申请时，他和客户D、E之间还没有联系。所以想要精准回溯客户A申请时刻的图谱状态及变量值，理论上需要从客户A出发，逐层扫描，扫描到申请时间在A之前客户，才继续向下一层扫描，扫描到申请时间在A之后的客户则需要切断该客户往外延伸的所有支路，依此方法穷尽找到所有关联节点，才能保证回溯的准确性，但这在技术实现上就要难一些。
另外一个难点是逾期状态的回溯，假如我们想要计算客户C申请时“所在团簇逾期30+人数占比”这样的变量，就需要对客户A、B、D、E在客户C申请前一天的逾期状态进行回滚，然后判断是否逾期30+。当然，如果我们有每个用款客户每日的逾期状态切片数据，那这个问题就可以解决，就是稍微麻烦些。

3、知识图谱防范团伙欺诈的及时性问题

虽然说知识图谱是防范团伙欺诈的一个利器，但也做不到将团伙欺诈消灭在摇篮里。比如假设我们分析找到一个非常有效的规则策略：团簇在5小时内成长到4人以上，则欺诈的概率超过50%，即便我们在风控中实时应用了这条策略，也不能将欺诈团伙中的前3个来申请的人防控下来，因为前3个客户来申请时还不足以触发这条策略。所以，知识图谱也具有普遍的局限性，需要和其它数字化风控产品相配合，形成一个完整、良性的风控闭环，才能尽量将风控反欺诈做到尽善尽美。