语音/音频 AI 应用实战

过去两年,语音 AI 悄悄跨过了"能听个大概"到"可以做成产品"的门槛。实时会议转写、低延迟语音对话助手、AI 配音、跨境实时翻译,这些场景在 2024 年还满是 demo 味,今天已经能在生产环境跑。但语音和文本 LLM 是两种工程难度:延迟不是几百毫秒,而是几百毫秒内的体感分水岭;一字之差不是"重生成",而是用户已经听完了尴尬的半句。

本文把语音 AI 应用拆成能力栈、产品场景、工程要点、架构选择和现实坑五块,讲清从 demo 到上线的真正难点。

一、语音 AI 的能力栈

语音应用主要由三类原子能力组合而成:

• ASR(Automatic Speech Recognition,语音转文字):把音频流转成文本。代表是 OpenAI Whisper、Deepgram、AssemblyAI、阿里/腾讯云的实时识别。
• TTS(Text-to-Speech,文字转语音):把文本合成自然人声。代表是 ElevenLabs、Azure Neural TTS、OpenAI TTS、MiniMax/字节的音乐级 TTS。
• 端到端语音助手:音频直接进、音频直接出,模型原生理解语音(含情感、语气),不经过显式文本中转。GPT-4o 的 realtime voice、Gemini Live 是这一路线。

中间还有两个常被忽略但决定体验的能力:VAD(Voice Activity Detection,语音活动检测)——判断用户什么时候开始说话、什么时候说完;以及 唤醒词 / 打断检测——决定助手什么时候该闭嘴。

绝大多数应用都是这三块的编排。理解了每块的延迟、成本和失败模式,就理解了整个产品。

二、典型产品场景

不同场景对延迟、准确率、自然度的要求差异巨大,选型前必须先归类:

一个常见误区是把"语音对话助手"的指标套到"配音生成"上。配音可以重生成十遍挑最好的;对话助手每多 300ms 延迟,用户感知就掉一档。

三、流式 ASR:边说边出文字

非流式 ASR(整段录音上传再返回)适合离线场景,但会议转写、字幕、语音对话必须流式——用户话音未落,文字已经开始滚动。

流式 ASR 通常走 WebSocket 或双向流式 HTTP,客户端持续推送音频分片(PCM 16kHz/16bit 是事实标准),服务端边收边返回增量结果(interim)和最终结果(final):

// 客户端:采集麦克风并推流到 Deepgram
const ws = new WebSocket(
  "wss://api.deepgram.com/v1/listen?encoding=linear16&sample_rate=16000&interim_results=true&endpointing=300",
  { headers: { Authorization: `Token ${DG_KEY}` } }
);

const mic = await navigator.mediaDevices.getUserMedia({ audio: true });
const track = mic.getAudioTracks()[0];
// WebRTC 的 captureStream + AudioWorklet 把 PCM 切成 ~100ms 帧
const node = audioCtx.createAudioWorkletFromModule("pcm-processor");
node.port.onmessage = (e) => ws.send(e.data); // ArrayBuffer

ws.onmessage = (ev) => {
  const { type, channel, is_final } = JSON.parse(ev.data);
  const text = channel.alternatives[0].transcript;
  if (is_final) commitToTranscript(text);   // 落库 / 推到 LLM
  else renderInterim(text);                 // 实时打字效果
};

几个工程要点:

• 分片大小:每帧 100ms 左右平衡延迟和吞吐。太大体感卡顿,太小会被协议头吃掉带宽。
• 静音端点(endpointing):服务端通常用 300-500ms 静音判定一句话结束,调太短会被咳嗽/换气截断,调太长对话场景用户等不起。
• final ≠ 绝对正确:流式 final 仍可能被后续上下文修正(尤其是标点、专有名词),要为转录文本设计可更新的事件模型,而不是 append-only。
• 音频格式协商:Opus 适合移动端省带宽,PCM 适合服务端零损耗解码。别让前端编码和服务端解码对不上。

四、低延迟 TTS:首音延迟是体感关键

