作者：秋半仙，哼哼
童鞋们好，前文我们花大篇幅聊了语音的唤醒与识别，今天我们另起一个话题，聊一聊语音的时间与体验。由于篇幅比较长，这个话题我们会分两期来聊，今天先聊聊语音的时间与体验（上篇）。
我个人认为，语音产品和其他产品最大的区别，在于更加强调了时间维度。我们不仅要站在三维空间中去思考产品的表现，还需要在时间维度上去思考产品的逻辑。这些逻辑是根据时间的演变在不断发生变化的，所以很难用“图”这种“时刻态”的表现形式呈现出来。做语音产品和语音交互的童鞋，请务必对“时间”保持足够的敏感度。“时间”对人的心理变化影响是非常大的，想做好语音产品的细节，千万不要忽略“时间”这把双刃剑～
Δ 图片来自网络
“语音识别”里对于“时间”的运用是非常多的，其中有一个知识点，叫“实时率”（或“RTF”）。实时率是用来表述当前的能力是否能做到实时，换句话说，就是一段声音的时间和处理它所需要的时间的比值。比如，10秒的音频，语音识别只需要1秒就能处理完毕，那么，实时率就是0.1；反之，1秒的音频需要10秒来处理，实时率就是10。实时率小于等于1时，我们都可以称之为是“实时”的。现在所有语音企业的语音能力，都能做到实时率小于1，而我们关注这个点的原因在于它的依赖因素——硬件能力。在不同的硬件能力下，运算耗时是不同的，因此这个值就不好说了。如果你的目标硬件是一个很磕碜的配置，比如不支持浮点运算，那建议要评估一下在目标硬件上的这个值。如果这个值已经很接近1了，那要小心了，可能产品体验的“慢”会远比你想象的要慢很多（这里主要针对在无网络环境下，依然对语音识别有强需求的语音产品）。
另一个和时间有关的重要知识点，叫“语音端点检测”（或“VAD”），顾名思义，就是用来检测“语音端点”。我们这里主要涉及到的语音端点，是一段声音的起始端点和结束端点，简称“前端点”和“后端点”。“前端点”是标明用户开始说话的节点，“后端点”是标明用户结束说话的节点。它们组合在一起，将“语音识别”需要处理的目标音频切割出来，待语音识别处理完成之后，进入下一个大环节“自然语言处理”。
听起来是不是很简单？仔细回忆一下，童鞋们肯定也遇到过这样的对话场景：你和一个人对话，你通常会在等他把话说完之后，你才说话。当你以为他已经说完了，你刚要发声，结果发现他又接茬继续说了，你只好把自己的话再硬生生憋回去……
Δ 图片来自网络
这个场景的关键状态，就是“说完了”如何界定。因为这一点对体验的影响很大，这里我多说一些。其实要通过VAD技术是很难准确判断“说完了”这个行为的。VAD既然叫端点检测，自然是负责检测端点用的，其原理是通过判断一个区间时间内的音频是有效语音，还是无效语音。通过反复监测，根据“有效”和“无效”的变化，就可以来界定有效音频的“开始”（从“无效”变“有效”）和“结束”（从“有效”变“无效”，并维持“无效”一段时间），从而实现把“目标音频切割出来”的效果。从这段描述中，我们需要看清技术原理中的关键点，即判定“说完了”的关键在于“一段时间内”是“无效语音”的。
这里本半仙再给各位童鞋开个小灶补充个小知识点。“一段时间”一旦结束，我们称这个结束的时刻为“Time Out”，即“超时”。我们一般把判断后端点的这个时长，叫做“后端点VAD的Timeout时长”。如果不提“前端点”和“后端点”，一般我们日常提及的“VAD的Timeout时长”都是指后端点。大家要清楚这些，平时沟（zhuang）通（bi）的时候会用到~
Δ 图片来自网络
产品思考的问题是“用户需要什么”，那我们就来看实际生活是怎样的。以导航领域来举例，比如你向语音设备说“导航到徐家汇”然后停顿，这个地方有一个比较短的时间“无效”就能决定“说完了”。我假设这个时间是500ms，如果说“导航到…”这个时候停顿了，想了一秒之后，说“徐家汇”，这个时候，500ms的判定就显得有些仓促了，就有可能出现语音设备要插话结果发现你还没说完的情况。人在犹豫和思考的时候是需要时间的，所以这种情况语音设备就需要等更多的时间再给反馈。综上可知，我们需要一个可以根据具体情况来动态调整后端点vad时长的技术，根据不同的情况，可自适应调整“短”、“长”甚至“更长”的等待时间。
秋半仙温馨提示：
这里岔一个题外话，请做产品的童鞋们特别注意。我以前看到过产品给研发的语音需求是类似上一段加粗部分这么写的（后排那个童鞋，说的就是你，自觉面壁去吧），这是很不专业的。你以为加上了“自适应”、“自学习”、“通过xx深度学习”、“通过xx进行机器学习”等等这些牛逼的黑科技的词感觉很高大上是吧？觉得技术童鞋会秒懂然后屁颠儿屁颠儿地去给你落地是吧？
Δ 图片来自网络
啧啧啧，童鞋们还是too young too simple啊。一方面，技术同学不一定能了解这些高新科技，另一方面，就算是要引用“深度学习”、“机器学习”、“自学习”、“自适应”，产品童鞋也得把具体的要求说得清清楚楚，甚至是将预期效果量化到需求中。如果还不了解这些玩意，可以先按“黑箱理论”的方式（不了解黑箱理论的请参考本半仙的文章一段声音的旅程（二）头疼的音频信号处理），先去了解清楚，再来写需求。上面的需求，有三个关键点是必须要描述清楚的：1. 具体情况，具体有哪些情况？更重要的是，如何界定这些情况？2. 等待时间，短、长、更长，具体是多少毫秒？3. 什么情况应该等待多长时间？需求的定义需要量化、严谨、详尽，或者简而言之三个字——别嘚瑟！
咳咳，扯远了哈，我们再回来聊聊vad。现在业内最通用的做法是不论什么情况下，后端点等待的时间是固定的，且这个固定值客户可以修改，但这样相对来说比较约束。其实变通一下，在同样的约束框架下，规定在多轮对话的场景里，下一轮的vad时长可以根据上一轮的结果来修改，这样就稍微有点自由度了。比如：在第一轮对话确定用户是要求语音设备进入导航领域后，下一轮开始，vad时长用500ms，而如果第一轮确定用户是要进入短信或微信领域后，下一轮开始，就使用3s（时间部分这里只是举例）。
再来聊聊时间这个部分。这个时间多了还是少了，对于产品会有什么影响？我们必须对这一点有一个很直观的理解。回到对话的情境里来，你和别人在对话沟通时，是期待他尽快回答你的。这个回答的等待时间如果很长，比如3秒，你每次说完一句话，要等3秒，他才有反应，如果每次都这样，你是不是会很崩溃，想立马甩脸子走人？
Δ 图片来自网络
反之，我们将这个回答等待时间缩短一点，比如100ms，这时候你会发现，艾玛，咋喘口气儿的功夫你就插话了呢。插话就插话吧关键你还没整明白我说的啥你就乱插话，就会那一句“你说的我听不懂，请再说一次”。再毛线啊再，你妈妈没教过你人家说话的时候你老打断是不礼貌的吗？真是的，不懂规矩😒😒😒！
Δ 图片来自网络
这里给出我的建议：如果只能设定一个固定值，那么这个值建议经过大量的体验测试来权衡决定。具体数值没有特定的标准，更多是靠体验去尝试。不同场景下的用户群不一样，心理状态不一样，使用习惯不一样，这个值都可能是不一样的。在车上设置的默认值是800ms，仅供参考，请以真实产品在真实场景下的体验为准。
上段所讲的部分都是根据现状所谈论的细节，如果我们跳出这个“现状”的框，其实产品最想要的是“在说话过程中，根据已经说的内容，动态调整本次说话的后端点的等待时长”，这个能做到吗？要做到肯定是能做到的，但是这个地方打破了今天很多“现状”的约束，也会引出很多很多新的问题，所以风险可能会很大。比如，今天的语音逻辑是激活语音后，在录音的同时去做asr。当后端点检测条件满足之后，结束录音，等待asr处理完毕，再去执行nlp。asr和nlp是一个串行行为，如果要实现这个逻辑，就需要在录音的同时，去做asr，同时去做nlu，根据nlu的处理结果，去动态改变后端点检测条件。当后端点检测条件满足之后，结束录音，等待asr处理完毕，等待nlp处理完毕。这是一个非常理想的状态，没有考虑硬件资源性能消耗，没有考虑本地引擎和在线引擎的区别，也没有考虑网络好和网络不好的可能性，更没有考虑各种噪音干扰环境下的具体表现……这么大的风险，能多大程度地提升产品体验？是否值得去冒险呢？
每个产品童鞋的心里需要一杆秤，去掂量每一个细节改善，每一次体验提升，详细评估风险，仔细掂量回报。做就要义无反顾，不做就要坚定不移。你的反反复复，很可能会让整个team军心摇摆，甚至最后落得一盘散沙一场空。这个方案原理上是可行的，在这里之所以展开来说，是希望能够帮助产品童鞋“跳出现状”思考“产品体验”。各位产品童鞋可以与技术童鞋详细研讨之后，自行商定。因为涉及面比较广，还是需要些时间去努力的，只有持之以恒地对这些细节耐心细致地打磨，才能把语音的体验越做越好~
—THE END—
网友评论