【51CTO.com原創稿件】在面向對象的時代裏，我們常說萬物皆對象，之前我們只是來分析對象的個體，隨着互聯網和社交網絡的發展，對象與對象之間的聯繫變得越來越緊密，我們把一個對象稱之爲一個實體。

我們現在對於實體之間關係的分析變得尤爲重要，我們可以使用知識圖譜相關技術，來挖掘實體之間的關係，從而找到其中的商業價值，打造自己的知識圖譜應用。

2018 年 11 月 30 日-12 月 1 日，由 51CTO 主辦的 WOT 全球人工智能技術峯會在北京粵財 JW 萬豪酒店隆重舉行。

本次峯會以人工智能爲主題，金山辦公 AI 領域專家黃鴻波在業務實踐專場與來賓分享"知識圖譜在企業中的落地"的主題演講。

本文將按照如下四個層次向大家介紹知識圖譜在企業中的落地情況：

• 知識圖譜發展展望，包括知識圖譜的定義和實現方式。
• 知識圖譜常見應用場景，包括如何來應用和具體的應用場景。
• 知識圖譜圖數據庫選型，包括選型比較和經驗分享。
• 知識圖譜落地，包括落地方案的制定和從無到有的圖譜架構。

知識圖譜發展展望

我們先來看看知識圖譜的發展歷史：

• 50 年代到 70 年代，符號邏輯、神經網絡、LISP(List Processing語言)、還有一些語義網絡已經出現，不過尚處於簡單且不太規範的知識表示形式。
• 70 年代到 90 年代，出現了一些專家系統，一些限定領域的知識庫(如金融、農業、林業等領域)，以及後來出現的一些腳本、框架、推理。
• 90 年代到 00 年，出現了萬維網、人工大規模知識庫、本體概念、以及智能主體與機器人。
• 00 年到 06 年，出現了語義 Web、羣體智能、維基百科、百度百科、以及工作百科之類的內容。
• 06 年至今，我們對數據進行了結構化。但是數據和知識的體量越來越大，因此導致了通用知識庫越來越多。隨着大規模的知識需要被獲取、整理、以及融合，知識圖譜應運而生。

從發展里程碑來看：

• 2010 年，微軟發佈了 Satori 和 Probase，它們是比較早期的數據庫，當時圖譜規模約爲 500 億，主要被應用於微軟的廣告和搜索等業務。
• 接着在 2012 年，谷歌推出了 Knowledge Graph(知識型圖數據庫)，當時的數據規模有 700 億。
• 後來，Facebook、阿里巴巴、以及亞馬遜也相繼於 2013 年、2015 年和 2016 年推出了各自的知識圖譜和知識庫。它們主要被用在知識理解、智能問答、以及推理和搜索等業務上。

從數據的處置量來看，早期的專家系統只有上萬級知識體量，後來阿里巴巴和百度推出了千億級、甚至是兆級的知識圖譜系統。

上圖便是如今在知識圖譜領域的世界各大知名公司，可見該領域的玩家還是非常多的。

上圖左表反映的是我們曾經給客戶做過的某類法律文本在數量上的變化趨勢。

在 2014 年文本的數量還不到 1500 萬，而到了 2018 年總量就超過了 4500 萬。

我們預計至 2020 年，文本的數量有望突破 1 億萬件(某一特定類別)。那麼，我們現在所面臨的問題包括：數據量的龐大、非結構化的保存、以及歷史數據的積累等方面。

這些都會導致信息知識體、以及各種實體的逐漸膨脹。因此，我們需要通過將各種知識連接起來，形成知識圖譜。

知識圖譜常見應用場景

知識圖譜可以被用於查找人與人之間的關係，如上圖所示，我們可以理解爲電視劇《人民的名義》中人物的關係圖譜。而在很多企業中，就是用到知識圖譜來找出用戶與用戶之間的關係。

知識圖譜的另一個應用場景是：找出實體之間的關係。所謂實體，我們可以理解爲早年曾提到的“面向對象”中“對象”這一概念。

如上圖所示，在公司和企業之間，包括它們的子公司、以及合作公司之間都存在着實體的關係，這就是知識圖譜的核心概念。

上圖是知識圖譜在農業方面的應用。可見，由氮素缺乏輻射開來之後，最終會導致葉子的枯萎，以及落果率的降低等農業方面的歉收情況。

因此，我們在做知識圖譜的時候，實際上就是要查找並建立各個實體之間的聯繫。

