本篇文章主要是對另一篇文章的提煉，鏈接放在文末。

1 廚房領域的問答系統

智能廚房主要分為4個部分

  1. 菜譜. 通過問答系統，你可以知道哪一道菜，比如說紅燒肉怎麼做等等
  2. 音樂. 比如，說「我想聽一個輕鬆的音樂」
  3. 視頻. 比如，說我想看《人民的名義》第九集
  4. 廚電的控制. 指令式反饋，比如，打開油煙機，打開竈具，類似於一個中控系統

整體流程：

  • 語音識別. 科大訊飛和思必弛較為出眾，目前調用的是科大訊飛的介面
  • 文本糾錯. 一、概率模型（馬爾可夫鏈）。根據語料庫做一個字跟詞之間，序列這樣的一個概率模型。那麼一句話來了之後，可以根據這個詞出現在下一個詞的概率來進行糾錯。二、將實體與已有的實體庫進行對比糾錯。
  • 垃圾過濾. 系統有5個類別，4+1，（個人猜測是將不屬於上述四類的語句分為一類，另外一類是其他），垃圾過濾主要是為了區分以下幾點。第一，區分是否和機器在對話；第二，將對話中的一些「無用詞」過濾掉，只留下實體和屬性等，主要用檢索的方式實現（與已有的實體庫進行對比）。
  • 文本分類. 對問句進行類別分類（5類），這裡的類別指的是菜譜、音樂、視頻、廚電控制，其他等類別。分到具體類別後，再抽取該類別的實體及屬性。
  • 實體及屬性抽取，邏輯表達式生成，SPARQL查詢生成. 這裡用一個小例子概括。得到問句「紅燒肉怎麼做？」，首先提取實體（紅燒肉）和屬性（做），然後生成邏輯表達式，主要分為「與或非」之間的關係，如辣不辣是「非」的關係；最後生成SPARQL查詢語句。
  • 資料庫查詢, ES檢索. 如下圖：

2 知識圖譜技術的運用

2.1 整體框架

2.1.1 數據存儲

  • 基礎數據

菜譜的圖片數據等龐大的數據集，放在 Hbase 裡面；然後通過 MapReduce 的程序得到結果，如果需要這個結果，就把它同步到Mongodb裡面去。 Hbase 跟 Mongodb 各有優勢，Hbase 寫入的速度比Mongodb快很多，但是它讀取的速度，不如 Mongodb，因此，Hbase 主要做基礎數據的存儲，Mongodb 用於呈現數據，如果有一些關係性特彆強的數據，會放在 Mysql 裡面。

  • 圖數據

主要採用OWL(Web Ontology Language)表示，伴隨RDF(Resource Description Framework)表示，因為參考了很多的論文之後，OW L其實是比 RDF 更先進的一種方式。對於大量的數據存儲，必須要找一個持久化的工具，最後採用TDB，沒有採用Neo4j，是因為Neo4j收費，並且節點的個數有限。

  • 索引數據

對於一些索引的數據，比如說小的指令級的，上一頁、下一頁、翻頁、換頁這樣的生成並不多，並且它們匹配的準確率又非常高，這個地方，可能就不需要做泛化，因此可以把它放到 Trie 樹裡面；一些實體會放到 Elasticsearch 裡面查詢；還有一些小的數據集也要索引，就會放到 Lucene 裡面；之後的緩存數據，還是用的 Redis 這樣的一個分散式的緩存處理。

2.1.2 數據採集

問句生成。同一個問題的問句是非常多的，首先對輸入問句進行分析，找到「種子問句」，然後對它進行分詞，把每一個詞用word2vec 尋找相關的詞（比如國外-男人=女王-女人），相關的詞把它們的位置序列記好，然後做笛卡爾積。這樣的做完了，會生成大規模這樣問句的數據，當然裡面有一些是不正確的句子，這個時候用文本糾錯的馬爾可夫鏈的概率圖模型去糾正它，最後人工篩選。第二種方法是，收集200多個跟菜譜相關的動詞，以及相關的同義詞，利用文本生成，生成問句。這裡推薦OpenKG

2.1.3 知識庫構建

  • 知識融合

首先做時序融合，就是之前做的實體，它的實體鏈接是不是根據時間的推理，而它換掉了它本身的這樣一個含義，進而做本體的擴充（不太懂）。多源融合，做一個實體的匹配和概念的對齊。

  • 知識計算

抽出實體和屬性

2.1.4 數據訪問

分為4個部分。

1.SPARQL查詢 2.自然語言查詢 3.SDK的方式 4.邏輯表達式，後臺將其轉化成SPARQL語句

2.2 知識圖譜的構建

其中，不辣的查詢比較耗時，原因是因為標籤沒有不辣，因此要把所有的屬性都查一遍。後來的解決方法是離線去處理，比如是甜的，那它一定不是辣的。

3 曾經踩過的一些坑

知識圖譜裡面的搜索是有一個問題的， ElasticSearch 檢索裡面的排序其實是非常容易去做的，本身底層就寫了一個排序打分的 TF-IDF。而用知識圖譜的時候，它附近的這些節點的權重都是一樣的。比如說土豆能做什麼菜，那麼查詢出來所有的菜的權重都是一樣的。知識圖譜裡面，映射的本身是扁平的，比如土豆這個節點，能夠查詢很多菜譜，發現有些所列出來的那些菜大家都不認識，會造成糟糕的體驗。解決方法：在知識圖譜的屬性當中，加了一個熱度的一個值，熱度主要是通過點擊次數去計算，然後根據熱度排序。

4 遇到的一些挑戰與困難

1. 跨領域問題除了基礎工作，比如查詢等方式不會有太大的改動，但是屬性是要重新設定的。

2. 語義理解還沒有達到一定的高度。當下主要還是在於文本分類+屬性抽取+邏輯表達式，但是用多大的數據量可以將一句話直接運用到知識圖譜中去還需要繼續探究。

- end -

Tip：索答科技已經將 50w 菜譜本體信息在 OpenKG 上開放出來，每個菜譜包含菜名，食材，味道，烹飪時間等屬性。鏈接

索答菜譜本體信息 - 開放知識圖譜

對於知識圖譜查詢這一塊，主要涉及了RDF,OWL,SPARQL,推薦看 知識圖譜-給AI裝個大腦 裡面講解的很詳細，也有個demo，有時間我會把python3的實現放到github上。

Reference：

知識圖譜-給AI裝個大腦?

zhuanlan.zhihu.com圖標索答科技：領域應用 | 基於知識圖譜的廚房領域問答系統構建?

zhuanlan.zhihu.com圖標
推薦閱讀：

相關文章