VAD Library Research

[TheShigure7]

VAD 库调研与 AnyClaw 适配建议

1. 目标

本文档聚焦 Voice Activity Detection，回答 4 个问题：

1. anyclaw1.2 当前的 VAD 是怎么实现的。
2. 业界成熟方案有哪些。
3. 这些方案的典型使用方法是什么。
4. 哪种方案最适合 AnyClaw 当前阶段替换或演进。

---

2. AnyClaw1.2 当前现状

anyclaw1.2 当前 VAD 位于：

• anyclaw1.2/anyclaw/pkg/speech/vad.go

现有实现特征：

• 输入是本地音频帧。
• 通过 RMS 能量 和 Zero Crossing Rate 做语音/静音判定。
• 通过 SpeechMinFrames、SilenceFrames、HangoverFrames 做状态机平滑。
• 典型配置项包括：
  • EnergyThreshold
  • ZeroCrossThreshold
  • SpeechMinFrames
  • SilenceFrames
  • HangoverFrames

这说明它本质上是一个：

• 本地
• 启发式
• 轻量
• 纯自研

的 VAD 实现。

这类实现的优点是：

• 无外部依赖
• 易调试
• 集成简单

局限也很明显：

• 在噪声环境下鲁棒性有限
• 对阈值敏感
• 对远场、弱语音、口音、设备差异适应性弱
• 更像工程基线，而不是成熟语音系统常用方案

---

3. 方案一：WebRTC VAD

3.1 定位

WebRTC VAD 是最经典的轻量级 VAD 方案之一，适合：

• 实时麦克风输入
• 本地音频切段
• 低延迟语音前处理
• 资源受限环境

对 AnyClaw 来说，它最像“当前自研 VAD 的成熟替代基线”。

3.2 核心特点

• 成熟、广泛使用
• CPU 开销低
• 延迟低
• 输出简单，只有 speech / non-speech

常见约束：

• 只接受 16-bit mono PCM
• 支持采样率：
  • 8000
  • 16000
  • 32000
  • 48000
• 支持帧长：
  • 10 ms
  • 20 ms
  • 30 ms

3.3 典型使用方法

Python 社区常用封装是 py-webrtcvad：

安装：

pip install webrtcvad

最小示例：

import webrtcvad

vad = webrtcvad.Vad(2)  # 0-3, 越大越激进
sample_rate = 16000
frame = pcm16_frame_bytes

is_speech = vad.is_speech(frame, sample_rate)
print(is_speech)

其中：

• 0 最宽松
• 3 最激进

通常接入流程是：

1. 麦克风流转为 16-bit mono PCM
2. 切成 10/20/30ms 帧
3. 每帧调用 is_speech
4. 再由上层状态机决定 utterance 起止

3.4 对 AnyClaw 的意义

如果 AnyClaw 只想把现有 vad.go 升级到一个更成熟但仍然轻量的版本，WebRTC VAD 是最直接的选择。

适配建议：

• 保留 AnyClaw 现有的 session / pipeline / turn 状态机
• 只替换底层“每帧是否为语音”的判定器
• 在 Go 侧通过第三方 binding 或 cgo 封装接入

3.5 优缺点

优点：

• 成熟
• 快
• 低延迟
• 易作为本地实时基线

缺点：

• 只是帧级二分类
• 在强噪声、远场、复杂场景下不如模型型 VAD
• Go 生态通常需要第三方绑定，不如纯 Go 自研那样零依赖

3.6 参考资料

• py-webrtcvad GitHub: https://github.com/wiseman/py-webrtcvad

---

4. 方案二：Silero VAD

4.1 定位

Silero VAD 是一个模型型 VAD，适合：

• 更高准确率需求
• 复杂噪声环境
• 远场语音
• 语音 Agent、语音机器人、边缘设备

相比 WebRTC VAD，它更像“高质量路线”。

4.2 核心特点

官方仓库强调的特点包括：

• 模型体积小
• 单线程 CPU 可用
• 支持 8k / 16k
• 可运行在 PyTorch 或 ONNX Runtime
• 社区有多语言示例，包括 Go

4.3 典型使用方法

Python 示例：

from silero_vad import load_silero_vad, read_audio, get_speech_timestamps

model = load_silero_vad()
wav = read_audio("test.wav")

speech_timestamps = get_speech_timestamps(
    wav,
    model,
    return_seconds=True,
)

