别再让语音机器人“答非所问”：AI Force任务型语音对话技术总结

推荐语

AI Force如何让语音机器人像真人一样专业又自然？揭秘三段式语音对话技术突破。

核心内容：
1. 任务型语音对话的两大核心挑战：拟人化表达与专业化服务
2. 三段式架构技术方案：TTS优化+双工对话模块+环境声模拟
3. 在营销、催收等场景实现首问语挂断率显著降低的实战效果

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

AI Force在营销、催收、客服服务等多个业务场景都大量依赖了外呼语音对话能力，且都对语音效果有着非常高的要求，AI Force 在过去一年持续投入了语音对话技术建设，逐步沉淀出一套三段语音架构下的的语音对话交互范式，支持了营销，催收，服务等多个业务场景，本文主要总结在这一年中语音对话场景遇到的挑战，技术解法，技术架构的演进以及达到的效果。

快速对话体验：

https://yunxiao-portal.alipay.com/home

AI Force的业务场景主要是面向企业的服务，语音对话也是面向任务的场景，而我们的语音agent也是面向任务型对话来构建的，例如在营销场景，语音agent需要充当营销专家的角色，进行电话营销，包括汽车行业邀约试驾，装修行业确认用户家装需求，教培行业授课等；而在催收行业，语音agent需要充当催收专员，进行电话催收。

这些不同场景的语音对话都有一个要求：语音agent需要像一个真人小二一样，通过语音对话的方式，完成既定的任务。

那么如何让语音agent能像真人一样完成任务？

这里可以抽象成两个要回的问题：

1.如何让机器人更拟人：首先说话表达上如何更拟人，像真人一样表达；对话体验延迟是否低，是否能像人一样快速的反应和回复；对话上能否像人对话一样自然，包括被打断，抢话，实时回应等。

2.如何让机器人更聪明，更专业：首先要能清晰识别用户的话的含义，即ASR识别的准；能明白自己的任务，基于任务与用户进行对话，完成给的任务，包括：能高效地完成对话流程；能用专业的知识进行回答；能使用工具辅助自己完成任务等。

面对这两个核心问题，因端到端语音模型技术目前尚不够成熟，我们采用传统的三段是架构，技术上首先从架构层面将对话拆解为各个模块，然后进行针对性的解决：

1.TTS：除采购第三方TTS服务商外，还进行了自研，对客服的小二声音进行了精调，在实际电话对话上明显提高了拟人化的表达，首问语挂断率大大降低。

2.双工对话模块：主要包含四块：

a.打断判断：机器人说话时，监测用户说话的状态，并且通过微调的打断模型进行语义上的打断判断，实现机器人能自然的被打断；

b.抢话判断：在机器人准备说话时，会判断用户此时的语音活动，用户没有语音活动时，才进行播报；

c.倾听与实时回复：用户说话时，出现思考停顿时，会判断用户连续说话的状态，若判断到有思考或打断机器人说话时，机器人能像人给出衔接反应表示在倾听，说出：“嗯”，“嗯，您说”这样的衔接语；

d.办公网环境声模拟：外呼等客服场景机器人声音通道添加办公网环境声，模拟客服作业，让用户认为就是在和小二对话；

3.极致耗时架构：采用one-server对话技术架构，一通会话除依赖必要的ASR，TTS模型外，对话主链路上的所有核心链路模块在一台服务器上完成，不涉及任何其他的RPC，DB，中间件缓存等操作，极致耗时处理。

1.ASR：目前主要还是采购云ASR模型，基于场景热词提高行业场景的准确率，自研ASR已在调试中

2.agent推理技术架构持续演进：从最初的SOP对话到 基于one model多轮对话，再到自研“衍算”语音推理框架，逐步解决了不支持全双工，模型指令遵循不可控，成本高及复杂业务不能支持的问题；在LLM推理，RAG检索，工具调用上都沉淀了一套语音交互对话上的范式。

3.统一对话上下文管理：统一语音上下文管理【打断，抢话，倾听等控制】和agent对话上下文控制，能更自然的控制语音到agent的上下文信息，控制agent更好的，更专业的表达。

在对这些问题做解法时，技术上也踩了非常多的坑，架构和能力上也在持续的演进，主要分为三个大的阶段：

方案&技术解法

• ASR：基于采购的ASR；

