导读：近年来，人工智能、大数据等新技术快速发展，推动金融信贷业迈向智能化、数字化时代。以AI为技术支撑，构建信贷“智慧大脑”，实现了信贷业务全流程管控和授信客户评级模型优化，精准定位，降低信贷管理风险，增强了风险防控能力。本文的主题为图计算在金融信贷风控尤其是反欺诈领域的应用。主要内容包括：① 背景介绍；② 图模型落地风控的难点；③ 图计算系统架构的演变；④ 经验总结。

首先和大家介绍图计算应用的业务背景——信贷业务。

1. Akulaku的发展历程

Akulaku是东南亚市场发展最快的电商、金融科技出海平台。公司成立于2016年，2019年收购印尼银行开始集团化发展，到2020年底注册用户达3300万，GMV突破6亿美元。Akulaku通过电商、消费金融、数字银行、线上投资和保险经纪服务，帮助用户满足新兴市场中被服务不足的客户的日常金融需求。

2. 信贷相关术语解释

今天分享的“智能风控”主要是服务信贷领域的，在展开风控介绍前，先来解释下今天内容相关的信贷术语和名词。

• 授信：指给予一个用户一定的授信额度，客户有了授信额度后便可以在平台继续借款。

• 下单：指分期。用户在购买某件商品时，分多期付完全款和利息。

• 信贷业务生命周期：包括贷前、贷中、贷后三个阶段。下面讨论的内容主要是针对反欺诈这一风险的防控，对于风险来说越早发现越好，也就是平时所说的风险发现前置。

• 新客：客群中的一种，指还未有一次完整账期还款的客户。新客是新进来的客户，一般质量比较差，风险的控制主要针对这个客群。

• 老客：跟新客相对应，指已经有过一次完整账期还款的客户。是平台已有的客户，相对质量好些。 

• 数据差异：授信和下单环节的数据差异，主要体现在授信环节的客户一般是新进来的客户，表现的数据不会很丰富。两者数据的时效性要求也不一样。

风险需要尽量早的发现，即风险的发现：能在授信环节发现的风险，就不要拖到下单环节去发现。能在贷前发现的风险，不要放在贷中、贷后去发现。一般贷后进入催收阶段时，风险已经造成了损失。

3. 图模型干系人介绍

在Akulaku，图算法工程师对接的主要是反欺诈业务人员。所以干系人分两类：技术人员、业务人员。

• 技术人员：建模分析、工程实施的人员，倾向于尝试比较新的技术和挑战。

• 业务人员：风控策略和反欺诈分析人员，保证策略的稳定，通过率等指标不能有太大的波动。

两者在合作过程中，需要逐步演进模型，加深对数据的理解，建立业务对技术的信心。 

4. 图计算在金融风控业务中的应用

概括来讲，图计算在金融风控中主要有以下两方面的应用：

• 团伙挖掘：由于在信贷业务中，“团伙”有具体的业务概念和含义，所以团伙的挖掘在风险防控中具有特殊的重要作用。在做团伙分析挖掘时，需要发现团伙成员，并在此基础上构建团伙特征，更进一步构建模型自动识别团伙。

• 关联发现：包括拓扑结构的分析、异常结构的发现，进行编码和模型的构建。

图计算在风控落地的时候，有很多的现实制约因素：

• 当前业务环节能提供数据的局限性。

• 业务环节的时效性要求：一般下单环节的时效性要求高于授信环节，这很大程度上影响着对相关技术方案的选择。所选取的方案，既能满足业务环节的风控要求，又要计算速度尽可能快，在要求的时限内完成。

• 数据的时效性要求：比如我们经常要做实时的图算法，从业务动作发生到在模型端看到相应的数据，大概有多大的延时？这一般取决于数据的特性以及实时数仓整个链路的延时。

模型应用形式（输出形式），有两种：

• 输出中间结果，如团伙的成员名单、团伙的特征。

• 端到端的模型，如最终的分数等。

5. 对图计算系统的要求

信贷业务对图计算系统的要求，主要体现在以下四个方面：

① 稳定性

这里讲的稳定性，既有技术人员理解的稳定也有业务人员理解的稳定。既要求模型服务稳定、可监控、调度稳定，又要求模型打分结果稳定（psi）不能使分数结果分布有大的变动。

② 时效性

要求图计算系统能满足不同业务环节（授信、下单）的要求。比如，下单环节要求系统500ms返回计算结果。

③ 准确性

要求图模型的线上特征和线下回溯的结果完全一致。即建模整个过程中避免数据穿越，虽然数据回溯的工作量巨大，但这能保证模型结果的正确性。

④ 可控性

要求模型具有可解释性、可验证性。这就要求在特征开发的时候要做特征验证确保模型特征的结果是确定的、非随机的。

