知識圖譜構建（入門）

參考：http://www.datagrand.com/blog/knowledge-map.html

1、什麼是知識圖譜？

知識圖譜是由 Google 公司在 2012 年提出來的一個新的概念。從學術的角度，咱們能夠對知識圖譜給一個這樣的定義：「知識圖譜本質上是語義網絡（Semantic Network）的知識庫」。但這有點抽象，因此換個角度，從實際應用的角度出發其實能夠簡單地把知識圖譜理解成多關係圖（Multi-relational Graph）。

二. 知識圖譜的表示

知識圖譜應用的前提是已經構建好了知識圖譜，也能夠把它認爲是一個知識庫。這也是爲何它能夠用來回答一些搜索相關問題的緣由，好比在 Google 搜索引擎裏輸入「Who is the wife of Bill Gates?」，咱們直接能夠獲得答案 -「Melinda Gates」。這是由於咱們在系統層面上已經建立好了一個包含「Bill Gates」和「Melinda Gates」的實體以及他倆之間關係的知識庫。因此，當咱們執行搜索的時候，就能夠經過關鍵詞提取（」Bill Gates」, 「Melinda Gates」, 「wife」）以及知識庫上的匹配能夠直接得到最終的答案。這種搜索方式跟傳統的搜索引擎是不同的，一個傳統的搜索引擎它返回的是網頁、而不是最終的答案，因此就多了一層用戶本身篩選並過濾信息的過程。

3、知識抽取

知識圖譜的構建是後續應用的基礎，並且構建的前提是須要把數據從不一樣的數據源中抽取出來。對於垂直領域的知識圖譜來講，它們的數據源主要來自兩種渠道：一種是業務自己的數據，這部分數據一般包含在公司內的數據庫表並以結構化的方式存儲；另外一種是網絡上公開、抓取的數據，這些數據一般是以網頁的形式存在因此是非結構化的數據。

前者通常只須要簡單預處理便可以做爲後續 AI 系統的輸入，但後者通常須要藉助於天然語言處理等技術來提取出結構化信息。好比在上面的搜索例子裏，Bill Gates 和 Malinda Gate 的關係就能夠從非結構化數據中提煉出來，好比維基百科等數據源。

信息抽取的難點在於處理非結構化數據。在下面的圖中，咱們給出了一個實例。左邊是一段非結構化的英文文本，右邊是從這些文本中抽取出來的實體和關係。在構建相似的圖譜過程中，主要涉及如下幾個方面的天然語言處理技術：

a. 實體命名識別（Name Entity Recognition）

b. 關係抽取（Relation Extraction）

c. 實體統一（Entity Resolution）

d. 指代消解（Coreference Resolution）（c,d難度更大）

 

4、知識圖譜的存儲

知識圖譜主要有兩種存儲方式：一種是基於 RDF 的存儲；另外一種是基於圖數據庫的存儲。它們之間的區別以下圖所示。RDF 一個重要的設計原則是數據的易發佈以及共享，圖數據庫則把重點放在了高效的圖查詢和搜索上。其次，RDF 以三元組的方式來存儲數據並且不包含屬性信息，但圖數據庫通常以屬性圖爲基本的表示形式，因此實體和關係能夠包含屬性，這就意味着更容易表達現實的業務場景。根據最新的統計（2018 年上半年），圖數據庫仍然是增加最快的存儲系統。相反，關係型數據庫的增加基本保持在一個穩定的水平。同時，咱們也列出了經常使用的圖數據庫系統以及他們最新使用狀況的排名。 其中 Neo4j 系統目前還是使用率最高的圖數據庫，它擁有活躍的社區，並且系統自己的查詢效率高，但惟一的不足就是不支持準分佈式。相反，OrientDB 和 JanusGraph（原 Titan）支持分佈式，但這些系統相對較新，社區不如 Neo4j 活躍，這也就意味着使用過程中不可避免地會遇到一些刺手的問題。若是選擇使用 RDF 的存儲系統，Jena 或許一個比較不錯的選擇。

5、 金融知識圖譜的搭建

接下來咱們看一個實際的具體案例，講解怎麼一步步搭建可落地的金融風控領域的知識圖譜系統。 首先須要說明的一點是，有可能很多人認爲搭建一個知識圖譜系統的重點在於算法和開發。但事實並非想象中的那樣，其實最重要的核心在於對業務的理解以及對知識圖譜自己的設計，這就相似於對於一個業務系統，數據庫表的設計尤爲關鍵，並且這種設計絕對離不開對業務的深刻理解以及對將來業務場景變化的預估。 固然，在這裏咱們先不討論數據的重要性。一個完整的知識圖譜的構建包含如下幾個步驟：

1. 定義具體的業務問題  

2. 數據的收集 & 預處理    實體對齊

3. 知識圖譜的設計  

