參考：http://www.datagrand.com/blog/knowledge-map.html
一、什麼是知識圖譜？
知識圖譜是由 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”）以及知識庫上的比對可以直接獲得最終的答案。這種搜尋方式跟傳統的搜尋引擎是不一樣的，一個傳統的搜尋引擎它傳回的是網頁、而不是最終的答案，是以就多了一層使用者自己篩選并過濾資訊的過程。
三、知識抽取
知識圖譜的建構是後續應用的基礎，而且建構的前提是需要把資料從不同的資料源中抽取出來。對于垂直領域的知識圖譜來說，它們的資料源主要來自兩種管道：一種是業務本身的資料，這部分資料通常包含在公司内的資料庫表并以結構化的方式存儲；另一種是網絡上公開、抓取的資料，這些資料通常是以網頁的形式存在是以是非結構化的資料。
前者一般隻需要簡單預處理即可以作為後續 AI 系統的輸入，但後者一般需要借助于自然語言處理等技術來提取出結構化資訊。比如在上面的搜尋例子裡，Bill Gates 和 Malinda Gate 的關系就可以從非結構化資料中提煉出來，比如***等資料源。
資訊抽取的難點在于處理非結構化資料。在下面的圖中，我們給出了一個執行個體。左邊是一段非結構化的英文文本，右邊是從這些文本中抽取出來的實體和關系。在建構類似的圖譜過程當中，主要涉及以下幾個方面的自然語言處理技術：
a. 實體命名識别（Name Entity Recognition）
b. 關系抽取（Relation Extraction）
c. 實體統一（Entity Resolution）
d. 指代消解（Coreference Resolution）（c,d難度更大）
四、知識圖譜的存儲
知識圖譜主要有兩種存儲方式：一種是基于 RDF 的存儲；另一種是基于圖資料庫的存儲。它們之間的差別如下圖所示。RDF 一個重要的設計原則是資料的易釋出以及共享，圖資料庫則把重點放在了高效的圖查詢和搜尋上。其次，RDF 以三元組的方式來存儲資料而且不包含屬性資訊，但圖資料庫一般以屬性圖為基本的表示形式，是以實體和關系可以包含屬性，這就意味着更容易表達現實的業務場景。
根據最新的統計（2018 年上半年），圖資料庫仍然是增長最快的存儲系統。相反，關系型資料庫的增長基本保持在一個穩定的水準。同時，我們也列出了常用的圖資料庫系統以及他們最新使用情況的排名。 其中 Neo4j 系統目前仍是使用率最高的圖資料庫，它擁有活躍的社群，而且系統本身的查詢效率高，但唯一的不足就是不支援準分布式。相反，OrientDB 和 JanusGraph（原 Titan）支援分布式，但這些系統相對較新，社群不如 Neo4j 活躍，這也就意味着使用過程當中不可避免地會遇到一些刺手的問題。如果選擇使用 RDF 的存儲系統，Jena 或許一個比較不錯的選擇。
五、 金融知識圖譜的搭建
接下來我們看一個實際的具體案例，講解怎麼一步步搭建可落地的金融風控領域的知識圖譜系統。 首先需要說明的一點是，有可能不少人認為搭建一個知識圖譜系統的重點在于算法和開發。但事實并不是想象中的那樣，其實最重要的核心在于對業務的了解以及對知識圖譜本身的設計，這就類似于對于一個業務系統，資料庫表的設計尤其關鍵，而且這種設計絕對離不開對業務的深入了解以及對未來業務場景變化的預估。 當然，在這裡我們先不讨論資料的重要性。
一個完整的知識圖譜的建構包含以下幾個步驟：
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”相關的文獻。
七、 知識圖譜在其他行業中的應用
除了金融領域，知識圖譜的應用可以涉及到很多其他的行業，包括醫療、教育、證券投資、推薦等等。其實，隻要有關系存在，則有知識圖譜可發揮價值的地方。 在這裡簡單舉幾個垂直行業中的應用。
比如對于教育行業，我們經常談論個性化教育、因材施教的理念。其核心在于了解學生目前的知識體系，而且這種知識體系依賴于我們所擷取到的資料比如互動資料、評測資料、互動資料等等。為了分析學習路徑以及知識結構，我們則需要針對于一個領域的概念知識圖譜，簡單來講就是概念拓撲結構。在下面的圖中，我們給出了一個非常簡單的概念圖譜：比如為了學習邏輯回歸則需要先了解線性回歸；為了學習 CNN，得對神經網絡有所了解等等。所有對學生的評測、互動分析都離不開概念圖譜這個底層的資料。
在證券領域，我們經常會關心比如“一個事件發生了，對哪些公司産生什麼樣的影響？” 比如有一個負面消息是關于公司 1 的高管，而且我們知道公司 1 和公司 2 有種很密切的合作關系，公司 2 有個主營産品是由公司 3 提供的原料基礎上做出來的。
其實有了這樣的一個知識圖譜，我們很容易回答哪些公司有可能會被這次的負面事件所影響。當然，僅僅是“有可能”，具體會不會有強相關性必須由資料來驗證。是以在這裡，知識圖譜的好處就是把我們所需要關注的範圍很快給我們圈定。接下來的問題會更複雜一些，比如既然我們知道公司 3 有可能被這次事件所影響，那具體影響程度有多大？ 對于這個問題，光靠知識圖譜是很難回答的，必須要有一個影響模型、以及需要一些曆史資料才能在知識圖譜中做進一步推理以及計算。
八、實踐上的幾點建議
首先，知識圖譜是一個比較新的工具，它的主要作用還是在于分析關系，尤其是深度的關系。是以在業務上，首先要確定它的必要性，其實很多問題可以用非知識圖譜的方式來解決。
知識圖譜領域一個最重要的話題是知識的推理。 而且知識的推理是走向強人工智能的必經之路。但很遺憾的，目前很多語義網絡的角度讨論的推理技術（比如基于深度學習，機率統計）很難在實際的垂直應用中落地。其實目前最有效的方式還是基于一些規則的方法論，除非我們有非常龐大的資料集。
最後，還是要強調一點，知識圖譜工程本身還是業務為重心，以資料為中心。不要低估業務和資料的重要性。
九、結語
知識圖譜是一個既充滿挑戰而且非常有趣的領域。隻要有正确的應用場景，對于知識圖譜所能發揮的價值還是可以期待的。我相信在未來不到 2-3 年時間裡，知識圖譜技術會普及到各個領域當中。