print(speech_timestamps)

这类模型型 VAD 的常见集成方式有 3 种：

1. Python 服务化封装
2. ONNX Runtime 本地调用
3. 单独进程/sidecar 服务，由主进程 RPC 调用

4.4 对 AnyClaw 的意义

如果 AnyClaw 未来目标是：

• 实时语音交互
• 更稳定的 turn detection
• 更低误切段率

那 Silero VAD 比当前自研阈值方案更值得长期演进。

但它的代价也更高：

• 需要模型 runtime
• 部署链路更复杂
• 在 Go 里通常需要 ONNX Runtime 或外部服务

4.5 优缺点

优点：

• 准确率通常优于启发式 VAD
• 对复杂环境更稳
• 模型小，适合边缘部署

缺点：

• 比 WebRTC VAD 更重
• 工程接入复杂度更高
• 运维和打包成本高于当前自研方案

4.6 参考资料

• Silero VAD GitHub: https://github.com/snakers4/silero-vad

---

5. 方案三：云端 VAD / Turn Detection

5.1 OpenAI Realtime API

OpenAI 在 Realtime 体系中支持转写会话和实时语音流处理，可以通过 WebSockets 或 WebRTC 建立实时转写会话。

这类方案的特点不是“本地导入一个 VAD 库”，而是：

• 使用云端实时转写
• 让服务端完成 turn detection / transcription session 管理

适合场景：

• 已经明确使用 OpenAI Realtime
• 更看重端到端语音体验
• 可以接受云依赖和网络时延

参考资料：

• OpenAI Realtime transcription: https://developers.openai.com/api/docs/guides/realtime-transcription

5.2 Google Cloud Speech-to-Text

Google Cloud Speech-to-Text 在 StreamingRecognize 中支持：

• SPEECH_ACTIVITY_BEGIN
• SPEECH_ACTIVITY_END
• voice activity timeout

这同样更像“服务端语音活动事件”，而不是本地 Go VAD 库。

适合场景：

• 你本来就用 Google Cloud STT
• 希望直接复用云端的语音活动事件
• 不想自己做本地 VAD 切段

参考资料：

• Voice activity events: https://cloud.google.com/speech-to-text/docs/voice-activity-events

---

6. 对比总结

方案	类型	延迟	准确率	接入复杂度	本地/云端	适合 AnyClaw 的阶段
当前自研 VAD	启发式	低	中下	低	本地	已有基线
WebRTC VAD	经典库	低	中	中	本地	短期替换首选
Silero VAD	模型型	低到中	高	中到高	本地	中期升级首选
OpenAI Realtime	服务端实时	中	高	中	云端	语音 Agent 路线
Google VAD Events	服务端事件	中	高	中	云端	Google STT 配套路线

---

7. 对 AnyClaw 的建议

7.1 短期建议

短期最务实的做法：

• 保留 AnyClaw 当前的语音管线结构
• 优先评估 WebRTC VAD
• 把当前 vad.go 降级为 fallback 实现

原因：

• 替换成本最小
• 能显著减少“纯阈值法”的维护压力
• 不会把部署复杂度一下子拉高

7.2 中期建议

如果语音交互会成为主线能力：

• 引入 Silero VAD
• 通过 ONNX Runtime 或 sidecar 服务方式接入

原因：

• 更适合复杂环境
• 更适合真实用户场景
• 更适合作为长远语音前处理基础

7.3 云端路线建议

如果未来语音链路本来就走：

• OpenAI Realtime
• Google StreamingRecognize

那么可以弱化本地 VAD，更多依赖云端 turn detection / speech activity events。

这种路线的代价是：

• 更依赖网络
• 更依赖供应商
• 本地离线能力下降

---

8. 最终结论

对 anyclaw1.2 来说：

• 当前 VAD 确实是自研启发式方案。
• 如果要找成熟替代基线，首选是 WebRTC VAD。
• 如果要找更高质量的长期方案，首选是 Silero VAD。
• 如果未来语音交互完全云端化，可以考虑直接依赖 OpenAI 或 Google 的服务端语音活动检测能力。

一句话总结：

当前 AnyClaw 的 VAD 更像“能工作但偏工程试验”的版本；如果要进入稳定产品阶段，优先级最高的替代方向是 WebRTC VAD，其次是 Silero VAD。