4. 把數據存入知識圖譜  

5. 上層應用的開發，以及系統的評估。

6.1 定義具體的業務問題

在 P2P 網貸環境下，最核心的問題是風控，也就是怎麼去評估一個借款人的風險。在線上的環境下，欺詐風險尤爲爲嚴重，並且不少這種風險隱藏在複雜的關係網絡之中，並且知識圖譜正好是爲這類問題所設計的，因此咱們「有可能」期待它能在欺詐，這個問題上帶來一些價值。在進入下一個話題的討論以前，要明確的一點是，對於自身的業務問題到底需不須要知識圖譜系統的支持。由於在不少的實際場景，即便對關係的分析有必定的需求，實際上也能夠利用傳統數據庫來完成分析的。因此爲了不使用知識圖譜而選擇知識圖譜，以及更好的技術選型，如下給出了幾點總結，供參考。

6.2 數據收集 & 預處理

下一步就是要肯定數據源以及作必要的數據預處理。針對於數據源，咱們須要考慮如下幾點：1. 咱們已經有哪些數據？ 2. 雖然如今沒有，但有可能拿到哪些數據？ 3.  其中哪部分數據能夠用來下降風險？ 4. 哪部分數據能夠用來構建知識圖譜？在這裏須要說明的一點是，並非全部跟反欺詐相關的數據都必需要進入知識圖譜，對於這部分的一些決策原則在接下來的部分會有比較詳細的介紹。

對於反欺詐，有幾個數據源是咱們很容易想獲得的，包括用戶的基本信息、行爲數據、運營商數據、網絡上的公開信息等等。假設咱們已經有了一個數據源的列表清單，則下一步就要看哪些數據須要進一步的處理，好比對於非結構化數據咱們或多或少都須要用到跟天然語言處理相關的技術。 用戶填寫的基本信息基本上會存儲在業務表裏，除了個別字段須要進一步處理，不少字段則直接能夠用於建模或者添加到知識圖譜系統裏。對於行爲數據來講，咱們則須要經過一些簡單的處理，並從中提取有效的信息好比「用戶在某個頁面停留時長」等等。 對於網絡上公開的網頁數據，則須要一些信息抽取相關的技術。

舉個例子，對於用戶的基本信息，咱們極可能須要以下的操做。一方面，用戶信息好比姓名、年齡、學歷等字段能夠直接從結構化數據庫中提取並使用。但另外一方面，對於填寫的公司名來講，咱們有可能須要作進一步的處理。好比部分用戶填寫「北京貪心科技有限公司」，另一部分用戶填寫「北京望京貪心科技有限公司」，其實指向的都是同一家公司。因此，這時候咱們須要作公司名的對齊，用到的技術細節能夠參考前面講到的實體對齊技術。

6.3 知識圖譜的設計

圖譜的設計是一門藝術，不只要對業務有很深的理解、也須要對將來業務可能的變化有必定預估，從而設計出最貼近現狀而且性能高效的系統。在知識圖譜設計的問題上，咱們確定會面臨如下幾個常見的問題：1. 須要哪些實體、關係和屬性？ 2.  哪些屬性能夠作爲實體，哪些實體能夠做爲屬性？ 3. 哪些信息不須要放在知識圖譜中？

基於這些常見的問題，咱們從以往的設計經驗中抽象出了一系列的設計原則。這些設計原則就相似於傳統數據庫設計中的範式，來引導相關人員設計出更合理的知識圖譜系統，同時保證系統的高效性。接下來，咱們舉幾個簡單的例子來講明其中的一些原則。 首先是，業務原則（Business Principle），它的含義是 「一切要從業務邏輯出發，而且經過觀察知識圖譜的設計也很容易推測其背後業務的邏輯，並且設計時也要想好將來業務可能的變化」。

舉個例子，能夠觀察一下下面這個圖譜，並試問本身背後的業務邏輯是什麼。經過一番觀察，其實也很難看出到底業務流程是什麼樣的。作個簡單的解釋，這裏的實體 -「申請」意思就是 application，若是對這個領域有所瞭解，其實就是進件實體。在下面的圖中，申請和電話實體之間的「has_phone」，「parent phone」是什麼意思呢？

