语音对话“活人感”改造：从三段式链路到副语言信息一体化

1. 为什么“能对话”不等于“像活人”1.1 一个被低估的体验断层做过语音助手类产品的人大概都有过这种感受把 ASR、LLM、TTS 三个模块各自单独拎出来测指标都挺好看——识别准确率 95% 以上大模型回答逻辑通顺TTS 音色也自然。可一旦串成完整链路跑起来用户第一句话往往是“怎么感觉像在跟机器念稿子”。这个落差不是错觉而是当前通用三段式链路的结构性缺陷。ASR 把声音转成文字LLM 把文字转成回复文字TTS 再把回复文字转成声音——每一步都在做“信息压缩”而人类对话里最关键的副语言信息语气、停顿、犹豫、呼吸、情绪起伏在第一步就被丢掉了后面两步再怎么优化也补不回来。我最初做语音交互项目时也踩过这个坑。当时团队花了大力气调 TTS 的韵律模型结果用户反馈依然是“听着假”。后来复盘才发现问题根本不在 TTS而在于 LLM 拿到的输入本身就是一具“没有体温的文字骨架”。1.2 通用链路的三个致命假设这条链路之所以走不通是因为它默认了三个在真实对话中根本不成立的假设。假设一文字等价于语义。ASR 输出的是去除了所有副语言特征的纯文本。但人类说“行吧”这两个字配上不同的语调可以表达同意、无奈、敷衍、愤怒四种完全不同的意思。纯文本丢掉了这个区分能力LLM 只能靠上下文猜猜错的概率不低。假设二轮次是离散的。通用链路把对话切成“用户说完→系统处理→系统回复”的离散轮次。但真实对话里用户经常在对方还没说完时就开始回应backchannel比如“嗯”“对”“然后呢”也会有重叠发言、抢话、沉默思考。离散轮次模型处理不了这些。假设三延迟可以靠工程优化解决。很多人觉得只要把 ASR、LLM、TTS 各自的延迟压到足够低整体体验就能接近真人。但真人对话的“活人感”恰恰部分来自于适度的延迟——思考时的停顿、组织语言时的“呃……”这些在工程视角下是“延迟”在体验视角下是“真实感”。把延迟压到零反而更像机器。1.3 本文要解决的问题边界这篇文章不打算讨论“如何把 ASR 准确率从 95% 提到 98%”这类单点优化而是聚焦一个更根本的问题如果目标是让语音对话有“活人感”通用链路需要做哪些结构性改造适合读这篇内容的人包括正在做语音助手/陪伴类产品/客服机器人的开发者对语音交互体验有要求的产品经理以及想理解“为什么语音 AI 听起来假”这个问题的技术爱好者。我会从链路拆解、关键改造点、实操方案、踩坑记录四个层面展开尽量给出可以直接参考的思路和参数。2. 拆解通用链路每一步到底丢了什么2.1 ASR 环节被丢弃的副语言信息ASR 的核心任务是把声波转成文字这个定义本身就决定了它会丢弃大量信息。具体来说以下几类信息在 ASR 输出中基本消失基频与语调曲线同样一句话语调上扬是疑问下降是陈述波动大是激动。ASR 输出统一变成句号或问号丢失了连续的情绪变化。语速与节奏语速快通常表示兴奋或紧张语速慢可能表示犹豫或强调。文字里看不出来。停顿位置与时长停顿在句中是犹豫在句尾是等待回应在句首是思考。这些在纯文本里全部消失。音质与音色变化气声、颤音、笑腔、哭腔这些直接承载情绪的声音特征ASR 完全不保留。非语言声音叹气、笑声、咂嘴、呼吸声大部分 ASR 会直接过滤掉。我实测过一个场景用户用疲惫的语气说“我今天不太想说话”ASR 输出就是这七个字。LLM 看到这句话可能会回复“那你要不要休息一下”。但如果系统能感知到“疲惫”这个副语言特征回复策略可能完全不同——也许应该更简短、更温和甚至主动减少追问。2.2 LLM 环节文字进文字出的局限LLM 拿到的是 ASR 输出的纯文本它擅长的是语义理解和内容生成但对“怎么说”这件事几乎没有控制力。这里有几个具体问题韵律不可控。LLM 输出的文字没有标注哪里该重读、哪里该停顿、语速该快还是慢。TTS 只能靠自己的韵律预测模型去猜猜出来的结果往往和 LLM 想表达的语气不一致。情绪标签缺失。即使 LLM 在文字里写了“笑着说”TTS 也未必能准确演绎。而且让 LLM 在回复里插入情绪标签本身就会影响文字的自然度。回复长度失控。LLM 倾向于生成完整、信息量大的回复但真实对话中人类回复往往很短——“嗯”“真的吗”“然后呢”。长回复在语音场景下体验很差用户听到一半就忘了开头。缺乏对话节奏感。LLM 不知道当前对话是快节奏的你来我往还是慢节奏的深思熟虑。它无法根据节奏调整回复的长度和复杂度。2.3 TTS 环节从文字到声音的最后一公里TTS 是整条链路里最“冤枉”的一环。它拿到的输入是已经被剥了两层皮的纯文本却要负责输出有“活人感”的声音。这就像让一个配音演员只拿着剧本文字却要演出角色的全部情绪——不是不可能但需要极强的文本理解能力和演绎能力。当前 TTS 的主要局限包括韵律预测依赖文本TTS 的韵律模型只能从文字里推断停顿和重音但文字本身不包含这些信息所以预测经常出错。情绪表达有限大部分 TTS 支持的情绪标签是离散的开心、悲伤、中性但真实情绪是连续变化的。缺乏对话上下文感知TTS 不知道上一句用户说了什么也不知道当前对话的氛围只能孤立地合成每一句。呼吸和停顿不自然真人说话有呼吸声、有自然的停顿TTS 合成的语音往往过于“干净”反而显得假。2.4 三段式链路的延迟叠加问题除了信息丢失通用链路还有一个工程上的硬伤延迟叠加。假设 ASR 端到端延迟 300msLLM 首 token 延迟 500msTTS 首包延迟 200ms那么用户说完到听到第一个字至少需要 1000ms。这还没算网络传输和调度开销。而真人对话的响应延迟通常在 200-500ms 之间超过 800ms 就会让人觉得“卡顿”。更麻烦的是这三段是串行的无法并行。ASR 必须等用户说完才能输出完整文本LLM 必须等 ASR 输出才能开始处理TTS 必须等 LLM 输出才能开始合成。每一段都在等上一段延迟自然叠加。我试过用流式 ASR 流式 LLM 流式 TTS 来缓解这个问题确实能把首字延迟压到 600ms 左右但代价是准确率和自然度都会下降。而且流式处理会进一步加剧信息丢失——流式 ASR 为了低延迟往往更激进地丢弃副语言信息。3. 改造思路从“三段式”到“感知-决策-表达”一体化3.1 核心思路保留副语言信息通道要让语音对话有“活人感”最关键的一步是在 ASR 之后、LLM 之前增加一个副语言信息提取与编码的环节。这个环节不改变 ASR 的文字输出而是额外输出一组副语言特征向量和文字一起送给 LLM。具体来说可以从原始音频中提取以下特征特征类别具体特征提取方式用途韵律特征基频曲线、能量曲线、语速音频信号处理判断情绪、强调停顿特征停顿位置、停顿时长VAD 对齐判断犹豫、等待音质特征气声比例、颤音、笑腔声学特征提取判断情绪状态非语言声音笑声、叹气、呼吸声音事件检测增强真实感这些特征不需要全部送给 LLM可以压缩成一个低维向量比如 16 维或 32 维作为“副语言 token”和文字 token 一起输入。LLM 在生成回复时可以同时参考文字内容和副语言信息从而生成更贴合当前对话状态的回复。3.2 LLM 输出改造文字 韵律标注LLM 的输出不能只是纯文字还需要附带韵律标注。有两种做法做法一LLM 直接输出带标注的文本。比如在文字中插入韵律标记像这样[慢速][低沉]我今天不太想说话[停顿500ms][轻声]让我一个人待会儿这种做法的好处是 TTS 可以直接解析标注控制力强。坏处是标注会占用 token影响生成效率而且 LLM 未必能准确预测韵律。做法二LLM 输出文字 独立的韵律向量。LLM 在生成文字的同时输出一个韵律向量序列每个文字 token 对应一个韵律向量。TTS 同时接收文字和韵律向量合成语音。这种做法更灵活不占用文字 token但需要 LLM 和 TTS 之间有额外的接口约定。我目前更倾向于这种做法因为它对现有 LLM 的改动更小。3.3 TTS 改造从“文本转语音”到“意图转语音”TTS 的输入不应该只是文字而应该是“文字 韵律 情绪 对话上下文”。具体来说TTS 需要接收以下信息文字内容要说什么。韵律标注每个字的重音、时长、音高。情绪标签当前回复的整体情绪倾向。对话上下文上一句用户说了什么当前对话的氛围。角色设定这个 AI 角色的音色、语速、口头禅等。有了这些信息TTS 才能合成出有“活人感”的语音。比如同样是“好的”两个字在用户说了一件开心的事之后应该用轻快上扬的语调在用户抱怨之后应该用温和低沉的语调。这些差异需要 TTS 根据上下文动态调整。3.4 延迟优化并行化与预测延迟问题需要从架构层面解决。我的思路是ASR 和副语言特征提取并行。两者都从原始音频出发互不依赖可以同时进行。LLM 流式生成 TTS 流式合成。LLM 生成第一个 token 后立即送给 TTSTTS 合成第一个字后立即播放不用等整句生成完。预测式 TTS。根据 LLM 已经生成的文字预测后续可能的韵律走向提前准备合成参数。这样当后续文字到达时可以更快合成。缓存常用回复。对于“嗯”“好的”“我明白了”这类高频短回复可以预合成多个情绪版本直接调用不用实时合成。实测下来这套组合拳可以把首字延迟压到 400-600ms基本接近真人对话的响应速度。4. 实操方案从零搭建一个有“活人感”的语音对话原型4.1 整体架构设计我搭的原型架构是这样的用户音频 → [ASR模块] → 文字 → [副语言提取模块] → 副语言向量 ↓ [LLM模块] → 回复文字 韵律向量 ↓ [TTS模块] → 合成语音 ↓ 播放关键改动在于增加了副语言提取模块以及 LLM 输出韵律向量。下面我分模块说明具体实现。4.2 ASR 模块选型与配置ASR 我选的是流式识别方案因为需要低延迟。具体配置采样率16kHz这是大多数 ASR 模型的标准输入。音频格式16bit PCM单声道。流式分块每 200ms 一个 chunk平衡延迟和准确率。VAD使用能量 零率双门限阈值需要根据环境噪声调整。注意流式 ASR 的 chunk 大小很关键。太小会导致识别准确率下降太大会增加延迟。我实测 200ms 是比较好的平衡点但具体要根据你的场景调整。安静环境下可以降到 100ms嘈杂环境下建议 300ms。ASR 输出除了文字还需要输出每个字的置信度和时间戳这些信息后续会用于副语言特征对齐。4.3 副语言特征提取模块这个模块是整个改造的核心。我从原始音频中提取以下特征基频曲线用自相关法或 YIN 算法提取帧长 25ms帧移 10ms。基频的变化范围可以反映情绪波动。能量曲线计算每帧的 RMS 能量归一化后得到能量包络。能量突变通常对应重音或情绪变化。语速通过 ASR 输出的字时间戳计算单位是字/秒。正常语速约 4-5 字/秒快语速 6 字/秒以上慢语速 3 字/秒以下。停顿检测基于 VAD 输出检测静音段。停顿超过 300ms 记为有效停顿超过 800ms 记为长停顿。非语言声音检测用一个小型声音事件分类模型检测笑声、叹气、呼吸、咂嘴等。这个模型可以自己训练也可以用开源的声音事件检测工具。这些特征提取出来后需要和 ASR 的文字对齐。我的做法是以字为单位每个字对应一个特征向量包含该字时间范围内的基频均值、能量均值、语速、前后停顿等信息。4.4 LLM 提示词设计与韵律向量输出LLM 的提示词需要包含以下信息你是一个语音对话助手。当前用户说了一句话文字内容是{text} 副语言特征显示{prosody_features} 请生成一个自然、简短的回复。回复要符合当前对话的情绪氛围。 同时请为你的回复生成韵律标注格式为每个字后面跟一个韵律向量 [音高偏移, 时长倍数, 重音程度]。韵律向量的三个维度含义音高偏移相对于基准音高的偏移量单位是半音范围 -12 到 12。时长倍数相对于正常时长的倍数范围 0.5 到 2.0。重音程度0 到 1 之间的连续值表示该字的强调程度。LLM 输出韵律向量时不需要非常精确大致合理即可。TTS 会根据这些向量做韵律调整即使有偏差也比完全没有标注要好。实操心得让 LLM 直接输出韵律向量一开始效果不稳定。后来我改成让 LLM 先输出文字再单独用一个小的韵律预测模型基于 BERT 或类似结构来预测韵律向量效果好很多。韵律预测模型可以用少量标注数据微调成本不高。4.5 TTS 模块的韵律控制TTS 我选的是支持韵律控制的方案。具体来说需要 TTS 支持以下控制接口音高曲线接收每个字的音高偏移调整合成语音的基频。时长控制接收每个字的时长倍数调整合成语音的节奏。重音控制接收每个字的重音程度调整合成语音的能量。情绪标签接收整体情绪标签调整音色和语调。如果用的 TTS 不支持这些控制可以考虑在 TTS 输出后做后处理用信号处理的方法调整基频和时长。但后处理的效果通常不如原生支持好。我实测下来支持韵律控制的 TTS 和不支持的在“活人感”上的差距非常明显。前者听起来像真人在说话后者听起来像机器在念稿。4.6 延迟优化实操延迟优化我做了以下几件事并行化ASR 和副语言特征提取并行执行两者都完成后才送给 LLM。流式处理LLM 流式生成每生成一个 token 就送给 TTS。TTS 流式合成每合成一个 chunk 就播放。预测式合成根据 LLM 已经生成的文字预测后续可能的韵律提前准备 TTS 参数。缓存高频短回复预合成多个情绪版本直接调用。实测延迟数据环节优化前优化后ASR300ms200ms副语言提取-50ms并行LLM 首 token500ms300msTTS 首包200ms150ms总计1000ms500ms500ms 的响应延迟基本接近真人对话的体验了。5. 常见问题与排查技巧实录5.1 副语言特征提取不准怎么办这是最常见的问题。副语言特征提取受环境噪声影响很大嘈杂环境下基频和能量曲线都会失真。我的排查思路是先检查音频质量用频谱图看一下如果噪声能量和语音能量接近说明信噪比太低需要先做降噪。检查 VAD 阈值VAD 误判会导致停顿检测错误。可以手动标注几段音频调整 VAD 阈值直到准确率满意。检查特征归一化不同录音设备的音量不同能量曲线需要归一化。我通常用整段音频的 RMS 均值做归一化基准。考虑场景适配安静环境和嘈杂环境可以用不同的特征提取参数。我通常会准备两套参数根据信噪比自动切换。5.2 LLM 生成的韵律向量不合理LLM 生成的韵律向量经常出现极端值比如音高偏移 12 或时长倍数 2.0导致 TTS 合成的声音很怪异。解决办法限制范围在提示词里明确告诉 LLM 韵律向量的合理范围并在后处理时做截断。平滑处理对韵律向量序列做滑动平均避免相邻字的韵律突变。用独立模型预测如前所述用专门的韵律预测模型代替 LLM 直接输出效果更稳定。5.3 TTS 合成语音不自然即使有韵律控制TTS 合成的语音有时还是不自然。常见原因和解决办法问题可能原因解决办法机械感强韵律变化太少增加韵律向量的变化幅度断句错误停顿位置不对检查韵律标注的停顿位置情绪不符情绪标签和文字不匹配检查 LLM 输出的情绪标签音质差TTS 模型本身问题换更好的 TTS 模型呼吸声缺失TTS 不生成呼吸声在长句中间手动插入呼吸声实操心得呼吸声是“活人感”的重要来源。我试过在 TTS 合成后在适当位置插入真实的呼吸声样本效果提升很明显。呼吸声的位置可以根据停顿检测结果来确定通常在长停顿处插入。5.4 延迟还是太高如果优化后延迟还是超过 800ms可以从以下方面排查网络延迟如果 ASR、LLM、TTS 部署在不同服务器网络延迟可能占很大比例。考虑合并部署或使用更近的节点。模型推理速度检查各模块的推理耗时如果某个模块特别慢考虑换更小的模型或做量化加速。流式处理是否真正生效有些框架号称支持流式但实际上还是等整句处理完才输出。需要实际测试验证。音频播放缓冲播放端的缓冲设置也会影响感知延迟。减小缓冲可以降低延迟但可能增加卡顿风险。5.5 多轮对话中副语言信息如何传递单轮对话的副语言处理相对简单多轮对话就复杂了——上一轮的情绪状态是否应该影响下一轮我的做法是维护一个“对话状态向量”包含当前的情绪基调、语速基调、正式程度等。每轮对话结束后用当前轮的副语言特征更新这个状态向量。下一轮 LLM 生成时同时参考当前轮的副语言特征和对话状态向量。这样可以让对话有连续性。比如用户第一轮很兴奋第二轮虽然文字内容平静但对话状态向量还保留着兴奋的余温LLM 的回复可以稍微活泼一些更符合真实对话的惯性。6. 一些实测数据和经验总结6.1 改造前后的对比我用同一组测试对话对比了改造前后的体验指标通用链路改造后首字延迟1000ms500ms韵律自然度人工评分 1-52.84.1情绪匹配度人工评分 1-52.53.9“活人感”评分人工评分 1-52.34.0用户愿意继续对话的比例45%78%这些数据来自我自己的小规模测试20 个测试者每人 10 轮对话不算严谨但趋势很明显。6.2 几个反直觉的发现发现一适度的不完美反而更真实。完全流畅、没有任何停顿和犹豫的语音听起来反而像机器。我在 TTS 合成时故意保留了一些小的停顿和语气词体验评分反而更高。发现二情绪不需要太强烈。一开始我把情绪标签的强度调得很高结果听起来很夸张。后来把强度降到中等反而更自然。真人对话的情绪表达通常是微妙的不是戏剧化的。发现三副语言特征不需要太精确。我一开始追求精确的基频和能量提取后来发现即使用粗略的特征只要方向对LLM 就能做出合理的调整。精确度不是关键关键是特征要能反映情绪的大致走向。发现四短回复比长回复更有“活人感”。LLM 倾向于生成完整的长回复但在语音场景下短回复5-10 个字听起来更自然。我后来在提示词里强制要求 LLM 生成短回复体验提升明显。6.3 后续可以继续优化的方向这个原型还有不少可以改进的地方。比如副语言特征提取可以加入更多维度像音色变化、共振峰偏移等。LLM 的韵律预测可以用更好的模型比如基于扩散模型的韵律生成。TTS 可以尝试端到端的方案直接从文字 副语言特征生成语音跳过中间的韵律标注环节。另外多模态的融合也值得探索。如果系统能同时获取用户的面部表情或姿态信息副语言特征的提取会更准确。不过这就超出纯语音对话的范围了。我个人在实际操作中的体会是语音对话的“活人感”不是一个单点问题而是整条链路的系统性问题。只优化 ASR、LLM 或 TTS 中的任何一个效果都有限。真正有效的做法是在链路中增加副语言信息的传递通道让每个模块都能感知到“怎么说”而不只是“说什么”。这个改造思路不复杂但需要对每个模块做针对性的调整工程量不小。不过从体验提升的幅度来看这些投入是值得的。