2016/12/26

我認為一個良好的 chat bot 架構設計

名詞介紹:
intent:意圖,bot 能做的事情,可以想像成一個 intent 就是一個 function。
keyword:從一個句子當中擷取出的關鍵字,可以想像成是 function 的參數,舉例來說可能是日期、時間或地點、名詞等。

我們可以把 user 輸入的每一個句子看做是高維度空間上的一個點,然後我們對這個空間做分群,假設我們的 bot 有 3 個 intent,那麼整個空間就會被分為 4 群,多 1 個群是因為不做回應。

而句子座標落在哪一群,就代表著 bot 要使用哪一個 intent 來做回應,也就是說,我們可以把機器人回應變成一個對句子做分群的問題,然後套用分群演算法。透過標示每一個句子應該落在哪一個 intent 裡,我們可以強化接下來 bot 的精確度。

怎麼把一個句子變成高維度空間上的一個點,會是一個門檻。

如果要做到 bot 可以根據前後文來做回答,那麼 keyword 的記憶會變成是一個非常重要的關鍵,比方說:

user : 「你知道日本嗎?」
bot : 「知道阿」

user : 「好玩嗎?」
bot : 「蛤你說什麼東西好玩?」

像這樣的 bot 沒有記憶能力,他只能回應上一句話,他應該要把所有提到過的 keyword 都先記住(使用類似 session 的方式去記)。當 user 觸發一個需要參數的 intent 時,應該優先考慮前面提過的 keyword,當 bot 覺得前面提到過的 keyword 都不適合做為此次呼叫的 intent 時,再跟 user 要求一個新的 keyword。

另一方面,Function Currying 是比較容易的。
https://zh.wikipedia.org/wiki/%E6%9F%AF%E9%87%8C%E5%8C%96

user : 「我下個禮拜一想請假」
bot : 「想要請什麼假?」

user : 「想請病假,因為我下個禮拜會肚子痛」
bot : 「可以~很可以」

user 呼叫請假(日期, 假別),可以透過 Function Currying 拆解成 請假(日期)(假別)

也就是說,前面所說的分群,還需要考慮 intent 如果是有參數的,那麼 bot 現在是要延續前一個 intent 的 Function Currying 的呼叫,還是 bot 會認為 user 想要呼叫另一個新的 intent,這是分群演算法也要能做到的。

user 先叫 intent 後傳參數,看起來容易做。但是先傳參數,再叫 intent 就比較困難。判斷到底該使用哪一個 keyword 作為參數會是一個難題。

目前為止沒有看過任何一隻 bot 能做到這點,做得到就神惹。

在 intent 數量很大而難以設計出良好 UX 的情境下,那才會是 chat bot 的擅場。所以我認為一個 bot 在 intent 數量很少的情況下,應該做成 App 或 Web,而不是 bot。也就是說,做一個 bot framework 必須考量如何讓 bot 擁有者能夠輕易地新增一個 intent 。一個太少 intent 的 bot 行為看起來跟智障沒兩樣。正因為卡米狗能夠讓 user 很輕易地新增一個 intent ,所以卡米狗能夠看起來很聰明。卡米狗的下一步,是讓每一個 intent 能夠自動對應到相似的句子,而不是完全match,這樣就能看起來更聰明些。

現階段這種看起來像智障的 bot ,有可能會被全部都串到個人助理類型的 bot 作為 proxy,比方說 siri 會根據使用者的句子,決定現在該把訊息傳給哪一個 bot 來做回應,然後這個個人助理就可以看起來很聰明。

比方說我是 microsoft ,我開發了一個 microsoft bot framework, 我知道所有 bot 的 intent ,所以我能夠知道 user 輸入的句子應該用哪一個 bot 來做 proxy,所以我能開發一個個人助理,他可能有上百萬個 intent ,而這些 intent 是開發者輸入的.... 科科。

結論:想開發聰明的 chat bot ,就要先開發 bot framework。

LINE Taiwan TechPulse大會心得

https://linecorp.com/zh-hant/pr/news/zh-hant/2016/1604

為了展現 Line bot 的魅力,Line 決定採用 Line bot 的介面去做活動報名以及議程的顯示,中場遊戲進行等等,但UX還有待加強,比方說chat bot不適合用文字來顯示議程,可以考慮用 ImageMap 來顯示。

雖然說這是開發者大會,但是會場對於開發者來說非常不友善,因為會場沒有插座,也沒有一個能連的wifi,所以身為開發者的我感到呼吸困難。

不知道是不是有經費上的問題,中午沒有附便當,但是卻附了 XBOX、PS4 、茶點和很有誠意的伴手禮。

整個活動對於時間上的掌控是有問題的,計畫趕不上變化,說好的中午 12:00 到 13:30 吃飯時間,變成了12:40~13:40。在附近沒有餐廳的情況下,約300人同時離開會場去覓食,13:40 會場人數回來不到一半。

看起來 Line 應該是第一次辦活動,還有很大的進步空間。


之後的 Line 群組會有管理者權限功能,以後不用怕翻群了。

之後的 Line 群組可以有很多聊天室。

之後的 Line 群組可以開發 App 稱為 Group App。

Group App 跟 Line Messaging API 是兩回事。


根據統計,Mobile App 的成長量小於 Mobile Web,所以開發網站還是比較重要der~