如上圖所示，在知識圖譜的研究和落地方面，業界一般分爲三大類：

• 智能語義的搜索。例如：我們通過搜索引擎把各種知識點、實體、以及內容結合起來，形成實體之間的關係。
• 個性化的推薦。例如：我們在網購和瀏覽頭條新聞時，下一次打開某個 App 所看到的內容，往往是該系統根據上一次搜索過的相關內容所做出的個性化推薦。
• 智能問答。比如：某家空調公司需要上線一個“知識問答”功能。那麼他們既要收集本領域的電器相關知識，又要從外部實體那裏抽取電路設計、功率設計、能耗設計、智能程度和用電量等方面的知識。

因此，他們會通過推薦或者是知識的抽取與融合，將結果保存到分佈式圖數據庫裏，進而發現各個點與點之間或是邊與邊之間的關係。

就每天有着超過兩億日活用戶數的 WPS 而言，我們需要通過建立用戶節點，將用戶的基本信息、屬性特徵和他們的文檔聯繫起來，存放到普通數據庫(如 MongoDB)裏，然後再轉化成圖數據庫的關係。

同時，我們需要梳理出各個用戶節點之間的邊。比如說：如果用戶A和B來自同一家公司，他們就可能會有同一條邊;如果他倆共享過了某個文檔，則又會生成一條邊。

因此具體尋找邊的表述方式會有如下兩種：

• 通過對數據的搜尋，發現在同一個數據庫中不同節點所包含的共同字段和屬性。
• 通過知識的融合與發掘、以及文檔內容的語義，提取文字或標題的中心內容，再運用算法分析，採用主體之間的對比方式，找到兩個用戶之間可能存在的關係，進而建立一個知識體。

知識圖譜圖數據庫選型

在做知識圖譜時，我們最常碰到的問題莫過於對圖數據庫的選擇。當前，業界有 Neo4j 和 Cayley 這兩種最爲常用的圖數據庫可供選擇。

大家可能會普遍地認爲：無論是網上資料的豐富程度，還是數據庫知名度的排名，Neo4j 在各個方面的優勢都勝過 Cayley。然而在實際選型中，我們卻選擇了後者。

具體原因如下：

• 數據的體量。由於我們公司有着兩億規模的日活數據量，而且還會持續產生無數個節點，因此我們需要選用一款能夠支持大體量數據的數據庫。
• 開源的屬性。如今 Neo4j 的企業版已經不再開源。而就算它以前的開源模式也並不完全。由於其核心內容並未開源，因此一旦出現了問題，我們很難得到及時的支持與幫助。
• 是否支持分佈式。鑑於上述企業版的限制，有人曾提出採用免費的版本。可是，由於只有企業版的 Neo4j 才能支持分佈式存儲與集羣，而且其免費版無法支撐我們的數據體量，因此我們後續沒有再去考慮 Neo4j。
• 落地時的性能。其間，我們還曾經對比過 Dgraph 與 Cayley。鑑於兩者都是開源型的數據庫，且都能夠支持分佈式，因此我們考量了它們的第三個維度：落地時的性能。

我們曾經使用上億的數據量，去分別檢驗兩種數據庫查找關係和建立關係的性能。

隨後，我們發現由於自身存在着 Bug，Dgraph 對於支持邊的權重計算存在着缺陷，會導致在進行邊與邊、點與點的計算時出現性能上的問題。

因此經過綜合考慮，我們最終還是選用了 Cayley 作爲自己的圖數據庫。當然，我們也將自己的發現提交給了 Dgraph 的作者，如今的 Dgraph 版本，已經修正了該 Bug。

總的來說，我們在給企業選擇圖數據庫時，需要分析企業自身的數據體量。如果要處理的數據量和知識量特別多，而且對於速度、性能有一定的要求的話，就不能使用單機版的數據庫，而應當去考慮分佈式。

與此同時，更重要的是：應用的場景。如果本企業除了要計算兩個節點之間的關係，還需要得出節點關係所對應的邊權重的話，那麼我們更應該進行綜合考量和全面對比。

在此，我分享一種我們自己研究出來的獨門方法：一般而言，大多數圖數據庫(如 Neo4j)，都會自帶底層數據庫。

而在實際建模的過程中，我們完全可以在底層不去使用圖數據庫，例如：可以用 MongoDB 作爲底層;然後在它的上面去嵌套一層並未內置底層數據庫的圖數據庫。而且實踐證明，這樣的混合模式會更加靈活且高效。

知識圖譜落地

