环路检测在风控领域的应用实践丨Fabarta 技术专栏

导读： 本文分享了在使用图分析引擎开发风控算法时遇到的挑战，以及我们采取的方案和措施，介绍环路检测算法在风控场景的探索和工程化方案，分享算法效率优化、硬件资源限制下的算法探索的一些经验。

▌环路检测的背景与挑战

简单介绍一下环路检测的背景。在风险管理领域，环路检测是一种常用的技术，主要用于分析金融交易。当一个交易中，一笔款项经过一系列的转账操作并最终回到初始账户时，就会被认为是一个环路，可能被标记为高风险场景。这种分析技术对于需要处理大量交易并识别潜在欺诈活动的银行和其他金融机构尤其重要。

环路检测技术也存在一些挑战。首先是金融交易数据量庞大，往往涉及数十亿甚至更多的交易。其次现有的图分析引擎大多只能处理简单图，而金融交易往往是多种点边类型的复杂图结构。最后，计算和存储资源的需求因客户而异，我们需要满足资源受限的客户需求。我们在客户交付过程中，针对上述挑战，开发并优化了环路检测算法，接下来我将详细介绍我们的方法及几个案例研究。

▌分布式图计算的优化方案

首先，我们采用了分布式图计算来处理大型图网络，这是业界常用的方法。我们的 ArcNeural 多模态智能引擎的分布式计算框架借鉴了 libgrape-lite，将大规模图数据切割为子图，并通过并行计算和消息传递方式实现高效的环路检测。ArcNeural 多模态智能引擎基支持 50+算法，覆盖路径分析、中心性分析、社区发现、关联性分析、子图挖掘等场景。我们使用了公开的 benchmark LDBC 数据集进行了内部测试。常见的算法包括 BFS、弱连通图、标签传播和 pagerank。如表格所示，ArcNerual 多模态引擎在性能方面大幅优于国内开源图计算引擎。

1. 剪枝策略优化

具体来说，我们如何优化环路检测算法呢？环路检测算法需要找出给定图中所有可能构成环路的路径。如果不对算法进行优化，由于需要遍历所有可能的路径，而不仅仅是遍历每个节点，这就使得需要遍历的数据量变得非常大，算法复杂度为 O（V*（V+E+R）），其中 V 为点数目，E 为边数目，R 为环路数目。

因此，我们进行了分析，考虑如何减少需要遍历的数据量。我们参考了拓扑排序算法的思路，找到不可能构成环路的点。例如，只有出度或者只有入度的末端点肯定不能构成环路。我们采用了迭代的思路，不断去除这些点以及与之相关的其他点。例如，对于一个初始出度和入度都不为 0 的节点，如果经过一些迭代之后发现它不可能构成环路，那么就可以将其从遍历的范围中去掉。这样一来，通过去除那些只有出度或者只有入度的点，我们可以大大减少需要遍历的数据量，可以极大地提高整个环路检测算法的效率。特别是在一些场景中，如果我们只需要知道一个节点是否在某个环路中，而不需要知道具体的环路路径，那么这种算法的效率会更高。例如，如果我们要判断一个用户是否存在转账环路，我们可以直接运行这个算法，得到结果并快速定位问题。这个算法的复杂度是 O（V+E），其中 V 是节点数量，E 是边的数量，这是一个较为简单的策略。

2. 多重图的含义及优化方案

在此基础上，我们还需要考虑多重图的情况。多重图的含义是在金融交易等场景中，同一对用户 A 和 B 之间的转账可能会发生多次。我们对算法进行了一些改造，以支持处理多重图的情况，此外在真实的金融场景中，同一对节点之间可能存在成百上千条相同类型的边，这样会对遍历的性能产生很大影响。

