事實上有一門學問叫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：聊天機器人如何聽懂人類的自然語言？
沒有留言:
張貼留言