事實上有一門學問叫NLU(Natural Language Understanding, 自然語言辨識),就專門在講這部分
但我想用比較簡單的方式來說明
聊天機器人對於問句的理解與回覆,簡單來說就是一個配對(觸發)過程
- "你叫什麼名字","我叫肥宅聊天小幫手"
- "你的專長是什麼","專門陪肥宅聊天"
- "你最討厭什麼","雖然不想,但還是要陪肥宅聊天"
這些就是我預先設定好的問題與答案,也就是Q&A
所以在開發聊天機器人之前,你必須要有一個大量且正確的資料庫(語料庫/語意庫)
回到語意分析,早期的方式叫Rule based
"你叫什麼名字","我叫肥宅聊天小幫手"
當使用者詢問聊天機器人"你叫什麼名字",就給他一個答案"我叫肥宅聊天小幫手"
但使用者不可能乖乖的照著你的方式詢問,一定會有超多種的變化
所以你只好窮舉出可能的問句
- 請問你的名字
- 問一下你的名字
- 可以知道你的名字嗎
- 方便告訴我你的名字嗎
當你把這些都建進去資料庫後,結果使用者問"請問你的姓名"
但你沒有告訴聊天機器人,名字=姓名=大名,所以聊天機器人一定答不出來
當你發現這個問題,只好繼續窮舉下去,但你馬上會發現,用人工的方式來做會死人的
(其實也還好啦,重點是現在就算外包給大陸,工資也不便宜呀)
為了解決這個問題,後來又提出了第二種方式叫Intent based,這是比較有效率的方式
目前所有的聊天機器人平台都是採用Intent + Entity的方式
Intent就是所謂的意圖
"我要做高鐵去台北",這句話的意圖就是"某個人"+"利用某個交通工具"+"去某個地點"
而 人/交通工具/地點就是Entity,Entity英文直翻叫做實體
- 你/我/他/某人都是主詞(人)的Entity
- 高鐵/台鐵/客運也是交通工具的Entity
- 台北/台中/台南/高雄都是地點的Entity
有些人可能會誤以為Entity是同意詞,但台北不等於台中,所以Entity不等於同意詞
Entity可以解釋為,屬於相同類型的名詞,也可以定義為參數
這樣是不是就可以發展出一個矩陣,然後產生多種組合
有沒有比剛才的第一種Rule based好多了
聊天機器人發現你的問句命中這個句型,就知道你在講什麼了
甚至還可以依據參數,給予不同的答案
例如"我要訂一張明天早上8:40從台北車站到左營車站的高鐵票"
- 意圖=訂票
- 數量=1張
- 時間=明天早上08:40
- 出發站=台北車站
- 到達站=左營車站
- 交通工具=高鐵
有了這些參數,你就可以透過API連結訂票程式達成訂票
甚至還可以做到,如果少了某個參數,例如缺少了時間
"我要訂一張明天從台北車站到左營車站的高鐵票"
這句對話中,明顯少了時間參數,可以設定缺少時間參數時回問 "請問幾點搭車"
這部分也有人稱之為Flow based
不過這種方式建資料會比較花時間
所以我會建議入門者用 Intent based 一問一答比較不會有挫折感XD
最後,我覺得Estelle Huang所寫的比我更好,你們可以參考看看
Rule-based vs. NLU:聊天機器人如何聽懂人類的自然語言?
沒有留言:
張貼留言