知識圖譜是一把開啟智能機器大腦的鑰匙，能夠打開Web 3.0時代的知識寶庫。本文將從知識圖譜的概念、架構、關鍵技術、應用領域以及一些需要注意的問題等方面，帶大家走進知識圖譜的世界。
A knowledge graph consists of a set of interconnected typed entities and their attributes.
知識圖譜本質(zhì)上是語義網(wǎng)絡，是一種基于圖的數(shù)據(jù)結(jié)構，由節(jié)點(Point)和邊(Edge)組成。在知識圖譜里，每個節(jié)點表示現(xiàn)實世界中存在的“實體”，每條邊為實體與實體之間的“關系”。知識圖譜是關系的最有效的表示方式。
通俗地講，知識圖譜就是把所有不同種類的信息（Heterogeneous Information）連接在一起而得到的一個關系網(wǎng)絡。知識圖譜提供了從“關系”的角度去分析問題的能力。
知識圖譜這個概念最早由Google提出，主要是用來優(yōu)化現(xiàn)有的搜索引擎。不同于基于關鍵詞搜索的傳統(tǒng)搜索引擎，知識圖譜可用來更好地查詢復雜的關聯(lián)信息，從語義層面理解用戶意圖，改進搜索質(zhì)量。比如在Google的搜索框里輸入科比的時候，搜索結(jié)果頁面的右側(cè)還會出現(xiàn)科比相關的信息比如出生年月，家庭情況等等。
在知識圖譜里，我們通常用“實體（Entity）”來表達圖里的節(jié)點、用“關系（Relation）”來表達圖里的“邊”。實體指的是現(xiàn)實世界中的事物比如人、地名、概念、公司等，關系則用來表達不同實體之間的某種聯(lián)系，比如人-“居住在”-北京、張三和李四是“朋友”等等。
通過上面這個例子，讀者應該對知識圖譜有了一個初步的印象，其本質(zhì)是為了表示知識，從實際應用的角度出發(fā)其實可以簡單地把知識圖譜理解成多關系圖（Multi-relational Graph）。
那什么叫多關系圖呢？ 圖是由節(jié)點（Vertex）和邊（Edge）來構成，但這些圖通常只包含一種類型的節(jié)點和邊。但相反，多關系圖一般包含多種類型的節(jié)點和多種類型的邊。比如下圖因為圖里包含了多種類型的節(jié)點和邊。這些類型由不同的顏色來標記。
當一個知識圖譜擁有屬性時，我們可以用屬性圖（Property Graph）來表示，如上圖，科比和凡妮莎是夫妻，他們的結(jié)婚時間是2001年到2020年，其中結(jié)婚時間就可以作為關系的屬性，類似的，科比也有自己的屬性，比如性別、出生日期等。這種屬性圖的表達很貼近現(xiàn)實生活中的場景，也可以很好地描述業(yè)務中所包含的邏輯。
除了屬性圖，知識圖譜也可以用RDF來表示，它是由很多的三元組（Triples）來組成。RDF在設計上的主要特點是易于發(fā)布和分享數(shù)據(jù)，但不支持實體或關系擁有屬性，如果非要加上屬性，則在設計上需要做一些修改。目前來看，RDF主要還是用于學術的場景，在工業(yè)界我們更多的還是采用圖數(shù)據(jù)庫（比如用來存儲屬性圖）的方式。
知識圖譜主要有兩種存儲方式：一種是基于RDF的存儲；另一種是基于圖數(shù)據(jù)庫的存儲。RDF一個重要的設計原則是數(shù)據(jù)的易發(fā)布以及共享，圖數(shù)據(jù)庫則把重點放在了高效的圖查詢和搜索上。其次，RDF以三元組的方式來存儲數(shù)據(jù)而且不包含屬性信息，但圖數(shù)據(jù)庫一般以屬性圖為基本的表示形式，所以實體和關系可以包含屬性，這就意味著更容易表達現(xiàn)實的業(yè)務場景。
知識圖譜的體系架構是其指構建模式結(jié)構，如下圖所示。知識圖譜的構建過程需要隨人的認知能力不斷更新迭代。
所謂的靜態(tài)關系圖譜，意味著我們不考慮圖譜結(jié)構本身隨時間的變化，只是聚焦在當前知識圖譜結(jié)構上。然而，我們也知道圖譜的結(jié)構是隨時間變化的。
在下面的圖中，我們給出了一個知識圖譜T時刻和T+1時刻的結(jié)構，我們很容易看出在這兩個時刻中間，圖譜結(jié)構（或者部分結(jié)構）發(fā)生了很明顯的變化。那怎么去判斷這些結(jié)構上的變化呢？ 感興趣的讀者可以關注我，后面會持續(xù)更新知識圖譜相關技術棧，本文先不做過多討論。
回到知識圖譜的體系架構那張圖，知識圖譜的構建是后續(xù)應用的基礎，而且構建的前提是需要把數(shù)據(jù)從不同的數(shù)據(jù)源中抽取出來。對于垂直領域的知識圖譜來說，它們的數(shù)據(jù)源主要來自兩種渠道：一種是業(yè)務本身的數(shù)據(jù)，這部分數(shù)據(jù)通常包含在公司內(nèi)的數(shù)據(jù)庫表并以結(jié)構化的方式存儲；另一種是網(wǎng)絡上公開、抓取的數(shù)據(jù)，這些數(shù)據(jù)通常是以網(wǎng)頁的形式存在所以是半結(jié)構/非結(jié)構化的數(shù)據(jù)。
前者一般只需要簡單預處理即可以作為后續(xù)AI系統(tǒng)的輸入，但后者一般需要借助于自然語言處理等技術來提取出結(jié)構化信息。比如在上面的搜索例子里，科比和凡妮莎的關系就可以從非結(jié)構化數(shù)據(jù)中提煉出來，比如維基百科等數(shù)據(jù)源。
信息抽取的難點在于處理非結(jié)構化數(shù)據(jù)。從一段非結(jié)構化的文本中，需要抽取出實體、關系和屬性。例如下圖是從維基百科拿到的科比文本信息：
要從海量文字中，構建出類似文章開頭的那種知識圖譜，需要涉及幾個方面的自然語言處理技術：
實體命名識別（Name Entity Recognition）
關系抽取（Relation Extraction）
實體統(tǒng)一（Entity Resolution）
指代消解（Coreference Resolution）
?首先是實體命名識別，就是從文本里提取出實體并對每個實體做分類/打標簽：比如從上述文本里，我們可以提取出實體-“科比·布萊恩特”，并標記實體類型為 “人”；我們也可以從中提取出“賓夕法尼亞洲費城”，并標記實體類型為“位置”。
這種過程稱之為實體命名識別，這是一項相對比較成熟的技術，有一些現(xiàn)成的工具可以用來做這件事情。其次，我們可以通過關系抽取技術，把實體間的關系從文本中提取出來，比如實體“科比”和“賓夕法尼亞洲費城”之間的關系為“出生于”等等。
?另外，在實體命名識別和關系抽取過程中，有兩個比較棘手的問題：一個是實體統(tǒng)一，也就是說有些實體寫法上不一樣，但其實是指向同一個實體。比如“科比·比恩·布萊恩特”和“科比”表面上是不同的字符串，但其實指的都是科比這個人，需要合并。
實體統(tǒng)一不僅可以減少實體的種類，也可以降低圖譜的稀疏性（Sparsity）；另一個問題是指代消解，也是文本中出現(xiàn)的“他”, “它”, “她”這些詞到底指向哪個實體。
實體統(tǒng)一和指代消解問題相對于前兩個問題更具有挑戰(zhàn)性。
大規(guī)模知識庫的構建與應用需要多種智能信息處理技術的支持。通過知識抽取技術，可以從一些公開的半結(jié)構化、非結(jié)構化的數(shù)據(jù)中提取出實體、關系、屬性等知識要素。
通過知識融合，可消除實體、關系、屬性等指稱項與事實對象之間的歧義，形成高質(zhì)量的知識庫。知識推理則是在已有的知識庫基礎上進一步挖掘隱含的知識，從而豐富、擴展知識庫。分布式的知識表示形成的綜合向量對知識庫的構建、推理、融合以及應用均具有重要的意義。
作為科普性的文章，本文的目的是帶大家入門，關于知識圖譜更深入的知識抽取、知識表示、知識融合以及知識推理技術，篇幅有限，將作為下一篇的重點內(nèi)容，供大家參考。
首先需要說明的一點是，搭建一個知識圖譜系統(tǒng)最重要的核心在于對業(yè)務的理解以及對知識圖譜本身的設計，這就類似于對于一個業(yè)務系統(tǒng)，數(shù)據(jù)庫表的設計尤其關鍵，而且這種設計絕對離不開對業(yè)務的深入理解以及對未來業(yè)務場景變化的預估。 當然，在這里我們先不討論數(shù)據(jù)的重要性。
一個完整的知識圖譜的構建包含以下幾個步驟：
定義具體的業(yè)務問題
數(shù)據(jù)的收集 & 預處理
知識圖譜的設計
把數(shù)據(jù)存入知識圖譜
上層應用的開發(fā)，以及系統(tǒng)的評估。
對于定義具體業(yè)務問題，要明確的一點是，對于自身的業(yè)務問題到底需不需要知識圖譜系統(tǒng)的支持。因為在很多的實際場景，即使對關系的分析有一定的需求，實際上也可以利用傳統(tǒng)數(shù)據(jù)庫來完成分析的。所以為了避免使用知識圖譜而選擇知識圖譜，以及更好的技術選型，以下給出了幾點總結(jié)，供參考。
下一步就是要確定數(shù)據(jù)源以及做必要的數(shù)據(jù)預處理。在這里我只說明的一點，并不是所有相關的數(shù)據(jù)都必須要進入知識圖譜，對于這部分的一些決策原則在后續(xù)的文章中會有比較詳細的介紹。
知識圖譜的設計是門藝術，作為程序媛，我把它交給更專業(yè)的人員。存儲上我們要面臨存儲系統(tǒng)的選擇，但由于我們設計的知識圖譜帶有屬性，圖數(shù)據(jù)庫可以作為首選。但至于選擇哪個圖數(shù)據(jù)庫也要看業(yè)務量以及對效率的要求。
如果數(shù)據(jù)量特別龐大，則Neo4j很可能滿足不了業(yè)務的需求，這時候不得不去選擇支持準分布式的系統(tǒng)比如OrientDB, JanusGraph等，或者通過效率、冗余原則把信息存放在傳統(tǒng)數(shù)據(jù)庫中，從而減少知識圖譜所承載的信息量。 通常來講，對于10億節(jié)點以下規(guī)模的圖譜來說Neo4j已經(jīng)足夠了。
做完這些，就可以來到我們最熟悉的環(huán)節(jié)，進行應用的開發(fā)（擼代碼）了。
知識圖譜應用的前提是已經(jīng)構建好了知識圖譜，也可以把它認為是一個知識庫。當我們執(zhí)行搜索的時候，就可以通過關鍵詞提取以及知識庫上的匹配可以直接獲得最終的答案。
這種搜索方式跟傳統(tǒng)的搜索引擎是不一樣的，一個傳統(tǒng)的搜索引擎它返回的是網(wǎng)頁、而不是最終的答案，所以就多了一層用戶自己篩選并過濾信息的過程。
知識圖譜的應用主要集中在搜索與推薦領域：
在語義搜索這一塊，知識圖譜的搜索不同于常規(guī)的搜索，常規(guī)的搜索是根據(jù)keyword找到對應的網(wǎng)頁集合，然后通過page rank等算法去給網(wǎng)頁集合內(nèi)的網(wǎng)頁進行排名，然后展示給用戶；基于知識圖譜的搜索是在已有的圖譜知識庫中遍歷知識，然后將查詢到的知識返回給用戶，通常如果路徑正確，查詢出來的知識只有1個或幾個，相當精準。
問答系統(tǒng)這一塊，系統(tǒng)同樣會首先在知識圖譜的幫助下對用戶使用自然語言提出的問題進行語義分析和語法分析，進而將其轉(zhuǎn)化成結(jié)構化形式的查詢語句，然后在知識圖譜中查詢答案。
首先，知識圖譜是一個比較新的工具，它的主要作用還是在于分析關系，尤其是深度的關系。所以在業(yè)務上，首先要確保它的必要性，其實很多問題可以用非知識圖譜的方式來解決。
知識圖譜領域一個最重要的話題是知識的推理。而且知識的推理是走向強人工智能的必經(jīng)之路。但很遺憾的，目前很多語義網(wǎng)絡的角度討論的推理技術（比如基于深度學習，概率統(tǒng)計）很難在實際的垂直應用中落地。其實目前最有效的方式還是基于一些規(guī)則的方法論，除非我們有非常龐大的數(shù)據(jù)集。
最后，還是要強調(diào)一點，知識圖譜工程本身還是業(yè)務為重心，以數(shù)據(jù)為中心。不要低估業(yè)務和數(shù)據(jù)的重要性。如果本篇對你有幫助，點個贊互相鼓勵一下吧！
參考：
《知識圖譜技術綜述》 徐增林, 盛泳潘, 賀麗榮, 王雅芳
知識圖譜基礎（一）-什么是知識圖譜
這是一份通俗易懂的知識圖譜技術與應用指南
作者：臧遠慧
簡介：就職于中科星圖股份有限公司（北京），研發(fā)部后端技術組。個人擅長 Python/Java 開發(fā)，了解前端基礎；熟練掌握 MySQL，MongoDB，了解 Redis；熟悉 Linux 開發(fā)環(huán)境，掌握 Shell 編程，有良好的 Git 源碼管理習慣；精通 Nginx ，F(xiàn)lask、Swagger 開發(fā)框架；有 Docker+Kubernetes 云服務開發(fā)經(jīng)驗。對人工智能、云原生技術有較大的興趣。
編輯：陶家龍
征稿：有投稿、尋求報道意向技術人請聯(lián)絡 editor@51cto.com
聯(lián)系客服
