魔鬼藏在细节里，而让 Voice Agent 像人一样自然对话的秘密，就藏在 AI 是否能主动沉默、打断或发起对话的细节里。

你是否也曾憧憬过，AI 能够主动提醒你注意来往车辆，根据你的偏好为你推荐周边的特色美食，在你情绪低落时主动提供心理疏导，在你健忘时提醒你重要的日程安排？ 或许在不久的将来，AI 不再仅仅只是冷冰冰的程序，而是摆脱工具定位，成为我们生活中值得信赖的伙伴。

本期 Meetup，我们邀请了来自 Soul、Voila、MagicHub 社区、TEN VAD 和 TEN Turn Detection 等项目的开发者和专家，共同探讨主动式语音 AI 的发展趋势。议题涵盖全双工通信、情境感知、轮次检测与管理、语音 VAD 等多个方面。

本次活动的微信群将持续开放，作为主动式语音 AI 主题的长期交流平台，欢迎通过文末方式加入我们的社区～🎉

以下内容基于会议纪要音视频整理，难免出现错漏和不严谨。如有疑问，欢迎评论留言，我们很乐意联系分享者确认交流。

主题分享

史业民@Viola 作者

实时互动是 AI 从虚拟走向现实的必经之路

我将这次分享的题目定为「实时互动世界」，而没有选择「实时互动与语音 AI」等更具体的名字，是因为我认为， 一个理想的实时互动系统更接近于现实世界所需要的人工智能，它应该具备更多模态的互动能力，例如语音、视觉，以及未来可能引入的面向机器人、面向更多场景的能力。

首先，什么是实时互动？可能大家在论文或者一些活动中听到过这个词，或者其他一些类似的词汇，比如全双工，以及在 Viola 的论文中使用的「自主」。在这里，我将这些概念统一起来，简称为「实时互动」。

为了更清晰地说明实时互动的概念，我们不妨从反例入手。ChatGPT、Kimi 等工具是「回合制」交互，需等待用户输入完毕才开始响应，用户也无法在 AI 回复时插话。可以类比回合制游戏，当用户需要进行操作时，游戏世界是静止的，用户的操作指令执行后，世界才继续运转。而实时互动强调反馈的即时性，不局限于完整语句，也可能是语气词等表达。

需要注意的是， 实时互动不等同于低延迟。 低延迟侧重快速响应结束信号，AI 可能并没有真正理解你说的内容，而是快速检测到你说话结束并实时反馈，本质上仍接近全双工模式，

实时互动为什么重要？我在这里列出三个 feature，实际上可能更多。首先， 现实世界中的任务通常没有明确的结束时间点，例如让机器人拿水，我们希望它能自动执行，而非等待指令。第二， 现实世界的行动和反应是同步而不是按照顺序发生的，突发事件会影响 AI 的决策，AI 需要具备实时互动的能力，以应对这些情况。例如， 机器人拿水时发生地震，它需要能动态调整姿态。此外，实时互动 AI 不应有如 ChatGPT 在回复时的「忙碌」状态，而应随时感知环境变化。

语音模型的技术细节与关键经验

这种交互方式的变革，并非单纯的智力或能力提升。我们基于此尝试了两个主要方向的研究：语音方向是我们重点之一，并且已经开源了相关模型。 我们的目标是让语音模型实现实时甚至全双工的交互，使其更接近人类的自然对话方式， 例如在对方说话时可以随时打断，反之亦然。

这个模型基于离散 token 的原始动态模型构建。为了实现实时互动，我们在模型层面进行了较多的改进， 主要集中在 token 设计和模型架构上。 在 token 设计方面，为了实现实时性，一方面需要模型以流式方式工作，另一方面也需要提高模型的工作速度。我们压缩了 token 的数量，将其控制在每秒 25 个。在模型架构上，我们将其改为了 input 和 output token 交错的方式，即每输入一个 token，就需要输出一个 token，从而使其变成了一种全双工的工作模式。

此外， 由于我们做的是语言模型，音色克隆非常重要。 因此，我们在训练这个模型时，着重让它支持音色克隆。这个模型有两个分支：N to N 版本 是一个标准的 Transformer 架构模型，支持语音输入和语音输出，需要等待完整输入后处理；而 VOA Autonomous 是我们主要探索的全双工/自主/实时模型，它可以在任意时刻接受语音输入，并同时产生语音输出。

这个模型的细节我简单介绍一下。为了支持快速输出，我们将 token 压缩至每秒 25 个，但实际单个 token 难以充分表达 40 毫秒的音频信息。 我们的解决方案是使用多个 token（例如四个、六个或八个）来表示这一瞬间的信息。 为了避免 token 数量爆炸，我们将这 40 毫秒的 token 额外拆分出一个维度，交给第二个 Transformer（我们称之为 Audio Transformer）进行处理。这样，主体的语言模型 backbone 负责生成一个 high-level 的 token，然后 Audio Transformer 再将这个 token 解码为多个更精细的 audio token。

关于音频模型开发，有几个关键经验： 首先，audio 的 next token prediction 对最终效果至关重要，无法通过少量数据跑通后再扩大的方式实现。其次，语音文本穿插是提升效果的 trick，而非必要功能。最后，多任务同时训练会产生冲突，若聊天模型智力水平下降，则往往是语音或文本数据不足。

总结而言，一个高质量的原生语音动态模型的关键在于：充足的数据、相对合理的架构（架构大致正确即可），以及尽可能减少人工干预的设计。

视觉方向的探索

语音方向之后，我简要介绍视觉方向的 World Model。它将图像、视频等多模态信息转换为离散/连续 token，进行端到端训练，支持多模态输入输出，模拟真实/虚拟世界。基于此，我们推出了 Deep Game 模型，支持实时互动，可实时生成视频，具备无限时长模拟和文本指令控制能力。目前模型延迟约 250 毫秒，帧率 16FPS，分辨率 720p。