• Agent：复用的在线对话agent，基于大模型+规则构建SOP对话流的方式，整体是基于大模型意图判断后，基于配置的边条件判断选择走到哪个回复节点，在回复节点基于prompt再进行话术生成或返回话术；

• TTS：基于采购的阿里云cosyvoice；

• 上下文工程：语音上下文 和 agent文本对话上下文分开管理；

• 双工对话工程：打断上只要检测到用户说话就打断；没有抢话等逻辑处理；

技术效果

基于三段式初步实现了一套语音对话链路。

效果问题

• 耗时很长：SOP两段式调用大模型，语音和agent处理分开带来的耗时，tts等连接耗时都影响了耗时，统计端到端录音的平均耗时 > 3.4s；

• 泛化能力差 & 运营成本高：agent基于sop流程推进，泛化差，需要穷举；

• 双工对话问题：无法实现全双工对话，一旦打断，如果sop没有边的穷举，很容易就跳转到其他节点；

• 交互体验差：打断过于灵敏，且频繁出现机器人抢话问题。

在第一代的基础上，面对在实际业务中遇到的问题，我们在agent推理架构，tts，上下文工程和双工对话工程上做了大量的优化和改进。

方案&技术解法

• Agent：得益于LLM的效果突破，多轮对话效果上有了明显的提升，我们也从放弃了第一代SOP的推理方案转为全部用LLM进行推理，将整个任务交给大模型进行推理，每轮请求大模型的内容由四部分构成：任务System prompt + 用户对话上下文 + 用户个人背景信息 + 用户当前问题输入。

• TTS：基于开源的cosyvoice，基于真实服务对话数据进行了精调，在客服，营销场景语音表达上拟人度有明显的提升。

• 上下文工程：将语音对话上下和agent文本对话上下文统一管理，更好的控制双工对话。

• 双工对话工程：

• 打断：升级成支持语义打断，在外呼任务型场景下，主要是用户“听我说”，大部分是不需要打断的，有明确的打断语义才进行打断。技术上通过：【黑名单 + 语义打断模型 + 白名单】规则+模型双重判断下进行用户真实意图的判断；

• 抢话：引入话轮判断，agent在准备说话时会判断用户的说话状态，若检测到用户有语音活动，则先停止说话，防止agent抢用户话；

• 倾听模式：语音agent双工对话上新建了倾听模式，用户说话时，出现思考停顿时，会判断用户连续说话的状态，若判断到有思考或打断机器人说话时，机器人能像人给出衔接反应表示在倾听，说出：“嗯”，“嗯，您说”这样的衔接语；

• 背景声模拟：在agent声音通道模拟办公白噪声，模拟小二作业环境，用户交互更真实；

• 对话架构上：升级到one-server架构，一通对话，所有逻辑在一台服务上处理，在工程链路上的处理耗时减小到极致。

技术效果

• 耗时：平均耗时 <= 1.7s，对话体验明显提升；

• 对话流畅性：升级到全双工交互，打断等效果明显提升，基本没有抢话；

• TTS表达拟人感：基于自研的TTS，真人感明显提升，TTS对话评测评分多项优于云TTS。

体验示例

也可直接在上面的链接直接体验最新效果。

效果问题

• 文本对话不可控：多轮对话非常依赖基模效果，目前的对话都只能选择最高的qwen3-plus-prem或qwen-max-prem高性能模型；

• 复杂业务需求无法承接：再面对更复杂的对话场景下，基于one-model推理的方式已无法支持，模型Prompt太大，导致模型更容易发挥，同时更复杂的场景也要求更严格的对话流程和更专业的agent，需要调用rag和工具等；

• 成本高：每次请求都需要完整的剧本prompt 和对话上下文，输入token非常高，必须使用prem高性能模型，整体成本也比普通的plus或max贵5倍；

• 耗时不稳定：每轮传入的prompt大，若没有命中模型缓存，首包耗时非常长，而在外呼语音对下，这种现象可能会让用户直接挂掉电话。

在第二代技术的基础上，我们主要优化了agent推理框架，自研了一套语音场景的agentic推理框架。

通过自研一套语音对话场景的agent推理框架，结合语音场景【强耗时短】的特点，构建了一套语音agent，语音对话场景下rag检索和语音对话工具执行的交互和推理范式，目前效果正在真实场景验证中。

