中文知識圖譜構建思路是什麼？

12-29

由於英文知識圖譜火了，雖然不知道到底為什麼就那麼火了= =。。。中國也開始做中文的知識圖譜，以至於我微信朋友圈經常被這個刷屏~~~不討論它的價值，因為朋友圈已經討論完了；我想知道如果做一個大規模中文知識圖譜的主要思路是什麼。我猜想有以下：
1. 翻譯freebase
2. 抽取百度百科
3. 用Infromation Extraction方法從文本中抽

希望有經驗的大牛分享一下心得

講真，一開始的話就直接不要去想Open Information extraction。
最靠譜的方法是狂上爬蟲抓那些個網站，抓完之後各種消歧和Align。就能搞到一個差不離。這時候就可以用了。

然後如果你真的想在這上面大投入，那再上Inference和Open IE。

利益相關:在NELL和OpenIE里都干過。

曾經參與過中文知識圖譜的部分構建工作

中文知識圖譜現在能夠做到上線系統級別，open domain的，我覺得應該只有百度和搜狗（1-2年之前，通過兩家公司的宣(chui)傳(niu)來看是這樣的）
英文的知識圖譜做的最好的應該是google，在收了freebase之後，在此基礎上又提高了數量級據說還上了大量的人。。

我們的一些做法：
open domain直接抽freebase，freebase裡面是有一些中文的部分，拿來直接用，逃（，沒有對freebase進行翻譯，首先是機器翻譯的準確率，其實，裡面更多的是entity，這個本事翻譯就比較困難吧，還要涉及到entity linking。
special domain:主要就是抓取網站的數據吧，比如電影電視去抽，時光網，TV貓。音樂去抓蝦米網，娛樂明星去新浪娛樂、搜狐娛樂。因為這些網站本事有一定的結構，抓下來消岐相對要簡單。

不管怎樣，我感覺人工的干預還是保證precision的重要法寶。。

Open Domain的話，我覺得2是一個能比較快速實現，準確率有一定保證的方法。

針對翻譯，不管是翻譯freebase還是dbpedia還是其他別的知識來源，MT的準確性和翻譯後的消歧、消重問題都沒有很好的解決方案，得到的結果恐怕很難在上線系統里應用。

從Web文本中抽取，這是Google、Facebook這些大公司在結構化數據達到一定規模以後獲取新的數據一定要使用的方法。這種所謂的knowledge harvest/knowledge fusion/...需要大量的語料，以及這些大公司積累的參數（應該不必應用太複雜的演算法和統計方法，以利於工程實現，但是模型的參數真是。。。）KDD2014上有一個tutorial，講到自動化抽取的confident facts大概有302M，其中223M在Freebase里，Freebase的規模大概是637M，我覺得效果還算不錯。
Web知識自動抽取這種方法，看起來比較有前景，但是投入比較大，回報也不算特別高。比較適合有一定NLP技術積累的搜索引擎公司（對，我說的就是百度。。。）來做，百度搜狗已經做了比較久了。

從頭構建知識圖譜，拋開應用不談，就是獲取結構化數據（並映射到本體）的過程。
快速構建的方法，個人覺得最好的是從各種源頭爬取結構化數據，涉及到幾個過程：
1. 網頁/數據的爬取，解析
2. 清洗
3. 消重，消歧
最近在構建電影和音樂領域的知識庫，有不少網站提供了具有一定結構化的數據。
寫一個爬蟲，慢慢爬（取決於你有多急迫，爬蝦米爬了小半年了。。。）
解析爬下來的網頁，因為同一個網站，解析比較容易。獲取結構化的信息。（需要注意的是，網站有時候。。。會改版的。。。）
這些網站的信息一般是眾包生成的，熱門的還好，但是非熱門的信息很可能非常不規範（想像一下，你發現一首歌的作詞人是「阿信60%_XX40%」。。。），看你的數據，清洗。
消重，消歧。你當然可以使用 " :阿信 owl:sameIndividual 阿信@五月天"，不過我更傾向於把『阿信@五月天』全替換成『五月天』。