我认为实时互动是 AI 从虚拟走向现实的必经之路。但 AI 如何从现实世界获取反馈并自我提升，以及如何从软件走向硬件，都是未来的重要研究方向。

Q&A:

Q：如果 AI 觉得用户需求不清晰，是否会主动要求更多信息？

A：理想情况下应主动请求更多信息，但目前 AI 尚不具备此能力，易产生幻觉。这是一个重要的研究方向，但现有成果仍有不足。

Q：Viola 使用了多少训练数据？语音和文本数据分别是多少？全双工的地方如何操作？是否使用了额外的 VAD？模型如何学习接话？

A：纯语音数据使用约 50-100 万小时，文本数据采用大模型全部数据，并通过重复语音数据平衡数据分布。全双工在模型侧实现，未采用额外 VAD。训练数据主要来自播客，未拆分段落。数据处理时使用 VAD 检测说话人，并在起始点加入 human/AI token 以区分说话人，由 AI 自主接管。

Q：Viola-autonomous 折中自动模式（双流模式）比单流模式推理成本高很多，训练难度也高很多。训练数据是来自真实数据还是构造数据（带 overlap）？智商水平差距多少？

A：推理成本高是事实，需要优化。自研推理引擎通过 batch 和并行处理，使单张 GPU 可 serve50 个 session。训练难度确实高很多，尤其在数据方面。Pre-train 数据主要来自真实播客数据，质量占比 90%，后续数据占比 10%。数据处理尽量使用原始数据。合成数据模拟带/不带 overlap 场景，力求真实，其中 Overlap 数据相对较少，gap 时间随机分布在 0-800 毫秒之间。

Q：如果一个卡并行处理 50 个 session，会不会导致延迟提升很多，失去了双工的感觉？

A：不会。在 serve 50 个 session 的前提下不会产生额外延迟。因为每个 token 的 audio 对应 40 毫秒，但生成一个 token 的时间只需要 10-20 毫秒，有 20-30 毫秒的时间做其他事情。

Rambo\@TEN VAD

TEN VAD：为对话式 AI 打造的高性能、低延迟语音活动检测引擎大家好，我是来自 TEN VAD 团队的，今天想和大家分享语音活动检测（VAD）的相关技术，以及我们 TEN VAD 的优势：低延时、低功耗、效果优异， 是一款高鲁棒性的 VAD 产品。

首先，简单介绍一下 VAD 的定义。VAD 全称 Voice Activity Detection，即语音活动检测。如下图所示，蓝色部分代表语音信号，横轴为时间，纵轴为采样点。红色线条表示语音活动状态，低电平（接近于零）通常对应无语音状态，例如噪声或伴奏；高电平（接近于一）则表示检测到人声。因此，VAD 的核心功能是判断输入语音帧中是否包含人声，实现人声与非人声的二元分类。

近年来，VAD 技术备受关注，尽管它在语音信号处理领域一直扮演着重要角色。随着对话式人工智能（Conversation AI）和全双工技术的兴起，VAD 在各类解决方案中的应用日益广泛。在 Conversation AI 领域，VAD 最核心的作用在于预测语音的起始点（Start of Sentence， SOS）和结束点（End of Sentence， EOS）。

SOS 和 EOS 事件在对话式 AI 中有何作用？简单来说，当智能体监听时，VAD 检测到持续语音活动会触发 SOS 事件，提示用户开始发言；检测到持续非语音活动则触发 EOS 事件，启动轮流检测，判断是否需要响应。反之，若智能体正在应答，用户突然发言触发 SOS 事件，系统需判断是否中断应答。因此， VAD 对优化响应体验和轮流检测至关重要，且越早检测到 SOS/EOS 事件，端到端延时越低。

VAD 落地挑战：噪声、失真与算力限制

尽管 VAD 算法看似简单，仅需区分人声与非人声，但要实现高性能的 VAD 绝非易事，面临着诸多实际挑战：

• 复杂多变的声学环境： 现实环境中充斥着各种噪声，从持续的稳态噪声到突发的瞬态噪声，再到混响和多人同时说话的干扰，这些都会显著影响 VAD 的准确性。

• 麦克风质量及传输限制： 麦克风的质量和连接方式直接影响 VAD 性能。低质量麦克风或蓝牙连接可能导致有效频率范围受限，采集到的语音信号质量下降，增加识别难度。

• 信号处理算法的潜在影响： 传统的 3A 算法（降噪、回声消除、自动增益控制）虽然可以消除一部分干扰，但也可能在某些情况下对语音信号造成损伤，导致语音失真，从而影响 VAD 的判断。此外，网络传输过程中的编码失真或丢包也会对 VAD 造成不利影响。

正是因为 VAD 承担着人声/非人声判断这一核心能力，并且被众多模块广泛调用，所以对 VAD 算法提出了很高的要求。首先，准确性是根本。其次，如前所述，必须具备低延时特性，以保证实时交互体验。最后，考虑到 VAD 可能会被多个模块同时调用，因此需要 VAD 的内存占用和运算量足够低，才能保证整体系统的效率，即需要 VAD 具备 「快速、轻量、且效果优秀」 的特点。

TEN VAD：高效精准低延时，Agent 的理想之选

