我認為一個良好的 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~