爬取的方法的限制是，到一定規模以後你的Recall就很難升了。
不過我覺得這時候用戶體驗應該已經不錯了，同時計算瓶頸也已經差不多了。。。
更適合領域知識庫的構建。
各個領域知識庫加起來肯定遠小於open domain，但是已經能滿足我想的業務需求了。
DBPedia里有不少中文的信息，不過直接提取出來可能會有些雜亂。

計算瓶頸是指，在有一定規模的結構化數據以後，怎麼存怎麼拿。
語義網界的方法一直是本體+jena/sesame/...，我以前還做過一些RDB2RDF的工作，把數據存在RDB里，然後mapping成知識。現在我還在用jena。這種方法的好處是可以用sparql，容易實現，人類可讀性好；缺點就是，慢，越大越慢。我猜Google/Watson肯定不用這個。
大佬們可能在用的方法是圖資料庫。不太懂，在學習。

更深刻的知識，或者更難獲取的知識（比如『香蕉皮是黃的』），只能人工去弄。
Cyc不知道還在不在了，在中國有計劃地人工弄應該還可以吧。。。

百科知識圖譜構建見：
Tianxing Wu, Shaowei Ling, Guilin Qi, Haofen Wang:
Mining Type Information from Chinese Online Encyclopedias. JIST 2014: 213-229
Xing Niu, Xinruo Sun, Haofen Wang, Shu Rong, Guilin Qi, Yong Yu:
http://Zhishi.me - Weaving Chinese Linking Open Data. International Semantic Web Conference (2) 2011: 205-220
另外，可以看看Yago和Dbpedia的相關論文，差不多也夠了。
百科知識圖譜的作用是什麼？就是提供基礎的知識庫，從而使得用NLP技術抽取三元組數據更容易。比如說，百科裡面有各種人物的介紹，可以用來對NER做消歧，提高NER的準確度，通過把百科知識鏈接到文本（entity linking），可以提升relation extraction的效果。

但是，是不是說知識圖譜構建用NLP技術就夠了呢，答案是，一般來說，對於一個應用，僅僅做一個relation extraction是不夠的，因為還需要多源數據的集成，這就要求做instance mapping，即兩個實體的匹配或者映射。另外，還需要對圖譜中缺失的信息做補全，即處理incompleteness的問題，這裡就需要用到推理技術，通常的有PRA和TransE，PRA實用性可能更好點。

另外，還需要考慮知識的分類組織，就需要schema，比如說Probase, http://Schema.org，中文的工作見：

Haofen Wang, Tianxing Wu, Guilin Qi, Tong Ruan:
On Publishing Chinese Linked Open Schema. Semantic Web Conference (1) 2014: 293-308
schema的只是不僅僅可以用於分類組織，還可以做邏輯推理，從而幫忙解決incompleteness問題，還可以做衝突檢測，從而解決知識庫的質量問題，還可以有助於搜索。

構建知識圖譜沒有統一的方法，因為知識圖譜的構建就是需要一整套知識工程的方法，這裡需要用到語義web技術，用到NLP，ML技術，用到圖資料庫技術，用到知識表示推理技術。

最後，做知識圖譜方面的項目一定要注意需求分析，因為「知識圖譜就是一種工程」，任何工程都需要有需求分析，離開需求分析談知識圖譜就是紙上談兵！

方法的是清晰的，沒有什麼秘密。樓上各位都說的很清楚了：實體提取，關係提取，圖譜存儲和檢索。

知識圖譜實踐坑太多了，絕不是看看教科書就能學會的。這是很年輕的學科，目前還沒有好的教材。

關鍵是項目的目標控制和路徑設計。科研項目，工程項目，大公司項目，小公司項目，大公司裝逼項目，大公司現有產品改進項目，搶資金項目，預研試驗項目。To B項目，To C項目，To VC項目，To G項目。那做法都是完全不同的。

