2018/07/30

chatbot 不能笨得像是問券調查,也不能太聰明像是真人

使用者已經厭煩不斷地安裝手機 APP,安裝了 APP 卻又很少打開來使用,自 2016 年 4 月 Facebook、Line 陸續發表聊天機器人 API 後,情況似乎有點改變,整個行銷活動,轉向了 chatbot,使用者在每天持續打開FB或是Line的狀況下,透過 chatbot,讓所有品牌跟廠商連接到了使用者那端。

過了 2017 到現在 2018 兩年,chatbot 的戰場可說是百家爭鳴,基本的核心 IM 平台已經很難有新進的服務,也沒有什麼改變,為了搶食 IM 平台上跟終端使用者聯繫的最後一哩路,圍繞在 IM API 上提供的服務及工具。

觀察一個 chatbot 的成功案例

AsiaYo 如何在一週內打造破萬使用者的 Chatbot!這篇文章中,說明了AisaYo 如何透過聊天機器人連貫起使用者之旅程體驗。他們以 UX 和商業的考量去定義 AsiaYo Chatbot 所應該賦予的功能,希望能協助旅客在訂房的前、中、後做決策及輔助。AsiaYo chatbot 經過了兩個版本的歷程。他們認為在旅遊訂房產業適用的設計的重點是:提醒與無縫式對話情境。也就是情境式的對話體驗,以及引導式的交談結構。

過程中的重點是在使用者瀏覽 AisaYo 旅遊資訊時,透過 cookie 收集資料,並在使用者瀏覽途中,彈出一則模擬 Facebook 對話視窗。如使用者同意接受對談,就將對話內容轉至 chatbot,並繼續以聊天機器人進行對話。且在使用者二次造訪 AsiaYo 網站時,便不再傳送訊息。

儘管 AsiaYo 利用模擬對話提示使用者,但仍然有少數消費者和 Chatbot 互動的過程中仍會察覺到自己被追蹤,並且對於追蹤的技術感到疑惑,造成使用者誤會侵犯隱私,加上對話的形式也會接續所追蹤的內容,所以少數消費者收到通知時會一頭霧水,此時的使用者體驗反而會降低。

在這個開發的過程中,可發現兩個重點,首先 chatbot 必須要夠聰明,不能太笨,一問一答當中,都是用固定的話術套路,交談的文字語氣,會影響使用者的感受,但是如果 chatbot 太聰明了,讓人覺得被騙了,原來不是真人,這時候反而會產生反效果,所以在 chatbot 進行前,需要適當地揭露,接下來是由專屬的機器人協助處理。

Google Duplex

最近最熱門的影片【超狂影片展示】Google AI 助理新把戲:幫忙打電話到餐廳訂位,等等你確定這不是真人?,展示了 Google Duplex 為基礎的 Assistant 功能,雖然只是代理「客戶」訂位,聲音幾與人類無異,不但能與店員來回對話、協調時間,還能在句子中適切加入「嗯…」、「呃哼」、「哦」等語助詞,成功在對方毫無察覺情況下完成預約。

然而這樣的技術產生了反效果,也導致 Google 必須強調他們將為Duplex加入自我揭露的功能,確保Duplex系統「適當表明身份」,Duplex太逼真嚇壞人,Google將讓AI語音助理表明「我是機器人」,Duplex 的表現嚇壞不少人,也引起批評聲浪。有人認為AI和人類聲音應該要加以區隔,就像刻意在無色無味的瓦斯中加入臭味,合成聲音應該就聽起來是合成的,任何以假亂真的事物將破壞信任,而當沒有信任就會引發失序。

同級生

有足夠年紀的人,應該還記得這個「同級生」這個戀愛遊戲

1992年發行的「同級生」確立了戀愛遊戲的基本形式。在典型的戀愛遊戲裡,玩者操縱一個被女性角色包圍的男性主角,透過交談選單選擇的形式,與女性角色交談,以增加該角色對主角的「好感度」。

當遊戲結束時會根據「好感度」和遊戲內發生的特定「事件」來決定遊戲的結局。這種遊戲通常會有多種結局,而玩家會重複多玩很多次,目的就是想要看到不同的結局。

有發現關鍵字「交談」跟「選單」嗎?戀愛遊戲就像是一個超級龐大的 chatbot,不過遊戲內操作的目標比 chatbot 簡單,就是記錄男主角跟其他每一個女性角色的好感度跟事件。

如果 chatbot 的使用者把 chatbot 當作女性角色在攻略,心理上就會有一玩再玩的衝動,但如果只是把 chatbot 當作是一個存取資訊的方式跟窗口,chatbot 表現出來的講話方式,跟笨拙的選單功能,不夠聰明的話,就會有惹惱使用者的風險。

