知識圖譜在風控的應用

本文將主要討論知識圖譜在風控領域的圖譜構建過程。enjoy~

知识图谱在风控的应用

一. 知識圖譜和金融領域簡述

什麼是知識圖譜?

借鑑其中一個理解:

知識圖譜主要的目標是用來描述真實世界中間存在的各種實體和概念,以及它們之間的關聯關係。

具體理論知識就不在此贅述,對於這個抽象的概念會有一篇文章來列舉一個代表性的例子。

知識圖譜起源於語義網絡,最初由Google提出用與優化搜索結果,發展至今已經應用於各個垂直化領域。從商業概念上,知識圖譜可分為“通用知識圖譜”和“行業知識圖譜”。通用知識圖譜顧名思義是面向全領域的,強調的是“廣度”,比較著名的知識庫有Freebase, Wikidata, Yago, DBPedia等。

行業知識圖譜是面向特定的垂直領域,對於數據有更嚴格的前置數據模式和更準確的準確度要求,強調的是“深度”。兩者之間的主要區別在於前者是“自底向上”構建的知識庫,後者是“自頂向下”構建的知識庫。

知识图谱在风控的应用

金融領域數據是典型的具有”4V”特徵的大數據(數量海量Volume、多結構多維度Variety、價值巨大Value、及時性要求Velocity)。進一步,金融領域是最能把數據變現的行業。金融業類別業非常廣,大類主要包括:銀行類、投資類、保險類等。再小粒度可分為:貨幣、債券、基金、信託等資管計劃、要素市場、徵信貸款等。知識圖譜在金融領域的應用主要包括:風控、徵信、審計、反欺詐、數據分析、自動化報告等,本文主要討論知識圖譜在小微風控的應用。

風控是指如何當項目或企業在一定的風險的環境裡,把風險減至最低的管理過程。它的基本程序包括風險識別、風險估測、風險評價、風險控制和風險管理效果評價等環節。

風險控制的最大兩個分類為企業風險監控和個人貸款審核。企業數據包括:企業基礎數據、投資關係、任職關係、企業專利數據、企業招投標數據、企業招聘數據、企業訴訟數據、企業失信數據、企業新聞數據。個人貸款的數據包括:個人的基本信息、行為信息、信用信息、社交信息、消費信息等。

本文將主要討論知識圖譜在風控領域的圖譜構建過程。

二. 風控的知識圖譜構建

知識圖譜的邏輯結構分為兩個層次:數據層和模式層。

在知識圖譜的數據層,數據如果以『實體-關係-實體』或者『實體-屬性-值』作為基本表達方式,我們把這種表達方式稱為“三元組”,則存儲在圖數據庫中的所有數據將構成龐大的實體關係網絡,形成知識的圖譜。

模式層在數據層之上,是知識圖譜的核心,在模式層存儲的是經過提煉的知識,通常採用本體庫來管理知識圖譜的模式層,藉助本體庫對公理、規則和約束條件的支持能力來規範實體、關係以及實體的類型和屬性等對象之間的聯繫。本體庫在知識圖譜中的地位相當於知識庫的模具,擁有本體庫的知識庫冗餘知識較少。

這裡涉及知識圖譜的另外一個重要概念是“本體( Ontology)”。本體的概念最早起源於哲學領域, 指的是對客觀存在系統的解釋和說明。在眾多概念中,維基上的定義更加通俗些:本體實際上就是對特定領域之中某套概念及其相互之間關係的形式化表達。具體到金融風控領域,本體目的就是對風控領域的知識術語進行分類,同時規定各個分類之間的關係和它們自身的屬性。

本體可以採用人工編輯的方式手動構建(藉助本體編輯軟件),也可以以數據驅動的自動化方式構建本體。自動化構建包含3個階段:實體並列關係相似度計算、實體上下位關係抽取、本體的生成。在領域本體構建的實際工程中,領域本體所涉及的實體類型非常有限(最多數量也不會過百),與其花很高的成本去做自動化,不如人工構建本體。所以本章節也主要討論風控領域的手動本體構建過程。

本體和知識圖譜的構建方法有很多,這裡分享一個在實際工作中初略的知識圖譜構建流程:

  1. 本體庫構建;
  2. 知識圖譜構建;
  3. 知識圖譜應用。
知识图谱在风控的应用

提到知識圖譜通常認為重點在於算法和開發,實際知識圖譜的構建和傳統關係型數據庫的構建情況一樣,重點在於具體業務流程的理解和本體的設計,知識圖譜的構建過程的工作佔比如下:

知识图谱在风控的应用

三. 風控的本體構建

如前所述,構建風控領域知識圖譜的首要工作是構建本體模型,即定義行業的通用概念為實體,以及實體之間的關係。

信貸最核心的主體就是貸款申請者,貸款申請者可能是個人也可能是公司,通過申請者的基本信息、行為信息、經營狀況、社會關係等評估貸款的風險。因此可以列舉信貸相關的核心實體為:人、企業、銀行賬戶、銀行、抵押物、申請事件、訴訟事件等,以及基本信息實體:電話、郵件、地址等。實體與實體之間的關係為 親屬、任職、所有權、事件參與方等。如圖所示為一個簡化版的信貸風控本體模型。

