NLP事件抽取/事件圖譜構建(五)
接上篇：
NLP事件抽取/事件圖譜構建(四)本篇我們繼續講實體庫構建的問題。
上篇講到實體庫需要抽取別名，然而會出現大量有問題的錯誤別名，甚至有些百科，將任務infobox的屬性和屬性值都搞錯了，比如講出生日期屬性的值弄成了別名，或者將出生地點的值弄成別名，這也很正常，百度百科其實就是個公眾編輯的平台，除了一些公眾名人，其他實體百科很難保證質量。如何處理這些錯誤別名呢？這就涉及到很多技巧了。幾米在工作過程中探索過一些可用的技巧包括：
- 通過對別名進行統計，將錯誤凸顯出來，一些錯誤屬性值在頻次統計後會發現異常高的現象。
- 通過對實體的正文信息，判斷是否包含別名
- 通過多數據源校對，比如互動百科與百度百科互相校對。
- 通過別名與真名判斷是否存在某些諧音
- 機器學習模型的方法
在校正了實體別名之後，真箇實體庫開始變得可用了，至少很多外國人物簡稱，公司機構簡稱可以被檢索出來了，這個是我們構建實體鏈接系統。
當然一些屬性和屬性值對齊的問題，也需要考慮，這為我們實體融合做實體相似度計算的時候提供很大幫助。比如我需要判斷百度百科的某個周杰倫和維基百科上某個周杰倫是否是同一個實體，那麼infobox中的屬性值就是很重要的判斷依據。例如：出生日期是否相等，出生地點是否相等，身高或體重是否接近，民族和國籍等，幾米將這些屬性稱為實體的「自然屬性」，即實體固有的屬性，對這些屬性做歸一化和對齊，長遠來看非常值得。這些屬性就是我們判斷是否同一個實體的特徵，然後通過簡單的規則就能知道兩個百科頁面是否指向同一個實體。
還有一些實體，是infobox很少的，而這些實體是大量的長尾存在，對這些實體做融合，就別指望能有個好的屬性來設計規則了，這時候我們可以通過對這些實體的正文介紹信息做相似度比對（如tf-idf , lda等），然後根據經驗設計閾值進行判斷，當然更好的方法是通過一些pairwise的深度學習模型方法，但是因為我們數據通常存儲在數據平台，前面會有大量腳本清洗的工作，我們通常會簡單的使用sql和udf來一起完成,深度學習模型較難整合進來。
在我們實體融合完成之後，基本的實體庫就構建完成了，不過還差一點，我們還需要設計策略為實體生成uid，因為我們的uid對實體來說是唯一關聯的，而uid一旦生成後並且被實體鏈接投入使用的話，後期基本不能更改，還有一點就是我們的實體庫後面會增量融合其他百科，如果uid設計不當，可能導致生成相同uid，所以uid的策略顯得更加重要。在數據平台上生成uid，可以通過md5方法對某些固有特徵進行編碼，自增id方式我們思考過，最終決定不使用。
前四期目錄：
NLP事件抽取/事件圖譜構建(四)
NLP事件抽取/事件圖譜構建(三)NLP事件抽取/事件圖譜構建(二)NLP事件抽取/事件圖譜構建(一)推薦閱讀：
