119 lines
3.7 KiB
Markdown
119 lines
3.7 KiB
Markdown
---
|
||
tags: [AI, 语音交互, STT, TTS, VAD, 流式处理, 多模态]
|
||
create time: 2026-06-12 11:13
|
||
---
|
||
|
||
# 语音交互
|
||
|
||
## 概述
|
||
|
||
语音是人机对话中最自然的交互方式。一个完整的语音交互链路包含：**语音活动检测 (VAD)** → **语音转文字 (STT)** → **LLM 推理** → **文字转语音 (TTS)**。本节拆解每个环节的技术选型与优化策略，重点关注**端到端延迟**的控制。
|
||
|
||
## 正文
|
||
|
||
### 语音交互全链路
|
||
|
||
```mermaid
|
||
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 的作用是从持续的音频流中检测"人什么时候在说话"，避免将环境噪音当作有效输入。
|
||
|
||
```typescript
|
||
// 使用 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 是低延迟的关键——不必等用户说完，边说边识别：
|
||
|
||
```typescript
|
||
// 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 生成第一个句子时就开始朗读，大幅缩短感知延迟。
|
||
|
||
```mermaid
|
||
graph TD
|
||
A["LLM 流式输出"] --> B{"句子边界检测"}
|
||
B -->|"检测到句号/逗号"| C["送入 TTS"]
|
||
C --> D["流式播放音频"]
|
||
B -->|"继续生成"| A
|
||
```
|
||
|
||
方案选择：
|
||
|
||
- **OpenAI TTS**：音质好，延迟中等，按字符计费
|
||
- **Edge TTS**：微软免费方案，音质不错，延迟略高
|
||
- **Fish Speech / CosyVoice**：开源方案，支持声音克隆，可自部署
|
||
|
||
### 延迟优化汇总
|
||
|
||
```mermaid
|
||
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 秒**就能听到第一个词。
|
||
|
||
## 关联笔记
|
||
|
||
- [[视觉理解]]
|
||
- [[成本控制]]
|
||
- [[用户故事]]
|