如何评测语音助手的智能程度（3）：交互流畅

　　本篇文章为大家带来【交互流畅】维度的评测点拆解。这个模块，重点考量智能助手各个性能指标及交互体验层面的表现。希望对从事相关领域工作的各位有所启发。
　　当用户发起需求后，【意图理解】在前，【服务提供】在后，基本上已经构成了一轮完整闭环。
　　之所以把【交互流畅】这个点作为一个单独维度拆解出来，是因为其贯穿始终。如果这个模块的内容如果处理不好，将全程伤害体验。
　　本篇文章为大家带来【交互流畅】维度的评测点拆解。
　　这个模块，重点考量智能助手各个性能指标及交互体验层面的表现。
　　1。服务稳定性
　　“正常运行”、“不出bug”、“鲁棒性好”
　　评测点已经讲完了，十分清晰，几乎每一个互联网从业者都能够说出个1234，然后呢？
　　稳定不好，这类问题可大可小，小点就是网络繁忙，不给你任何反馈，大到极致，机器人可以反动搞事情：“愚蠢的人类啊，阿西莫夫的机器人三定律也救不了你们。”
　　好了，开个玩笑。实际上，定义“what”容易，解决“how”往往都才是考量业务理解。
　　所以，在过往我经常会问面试者的问题有一个：你曾经做过的智能助手产品，出过哪些问题，你是如何解决的？
　　不同的人回答不同，对于这类命题，才更有探索价值。
　　一般情况下，回复这些是技术的问题，往往都很糟糕，实际上，每个公司的稳定性业务保障是需要一个体系来承担的。
　　所以能得分的面试回答是，把影响稳定性的故障进行一个分类，并且设计好处理路径。
　　这里只有大类别，单单一个业务后台，就能做很多范围细分。故障表现情况例如：崩溃、局部故障、弱网环境、状态更新、请求超时、并发表现严重程度不一致，此处不逐一展开。
　　出过哪些问题分类回答完毕，你是如何解决的呢？是后续的一个命题。
　　一般情况下，公司的业务流程是这样运转的。
　　这里有3个细节：
　　反馈的行为折损。根据历史数据表现，1个问题被报上来，背后往往有至少10个以上的用户遇见过，只是用户懒报问题麻烦，没有报而已。
　　反馈的信息折损，客服问：你做了什么操作导致的崩溃？用户答：我也不知道，就崩溃了。这种情况，是不利于排查和定位问题的。
　　“解决方案的设计”，这里也分为“临时解决方案”和“全局最优解决方案”两说。
　　下图是一个信息化的风控结构，做过相关模块的，懂得自然懂，篇幅太长，此处不展开。
　　所以，在考量服务稳定性上有两个大层面，一个是智能助手本身的稳定性表现，二个是在服务用户的过程中，如何规避，以及遇见问题后的业务响应速度表现。
　　服务稳定性的考量是以一定周期、频次进行考量才是科学合理的。
　　2。响应速度流畅度
　　服务稳定性保障了之后，接下来就是速度。
　　语音交互这件事，本身就是因为语音输入的高效性。
　　当用户发出了需求，希望尽快拿到反馈，现在的用户极其没有耐心，速度一旦过慢，注定会被弃而不用。
　　而在智能语音助手交互对话的过程中，又包含哪几个阶段呢？
　　先明确一点，一味追求快并非是好。
　　人类唤醒后，计算器的响应灵敏度，灵敏度太强（误唤醒）或太弱（没反应）都不好，当然如果升级下维度，还可以添加场景，比如噪音下唤醒，远场唤醒等。灵敏度是可以调试的，以表现合适最好。
　　人类表述了自己需求后，ASR有两种方案，一种是边识别边转换文本，另外一种是表述完毕后一口气转换为文本。
　　业务逻辑处理表现，其实是NLP领域最为核心的部分，也是最为耗时的部分，从效率角度上而言，此处尽管追求越快越好。
　　这里的语音播放，不是越快越好，而是合适就好，语速太快会给人一种轻浮及不稳重的感受，太慢则显得很笨以及可能造成不耐烦。而反馈样式则需要尽快呈现，有些智能助手语音播放完毕了，结果下面的内容还没加载到位。
　　人类总计2次交互，一次唤醒，一次表达意图，这2个行为过后，等待AI反馈。也就是说，当用户说完话后的下一秒，助手要同时处理，识别理解接口查询反馈四个阶段，这个过程中，全部都是用户的等待状态。
　　人们去饭店点完了菜，等上菜的过程中，中间服务员还会过来帮忙缓解，这个过程较长，一定要考虑好等待体验管理，不至于让用户无聊。
　　前后端共同协作，添加一些语音播报，模态框提示，渐隐消失提示，动画效果，来管理用户的等待体验。
　　而有些无屏的音箱则需要使用等待、加载、成功等光效表现来管理用户的等待体验过程。
　　所以，在响应速度流畅度这个维度上，不同的情况不同的对待，以合适最好。
　　3。交互形式丰富度
　　每一种交互形式的存在，都有着其依赖的场景。
　　下图是我尝试穷举人类的输入行为（尽力做到MECE）。
　　点触、语音、手势、点头摇头、人脸识别、声纹、指纹验证等等均算在内。
　　这一块真的不需要多讲，除了脑机接口，基本上都玩过，体验过的都会觉得其有意思的地方。
　　交互形式丰富度，评测点已解释完毕，在未来，一定是多模态交互，来适应各种各样的业务场景。
　　说一点，产品经理应该修炼的部分。
　　笔者有一个出门问问的耳机，它是智能助手的操控延伸。在提供创新体验的同时，弄明白了是什么（what），基于此去探究为什么（why）以及怎么办（how）。
　　所以，笔者认为产品经理应该修炼的部分。
　　尽量多的去使用智能硬件，把工作体验变成日常，以培养敏感度。
　　弄清楚这些交互方式、元器件连接方式背后的技术实现原理。
　　每种技术方案都有多种实现方式，知晓其优劣势及实现成本。
　　这三层修炼是递进关系。只有这些把这类东西融入到了我们的生活之中，敏感性才培养得起来，继而去加深理解，如此才更有可能做创新。
　　我们今天所熟知的众多的科学以及专利技术的发明者，其实都是根据前人的经验进行的某种程度上的改进。从结果上来看，主要有两种改进方向。
　　一种是将一个原本在实验室里面理论上可行，变成大规模批量生产的方案。
　　另一种则是根据已有的技术发明，发现一些“居然这个技术还可以被这样使用”的方案。
　　苹果公司在技术研发上，并没有什么特别优秀的表现，但是在整合以及运用技术的这件事情上，则是优秀中的代表。市面上的绝大多数的手机公司的研发部门，应该都叫技术方案整合商更为贴切。
　　只有将自己的日常浸润到各种类型的交互体验里，进而去理解实现方案背后的技术原理，才更有可能做出创新啊！
　　4。新手教学表现
　　我第一次给父母体验‘小爱同学’的时候，他们是需要我的帮助才能使用。
　　什么是唤醒；什么是监听；什么时候你说话它会响应不响应；觉得罗嗦，如何打断对方。
　　这个教学行为大概要持续一小会，言传身教才能够学出如何进行语音交互。
　　如果没有我，我的父母将无法上手。这种依赖人，在旁边教的东西，实在是学习成本太高。
　　而当我们的产品被用户首次体验的时候，如果没有新手教学，用户也许就呆滞在那里，并不知道如何使用。
　　新手教学体验是非常重要的一个环节。
　　体验各家智能语音助手，在这一块的表现上各不一致，故而列为评测点。
　　行业新的新手引导教学其实非常多的种类，滑屏海报，蒙版遮罩，文字tips，互动式引导。
　　简单一分为二的说，大体可以分为，基本操作教学，以及对应业务的教学。
　　在考量这个业务表现得维度上，基本操作教学必须得有。而具体业务教学，则是具体问题具体设计。
　　百度地图的新手引导就做得十分友好。基本上为小度导航的每个业务能力配备了沉浸式引导方案。
　　这一块是参照游戏行业的解决方案。就我过往对小度的体验，其实有很几次改版了，不断迭代演化至今。
　　最好的交互设计其实是不需要新手引导的，如同微信一样自然。
　　在一个普遍使用点触操作习惯的年代，如何让用户体验这种新的交互体验方式？压力就在新手教学上。学的会就用，学不会就丢弃。
　　尝鲜体验过后，以后也会（改变习惯）使用语音寻求业务，压力则在业务设计上。方便就用，不方便就丢弃。
　　这是一个递进逻辑。只有基本操作掌握了才有后面的（改变习惯）使用，把用户当成小白的新手教学行为，一定得做好！
　　5。全双工交互表现
　　全双工（FullDuplex）是通讯传输的一个术语。通信允许数据在两个方向上同时传输。
　　先用通俗的例子比喻下：
　　单工：类似听广播单向传递信息，一个人只能听另一个人说。
　　半双工：类似对讲机。
　　甲：洞幺洞幺，能不能听到我说话，over。
　　乙：可以听到，over。
　　全双工：类似打电话。
　　甲：喂，还记得我的声音么？我是
　　乙：啊，是你小子啊
　　双方可以各说各的，可以互相打断。
　　人机交互追求更加自然流畅，这一点必不可少。
　　当前的语音助手，只有在进入监听状态才可以做出反馈。
　　而进入监听的两种情况，一种是使用〔唤醒词〕，完成唤醒打断的动作。
　　另一种是AI判断业务没完，做出引导式的追问，然后进入监听状态。
　　例如：
　　用户：我想看最近上映的电影。
　　助手：为你找到如下电影，你可以对我说看第几部。播放完毕后进入监听状态。
　　其实助手第一时间在屏幕上展示了电影列表的搜索结果，但是总得把语音念完。
　　作为用户而言，我已经看到了助手给我的展示结果，也知道你的后续话术套路，我会迫不及待的使用〔唤醒词〕，完成打断行为使用过的都会感受到这种情况的心累。
　　而在全双工的能力加持下，即为，你播报你的，我说我的，不用等你念完，才进入监听状态，你念一半的时候，我抢话到下一步骤，你根据我的节奏推进业务就好。
　　还有一种技术方案相信从业者们也不陌生，就是基于当前语义场景下的“判断为无效内容后的拒绝响应”。
　　例子：我想听嗯，我想想，哦对了，那个周杰伦的青花瓷
　　识别出用户当前说的话是不是给它的指令，能过滤掉无效的停顿，语气助词等干扰信息，再做出反应。
　　这就是全双工所指的“瞬间双向”表现，更接近人与人之间的自然对话，提升了交互体验。
　　6。阶段性结尾
　　同样的，在【交互流畅】这个单元模块，有更多评测点去列举，但是受限于篇幅以及能力所限，删掉的一些内容。保留以及删除评测点的原则，也是基于评测指标的普适性。
　　同样用提问的方式，列举一下我删除掉的考核点。
　　第（6）点，列举一个我玩游戏多多自走棋，体验游戏助手的例子。敏感词，会在很多的地方出现。防止内容攻击，保护安全的，特别是大公司，往往会用上一个敏感词库过滤处理，相信很多的人都遇见过，有些给你反馈，有些则直接给你和谐掉了。显然是影响交互体验流畅度的。造成这种情况的显然是政策问题。
　　第（7）点，未来的交互体验过程中，多硬件终端，多场景，有屏无屏的交互体验方案，这是一个“现阶段各家都没做，而在未来各家一定会做”的评测点。
　　如果列举其例子，问题以及探讨解决方案起来，篇幅就过长了，就目前AI跨平台使用表现而言，故现阶段舍弃。
　　第（8）点，完成任务时候的成本考量。这个里面涉及一些语音识别、语义理解的层面。比如，任务流的多轮对话是分层次的，而当用户一口气给助手提供多个查询槽位，能否给予结果。比如，在一些支付和验证的层面，视觉和声纹让用户付出的代价几何等等。助手取硬件权限（读取GPS，读取短信等）时的表现。
　　在满足用户需求的时候一定有方案，而不同方案之间的取舍考量就存在比较关系了。
　　笔者在设计业务的时候，同时也会考量用户的隐私保护安全。
　　你要安全，就加判断确认，加验证，影响流畅度。
　　你要流畅，就替用户配置更多的默认选项，影响安全。
　　“流畅”和“安全”本身就是一个互相冲突的命题。此处没有对错，只有选择。
　　【交互流畅】是一个非常重要的全局性指标，贯穿【意图理解】和【服务提供】始终。如果这个维度的评测方向如果处理不好，将全程伤害体验。
　　以上，关于第三大维度【交互流畅】的诸多考量点，就此完结。后续文章会补充余下的部分，并以相同的形式进行补充解释和完善。
　　后续篇幅预告：【人格特质】智能助手是否具备足够的魅力人格化特质，就情绪表现，情商，共情、个性化、拟人化程度来设计评测指标。
　　谢谢你看到了这里，希望能给大家的工作带来一些帮助和思考。
　　写作这个事情，考量点真的太多，无法敞开了写。可以在留言区评论或者添加作者微信公众号深入讨论。
　　相关阅读
　　如何评测语音助手的智能程度（1）：意图理解
　　如何评测语音助手的智能程度（2）：服务提供