拋開炒做看知識圖譜，爲何如今才爆發？

知識圖譜正在被大肆炒做，Gartner 的 2018 年新興技術炒做週期中就包含了知識圖譜。咱們甚至沒必要等 Gartner 宣佈 2018 年是「知識圖譜年」，與活躍在這個領域的全部人同樣，咱們都看到了機會，但也看到了威脅：伴隨炒做而來的是混亂。

知識圖譜是真實的，它們至少已經存在了 20 年。知識圖譜的原始定義是關於知識表示和推理，如受控詞彙表、分類法、模式和本體之類的東西，它們都是創建在標準和實踐的語義 Web 基礎之上。

那麼，有哪些東西發生了變化？爲何 Airbnb、亞馬遜、谷歌、LinkedIn、Uber 和 Zalando 等公司的核心業務都應用了知識圖譜？爲何亞馬遜和微軟加入了圖數據庫提供商的行列？你又能作些什麼？

當知識圖譜還沒那麼酷的時候

知識圖譜聽起來彷佛很酷，但它們到底是什麼？問這樣的問題彷佛有點幼稚，但要構建知識圖譜，首先要正確地定義它們。從分類法到本體論——本質上是不一樣複雜性的模式和規則，而這些就是人們多年來一直在作的事情。

用於編碼這些模式的 RDF 標準就具備圖的結構。所以，將基於圖結構編碼的知識稱爲「知識圖譜」是件很天然的事情，而相應的數據建模者就被稱爲知識工程師或本體論者。

知識圖譜有不少應用——從編目項目到數據集成和 Web 發佈，再到複雜的推理。這個領域的一些佼佼者包括 schema.org、Airbnb、亞馬遜、Diffbot、谷歌、LinkedIn、Uber 和 Zalando。這就是爲何經驗豐富的知識圖譜人士對炒做嗤之以鼻。

知識圖譜如今已經出如今新興技術的炒做週期中。對於擁有超過 20 年曆史的技術來講，還算不錯。

與其餘數據建模同樣，這是一項艱難而複雜的任務。它必須考慮到不少利益相關者和世界觀、管理起源和模式漂移等。加上混合推理和 Web 規模，事情很容易失控，這就是爲何這種方法直到如今仍然沒能成爲最流行的方法。

另外一方面，無模式卻一直很流行。無模式可讓你快速入門，並且至少在某種程度上，它更簡單、更靈活。但無模式可能帶有欺騙性，由於不論是什麼領域，都存在模式。讀時模式（schema-on-read）？或許能夠。那麼徹底無模式呢？

你可能不會事先對你的模式有充分的瞭解。它可能很複雜，並且會發生變化，但它必定存在。所以，忽略或淡化模式並不能解決任何問題，只會讓事情變得更糟。問題將會潛伏起來，並花費你更多的時間和金錢，由於它們會給開發應用程序並得到對模糊數據洞察力的開發人員和分析人員帶來阻力。

關鍵在於不是要拋棄模式，而是讓它發揮做用，讓它變得靈活和可互換。RDF 就很好，由於它也是數據交換標準化格式（如 JSON-LD）的基礎。順便說一下，RDF 還能夠用於輕量級模式和無模式方法以及數據集成。

圖譜的知識輸入和輸出

那麼，這項 20 年的老技術爲什麼出如今炒做週期的新興技術中？炒做是真實存在的，而出現炒做也不是沒有緣由的。這與迅速崛起的人工智能炒做同樣：並非由於方法自己發生了變化，更多的是由於數據和算力的發展讓它能夠大規模運做。

此外，AI 自己也起到必定做用。或者，更確切地說，是現在被炒得火熱的自下而上、基於機器學習的 AI。知識圖譜本質上也是另一種 AI，但不是那種被大肆宣傳的 AI，而是那種象徵性的、自上而下的、基於規則的、迄今爲止仍然不是很流行的那種。

並非說這種方法就沒有侷限性。對複雜的領域知識進行編碼，並進行大規模推理是很困難的事情。所以，機器學習就像無模式方法同樣纔會變得流行起來，而且有充分的理由。

知識圖譜起初可能很難，但不要放棄。實踐是走向完美的鋪路石。

隨着大數據的大肆發展和 NoSQL 的崛起，開始出現其餘的一些東西。有關非 RDF 圖譜的工具和數據庫開始出如今市場上。這些標籤屬性類型（ Labeled Property Kind，LPG）的圖譜更簡單和簡潔。與 RDF 相比，它們缺乏模式或只提供了基本的模式功能。

