摘要：最近刚好开发一个实时数字人系统的语音唤醒功能，以补充需要人工每次手动点击按钮的麻烦，像下面这种交付方式，虽然可行，但是可用性不高：

最近刚好开发一个实时数字人系统的语音唤醒功能，以补充需要人工每次手动点击按钮的麻烦，像下面这种交付方式，虽然可行，但是可用性不高：

为此，我需要将手动操作的方式完全丢掉，理想效果是只动嘴就好了。

但是完全动嘴的效果，大家也不要期望过高，为了让大家有一个直观的体会，可以看看这个视频：

虽说这个视频是演绎，但是至少说明了当前语音交互存在的一些常见问题：

1 语音识别问题

3 指令决策问题

3.知识库问题

首先面对的第一个问题是唤醒，系统是否一直处于监听用户说话？貌似不这样做还不行，这就出现一个性能问题。

客户端需要不停的向服务器发送语音，这一点从家里的小爱音箱就能看出来，比如我们平时聊天，偶尔不小心提到小爱二个字，或者听起来像小爱发音的词语，这个时候小爱音箱马上蹦出来了。

这个着实让人后背发凉，不知道我们的谈话信息，被服务器抓到了多少。

回到技术本身，24小时不间断上传语音，然后识别对系统资源消耗不是一般的大，这里面肯定有很多方法去优化，比如客户端可以在检测到有人说话的时候才会开始监听，其他的噪音，静音可以直接忽略。

当检测到人声，并且触发到了唤醒词，这个时候系统才会响应，对于唤醒词的选择也是有讲究的，比如小度小度，小爱同学，你好宝马。。。4个字的连字容易被系统识别。

但是当你使用这些唤醒词的时候，会发现，这些系统每次只能进行一轮问答，比如：

而且还不能打断，更没有上下文。

如果不这么做，可能会出现很多问题，比如：

如果系统需要识别多轮对话，客户端需要一直监听用户说话，因为系统在回答问题的时候，还在听用户说话，很容易误抓自己的语音。

如果必须等系统讲完再开始抓用户语音，那系统需要一直监控自己的讲话进度是否结束，因为语音是从服务器推送到客户端的，客户端如果想要发起新一轮的语音获取，必须等服务器的语音发送完毕和客户端的播放结束，这无疑增加了系统的复杂度。

同时客户端系统在抓取用户语音的时候，也会设定一个时间窗口，比如是抓取3秒，还是5秒，还是一直等用户说完，我猜客户端系统肯定设置了超时时间，这个超时时间如果设置太短，就容易漏掉语音。如果抓取的太长，又增加了服务器的压力。

如果遇到心急的用户在系统没有讲完就提前抢话，那客户端系统同样会丢失语音。反正，客户端系统提前抓取语音，那又可能抓到了自己的语音。

也许，可以让系统识别音色，只抓取用户的声音，这又增加了系统的复杂度。

这个问题在支持打断的场景中更严重，因为系统会一直监听讲话，包括自己的语音。

反观当前市面上的系统，用一种简单粗暴的方法确实能够应付日常对话中的很多问题。

那有没有一种方法不太消耗资源，支持多轮对话，同时支持打断呢？

我尝试实现了一种方法，请看效果：

使用方式：

我们的数字人实时交互系统，目前已经发布到4.7.1，支持实时字幕展示。

下个版本支持广告消息弹窗，自定义画面切换等，敬请期待。

最新版本下载试用地址：

来源：晓加科技观