基于以上一年的架构和技术演进，逐步沉淀了一套三段式的语音对话架构，主要特点：

one server架构

一通语音对话，所有服务，会话上下文管理，agent推理等集中在一台服务器，极致耗时处理。

模型插件化

ASR，TTS，语义打断模型插件化，可平滑切换其他模型或三方服务进行支持。

“衍算”推理框架

融合并行推理思路，多轮对话agentic任务状态推进，建立语音场景的RAG和工具调用技术范式。

同时与one-model方式并存，可多项选择。

三段式语音对话交互范式

分为五大模块，各个模块协同控制，解决拟人对话和专业对话的问题。

整体对话架构如下：

语音场景下的对话相较在线agent对话，主要有两个很大的特点：“延迟要足够短”，“双工交互能顺畅执行”

而结合我们在实际业务中遇到的问题，任务型语音对话下的agent可以归为六类问题：

• 耗时问题：语音场景对耗时非常敏感；

• 双工对话问题：语音对话用户会随时打断或切换状态，agent需要基于用户的话进行快速切换并能继续完成任务；

• 推理准确性问题：如何让agent指令遵循的更好，更好的完成对应的任务，在多次对话下不发散，不发挥；

• 专家问题：在引入rag和工具调时候如何流畅对话交互？

• ASR识别不准后对话完成度问题：asr识别不准的情况下，仍需要尽可能的完成对话；

• 成本问题：如何有效地控制模型的成本以及运营的成本。

在结合第一代和第二代的对话架构里，采用的sop推理和one-mode推理都有不同的问题：

我们在建设语音对话的过程中，agent推理分别经历了SOP方式的推理和one-model方式的推理，我们期望能结合两者的优势：强指令遵循和内容可控性，低成本，支持语义双工等，建设一套适合语音对话场景下的推理引擎。

整体的思路大致是一个学生执行，一个老师教，学生的职责是对当前用户的问题进行回复以及执行对话任务；老师的角色主要是对对话做总结以及指导学生在下一轮进行更好的对话，在经过大量的实验和验证后，逐步形成了现在的V1版本。

PS：为什么叫“衍算”，运行时推理链路包含两个主要的子agent:

• planner：充当老师的角色，主要负责推衍和指导下一轮对话；

• reasoner：充当学生的角色，执行对话，主要负责计算；

衍算框架的主要架构和推理思路如图：

主要分为两部分：

• 对话剧本的生成与运营：通过具体的场景任务 + 衍算任务生成提示词 -> 生成衍算任务思维图，运营可基于生成的任务思维图进行可视化运营，最后生成可实际对话的任务思维；

• 对话推理：在实际对话中，基于任务思维一步步完成对话任务。

• 面向任务型：我们主要是外呼场景，而外呼场景都是面向既定任务的，无论是营销，还是服催，还是服务，都是围绕一个范围-将剧本的大任务拆分成多个子任务，每次LLM只需要专注于完成这个分任务下的某几个子任务即可，降低了给LLM的输入，从而让LLM有更好的指令遵循能力

• agentic推进：基于LLM自动化的规划和推进到下一轮任务【planner】，从而解决传统SOP无法回退，语音上无法双工交互问题；并行subAgent处理，保证每一轮次的语音交互耗时。一个轮次的对话由多个subAgent组成，多个subAgent共同作业保障交互效果：

• 并行推理：将推理分为多个agent并行执行，各个agent只关注自己的任务，耗时只由reasoner决定，其他agent都是并行推理，各个agent的交互和通信由对话上下文统一管理：

• plannerSubAgent：一次对话输入后，由plannerSubAgent 进行并行规划，确认当前对话已推进到哪个子任务下。对整个任务进行状态的管理，规划下一轮应该执行的子任务块，不影响当前轮对话。

• reasonerSubAgent：实际推理并回复给用户，先进行全局的检索，检索出对应的规则&限制&知识知识，基于plannerSubAgent规划指导的分任务和子任务，将任务prompt进行组合，直接交由大模型进行推理，将reasonerSubAgent的推理prompt限制在：当前检索的规则&限制 + plannerSubAgent规划的当前轮应该执行的分任务及其子任务，从而约束LLM的prompt的size大小，降低推理耗时，提高指令遵循效果。

