Rule-based vs. NLU：聊天機器人如何聽懂人類的自然語言？
隨著運算技術與存儲技術的不斷突破，電腦也愈發能從大量語料中學習應對進退。Facebook, LINE, Telegram, WeChat, Kik, Slack 等各大通訊平台，都積極釋出 API 供開發者串接，希望在對話式商務時代有一席之地（比較稀奇的是，美國市佔率第二名的聊天軟體 WhatsApp 至今尚未加入 chatbot 的行列）。
而對 chatbot 開發者來說，找出對的應用只是第一步，設計出好的體驗才是讓使用者留下的關鍵因素。關於聊天機器人的使用體驗設計，有許多眉眉角角可以鑽研，這篇想討論的，是另一個影響體驗的要素：自然語言理解能力（Natural Language Understanding）。
儘管未必要聽得懂自然語言，才能成為一隻體驗優良的 chatbot；但是，隨著選單式 chatbot 製作門檻的降低，如果能讓機器人也聽得懂人話，就能尋求按鈕互動以外的可能性，讓 chatbot 的互動彈性脫穎而出。
聽得懂人話的 bot 才好玩啊。
Rule-based vs. NLU
在聽「懂」自然語言方面，主要有兩種做法（這裡先將「懂」定義為「能對人類的自然語言產出準確的回應」，不討論哲學層次上「懂」的具體意義到底是什麼）：
1. 建立規則（rule-based）
知識一：聽到「付費」-> 就提供「商品購買連結」
知識二：聽到「交易失敗」-> 就提供「疑難排除連結」這種 if-else 式的方法成本較低，能快速建立 chatbot 的自然語言應對機制。
不過，我們總是希望機器人能聽懂更多詞彙/句型，而隨著知識範圍的擴張，rule-based model 後續維護起來，是非常恐怖的：
知識一：聽到「付費、付款、付錢、買東西、...」-> 就提供「商品購買連結」
知識二：聽到「交易失敗、卡刷不過、網頁卡住了...」-> 就提供「疑難排除連結」
知識三：聽到「優惠、折扣、週年慶...」-> 就提供「優惠資訊連結」- 問題：那「付款失敗了」怎麼辦？得多寫一層規則，讓疑難排除順位大於商品購買
- 問題：那「會員買東西有折扣嗎」怎麼辦？也得多寫一層規則，解決詞彙處理順位的問題
- ......
我們無法窮舉詞彙/句型，讓機器人學到所有的說法；此外，更不可能撰寫規則，逐條告訴機器，該用何種順序處理詞彙/句型。
讓機器自己運算詞彙、句型間的關聯，從中探索出模式，似乎是個更可行的方向。
2. 自然語言理解（NLU, Natural Language Understanding）
首先，我們可以讓電腦從大量語料，例如日常對話、網路留言、新聞、電影台詞中，探索出詞彙之間的語意距離。舉例而言，
某些詞彙經常同時出現：國王、皇后、城堡；海帶、豆乾、滷味；潮汐、海浪、地球
某些詞彙經常出現在句子的同個地方：我們一起 去 公園散步、小明和老王一起 到 沖繩玩
......即便電腦無法瞭解「滷味是個集合名詞，泛指用醬油與香料醃漬、烹調過的食物；而海帶和豆乾是具體的食物品項，經常被做成滷味…」這麼複雜精確的意義，但是電腦可以從文本中探索出，「海帶、豆乾、滷味」之間的語意距離，應該比起「國王、海帶、潮汐」來得接近許多。
（大量語料怎麼來？可以自己蒐集、自己寫爬蟲，或是參考一些開源服務，例如 Google 推出的 word2vec，就提供了語料、甚至 pre-train 好的模型。）
至此，電腦對自然語言已經具備模模糊糊的概念。接下來，我們可以讓電腦更具體地理解語句。
How Does It Work?
做法上，我們可以把使用者輸入的自然語言，分為幾大部分：
Intent
- 使用者的意圖
- 我要換輪胎、最近想買新車 → Intent: 商品購買
- 排檔桿壞了、昨天車子被 A 到 → Intent: 保固維修
Entity
- 實體。使用使用者語句中有明確指涉對象的詞彙
- 我要換輪胎 → Intent: 商品購買 → Entity: 輪胎
- 排檔桿壞了 → Intent: 保固維修 → Entity: 排檔桿
接著，就能根據 intent / entity 設計不同的回答
- 會根據使用者的意圖而有所不同
- Intent: 商品購買 → Entity: 輪胎 → Response: 請告訴我您的車款，我會推薦您適合的輪胎喔！
- Intent: 保固維修 → Entity: 排檔桿 → Response: 請傳送您的地理位置，我會推薦您交通最便利的維修中心喔！
Context (State)
- 對話的脈絡（狀態）。
- 語句中可能出現：1. 代名詞：這個多少錢？ 2. 沒有主謂賓結構：然後咧？所以呢？ 等情況。如果沒有針對 state 規劃應對機制，模型會將單個語句視為獨立的表意方式，例如以下情境：
未處理 context 的 NLU：（已經結帳完）→ Q: 這樣就可以了嗎？ → A: 抱歉，請問您想表達的意思是？有處理 context 的 NLU：（已經結帳完）→ Q: 這樣就可以了嗎？ → A: 是的，歡迎再次光臨喔！
- 比起 intent 和 entity，context 的挑戰性又更高了，因為模型必須具備 memory，能記住最近到底在聊什麼（最近處理了什麼 intent），而且要有判斷代名詞指涉對象的能力。這篇文章暫時不討論。
How to Teach the Machine?
Step 1. 界定知識範圍
為什麼需要界定知識範圍？因為給定同樣的時間，要做得廣，就做不深；要做得深，就做不廣。較容易產生價值的是後者：擁有特定領域知識（domain knowledge），能夠回答 Google 搜尋不到的專業問題的機器人（不然直接問 Siri 就好啦）。
想像一個汽車 chatbot，如果能充分回答「商品購買、保固維修、門市資訊」的資訊，已經是功德圓滿了。「最近有什麼好看的電影？」這樣的問題，我們並不期待它能回答。這看起來是件顯而易見的小事，但實際在設計 chatbot 的自然語言應對機制時，很容易落入什麼都想回答的陷阱裡，不可不慎。
Step 2. 拆解意圖
目前，我們將知識範圍限定在三大類：「商品購買、保固維修、門市資訊」。基於這樣的結構，已經可以教機器人作答了。
不過，請試著觀察以下句子：
小明: 想看今年的型錄～
小華: 我要預約賞車。
小美: 想換輪胎了！
老王: 有推薦的代步車嗎？發現問題了嗎？
在目前的結構底下，上述句子都指向「商品購買」這個類別，所以小明、小華、小美、老王的問題會得到相同的答案。
但是這四個人的需求其實是不同的。這代表什麼呢？代表答案如果不寫得複雜細緻，就要寫得非常模糊，才能 fit 這些句子。
- 複雜的回答：「來看看我們最新的型錄吧（附個網址）！心動的話，點擊按鈕，快來預約賞車！如果還不確定要買什麼車，就讓我來推薦你吧！......」
- 模糊的回答：「關於商品購買，請參考以下按鈕：...」以上兩種體驗，其實都挺糟的。根本的解法就是改善意圖（intent）結構。以「商品購買」為例，其實可以進一步拆成「車款介紹、預約賞車、車款推薦、汽車周邊」，再進行後續工作。
不過，這裡可能會產生另一個疑問：「那為了讓體驗更加細緻，是不是乾脆把所有知識拆成愈細的意圖越好，讓機器人可以精準回答？」
確實，意圖拆得愈細，機器人愈能提供精緻的互動。不過，每多一種 intent，就得讓機器人多學一種回答方式，而且 intent 數愈多，彼此之間的語意距離便會愈相近、甚至重疊，而機器人無法區辨意圖的可能性便會大幅增加。
如何在體驗和開發複雜度之間取得平衡，是意圖設計的一大考驗。
Step 3. 資料生成（撰寫例句）
延續目前的架構。要如何教機器人聽懂「車款介紹、預約賞車、車款推薦、汽車周邊、保固維修、門市資訊」這些意圖呢？
這裡得要針對每個 intent，提供 utterance（例句），讓 AI 從中學習，「原來這個句子，是指向這個意思呀」。
舉例而言：
其實這裡在做的事情，非常類似資料標記（data labeling）：例如我們拿到一堆動物的照片，而我們想教電腦辨識狐狸，於是我們就對照片標記（label）哪張照片是狐狸、哪些照片不是狐狸，讓電腦從中學習狐狸和非狐狸的特徵。
照片是 data，狐狸/非狐狸是 label。而在自然語意理解的世界中，data 是各式各樣的句子，而句子的意圖則是 label。
更精確地來說，這個步驟是在做資料生成（data generation）。我們先有了一堆 label，而我們對每個 label 提供 data。我們先有了「保固維修」這個 intent，然後回過頭來告訴電腦「我車保險桿壞了、昨天發生車禍、車子被別人碰到…」這些句子是指保固維修。
Step 4. 標記實體（Entity）
如果我們期待電腦對於「請推薦幾台休旅車」、「請推薦幾台買菜車」這樣的句子，提供不同的答案，就必須標記出 entity，才能對不同詞彙提供更精細的答案。這裡的 entity 很明顯是車的類型：
請推薦幾台<carType>休旅車</carType>
我想找<carType>雙門跑車</carType>
...Entity 經常用來處理人事時地物的問題，例如：
我想預約<day>星期三</day> <time>下午三點半</time>賞車在 utterance 中標記完後，模型不僅會學習判斷 intent，更會去爬梳實體（entity parsing），讓理解力更趨精準。
結論
電腦對於排序、檢索等具有明確規則的事情，遠比人腦厲害，透過 rule-based 的做法可以非常快速地讓電腦掌握互動重點。不過，人類的語言具有高度歧義性，使用者輸入的語言很容易就超出 rule-based model 掌握的範圍。要建立夠聰明的機器人，透過 NLU 技術是不可或缺的。
除了本篇討論到的 intent, entity，還有 context（如何理解前後文）, unknown handling（機器人要如何知道「這句話我聽不懂耶」，避免亂答的情況發生） 等複雜有趣的問題。過些時間再推出續篇。