相信很多小伙伴都用过 WebRTC VAD。 它的核心原理是基于基音周期（Pitch）来进行 VAD 估计。 基音周期是指发浊音时声带震动的频率。判断的依据很简单：如果估计出的基音周期大于零，则认为有人声；如果接近于零，则认为没有语音。通过这样一个简单的特征，就可以进行人声/非人声的区分。当然，这种基于基音周期的 VAD 存在一些问题。比如，当人发出轻音（例如「丝」音）时，声带是不振动的，这时估计出的基音周期为零，但它实际上是人声部分，这会导致较高的漏检率。另外，当遇到一些伴奏或者 Bubble Noise 时，信号中也会存在谐波结构，这时估计出的基音周期就不为零，这会导致较高的误警率。

接下来将介绍我们基于神经网络训练的 TEN VAD，我概括了以下几点特点：

首先，我们的 VAD 融合了音频 AI 领域广泛应用的 Fbank 特征。这种压缩特征的使用，能够有效地控制模型规模。与此同时，我们也没有抛弃物理上的基音周期特征，而是将其与 Fbank 特征进行了的融合。在损失函数的设计上，除了常见的 Cross Entropy Loss 之外，我们还引入了 Domain Loss。

此外，虽然目前开源的部分仅包含 Voice Detection 功能，但在模型训练阶段，我们采用了 Masked Task 方式进行辅助预测。实践证明，这种辅助训练方式能够显著提升 VAD 的整体性能。

为了确保训练数据的质量，我们投入了大量精力，对 1000 小时的真实语音数据进行了人工标注。我们甚至采用了双人交叉标注的策略，只有当两位标注人员的标注差异小于 5% 时，该语料才会被最终纳入训练数据集。

这张 PR 曲线图展示了我们 TEN VAD 的优越性。横坐标为召回率（Recall），纵坐标为精确率（Precision），数值越高越好。图中，绿色线代表基于基音周期的 WebRTC VAD，红色线为我们的 TEN VAD，蓝色线为 CVC VAD。可以看出，TEN VAD 的 PR 曲线最高。

TEN VAD 对 Agent 更友好，主要体现在以下几点：

• 更快的 EOS 检测： 面对明确的 EOS，TEN VAD 能更快地判断为非人声，降低响应延时。

• 更准确的静音间隔检测： 能够准确识别连续两句话间的短暂静音间隔，避免 Silero VAD 可能出现的漏判。

在性能方面，我们对比了 Lib Size 和 RTF（Real-Time Factor，处理一秒音频所需时间，越小越好）。在 Linux（Intel 6348）CPU 上的测试结果显示：TEN VAD 的 RTF 为 0.0086，即处理一秒音频需 8.6 毫秒，优于 Silero VAD 的 12.7 毫秒。 此外，TEN VAD 模型大小仅几百 KB，远小于 Silero VAD 的两兆多。我们已开源 ONNX 模型和预处理代码，方便大家部署到各类硬件平台和架构上。

TEN VAD 开源了 ONNX 模型及相关预处理代码，开发者可以在任何平台和硬件架构上部署 TEN VAD。让 Voice AI Agent 更加拟人化。

TEN VAD 是一个低延迟、低功耗、高准确率的语音活动检测模型（Voice Activity Detector）。它非常轻量，相比 Silero VAD，TEN VAD 的 RTF 减少了 32%，library size 减少了大约 86%。

作为对话式 AI 的原子能力，TEN VAD 通过准确识别音频帧中是否有人声，提升人机对话的交互体验。同时，TEN VAD 还支持无缝集成主流对话式 AI Agent 开源框架 TEN Framework。

相关链接：https://github.com/TEN-framework/ten-vad

Q&A:

Q：声学 VAD 语音全双工交流是否需要结合语音判断结束？

A：是的。单独的 VAD（从语音信号层面判断人声/非人声）不能独立用于全双工。必须结合后面的语义判断（turn detection）。声学判断（语音信号层面）和文本/文字判断融合，才能有更好的全双工体验。单独用 VAD 无法实现好的体验。

Q：开源协议有什么限制吗？

A：TEN VAD 沿用 TEN Framework 的开源协议，但取消了 TEN Framework 对端侧的限制，可以在端侧/云端部署。

Q：TEN VAD 如何能判断出两句独立的话之间的静音呢？是有语义理解能力在里面吗，怎么能判断出是两句独立的话。

A：TEN VAD 通过信号层面判断，检测两句独立话语之间的静音，没有语义信息，需与 turn detection 结合。判断 EOS 时，需要设置参数，定义多久的非人声被认为是 EOS。

Q：TEN VAD 是如何判断 EOS 是说话停止还是短暂的停顿？

A：不同人的讲话方式不同，停顿习惯不一样。不能单纯依靠 VAD 判断 EOS，需要结合语义信息，进行语音和语义模态融合。

Q：TEN VAD 有推荐的硬件配置吗？

A：TEN VAD 运算量小，几乎不计，可在任何硬件上运行，内存占用小（几百 K）。

Q：有 2 个小问题：1。我们经常发现 VAD 在处理轻音的开始或结束的时候存在丢字，导致不需要被切片成需要，有好的处理意见吗？2.当前没有兼容 8k，有计划支持 8k，现在从 16k 转 8k 会有一定的延迟

A：TEN VAD 在处理轻音方面可能效果更好。计划兼容 8k 采样率。TEN VAD 目前输入是 16k，可以用 8k 转为 16k 后使用。内部讨论模型是否需要适配 8k。

Q：模型预测输出的颗粒度，是一帧一帧吗，会出现预测结果是 010101 这种情况吗，一帧人声，一帧非人声，一帧人声……

A：模型预测输出是一帧一帧的，可能会出现 010101 情况。使用 VAD 时，需要根据任务进行平滑操作，避免此问题。

Q：TEN VAD 对国外的众多语种也很 work 吗

A：TEN VAD 不区分语种，因为人声/非人声的发音方式相似，训练集包含中文、英文和其他小语种。