關鍵是成本控制，回報周期控制，和出錢的大爺的預期管理。在技術上做好演進的，可容忍低結構、高雜訊、低質量數據，充分理解沒有神奇的銀彈。在團隊上充分考慮到知識圖譜人才稀缺性，盡量用現有的技術人才漸進推進。在資金管理上充分理解大爺們耐心是有限的，要快速迭代，快速出活。

其實並沒有什麼太大區別啊…所謂知識圖譜聽起來很高大上號稱給計算機裝上了大腦…其實無非就是從各種結構化/半結構化/非結構化數據中抽取實體/實體屬性/實體之間的關係，構成一張圖，這張圖能夠反映真實世界的相關信息，因為真實的世界在人類的認知當中就是由實體、屬性和實體間的關係構成的

獲取這些東西的最大挑戰無非就是實體識別、消歧（重名，別名）、實體關係挖掘等，這些歸根到底都屬於nlp的問題

所以說如果中文知識圖譜的構建和英文的有什麼區別的話，只能是中文和英文在自然語言處理技術上的差別

比如處理語料時中文和英文分詞的差別，這點中文更難，很多實體的指代直接被分成多個詞，後面再想救回來又得另想辦法；比如消歧的時候英文中有大量的縮寫指代，同一個縮寫對應很多可能的實體，這點英文比中文難；再比如關係挖掘的時候，個人感覺中文要更難一些，因為表述更豐富更不規律

綜上，中文知識圖譜的構建和英文的所謂區別，歸根結底只在nlp這一塊，其他的諸如步驟流程框架等等確實沒啥差
當然，英文方面現成的東西更多一點，可以直接拿來用，中文就苦逼呵呵了…這會導致實施起來有所不同，在我看來這也算是一個很大的差別吧…

實現一個大規模中文知識圖譜主要有兩部分，以「美人魚的導演是誰」為例：

1. 建知識庫(KG)。工程上，解析半結構化網頁 &>&> Open IE。於是爬百度百科，解析網頁，實體對齊。知識庫可以用RDF表示：三元組（美人魚，導演，周星馳），和對應的schema（movie, movie_director, person）。存儲方式有多種：Neo4j/MySQL/自定義。抓取的網站越多，歧義消除/指代消解/知識融合之類的事越多，找質量好的網站可以省很多事。半結構化的網頁到結構化的數據是一大坑。

2. 問答系統(KBQA)。除了圖關係挖掘外，主要的通用的應用場景。方法精度上，Pattern &>&> Machine Learning。語義分析「美人魚的導演是誰」，得到句法樹，生成檢索語句（與對應的存儲方式對應：SparQL-Neo4j / MySQL-SQL），檢索知識庫得到結果「周星馳」。

PS：
1. 知識圖譜發paper和工程實現，著重點完全不同，可以認為是兩個項目。
2. 數據質量是個大坑，會花掉絕大部分時間。
3. 目前不實用。找不到像搜索/推薦類似的大場景，期待神人出現。