TTS 的指标不是"合成这段话要多久",而是 TTFB(Time To First Byte,首音延迟)——用户按下播放到听见第一个音节的时间。一段 5 秒的语音,3 秒 TTFB + 流式吐音,体验远好于 1.5 秒整段返回。

现代 TTS 几乎都支持流式:文本切片喂入,边合成边推送 PCM/MP3 帧,客户端边下边播。关键是 首句优先——先合成第一个短句甚至半句立刻播放,后续句子在播放过程中并行合成。

// OpenAI TTS 流式调用,首音延迟可控
const res = await fetch("https://api.openai.com/v1/audio/speech", {
  method: "POST",
  headers: { Authorization: `Bearer ${KEY}`, "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "gpt-4o-mini-tts",
    voice: "alloy",
    input: longText,
    response_format: "mp3",
    stream: true,
  }),
});

const player = new AudioContext();
const src = player.createMediaElementSource(new Audio());
// reader 边读 chunk 边喂给 MSE / AudioBufferSource,实现边下边播
for await (const chunk of res.body) appendToBuffer(chunk);

实战建议:

• 按句子切片送 TTS,而不是整段 LLM 输出等完。LLM 流式输出 + TTS 流式合成可以管线化,首音延迟约等于"LLM 出第一句的时间 + TTS TTFB"。
• 预生成常用语。"好的"、"我来查一下"、"请稍等"这类 filler 提前合成,用户说话后立刻播放,掩盖后端真实延迟——这是商业语音助手体感快的公开秘密。
• 音色一致性:同一会话锁定同一 voice id 和版本,TTS 厂商升级模型会变音色。
• 长文本韵律崩坏:超过 200 字一段容易读得平,需要按段落切分再拼接,注意拼接处的停顿和语调。

五、VAD 与打断处理

对话场景里,真正难的往往不是 ASR/TTS 本身,而是什么时候开始听、什么时候停止说。

VAD(语音活动检测)是入口:用户开口立刻开始推流到 ASR,而不是录音完再上传。轻量 VAD(Silero VAD、WebRTC VAD)能在端上 30ms 一帧判断"有人声/无人声",延迟低、隐私好。VAD 的关键参数是起点触发(避免吞第一个字)和终点静音阈值(避免把换气当结束)。

更难的是 barge-in(打断):AI 正在说话,用户突然开口打断。处理流程是:

TTS 播放中 ──VAD 检测到人声──> 立即停止 TTS 播放 + 取消剩余合成
                              └─> 把当前 ASR 文本送进 LLM,开始新一轮回复

坑点:

• 回声消除(AEC):外放场景下 AI 自己的声音会被麦克风拾取,误判成用户打断。必须用 AEC(WebRTC 内置 / 系统级)或强约束"必须戴耳机"。
• 半秒延迟窗口:VAD 触发后留 150-300ms 确认窗口,避免被环境噪声/咳嗽误触发。
• 取消要彻底:取消 LLM 流式请求、取消 TTS 剩余 chunk、清空播放队列,否则会"打断后又冒出半句"。
• 打断语义:用户打断可能不是"停下",而是"补充信息"。把打断时的不完整 ASR 文本和未播完的 AI 文本一起作为上下文,交给 LLM 决定是中断重答还是继续。

六、多模态语音助手架构:串联 vs 端到端

语音对话助手有两条路线:

A. 串联流水线(ASR → LLM → TTS):每一段独立选型、独立优化、独立替换。工程清晰、可观测、可灰度。代价是延迟叠加——ASR 的 endpointing 等 300ms,LLM 首 token 500ms,TTS TTFB 300ms,加起来轻松破 1.2 秒,体感"卡"。

[麦克风] → VAD → ASR(流式) → LLM(流式) → TTS(流式) → [扬声器]
                  │                          │
                  └──── barge-in 取消线 ─────┘

B. 端到端语音模型(GPT-4o realtime、Gemini Live 等):模型原生吃音频 token、吐音频 token,不经过显式文本。优势是延迟低(可到 300-500ms)、能保留语气/情感/打断的细微差别,甚至能听出"用户在笑"。劣势是:贵、可控性差(不能在文本层做安全过滤)、调试难(没有中间文本可 log)、对噪声/多说话人仍然敏感。