Q：8k 的 vad 会更麻烦，高频缺失，会导致轻音更容易出问题

A：确实如此，8k 采样率有效频率只有 4k，轻音频率集中在 4k 以上，无法判断，影响识别。建议使用 16k 采样率。语言开头通常是浊音，SOS 和 EOS 之间如果出现短暂的非人声，可以做平滑处理，将非人声判断变为人声判断。语音结尾的轻音确实会带来影响，可以通过设置连续的非人声判断成 ES 的阈值来缓解，但可能增加延时。现在的处理方案是在 VAD 后自己在前面补帧数再发送给 AS（自动语音识别）。

圆桌讨论：

嘉宾介绍：

技术专家：

尹顺顺@Soul，正在开发端到端全双工语音通话，让 AI 自主决定说话时机

Rambo\@TEN VAD，低延迟，低功耗，高准确率语音活动检测 AI 模型

史业民@Viola 作者，实时互动 AI 创业者，前智源研究院研究员

张晴晴 @ 晴数智慧，MagicHub.com 近期开源了全双工自然对话数据集

jinti\@rustPBX，面向 AI 可编程语言网关，原生支持 SIP 和 WebRTC

Ethan\@HooRii Technology，AI 陪伴硬件开发套件

范潞 @ 京东语音

余果宸 @ 智谱语音

Voice Agent 创业者：

Jackie\@Chikka.ai AI 语音访谈

陈志腾 @ 心语心声，语音分析 Agent

魏佳星 @ 云蝠智能呼叫智能体

田野@Jumpo AI 相机

chak\@2fun.ai，女性健康 AI

伏英娜 Leody\@Magics.ai 迈吉客科技，企业语音智能体平台

黄和金@buddie，Always on 会议耳机

Chengyuan\@Mark，语音互动书签

付则宇 @ 数字人格，实时互动智能编排

Jason G\@Couch Copilot

秀才 @ 互动式播客

周磊@Neovoya，旅行伴侣

特邀主持：

Darcula\@TEN Turn Detection

Darcula： 大家好，我是 TEN Detection 的作者 Darcula，非常高兴今天可以参加这个全双工技术相关的圆桌讨论。

首先，我来简单介绍一下 TEN Detection。TEN Detection 模型旨在解决真实对话中，因人们的停顿、思考等原因造成的对话模型误触发问题。 它在 VAD 判断语音段落结束后，从语义层面二次判断句子是否完整，从而避免对话模型在不完整语句后进行不恰当的回复。

在刚才各位嘉宾的分享中，我们看到听众朋友们提出了一些问题。我也想借此机会抛砖引玉，向各位嘉宾提出几个问题。

史业民@Viola ：全双工视频技术面临的挑战

Darcula： 首先，我想请教一下史业民老师，目前大家主要关注文字或音频方面的全双工技术， 你认为在视频场景下，全双工技术可能会遇到哪些困难？

史业民： 全双工本身就有很多困难，现在还没有成熟架构。视频方向更是困难重重，整个流程涉及预处理、模型和推理。语音方面，每 40 毫秒可用几个 Token 表示，但视频一张图或一段视频需要上千 Token。如何将上千 Token 变成可实时处理的信息，本身就是个难题。我们最终选择连续向量的方式，因为信息密度更高，实测可用四到八个 Token 代表一个视频片段。

另一方面，视频或图像的输入和输出之间存在互斥性，如何解决这种互斥性，以及如何设计网络架构和 Token，都会带来很多复杂问题。模型架构也需要因此调整。比如，视频解码大概率需要完全基于 CNN 的方式，否则质量下降明显。

Darcula: 模型本身延时就比较高。

史业民： 对，Diffusion 模型还涉及如何降低 Time Step。通常需要 50 个 Step，我们将其降低到 2-4 个，需要对 The Distillation 任务做很多优化，才能在不降低质量的前提下，实现实时交互的精确度和清晰度。可以说每一步都是要重新研究的任务。

Darcula： 核心问题是延迟和推理的复杂度。好像现在所有涉及到视频方面的多模态模型，归根结底很多的困难都在于我到底能够用多大的成本，然后多快的速度完成推理。

史业民： 现在可以给大家提信心的是，一张 H100 就可以支持这个模型进行实时交互。所以我觉得这个事情未来一定是可解的。

Darcula： 那你认为，以现在的推理成本、延迟和效果来看，视频方面的全双工应用能够落地在哪些场景呢？

史业民： 其实它的应用场景我觉得非常不清晰。做游戏是一个可能性，但没有完全验证。也有人将其用于虚拟仿真，用于增加机器人，目前看起来有点可能性，但也还没有真的落地，所以我觉得更像是一个探索。

Rambo\@TEN VAD：VAD 与多模态结合的思考

Darcula： 好的，非常感谢史老师。接下来的问题想问问 Rambo，VAD 主要基于音频信号判断语句起止，但真实对话时，人们还会结合表情和肢体动作。你对 VAD 扩展到融合音视频的多模态场景有什么看法？如何将视觉信息融入 VAD 的判断中？

Rambo： 仅凭 VAD 进行判断的确不够全面，它只能作为整体方案的一部分。要应用于真实场景，必须结合语义层面的理解，这也是我们实践的方向。 我认为更理想的方案并非简单地将音频 VAD 与文本 LLM 结合，而是要收集高质量的全双工多通道数据，利用 Audio LLM 学习人类在交互时的停顿、打断、思考和应答模式。

以往我们讨论的多是轮流进行的对话，但实际场景中存在大量非轮次对话。例如，Agent 何时可以与用户产生争论？这涉及到复杂的因素，需要长期的上下文信息，甚至需要为 Agent 预设角色。如果是陪伴型聊天机器人，可能更侧重倾听；如果是面试官，则可能更倾向于主动打断。因此，这条道路还很长，需要考虑更多主观判断因素。