接下來再看一下下面的圖，跟以前的區別在於咱們把申請人從原有的屬性中抽取出來並設置成了一個單獨的實體。在這種狀況下，整個業務邏輯就變得很清晰，咱們很容易看出張三申請了兩個貸款，並且張三擁有兩個手機號，在申請其中一個貸款的時候他填寫了父母的電話號。總而言之，一個好的設計很容易讓人看到業務自己的邏輯。接下來再看一個原則叫作效率原則（Efficiency Principle）。 效率原則讓知識圖譜儘可能輕量化、並決定哪些數據放在知識圖譜，哪些數據不須要放在知識圖譜。在這裏舉一個簡單的類比，在經典的計算機存儲系統中，咱們常常會談論到內存和硬盤，內存做爲高效的訪問載體，做爲全部程序運行的關鍵。這種存儲上的層次結構設計源於數據的局部性 -「locality」，也就是說常常被訪問到的數據集中在某一個區塊上，因此這部分數據能夠放到內存中來提高訪問的效率。 相似的邏輯也能夠應用到知識圖譜的設計上：咱們把經常使用的信息存放在知識圖譜中，把那些訪問頻率不高，對關係分析可有可無的信息放在傳統的關係型數據庫當中。 效率原則的核心在於把知識圖譜設計成小而輕的存儲載體。

好比在下面的知識圖譜中，咱們徹底能夠把一些信息好比「年齡」，「家鄉」放到傳統的關係型數據庫當中，由於這些數據對於：a. 分析關係來講沒有太多做用   b.  訪問頻率低，放在知識圖譜上反而影響效率。

另外，從分析原則（Analytics Principle）的角度，咱們不須要把跟關係分析無關的實體放在圖譜當中；從冗餘原則（Redundancy Principle）的角度，有些重複性信息、高頻信息能夠放到傳統數據庫當中。

6.4 把數據存入知識圖譜

存儲上咱們要面臨存儲系統的選擇，但因爲咱們設計的知識圖譜帶有屬性，圖數據庫能夠做爲首選。但至於選擇哪一個圖數據庫也要看業務量以及對效率的要求。若是數據量特別龐大，則 Neo4j 極可能知足不了業務的需求，這時候不得不去選擇支持準分佈式的系統好比 OrientDB, JanusGraph 等，或者經過效率、冗餘原則把信息存放在傳統數據庫中，從而減小知識圖譜所承載的信息量。 一般來說，對於 10 億節點如下規模的圖譜來講 Neo4j 已經足夠了。

6.5 上層應用的開發

等咱們構建好知識圖譜以後，接下來就要使用它來解決具體的問題。對於風控知識圖譜來講，首要任務就是挖掘關係網絡中隱藏的欺詐風險。從算法的角度來說，有兩種不一樣的場景：一種是基於規則的；另外一種是基於機率的。鑑於目前 AI 技術的現狀，基於規則的方法論仍是在垂直領域的應用中佔據主導地位，但隨着數據量的增長以及方法論的提高，基於機率的模型也將會逐步帶來更大的價值。

6.5.1 基於規則的方法論

首先，咱們來看幾個基於規則的應用，分別是不一致性驗證、基於規則的特徵提取、基於模式的判斷。

不一致性驗證

爲了判斷關係網絡中存在的風險，一種簡單的方法就是作不一致性驗證，也就是經過一些規則去找出潛在的矛盾點。這些規則是以人爲的方式提早定義好的，因此在設計規則這個事情上須要一些業務的知識。好比在下面的這個圖中，李明和李飛兩我的都註明了一樣的公司電話，但實際上從數據庫中判斷這倆人其實在不一樣的公司上班，這就是一個矛盾點。 相似的規則其實能夠有不少，不在這裏一一列出。

基於規則提取特徵

咱們也能夠基於規則從知識圖譜中提取一些特徵，並且這些特徵通常基於深度的搜索好比 2 度，3 度甚至更高維度。好比咱們能夠問一個這樣的問題：「申請人二度關係裏有多少個實體觸碰了黑名單？」，從圖中咱們很容觀察到二度關係中有兩個實體觸碰了黑名單（黑名單由紅色來標記）。等這些特徵被提取以後，通常能夠做爲風險模型的輸入。在此仍是想說明一點，若是特徵並不涉及深度的關係，其實傳統的關係型數據庫則足以知足需求。

基於模式的判斷

這種方法比較適用於找出團體欺詐，它的核心在於經過一些模式來找到有可能存在風險的團體或者子圖（sub-graph），而後對這部分子圖作進一步的分析。 這種模式有不少種，在這裏舉幾個簡單的例子。 好比在下圖中，三個實體共享了不少其餘的信息，咱們能夠看作是一個團體，並對其作進一步的分析。

再好比，咱們也能夠從知識圖譜中找出強連通圖，並把它標記出來，而後作進一步風險分析。強連通圖意味着每個節點均可以經過某種路徑達到其餘的點，也就說明這些節點之間有很強的關係。

6.5.2 基於機率的方法

除了基於規則的方法，也可使用機率統計的方法。 好比社區挖掘、標籤傳播、聚類等技術都屬於這個範疇。 對於這類技術，在本文裏不作詳細的講解，感興趣的讀者能夠參考相關文獻。

