图算法在风控场景的应用

　　导读：本文将分享图算法在风控中的应用。
　　今天的介绍会围绕下面四点展开：图算法和风控简介图算法在风控的演化相应平台的心得展望未来
　　分享嘉宾汪浩然互联网行业资深风控和图计算专家
　　编辑整理戴杰永辉超市
　　出品社区DataFun
　　01hr图算法和风控简介
　　1。什么是图算法图论算法
　　图算法最早来源于图论和组合优化相关算法，在风控里面应用比较多的基本上都是传统的图算法或比较偏数学理论的算法，如最短路径发现，不同的账号和交易之间存在异常的最短路径，某些账号或设备存在异常的关联。另外，还有图的识别，比如洗钱，会涉及到异常的环路。
　　早期图在风控的应用都是基于明确的数学结构定义，如果大家仔细研究这些算法，会发现有的算法是多项式时间可以解决的，有些是多项式时间无法解决的，比如NPhard问题。在团或圈的发现算法中，其实会用到一些近似算法。而且风控中有意思的一点是数学上定义得越严格，黑产绕过就越容易。比如黑产知道你的目的是发现团，他会故意某几个设备少一两条边，那数学严格的定义就很容易被绕过。
　　2。什么是图算法图机器学习
　　早期业内是直接应用这套传统图算法到风控中，随着技术的发展，图机器学习也开始应用在风控中。比如早期本人在交易场景中落地了一个标签传播算法，它是一个Transudative推演式的算法（非归纳式）。
　　在现实应用中，很多时候我们没有办法对黑白灰样本去做完全精确的定位。那该如何利用类似社交网络的同质性（好人和好人关系近，坏人和坏人关系近）做团伙识别？在风控场景，很容易通过强规则产出高准确率的样本，但覆盖率很低（低召回），那么如何扩充这些样本呢？
　　此时标签传播算法和半监督技术就开始在风控中使用。图神经网络的半监督学习，其学习能力和鲁棒性高于传统图算法。有别于传统的图算法的自定义Aggregate和MessagePassing，随着图神经网络的发展，也越来越多的应用到风控场景。
　　3。什么是图算法图挖掘算法
　　风控场景中使用到很多图挖掘算法，如：高密度子图，一些异常账号和异常行为对象之间会存在高密度子图。邻居域异常，异常节点、边、网络存在异常的形状（如星形散射状），即该账户的邻居域异常。复杂网络，比如异常网络的度分布和正常网络的度分布是不同的。如有时挖掘了一些团伙，可以基于DegreeSequence构建特征和模型。不同DegreeSequence分布的网络存在不同的特性，这可以指导我们进一步构建拓扑相关特征。
　　4。什么是风控
　　上图中的台词很好地概括了风控的工作，人活一世，有的人成了面子，有的人成了里子，都是时势使然。从事金融风控、交易风控，风控规则和算法是公司的核心竞争力，都需要保密。有很多精彩的算法及落地不方便出来交流，可能很少有人知道，但这都成了里子。风控同学也是甘于寂寞，不断地去进行各种对抗，同时也在钻研技术和业务。
　　5。互联网风控干什么
　　众所周知的羊毛党薅羊毛、账户被盗、盗卡、现金贷、以贷养贷、猫池、恶意退货、物流空包、各种各样的诈骗、杀猪盘等等，这些场景都属于互联网风控范畴。
　　6。图算法和风控的相遇
　　为什么图算法和风控会相遇？黑产作案存在团伙性，一个人不可能靠一个账户就去作案，更多的时候需要多人多账户的协同。
　　团伙特性就会使黑产之间产生关联，这就引入了图算法。作案有相似性，但案件和作案人之间可能没有物理和空间关联，但在某些角度他们存在相似性（如行为）。风控也可以通过除了直接的关系外的点和点之间的相似性构造边。因为作案有相似性，这也是网络可以存在的一个条件。
　　还有一个原因是作案需要大量的账号和设备资源的配合，利益的驱动就会让黑产做更多的事情。作案需要成本，如手机、账号等。物以类聚，人以群分（同质性）。
　　以上这些就是图算法和风控相遇的原因。
　　02hr图算法在风控的演化
　　1。几个核心趋势
　　早年间风控尤其是风控策略，更多的是一个RuleWriter。通过业务理解写规则，慢慢演化成算法模型。还有从经典一阶的Velocity变量变成了NeutralNetAggregator（后面会细讲）。传统的风控算法或规则只能看到相邻点的特征，现在可以通过神经网络计算Aggregator。这也是从数学严格定义的网络结构到图神经网络、StrictDefinition到概率化的推断的演进过程。
　　本人曾请教过图灵奖得主JohnHopcroft，他在图的匹配还有自动机方面做了很多工作。当时问他，传统的图算法的研究对现在的人工智能有没有什么帮助？首先他觉得是没有的（可能是谦虚），他谈到一个非常大的趋势，过去大部分都是严格数学的定义，以后会更偏向概率推断。这个趋势也很契合风控，数学上定义得越严格，越容易被黑产攻克。使用机器学习、图神经网络去进行学习，最终就是变成了一个概率的推断。
　　2。经典一阶的Velocity变量
　　传统的一阶Velocity能看到一个IP周围有很多的Device。要评估该IP的风险，可以观察其相邻的Device的风险特征，如最近几天的交易登陆统计，最近7天的交易笔数，一小时内同IP的交易用户数等，这些都属于一阶Velocity。
　　以前风控从业者相当于人工构建了图神经网络的Aggregate函数（Min、Max、Mean）。
　　Min函数，比如该IP周围Device注册的最小时间，如设备注册最小时间都是最近的，即新设备，那么该IP存在很大的风险。
　　Max函数，如设备上的最大的账户数，多人共用单个设备也是异常。
　　Mean函数，如周围的设备平均的交易数。之前风控从业者通过手工去设计这个一阶的Aggregate，通过图算法能从一阶到两阶。
　　3。神经网络的聚合
　　引入了神经网络以后，把一阶或者二阶的Velocity通过神经网络学习。让算法去学坏人的Pattern而不是手工地去归纳，增加了绕过成本和模型的鲁棒性。单纯的一阶的阈值很容易被黑产试出来，通过鲁棒性的MLP去预测，有明显的效果提升。
　　4。Aggregator算子的突破
　　Aggregator算子最核心的算法上的突破就是Deepmind实现的。它用了代数拓扑的概念，如一个节点的邻居有N个点，每个都只有一个特征，即Size是N的MultiSize，这时至少要N个Aggregate才能够避免入射的产生。从算法上来讲，GNN如Graphsage，Gat等价于一阶的WLtest，本质上转换成了同构图的问题。同构就是让不同的子图确实能够通过Aggregate函数不发生入射。
　　为解决这个问题，Deepmind设计了一种新型的Aggregator算子，N个Moments对应着N个Aggregator算子。后面加了一个Scalers，下面的Sigma相当于是整合度的总和。d就是这个点的度，Alpha是一个系数，Alpha有1又有1。
　　在社交电商领域，基于人和人的推荐，有些商品实际上是适合刘耕宏这种度很大的人来推荐的，这时Alpha1。有些私密的商品适合你的闺蜜来向你推荐，此时Alpha1。你们两个度都很小，但你们两个是有联系的，这样推荐商品转化率是很高的。
　　这些在社交电商的场景下去解释是很合理的。最终通过从一阶Velocity的规则到不同Aggregate聚合函数，再有MLP，Scalers对不同度的归一化，再去使用MLP，形成了整体框架。
　　03hr相应平台的心得
　　早期一些Velocity很简单，但是工程压力大。要保证不同的特征能对齐，还有时间窗口的计算也很复杂。比如风控的过程中，想实现时间衰减，昨天的累计和与今天的累计和加上不同的权重或者系数，都需要做很大的系统改造。我们需要站在更高的角度上去做风控的聚合算法和底层存储索引系统，否则就是打补丁模式。
　　其实实现难度也不大，用DGL都可以很轻松地去实现这样的算子。
　　从算法角度来看，制约GNN学习能力的就是算子。不能变成另一种极端，复杂的框架和链路，用简单的算子。如果算子非常简单，就像四则混合运算，再怎么组合，再怎么搭积木，最后也就是四则混合运算，做不了微积分，又何谈更高阶的运算。
　　1。常用离线图算法框架GraphX
　　早期尝试去做图的时候，主要是做图的最短路径，单机版很简单。在大厂数据量很大，会使用分布式的图学习。首先是思维的转变，传统的图算法，都是Sequency的结构，很少有迭代式或者分布式。在MessagePassing的框架下，代表有阿里的OdpsGraph、SparkGraphX，背后的框架都用的是谷歌的思想，第一次把图算法的思路转化成以点为中心，和周围的点去做通信。
　　数学家说这是一种local算法，怎么通过Local的算法来产生一个全局的观测？当所有的点都在做Local的时候，就变成分布式了。
　　相对来说，阿里OdpsGraph实际上没有很复杂的设计，但是它保证了只要Work足够，总能算出结果。而且它是用Java开发，相对于GraphxScala没有做太多的封装，可以自己去写一些底层的函数。在实际的使用中，它并没有很耗内存，GraphX是非常耗内存的。如果要实现PreK框架这种MessagePassing的传统图算法甚至图标签算法，OdpsGraph是一个不错的选择。
　　2。腾讯高性能分布式图计算框架Plato
　　柏拉图是对于图论的算法以及Degree的分布做了优化。目前大部分框架并没有很强耦合，没有要求图的算法或分布要满足一定条件，更像是一种通用的分布式的产品。
　　首先MessagePassing有凝聚点的过程（push）和Pull过程（PushPull）。在这个过程中，大部分的算法有Sparse和Dense的演化过程。比如有些图只有很少的点，如微信好友圈有些点只有很少的度，少部分点有很多的度，Push阶段这些点都是很稀疏的，接收的时候是很稠密的。
　　Sparse和Dense双引擎类似CSR和CSC倾向于列和行不同的压缩模式。大部分MessagePassing算法，只有小部分的点会经过很多轮的迭代才会收敛，大部分的点几轮就会收敛。它是基于这种假设去设计的系统。
　　有时可能感觉它并没有达到那么好的效果，这其实与算法有关系。比如经典的PageRank，早期谷歌在优化PageRank的时候，请了矩阵计算的大牛去完成优化。核心的优化点就是观察到大部分的点经历了几步以后就已经收敛了，只有少部分的点要很多轮。基于这个洞察，让一些点停止，不再跟周围的点进行更新。这只有利用到Sparse和Dense特性才可以实现。使用该系统的时候，如果不去深入研究系统原理，最终效果可能都不太理想，这个还和图结构有关系。QQ的图与微信的图是不一样的。不同的算法在不同的图上，不同的目的，它的Sparse和Dense的表现也是不一样的。这需要算法去了解底层框架。
　　这个系统还有一个亮点，实现了特殊偏概率权重下的拒绝采样。
　　拒绝采样是动态的，如Node2Vec的算法，P和Q的参数是来调整节点更倾向于深搜还是广搜。它使用了一种抽样方法去实现，比较适合Node2Vec算法。Node2Vec每个边概率的权重是有上限的，P和Q的权重决定了面积的大小，那么它就适合。此时做蒙特卡洛随机采样的时候，确实是能够看到效果的提升。但如果使用动态权重的话，就会出现一些凝聚点和高峰。比如走到一个热点（明星点），会有一些高峰诞生，周围的点就很塌。此时会发现拒绝采样要多走好多轮才可能会落到R中，效果反而不好。针对Node2Vec这种每个偏概率权重有上限的情况，确实是能够很好地优化，对于通用的情况可能就会出现很差的效果。这时候需要算法同学选择合适的框架去做，也需要算法同学非常了解应用算法和系统算法的原理，做到上下贯通。
　　3。腾讯Angle图计算框架
　　腾讯Angle图计算平台在有些地方很好用，但也存在一些瓶颈。
　　首先图很难实现分布式及分布式管理。为了解决这个问题，Angle用了ParameterServer框架去实现。对于不同的算法，比如PageRank要把每个点的向量作为参数存起来，然后再进行分布式计算。在分布式计算的时候，采用了Spark计算的原理，一个Spark程序有很多的Executor来实现分布式计算。也从某种程度上解决了算法同学编程难的问题。
　　Angle针对Graphsage改一下是能够实现的。比如通过把连接节点放在ParameterSurvey中实现分布式，再通过CPyTorch的ModelJVM技术，使用SparkExecute方式实现分布式。这是一个更通用的计算平台。不同的图算法，不管是图神经网络还是特定图模式的发现都可以实现。
　　4。开源图数据库NebulaGraph
　　近几年，开源图数据库生态正在日益完善，NebulaGraph的开源图数据库在社区中已经有很多的文章。早期算法同学需要自己实在Flink框架实现数据同步，Nebula提供了Connected组件可以去实现。风控要做大量的案件和观点的分析，有这种可视化的平台很方便。但是从工程的角度，还有很多运维的事情。不管是在数据链路，跟流数据Flink还是离线数据Spark的打通上，跟图算法的打通，以及可视化分析，在运维上都已经有比较成熟的解决方案。
　　5。线上实时模型查询推理系统
　　金融支付防范实时风险可以用大厂的开源工具去实现。比如使用DGL实现模型实时推理。离线模型使用社区、交易数据训练，产生模型文件。
　　线上实时推理时，Nebula拿到实时文件去获得子图。AmazonSageMaker这样的Online的Inference还是很好用的。自己去写一些脚本，query图，解析图，导入图，再打通变成风控上的UDF。随着DGL的进步和Nebula的进步，一般独角兽公司SageMaker肯定是够用的。
　　从算法出发，反而能给到工程和设计更多帮助。比如要问SageMaker留一个脚本的口子的好处是什么，是要写死还是留给算法同学，可能需要不同类型的人去参与到图平台和框架的建设中去。如果不能成为风控、推荐中的一个特征或者因子，平台再好也没有多少价值，不会有更多的资源投入，也不会真正在工业界发挥作用。
　　6。DGLMessagePassing角度优化
　　DGL的MessagePassing的封装做得比较好。比如用DGL去开发标签传播，比用OdpsGraph去开发，速度快了很多，效率很高，因为它把MessagePassing函数、聚合函数都做了封装，能够快速实现各种各样的标签传播算法。
　　GDL的底层也做了一些优化。因为基于Spark，有一个问题就是Aggregate到Send过程会有很多额外的通讯和存储的开销。优化的方式是把该过程变成了矩阵的计算，然后再用到GPU优化的特性去完成，所以编程难度有所降低，效率上有很大的提高。
　　另外，有时图本身并不复杂，GPU很长时间在等待。现在的做法是，把更多的计算放到GPU中。去年黄仁勋在英伟达大会中也谈了GPU对DGL的推动。当然在工业界，与敏捷有一些差别。敏捷是更往下走，希望能封装成更底层的一些神经网络的算子，而我们是希望往上封装，提高对一线算法同学的易用性。
　　我们自己做了一个DGLAdapter，以突破内存限制，用少量的通信成本的牺牲，换取更大的图数据规模的训练能力。这是一个分布式的框架，有client和Server去获取图数据，再把不同的Batch分发给不同的worker，不同的Worker有了反馈结果，采样的结果再返回过来进行计算。
　　04hr展望未来
　　最后展望一下未来。长期的趋势是要从算法层面、平台层面、系统层面去改进。
　　1。图算法和图神经网络算法的融合
　　现在很多团队在谈GNN，但有时并不能说清GNN到底学到了什么东西，解释能力有多强。图的传统算法也不能放，因为不同的互联网公司、社区等等，都有不同的网络结构。我们要基于这些网络结构有一些洞察。比如是否需要和图神经网络，和DataMining结合。在风控的特定场景下，还要对图的特定Pattern去进行挖掘。比如Angle支持在ParameterServer框架的基础上加Spark，DGL又开了一个MessageParsing的口子，只要是能够变成MessageParsing框架的图算法，就都是可以实现的。首先算法同学在一线要知道如何融合，才能跟中台团队框架团队去合作。
　　2。图神经网络算法学习能力的攻克
　　学习能力的攻克，包括基本算子的不断突破非常重要，否则光是四则混合运算，再怎么组合其本身学习能力就不够。
　　3。图神经网络算法鲁棒性
　　风控很多时候是对抗，并不知道会有什么样的攻击方式，因此要提高算法鲁棒性。
　　4。图神经网络算法可解释性
　　无论是推荐还是风控，现实中制约落地的很多时候是一个可解释性的问题。
　　5。平台易用性和整合性
　　平台易用，用起来流程快，才能更快地实现各种算法的迭代。
　　6。应用算法和系统算法上下融合贯通和统筹
　　在建设图计算平台的时候，要真的懂业务和应用算法，实际用户也要懂系统算法层面，整体上需要上下打通和统筹。
　　一线算法、平台算法和中台等各个团队需要加强合作，也需要学术界和工业界一起努力。
　　05hr问答环节
　　Q1：风控场景中，它有这种事前事中和事后这种图模型。在这些三种不同的场景的话，它的图模型分别是如何来应用的？
　　A1：可能以前我们对算法和系统的发展没有那么好的时候，会分得比较清楚，事前事中事后，但是现在发展得更快，尤其我前面说的那个框架，就图数据库的完善，DGL以及类似SageMaker完善了以后，实时模型也不像以前那么难了，所以它在应用的时候更多的还是从数据和特征角度一方面要去考虑。在事前事中事后拿到的数据不一样是可以容忍的，计算量是不一样的。可能在事前算法不会那么复杂。比如一个新用户的数据本身是有限的，那这时候去做事后就可以上一些更加复杂的算法。一个人比如说今天来了就要判断他是坏人还是他在这里表现了30天是坏人？两者难度是不一样的，在算法的复杂度特征上是会不一样的。
　　Q2：在风控场景中有遇到图模型的可解释性问题吗？怎么解决？
　　A2：这个其实是很有意思的问题。图模型的解释性，其实说句实话比其他模型要容易的。为什么？因为图算法在风控为什么用得那么好？它有个强大的图的可视化能力。把不同的团伙可视化出来，一目了然。通过可视化来展示你的算法，主要就发现几种模式，一看就知道是批量注册。也可以通过动态图的演化，有一伙人在迁移。这方面大家可以多用一些图可视化的技术去形象化地把你发现东西总结出来。这是最快的。你也可以尝试着去实现一个GNNExplain。这里可能有些坑，因为GNN本身是一个优化问题，一般的机器学习都是无约束的，优化之后怎么去处理？可以弄一个近似GNNExplainner就大概知道到底学到了什么。不知道你学到了什么东西，其实也很难去进一步调整图神经网络，然后可能还要用一些观察。个人建议大家可以找一些学术合作伙伴，对于明天的方法，后天的方法也可以让学术界的朋友来看一看，就是说如何能够定量地去对GNNExplainner做一些突破，这些都可以。
　　Q3：图算法的鲁棒性，有哪些方法去度量？
　　A3：这个分一种学术上或者技术上严格意义的。这个度量是指改变了点和边的一些特性以后，其结果的变化，那就是一些面子上的或者是最基本的。在风控场景下的所谓鲁棒性的攻击，我总结下来就可能，点是真的，边是假的或者点是假的，边是真的。比如说今天别人伪造IP随便输了个IP来脚本攻击，那IP可能是真的，但边是假的？那有可能今天伪造了一个东西，这个点就是假的，所以有几种可能性。作为风控来说，可以尝试这几种不同的可能性去对你的模型进行攻击。因为现在对于风控来说比较缺的就是领域内的Cost和Attacks。Attacks有时候是未知的，黑产有时候用你不知道的方法，但是Cost可能是知道。在Cost和Attacks部分知道的情况下怎么去定义模型的鲁棒性，我觉得这个可能是对风控来说比较有价值的一个研究方向。
　　今天的分享就到这里，谢谢大家。
　　分享嘉宾
　　汪浩然
　　互联网行业资深风控和图计算专家
　　英国硕士，曾在蚂蚁金服，阿里巴巴，腾讯等公司主要从事风控算法，社交计算和图计算等工作，横跨金融，支付，电商，供应链，社区，社交等场景。率先工业界落地过诸多图上挖掘和机器学习算法，有算法百晓生和扫地僧之称。
　　DataFun新媒体矩阵
　　关于DataFun
　　专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100线下和100线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号DataFunTalk累计生产原创文章800，百万阅读，15万精准粉丝。