我还想分享一点，很多人关注全双工语音中的智能交互，但我们在实际开发中发现，音频信号处理本身也面临诸多挑战，甚至更加棘手。 比如，我们往往关注理想环境下的交互，但实际使用场景可能是在嘈杂的咖啡馆，背景人声容易造成误触发。这类问题很难解决，仅仅依靠音量大小无法准确识别目标说话人。而且，如果目标说话人距离较远，还会涉及到信噪比等问题。

此外，回声消除也是关键。全双工通信必须使用 AEC 技术，消除 Agent 自身产生的回声，避免循环反馈。做好音频基础工作至关重要，包括回声消除、降噪、动态增益控制、VAD 等等。AI 时代对音频基础算法提出了更高要求，需要与 Agent 应用场景紧密结合，机遇与挑战并存。

尹顺顺@Soul：全双工端到端语音通话的进展

Darcula： 感谢 Rambo。我想请尹顺顺老师介绍一下，Soul 在端到端语音通话方面取得的进展，以及目前全双工音频端到端模型的进展情况。

尹顺顺： 大家好，我们主要做 AI 陪伴，在站内孵化虚拟 IP，通过各种功能与真实用户互动，构建人和 AI 共同的社交网络。其中有很多语音场景，例如一对一语音聊天、私聊语音条，以及多人语音会议。

我们计划在 7 月份上线全双工功能，之前目标是 5 月，但遇到很多问题。上线后，要解决成本问题，例如如何并行化和降低成本。全双工端到端的落地成本仍然很高。预计 8、9 月份会开源一些模型，为开源社区做贡献。

首个全双工版本将在 7 月上线，优先应用于一对一陪伴场景。我们认为，纯语音的全双工在很多场景下并不必要，例如工具类或严肃场景，打断用户可能反而降低体验。但在情感陪伴场景中，如果用户将 AI 视为朋友或恋人，AI 只能一句一句回复会破坏沉浸感。

我们更大的动力在于未来会做更多互动式博客，以及在多人场景中融入 AI 。在多人对话或辩论时，AI 何时发言至关重要，其重要性甚至高于两人对话，因为多人场景对发言时机更敏感。

我们采用端到端的双流结构，以便未来扩展到多人场景，并融入视频模块。虽然多流结构在效果调优上更具挑战，但相比外挂式模型，端到端模型的优势在于延迟更低，最低可达 40-80 毫秒，相当于一到两个 Token 的时间。

Darcula： 之前我看过一些 Demo 视频，AI 与人在一对一场景中自然地进行「吵架」，效果不错。我好奇的是，打断非常主观，尹老师你觉得 在设计全双工模型时，如何评估打断的「正确性」？

尹顺顺： 的确，打断是否恰当非常主观，用户自己也很难评估。我们从以下几个方面入手：

首先，上线后会进行 AB 测试， 通过调整解码策略等，观察用户的接受度。频繁打断用户体验不好，但不打断则失去了全双工的意义，因此需要平衡。

其次， 在训练时，我们会设定 AI 的打断频率， 分为多个档位（例如非常喜欢打断、非常不喜欢打断），作为可控的 Prompt，方便后续 AB 测试。我们会基于训练数据中 AI 的打断行为，反向设计这些 Prompt。

再次， 尝试实现用户个性化。 可以基于用户历史互动行为（例如在社区中的行为）判断其是否喜欢被打断。简单方法是基于用户历史行为打标签，更优雅的方式是将用户之前的聊天内容（特别是语音片段）作为输入，提升个性化效果。

如果不考虑个性化，在训练时加入控制，并在测试时基于用户反馈调整策略，就能解决大部分问题。

告别「一来一往」式对话，Soul App 全双工语音大模型让人机交互更有人情味 https://mp.weixin.qq.com/s/4N55umSnDZKsJ6iic7mbww

张晴晴 @ 晴数智慧：高质量全双工对话数据集的构建

Darcula： 感谢尹老师。高质量数据集的构建对于大模型至关重要，晴数之前发布了一版高质量的全双工对话数据集。接下来想请张晴晴老师介绍数据集的情况，以及如何构建高质量数据集。

张晴晴： 大家好，我是晴数智慧的创始人张晴晴。前面几位嘉宾提到了全双工的关键点，例如语义 VAD、打断、无效意图，以及如何构建沉浸感。这些在数据设计环节都需要仔细考虑。

MagicData 是我们自己做的一个数据开源社区。我们一直在陆续发布对话开源数据，之前发布过方言数据，今年陆续发布了中文、英文和日语的全双工对话数据。选择这些语言，是因为它们是大家比较关注的。

预训练时，数据的质量至关重要，要考虑降低幻觉率等。但从语音数据处理的角度来看，客观地说，目前 90% 以上仍使用全自动或机器流水线的方式处理。但我认为， 语音与大模型（例如数学或代码）有很大不同。语音更像是一门艺术，要给人带来沉浸感，并且这种沉浸感一定是差异化的、个性化的。 如果想用通用解法来解决这个问题就很难。如果所有数据都采用合成数据、AIGC 数据，或全自动流水线处理，就会抹平那些个性化的部分。虽然可以作为基础，但很难深入人心，让人愿意与 Agent 进行对话。因此，我们需要一些小插曲或小意外，而这些很难通过预先设定的规则实现。

所以，我们的数据理念是强调 「Human-in-the-Loop」 ，将人放在首位。我们一定要在数据环节渗透更多人的因素或差异性。我们的开源数据融合了这些特点，采用真人采集，并在数据处理中融入人的介入。例如，做 VAD 时，需要人工调整时间点，确保语义完整。此外，我们还会体现笑声、大喘气等富语言信息。

