4 posts tagged with "chatbot"

我的第一個 Google 助理服務「歷史上的今天」上架了，已列在 Google 助理服務 (中文) 列表中。

https://assistant.google.com/services/a/uid/0000005a1a233d97

相對於 Google 助理服務 (英文) 列表，中文的 Google 助理服務還不多，簡單分享一下開發心得。

如何使用​

這個 Google 助理服務的功能很單純，即從維基百科中隨機選出一條歷史上的今天所發生過的事。

要使用這個 Google 助理服務，可開啟 Google 助理，詢問「我想問歷史上的今天」，Google 助理就會啟動「歷史上的今天」服務。

怎麼做 Google 助理服務​

「歷史上的今天」資料取自維基百科，也希望任何感興趣的人都能來參與維護，因此選擇開源。專案頁面在 https://github.com/gasolin/todayinhistory

我所說的 Google 助理服務其實英文叫「Google Action」，可以用在各種 Google 助理 (Assistant) 支援的場景中，如手機，手錶，Chrome Book，Google Home 等。

歷史上的今天 這個 Google 助理服務由 https://dialogflow.com/ 託管，使用Cloud Function來回應使用者。Dialogflow與Cloud Function都是 Google 旗下的服務。

Dialogflow提供了各種語音 / 文字聊天機器人 (Chat bot) 的一站式訓練 / 開發 / 部署環境。除了 Google 助理服務，也可以在上面使用Dialogflow API 同時支援 LINE，Facebook Messenger 等聊天機器人。Cloud Function也被整合在 Dialogflow 中，讓開發者可以簡單地呼叫一段腳本執行命令，而不需要維護完整的網頁伺服器端程式。

開發歷史上的今天的過程中，只要在Dialogflow網站上開發，在 Actions on Google 中測試與發佈即可，整個流程甚至不需要下載資料到電腦中。

如果對程式本身，或對每天可能會收到的回應感興趣，專案頁面在 https://github.com/gasolin/todayinhistory ，歡迎造訪按 Star，也歡迎前往 https://assistant.google.com/services/a/uid/0000005a1a233d97 留下好評。

可以透過 QRCode 加入營養成份 LINE bot。

Update: 謝謝大家熱烈試用「營養成份 bot」, 因為測試帳號已達 50 人的上限，所以將遷移到新的無人數上限的「營養成份 2 bot」，請點選新的「營養成份 bot」邀請連結 https://line.me/R/ti/p/%40hoz2085q

歡迎分享新連結給可能需要的朋友，讓大家隨手查營養，吃得更健康。 (目前的 bot 仍然可以使用，但不再更新維護)

食物，運動，與身體平衡​

最近在看代謝型態飲食全書，裡面提到吃下的東西與運動，與體內的平衡和慢性病的產生有相當密切的關係。要讓身體重新回復到平衡的健康狀態，需要選擇適合自己的食物（營養素的比例）並搭配適當運動（有氧 + 無氧）與充足睡眠。

其中我們所選擇的一天三餐與餐間的飲食習慣，則是潛移默化地影響我們的健康。 當我們持續吃不好的食物或錯誤的營養素比例，則讓體內的系統處在有的養分過多，有的養分不足的持續不平衡的狀態。這些不平衡讓各種體內各種系統無法正常工作。例如一餐吃進過多的精製糖份可能造成血液中的糖份快速升高，胰臟必須快速分泌大量胰島素來協助細胞消化糖份，當這樣不平衡的狀態維持久了，就會造成胰臟的過度負擔。當體內的代謝開始失常時，我們可以先觀察到一些亞健康症狀，累積久了就成了各種慢性病。因此選擇適合自己的食物是相當重要的。

Bot 怎麼做成的​

要選擇適合自己的食物時，我除了先做了測驗了解個人飲食中三大營養素 (碳水化合物、蛋白質、脂肪) 的參考比例，也想知道每樣吃下的東西大致的營養成份。

我想到如果有各種食材的營養成份資料，就可以做成聊天機器人或 App 以供隨時查詢。我搜尋了一下，發現政府資料開放平台上有公開的「食品營養成分資料集」，提供 csv, json, xml 等格式下載。

下載開啟資料後，發現原始的 JSON 格式還是蠻.... 有趣的。

下載的 JSON 格式資料長這樣：