基本上就是這個事件:誤交損友:微軟的聊天機器人是怎麼被計畫性「攻陷」帶壞的?發生的原因,因為微軟設定,Tay 是一名 19 歲的機器少女,使用者計畫性地不斷地以話術攻陷 Tay,導致一天內這個 chatbot 就下架了。

人工智慧畢竟還是人工

史丹佛大學人工智慧實驗室主任,同時也是Google雲端人工智慧既機器學習首席科學家李飛飛最喜歡的說法是:「機器很快、很精準,也很笨;人類很慢、不精準,但聰慧(Brilliant)。」。換句話說,人工智慧這麼聰明的原因,是因為實作人工智慧的工程師夠聰明,能夠讓這麼笨的機器,進行動態的思考與處理,但仍然是「有範圍」的聰明,因為再怎麼開發,也沒辦法做到什麼都會的人工智慧。

這樣說好像有點過分,畢竟「術業有專攻」,也沒有一個真人能夠樣樣精通。就像是自動駕駛的問題,我們會要求自動駕駛必須要「零」風險,然而自動駕駛如果是代替一個真人開車,真人是不可能完全迴避車禍風險的,但要怎麼要求人工智慧自動駕駛要零風險?從另一個角度想,既然這項新科技,是為了協助人類,避免做出失敗的決策,如果將 AI 視為機器設備的一部分,而不是取代人工,那麼必須要求零風險才能上路,否則只要 AI 出現異常,就算是機器故障,因此不應該貿然上路。

智能音箱是另一個必須要真人互動的 AI 科技,在 Amazon Echo 打開了低價智能音箱的市場後,各家科技大廠就先後推出智能音箱產品,搶進智慧家庭的一環。在 當智能音箱跌破百元,它們看上去更像玩具了 這篇文章中提到,音箱最重要的還是音質,再搭配 AI 晶片,而晶片的優劣決定了音箱到底夠不夠智能。

因為 AI 晶片不夠聰明的關係,聽不懂用戶在說什麼,或誤解用戶的意思,不少智能音箱被用戶怒噴為智障,是目前該領域非常嚴重的一個問題。很明顯的,智能音箱現在還沒有太過於聰明的問題,因為使用者在使用時,明確地知道自己是在跟機器對話。

chatbot 因為要跟其他人類互動,太像真人的科技反而會造成恐慌,而自動駕駛完全是機器跟資料處理的世界,這項科技必須要非常聰明,到完全零風險,才會被市場接受。

該怎麼做

Chatbot 的拐點之年這篇文章中,提供了 Facebook 跟營銷商會面並對 Messenger 做相關表述時,列出了三種 chatbot 類型

  1. 真人:僱傭人類職員回答入站信息
  2. 以樹形檢索為基礎的決策機器人:它們有固定的、自動的對話路徑
  3. 人工智慧機器人:能夠使用自然語言以及計算機技術進行更為廣泛的對話。

而他們建議最成功的 chatbot 應該介於第二種和第三種之間。更實際的做法是,透過一家科技公司的協助,能針對每一個問題,找到25種正常人對一個問題的反應的對話腳本,這樣的交談分析結果,讓 chabot 有了生命,也更能跟客戶進行長時間的交談,當然為了避免 Tay 那樣的問題,chatbot 所能處理的事情有範圍限制,他會嘗試讓客戶的對話回到能夠服務的主題上。

在 IM 中的 Menu,有點像是走回瀏覽器的老路,不過這個方式,確實引導了對話的進程。雖然純文字自然語言的交談互動,讓使用者覺得親切,但更多的狀況,是純文字的打字過程,增加了使用的難度,選單的確讓整個交談的過程變得更順暢,但相對地讓「交談」這個事情變得無趣。

使用菜單結構或傳統的用戶介面結構,幾乎都是認輸的表現,如果走向了某種極端,讓 Chatbot 變成Messenger平台上一個小小的Web視圖,這就很難讓用戶感到愉悅或者吸引用戶來使用了。

References

你做的聊天機器人像個人工智障?六個實戰指南幫你的機器客服找回智商

持續的互動需要持續理解背景信息 EQ 跟 IQ 同樣重要

打造跨平臺企業級Chatbot,Google Bot引擎Dialogflow正式版來了

如何用聊天機器人創造 150 倍的自然觸及|Mr.Reply 教學

必須先設定 訊息腳本,再來則是設定 觸發訊息腳本的規則,最後才是設定 貼文留言自動回覆的條件。

留言回覆的訊息千萬不能只有一種,因為會有非常高的機率被 Facebook 封鎖留言功能,建議至少設定 3 種以上的留言回覆,讓 Mr.Reply 自動任意回覆即可。

2018/07/23

