本文首發於 DataFunTalk 公眾號，授權 NebulaGraph 社群轉發。
導讀：本文將分享圖演算法在風控中的應用。
今天的介紹會圍繞下面四點展開：
- 圖演算法和風控簡介
- 圖演算法在風控的演化
- 相應平臺的心得
- 展望未來
分享嘉賓｜汪浩然，網際網路行業資深風控和圖計算專家。
圖演算法和風控簡介
什麼是圖演算法——圖論演算法
圖演算法最早來源於圖論和組合最佳化相關演算法，在風控裡面應用比較多的基本上都是傳統的圖演算法或比較偏數學理論的演算法，如最短路徑發現，不同的賬號和交易之間存在異常的最短路徑，某些賬號或裝置存在異常的關聯。另外，還有圖的識別，比如洗錢，會涉及到異常的環路。
早期圖在風控的應用都是基於明確的數學結構定義，如果大家仔細研究這些演算法，會發現有的演算法是多項式時間可以解決的，有些是多項式時間無法解決的，比如 NP-hard 問題。在團或圈的發現演算法中，其實會用到一些近似演算法。而且風控中有意思的一點是數學上定義得越嚴格，黑產繞過就越容易。比如黑產知道你的目的是發現團，他會故意某幾個裝置少一兩條邊，那數學嚴格的定義就很容易被繞過。
什麼是圖演算法——圖機器學習
早期業內是直接應用這套傳統圖演算法到風控中，隨著技術的發展，圖機器學習也開始應用在風控中。比如早期本人在交易場景中落地了一個標籤傳播演算法，它是一個 Transudative 推演式的演算法（非歸納式）。
在現實應用中，很多時候我們沒有辦法對黑白灰樣本去做完全精確的定位。那該如何利用類似社交網路的同質性（好人和好人關係近，壞人和壞人關係近）做團伙識別？在風控場景，很容易透過強規則產出高準確率的樣本，但覆蓋率很低（低召回），那麼如何擴充這些樣本呢？
此時標籤傳播演算法和半監督技術就開始在風控中使用。圖神經網路的半監督學習，其學習能力和魯棒性高於傳統圖演算法。有別於傳統的圖演算法的自定義 Aggregate 和 Message Passing，隨著圖神經網路的發展，也越來越多的應用到風控場景。
什麼是圖演算法——圖挖掘演算法
風控場景中使用到很多圖挖掘演算法，如：
- 高密度子圖，一些異常賬號和異常行為物件之間會存在高密度子圖。
- 鄰居域異常，異常節點、邊、網路存在異常的形狀（如星形散射狀），即該賬戶的鄰居域異常。
- 複雜網路，比如異常網路的度分佈和正常網路的度分佈是不同的。如有時挖掘了一些團伙，可以基於 Degree Sequence 構建特徵和模型。不同 Degree Sequence 分佈的網路存在不同的特性，這可以指導我們進一步構建拓撲相關特徵。
什麼是風控
上圖中的臺詞很好地概括了風控的工作，“人活一世，有的人成了面子，有的人成了裡子，都是時勢使然”。從事金融風控、交易風控，風控規則和演算法是公司的核心競爭力，都需要保密。有很多精彩的演算法及落地不方便出來交流，可能很少有人知道，但這都成了裡子。風控同學也是甘於寂寞，不斷地去進行各種對抗，同時也在鑽研技術和業務。
網際網路風控幹什麼
眾所周知的羊毛黨薅羊毛、賬戶被盜、盜卡、現金貸、“以貸養貸”、貓池、惡意退貨、物流空包、各種各樣的詐騙、殺豬盤等等，這些場景都屬於網際網路風控範疇。
圖演算法和風控的相遇
為什麼圖演算法和風控會相遇？黑產作案存在團伙性，一個人不可能靠一個賬戶就去作案，更多的時候需要多人多賬戶的協同。
團伙特性就會使黑產之間產生關聯，這就引入了圖演算法。作案有相似性，但案件和作案人之間可能沒有物理和空間關聯，但在某些角度他們存在相似性（如行為）。風控也可以透過除了直接的關係外的點和點之間的相似性構造邊。因為作案有相似性，這也是網路可以存在的一個條件。
還有一個原因是作案需要大量的賬號和裝置資源的配合，利益的驅動就會讓黑產做更多的事情。作案需要成本，如手機、賬號等。物以類聚，人以群分（同質性）。
以上這些就是圖演算法和風控相遇的原因。
圖演算法在風控的演化
幾個核心趨勢
早年間風控尤其是風控策略，更多的是一個 Rule Writer。透過業務理解寫規則，慢慢演化成演算法模型。還有從經典一階的 Velocity 變數變成了 Neutral Net Aggregator（後面會細講）。傳統的風控演算法或規則只能看到相鄰點的特徵，現在可以透過神經網路計算 Aggregator。這也是從數學嚴格定義的網路結構到圖神經網路、Strict Definition 到機率化的推斷的演進過程。
本人曾請教過圖靈獎得主 John Hopcroft，他在圖的匹配還有自動機方面做了很多工作。當時問他，傳統的圖演算法的研究對現在的人工智慧有沒有什麼幫助？首先他覺得是沒有的（可能是謙虛），他談到一個非常大的趨勢，過去大部分都是嚴格數學的定義，以後會更偏向機率推斷。這個趨勢也很契合風控，數學上定義得越嚴格，越容易被黑產攻克。使用機器學習、圖神經網路去進行學習，最終就是變成了一個機率的推斷。
經典一階的 Velocity 變數
傳統的一階 Velocity 能看到一個 IP 周圍有很多的 Device 。要評估該IP 的風險，可以觀察其相鄰的 Device 的風險特徵，如最近幾天的交易登入統計，最近 7 天的交易筆數，一小時內同 IP 的交易使用者數等，這些都屬於一階 Velocity。
以前風控從業者相當於人工構建了圖神經網路的 Aggregate 函式（Min、Max、Mean）。
- Min 函式，比如該 IP 周圍 Device 註冊的最小時間，如裝置註冊最小時間都是最近的，即新裝置，那麼該 IP 存在很大的風險。
- Max 函式，如裝置上的最大的賬戶數，多人共用單個裝置也是異常。
- Mean 函式，如周圍的裝置平均的交易數。之前風控從業者透過手工去設計這個一階的 Aggregate，透過圖演算法能從一階到兩階。
神經網路的聚合
引入了神經網路以後，把一階或者二階的 Velocity 透過神經網路學習。讓演算法去學壞人的 Pattern 而不是手工地去歸納，增加了繞過成本和模型的魯棒性。單純的一階的閾值很容易被黑產試出來，透過魯棒性的 MLP 去預測，有明顯的效果提升。
Aggregator 運算元的突破
Aggregator 運算元最核心的演算法上的突破就是 Deepmind 實現的。它用了代數拓撲的概念，如一個節點的鄰居有 N 個點，每個都只有一個特徵，即 Size 是 N 的 Multi-Size，這時至少要 N 個 Aggregate 才能夠避免入射的產生。從演算法上來講，GNN 如 GrapSAGE，Gat 等價於一階的 WL-test，本質上轉換成了同構圖的問題。同構就是讓不同的子圖確實能夠透過 Aggregate 函式不發生入射。
為解決這個問題，Deepmind 設計了一種新型的 Aggregator 運算元， N 個 Moments 對應著 N 個 Aggregator 運算元。後面加了一個 Scalers, 下面的 Sigma 相當於是整合度的總和。d 就是這個點的度，Alpha 是一個係數，Alpha 有 1 又有 -1。
在社交電商領域，基於人和人的推薦，有些商品實際上是適合劉耕宏這種度很大的人來推薦的，這時 Alpha=1。有些私密的商品適合你的閨蜜來向你推薦，此時 Alpha=-1。你們兩個度都很小，但你們兩個是有聯絡的，這樣推薦商品轉化率是很高的。
這些在社交電商的場景下去解釋是很合理的。最終透過從一階 Velocity 的規則到不同 Aggregate 聚合函式，再有 MLP，Scalers 對不同度的歸一化，再去使用 MLP，形成了整體框架。
相應平臺的心得
早期一些 Velocity 很簡單，但是工程壓力大。要保證不同的特徵能對齊，還有時間視窗的計算也很複雜。比如風控的過程中，想實現時間衰減，昨天的累計和與今天的累計和加上不同的權重或者係數，都需要做很大的系統改造。我們需要站在更高的角度上去做風控的聚合演算法和底層儲存索引系統，否則就是打補丁模式。
其實，實現難度也不大，用 DGL 都可以很輕鬆地去實現這樣的運算元。
從演算法角度來看，制約 GNN 學習能力的就是運算元。不能變成另一種極端，複雜的框架和鏈路，用簡單的運算元。如果運算元非常簡單，就像四則混合運算，再怎麼組合，再怎麼搭積木，最後也就是四則混合運算，做不了微積分，又何談更高階的運算。
常用離線圖演算法框架——GraphX
早期嘗試去做圖的時候，主要是做圖的最短路徑，單機版很簡單。在大廠資料量很大，會使用分散式的圖學習。首先是思維的轉變，傳統的圖演算法，都是 Sequency 的結構，很少有迭代式或者分散式。在 Message Passing 的框架下，代表有阿里的 ODPS Graph、Spark GraphX，背後的框架都用的是谷歌的思想，第一次把圖演算法的思路轉化成以點為中心，和周圍的點去做通訊。
數學家說這是一種 local演算法，怎麼透過 Local 的演算法來產生一個全域性的觀測？當所有的點都在做 Local 的時候，就變成分散式了。
相對來說，阿里 ODPS Graph 實際上沒有很複雜的設計，但是它保證了只要 Work 足夠，總能算出結果。而且它是用 Java 開發，相對於 GraphX Scala 沒有做太多的封裝，可以自己去寫一些底層的函式。在實際的使用中，它並沒有很耗記憶體，GraphX 是非常耗記憶體的。如果要實現 Pre-K 框架這種 Message Passing 的傳統圖演算法甚至圖示籤演算法，ODPS Graph 是一個不錯的選擇。
騰訊高效能分散式圖計算框架——Plato
柏拉圖是對於圖論的演算法以及 Degree 的分佈做了最佳化。目前大部分框架並沒有很強耦合，沒有要求圖的演算法或分佈要滿足一定條件，更像是一種通用的分散式的產品。
首先 Message Passing 有凝聚點的過程（push）和 Pull 過程（Push & Pull）。在這個過程中，大部分的演算法有 Sparse 和 Dense 的演化過程。比如有些圖只有很少的點，如微信好友圈有些點只有很少的度，少部分點有很多的度，Push 階段這些點都是很稀疏的，接收的時候是很稠密的。
Sparse 和 Dense 雙引擎類似 CSR 和 CSC 傾向於列和行不同的壓縮模式。大部分 Message Passing 演算法，只有小部分的點會經過很多輪的迭代才會收斂，大部分的點幾輪就會收斂。它是基於這種假設去設計的系統。
有時可能感覺它並沒有達到那麼好的效果，這其實與演算法有關係。比如經典的 PageRank，早期谷歌在最佳化 PageRank 的時候，請了矩陣計算的大牛去完成最佳化。核心的最佳化點就是觀察到大部分的點經歷了幾步以後就已經收斂了，只有少部分的點要很多輪。基於這個洞察，讓一些點停止，不再跟周圍的點進行更新。這隻有利用到 Sparse 和 Dense 特性才可以實現。使用該系統的時候，如果不去深入研究系統原理，最終效果可能都不太理想，這個還和圖結構有關係。QQ 的圖與微信的圖是不一樣的。不同的演算法在不同的圖上，不同的目的，它的 Sparse 和 Dense 的表現也是不一樣的。這需要演算法去了解底層框架。
這個系統還有一個亮點，實現了特殊偏機率權重下的拒絕取樣。
拒絕取樣是動態的，如 Node2Vec 的演算法，P 和 Q 的引數是來調整節點更傾向於深搜還是廣搜。它使用了一種抽樣方法去實現，比較適合 Node2Vec 演算法。Node2Vec 每個邊機率的權重是有上限的，P 和 Q 的權重決定了面積的大小，那麼它就適合。此時做蒙特卡洛隨機取樣的時候，確實是能夠看到效果的提升。但如果使用動態權重的話，就會出現一些凝聚點和高峰。比如走到一個熱點（明星點），會有一些高峰誕生，周圍的點就很塌。此時會發現拒絕取樣要多走好多輪才可能會落到 R 中，效果反而不好。針對 Node2Vec 這種每個偏機率權重有上限的情況，確實是能夠很好地最佳化，對於通用的情況可能就會出現很差的效果。這時候需要演算法同學選擇合適的框架去做，也需要演算法同學非常瞭解應用演算法和系統演算法的原理，做到上下貫通。
騰訊 Angel 圖計算框架
騰訊 Angle 圖計算平臺在有些地方很好用，但也存在一些瓶頸。
首先，圖很難實現分散式及分散式管理。為了解決這個問題，Angel 用了 Parameter Server 框架去實現。對於不同的演算法，比如 PageRank 要把每個點的向量作為引數存起來，然後再進行分散式計算。在分散式計算的時候，採用了 Spark 計算的原理，一個 Spark 程式有很多的 Executor 來實現分散式計算。也從某種程度上解決了演算法同學程式設計難的問題。
Angel 針對 GraphSAGE 改一下是能夠實現的。比如透過把連線節點放在 Parameter Survey 中實現分散式，再透過 C++& PyTorch 的 Model JVM 技術，使用 Spark Execute 方式實現分散式。這是一個更通用的計算平臺，不同的圖演算法，不管是圖神經網路還是特定圖模式的發現都可以實現。
開源圖資料庫——NebulaGraph
近幾年，開源圖資料庫生態正在日益完善，NebulaGraph 的開源圖資料庫在社群中已經有很多的文章。早期演算法同學需要自己實在 Flink 框架實現資料同步，NebulaGraph 提供了 Connector 元件可以去實現。風控要做大量的案件和觀點的分析，有這種視覺化的平臺很方便。但是，從工程的角度，還有很多運維的事情。不管是在資料鏈路，跟流資料 Flink 還是離線資料 Spark 的打通上，跟圖演算法的打通，以及視覺化分析，在運維上都已經有比較成熟的解決方案。
線上實時模型查詢推理系統
金融支付防範實時風險可以用大廠的開源工具去實現。比如使用 DGL 實現模型實時推理；離線模型使用社群、交易資料訓練，產生模型檔案。
線上實時推理時，NebulaGraph 拿到實時檔案去獲得子圖。Amazon SageMaker 這樣的 Online 的 Inference 還是很好用的。自己去寫一些指令碼， query 圖、解析圖、匯入圖，再打通變成風控上的 UDF。隨著 DGL 的進步和 NebulaGraph 的進步，一般獨角獸公司 SageMaker 肯定是夠用的。
從演算法出發，反而能給到工程和設計更多幫助。比如要問 SageMaker 留一個指令碼的口子的好處是什麼，是要寫死還是留給演算法同學，可能需要不同型別的人去參與到圖平臺和框架的建設中去。如果不能成為風控、推薦中的一個特徵或者因子，平臺再好也沒有多少價值，不會有更多的資源投入，也不會真正在工業界發揮作用。
DGL-Message Passing 角度最佳化
DGL 的 Message Passing 的封裝做得比較好。比如用 DGL 去開發標籤傳播，比用 ODPS Graph 去開發，速度快了很多，效率很高，因為它把 Message Passing 函式、聚合函式都做了封裝，能夠快速實現各種各樣的標籤傳播演算法。
DGL 的底層也做了一些最佳化。因為基於 Spark，有一個問題就是 Aggregate 到 Send 過程會有很多額外的通訊和儲存的開銷。最佳化的方式是把該過程變成了矩陣的計算，然後再用到 GPU 最佳化的特性去完成，所以程式設計難度有所降低，效率上有很大的提高。
另外，有時圖本身並不複雜，GPU 很長時間在等待。現在的做法是，把更多的計算放到 GPU 中。去年黃仁勳在英偉達大會中也談了 GPU 對 DGL 的推動。當然在工業界，與敏捷有一些差別。敏捷是更往下走，希望能封裝成更底層的一些神經網路的運算元，而我們是希望往上封裝，提高對一線演算法同學的易用性。
我們自己做了一個 DGL-Adapter，以突破記憶體限制，用少量的通訊成本的犧牲，換取更大的圖資料規模的訓練能力。這是一個分散式的框架，有 Client和 Server 去獲取圖資料，再把不同的 Batch 分發給不同的 Worker ，不同的 Worker 有了反饋結果，取樣的結果再返回過來進行計算。
展望未來
最後展望一下未來。長期的趨勢是要從演算法層面、平臺層面、系統層面去改進。
圖演算法和圖神經網路演算法的融合
現在很多團隊在談 GNN，但有時並不能說清 GNN 到底學到了什麼東西，解釋能力有多強。圖的傳統演算法也不能放，因為不同的網際網路公司、社群等等，都有不同的網路結構。我們要基於這些網路結構有一些洞察。比如是否需要和圖神經網路，和 Data Mining 結合。在風控的特定場景下，還要對圖的特定 Pattern 去進行挖掘。比如 Angel 支援在 Parameter Server 框架的基礎上加 Spark，DGL 又開了一個 Message Parsing 的口子，只要是能夠變成 Message Parsing 框架的圖演算法，就都是可以實現的。首先，演算法同學在一線要知道如何融合，才能跟中臺團隊框架團隊去合作。
圖神經網路演算法學習能力的攻克
學習能力的攻克，包括基本運算元的不斷突破非常重要，否則光是四則混合運算，再怎麼組合其本身學習能力就不夠。
圖神經網路演算法魯棒性
風控很多時候是對抗，並不知道會有什麼樣的攻擊方式，因此要提高演算法魯棒性。
圖神經網路演算法可解釋性
無論是推薦還是風控，現實中制約落地的很多時候是一個可解釋性的問題。
平臺易用性和整合性
平臺易用，用起來流程快，才能更快地實現各種演算法的迭代。
應用演算法和系統演算法上下融合貫通和統籌
在建設圖計算平臺的時候，要真的懂業務和應用演算法，實際使用者也要懂系統演算法層面，整體上需要上下打通和統籌。
一線演算法、平臺演算法和中臺等各個團隊需要加強合作，也需要學術界和工業界一起努力。
問答環節
Q1：風控場景中，它有這種事前事中和事後這種圖模型。在這些三種不同的場景的話，它的圖模型分別是如何來應用的？
A1：可能以前我們對演算法和系統的發展沒有那麼好的時候，會分得比較清楚，事前事中事後，但是現在發展得更快，尤其我前面說的那個框架，就圖資料庫的完善，DGL 以及類似 SageMaker 完善了以後，實時模型也不像以前那麼難了，所以它在應用的時候更多的還是從資料和特徵角度一方面要去考慮。在事前事中事後拿到的資料不一樣是可以容忍的，計算量是不一樣的。可能在事前演算法不會那麼複雜。比如一個新使用者的資料本身是有限的，那這時候去做事後就可以上一些更加複雜的演算法。一個人比如說今天來了就要判斷他是壞人還是他在這裡表現了 30 天是壞人？兩者難度是不一樣的，在演算法的複雜度特徵上是會不一樣的。
Q2：在風控場景中有遇到圖模型的可解釋性問題嗎？怎麼解決？
A2：這個其實是很有意思的問題。圖模型的解釋性，其實說句實話比其他模型要容易的。為什麼？因為圖演算法在風控為什麼用得那麼好？它有個強大的圖的視覺化能力。把不同的團伙視覺化出來，一目瞭然。透過視覺化來展示你的演算法，主要就發現幾種模式，一看就知道是批次註冊。也可以透過動態圖的演化，有一夥人在遷移。這方面大家可以多用一些圖視覺化的技術去形象化地把你發現東西總結出來。這是最快的。你也可以嘗試著去實現一個 GNN Explain。這裡可能有些坑，因為 GNN 本身是一個最佳化問題，一般的機器學習都是無約束的，最佳化之後怎麼去處理？可以弄一個近似 GNN Explainer 就大概知道到底學到了什麼。不知道你學到了什麼東西，其實也很難去進一步調整圖神經網路，然後可能還要用一些觀察。個人建議大家可以找一些學術合作伙伴，對於明天的方法，後天的方法也可以讓學術界的朋友來看一看，就是說如何能夠定量地去對 GNN Explainer 做一些突破，這些都可以。
Q3：圖演算法的魯棒性，有哪些方法去度量？
A3：這個分一種學術上或者技術上嚴格意義的。這個度量是指改變了點和邊的一些特性以後，其結果的變化，那就是一些面子上的或者是最基本的。在風控場景下的所謂魯棒性的攻擊，我總結下來就可能，點是真的，邊是假的或者點是假的，邊是真的。比如說今天別人偽造 IP 隨便輸了個 IP 來指令碼攻擊，那 IP 可能是真的，但邊是假的？那有可能今天偽造了一個東西，這個點就是假的，所以有幾種可能性。作為風控來說，可以嘗試這幾種不同的可能性去對你的模型進行攻擊。因為現在對於風控來說比較缺的就是領域內的 Cost 和 Attacks。Attacks 有時候是未知的，黑產有時候用你不知道的方法，但是 Cost 可能是知道。在 Cost 和 Attacks 部分知道的情況下怎麼去定義模型的魯棒性，我覺得這個可能是對風控來說比較有價值的一個研究方向。
今天的分享就到這裡，謝謝大家。
分享嘉賓
汪浩然，網際網路行業資深風控和圖計算專家。英國碩士，曾在螞蟻金服，阿里巴巴，騰訊等公司主要從事風控演算法，社交計算和圖計算等工作，橫跨金融，支付，電商，供應鏈，社群，社交等場景。率先工業界落地過諸多圖上挖掘和機器學習演算法，有演算法百曉生和掃地僧之稱。
謝謝你讀完本文 (///▽///)
一起用 NebulaGraph Cloud 來搭建自己的圖資料系統，節省大量的部署安裝時間來搞定業務吧~ NebulaGraph 阿里雲端計算巢現 30 天免費使用中，點選連結來用用圖資料庫吧~
想看原始碼的小夥伴可以前往 GitHub 閱讀、使用、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraph 使用者一起交流圖資料庫技術和應用技能，留下「你的名片」一起玩耍呢~