于嘰嘰（原創）

轉眼間，距上篇發文已經過去快5個月了，雖然主要是因為拖延癌晚期發病一直在各種放化療（頭發掉了一堆這事我會亂說），但“治療”期間也是苦苦憋了個大招。接下來我就分享下我們如何將AI接入到了VR中，并嘗試了哪些有趣的場景。

? 緣起?

事情要從VR的輸入方式說起。在之前有關VR交互范式的三篇文章中（微信權限限制，不能在這粘跳鏈，大家手動查看歷史文章就行），我列舉了當前市面上主流VR設備的信息輸入方式，大體上從最低端的只能靠凝視觸發到高端的如數據手套，手勢追蹤等都有，而且在行業沒有完全成型的時候，各家都在發展適合自己硬件的交互輸入方式，使得至今VR的交互范式百家爭鳴，并沒有一個一統天下的標準出現。

不過，作為一個沒有自家硬件做支撐的項目組，當選取交互方式時就陷入到一種很尷尬的境地?？犰湃鐢祿痔资謩葑粉櫟慕换シ绞诫m然體驗好，但過分依賴昂貴且不成熟的硬件，使得用戶門檻過高不利于推廣普及。最終部門老大還是選擇了當前出貨量最大的“手機—VR眼鏡—手機app”這種硬件配置。這就引出了一個棘手的問題。以這種硬件為基礎，用戶戴上眼鏡后就不能用雙手操作手機，只能通過“凝視觸發”來進行簡單的操作。這樣一來，原本簡單的翻頁、選片等操作會變得效率低下，而相對復雜一點的文字輸入就基本廢了。于是我們需要找到一種既不依賴特殊硬件又能做到體驗優良的交互輸入方式，當然很自然地想到了語音，不能用手，你就講出來嘛。

?語音交互?

市面上的語音交互系統按照識別的指令可以簡單的分為兩種：一種是基于“有限狀態語法（finite state grammars）”的可交互式語音答錄系統（IVR）；另一種是基于統計語言模型（statistical language models）的自然語言交互系統（NLP）。這樣說有點抽象，簡單形容，IVR系統就像是火車電話訂票中的系統提示音，所有用戶指令都被限定在一個預設好的聲紋庫中，用戶只能在系統的提示下說特定的指令系統才能識別，常見于各種自動客服系統。而NLP是當前比較流行的一種方式，比如蘋果的siri，微軟的cortana和亞馬遜的Echo都是基于自然語音識別的經典案例。用戶可以根據需要，以自然會話的方式向系統發布指令，系統依靠語音識別將語音轉成文字，再根據需要將大段文字拆成短命令并與指令庫匹配，從而執行相應的動作。上面兩種方式并沒有誰優誰劣的區分，IVR系統通常用在用戶意圖相對較為明確（換句話說就是系統支持的功能較少），提倡精準且高效的場景，而NLP系統則通常會被包裝成“助手”，所以自然語言式的指令會讓用戶感到更為親切自然，不過技術限制使得當前的NLP系統的識別精度和反饋速度都相對較低，這也是為啥上文提到的siri等語音助手經常會用諸如“哦”等賣萌語來掩蓋識別無果的尷尬。

? 語音1.0 — 假助手?

在第一版的設計時，我們更多的考慮是在技術可行性和未來擴展性上尋求平衡。

技術方面，百度有自己的自然語音識別接口，其在線識別的精確度相當不錯，但難點就在對識別出的用戶指令進行拆解識別并對應到相應功能，這個短期內很難有突破，畢竟憑著幾個人的開發團隊要干人家幾百人干的活也不現實。再回到產品需求上，我們的功能豐富度也還不足以支撐用戶對一個擬人的語音助手的期待。但從用戶認知度和接受度來考慮，支持自然語音識別的語音助手無疑是當前用戶接受度最高的，所以最終我們還是決定包裝成“語音助手”，即使背后的識別邏輯做的簡單一些，畢竟一個“傻點”的語音助手以后還有變聰明的可能，一開始定位成語音輸入就沒有后續優化的空間了。

具體來說我們是這樣做的：

認真看的你不難發現，這個超簡單的流程存在很多bad case，比如用戶發起的很多我們沒有涵蓋的服務會被當做搜索詞進行一次檢索，而某些與預錄詞庫有重疊的搜索意圖又會被識別執行成其他服務，再加上詞庫的設置上我們并沒有相關的經驗，基本上是靠近義詞詞典支撐，所以只能在用戶一開啟語音助手時就將標準命令詞顯示在界面上來做提示。

? 語音2.0 — 真助手?

