智能音箱场景下的性能优化

QCon是由InfoQ主办的综合性技术盛会，今年是Qcon举办的第10个年头，半吊子全栈工匠有幸作为演讲嘉宾分享一个近两年来的实践经验——智能音箱场景下的性能优化，隶属于曾波老师出品的“场景化性能优化”专场。

作为第二个出场者，前面是字节跳动银国徽老师的高性能弹幕设计解决方案，讲的是数学建模解决性能问题，后面是京东常亮老师的网关性能优化，从宕机引入性能优化的方方面面，最后是腾讯姜承尧老师的MGR，数据库同步中的性能优化与实践。 如此安排，颇有“凤头、猪肚、豹子尾”的架势，可见曾波老师还是花了很多心思的。智能音箱场景下的性能优化是端到端的系统优化，很有“猪肚”的感觉，而恰巧我也是属猪的。

一个工作了20多年的老码农，开场难免有些絮叨，聊了聊自己的“1，2，3，4，5，6，7，8，9，10”。

智能音箱已经走进了我们的日常生活，“用人工智能让人和设备的交互更自然，让生活更简单美好，”这是我们的使命。

从亚马逊最早推出Echo，到现在智能音箱的兴起，就是这最近几年的时间，这里列出的是我们小度系列音箱，可以从小度商城dumall.baidu.com直接购买，因为自己去年有相当一段时间在做商城，满满的都是回忆。

那么什么是智能音箱呢？

百度百科给出了一个解释，传统的音箱只是扬声器（喇叭），在加上功放形成音响，相当于只是一个输出设备。 而智能音箱还包括了麦克风这样的输入设备，通过互联网连接到云端的各种技能服务，能够和用户形成自然交互。

智能音箱是如何工作的呢？

智能音箱通过麦克风接收用户的语音输入，对于有屏幕的音箱而言，同样接收用户的触屏输入，通过音箱的信号处理和本地AI的处理，完成音箱的唤醒。其中涉及很多的技术，具体可以参见《令人激动的语音UI背后》一文。 在音箱唤醒之后，用户的语音数据会通过互联网加密传输到后台系统，完成进一步的语音识别和自然语言理解，将用户的语音理解为具体的意图之后，通过业务引擎完成资源的检索和技能服务的逻辑调用，对业务的结果实现自然语言生成，以TTS等方式在智能音箱上播放处理，形成一次用户的交互。

另外，智能音箱还可以通过WIFI、蓝牙、ZigBee、红外等技术与物联网设备连接，实现对物联网设备的信息获取和控制，即语音操控，例如灯泡、电视等。

智能音箱作为人工智能的落地产品一般都需要操作系统层面的支撑，以小度系列音箱为例，所有小度音箱都是构建在对话式AI操作系统DuerOS之上的。

什么是人工智能操作系统呢？ 具体可以参见《感知人工智能操作系统》一文。其中与开发者密切相关的是技能开放平台（DuerOS Bot Platform，DBP），通过DBP 平台可以很容易地将我们的服务和产品应用到小度系列智能音箱上，和我们开放一个web 服务的区别不大。通俗地讲，可以把智能音箱以及DuerOS平台看作浏览器，只不过原来的键盘和鼠标输入换成了现在的语音交互而已。

基于DuerOS的智能音箱业务流程相当简单，如下图所示。

DuerOS的核心是对话服务，这里的算法并行化是优化中的一个重点。对用户而言，语音交互是最自然的；对开发者而言，只需要关注技能服务的开发，这里是咱们熟悉的HTTP接口，具体可以参见《面向接口/协议？看DuerOS的技能开发》。

端到端的系统优化，首先要理解端到端的业务流程，然后要明确优化的内容。

智能音箱的性能包括软/硬件两个方面，鉴于时间的因素，这里重点阐述响应时间。

那么，什么是响应时间呢？

明确了响应时间的定义，可以从参考文献中知道，人对100ms的响应时间是有感知的。

有了性能优化的目标，如何提高智能音箱的响应速度呢？

首先要弄清系统端到端的时延分布，然后从网络、架构、代码逻辑以及缓存等多方面着手进行优化，这是面向时间的奋斗。

度量是基础，否则难以明确优化的重点。

