關於寫對談機器人 (bot) 的兩三事

最近在軟體開發圈,無處不碰到有開發人或團隊想開發對談機器人(Chat Bot,常會被簡稱為 bot,以下我也以 bot 簡稱之),做為一個技術傳教士,幾個月下來也接觸到不少有興趣開發 bot 的團隊,從這些團隊中我也學習到不少經驗與心得,所以想寫下來與大家分享或交流。

對談機器人不是新玩意兒

雖然今年開始很多軟體公司開始拋出 bot 的相關開發議題,例如微軟提出的對話即平台(Conversation as a Platform) / Bot Framework / Skype SDK、Facebook 提出的 Messenger Platform、apple 也把 iMessage 變成開發平台、或是 Line 也正式推出 Messaging API 等等,但早在這些東西之前就有許多通訊平台已經提供 API 讓開發人員寫 bot 了,那為什麼今年開始大家又在炒熱(?) bot 開發的話題呢?

軟體開發又將進入一次典範轉移…

軟體開發之時代的眼淚

想一下你什麼時候會想要開發軟體,答案不外乎是在自己或是許多人花最多時間的平台上(可能)沒有好用的工具覺得想寫一個提高自己的生產力、或是做為知識財識來販賣價值,隨著時代的演進,人們花在平台上的時間也跟著不斷轉移,所以軟體開發商也從桌面、Web、一直到行動裝置上開發應用程式(甚至一度在社交平台上開發應用程式或遊戲也成為顯學),畢竟軟體寫出來就是要有人用,人潮在哪裡,機會就在哪裡,而近年來在許多調查或研究中都顯示人們花在通訊應用上的時間遠遠超過使用其它應用程式的時間,這也直接說明了通訊平台無疑是下一個軟體應用的機會,而在通訊平台上的應用程式呈現方式,自然就是 bot 了。

資料來源:BI Intelligence, Portio Research

對談機器人與數位助理不同

很多人剛接觸到 bot 的議題,會與 Microsoft 的 Cortana、apple 的 Siri 或是 Google 的 Google Now 聯想在一起,接著會好奇:「我會做得比這些公司還要好嗎?」這其實是把 bot 誤解成了數位助理(digital assistants,如上述的 Cortana/Siri/Google Now 等),這兩者在本質上有很大的不同:Bots 的目標是專注在解決單一問題、特定任務,而數位助理則是希望可以幫你完成所有大小事(就算自己做不到也會開放 APIs 來擴充)

Bots are the new apps;
Digital assistants are meta apps

舉個簡單的例子,就拿披薩店來說好了,Bot 就像是披薩店的櫃檯人員,他的任務就是完成你買披薩的需求,他會聆聽你的需求、提供餐點資訊、確認你的訂單、完成結帳與遞送比薩,雖然他可能會問你怎麼稱呼、取得信用卡完成結帳,但是他不會記錄你的隱私訊息(正常狀況下應該都是如此),下次你要來買披薩時還是要提供資訊來買披薩;數位助理則不同,它就像是你的貼身秘書,知道你所有的口味偏好、要不要副餐飲料、甚至可能還擁有你的信用卡或支付帳號,它能直接幫你買披薩,但它不是只能做這個工作而已。這裡可以簡單做個結論:你與 bot 的互動是交易式(transactional)的行為,而數位助理則是默默地記錄你的一切做出最合適的動作。

對談機器人並不是全新的軟體開發模式

大多數人都不太習慣改變,一聽到新的軟體典範出現,要嘛假裝看不見,不然就是大喊又是新的炒作等等,想到自己投入在 web 或行動裝置上的應用程式開發這麼久,難道又要一次砍掉重練嗎?其實不然,接續著前一段的例子,如果你本來為披薩店的點餐做了一個行動裝置的應用程式,難道改成 bots 就不會處理點餐邏輯或是後端資料庫的部份嗎?只要你冷靜下來思考,其實在系統架構下,不管是寫 web、app 還是 bot 其實都是一樣的,差別只在於呈現(presentation)的方式不同而已,開發 bot 不代表要全部重來,這些商業邏輯還是繼續為了完成任務服務著;而開發 bot 也不代表就不用處理系統的延展性問題,除非這個 bot 沒有人用……

Human language is the new UI

開發對談機器人可能會遇到什麼狀況

好吧,當作你已經被說服要開發 bot 了,那可能會遇到什麼狀況呢?

通訊平台那麼多怎麼辦?