02

图模型落地风控的难点

图计算系统的落地难点与对图计算系统的要求相对应，即体现在稳定性、时效性、准确性、可控性四个方面。

稳定性方面，最大的难点是图数据库比较新且不成熟，相对于传统关系型数据库，图数据库本身的稳定性较差；时效性方面，需要满足业务环节的要求，而图数据由于局部性比较差（有图分区和工程实现的要求，比其他机器学习的应用要求更高），不容易实现快速计算；准确性方面，图数据相关的数据回溯工作很复杂，比如用户维度的某个特征回溯3天前的订单，那就是把这个客户的相关数据回溯。但如果是图的场景，需要加工一个团伙的特征，那需要回溯到团伙当时的表现，也就是需要对团伙所有成员特征进行回溯，这会更加复杂；可控性方面，图模型自适应能力很强，但可解释性比较差，在落地时要基于对业务对数据的深刻理解，逐步使用复杂模型。图模型特征开发、数据回溯、模型结果的验证，相对难度都比较大。 

03

图计算系统架构的演变

1. 第一阶段：图挖掘初始实现

① 实现方式

在该阶段，还没有成型的图计算系统。图计算的实现采用离线和实时完全分开的方式。

• 离线算法：主要实现团伙挖掘和特征挖掘，例如实现“逾期”等时效性要求不高的特征挖掘。离线挖掘会导致一些问题的发生，比如下单环节模型调用的时效性要求很高，这时就不能单独等某个团伙计算结束然后取结果的数值，一般是把团伙单独拿出挖掘其特征，得出的结果进行T+1更新，在下单环节时调用该结果。这样实现会产生时效性问题：离线数仓最快支持1天后拿到结果，这时如果想要做新客的挖掘，会导致部分数据覆盖不到。

• 实时算法：主要是实现一些明确的业务规则，比如一度关联人黑名单、二度关联人黑名单、设备或明确的拓扑结构。实现方式是实时数据源、图数据库、以及图查询的组合。实时特征刚开始一般用于授信环节，相对时效性要求低一些、但数据全面性要求较高。

② 图模型案例

• 算法用途：输入参数uid、设备、ip的记录信息，根据该记录构造出图模型，进一步发现异常结构。具体见文献[1]。

• 原算法：用户跟他关联的设备或ip是二部图，首先计算该图的联通子图，联通子图的计算方法常见的有邻居的标签传播、边带来的关联等。联通子图计算完成后，通过如下公式进行子图的编码。该算法用离线的方式很好实现，但如果对时效要求较高，需要对算法进行改进。

• 改进算法：在原算法的基础上增加实时挖掘方案，即由原来的全量逻辑改为增量逻辑。只需要考虑新进来的一条边对上述两公式（即s-source,d-destination）的影响，分以下四种情况处理：① 两个端点都不属于已有的连通子图：生成一个单独的连通子图；② 两端属于不同的连通子图：先合成新的连通子图；③ 两端属于相同的连通子图：直接更新连通子图的值；④ 一端属于已有的连通子图，一端是新的：更新连通子图的值同时新建。

• 算法存在的问题：时间窗口问题，例如该算法无法实现只查找近1天的异常特征，因为该算法下，连通子图的更新不仅只有新的边进来，还有之前的边出去，所以难实现按时间的增量，需要在现有算法的基础上增加滑动时间窗口进行改进。

③ 图计算系统架构

④ 第一阶段特点及问题

• 实时计算主要实现业务的强规则，依赖图数据库；团伙特征等复杂特征难以实现；

• 离线为主，高可控性、强解释性；

• 因为大部分是T+1的图挖掘计算，特征数据回溯相对较容易；

• 调度以脚本为主，缺乏监控，灵活性差；

• 数据覆盖度不全，无法用于授信环节；

• 图数据库的性能差，即使配置较高的机器，需要支撑较大的图（节点10亿，边100亿）运行也非常慢。

⑤ 图数据库选型

针对图数据库性能差的问题，进行图数据库的选型，对比了JanusGraph，Dgraph，Nebula三个数据库，选择了Nebula。

• JanusGraph：可以支持Hbase等后端存储系统，能存储大图，但查询经常返回不出结果，性能较差。

• Dgraph：有严谨的学术基础，但工程实现差，批量导入功能对大图完全不可用。

• Nebula：写入速度、查询响应、扩展性都不错。 

2. 第二阶段：图挖掘算法实时化

① 实现方式

第二阶段实现了图算法的实时化和平台的完善。主要是将团伙成员挖掘、特征挖掘的计算速度进行了提升，将应用的业务环节从下单前移到授信。

② 图模型案例