• voiceUnderstandingSubAgent：并行音频理解，理解音频的信息，获取音量，音调，识别情绪，识别性别等，从而将音频理解上下文带入到reasonerSubAgent，从而更好的让agent有更好的共情能力，理解能力【规划建设中】。

在复杂场景下，特别是一些需要专业知识背景的场景下，需要进行知识检索，以让agent完成更专业的解答。

而在在线，入呼和外呼场景下对RAG的要求也是不一样的。

一般的RAG链路主要包括以下几个部分，其中query改写和re-rank耗时较高。

在外呼语音对话场景下，知识较少，同时耗时也更敏感【给知识检索预留的耗时 <= 150】。

基于此，外呼任务型场景下我们做了以下处理以达到我们的效果：

• query改写部分：我们去除了query改写，改为补全【因前置asr，可能存在断句不准的问题】；

• 召回部分：qa对和doc文档并行检索；

• 文档切分：改为默认的512大小切分，若切分太大，prompt太大会影响推理耗时，同时我们更多会采用faq召回的方式；

• re-rank：去除，不需要精排；

• embedding模型：算法微调了向量模型，耗时更短；

• 检索链路：agent知识库一般是独立应用，我们为了极致耗时，才去近端包的方式，检索整体与对话链路同属一台服务器，去除了分布式RPC调用的耗时以及知识库内部自己的处理逻辑，只保留调用向量库检索的逻辑；

技术效果

• RT_p95 <= 150ms，平均只有100ms

• 召回率：基于某汽车场景评估top3召回率 >= 80%

在一些更复杂的场景下，我们需要调用工具辅助agent进行推理，例如某家居对话场景下，需要搜集用户所在地地址，搜集后需要调用客户的接口进行门店判断，若当地有门店，就执行A逻辑，若没有门店就执行B逻辑。

我们在语音对话场景下也设计了一套工具调用交互的范式，大致如图所示：

衍算框架的某个任务可以挂上一个工具，执行到具体的任务时，整个推理过程会立即返回一个承接语【减少用户静默等待时间】，然后同步调用具体，调用工具后会再调用模型进行下一步的推理。

• 对话能力上：可支持更复杂的业务场景，例如条件互斥任务推进等；

• 端到端耗时【基于某物流外呼客户场景评测】：

• one-model架构下：平均值约1.7s，RT_p95：约2.32s；

• 衍算引擎：平均值：约1.54s，RT_p95: 约1.72s【平均RT降低160ms，RT_p95降低600ms】；

• 成本：目前复杂场景成本约为one-model的4/5；目标LLM成本可降低到one-model方式的1/10。

• 对话评测上-某物流行业：

目前我们的版本还存在一些问题，例如多人声环境下识别准确率的问题【典型的鸡尾酒会问题】，双工交互效果仍不够顺畅；衍算框架是强任务流，主要面向外呼任务型对话，若用户突然问题跨度大，存在回复不准或重复询问同一个任务等问题，并且无法满足入呼等更加发散的语音对话场景。因此，为了满足更加复杂的业务需求，我们仍需要在整个对话上做更精细化的打磨，提高各个模块的效果从而让整个对话对话效果提升。

未来的方向包括但不限于以下几个方面：

• 衍算效果持续优化：持续优化衍算框架推理效果，包括不限于推理架构，微调行业模型等，从而提高整体的指令遵循准确率；

• 录音：融合传统录音切片优势，支持录音播报；

• 泛服务类agent：衍算框架升级到支持泛服务类对话推理，除外呼任务场景外，支持更复杂的任务型语音对话推理场景；

• 双工交互优化：持续优化打断顺畅度，倾听衔接准确率，打造更自然的对话交互；

• 3a模块&注意力锁定机制探索：对声音做降噪，增强等处理，探索对话注意力锁定机制，优化多人声对话下识别错误问题；

• 多agent协同：目前我们的对话架构初步具备了多个agent协同推理的能力，未来还要继续丰富语音理解agent，plannerAgent多agent的协同的能力，以满足更复杂的业务对话场景和提高交互效果；

随着大模型技术的持续演进，agent的能力边界也在不断拓展，我们也会积极拥抱最新的AI模型，最先进的agent架构，结合这些前沿技术不断优化和丰富我们的语音对话产品。