在行動裝置時代,如果你要接觸到最多的用戶,你可能至少就要維護 3 個專案——Windows/iOS/Android(OK,我知道絕大多數是其中 2 個),在通訊平台這個百家爭鳴、各地區或不同用途還流行不同平台的戰國時代,如果要通吃所謂的大多數平台,開發團隊可能要維護超過 3 個以上的專案,而且還得不斷追著改版是家常便飯的 API 呼叫格式,這樣聽起來不太誘人,所以市場上也有不少解決方案試圖減輕開發團隊的負擔,其中一項(畢竟我是微軟的技術傳教士)就是 Microsoft 的 Bot Framework

Microsoft Bot Framework

Bot Framework 的核心任務是希望讓開發 bot 的團隊可以盡可能地只要開發一支 bot 程式,然後幫你接上多個通訊平台(例如:Web、Skype、Slack、Facebook Messenger, …),使用這個 framework 並不一定要部署 bot 到特定平台,可以是任何 HTTPS 能存取到的地方。這個 framework 包含三個部份:

  • Bot Builder SDK: 開發 bot 的軟體函式庫,目前開源提供 C# 以及 Node.js 兩個版本,雖然它某程度上設計了一套 API 通用於各個平台,但也提供彈性讓你可以針對特定平台有特定的回應格式(例如在 Facebook Messenger 中以 Card 格式回覆訊息),不必擔心因為用了通用平台而只能做出單調的 bots。
使用 Bot Framework 開發的 Facebook Messenger bot 也可以回覆其特有的 Airline template (Photo Credit: Shih-Ming Tung)
  • Bot Connector: 這就是 bot framework 要幫你接上各大平台的部份,在其支援的平台中,只要你將需要的資訊(通常是該平台的 appid 及 secret )填妥,Bot Connector 就會幫你接通與該平台的通訊。支援的平台陸續會增加,但若是你想連接的平台還未在支援列表中,Bot Connector 也提供了 RESTful API/Direct Line 的方式讓你串接,盡可能地把 bot 的處理邏輯集中在一起。
Bot Connector 最基本會給你一個 Web 介面的機器人讓你嵌在網站中
  • Bot Directory: 就是一個公開展示的平台,除了 bot framework 的網站之外,其它微軟的平台(例如:Bing、Skype、Windows、Surface 等)也會做為推薦的內容推薦給使用者,讓你利用 bot framework 開發的 bot 可以增加更多曝光機會。

Bot 如何更加有人性或智慧

寫 bot 雖然說穿了就是把對話當成 UI,然後接上平台的 APIs 完成接/收訊息,但是如同寫 web、app 一樣得重視使用者經驗(UX, user experiences)才能讓使用者愛上並經常使用,而 bot 的 UX 最重要的不外乎就是自然語言的處理(NLP, nature language process)能力,以及表現得像個真人

自然語言處理,當然坊間已經有許多各式各樣商業或開源的引擎,而微軟也將原本在 Bing/Cortana 中使用的 LUIS (Language Understanding Intelligent Service) 開放出來,這是一套語言模型學習引擎,你可以自己定義語言的動機、關鍵字詞等等,然後自行訓練它的理解能力,而訓練完成的語言理解模型也可以直接變成 web service,方便與其它應用程式介接。在前一段截圖中的請假機器人,就是結合 LUIS 來做語言理解的引擎。

用 bot framework + LUIS 開發的請假機器人我將它開源在此作為參考
LUIS 的操作介面,你可以定義一個領域的動機及關鍵字,然後不斷透過真實語句訓練它

而 LUIS 只是單單一個理解語言用的引擎,微軟不僅釋出這個引擎,更將所有 Bing/Cortana 等許多原本內部單位在使用的智慧型服務都以 API Services 的形式釋出,這一系列的 API Services 為 Microsoft Cognitive Services,你可以在上面找到許多關於視覺、語音、語意、搜尋與知識網路等服務,透過這些服務的整合,你的 bot 更容易表現得像個真人!

Microsoft Cognitive Services 讓你輕易為 bot 或應用程式加上人性或智慧

雖然有了這些服務加持(當然不只微軟有提供這些服務),但在設計 bot 的過程還是要思考怎麼適度地使用這些服務為軟體加值,而不是一股腦地拼命呼叫這些 APIs,畢竟呼叫愈多、付得愈多。

總結

拉拉雜雜寫了一些心中的感想,希望有機會與各位有興趣開發 bots 的開發人員進行交流,或是能聽到使用這些技術(特別是微軟這些服務與其它類似服務的比較)的各種心得,歡迎直接跟我聯絡。最後希望對談機器人的開發熱度能愈來愈高,讓我們有更多方便、智慧型的服務可以完成手上的任務。