關聯圖譜在轉轉風控的實踐
來源:轉轉技術
1 背景 1-1 引言 2 關聯圖譜介紹 2-1 關聯圖譜的定義 2-2 關聯圖譜和圖論的關係 3 關聯圖譜架構 3-1 關聯方案 3-2 關係儲存 3-3 關聯架構 3-4 關聯降噪 3-5 關聯擴召 4 關聯圖譜應用 4-1 關聯特徵挖掘 4-2 關聯染色 4-3 運營後臺展示 4-4 關聯資料分析 4-5 關聯監控 5 總結
1.背景
1-1.引言
轉轉上大多數“壞事”是少部分人做的,這一小部分人(黑產)為了控制成本,重複利用已有資源進行欺詐、薅羊毛、洗錢等違規行為。黑產的資源和行為會成聚集性,因此,關聯在團伙識別上發揮著重要的作用,能使單一維度的使用者識別升級成對團伙的對抗,對於風險控制是非常有效的手段。
2.關聯圖譜介紹
2-1.關聯圖譜的定義
在常規的風險識別場景中,往往關注的是單一節點的屬性。其實,在這背後還有另一類非常有效的資訊——關聯資訊。比如,使用者A的註冊手機號是M;使用者B的註冊手機號也是M;那麼,使用者A和使用者B則透過註冊手機號M相互關聯,M就是使用者A和使用者B的關聯因子。如果將使用者A、使用者B、關聯因子M這些結構型的資訊用圖表示出來,就構成了我們所說的關聯圖譜。
2-2.關聯圖譜和圖論的關係
關聯圖譜的理論基礎是圖論。圖論是數學的一個分支,它以圖為研究物件,圖論中的圖是由若干給定的點及連線兩點的線所構成的圖形,這種圖形通常用來描述某些事物之間的某種特定關係,用點代表事物,用連線兩點的線表示相應兩個事物間具有這種關係。圖論本身有很多分支,如幾何圖論、組合圖論、演算法圖論、隨機圖論、代數圖論等。通常我們說的圖論是組合圖論,而在人工智慧的領域裡代數圖論也有很重要的應用。
2-3.圖論
2-3-1.頂點和邊
頂點表示某個事物或物件,如下圖中的使用者A、使用者B、使用者C。
邊表示事物和事物的關係,如下圖中的關聯因子a、關聯因子b、關聯因子c。
2-3-2.有向圖和無向圖
無向圖:節點之間的邊不存在方向。如下圖:
有向圖:節點之間的邊存在方向。如下圖:
2-3-3.同構圖和異構圖
異構圖:可以存在多種節點和邊。如下圖,可以存在多種節點(使用者、手機號、裝置)。
同構圖:只存在一種節點和邊。如下圖,只存在一種節點(使用者節點)。
2-3-4.鄰接矩陣和鄰接表
鄰接矩陣和鄰接表是圖的兩種表現形式。
鄰接矩陣用一個一維陣列儲存頂點的資訊 和 二維陣列來邊的資訊 上圖的鄰接矩陣表示:
A | B | C | D | E | F | |
---|---|---|---|---|---|---|
A | 0 | 0 | 1 | 0 | 0 | 1 |
B | 0 | 0 | 1 | 1 | 0 | 1 |
C | 1 | 1 | 0 | 0 | 1 | 0 |
D | 0 | 1 | 0 | 0 | 1 | 0 |
E | 0 | 0 | 1 | 1 | 0 | 0 |
F | 1 | 1 | 0 | 0 | 0 | 0 |
鄰接表陣列(頂點集)+連結串列(邊集)的形式 無向圖的鄰接表:
2-3-5.路徑和最短路徑
路徑:從圖中一個頂點到另一個頂點所經過的長度叫做路徑。其中,長度最小的路徑叫做最短路徑。最短路徑問題主要包括兩個方面:單源最短路徑:給定頂點到其它所有頂點的最短路徑問題。多源最短路徑:每對頂點之間的最短路徑問題。一般求圖中路徑的方法最通用的就是廣度優先遍歷演算法和深度優先遍歷演算法。求最短路徑常用演算法有很多,比如Dijkstra演算法、Floyd演算法。在此就不展開講啦~
2-3-6.連通圖和連通分量
在無向圖G中,如果從頂點 v 到頂點 w 有路徑存在,則稱 v 和 w 是連通的。如果圖G中任意兩個頂點 v 和 m 都是連通的(即任意兩個頂點連通),則稱G是連通圖(Connected Graph)。無向圖中的極大連通子圖稱為連通分量。注意連通分量的概念,它強調:
要是子圖; 子圖要是連通的; 連通子圖含有極大頂點數; 具有極大頂點數的連通子圖包含依附於這些頂點的所有邊。
上圖的圖a是一個無向非連通圖。但是它有兩個連通分量,即圖b和圖c;而圖d儘管是圖a的子圖,但它卻不滿足連通子圖的極大頂點數;因此它不是圖a無向圖的連通分量。
3.關聯圖譜架構
3-1.關聯方案
3-1-1.同構圖 vs 異構圖
上面圖論基礎中介紹過,同構圖只存在一種行為/關係,而異構圖存在多種行為和關係。只儲存使用者和關聯因子的情況下:
同構圖 | 異構圖 | |
---|---|---|
儲存成本 | 低 | 高 |
圖的大小 | 小 | 大 |
計算複雜度 | 低 | 高 |
所以,同構圖既符合應用場景,又能最小代價的解決問題。
3-1-2.圖——>樹
將圖五中錯綜複雜的關係以使用者A為樹的根節點,F、C為第二層樹節點,以此類推,將圖五表示成樹的形式,這種樹型的形式對於線上單一使用者的關聯比較容易理解。如下圖
3-2. 關係儲存
如下圖所示,有一組這樣的關聯資料,該怎麼儲存呢?
3-2-1. MySQL
裝置表:
使用者uid | 裝置資訊 | 時間 |
---|---|---|
使用者A | 裝置a | t1 |
使用者B | 裝置d | t2 |
使用者C | 裝置a | t3 |
使用者C | 裝置b | t4 |
使用者C | 裝置f | t5 |
使用者D | 裝置f | t6 |
使用者D | 裝置c | t7 |
使用者F | 裝置b | t8 |
使用者G | 裝置c | t9 |
手機號表:
使用者uid | 手機號資訊 | 時間 |
---|---|---|
使用者A | 手機號a | t1 |
使用者A | 手機號b | t2 |
使用者B | 手機號a | t3 |
使用者B | 手機號c | t4 |
使用者D | 手機號b | t5 |
為啥關聯因子要分開儲存?這是具體的業務形態決定的,各個關聯因子分散在不同的業務中。
3-2-2. Redis
redis儲存的是key-set結構,這樣就可以快速定位到對應的使用者(或者關聯因子)關聯的資料(類似於前面介紹的鄰接表)。
3-2-3. 圖資料庫
圖資料庫雖然對圖計算和圖查詢有很好的支援,但是會有一些弊端(如neo4j缺少叢集和橫向擴充套件的能力)。並且叢集運維也需要專門的人力去覆蓋,暫時來說還不做考慮。
3-3. 關聯架構
3-3-1. 關聯結構
3-3-2. 關聯架構圖
3-4. 關聯降噪
隨著關聯因子緯度的增多,並非每個關聯因子都能絕對準確的刻畫兩個使用者之間的關係。有些弱關聯會造成關聯誤傷,為了提高準確性,需要將弱關聯因子降噪。
3-4-1. 關聯增加限定條件
關聯因子存在過期時間,因子長時間未活躍的,設定無效關聯。 排除無效關聯因子,比如說:手機號11111111111。 弱關聯因子組合使用,組合次數越多,準確越高。
3-4-2. 排除異常關聯部分
某一個關聯因子關聯使用者太多,這種就需要考慮因子的準確性問題。
3-4-3. 設定關聯上限
設定關聯上限,一是保證介面的時效性;二是防止關聯過多帶來的誤傷太大。
3-4-4. 設定關聯層級
層級越深,召回越大,關聯誤傷越多;在實際業務場景中,需要根據業務權衡召回和準確。
3-5. 關聯擴召
3-5-1. 弱關聯因子
比如說,同一個ip、同一個地址等等。弱關聯也可透過降噪使用增加召回。
3-5-2. 行為相似關聯
團伙在進行操作的時候基本上都會統一操作,指令碼程式自動化操作,所以行為存在很大的相似性,增加行為相似的關聯也能擴大關聯的召回。
4. 關聯圖譜應用
4-1. 關聯特徵挖掘
我們可以根據關係挖掘出許多特徵。比如,團伙使用者的中心性相關的特徵。中心性(centrality)體現了節點在關聯中的重要程度,衡量指標主要包括度中心性(Degree centrality)、緊密中心性(Closeness centrality)、中介中心性(Betweenness centrality)、特徵向量中心性(eigenvectorcentrality)等。簡單介紹下度中心性(Degree centrality): 度中心性定義為節點上度的數目,是關聯圖譜中中心度量方式。一個節點如果與很多其他節點發生直接聯絡,那麼這個節點就處於中心地位。透過這個我們就可以挖掘一些最直接的特徵,比如:使用者下關聯因子的數量、關聯因子關聯的使用者數量等等。
還有許多其他的相關的特徵,在此不一一列出。
4-2.關聯染色
4-2-1. 關聯染色定製化
關聯因子層級可配,關聯因子可配置 關聯因子和關聯層級針對具體的業務配置,根據業務場景的準確性進行後續的處置(直接處罰,降級處罰,人工稽核等)。
4-2-2. 主動染色
4-2-2-1. 策略(運營人員)識別染色
4-2-2-2. 場景行為關聯染色
如上圖流程,使用者A在平臺內進行登入行為的時候;當前請求中含有使用者的唯一編碼、裝置資訊等。此時,以使用者A為樹中的一個點經過裝置(關聯因子1)去發散,發散的層級根據具體的業務場景去決策。如果在發散的過程中,發現與之關聯的賬戶是黑產賬戶,使用者A就會染成黑色賬戶或者灰色賬戶,為後續使用者風險識別提供決策依據。注意:如果確定要將使用者A染色,務必記錄染色的源頭賬戶以及關聯染色的關係鏈,為後續分析提供證據。比如:使用者A->B->F->G,發現F和G都是黑產賬戶,可以將A賬戶染色,B賬戶染色。記錄A、B賬戶的源頭賬戶是F的源頭賬戶(F賬戶可能也是關聯染色的賬戶,因此此處記錄的是最終的源頭)。
4-2-3. 染色解除
如果發現黑產賬戶誤染,解除當前賬戶的時候要檢視當前賬戶是源頭染色還是非源頭染色;如果是源頭染色,確認無誤後,解除此源頭下所有的染色使用者;如果是非源頭染色,首先要確認此賬戶源頭染色賬戶是否有問題,如果屬於誤染,解除團伙所有的染色。如果不屬於誤染,再確認下當前賬戶是否有問題,如果屬於關聯因子準確性導致的誤染,需要解除當前賬戶染色以及因為當前賬戶關聯的染色,再將當前賬戶的關聯因子清除(防止關聯因子再次誤傷);還可以把當前賬戶孤立,就不會再次誤傷了;賬戶孤立的弊端就是此賬戶不會再在團伙中出現。
4-3. 運營後臺展示
4-3-1. 關聯賬戶資訊
4-3-2. 使用者之間的關聯路徑
由於關聯資料儲存和關聯層級配置,選擇的是廣度優先遍歷演算法。如圖十七:使用者S和使用者E的關聯路徑
4-4. 關聯資料分析
4-4-1. 使用者關聯
表1
使用者uid | 關聯因子a |
---|---|
uid1 | 關聯因子1 |
uid2 | 關聯因子2 |
...... | ...... |
uidn | 關聯因子n |
hive表關聯,一個join表操作就能將關聯資料輸出:
select
distinct zzt2.使用者uid as 使用者A,
zzt3.使用者uid as touid As 使用者B,
zzt1.關聯因子a as 關聯因子
from
(select 關聯因子a from 表1 group by 關聯因子a having count(1)>=2 ) zzt1
JOIN
(select 使用者uid,關聯因子a from 表1 ) zzt2
ON
zzt1.關聯因子a=zzt2.關聯因子a
JOIN
(select 使用者uid,關聯因子a from 表1) zzt3
ON
zzt1.關聯因子a=zzt3.關聯因子a
當然,實際工程中要比這個複雜,關聯因子的資料要經過多次的預處理。
4-4-2. 關聯分組
透過Graphx的connectedComponents求圖中的連通圖,選取連通圖中的一個id作為組id,這個是為了方便資料分析用。上面連通圖已經介紹過了,此處不再次介紹。
4-5. 關聯監控
4-5-1. 大團夥監控
團伙數量大於n的團伙定時check。關聯賬戶數量太多,屬於很不正常的特徵。需要定時review大賬戶的使用者行為,進行染色或者重點監控。
4-5-2. 關聯佔比
監控團伙使用者(關聯賬戶>2)的佔比,資料波動應該穩定在一定的範圍之內;否則,要引起重視。
4-5-3. 團伙請求qps佔比
這個指標需要實時監控,如果指標突然佔比增多,大機率有團伙在作案,需要根據行為重點跟蹤。
5. 總結
關聯圖譜是一種非常有效的風控基礎能力,關聯強度的定義要和業務邏輯融合;關聯因子的強弱選擇和具體的業務場景是相輔相成的,關聯圖譜的準確和召回也跟具體的業務場景有莫大的聯絡;因此,要從實際的業務場景出發,選擇適合自己業務的關聯能力。
作者介紹:
劉鼕鼕,轉轉資深研發,多年風控研發經驗,主要負責風控架構,涉及策略引擎、關聯圖譜等風控核心能力。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70027824/viewspace-2995814/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Nebula 在 Akulaku 智慧風控的實踐:圖模型的訓練與部署模型
- 風控沙龍 | 圖分析方法在業務風控中的應用
- 京東物流實時風控實踐
- 圖分析方法在業務風控中的應用
- 動態執行緒池在轉轉平臺的實踐執行緒
- PostgreSQL家譜、族譜類應用實踐-圖式關係儲存與搜尋SQL
- 知物由學 | 使用者關係圖譜在內容安全領域的應用實踐
- 【機器學習PAI實踐四】如何實現金融風控機器學習AI
- 在Delphi中實現圖片的旋轉、縮放 (轉)
- 基於 Nebula Graph 構建百億關係知識圖譜實踐
- 錢大媽基於 Flink 的實時風控實踐
- 檔案關聯 (轉)
- 回顧·知識圖譜在貝殼找房的從0到1實踐
- TiDB 分散式資料庫在轉轉公司的應用實踐TiDB分散式資料庫
- 關於物聯網框架的實踐框架
- 轉轉OLAP自助分析實踐
- ThinkJS 關聯模型實踐JS模型
- 圖演算法、圖資料庫在風控場景的應用演算法資料庫
- 在關聯式資料庫中儲存RDF (轉)資料庫
- 轉轉上門履約的LBS實踐
- 證券圖譜平臺國產化替代實踐
- 騰訊音樂知識圖譜搜尋實踐
- C語言,實現數字譜到簡譜的轉換(二)C語言
- 淨室與其他軟體工程實踐的關係 (轉)軟體工程
- 物聯網產業鏈圖譜–資訊圖產業
- 基於LLM Graph Transformer的知識圖譜構建技術研究:LangChain框架下轉換機制實踐ORMLangChain框架
- 知識圖譜丨知識圖譜賦能企業數字化轉型
- TiDB 在轉轉的業務實戰TiDB
- 實踐法(轉載)
- 圖資料庫在中國移動金融風控的落地應用資料庫
- Flink 在風控場景實時特徵落地實戰特徵
- 機器之心轉載 | 知識圖譜從哪裡來:實體關係抽取的現狀與未來
- 關於程式設計風格的討論 (轉)程式設計
- 貝葉斯統計和因果推斷在轉轉估價中的落地實踐
- 圖資料和知識圖譜,數字化轉型的新引擎
- CPA二十--關聯方關係的披露要求(轉載)
- 實踐中的增量計劃 (轉)
- InteractiveGraph 實現酷炫關係圖譜之前瞻