社區挖掘算法的目的在於從圖中找出一些社區。對於社區，咱們能夠有多種定義，但直觀上能夠理解爲社區內節點之間關係的密度要明顯大於社區之間的關係密度。下面的圖表示社區發現以後的結果，圖中總共標記了三個不一樣的社區。一旦咱們獲得這些社區以後，就能夠作進一步的風險分析。

因爲社區挖掘是基於機率的方法論，好處在於不須要人爲地去定義規則，特別是對於一個龐大的關係網絡來講，定義規則這事情自己是一件很複雜的事情。

標籤傳播算法的核心思想在於節點之間信息的傳遞。這就相似於，跟優秀的人在一塊兒本身也會逐漸地變優秀是一個道理。由於經過這種關係會不斷地吸收高質量的信息，最後使得本身也會不知不覺中變得更加優秀。具體細節不在這裏作更多解釋。

相比規則的方法論，基於機率的方法的缺點在於：須要足夠多的數據。若是數據量不多，並且整個圖譜比較稀疏（Sparse），基於規則的方法能夠成爲咱們的首選。尤爲是對於金融領域來講，數據標籤會比較少，這也是爲何基於規則的方法論仍是更廣泛地應用在金融領域中的主要緣由。

6.5.3 基於動態網絡的分析

以上全部的分析都是基於靜態的關係圖譜。所謂的靜態關係圖譜，意味着咱們不考慮圖譜結構自己隨時間的變化，只是聚焦在當前知識圖譜結構上。然而，咱們也知道圖譜的結構是隨時間變化的，並且這些變化自己也能夠跟風險有所關聯。

在下面的圖中，咱們給出了一個知識圖譜 T 時刻和 T+1 時刻的結構，咱們很容易看出在這兩個時刻中間，圖譜結構（或者部分結構）發生了很明顯的變化，這其實暗示着潛在的風險。那怎麼去判斷這些結構上的變化呢？ 感興趣的讀者能夠查閱跟「dynamic network mining」相關的文獻。

7、 知識圖譜在其餘行業中的應用

除了金融領域，知識圖譜的應用能夠涉及到不少其餘的行業，包括醫療、教育、證券投資、推薦等等。其實，只要有關係存在，則有知識圖譜可發揮價值的地方。 在這裏簡單舉幾個垂直行業中的應用。

好比對於教育行業，咱們常常談論個性化教育、因材施教的理念。其核心在於理解學生當前的知識體系，並且這種知識體系依賴於咱們所獲取到的數據好比交互數據、評測數據、互動數據等等。爲了分析學習路徑以及知識結構，咱們則須要針對於一個領域的概念知識圖譜，簡單來說就是概念拓撲結構。在下面的圖中，咱們給出了一個很是簡單的概念圖譜：好比爲了學習邏輯迴歸則須要先理解線性迴歸；爲了學習 CNN，得對神經網絡有所理解等等。全部對學生的評測、互動分析都離不開概念圖譜這個底層的數據。

在證券領域，咱們常常會關心好比「一個事件發生了，對哪些公司產生什麼樣的影響？」 好比有一個負面消息是關於公司 1 的高管，並且咱們知道公司 1 和公司 2 有種很密切的合做關係，公司 2 有個主營產品是由公司 3 提供的原料基礎上作出來的。

其實有了這樣的一個知識圖譜，咱們很容易回答哪些公司有可能會被此次的負面事件所影響。固然，僅僅是「有可能」，具體會不會有強相關性必須由數據來驗證。因此在這裏，知識圖譜的好處就是把咱們所須要關注的範圍很快給咱們圈定。接下來的問題會更復雜一些，好比既然咱們知道公司 3 有可能被此次事件所影響，那具體影響程度有多大？ 對於這個問題，光靠知識圖譜是很難回答的，必需要有一個影響模型、以及須要一些歷史數據才能在知識圖譜中作進一步推理以及計算。

8、實踐上的幾點建議

首先，知識圖譜是一個比較新的工具，它的主要做用仍是在於分析關係，尤爲是深度的關係。因此在業務上，首先要確保它的必要性，其實不少問題能夠用非知識圖譜的方式來解決。

知識圖譜領域一個最重要的話題是知識的推理。 並且知識的推理是走向強人工智能的必經之路。但很遺憾的，目前不少語義網絡的角度討論的推理技術（好比基於深度學習，機率統計）很難在實際的垂直應用中落地。其實目前最有效的方式仍是基於一些規則的方法論，除非咱們有很是龐大的數據集。

最後，仍是要強調一點，知識圖譜工程自己仍是業務爲重心，以數據爲中心。不要低估業務和數據的重要性。

9、結語

知識圖譜是一個既充滿挑戰並且很是有趣的領域。只要有正確的應用場景，對於知識圖譜所能發揮的價值仍是能夠期待的。我相信在將來不到 2-3 年時間裏，知識圖譜技術會普及到各個領域當中。