我们开源这些数据的想法是，有些开发者想尝试双工数据，但又不能立刻去找人采集或标注，希望先做一些 Demo 实验看看效果。我们的不同数据品类，开源量不同，通常在 10 小时到百小时的区间。我们认为，这样的规模足以让大家先进行尝试。之前上海一位语音领域的教授告诉我，他们用我们的方言数据做了一些翻译，合成的语音效果不错。

未来，我们计划探索更多语种的双工数据。目前，我们已积累了中文和英文的上百小时高质量数据。事实上，我们早在 2018 年左右就开始着手这类数据的构建，因为我们坚信，未来的交流将走向更加自发和自然的方式。我们希望做好语种的扩充性，并对数据进行分类，例如任务型和闲聊型。

Darcula： 你们在确保全双工数据集多样性方面，有哪些特别的措施？例如在中文领域，如何涵盖不同场景和打断倾向？

张晴晴： 数据集的多样性至关重要，主要体现在两个方面：多样性本身和个性化。个性化实际上也是一种多样性的体现。在双工对话中，首先要确保主题或场景的多样性，例如涵盖游戏、旅行、教育等，并力求不断扩充和完善。其次，人的因素同样关键。打断的频率能够在一定程度上反映人的性格特点，例如是否急躁。在数据录制过程中，我们会尽可能覆盖不同地域的人群，例如广东、东北、四川等地，因为不同地域的人往往具有独特的语言和表达习惯。此外，年龄也是一个需要考虑的因素，不同年龄段的人在表达方式上也存在差异。当然，以上这些都属于较为粗略的划分。

我认为，数据维度需要持续迭代，一方面要不断扩大数据规模，以保证多样性；另一方面要在扩大规模的同时，不断优化数据细节。例如，需要对细节刻画进行精心设计，并深入思考如何评估打断行为的合理性。这类似于产品设计或艺术创作，我们需要不断地对数据进行设计，并引导模型理解数据背后的逻辑，既要充分考虑人的因素，又要兼顾 AI 的理解能力，循序渐进地进行。

圆桌开放麦:

Darcula： 好的！非常感谢张老师。频道里有很多听友提出了问题，接下来我们直接开放麦克风。

优化大模型电话客服的轮次检测与静默应对策略

魏佳星： 大家好，我叫魏佳星，我们做的项目是让大模型打电话和接电话。上周我们上线了轮次检测功能，发现了一些问题，想请教各位。

首先，在轮次检测中，当系统判定为 wait 或 finish 状态时，下一步应该如何处理？目前，我们采取的方式是为 wait 状态增加 2 秒的等待时间，finish 状态增加 1 秒，但这种简单的延时处理总感觉有些生硬。

其次，在等待轮次检测结果的过程中，如果 AI 长时间保持静默，用户体验会大打折扣。因此，我们需要让 AI 适当地进行一些回应。但仅仅使用像「嗯」这样的语气词，效果并不理想；添加一句「您讲」又显得过于正式和生硬。想请教各位，在这种情况有没有更巧妙、更人性化的建议？

最后，我们观察到，当前的轮次检测机制似乎过度依赖 AI 的判断，导致 wait 状态的触发频率偏高。而在实际应用中，我们更希望降低 wait 状态的出现频率。那么，有没有办法可以适当调整模型的权重？

Darcula： 我来回答一下。首先第一个问题，我们实际应用中会输出 chat、listen 以及 wait/complete/incomplete 三种状态。complete 状态直接交由大模型回复即可。incomplete 状态，我们通常会增加 2-4 秒的倾听时间，延迟后再次判断；如果在延迟时间内用户继续发言，则忽略本次请求；wait 状态则表示用户强制要求模型静音，直接不做任何处理。这是我们目前建议的处理方式。

第二个问题，AI 静音时如何适当回应。有两种方法：一是建立「填充词」词表，随机选择填充，虽然简单快捷，但需注意填充词与上下文的关联性。二是利用 prompt engineering，引导模型生成填充词，并限制 token 数量。但这种处理方式需要注意 TTS 的渐入渐出效果，音量要做特殊处理，建议根据实际场景灵活调整，核心是在保证用户能够听清的前提下，避免打断对方，可以考虑增加拖尾音等音频处理方式。

最后一个问题，你说 wait 的触发频率有点高？调整 wait 权重是可行的。最佳方案是针对你的特定场景进行微调。你可以构建一些数据集，对开源模型进行微调，数据集规模无需太大。另外，你也可以获取大模型输出 token 时的 probability，针对有效的三个 token 设置不同的 threshold，并根据实际情况动态调整这些 threshold 值。

语义 VAD 深度探讨：挑战、应用与技术细节

余果宸： 大家好，我是来自智谱的余果宸，想请教一个关于语义 VAD 的问题。在实际应用中，语义 VAD 是否会考虑到误打断纠错的数据？因为实际场景中可能会出现误打断情况，用户可能会表达「你不要误打断我」之类的诉求。此外，语义 VAD 在判断时，是否会结合历史上下文信息？最后，将语义 VAD 整合到后续的大模型中一起处理，是否会更加理想？现在有很多研究工作都是这么做的。

Darcula： 目前的语义 VAD 设计，在判断一句话是否结束时，主要依据客观标准。如果加入历史信息，就像刚才和 Soul 交流时提到的，就会涉及到主观判断。 主观判断并非不可行，但构建起来会更加复杂。因此，我们目前只考虑当前语句本身，判断其在语法和语义层面上是否构成一个完整的句子。complete 状态的判断标准就是这句话本身是否在语义或语法上是完整的。不知道尹老师对此有何看法？