從1.0的語音“假”助手的嘗試中我們發現主要的技術瓶頸是對用戶的意圖進行拆解識別，而這需要較為復雜的算法和大量的數據訓練才能實現，此時我們想到了百度自己的一款已有產品——度秘，如果將度秘已經訓練的較為成熟的識別能力接入我們的語音助手豈不是就解決了上面的技術瓶頸。于是在一個風和日麗的下午，一個交互、一個視覺、兩個開發，四個人組成的小分隊開始嘗試將AI接入到VR中（這是我們的一小步，也是人類的一大步，噗哈哈哈~~~）

? 基本交互?

目前度秘APP主要是會話式的交互模式，用戶通過與度秘的會話獲取各種反饋信息，這種形式比較符合語音助手形象，因此在VR化過程中我們也考慮復用這種形式，在用戶使用習慣和開發成本上都是一個很好的延續。

通過分析度秘的會話內容，我們將信息分為兩類：

1. 度秘與用戶的普通會話內容

2. 點擊命令結果跳轉到的服務詳情頁

因此，在VR空間的排布上，我們將這兩類信息分別放置在前方的會話層和后方的內容展示層，如下圖：

用戶首次進入VR環境時，內容展示層會顯示推薦內容，用戶通過與度秘的對話調起各種服務（如檢索并播放視屏等），對話內容在會話層中展示，而內容展示層會展示服務內容。

?接入度秘自有服務?

度秘SDK分為兩部分，一部分是語音識別，另一部分是度秘API，此次我們采用的是百度VR瀏覽器語音識別模塊+度秘線上API的方案，這樣的方案使得我們對接度秘時，沒有引入任何新的二進制文件，控制安裝包大小同時，減少了調試難度，提高了開發效率。以下是度秘服務的基本流程：

當前度秘自有服務主要分為三類：信息，聊天，服務（具體詳見郵件附件）。而我們要做的是采集用戶的query詞傳給度秘，在VR的3D場景下將度秘返回的服務信息進行展示。我們選取了天氣和美食兩類服務進行接入，效果如下：

?天氣查詢?

在“內容層”上展示度秘返回的天氣信息

?附近美食?

用VR瀏覽器展示美食詳情頁信息，可以支持在線訂餐

?新場景暢想?

從上面的案例可以看出目前百度VR瀏覽器已經具備在3D場景中對度秘自有服務進行展示和操作，只需對方提供對應接口，我們做好數據展示就能很好的對接成功。但目前度秘的自有服務更多的聚焦在生活服務和信息查詢方面，這與VR瀏覽器用戶偏娛樂化的需求相悖，所以更多的需要我們結合VR瀏覽器用戶的使用場景，重新定義“VR度秘”應具備的功能。

① 直播小助手

當前市面上的VR直播仍然處于只能觀看或僅支持簡單互動的階段，其互動的瓶頸在于用戶在VR環境下很難進行信息處理，包括打字、送禮物等。將VR度秘作為直播小助手，在直播前可以進行直播預約提醒，在直播中使用語音發送消息（發彈幕），送禮物，同時還可以進行內容講解等等。

② 虛擬體驗項目與線下體驗推薦

目前VR資源中有很大一部分是虛擬體驗視頻，例如過山車、滑蹦極等極限運動，可以將這些資源整合成“度秘帶你體驗虛擬xxx”的入口，結合度秘的智能搜索與推薦，引導用戶觀看和體驗這類視頻，并與線下娛樂休閑項目數據聯動，在適當時機提供線下餐飲、游樂、休閑等項目的體驗和購買入口，達到商業化的目的。

③ 與地圖合作打造虛擬游覽

目前百度地圖有行業內獨一無二的街景技術和資源，并且團隊已具備將街景接入VR的技術能力，因此我們可以將一些特殊地標，例如城市中的景點，或一些經典的城市游覽線路——如上海的石庫門一日游——打造成虛擬游覽體驗，將景點簡介等信息預先錄入，用戶在“游覽”到某一節點時度秘會像導游一樣，向用戶講解當前景點的相關信息。同時，這種虛擬游覽的方式可以衍生出很多不同主題，并且可以對接很多相關服務，這樣能夠在街景較為單一的呈現方式和使用場景之上，更加豐富它的體驗與產品維度。

下面是我們用實現的Demo錄制的一段介紹視頻

謝謝觀賞

以上這些都還是一些設想，不過互聯網這東西就是用來縮短夢想和現實的差距的，現在是2017年0點14分，更著公眾號不知不覺就跨年了，2017繼續充實下去。

當然還要謝謝這個小項目中一起奮戰的小伙伴們，2017我們繼續約項目~~