正在做基於維基百科的知識庫構建，做法如下，首先，大家都知道知識圖譜是一個知識網路，可以認為這是一個圖結構，所以第一步應該是先確定圖中的各個節點，就通用領域來說（特定領域的不清楚），其實節點就是各種實體，比如ACE2005定義的七大類實體（人物，地點...），當然，對於特定的任務可以有特定的實體，比如電影名稱等等。
一、對於確定圖中的節點，具體的實現步驟如下：
1、定義實體類別，雖然我們可以將七大類實體作為第一個層次的類別，但不夠細化，比如運動員和音樂家如果同屬於一個類別下，就比較難以區分。所以這一步需要定義更加細化的實體類別，比如人物可以細分為：政治家，藝術家，動漫作者等等。這一步暫時沒有什麼好方法，我都是通過維基的模板抽取處理，規範化後，再人工核對的，如果誰有自動化的方法，還請不吝賜教。
2、定義各類別的屬性，在上一步驟中細化各個類別，這一步中將為每個類別設置其固有的屬性，比如音樂家有屬性：「代表作」，而足球運動員有屬性：「position」，這一步驟是對於維基百科信息盒的某一類模板，將其出現頻率在15%以上的屬性保留下來，對於出現頻率少的屬性刪除。
3、確定了各類別的屬性後，就需要實例化各個類別，這和面向對象的思想有點類似。比如對於足球運動員這一類別，具體實例可以為「李毅」（李毅大帝估計應該無人不知吧），這個時候出遇到一個問題，就是實體屬性缺失，雖然我們選擇的屬性都是高頻屬性，但還是有部分可能沒有，這個時候就需要從維基描述文本中進行抽取，目前我也正在做這個事情，初步的是CRF去做，做完之後再來補充。
二、在確定了圖中的節點後，需要做的就是確定各個節點之間的邊，即各實體之間的關係。關係越多，整個圖結構就越複雜，知識也就越豐富。關係的抽取可以來自很多地方，我做的還會基於維基百科的信息盒，每個條目的信息盒都會有一些屬性，當然其中有些是固有屬性，比如人物有：姓名，出生日期等等，還有一些是關係屬性，即可以和其他的實體產生聯繫，比如人物有：父親，朋友，等等。對於關係的抽取，主要有以下幾個步驟：
1、定義關係的類型，這些關係可以自己定義，比如YAGO用的自定義關係有：birthOfPlace，這是出生地點，hasGDP等等，當然也可以直接使用ACE2005定義的六大類實體關係。
2、實體鏈接，在已知某個名稱為一個實體的基礎上，需要做的是實體鏈接，即將該實體鏈接到一個具體的實體描述上（即圖中的節點上），比如遇到一個實體「馬雲」，世間叫馬雲的何其之多，但是如果其上下文中出現了阿里巴巴等等辭彙，那這個「馬雲」具體是誰呼之欲出，這個過程就是實體鏈接，根據實體出現的上下文將實體連接到具體的節點上。
3、實體關係抽取，對於一個條目，比如「傑米·奧利弗」，其屬性中有一條如下所示：
&GB[[英國]][[艾塞克斯郡]][[克萊維林]]&
如此，可以得到關係：傑米·奧利弗出生於克萊維林；克萊維林屬於艾塞克斯郡；
艾塞克斯郡屬於英國。這樣可以有四條邊來連接這4個節點，同時我們可以很容易推理出傑米·奧利弗是英國人。
三、在確定了節點，以及節點之間的邊之後，剩下要做的就是如何存儲這些數據了，目前用的比較多的有Jena+MySQL，還有就是使用圖資料庫Neo4j. 前者是使用主要使用的是語義描述語言OWL來對知識庫進行描述，可以進行一些推理，不過要先定義好推理的函數，後者主要是將以圖結構來描述整個知識庫，推理即是對圖中的節點進行遍歷。

有一篇文章
Machine Learning Techniques for Automatic Ontology Extraction
裡面提到其實要多種方法結合，可以參考。

