于叽叽（原创）

转眼间，距上篇发文已经过去快5个月了，虽然主要是因为拖延癌晚期发病一直在各种放化疗（头发掉了一堆这事我会乱说），但“治疗”期间也是苦苦憋了个大招。接下来我就分享下我们如何将AI接入到了VR中，并尝试了哪些有趣的场景。

░ 缘起░

事情要从VR的输入方式说起。在之前有关VR交互范式的三篇文章中（微信权限限制，不能在这粘跳链，大家手动查看历史文章就行），我列举了当前市面上主流VR设备的信息输入方式，大体上从最低端的只能靠凝视触发到高端的如数据手套，手势追踪等都有，而且在行业没有完全成型的时候，各家都在发展适合自己硬件的交互输入方式，使得至今VR的交互范式百家争鸣，并没有一个一统天下的标准出现。

不过，作为一个没有自家硬件做支撑的项目组，当选取交互方式时就陷入到一种很尴尬的境地。酷炫如数据手套手势追踪的交互方式虽然体验好，但过分依赖昂贵且不成熟的硬件，使得用户门槛过高不利于推广普及。最终部门老大还是选择了当前出货量最大的“手机—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录制的一段介绍视频

度秘接入百度VR浏览器 - 腾讯视频

谢谢观赏

以上这些都还是一些设想，不过互联网这东西就是用来缩短梦想和现实的差距的，现在是2017年0点14分，更着公众号不知不觉就跨年了，2017继续充实下去。

当然还要谢谢这个小项目中一起奋战的小伙伴们，2017我们继续约项目~~