它們一般在運營類應用、圖算法或圖分析方面表現得更好。最近，圖也開始被應用於機器學習。這些都是很是有用的東西。

算法、分析和機器學習能夠提供有關圖的看法，一些常見的用例包括欺詐檢測或推薦系統。所以，你能夠說這些技術和應用程序從圖譜中獲取知識，是自下而上的。另外一方面，RDF 圖譜將知識引入圖譜，這是自上而下的。

那麼，自下而上的圖譜也是知識圖譜嗎？

知識工程師可能會說，這是一個語義問題。咱們很容易陷入知識圖譜炒做中。但最終，可能會由於缺少清晰度而沒法發揮太大做用。圖算法、圖分析和基於圖的機器學習和看法，這些都很好，它們也不與「傳統」的知識圖譜相互排斥。

咱們以前提到的這個領域的佼佼者都使用了多種方法的組合。例如，使用機器學習來計算知識圖譜有助於構建最大的知識圖譜——至少在實例方面。這也是像 DeepMind 這樣的 AI 先驅正在研究的東西。

有些舊東西，有些新東西，有些借來的東西

一般，使用何種圖譜方法和工具取決於你的實際用例。對於圖數據庫來講也是同樣的，咱們一直在密切關注它的發展，一路看着新的提供商和功能的加入。

在不久前的 Strata 大會上，得到最具顛覆性創業獎的獲獎者和亞軍都是圖數據庫：TigerGraph 和 Memgraph。若是你想要這個領域快速進展的證據，那麼這就是。順便說一句，這兩家創業公司都很年輕。

對於在 2017 年 9 月低調現身的 TigerGraph 來講，這是很是活躍的一年。TigerGraph 剛剛宣佈推出了新版本。它包含了一些舊東西，一些新東西，一些借來的東西。

自上而下仍是自下而上？

新東西不多。他們都在解決 TigerGraph 現有的痛點。TigerGraph 增長了與流行數據庫和數據存儲系統的集成，包括：RDBMS、Kafka、Amazon S三、HDFS 和 Spark（即將推出）。TigerGraph 表示，他們將會推出開源的數據庫鏈接器，並託管在 GitHub 上。

固然，若是沒有社區，Github 存儲庫也不會有太大做用。TigerGraph 正在努力，併發布了新的開發者門戶和電子書。這個版本還帶來了更多部署選項，添加了對微軟 Azure 的支持。爲了跟上容器化趨勢，還增長了對 Docker 和 Kubernetes 的支持。

咱們以前提到了圖算法，這多是這個版本最有趣的方面。TigerGraph 增長了對圖算法的支持，例如 PageRank、Shortest Path、Connected Components 和 Community Detection。有趣的是，這些是經過 TigerJraph 本身的查詢語言 GSQL 來提供支持的。

咱們已經提到了查詢語言對圖數據庫的重要性。最近，領先的圖數據庫提供商 Neo4j 提出了爲 LPG 圖數據庫建立標準查詢語言的建議。與自帶 SPARQL 的 RDF 不一樣，這在 LPG 世界中尚不存在。

最開始，TigerGraph 迴應了 Neo4j 的提議，但如今狀況正在發生變化。TigerGraph 剛剛發佈了一個 Neo4j Migration Toolkit，主要用於將 Cypher（Neo4j 的查詢語言）翻譯成 GSQL。

TigerGraph 這樣作是有道理的，由於一直要遷移現有的 Cypher 查詢體系將會成爲他們發展的障礙。TigerGraph 的實現方式頗有趣，他們提供了一次性的批量翻譯過程，而不是進行交互式的遷移。

這是一種戰略選擇。TigerGraph 但願人們切換到 GSQL，而不是在 TigerGraph 之上使用 Cypher。通常來講，開發人員一直不肯意學習新的查詢語言。TigerGraph 能夠嘗試去說服他們，但能不能奏效徹底取決於每一個人。

舊東西是指 TigerGraph 發佈公告包含的基準測試。這些基準測試其實是新的，但 TigerGraph 在剛推出時就已經提供了基準測試。對於一款聲稱比其餘任何解決方案都要快的產品，這樣作是無可厚非的。基準測試將 TigerGraph 與 Neo4j、亞馬遜 Neptune、JanusGraph 和 ArangoDB 進行了對比，而且不出意料的是，它比其餘產品都要快。

那麼哪些東西是借來的？固然是知識圖譜。TigerGraph 的員工也證明了客戶對此表現出極大的興趣，例如知識圖譜相關活動在中國吸引了 1000 多人蔘與。哪一個知識圖譜？如今你應該知道了。