领域应用 | 知识图谱的技术与应用
本文轉載自公眾號：貪心科技。
?? ? ? ??
作者 | 李文哲，人工智能、知識圖譜領域專家
導讀：從一開始的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年時間里，知識圖譜技術會普及到各個領域當中。
很多細節性的內容很難在一篇文章里面面俱到、如果想對知識圖譜領域有更全面的了解，并且快速開發出一款可落地的知識圖譜產品，可以參考我近期推出的《知識圖譜技術與應用》課程。在課程里，我會詳細地給大家介紹怎么從零開始一步步搭建完整的知識圖譜系統，并把每一個細節中遇到的問題以及坑給大家講解。
課程匯集了多年在知識圖譜一線的實踐經驗，可以幫助學員快速地對知識圖譜入門。不管是研發、工程師、產品經理還是其他崗位的人或者學生，通過本課程的學習都會對工業界的知識圖譜實踐有更清晰的認識，并且通過一些小的實踐作業讓學員對知識圖譜的構建有跟更深入的理解。本課程不需要任何AI背景。
本課程包含： 完整案例的講解、簡單的實戰練習、作業、過程中所涉及到的算法以及實現等。 不包含：語義網絡相關的理論、RDF、以及Spark, Hadoop等大數據平臺技術。?
OpenKG.CN
中文開放知識圖譜（簡稱OpenKG.CN）旨在促進中文知識圖譜數據的開放與互聯，促進知識圖譜和語義技術的普及和廣泛應用。
點擊閱讀原文，進入 OpenKG 博客。
總結
以上是生活随笔為你收集整理的领域应用 | 知识图谱的技术与应用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 机器学习算法优缺点改进总结
- 下一篇： 新词发现简介