一种优化思路是先忽略并行的节点，先找到所有的节点，等到需要进行分析的时候再展开这些并行节点。但是这种方法存在一个问题，就是我们无法获得边信息。在金融场景中，转账次数、金额、频率等信息十分重要，对于风控分析至关重要。因此，我们目前没有优先考虑实现这种方法。另外一种思路是将多重边信息编码，只遍历一次并记录多重边信息，在需要展开的时候进行处理，这是我们目前使用的一种方案。对于同一对节点之间可能存在多条相同类型的边，我们可以将这些边的信息存储一次，避免了重复遍历，这是一个比较小的优化点。

整体上，我们已经实现了从底层数据的分析、存储到整体上层的算法分析，支持多重图的处理。这样可以更好地满足金融场景中复杂的数据分析需求。

3. 有限硬件资源下的算法调整

在硬件资源有限的情况下，我们需要对算法进行调整，以优化内存的使用。

3.1 分布式图计算框架介绍

首先，简单介绍一下 PIE 图分析算法框架的思路。我们使用的是 PIE 框架，它的做法可以分为两步。第一步是初始化环节，也被称为 PEval，每个节点分别运行单机版本的图算法。第二步是增量算法环节。以多跳算法为例，从一个点出发，找到它的一度、二度、三度的邻居节点。第一步单机图算法根据输入的起点，在每个节点上进行扩展，直到扩展到某个点时发现不在当前节点上。这时，算法会将这个点信息存储下来，并通知其他节点更新状态。此后，增量算法会根据收到的消息通知，继续进行扩展，直到无新的消息产生。

具体到环路检测算法，我们也采用了类似的思路。第一步是运行 单机图算法，它是一个遍历算法。我们从每个点开始向外扩展，每扩展一次就判断是否成环，如果成环就记录输出。如果遇到外部节点，我们会发送消息通知其他节点。第二步是增量算法，我们根据收到的消息不断迭代，如果遇到外部节点，我们也会发送消息通知其他节点。因此可以将算法认为是消息驱动的迭代框架，单机图算法的消息来源是输入起点。

3.2 内存消耗分析

为了找出内存资源消耗的原因，我们需要分析算法的运行过程。首先，算法中间会有一个状态消耗，因为无论是宽搜还是深搜，遍历时都需要存储当前遍历状态，输出的结果也需要被存储，另外，我们也发现当前框架在每一步迭代时，都会先将消息存储下来，当前迭代完成后一起处理。总体来说内存消耗主要分为遍历状态、迭代间消息、结果三部分。下面分析不同的实现方法内存消耗情况：

3.2.1 单机 BFS

宽搜实现整体思想是逐层向外扩张邻居点，这可以用队列来实现。例如，我们从起点 A 开始，可以得到邻居点 B、C、D，将它们存储在队列中，然后再从队列中依次取出一个点进行遍历得到新的邻居点，这样就可以逐层向外扩散，中间状态为分层遍历得到的路径。

3.2.2 单机 DFS

然而，这种方法存在一个问题，即由于每次都是一圈一圈地向外扩散，因此中间状态需要存储很多路径，导致内存消耗很大。另一种思路是采用深搜，从树结构的角度来看，深搜从一个起点往下走，中间状态为当前深搜的路径，内存占用较小。

经过实际运行，我们发现单机情况下算法表现良好，但在分布式情况下却存在问题。具体问题在于，如果分布式节点将图数据切分的较为细碎，从起点 A 往外走时，许多可达节点都已经被截断并分配到其他节点上，当遇到断头路时，需要将断头路径作为消息保存下来，这样做会导致消息堆积量非常大，因此这种算法消息内存消耗较大。

总的来说这两种算法都存在内存消耗量很大的问题。但是与宽搜方法相比，单机的深搜方法在没有消息缓存的情况下表现更好。因此，如果数据量较小且可以在单机上运行，则可以选择单机深搜方法。但是，如果数据量太大而单机无法运行，则需要使用分布式 DFS 方法。

3.2.3 分布式 DFS