RTSP/RTP vs RTMP vs WebRTC vs HLS vs SIP/RTP

多媒體資料包含了語音及影像,因為原始資料不同,壓縮格式也有差異,在一個影音資料中,通常包含了這兩種獨立的媒體,如果遇到多國語言的狀況,也可能會看到一個影片中夾帶了多個語音。當多媒體資料放到網路上,為了達到一邊下載,一邊觀看的功能,我們需要 streaming media 的網路協定,幫助我們將影音資料壓縮後,搭配協定傳送到收視端,透過媒體播放器解壓縮,並播放出來。

串流 streaming 的意思就是將影音資料壓縮後,切割成多個區塊的網路資料,分開但連續地發送給客戶端,客戶端不需要一次將整個多媒體資料下載完成後,才能播放影片,而是透過即時下載的分塊資料,先暫存在 buffer 中,只要客戶端有了幾秒鐘的影音 buffer,就可以一邊繼續下載,一邊播放影片。

骨灰級的使用者,可能有聽過 MMS(Microsoft Media Server),或是 RM(Real Media) 這兩種串流多媒體的標準,但現在幾乎都已經消失了,取而代之的是 RTSP, RTMP, WebRTC, HLS 及 SIP 這些協定。

RTSP

RTSP(Real Time Streaming Protocol) 是用來控制遠端多媒體的播放、錄製、暫停的控制協定,有點像是遠端遙控錄放影機的感覺,我們在網路的遠端,發送 RTSP 的控制指令,告訴 Server 我們想要看哪一個影片,找到後,就開始播放影片,也可以暫停。RTSP 協定中,看不到影音資料的內容,因為真正的影音資料是透過另一個協定 RTP(Real-time Transport Protocol) 發送的,在 RTSP 中,Server 會以 SDP(Session Description Protocol) 的形式,將 RTP 影音的資訊,包含 UDP Port,影音的壓縮格式等等資訊,告訴 client 端。

SIP

跟 RTSP 功能比較相近的是 SIP(Session Initiation Protocol),SIP 也是一種多媒體的控制協定,RTSP 像是個網路影音播放器,但 SIP 卻是一種網路電話,SIP 本身也只負責處理通訊的對談建立以及掛斷的處理,真正的影音多媒體資料,也同樣是由 SIP 以 SDP 的方式描述 RTP 影音資料的資訊,透過 RTP 將影音資料傳送到另一端,因為 SIP 是建立雙向對談的協定,因此 RTP 影音會是雙向的串流。

同樣的 RTP 的影像以及語音是分開在不同的 UDP Port,這個 Port 是透過 SDP 在通訊建立時,即時雙向建立起來的。因為電話這種應用必須要一邊講一邊聽,這是最常見的一種串流媒體的應用。

SIP 跟 RTSP 的基本差異在於,SIP 是雙向影音,而 RTSP 是單向點播,雖然說是這樣,但 RTSP 還是可以做到雙向視訊通話,不過那已經不是該協定的應用本意。目前 RTSP 最常見的應用場景是網路攝影機。

RTMP

RTMP(Real Time Messaging Protocol) 是由 adobe flash player 引領的串流媒體協定,因為 flash player 在過去的網頁曾經霸佔了很長一段黃金時代,只要裝了 flash player,不僅可以看串流影片,還可以存取電腦的麥克風及 webcam,還能玩一堆網頁遊戲。

不過 flash player 的時代已經走入歷史,但在裡面應用的 RTMP 串流協定還持續存活著,原因在於網路直播,因為 RTMP 有低延遲的特性,適合用在網路影音直播中,目前的原生 APP 網路影音直播都是採用 RMTP 協定,除非要轉到網頁瀏覽器播放,才會轉換到 HTML5 或是 HLS 的協定。

RTMP 跟 RTSP 與 SIP 不同的地方在於,RTMP 將媒體控制指令跟多媒體資料放在同一個協定中,標準是使用 TCP Port 1935,而不像是 RTP 一樣是使用 UDP,每一種媒體資料使用一個 UDP Port。

而且 RTMP 裡面還有著網路頻寬偵測的能力,因應著不同的網路速度,可以動態調整影音資料內容的解析度,以低解析度的影片應付低頻寬的網路環境。

WebRTC

WebRTC(Web Real-Time Communication) 是 google 開放的標準,目前已經提交成為 W3C 標準,專門支援在網頁瀏覽器中進行影音對談的 API。

不同於 Flash Player 的 plugin 機制,WebRTC 需要瀏覽器原生的支援,也就是內建於瀏覽器的影音對談 API,雖然 WebRTC 已經解除了 flash player 的窘境,不需要安裝 plugin,但這個協定/API 本身的能力跟等級,跟 RTMP 還是有落差。