实战建议:先做串联,跑通后再上端到端。串联的中间文本是金矿——可以插入安全过滤、函数调用、RAG、审计日志,这些在端到端模型里都很难做。端到端适合"陪伴/情感对话"这种文本中间态无意义、对延迟极度敏感的场景。

一个混合架构也常见:端到端模型负责对话流,关键决策点(下单、查数据库)用 ASR→LLM→工具→TTS 的显式流水线,兼顾低延迟和可控。

七、现实坑

• 延迟累积:三段串联的最坏情况是 ASR 等 endpointing + LLM 长 prompt + TTS 合成,轻松到 3 秒。永远用 P95/P99 而不是平均延迟评估,管线化 + filler 预合成是救命的。
• 口音与噪声:WER 在干净朗读语料上能到 5%,放到带音乐底噪的会议、带方音的客服录音,直接飙到 20%+。选 ASR 一定要在你的真实声学环境上测,别信厂商 demo。
• 情感与语气:TTS 的"喜怒"远没有文本 LLM 成熟。同一句"好的"在生气和开心下应该不同,多数 TTS 做不到自然。需要情感的地方,用 SSML 标记或专门的 emotional TTS,或者干脆让 LLM 在文本里写明语气词。
• 多说话人(speaker diarization):"谁说了什么"在会议场景必需,但流式 diarization 仍不可靠,通常要离线二次处理。实时只做"分段",事后才做"归属"。
• 隐私与合规:录音上传到云端触发 GDPR/个保法/行业合规(医疗、金融)。要么端侧跑 Whisper-small,要么明确告知、本地加密、短保留期。企业场景的语音数据往往比文本更敏感——它可能包含生物特征信息。
• 幻觉 ASR:Whisper 在静音段会"编"出文本("Thanks for watching!" 是著名幻觉)。流式场景必须用 VAD 把静音段切掉再送 ASR,而不是无脑推流。

八、工具选型参考

• ASR:实时/英文用 Deepgram(延迟极低)、AssemblyAI(diarization 好);中文用阿里/腾讯云实时识别;离线/隐私敏感用自托管 Whisper(faster-whisper 是事实标准,比原版快 4 倍)。
• TTS:质量上限 ElevenLabs(情感、克隆强);企业稳定 Azure Neural TTS / 谷歌;中文音色 MiniMax、字节的火山引擎、阿里 CosyVoice;本地/openai-compatible 走 Kokoro / Mellotron。
• 实时语音 API:OpenAI Realtime API(GPT-4o)、Deepgram Voice Agent、LiveKit Agents(开源编排框架,可串联各家)、Vapi / Retell(对话型电话 agent 平台)。
• VAD:Silero VAD(端上、准、轻)、WebRTC VAD(极快但粗)、Deepgram endpointing(服务端)。
• 编排:自己用 WebSocket 拼 vs 用 LiveKit Agents / Pipecat 这类语音 Agent 框架。后者已经处理好打断、VAD、pipeline 编排,能省一两个月。

选型时别只看模型榜单,看三件事:P95 延迟曲线、你的真实音频上的 WER/自然度、定价里有没有隐藏的"音频时长 vs 字符数"陷阱。

小结

• 语音 AI = ASR + TTS + VAD + 编排,产品体验由延迟和打断处理决定,而不是单一模型的指标。
• 流式是底线:ASR 要边说边出字,TTS 要边生成边播,LLM 要流式输出与 TTS 管线化,首音延迟比总延迟更影响体感。
• 对话助手先做 ASR→LLM→TTS 串联,拿到中间文本做安全/工具/审计,再在需要极致延迟的场景上端到端语音模型。
• 实战三坑:回声导致误打断(必须 AEC)、静音段被 Whisper 幻觉(必须先 VAD)、三段串联延迟叠加(必须 filler 预合成 + 管线化)。
• 选型别看榜单看真实音频:WER 在干净语料和带噪录音上能差 4 倍。

一句话:文本 LLM 的工程难点是"对不对",语音 AI 的工程难点是"快不快"——而快,永远是体感层面的快,不是 benchmark 层面的快。