[{"食品分類":"魚貝類"},{"資料類別":"樣品基本資料"},{"整合編號":"J11101"},{"樣品名稱":"鮸魚"},{"俗名":"鮸仔,敏魚,鮸,敏仔魚"},{"樣品英文名稱":"Brown croaker; Mi-iuy croaker"}

... 對於這種 JSON 存法只能... 呵呵。

重新下載了 csv 檔，這次看到的格式總算正常了點，但解開後的 csv 檔案有接近 50MB 大小。寫了個腳本過濾掉不需要的資料，並轉換成需要的格式後，輸出總共不到 500KB，這樣的大小就算放到 App 裡也還合適。

這次使用bottender框架來連接到 LINE¹。由於 LINE 需要 HTTPS 連線，開發的過程中使用了ngrok來讓 LINE 可以連到開發中的電腦，免去另外架設公開網站的麻煩。

此外還使用了Fuse.js這個模糊搜尋函式庫，在搜尋的時候只要打部份內容，就可以搜出相關的條目。

整個 bot 的軟體架構如下

開發中遇到的小坑​

• developer channel or free channel

剛開始申請用 developer channel ，因為所有 API 都可以使用，開發起來會比較順暢。但稍後就遇到了 Bot 只能加 50 人好友的限制。

• Push Message vs Reply Message

developer channel 可以用 Push Message API (也就是 bottender 範例中接的 sendText)。free channel 的話不能使用 Push Message API (context.sendText)，只能用 Reply Message API。也就是不能推送訊息，但可以回覆使用者訊息（至多五筆）。查了一下文件²，雖然需要稍微改變一點寫法 (context.reply)，但還算容易解決。

現在上線讓大家使用的已是改用 Reply Message API 的版本。

我可以加這個 Bot 嗎？​

可以透過掃描 QRCode 加入營養成份 LINE bot。

或點選以下連結

因為使用免費的 Host，不能保證 bot 永遠在線，若第一次沒回應，可以稍等半分鐘後再試。

會不會 Open Source​

目前程式還沒有好好整理，尚不打算開源。

參考資料​

• [1] https://bottender.js.org/docs/Platforms-LINE
• [2] https://bottender.js.org/docs/APIReference-LineContext#reply-api---official-docs

聊天機器人（Chat bot）已存在許久，常見於各種即時通訊工具中。一般人最可能接觸到的，還是銀行的語音服務（Voice Response System）。

當我們打電話到銀行免付費專線，會有語音提示我們輸入驗證資料，然後輸入對應的數字來得到銀行服務。 只有在根據一串語音提示，輸入特定數字時才轉接到真人回應的專線。這個過程跟使用聊天機器人基本上是一樣的。

銀行的語音服務流程

行動裝置的完全普及​

近年來聊天機器人能重新進入公眾視線，主因還是行動裝置的完全普及： 幾乎所有的人都擁有一台智慧型手機。而且所有人的手機上都有一至數個聊天 App（LINE, Facebook Messenger, Wechat）。

邏輯思維 2017 年跨年演講¹裡提到，美國，中國想上網的人基本都已經能上網（上網人口已經接近飽和），人們每周平均花 24 小時上網，而這些數字都已經沒有太大的提升空間。因此所有的網路服務都得從有限的總量中搶占使用者的上網時間與關注。

換句話說，2016 年我們已正式進入行動網路（移動互連網）的下半場，廠商除了需要想方法佔用更多使用者上網時間之外，另一條路或是協助使用者更有效地利用上網的時間。

聊天 App 佔用使用者更多上網時間​

2016 年初的調查顯示，人們每天平均在手機和在電腦上所花的時間差不多。 隨著手機 App 的發展，人們能透過手機完成的事也越來越多。可以預見到的是人們每天花在手機上的時間佔比會再增加。 人們在手機上花費最多時間的是聊天 App 和社交 App。而今天的聊天 / 社交 App 都已內建網頁檢視（webview）功能。 看到「朋友」分享的新聞連結，點選後可以直接瀏覽內容，完全不需要另外再開啟瀏覽器來查看新聞。

由於聊天 App 佔用了使用者多數的時間，依照「使用者在哪，機會就在哪」的原則，聊天機器人，或是對話式界面 (Conversational UI) 成了一個選項。

Siri, 聊天機器人的濫觴​

這波新一代聊天機器人的濫觴，也許可以歸功於 2011 年蘋果推出的 Siri²，雖然 Siri 並不存在於聊天 App 中。 iPhone 的使用者可以透過手機上的 Siri 智能助理應用，做到用口語詢問近期天氣，日程表，查詢地圖，餐廳，設定鬧鐘等行動，從而用更便利的方式取得服務。 雖然今天 Siri 與其他選擇相比，已盡顯不足之處，但當時 Siri 的推出，讓人們感知到與機器直接對話已不再遙不可及，這直接鼓勵了眾家廠商願意加大投入。

近幾年語音辨識，人工智能 AI 的爆發式進展，與此必然有著千絲萬縷的聯繫。

聊天機器人有什麼用？​

Reddit 曾有用戶提問，如果某個 1950 年代的人突然出現，最難向他解釋的現代事物是什麼？
最多人推的回答是： 「我擁有一部機器，就放在我的口袋裡，我可以用它來存取任何人類已知的知識。
我常用這個來看貓咪的圖片，還有跟陌生人筆戰。」
-- @wastemobile

就像现在手机 App 一样，大部分的 App 其实没什么用，用了只是消耗自己的时间。 但是像 Siri 所能做的，使用者透過聊天機器人簡化日常的瑣事，或是快速得到常見問題的答案。 Slack 平台上已有許多機器人，可以同步 Github Bug，同步代辦事項資訊，提醒今日任務等。這些 Bot 能省下使用者寶貴的線上時間。 我們更多需要的是這類型（用更便利的方式取得服務）的聊天機器人。

聊天機器人與使用者的互動方式​

在網際網路上，沒人知道你是一隻狗

聊天軟體原本的功用是讓使用者可以和「另一個使用者」或「一群使用者」交流。聊天機器人則是取代「另一個使用者」的角色³，讓使用者和「聊天機器人」一對一交流，或是讓聊天機器人加入群組，和「一群使用者」交流。

一對一

群組（多對多）

聊天機器人的應對方式​

除了「一對一」，「群組」（多對多）之外，依據聊天機器人的應對方式，還可以分為通知型（Notify），模式型（Pattern Matching），對話型（Context Aware）等幾種聊天機器人⁴。

通知型（Notify）​

通知型機器人會根據使用者「訂閱」的資訊，傳訊息通知使用者。例如明日天氣預報機器人可以定時告訴使用者明天氣象狀況與溫度，出門需不須要帶傘。 使用者一般不需要輸入任何訊息與機器人對話。

模式型（Pattern Matching）​

模式型機器人會比對使用者送出的訊息，如果符合機器人設定好的一些模式，就做出對應的回應。

例如使用者可以透過天氣機器人，輸入 "weather in Taipei" 查詢當前台北的天氣。

基本的模式型機器人沒有對話的概念，並不會根據使用者過去的應對而改變回應的結果。 例如使用天氣機器人時每次都需要指定想查詢的地點，或是透過預先設定地點 / 偏好溫度格式來簡化使用方式。

除了傳統使用正則表達式 (Regex) 來比對模式外，Facebook Messenger bot 則提供更接近口語的自然語言處理（Nature language Processing）模式比對。 多數聊天機器人框架目前都仍偏向模式型。

對話型（Context Aware）​

對話型機器人會從與使用者過去的對話中提取使用者的偏好，並運用到後續的對話中。

例如 Google Assistant 會根據你之前的查詢，去進一步找到你想听的音樂。

能理解與使用者過去的對話，也是對話型人工智能的重要特徵。當使用者在聊天軟體中新加入一個 bot 服務，使用者與這個服務的對話都與和一般服務員的交談無異，那麼服務的後面是不是真人還重要嗎？

參考資料​

• ¹ 羅輯思維 4 小時跨年演講 https://kknews.cc/zh-tw/tech/xz2x4p8.html
• ² https://en.wikipedia.org/wiki/Siri
• ³ 在網際網路上，沒人知道你是一隻狗
• ⁴ Bot Design Patterns

「聊天機器人一份，不加咖啡」是今年在 Coscup 2016 分享的講題，投影片在此。 內容包含介紹聊天機器人與 Hubot，轉換 Coffeescript 到 ES6，與移植經驗總結。

Webbybot 是我們將 Hubot 完全移植到 ES6 的成果。在準備這場演講時，有鑑於 Server Side 聊天機器人設定上還是稍嫌複雜，於是我參考 Hubot 架構，做了原始版本只有 80 行的網頁端聊天機器人。除了支援聊天機器人基本功能外，同時也支援擴充腳本 (plugin) 與擴充功能 (addon)。由於參考了 Hubot 架構，於是命名時就取了Saihubot 這個既包含 Hubot，又有濃濃台味的名稱（SaiHu 即台語的「師傅」）。

這次活動官方有提供 LINE 版的聊天機器人。我在活動早上花幾小時基於 Saihubot　做了　Coscup 2016 網頁版機器人，可以上去玩玩。

要做一個自己的網頁聊天機器人，只須在 github 上 fork 專案，然後就可以直接在 Github 上編輯，修改後的結果直接反應到 https://[your name].github.io/saihubot 網站上。修改極端容易，畢竟核心只有不到 100 行，對聊天機器人有點興趣的人可以照著上述說明試試，看看原始碼，當然若能送個 Issue 或 Pull Request，這場「扎根」議程達到的效果就最好了。