语音交互

概述

语音是人机对话中最自然的交互方式。一个完整的语音交互链路包含：语音活动检测 (VAD) → 语音转文字 (STT) → LLM 推理 → 文字转语音 (TTS)。本节拆解每个环节的技术选型与优化策略，重点关注端到端延迟的控制。

正文

语音交互全链路

graph LR
    A["麦克风"] --> B["VAD"]
    B --> C["STT"]
    C --> D["LLM"]
    D --> E["TTS"]
    E --> F["扬声器"]

用户感知到的延迟 = VAD 响应 + STT 耗时 + LLM 首 token + TTS 首包。任何一个环节拖后腿，对话体验都会"卡顿"。

[!question] 思考人类对话中，停顿超过 300ms 就会感到"对方在想"。你认为端到端延迟控制在多少毫秒以内，才能让 AI 对话"像真人"？

环节一：语音活动检测 (VAD)

VAD 的作用是从持续的音频流中检测"人什么时候在说话"，避免将环境噪音当作有效输入。

// 使用 WebRTC VAD（浏览器端轻量方案）
import { MicVAD } from "@ricky0123/vad-web";

const vad = await MicVAD.new({
  onSpeechStart: () => console.log("用户开始说话"),
  onSpeechEnd: (audio) => {
    // audio: Float32Array，送入 STT
    sendToSTT(audio);
  },
  positiveSpeechThreshold: 0.5, // 检测灵敏度
  minSpeechDuration: 250        // 最短语音时长 ms
});

vad.start();

[!tip] 为什么要在浏览器端做 VAD？如果把所有音频都发给服务端，带宽成本会很高。浏览器端 VAD 只在检测到语音时才上传数据，能减少 70%+ 的无效传输。

环节二：语音转文字 (STT)

主流方案对比：

方案	延迟	成本	特点
Whisper API	1-3s	按分钟计费	准确率高，支持多语言
Deepgram	<500ms	按分钟计费	流式识别，延迟极低
浏览器原生	~1s	免费	依赖浏览器，中文效果一般
FunASR	<500ms	自部署免费	阿里开源，中文优化

流式 STT 是低延迟的关键——不必等用户说完，边说边识别：

// Deepgram 流式识别示例
const ws = new WebSocket("wss://api.deepgram.com/v1/listen", {
  headers: { Authorization: `Token ${API_KEY}` }
});

ws.onmessage = (event) => {
  const { transcript, is_final } = JSON.parse(event.data).channel.alternatives[0];
  if (is_final) {
    // 一句完整语音，送入 LLM
    onFinalTranscript(transcript);
  }
};

环节三：TTS 语音合成

TTS 是用户听到"AI 声音"的最后一环。流式 TTS 可以在 LLM 生成第一个句子时就开始朗读，大幅缩短感知延迟。

graph TD
    A["LLM 流式输出"] --> B{"句子边界检测"}
    B -->|"检测到句号/逗号"| C["送入 TTS"]
    C --> D["流式播放音频"]
    B -->|"继续生成"| A

方案选择：

OpenAI TTS：音质好，延迟中等，按字符计费
Edge TTS：微软免费方案，音质不错，延迟略高
Fish Speech / CosyVoice：开源方案，支持声音克隆，可自部署

延迟优化汇总

graph TD
    A["端到端延迟优化"] --> B["VAD 浏览器端处理"]
    A --> C["流式 STT 边说边识别"]
    A --> D["LLM 流式输出"]
    A --> E["TTS 句子级流式合成"]
    A --> F["并行处理: STT 与上下文准备"]

[!info] 关键数字一个优化良好的语音对话链路，端到端延迟可以控制在 1.5~2 秒以内——从用户说完话到听到 AI 回应。如果做到流式 TTS，用户在 LLM 开始生成后 0.5 秒就能听到第一个词。

3.8 KiB Raw Blame History Unescape Escape