接下來，我們來看看知識圖譜的落地。如上圖所示，整個過程分成六個方面：

• 建立一套知識的模型
• 如何獲取知識
• 如何做好知識的融合
• 如何實現知識的存儲
• 如何保證知識的計算
• 高效地開展知識應用

我們除了需要事先建立知識圖譜的模型、以及運用模型來實現知識計算之外，上圖反映了其他四個重要的過程，下面我們來逐一討論。

知識獲取

我們既可以通過網絡爬蟲爬取，也可以通過事件抽取(如使用 CRF 和 LSTM 等機器學習算法)，還可以通過國內與國外的一些開源數據集來實現。

知識表示

在獲取到了知識之後，我們要對知識進行加工表示。我們既可以用到邏輯表示、框架表示、語義表示，也可以用到各種詞表、本體組織，還可以用到語義網絡、以及文本與語義的分類方法。

在完成模型表示之後，我們需要進行各種模型的建設。當前，國內業界普遍採用的方法是專家法和歸納法，當然，參照法也有被用到。

所謂專家法，就是根據團隊自身對於現有業務和行業的理解程度，通過人工來建模表示。

而歸納法，則是通過一些歸納算法、人工歸納、以及文本分類的方法，來進行模型的歸納。

我們混合使用了上述兩種方法。而在建模工具方面，當屬 Protege 和 MSVisio 最爲常用。

知識存儲

接着要進行的是知識存儲，如前所述，我們需要選擇一款數據庫，包括：MySQL、SQL Server、MongoDB、Neo4j 等，不一而足。

根據我們過往的屢次實驗經驗，您可以先將數據存放到 Key-Vaule 類型的數據庫中，而在後續需要的時候，再往 Neo4j 之類的圖數據庫中拉。

這種模式的性能要比直接存儲要高一些。而在工具平臺方面，Neo4j、Titan、以及 Cayley 都十分常用。

知識應用

確定了存儲方式，後面就是知識應用。它包括自然語言理解、知識搜索、知識問答、以及機器翻譯等典型的應用場景。

業界一般在模式上分爲兩種：

• 檢索模式。在已經建立好的現成知識庫圖譜的基礎上，我們將需要理解或翻譯的句子，放到庫裏進行“答案”檢索，再通過語義分析來進行匹配。最終將匹配出來的結果反饋給用戶。可見，這是一種理解自然語言的常用場景。
• 混合模式。在檢索模式的基礎上，我們添加了深度自我生成的模型，以應對在知識庫或語義庫的匹配效果不佳的情況下，利用 RNN(循環神經網絡)和 LSTM(長短期記憶網絡)來生成智能模型。

在知識應用中，常用的關鍵技術包括：CQL、SPARQL、Jena、Neo4j、以及歸納、演繹和基於規則學習的推理。

上圖是一張非常經典的知識圖譜整體架構圖，讓我們一起從下往上來解讀這張圖：

• 通過百度搜索、Word 文件、PDF 文檔或是其他類型的文獻，抽取出非結構化的數據。
• 通過自然語言處理技術，使用命令實體識別的方式，來識別出文章中的實體，包括：地名、人名、以及機構名稱等。
• 通過語義相似度的計算，確定兩個實體或兩段話之間的相似程度。
• 通過同義詞構建、語義解析、依存分析等方式，來找到實體之間的特徵關係。
• 通過諸如 TF-IDF 和向量來提取文本特徵，通過觸發事件、分詞詞性等予以表示。
• 通過 RDA(冗餘分析)來進行主題的含義分析。
• 使用數據庫或數據表進行數據存儲。
• 針對所提取出來的文本、語義、內容等特徵，通過知識本體的構建，實現實體之間的匹配，進而將它們存放到 Key-Value 類型的數據庫中，以完成數據的映射和本體的融合。
• 當數據的體量過大時，使用 Hadoop 和 Spark 之類的分佈式數據存儲框架，再通過 NoSQL 的內容將數據存過去。
• 當需要進行數據推理或知識圖譜的建立時，再從數據中抽取出各類關係，通過各種集成規則來形成不同的應用。

總結起來，在我們使用知識圖譜來進行各種應用識別時，需要注意的關鍵點包括：如何抽取實體的關係，如何做好關鍵詞與特徵的提取，以及如何保證語義內容的分析。這便是我們構建一整套知識圖譜的常用方法與理論。

【51CTO原創稿件，合作站點轉載請註明原文作者和出處爲51CTO.com】