如果要做少量的視訊會議對談,用 WebRTC 是可以做到的,但如果要做大量的 APP 影音直播,瞬間有上千或上萬個人在觀看的直播影音,目前還是要走 RTMP 搭配 HLS 的解決方案。

HLS

HLS (HTTP Live Streaming) 是 Apple 提出的基於 HTTP 延伸的串流媒體傳輸協定,在媒體播放過程中,允許客戶端因應網路速度動態調整不同解析度的媒體資料,在串流媒體一開始,客戶端會下載 m3u8 playlist,用來取得可以使用的媒體資料流。

HLS 跟 RTP 的差異在於 HLS 可穿過所有允許 HTTP 通過的 firewall 或 proxy,非常適合搭配 CDN 發布媒體串流。因此網路 APP 影音直播,才會以 RTMP 發布,在雲端轉換為 HLS,再提供給大量客戶端觀看這樣的機制。

ONVIF

ONVIF (Open Network Video Interface Forum) 是 Axis、Bosch Security System 及 Sony 在 2008 成立的標準論壇,目的在於讓不同品牌的網路影音設備能夠有共通的標準,能夠互通,幫助硬體生產及網路開發商能夠透過標準整合出各種不同的網路影音監視系統。

ONVIF 有五種 profile

  • Profile S for encompasses video streaming 網路監視系統
  • Profile G for video storage 視訊儲存及重播
  • Profile C for access control 門禁控制
  • Profile Q for Out-of-the-box interoperability 開箱即用,更簡便的操作介面
  • Profile A for Physical Access Control System (PACS) 跟 Profile C 很類似,但 Profile C 用於基本的門禁控制,Profile A 則是擴充,有比較複雜的控制邏輯

以往在網路攝影機的市場,大多是以 RTSP/RTP 的方式提供影音,但現在已經有支援 RTMP 的網路攝影機出現了。

References

即時串流通信協定 RTSP

直播終端技術比較:Native vs H5 vs WebRTC vs 小程序

網絡視頻監控:ONVIF標準協議6個常見問題

什麼是Onvif協議,誰開啟了Onvif時代?

ONVIF -- Profiles (S,G,C,Q,A)

Which protocol is best for a video live streaming from a server to an Android: RTSP, RTMP, HTTP or something else?

Streaming 通訊協定 RTP RTCP RTSP RTMP HLS 介紹

Streaming 通訊協定 RTP RTCP RTSP RTMP HLS 介紹

RTMP vs RTSP/RTP: Which to choose for an interactive livestream?

RTSP協議詳解

[RTSP]rtsp和sip的區別和聯繫

SDP (Session Description Protocol) 閱讀心得

可以用WebRTC來做視頻直播嗎?

2018/07/02

Green Process, Green thread, Native Process

在某個作業系統中,要達到 multitasking 的能力,必須要由 OS 提供建立 thread 或是 process 分別處理不同工作的 library,thread 跟 process 的最大差異是,thread 是在一個 process 裡面運作,多個 thread 之間可以共享資料。

而 Green Thread 是 Java VM 裡面的特殊用語,當時 Java VM 是利用 libthread.so 發展支援多工的專案,該專案名稱為 "Green",所以就稱為 Green Thread。

至於有人寫說 Erlang VM 的多工是採用了 Green Process,這就像是借用了 Green Thread 跟 Native Process 的概念,因為 Erlang 的 Process 之間不能共享資料,而又跟 Java 一樣本身是 VM,所以就借用了 "Green",稱為 Green Process。

有個比 Green Process 更一般化的名詞為 Light-weight process,他會以單一個 kernel thread 實作,運作在 user space,且會共享 memory address space。

Green threads wiki 中明確的下了定義,只要是取代 OS 原生的機制,透過 runtime library 或是 VM,進行 thread 的 scheduling 處理,這種 thread 就稱為 Green Thread。Green Thread 會在 user space 而不是 kernel space 運作,讓多工服務不需要 native thread 的支援。

但現今的 Java VM 其實也已經放棄了 Green Thread,而改回使用 native thread。原因在於運作的速度,在抽象化 thread 多工模型時,耗費了太多精力,再加上新的多核心 CPU,如果要完全運用所有CPU核心的運算能力,也就是 SMP,透過 OS 的 thread 機制會是最簡單且快速的,因此現在的 VM 都是直接映射到 OS 的 thread,再搭配 Thread Pool 的做法,可減少 Thread 建立跟銷毀所消耗的資源。


References

What other systems beside Erlang are based on “Green Processes”?

What's the difference between “green threads” and Erlang's processes?

What is the difference between multicore programming in Erlang and other language?

Erlang調度器的一些細節以及它重要的原因(譯文)

Why not Green Threads?

Java的Green threads是Coroutine嗎?