如何让你的语音助手有眼力见——Turn Detection 的 5 种解法丨Voice Agent 学习笔记-编程实验室

从2022年优化智能客服开始，我就开始尝试优化人机语音对话中的“语义完整度”模块。当时大部分人的精力都集中在优化识别率，在语音对话系统中，这不是一个核心模块，似乎是可有可无的，但语义上的完整度对于用户体验、信息收集的效率都有很大的影响。特别是在今天人们对于智能和体验的极致追求下，语音对话类各种应用，比如陪伴、玩具、客服等场景的大模型升级，越来越多的工作开始瞄准这个方向，业界需求也在增加，这也印证了我们之前的文章中提到的语音应用的趋势之一，即从功能实现到体验提升。本文将重点分享几个语义完整度的优化思路、方案和实际挑战。

一个完整的级联对话系统的方案

本文就不再过多解释，有兴趣的朋友可以参考下面的视频：

什么是语义完整度？

语义完整度，或者叫做Turn Detection，轮次检测，其实属于用户意图判定的一种，主要用来判定用户是否已经完整地表达了自己的想法。一个真正的智能系统，应该可以做到有“眼力见”：

该响应的时候及时回复，不该响应的时候保持沉默。

但在真实的语音交互场景中，经常有以下这几种情况出现：

机器过早回复：用户使用“嗯、啊”等词汇过渡，用户的不流利发音，或者用户在面对复杂问题的思考间隙过长，从语音信号能量上看，物理上用户是停止了说话，但信息并不完整，或者噪声导致识别出文字，误以为用户响应；
机器等待过长：一般是由于噪声存在，机器误以为用户正在响应，没有及时做出回应。

看似一个简单的分类任务，做起来可不简单。同样一个“嗯”字，不同的上下文、不同的语调语气说出来，意义就完全不一样。

其实语义完整度的预测并不是新方向。下面，就按照时间顺序，梳理一下几个不同的方案，包括一些开源的工作，不同的方案适应不同的场景，有些看似过时的方案，也许是适合现在业务的。特别是方案5，联合文本+音频的方案，我认为是最合理的。

方案1：VAD和完整度的联合预测

可以参考Google 2019年左右的文章[1]，虽然比较老了，**但优点是相对独立，轻量级。**适合有一定语音背景，训练过VAD模型的朋友。

这篇文章中，他们把语义上的完整度叫做End-of-Query (EOQ)，主要是针对语音搜索场景，同样适用于语音对话。

相比于VAD模型只进行语音、非语音的预测，他们的方案采用多任务学习框架，额外增加了EOQ的预测：

并且考虑到不同领域的应用，比如近场和远场交互，将domain ID作为一个特征。后面，我还会讲到，Domain或者数据覆盖，其实是语义完整度检测的一个比较大的挑战。

方案2：ASR和Turn Detection的联合优化

同样是Google在2022年的文章[2]，由此可见，Google对于这个问题还是很重视的。这个方法适用于有自己的语音识别系统，能够自己训练模型。如果采用了别人的API，就不适合这个方法了。简单来说，就是在语音识别的标签中增加一个特殊的标记符号<pause>来标识短暂的暂停。

当然了论文还是基于RNNT的框架，有一些探索也不具有很大的意义。但这种联合训练方式优点有：

本质上是一种多模态的方式，因为ASR模型天然就是文本+语音的。
可以降低由于数据不匹配造成的性能下降。
不增加额外的模块和系统复杂度。

方案3：纯文本大模型方案

比如Agora开源的TEN Turn Detection[3]，支持三个状态的预测：

Finished：用户完整表达了自己的意图

Wait：用户明确要求AI停止输出

Unfinished：用户表达不完整，还没有完成本轮输入

支持多轮对话管理，可以将长上下文作为条件，支持多语言。

纯文本的方案缺点明显，会丢失语音中能量、语调、情感、频率等信息；TEN Turn Detection采用了文本大模型作为Base模型，需要GPU推理。

优点就是非常容易级联到现有系统。具体实现的时候，将声学VAD的静音判断时间调短，在短暂暂停时，将当前的识别结果送给TEN Turn Detection，根据结果来调整下一步的状态。

方案4：纯音频方案Smart Turn

其实Smart Turn的方案[4]比方案1还要简单，官方也是建议配合VAD使用，VAD检测到静音之后，将整段音频送入Smart Turn进行判断，它并不适合流式的推理。

Smart Turn的优点是部署相对容易，因为底层是Whisper，支持多语言。

但是在真实的、垂直的业务场景中的效果如何，需要实际去验证。

方案5：文本+语音多模态大模型方案

Easy Turn[5]，西工大ASLP开源的一个基于多模态的大模型方案。我个人认为文本+语音多模态的方式，是最好的解决方案，其训练流程融合语音识别的预训练和Turn Detection的后训练。

但是由于这个工作是学术工作，如果想要在工程上进行应用，其实需要做一些工程化的工作，比如流式推理的时候，需要做好语音流队列管理，ASR结果和语音数据的对应等工作。

基于这个架构，在自己的垂直领域上进行微调，可以进一步解决数据不匹配的问题。

文章对方案3-5做了系统的对比：

其他方案

如果是相对封闭的场景，比如问题有限的信息采集、确认，还可以采用Embedding+完整度计算的方式。这个方式和大模型方案整体比较相近，不过多解释。

挑战和总结

所有的方案，其实都面临一个domain mismatch的问题，他们使用的数据往往和真实业务数据有很大的分布差异，并且会采用大量的合成数据进行模型训练，这些都是影响效果的重要因素。看似简单的问题，其实一点都不简单，它需要模型能力足够强，需要产品设计来兜底。上面的5种方案和思路，也只是一个参考和基线。具体的问题还有具体分析。在大家都用API的时代，细节决定了产品体验，而语义完整度就是这样的重要细节。总结来说：