分布式 DFS 将全部节点当做单机来处理，当节点 A 遇到断头路时，记录当前深搜状态并停止遍历，在节点 B 上继续遍历，当遍历完成后，回头通知 A 继续深搜。本质上为维护一个全局的深搜遍历，从而避免中间消息存储。这样整个内存量会很小，就像单机内存一样。但是并行度会降低，因为我们没有充分利用多台计算机的性能。

当数据量小可以单机部署时，使用单机 DFS 方案，如果数据量较大需要多节点部署时，由于实际实际图切分多为哈希切分，跨节点的点和边很多，一般使用分布式 DFS 方案。理想的多节点最优方案好的图切分+单机 DFS 较难实现。

4. 实验结果

复杂度分析方面，相比于无剪枝策略的复杂度，使用剪枝策略后复杂度大大降低，包括剪枝算法复杂 O（V+E）和在剪枝后存在环的图上遍历并输出环复杂度为 O（V✖️R）。

在 10w 点，1w 边的图上进行测试，从实验结果也可以佐证我们前面的分析，单机 BFS 方案单节点和多节点内存消耗都非常大，由于客户硬件内存配置仅 32G，导致无法运行。单机 DFS 方案单节点部署和分布式 DFS 方案内存使用均较小，符合预期。最后剪枝策略的对照实验也表明使用了剪枝后，可以减少几十倍的时间消耗量，这是非常可观的。

▌ArcNeural 多模态智能引擎案例

案例方面，我们跟几个金融和经侦的客户合作，使用了我们的 ArcNeural 多模态智能引擎，我们跟进了他们后续的使用结果。其中一个案例是交易闭环，客户这个场景下会指定一批起点，并沿着环路方向进行交易，要求交易时间递增。相比于普通的环路，时序的环路在交易行为中才有意义。客户在 50 万个点中发现了大约 30 万个环路，涉及到大约 6000 个点，而这些结果都是潜在的欺诈行为，客户已经将这些结果与其他数据结合起来做进一步的分析。

另一个案例涉及经侦场景的转账回路，利用经侦的先验知识对环路第一次转账有时间限制。目前环路结果的后续使用方法主要为根据经验联合交易次数、金额和长度等人工分析和作为一部分特征进行机器学习风险预测。

▌总结与展望

今天主要为大家介绍了环路检测算法在风控场景的探索和工程化方案，分享了算法效率优化、硬件资源限制下的算法探索的一些经验，希望对大家有一些帮助。目前环路检测算法作为一种图分析算法，内部逻辑较为简单，环路结果与最终业务的直接关联还需要进一步分析和努力。此外，环路也可以认为是一种特殊的图模式匹配，ArcNerual 引擎也支持图模式匹配算法，可以通过输入子图的模式来查找各种各样的拓扑结构。

在与客户沟通的过程中，我发现基于分布式算法框架开发仍然比较复杂。整体链路的优化、开发新型工具等都是需要考虑的问题。甚至我们也在思考一个可能性：能否不使用分布式图形计算框架，而是将图引擎存储的数据直接用 AI 方式处理，以直接得到我们想要的结果。这是一个难点，但也是我们目前在思考的一个方向。另外图如何又好又快的切分也是一个难点，是上层图查询和图分析的基础，也有待持续优化。

最后，简单介绍一下我们公司 Fabarta。我们是一个 AI 基础设施公司，前面的环路检测算法是我们 ArcNerual 多模态智能引擎的能力之一。我们也在引擎基础上提供企业智能分析平台和数据治理场景的多模态数据编织平台，欢迎大家来和我们多交流。最后感谢 DataFun 给我们提供这次与大家交流的机会，谢谢。

▌问答

问题：您工作中有没有异构图的风控案例？
回答：有的，图模式匹配算法其实是支持异构图的，已经在一些智能分析场景中使用，其他的异构图的风控需求我们也在持续的挖掘和支持中。

本文作者韩纪飞，Fabarta 高级技术专家，先后就职于华为、快手，从事多模态、风控算法研究，现负责 Fabarta 图算法、图机器学习的研究与应用。