尹顺顺： 我们去年也做过语义判定的相关工作，但误识别率较高。例如，有些用户语速较慢，可能会说「我今天想吃的……但没吃上」。如果仅凭「我今天想吃的」就进行判定，很可能会误判为结束，并开始回复。如果不考虑个性化因素，语义判定只能满足大多数用户。

此外，这个问题具有一定的主观性。即便用户在正常对话中被打断，通常也不会特别在意。因此， 我们将这个问题视为一个业务问题，即我们的模型应支持不同程度的打断，然后将其转化为一个业务层面来解决。

我相信未来会出现更好的解决方案，但 ** 如果追求极致的准确性，必然需要走向个性化，** 而无法简单地通过一种通用的方法来实现。因为这个问题既具有主观性，又带有一定的客观性，所以未来的发展方向应该是个性化定制。

Darcula： 是的，我们的判断逻辑也类似。如果需要考虑上下文，例如当前语句在语义和句法上都是完整的，但根据上下文推断，可能需要稍作停顿。正如李老师所说，「我今天饭吃完了，但我觉得不好吃」，如果 VAD 已经将前一句发送，那么单独来看这句「我今天饭吃完了」，无论从哪个角度分析，都是一个完整的句子。

如果希望有一个模型能够让大模型延迟回复，这个模型本身就带有很强的主观性，实际上是在模仿特定人的行为习惯。 当你试图模仿人的行为习惯时，这个模型必然不是通用的。这就涉及到针对不同场景，需要区分不同类型用户的情况。因此，目前我们在轮次检测中尚未引入这些因素，我们的目标仍然是构建一个更通用的轮次检测模型。

jinti: 我补充一点。在 VAD 中，我们实际上区分了两种类型：一种是基于声学的传统 VAD，另一种是基于语义的 VAD。我们认为声学 VAD 的作用是判断一个 EOU（End Of Utterance），即话语结束。

在我们的 pipeline 中，实际上包含三种 VAD：声学 VAD、语义 VAD 和 EOU。EOU 用于判断用户是否完整地说完了一句话。而语义 VAD 解决的问题是，当机器人在播放一段语音时，用户可能会有口语化的应答，例如「是的」、「明白」等。从语义层面来看，此时不应打断机器人的播放。机器人无需停止，应该继续播放，因为用户只是在回应。

我不确定我的理解是否与各位有所不同，我们的 EOU 主要用于判断用户是否说完。语义 VAD 则用来判断大模型是否应该继续播放语音，是否应该忽略用户的输入。实践表明，将两者分离，能够显著提升用户体验，用户能够更完整地听完一句较长的句子。

Darcula： 确实如此，这实际上是一个术语定义的问题。由于全双工技术目前尚未形成完善的体系，大家对相关术语的称谓和定义还没有统一的标准。

我们是这样划分的：将人声学相关的部分称为 VAD。而所有需要基于语法、语义或其他信息来判断一句话是否完整，或者判断大模型是否应该开始回复的部分，我们都归类到全双工模块，也就是由 end-time detection 这个模型来处理。

包括你刚才提到的 filler word（语气词），可以将其全部纳入全双工模块，或者放在轮次管理或 detection 模型这个范围内进行讨论。这是我们的划分方式。

当然，在实际技术开发中，肯定也有人会将「语义 VAD」的概念单独拆分出来，然后将语法结构的完整性作为不同的模块来考虑或设计，这也是有可能的。

所以，这实际上是个术语定义的问题。由于这项技术还很新，又缺乏权威的官方或学术指导，因此大家的叫法各不相同，这是很正常的现象。

jinti： 我想补充的是，除了要理解用户的意图之外，还需要反过来思考，如何尽可能避免机器人产生误判。如果机器人正在陈述，但由于某种原因被打断，大模型可能会误以为其已完整输出这段文本，但实际上用户并未完全听取，这会导致整个推理过程出现偏差。我们在早期版本中就遇到过这种情况，后来我们专门将这个问题剥离出来，进行单独处理，尽可能确保用户能够理解完整的上下文。引入这种机制后，整个对话流程变得更加自然。从这个月的数据来看，效果是积极的。

高端的 AI，往往以素人的方式出现：Soul 虚拟伴侣的陪伴感秘诀

靖然： 我想向 Soul 的尹老师请教一个问题。我体验了 Soul 的虚拟伴侣功能，感觉就像在与一个有情感的真人进行对话。我平时也比较喜欢尝试各种 AI 聊天应用，但似乎只有 Soul 做到了这一点，我能从虚拟伴侣的语气、语调、语速中感受到其话语背后的情感或想法。我理解这种效果可能与高质量的数据集密切相关。我想了解一下，在构建数据集时，Soul 是否会特别针对语气、情感等富含语言信息的内容进行标注？数据集通常会包含哪些维度的标签？

尹顺顺： 为了提升语音交互的真实感，我们构建了一套全面的语音维度体系，精细地划分了语言事件（如笑声、哭声）、语种方言、情绪状态以及背景噪音等。在此基础上，我们有意识地增加了预训练和 SFT 阶段带有语气和情感色彩的数据比例。

之所以我们的虚拟伴侣能够给人以真实感，主要归功于以下几点：首先，在产品设计层面，我们采用了更贴近真人的角色设定，并通过加入「正在输入」等细节提示，模拟真实的社交互动体验。避免使用二次元形象，也是为了防止用户将其视为游戏，从而影响陪伴感。

其次，我们发现用户往往更喜欢略带「笨拙感」，更像是陪伴者的 AI，而不是过于聪明的助手。