知識圖譜最近變得很火，市場上對這樣人才的需求量也特別大。
個人感覺工業界對知識圖譜的需求主要是幾種應用場景：QAatbot，搜索引擎，領域實體關係分析，推薦系統和命名實體識別NER。
如果從構建方法來看這些不同場景，我覺得又可以把知識圖譜分為強關聯類型和弱關聯類型兩種。強關聯類型基本都是需要提取實體之間的多種具體關係，這是對於知識圖譜的最高要求，問答系統和智能搜索引擎一般就要求這種類型的知識圖譜，需要定義實體，實體類型以及不同類型所具有的屬性（潛在關聯）。這些東西上面的同學都已經說得很詳細，我就不說了。但是說實話，大多數的公司（除了最大那幾個）都做不了或者做不好這樣的知識圖譜。
領域實體關係分析介於兩者之間，不過因為是局限於領域內而且在特定產品的應用場景要求下潛在關聯也比較簡單，所以工程複雜度要低很多。基本的思路用監督式學習的方法找到特定關聯的模式，這個模式可以是簡單的正則或者其他規則，也可以利用各種監督式學習演算法來訓練出來，從傳統的SVM到神經網路都可以。
弱關聯類型不需要定義實體之間的關係，甚至都不需要有定義明確的實體，這樣的知識圖譜主要用途是在不同的實體/詞語之間聯立關聯，然後用來推薦或者去歧義。提取關係可以通過簡單的統計關係或者集合覆蓋來完成。
舉個例子，如果想要生成某個領域的知識圖譜，可以首先在該領域的大量文本中提取關鍵詞/潛在概念，然後遍歷分析這些關鍵詞的出現統計規律推測它們的相互關係。還可以結合聚類演算法來進一步對關鍵詞進行分類。
形成了一個領域的知識圖譜就可以在不同的概念之間建立聯繫，這在基於內容的推薦系統中很有用。比如你對「籃球」感興趣，因為「籃球」在這樣的知識圖譜中可能在「運動」或者「比賽」的關鍵詞下，或者同一個大類下還有「足球」的關鍵詞，這些都可以作為推薦的依據。
在資訊類閱讀APP中可以採取這種方案來進行新聞推薦，《布爾財經》智能投資工具不僅嵌入了新聞聚合和智能推薦功能，還為投資者匯總了各種相關財經數據並及時提供投資信號。。。
如果你感興趣的話，可以下載或關注支持！

下載布爾財經APP，獲取更多炒股工具：布爾財經官方網站

中文知識圖譜的構建一般要有幾種方式：1、本體。這種方式構建起來需要設計本體中類、屬性、以及數據類型，然後根據設計的本體模型填充實例數據，最後形成本體文件，供後續模塊使用。特殊情況下還需要根據本體設計一些推理規則，一般推理的時間複雜度比較大，建議將規則轉換成實例數據存儲在本體中。2、三元組的形式。這種建法比較靈活，可以以subject、predicate、object的形式建，存儲在RDF,或者ttl中，規模比較大的還需要存儲在TDB或者其他的圖資料庫中，這種方式不需要設計複雜的類以及屬性，只需要根據實際的數據填充主謂賓就OK了。而對於知識圖譜的使用當然回歸到搜索上，一般使用SPARQL進行搜索，這種方式比傳統的搜索有比較大的提升。

中文知識圖譜的話推薦一下 http://zhishi.me/

Open IE的話我曾經整理過一些（在學校的時候嘗試過把其中一些論文的方法運用到構建中文知識圖譜上）

剛開始接觸知識圖譜構建，目前要搞一個KBQA，主要針對領域數據，最開始看到本體那一套，打算用Stanford Protege+Apache Jena去弄，發現有點弄不懂，構建本體也聽複雜的，乾脆先來簡單的，人工抽取出實體關係後導入Neo4j，直接基於圖進行檢索，也不知道行不行得通～～～

Quora上的答案還是挺詳細的，還可以順便看看鏈接頁面里列的周邊近似的問題

https://www.quora.com/How-do-you-build-and-maintain-a-knowledge-graph

常規：先做知識定義即建模，然後依此填充具體知識數據，可以數據轉換，也可以UGC。
快速：定向抓取。比如從豆瓣上抓書籍，或者從豆瓣/imdb上抓電影，從微博上抓名人之間的關係等等。
自薦：楚辭 -- 讓知識融入你的生活/作品

國內的技能樹，Taguage等都是類似的產品：

SkillTree：幫你導入思維，存儲筆記，解決知識體系碎片化問題 - 科技創新,互聯網創業,創業網 - 科技訊

1.知識圖譜不能簡單的理解為一個類似知識庫，更多的是指一個範疇。

2.大規模的知識圖譜的構建很不現實。

3.可以考慮從知識的提取、存儲或表現下的一個細分入手。