基于日志的度量有两个关键因素，一个是统一的日志标识，能够将一条请求从智能音箱一直到后面的技能服务所有的日志记录串联起来。另一个是时间戳，要保障时间戳的精度。具体的统一日志采集有很多种技术可以实现，例如ELK等等， 我们采用了自有的技术体系。

优化的开始是标准动作， 现优化网络的基础设施。

让服务系统的物理位置靠近，采用专线连接，提高内外的带宽，这些都是常规的操作。对用户而言， 多机房的异地部署，能够让用户可以就近访问服务，同样是网络结构优化的必要手段。

协议架构的优化是另一个通识，用户所在的网络千差万别，适度减少通信协议的交互次数，可以收益多个RTT。

内网的通信大多数要优于公网， 多种人工智能技术的融合是协议优化的前提。

智能音箱性能优化的重点还是在于音箱的业务逻辑，根据日志信息，可以得到如下的时延分布：

端上的延时处理是指智能音箱自身处理的软硬件时延，尾音监测和VAD检测是音箱判断用户的闻讯是否结束的依据。然后，才是语音识别和自然语音处理以及具体的业务逻辑处理，最后是返回结果的自然语言合成，以无屏音箱为例，主要是TTS合成。

具体的业务逻辑就是技能服务应用，和我们通常的Web 服务类似，关注的是代码逻辑的优化，尤其是连接池的处理。

不论是我们自有的技能应用，还是合作伙伴/第三方开发者的技能服务，都是通过DBP 平台完成。

对于第三方技能服务而言， 为了减少网络异构造成的时延，可以考虑将服务部署在百度云上， 也可以直接使用百度的CFC服务来开发技能。

CFC 是百度云的函数计算， 是无服务架构（serverless architecture)的具体应用。

智能音箱核心业务优化的两个方向是并行处理和预处理，并行处理算法主要应用在NLP的环节，而我们在调优时的并行处理是业务流程的并行处理。

在VAD检测的过程中，即开始以数据流分段的形式进行语音识别、NLP、业务逻辑处理等， 在确认用户问询完毕后，对多个预处理的结果进行确认，从而节省了整个端到端处理的时间。举一个简单的例子， 大家在用百度搜索的时候，在输入框输入的过程中，会提示一些候选的结果，在智能音箱的场景，我们采用了类似的技术。

既然自然语言处理可以采用并行方式进行预处理，那么自然语言的生成为什么不可以呢？

以无屏音箱为例，根据NLP的预测流，可以对其进行TTS的预合成，再根据NLP的确认结果，选择预合成的TTS流进行输出，这就是TTS的预充。

对使用频率高的用户请求，在TTS侧事先进行缓存，对提升端到端的整体性能有着可观的帮助。

性能调优，离不开缓存， 缓存无所不在，在智能音箱的端上，同样如此。

在端上，用户的语音输入是有缓冲区的， 最小的语音处理单位一般认为是8ms，缓冲区的调整可以提升一些性能。声音的播放同样存在硬延时，这是智能音箱收到数据流并解码播放发出声音的时间。这个硬延时的测量涉及到从数字域到模拟域的转化，难以直接测量。 百度语音的同学帮我们采用了一种间接性测量的方法，周期性播放固定声音，测它的周期性偏差。很多的语音或者音频在内容的开始会有一些静音，有选择地跳过静音也会有几十毫秒的收益。

那么，智能音箱的性能优化有终极目标么？

根据DuerOS 和百度用户体验中心的调查结果， 所谓的最远体验大约是这样的，1.25s以内是较优的响应时间（perfect），1.8s 以内大概是还好（good）， 小于2.5s大约是勉强（just so so ), 2.5～3s 只能是勉强接受了，用户明显感觉到慢，体验下降。如果响应时间大于3s，用户难以接受，估计会被扔到垃圾桶里了。

小度系列音箱的响应时间是多少呢？ 官网上已有介绍，如果不相信数字的话，可以拿小度音箱直接体验， 如果拿友商的音箱做对比实验，就能有清晰的感受了。当然，这是DuerOS团队、语音团队、云团队等百度同学共同努力的结果， 我只是有幸参与其中而已。

当然，现场的分享可能要比这里的文字内容丰富的多，可以随时现找个朋友做例子和类比，这里也再次感谢超总，梓晨，花非花等朋友的专程捧场。

在Qcon， 不论是分享，还是倾听，或者讨论互动，都有着不错的体验！

参考阅读：