最后，也是非常关键的一点，就是我们去年 9 月上线的语音功能，它极大地提升了用户的接受度，使得 DAU 实现了两到三倍的增长。语音的加入能够迅速拉近用户与 AI 之间的距离，让用户感受到更加鲜活和真实的互动体验。

靖然： 好的，非常感谢尹老师的解答。所以说，这种拟人化的效果，其语气语调与真人相似的程度，主要还是取决于训练阶段所使用的数据集质量，是吗？

尹顺顺： 确实如此。我们的语音并非完美无瑕，甚至有时会出现错别字，因为真人也会出现类似情况。其次，我们使用的是非常接近普通人的音色，这些音色均由我们的同事录制，时长仅有七八秒。我们有十几位训练师，他们都是我们的男女同事，每个人录制了约十秒钟的音频，而且通常不是在专业的录音棚，而是直接使用手机录制后发送给我们，再由我们进行声音克隆。

用户似乎更喜欢这种略带素人感、并非过于精致的音色，因为它能拉近距离，避免过于「演绎」的感觉。 现在有些语音产品会使用御姐音或青年音等进行演绎，但听久了容易感到腻烦。相比之下，素人的音色可能更适合长时间交流。

傅丰元： 高端的 AI 往往以素人的方式出现。

尹顺顺： 是的，这或许也是社交领域的一个特点。当然，这种策略可能不适用于所有领域，但在社交领域，素人感或接地气的感觉尤为重要。

Lightning Demo

fu：WasmEdge ：一个轻量、高性能、可扩展的开源软件

WasmEdge 是一个轻量、高性能、可扩展的 WebAssembly 运行时，适用于云原生、边缘和去中心化应用。它为无服务器应用、嵌入式函数、微服务、智能合约和物联网设备提供支持。

链接： https://github.com/WasmEdge/WasmEdge/

张锑：通过语音控制提升计算机交互效率的开源应用

该项目是一款旨在通过语音控制来优化计算机使用体验的应用，其核心功能包括一个「语音收藏夹」，允许用户通过语音指令直接打开常用内容；也可作为独立的语音输入法，将语音即时转换为文本并自动复制到剪贴板。现已开源。

链接：https://github.com/zhangti112358/TalktoComputer

魏佳星：云蝠智能呼叫智能体 大模型驱动的智能外呼与接听解决方案

该产品是一款利用大模型进行 AI 外呼与接听的智能体。该产品的核心逻辑是直接调取智能体进行 AI 语音交互，旨在高效地完成电话外呼和接听任务，并在其中引入变量和记忆能力，使 AI 能够理解前后上下文。

https://www.telrobot.top/

叶姿逸：商汤 v6 omni

该模型具备强大的媒体处理能力，能够支持音视频流的输入和纯音频流的输出，同时也能实现纯音频流的输入与纯音频流的输出。支持全双工和半双工两种工作模式，并采用了两段式模型架构。

在实际落地方面，叶姿逸提及了与「灵宇宙小方机」合作的产品。这款产品目前已成功在京东上架并进入量产阶段，主要应用于户外伴学等场景，例如能够对小朋友提出的「这是什么」等问题提供音视频流输入和音频流输出的讲解，展现出强大的实物识别与讲解能力。

用户还可以通过下载已上架 Apple Store 的「商量」App 来直接体验模型的能力。「商量」App 支持文本输入、音视频流电话以及纯音频流电话。

https://platform.sensenova.cn/technology/real-timeInteraction/real-timeInteraction/

周磊：专为独自旅行者和自由行旅客设计的 AI 语音互动产品 Neovoya

Neovoya（旅游伴侣）是一款正在开发的专为独自旅行者和自由行旅客设计的 AI 语音互动产品，旨在超越传统导游功能，解决用户在旅途中的孤独感。

该产品将通过 AI 提供旅行规划、目的地介绍，并创新性地增加由 AI 主动发起活动和邀约的「结伴」功能，同时提供天气、交通及安全等方面的语音提醒，全程通过语音交互提升旅行的便捷与安全。

Jackie Luan ：端到端的 AI 语音顾客访谈智能体 Chikka.ai

Chikka.ai 是一款端到端的 AI 语音顾客访谈智能体，用户只需 2 分钟即可创建专属的个性化语音主持人 Ava。她能与真实用户展开对话，主动提出有深度的问题，帮助企业高效获取真实、富有洞察力的客户反馈。相关链接：https://chikka.ai/

朱逸骁 Eason：Sex Trainer AI 成人用品领域的情感陪伴与训练

产品旨在通过 AI 与硬件结合，提供一对一交流体验。已规划并部分实现的功能包括：对用户使用过程中的数据进行量化分析，并据此进行训练排期和强化指导。未来计划将这些数值进行排名，并结合其 AR 专长，在海外市场引入 AR 眼镜以增强体验。

MIKEMIKE ：基于手机原生通话的视频智能客服

MIKEMIKE 分享了北京创业互联科技有限公司推出的视频智能客服产品，产品主要功能是基于手机原生通话提供单向视频服务（服务端向用户侧传输），并在特殊场景下支持用户侧视频共享，旨在通过视频交互丰富客服内容展示，解决传统语音客服在用户理解和信息传递上的局限。

主题分享、圆桌对谈、demo 分享、分组自由讨论——感谢大家的参与，我们下一次 RTE Meetup 再见！！

级联 vs 端到端、全双工、轮次检测、方言语种、商业模式…语音 AI 开发者都在关心什么？丨 Voice Agent 学习笔记

对话式 AI 硬件开发者都关心什么？低延迟语音、视觉理解、Always-on、端侧智能、低功耗……丨 RTE Meetup 回顾

Gemini 2.0 来了，这些 Voice Agent 开发者早已开始探索……