AppCoda在台舉辦開發者聚會,引爆後APP時代聊天機器人熱潮

IMG_2449

AppCoda是全球知名的iOS教學部落格,許多人的第一隻APP應用程式都是看這個網站寫出來的。創辦人Simon自昨天(3/24)起在台灣一連舉辦三場開發者聚會(北、),除了分享最新的聊天機器人開發之外,並舉辦Light Talk、現場抽獎等活動,十分熱鬧。

IMG_2451

Simon這次帶給台灣開發者的分享是「如何於iOS實作AI聊天機器人」,這可說是最近潮到翻的話題。至於為什麼Simon會選擇這個主題,原來行動開發學院也是幕後的推手之一:

IMG_2453

感謝Simon引用,不過下次不需要特別在後面註明,這個魔鏡說的大家未必認同 XD ,就是個博君一笑的應用就是了。

言歸正傳,那麼Simon用了哪些東西來完成他的APP聊天機器人呢?

  1. 聊天的介面:JSQMessagesViewController (我的老天鵝啊,這個專案竟然有一萬多個星星,找時間來玩一下)
  2. 自然語言處理器:API.ai (今天的主角)

API.ai是一家已經被Google收購的聊天機器人開發工具商,能夠提供開發者整合聊天服務機制於App、網站或是直接建立聊天機器人於社交軟體中。

那為什麼沒事要搞個聊天機器人呢?其實正確地說,我們想要建構的是聊天室的介面,也就是最近很夯的Conversational UI。

在過去,我們會透過網頁的介面、APP的介面,類似表單的方式進行資料輸入,或是輸入查詢的條件,來獲取或儲存資料。某種程度來說,不論表單的介面做得再怎麼「友善」,還是比不上一個專人為你服務來得親切,這也就是每每總是令你火大的客服專線,設置了一堆選項你還是只想按9轉接專人服務。

但是專人服務的成本很高,我們有沒有可能讓使用者有「專人」的錯覺,但是卻享有專人般的服務呢?這就是現階段聊天機器人最常做的功能,以問答的方式,取代過去的表單頁面,完成查詢條件的輸入

那這件事情的難度在哪?原因在於語言這一種東西有其模糊性。我們對同一件事情的陳述,通常會有好多種說法,更可怕的是,同一句話,也很有可能因情境、上下文,而有了不同的意義。有時連人與人都很容易會誤會了,更何況是機器呢?

Screenshot 2017-03-24 14.58.17

所以這個棘手的問題,當然就得交給人工智慧專家,透過「模糊理論」、「類神經網路」等等的技術,能夠知道該怎麼分類、對應,讓機器像個人似的看得懂圖片、聽得懂人話,還能夠與你形成「有意義」的對談。這真的很困難,因為仔細一想,你是否也曾經跟許多人講話,感覺有「代溝」、怎麼講都「講不聽」的感覺呢?XD

那我們不是人工智慧專家該怎麼辦?這是一個分工的時代,那一段就交給幾個大型的雲端服務商吧 (乖乖打開錢包)

舉個例子來說,我們希望建立一個可以回答天氣的機器人,所以這個機器人一定要接收到的訊息有:

  • 日期:使用者想問哪一天的天氣
  • 位置:使用者是想問哪個地方的天氣

所以以上兩項必要的資訊就稱之為Entity,日期跟位置都是很常見的資訊,所以可以直接套用系統層級的Entity:@sys.date、@sys.geo-city

接著問題來了,使用者問天氣的句子可能千變萬化,所以你要開始訓練你的機器人,當缺少以上必要的Entity時,機器人要回問的句子,以及使用者問了什麼句子,就代表已經提供了上面的Entity資訊。

一旦訓練完成後,使用者就可以透過與機器人的簡短對談,達成輸入「日期」與「位置」這兩項資訊,進行天氣的查詢動作。

API.ai可以回傳給你JSON格式,包含以上的兩項資訊,那麼你就可以利用這些資料,再介接例如天氣的開放資料,完成整個查詢動作。

這項服務不僅可以利用文字查詢,也支援口語輸入,所以站在它的肩膀上,什麼語音辨識、語意判斷,這些通通都交給它了,是不是非常方便呢?

IMG_2477

最後,換我來引用一下Simon的話,最好的學習方式就是,捲起袖子開始試試,不論是多小的應用,都將會是一個美好的開始!一起動手做做看吧!


IMG_0824

Ryan Chung

任職於資策會IT訓練中心,曾遠赴德國擔任難民組織網頁工程師,也在美國Udacity擔任行動開發專案審核員。對於資訊教育有著無比的熱情,最新的玩具是不會講中文的Echo Dot。