從一開始的Google搜尋，到現在的聊天機器人、大資料風控、證券投資、智慧醫療、自適應教育、推薦系統，無一不跟知識圖譜相關。它在技術領域的熱度也在逐年上升。 本文以通俗易懂的方式來講解知識圖譜相關的知識、尤其對從零開始搭建知識圖譜過程當中需要經歷的步驟以及每個階段需要考慮的問題都給予了比較詳細的解釋。 對於讀者，我們不要求有任何AI相關的背景知識。
目錄：
概論
什麼是知識圖譜
知識圖譜的表示
知識抽取
知識圖譜的儲存
金融知識圖譜的搭建
定義具體的業務問題
資料收集 & 預處理
知識圖譜的設計
把資料存入知識圖譜
上層應用的開發
知識圖譜在其他行業中的應用
實踐上的幾點建議
結語
1. 概論
隨著移動網際網路的發展，萬物互聯成為了可能，這種互聯所產生的資料也在爆發式地增長，而且這些資料恰好可以作為分析關係的有效原料。如果說以往的智慧分析專注在每一個個體上，在移動網際網路時代則除了個體，這種個體之間的關係也必然成為我們需要深入分析的很重要一部分。 在一項任務中，只要有關係分析的需求，知識圖譜就“有可能”派的上用場。
2. 什麼是知識圖譜？
知識圖譜是由Google公司在2012年提出來的一個新的概念。從學術的角度，我們可以對知識圖譜給一個這樣的定義：“知識圖譜本質上是語義網絡（Semantic Network）的知識庫”。但這有點抽象，所以換個角度，從實際應用的角度出發其實可以簡單地把知識圖譜理解成多關係圖（Multi-relational Graph）。
那什麼叫多關係圖呢？ 學過資料結構的都應該知道什麼是圖（Graph）。圖是由節點（Vertex）和邊（Edge）來構成，但這些圖通常只包含一種型別的節點和邊。但相反，多關係圖一般包含多種型別的節點和多種型別的邊。比如左下圖表示一個經典的圖結構，右邊的圖則表示多關係圖，因為圖裡包含了多種型別的節點和邊。這些型別由不同的顏色來標記。
在知識圖譜裡，我們通常用“實體（Entity）”來表達圖裡的節點、用“關係（Relation）”來表達圖裡的“邊”。實體指的是現實世界中的事物比如人、地名、概念、藥物、公司等，關係則用來表達不同實體之間的某種聯絡，比如人-“居住在”-北京、張三和李四是“朋友”、邏輯迴歸是深度學習的“先導知識”等等。
現實世界中的很多場景非常適合用知識圖譜來表達。 比如一個社交網路圖譜裡，我們既可以有“人”的實體，也可以包含“公司”實體。人和人之間的關係可以是“朋友”，也可以是“同事”關係。人和公司之間的關係可以是“現任職”或者“曾任職”的關係。 類似的，一個風控知識圖譜可以包含“電話”、“公司”的實體，電話和電話之間的關係可以是“通話”關係，而且每個公司它也會有固定的電話。
3. 知識圖譜的表示
知識圖譜應用的前提是已經構建好了知識圖譜，也可以把它認為是一個知識庫。這也是為什麼它可以用來回答一些搜尋相關問題的原因，比如在Google搜尋引擎裡輸入“Who is the wife of Bill Gates?”，我們直接可以得到答案-“Melinda Gates”。這是因為我們在系統層面上已經建立好了一個包含“Bill Gates”和“Melinda Gates”的實體以及他倆之間關係的知識庫。所以，當我們執行搜尋的時候，就可以透過關鍵詞提取（"Bill Gates", "Melinda Gates", "wife"）以及知識庫上的匹配可以直接獲得最終的答案。這種搜尋方式跟傳統的搜尋引擎是不一樣的，一個傳統的搜尋引擎它返回的是網頁、而不是最終的答案，所以就多了一層使用者自己篩選並過濾資訊的過程。
在現實世界中，實體和關係也會擁有各自的屬性，比如人可以有“姓名”和“年齡”。當一個知識圖譜擁有屬性時，我們可以用屬性圖（Property Graph）來表示。下面的圖表示一個簡單的屬性圖。李明和李飛是父子關係，並且李明擁有一個138開頭的電話號，這個電話號開通時間是2018年，其中2018年就可以作為關係的屬性。類似的，李明本人也帶有一些屬性值比如年齡為25歲、職位是總經理等。
這種屬性圖的表達很貼近現實生活中的場景，也可以很好地描述業務中所包含的邏輯。除了屬性圖，知識圖譜也可以用RDF來表示，它是由很多的三元組（Triples）來組成。RDF在設計上的主要特點是易於釋出和分享資料，但不支援實體或關係擁有屬性，如果非要加上屬性，則在設計上需要做一些修改。目前來看，RDF主要還是用於學術的場景，在工業界我們更多的還是採用圖資料庫（比如用來儲存屬性圖）的方式。感興趣的讀者可以參考RDF的相關文獻，在文字里不多做解釋。
4. 知識抽取
知識圖譜的構建是後續應用的基礎，而且構建的前提是需要把資料從不同的資料來源中抽取出來。對於垂直領域的知識圖譜來說，它們的資料來源主要來自兩種渠道：一種是業務本身的資料，這部分資料通常包含在公司內的資料庫表並以結構化的方式儲存；另一種是網路上公開、抓取的資料，這些資料通常是以網頁的形式存在所以是非結構化的資料。
前者一般只需要簡單預處理即可以作為後續AI系統的輸入，但後者一般需要藉助於自然語言處理等技術來提取出結構化資訊。比如在上面的搜尋例子裡，Bill Gates和Malinda Gate的關係就可以從非結構化資料中提煉出來，比如維基百科等資料來源。
資訊抽取的難點在於處理非結構化資料。在下面的圖中，我們給出了一個例項。左邊是一段非結構化的英文文字，右邊是從這些文字中抽取出來的實體和關係。在構建類似的圖譜過程當中，主要涉及以下幾個方面的自然語言處理技術：
a. 實體命名識別（Name Entity Recognition）
b. 關係抽取（Relation Extraction）
c. 實體統一（Entity Resolution）
d. 指代消解（Coreference Resolution）
下面針對每一項技術解決的問題做簡單的描述，以至於這些是具體怎麼實現的，不在這裡一一展開，感興趣的讀者可以查閱相關資料，或者學習我的課程。
首先是實體命名識別，就是從文字里提取出實體並對每個實體做分類/打標籤：比如從上述文字里，我們可以提取出實體-“NYC”，並標記實體型別為 “Location”；我們也可以從中提取出“Virgil's BBQ”，並標記實體型別為“Restarant”。這種過程稱之為實體命名識別，這是一項相對比較成熟的技術，有一些現成的工具可以用來做這件事情。其次，我們可以透過關係抽取技術，把實體間的關係從文字中提取出來，比如實體“hotel”和“Hilton property”之間的關係為“in”；“hotel”和“Time Square”的關係為“near”等等。
另外，在實體命名識別和關係抽取過程中，有兩個比較棘手的問題：一個是實體統一，也就是說有些實體寫法上不一樣，但其實是指向同一個實體。比如“NYC”和“New York”表面上是不同的字串，但其實指的都是紐約這個城市，需要合併。實體統一不僅可以減少實體的種類，也可以降低圖譜的稀疏性（Sparsity）；另一個問題是指代消解，也是文字中出現的“it”, “he”, “she”這些詞到底指向哪個實體，比如在本文裡兩個被標記出來的“it”都指向“hotel”這個實體。
實體統一和指代消解問題相對於前兩個問題更具有挑戰性。
5. 知識圖譜的儲存
知識圖譜主要有兩種儲存方式：一種是基於RDF的儲存；另一種是基於圖資料庫的儲存。它們之間的區別如下圖所示。RDF一個重要的設計原則是資料的易釋出以及共享，圖資料庫則把重點放在了高效的圖查詢和搜尋上。其次，RDF以三元組的方式來儲存資料而且不包含屬性資訊，但圖資料庫一般以屬性圖為基本的表示形式，所以實體和關係可以包含屬性，這就意味著更容易表達現實的業務場景。
根據最新的統計（2018年上半年），圖資料庫仍然是增長最快的儲存系統。相反，關係型資料庫的增長基本保持在一個穩定的水平。同時，我們也列出了常用的圖資料庫系統以及他們最新使用情況的排名。 其中Neo4j系統目前仍是使用率最高的圖資料庫，它擁有活躍的社群，而且系統本身的查詢效率高，但唯一的不足就是不支援準分散式。相反，OrientDB和JanusGraph（原Titan）支援分散式，但這些系統相對較新，社群不如Neo4j活躍，這也就意味著使用過程當中不可避免地會遇到一些刺手的問題。如果選擇使用RDF的儲存系統，Jena或許一個比較不錯的選擇。
6. 金融知識圖譜的搭建
接下來我們看一個實際的具體案例，講解怎麼一步步搭建可落地的金融風控領域的知識圖譜系統。 首先需要說明的一點是，有可能不少人認為搭建一個知識圖譜系統的重點在於演算法和開發。但事實並不是想象中的那樣，其實最重要的核心在於對業務的理解以及對知識圖譜本身的設計，這就類似於對於一個業務系統，資料庫表的設計尤其關鍵，而且這種設計絕對離不開對業務的深入理解以及對未來業務場景變化的預估。 當然，在這裡我們先不討論資料的重要性。
一個完整的知識圖譜的構建包含以下幾個步驟：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年時間裡，知識圖譜技術會普及到各個領域當中。
很多細節性的內容很難在一篇文章裡面面俱到、如果想對知識圖譜領域有更全面的瞭解，並且快速開發出一款可落地的知識圖譜產品，可以參考我近期推出的《知識圖譜技術與應用》課程。在課程裡，我會詳細地給大家介紹怎麼從零開始一步步搭建完整的知識圖譜系統，並把每一個細節中遇到的問題以及坑給大家講解。
對文章內容有任何疑問的讀者可新增本文作者微信（liwenzhe595675）溝通交流。