為什麼要將人和公司的電話地址設計為單獨的實體節點,是基於風控的業務關注點,當兩個貸款申請者有相同的電話或者地址時候,可能就是一個需要關注的風險點。把這兩個信息作為單獨的節點,基於圖譜理論,當統計“電話”類型節點的邊數量超過一個就能很方便找出高風險申請者。

本體構建完成後,需要對比實際業務對本體進行驗證,確保本體能夠正確描述當前業務,並且包含了所有的業務流程。

知识图谱在风控的应用

四. 風控的圖譜構建

知識圖譜的構建是圖譜應用的前提,構建的主要工作是把數據從不同的數據源中按照本體模型所規定的規則抽取出來。對於垂直領域的知識圖譜來說,數據的主要來源是是業務本身的數據,其通常是機構自己的私有數據以結構化的形式存儲。通過ETL處理,將數據抽取轉換為圖譜數據。圖譜數據的存儲形式目前有兩種:基於RDF等存儲和圖數據庫存儲。兩者的比較如下所示:

知识图谱在风控的应用

RDF圖數據庫存儲三元組節點和關係擁有屬性符合W3C標準圖的遍歷和擴展方便有標準的推理引擎擁有事務管理數據可移植性高工程化程度高多用於學術場景可視化效果好。

在實際工程應用中主要採用圖庫的方式對知識圖譜進行存儲,當前比較流行的圖數據庫為Neo4j,本篇不再詳細介紹圖數據庫和Neo4j,重點在於如何根據本體將數據映射成為Neo4j要求的數據格式。Neo4j提供了多種加載數據的方式,對於小規模數據(1w – 10w條數據),可以採用加載CSV的方式進行,CSV的格式要求如Neo4j官網的操作手冊所示。

假設數據源是關係型數據庫,其中中有三張表及其字段如下所示,company表中字段“legal_person(法人代表)”和“manager(經理)”是外鍵關聯到person表:

我們要從源數據中抽取出多個實體和多條關係,這裡部分舉例如下:

實體:

person

company

account

bank

phoneNo

address

關係:

person – lsLegalPersonOf -> company

person – lsManagerOf -> company

person – isOwnerOf -> account

account – belongsTo -> bank

person – hasPhoneNo -> phoneNo

company – hasAddress -> address

根據Neo4j的要求將源數據進行ETL處理,映射成為Neo4j要求的CSV格式文件,簡單列舉如下:

person節點:

personId:ID, personName, : LABEL

001, “personA”, person

002, “personB”, person

法人關係:

:START_ID, :END_ID, : LABEL

001, 101, isLegalPersonOf

002, 102, isLegalPersonOf

五. 圖譜的應用

當前,小微貸款和個人小額貸款還處於“蠻荒時代”,甚至出現了各種中介機構通過各種偽造的虛假信息幫助客戶申請貸款。所以對於放貸方而言,借貸風險控制面臨非常巨大的挑戰。

1. 貸款申請方畫像

可以在圖譜中直接搜索某個具體的人名字或者公司名字,獲取該人或者公司的基礎信息畫像,如電話,地址,關聯方的信息。如圖所示:

知识图谱在风控的应用

2. 關聯方探查

通過圖譜可以調查某個人或者某家申請貸款公司的關聯方信息。在貸款審核期間,申請貸款主體的關聯方信息中有借貸糾紛的訴訟事件,擔保方過多等可關注的風險點。在貸款發放後,有時出現貸款方失聯的情況,無法通過申請貸款時提交的信息聯繫到借款方,可以通探尋更“深遠”的關聯方找到失聯的貸款方。

知识图谱在风控的应用

3. 反欺詐調查

在實際場景中,有不少人利用各種渠道而來身份證進行貸款申請。還有公司通過循環轉賬等方式提供虛假的經營流水信息。通過知識圖譜可以識別以上風險點。如多個貸款申請人提供的身份證號嗎不同,但是卻有相同的聯繫電話號嗎或者聯繫地址。銀行作為借貸機構,可以調查申請人賬戶資金往來情況,識別是否存在循環轉賬等異常資金往來信息識別風險點。

在圖譜中,通過條件搜索指定的節點可以篩選調查風險節點,如:“電話號碼”節點的關聯方大於1的節點。

知识图谱在风控的应用

4. 風險指標報告

在風控處理中,貸款風險比率是衡量商業銀行風險最重要的指標之一,主要包括不良貸款比率、貸款加權風險度、貸款分散化比率、不良貸款撥備覆蓋率等。將知識圖譜中貸款人節點和相關指標相結合,設定報警閾值,通過機器學習等技術,找到隱蔽的風險結構,指標特徵,能夠快速找出相關責任方和其關聯方,形成報告供業務人員進行調。

總結

本文主要介紹了知識圖譜在風控中的應用和風控領域知識圖譜的構建方法。知識圖譜的構建前提是清晰的業務場景和良好的數據治理。很多著名的知識圖譜構建案例中,大部分時間都是用在數據治理和數據映射上。借用一句別處看來的話:

A “graph”—that understands real-world entities and their relationships to one another: things, not strings。

本文由 @Eric_Xie 原創發佈於人人都是產品經理。未經許可,禁止轉載。

題圖來自 Pixabay,基於 CC0 協議


分享到:


相關文章: