跳到正文
只看论文#实时音视频
  1. webrtcHacks74

    实测：Chrome 新回声消除器把语音代理自问自答率降到 Edge 的五分之一

    Chrome 新的 ML 残差回声估计器把语音代理的单词错误率减半，也减少了代理应答自己问候语的情况。作者用 Hugging Face speech-to-speech 搭建语音代理，在相同房间、麦克风和服务器下交替使用 Edge 与 Chrome 各跑一百多次：回声被 STT 当成用户语音的比例为 Edge 21%、Chrome 4%，失败都发生在会话开始后 1.0 到 2.2 秒之间。dump 显示问候语第一段被抑制 51 到 58 dB，约一秒后的第二段却以高于播放 7 到 13 dB 的电平上行，增益控制器在此期间把自适应数字增益从 15 dB 调高，放大了漏出的回声。作者还指出 min_speech_ms 从 500 ms 降到 384 ms 后，三次失败落在 384 到 500 ms 之间，而 smart-turn-v3 以 0.954 的置信度判定回声已说完，说明问题出在流水线看不到的浏览器组件。

    推荐理由：作者用 AEC dump 对比 Chrome 与 Edge 的语音代理自问自答率，并给出 VAD 阈值取舍的实测依据。

  1. Tavus Blog71

    Tavus 发布 Sparrow-2 对话理解模型，在 TurnBench 轮次切换两项任务上领先

    Tavus 发布音频原生、流式优先的多语言对话理解模型 Sparrow-2，不再依赖降噪和静音计时器，而是保留并分类背景语音、噪声、反馈语和打断等信号，联合建模语义、韵律与说话人身份。在独立基准 TurnBench 的公开 dev split（38 段对话、7.3 小时音频）上，它取得 92.4% 的轮次结束召回和 97.4% 的打断召回，是唯一同时领先两项任务的系统，中位决策延迟 632 ms，7.6% 的轮次结束未被响应。模型以 10 ms 帧率运行，处理 80 ms 音频约需 7 ms，可容忍 6 至 8 秒的思考停顿，现已通过 Tavus API 和平台正式可用。

    推荐理由：Sparrow-2 把轮次切换从端点检测改为整体对话状态建模，并给出与十四套系统的基准对比，可据此判断语音智能体在嘈杂环境中的可用边界。

  1. Daily.co Blog71

    Pipecat 发布语音智能体 STT 基准：对比 10 家服务的延迟与语义准确率

    Pipecat 团队发布面向实时语音智能体的 STT 基准，在 1000 条真实人类语音样本上测试 10 家 STT 服务，同时衡量转写延迟（TTFS）与语义准确率。中位延迟上 Deepgram Nova 3（247ms，1.62% WER）、Soniox（249ms，1.29% WER）、Speechmatics（495ms，1.07% WER）位于帕累托前沿。基准用 Claude 做语义 WER 评估，只统计会导致 LLM 理解不同的错误，并强调 P95 延迟与 finalization 支持比中位数更影响对话体验；代码已在 GitHub 开源，Pipecat 0.0.102 起可设置 ttfs_p99_latency 参数。

    推荐理由：Pipecat 团队用 1000 条真实语音对比 10 家 STT 服务的延迟与语义准确率，并给出可自行复现的基准工具。

  1. Daily.co Blog60

    Daily 发布语音智能体 LLM 基准 aiwf_medium_context，测试长多轮工具调用与延迟

    Daily 发布语音智能体基准 aiwf_medium_context，测试文本模式 LLM 与语音到语音模型在约 30 轮长对话中的工具调用、指令遵循和知识引用，源码已在 GitHub 开源。结果显示已有三个模型在该基准上各项指标达到 100%，但都太慢，无法满足语音智能体所需的 1500ms 以内语音到语音响应（约对应文本模型 700ms TTFT）；生产中最常用的仍是 GPT-4.1 和 Gemini 2.5 Flash，AWS Nova 2 Pro 在性能与延迟上与之持平。语音到语音模型中 Ultravox 0.7 表现突出，GPT Realtime 通过率为 86.7%，低于 GPT-4.1 的 94.9%。

    推荐理由：Daily 公开语音智能体基准的源码与结果，可看到长多轮对话下模型能力与延迟之间的取舍。

已经到底了