dw制作网站模板佛山模板网站建站

dw制作网站模板,佛山模板网站建站,北京住房和城乡建设部网站,嘉兴品牌网站建设从2022年优化智能客服开始#xff0c;我就开始尝试优化人机语音对话中的 “语义完整度” 模块。当时大部分人的精力都集中在优化识别率#xff0c;在语音对话系统中#xff0c;这不是一个核心模块#xff0c;似乎是可有可无的#xff0c;但语义上的完整度对于用户体验、信…从2022年优化智能客服开始我就开始尝试优化人机语音对话中的“语义完整度”模块。当时大部分人的精力都集中在优化识别率在语音对话系统中这不是一个核心模块似乎是可有可无的但语义上的完整度对于用户体验、信息收集的效率都有很大的影响。特别是在今天人们对于智能和体验的极致追求下语音对话类各种应用比如陪伴、玩具、客服等场景的大模型升级越来越多的工作开始瞄准这个方向业界需求也在增加这也印证了我们之前的文章中提到的语音应用的趋势之一即从功能实现到体验提升。本文将重点分享几个语义完整度的优化思路、方案和实际挑战。一个完整的级联对话系统的方案本文就不再过多解释有兴趣的朋友可以参考下面的视频什么是语义完整度语义完整度或者叫做Turn Detection轮次检测其实属于用户意图判定的一种主要用来判定用户是否已经完整地表达了自己的想法。一个真正的智能系统应该可以做到有“眼力见”该响应的时候及时回复不该响应的时候保持沉默。但在真实的语音交互场景中经常有以下这几种情况出现机器过早回复用户使用“嗯、啊”等词汇过渡用户的不流利发音或者用户在面对复杂问题的思考间隙过长从语音信号能量上看物理上用户是停止了说话但信息并不完整或者噪声导致识别出文字误以为用户响应机器等待过长一般是由于噪声存在机器误以为用户正在响应没有及时做出回应。看似一个简单的分类任务做起来可不简单。同样一个“嗯”字不同的上下文、不同的语调语气说出来意义就完全不一样。其实语义完整度的预测并不是新方向。下面就按照时间顺序梳理一下几个不同的方案包括一些开源的工作不同的方案适应不同的场景有些看似过时的方案也许是适合现在业务的。特别是方案5联合文本音频的方案我认为是最合理的。方案1VAD和完整度的联合预测可以参考Google 2019年左右的文章[1]虽然比较老了**但优点是相对独立轻量级。**适合有一定语音背景训练过VAD模型的朋友。这篇文章中他们把语义上的完整度叫做End-of-Query (EOQ)主要是针对语音搜索场景同样适用于语音对话。相比于VAD模型只进行语音、非语音的预测他们的方案采用多任务学习框架额外增加了EOQ的预测并且考虑到不同领域的应用比如近场和远场交互将domain ID作为一个特征。后面我还会讲到Domain或者数据覆盖其实是语义完整度检测的一个比较大的挑战。方案2ASR和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的时代细节决定了产品体验而语义完整度就是这样的重要细节。总结来说纯文本的方案无法充分利用音频特征但是容易集成。纯音频方案会缺失语言语义信息。音频文本方案是一个理论上比较完善的方案但是需要匹配的训练数据工程化相对复杂。参考文献[1] https://ieeexplore.ieee.org/abstract/document/9003787/[2] https://arxiv.org/pdf/2208.13321[3] https://github.com/TEN-framework/ten-turn-detection[4] https://github.com/pipecat-ai/smart-turn[5] https://arxiv.org/pdf/2509.23938 Voice Agent 学习笔记了解最懂 AI 语音的头脑都在思考什么