• 基础算法：基于模块度优化的离线算法——Louvain。 

• 改进算法：在基础算法的基础上增加了增量逻辑，对于新进来的一条边（a,b），分两种情况处理：① a所属的团伙并入b所属的团伙；② b所属的团伙并入a所属的团伙。 具体实现细节见文献[2]。

使用时注意的问题：

避免重复的边数据，但是同时要避免存储过多的状态数据。具体原则为：能不存边数据就不存边数据（只通过实时数据的binlog确定需要处理哪些边），只保存节点的状态；这样空间的复杂度尽量限制在O(N)而不是O(E).

另外注意到这个增量的团伙的原生实现是单线程的，如果我们要保证数据的吞吐量怎么办呢？实际上这个算法实现的时候是可以用多线程并发的，只需要确保更新团伙的操作的原子性即可。

我们这个增量算法是在某个初始状态（某个时间截面）之后使用，该状态之前都是离线算法，这样处理的优势在于一旦出现问题可以重启到该初始状态，效率比较高；

团伙特征（如团伙通过率、类别、占比等）的计算尝试了Flink 和PolarDB两种方式，其中Flink的一个大问题是他的状态存储不支持外部的程序对其初始化，并且时间窗口的支持不符合当时的业务要求，具体表现为flink的窗口计算要求窗口长度与步长的比值不能太大。但是我们的特征往往窗口较长，同时为了保证准确，步长不能太大。针对这个问题，我们考虑利用了关系型数据库PolarDB的挖掘能力，用PolarDB存储中间表。数据有变化时仅针对变化的数据进行计算，完全基于数据变化的事件驱动。数据的变化来源于两类：一是团伙成员变更、二是关联的业务数据发生了变化。用中间表的好处是一旦发现特征有问题可以很方便的查看、回溯数据，进一步定位问题。

③ 图计算系统架构

④ 第二阶段特点及问题

• 将团伙特征在授信环节的覆盖度由43%提高到100%。 

• 图数据库的高可用性。

• 实时化、可靠性高、可验证性强。

• 图相关特征的数据回溯验证工程量大、无端到端模型。 

3. 第三阶段：图模型端到端

① 实现方式

第三阶段（目前阶段）主要引入了图卷积，并实现了端到端模型的研发。

② 图计算系统架构

③ 第三阶段特点

• 大量基于关联的业务规则被单一模型代替，业务通过率得到了提升；

• 实时数据来自实时数仓；

• 基于业务、数据的深入了解，引入了图卷积（基于图数据库进行的在线推理）。

04

经验总结

经验总结围绕“对图计算系统的要求”展开。

1. 稳定性

重点关注数据库的选型、主备的高可用、可监控性。 

2. 时效性

基于对时效性的要求，需要实现以下内容：

• 图挖掘：实时算法。通常的思路是需要我们从增量的角度重新设计图挖掘算法。 

• 特征计算：图相关特征的异步计算。

需要注意的是，实时图挖掘算法时效性更高，但相关的工程量也更大。

3. 准确性

• 回溯时，尽量抽象特征回溯验证的模式，简化该部分工作。

• 使用了实时特征的模型上线后，要同时有一套模型建模回溯的脚本，校验线上模型调用时的特征值是否和我们回溯分析时通过离线数仓加工出来的特征值一致，这套东西同时可以用于发现实时数仓数据质量的异常波动。虽然做起来比较繁琐，但是很有用。

4. 可控性

• 从业务角度考虑，图模型需要从简单模型开始推动，随着对数据和业务理解的深入，逐步尝试更加复杂的模型。从简单的规则，到相对复杂但仍有可解释性的团伙特征，再到端到端，可解释性较差的深度模型，一步一步来，逐步加深我们对数据和业务的理解，切忌一开始贪多求快，在数据没有完全理解清楚的情况下贸然上“高大上”的模型。

• 验证工作：虽然验证工作量巨大，但验证不可缺少，对实时特征的开发来说尤其是这样。

• 在有条件的情况下，中间结果落表存储，便于我们发现问题。 

引用：

[1] Li, X. and W. Zhang. “HGsuspector : Scalable Collective Fraud Detection in Heterogeneous Graphs.” (2018).

[2] Alexandre Hollocou, Julien Maudet, Thomas Bonald, Marc Lelarge. A Streaming Algorithm for Graph Clustering. NIPS 2017 - Wokshop on Advances in Modeling and Learning Interactions from Complex Data, Dec 2017, Long Beach, United States. pp.1-12. ffhal-01639506v2

在文末分享、点赞、在看，给个3连击呗~

分享嘉宾：

活动推荐：

社群推荐：

关于我们：

🧐分享、点赞、在看，给个3连击呗！👇