1. 为什么一个“语音接送”接口,值得单独写一期日记先说个背景。这个手搓情感聊天机器人系列写到现在,已经是第 13 天。前 12 天我把注意力全放在了怎么让机器人“说话更像人”——情感语气、上下文记忆、回复的多样性,这些做得差不多了。但真正把机器人摆到桌面上用的时候,最大的痛点根本不是回复质量,而是交互方式。最初的方案特别笨:用户必须按住一个实体按钮才能说话,松手之后机器人开始识别、生成回复、语音播放。这确实是能跑的方案,但用起来极其反人性。你想一下,两个人面对面聊天,谁说话之前还得先按一下按钮?这种“半双工”交互最多算个语音对讲机,而不是聊天机器人。尤其做情感陪伴类场景,用户往往是躺在沙发上、闭着眼、手里抱着抱枕的状态,让这样的人伸手去按按钮,体验直接崩了。所以 Day 13 的核心任务非常明确:彻底砍掉手动触发,让机器人自己判断你什么时候开始说话、什么时候说完,然后自动接话。这里的关键技术就是标题里提到的 VAD,全称 Voice Activity Detection,语音活动检测。它的职责就一句话:区分“人在说话”和“周围很安静”。听起来简单,但真要做得让用户觉得“自然、不尴尬、不用等”,坑比想象中多得多。这篇日记就把我这一整天折腾 VAD、从手忙脚乱到最终丝滑对话的过程完整记下来,给同样在做语音机器人、或者想做类似语音助手的你一点参考。适合谁看?如果你正在做语音对话机器人、语音助手、语音输入工具,或者哪怕只是在智能音箱上写个简单的唤醒交互,这篇里的思路和参数调优方法应该都能直接用上。完整代码我不会贴所有工程文件,但核心算法流程、关键参数、以及我踩过的几个坑,都会讲透。2. VAD 技术方案的选型:从“自己算音量”到“直接用现成模型”2.1 最朴素的思路:能量阈值为什么不够用接到“自动检测说话”这个需求时,我第一反应是:算音频帧的能量不就行了吗?音乐里有鼓点的时候能量大,安静的时候能量小,设定一个阈值就完了。这个想法确实能跑,但只在一种情况下好用:环境极其安静,人离麦克风很近,而且背景里没有任何其他声音。我的使用场景显然不满足——客厅里可能有空调声、窗外的车流声、甚至是手机电视的背景音。能量高的时候不一定是在说话,可能是打了个喷嚏、挪了下椅子、或者猫叫了一声。能量低的时候也不意味着没人说话,一个人小声嘀咕着心事,这种轻声细语恰恰是情感机器人最该捕捉到的内容。用纯能量阈值做的结果就是:要么一句话被拦腰截断,要么机器人被环境音疯狂误唤醒。所以这条路走了不到半个小时就放弃了。我意识到,VAD 不能只看“响不响”,还得看“像不像人声”。2.2 三套备选方案的实测对比放弃自研之后,我开始在三种现成的 VAD 方案里选型。方案原理优点缺点WebRTC VAD基于 GMM 统计模型,判断每帧是否包含语音轻量、毫秒级、部署简单对低信噪比场景不够灵敏,容易漏掉轻声说话Silero VAD基于神经网络的端到端模型,直接在 PyTorch 中运行准确率高、对噪声鲁棒、支持流式逐帧判断需要一点模型推理开销,但 CPU 上完全可接受云端 ASR 的端点检测语音识别服务自带的静默切分最准,直接拿到文字结果依赖网络,延迟高,不适合本地实时控制表中最后一行“云端 ASR 的端点检测”是个特别容易踩的误区。之前我用过某云的语音识别接口,它自己是有静默检测的,能识别出“用户说完了”然后返回完整文本。如果完全依赖它,交互也是通的,代价是每一次静默判断都要等一个网络往返,而且你没法在本地做精细的状态控制。比如你想在用户停顿 800ms 时就提示“我正在听”,那这个判断必须在本地做完,不能让云端替你做。所以最后我选了Silero VAD 做本地实时检测,云端 ASR 只负责把识别到的语音片段转成文字。本地负责“什么时候开始听、什么时候停”,云端只负责“刚才这段说了什么”。分工明确,延迟和可控性都拿到手。2.3 Silero 模型跑起来的成本提到神经网络,很多人会下意识觉得“得有个 GPU 吧”“是不是很吃内存”。Silero VAD 完全不是这个量级。它是个非常小的模型,大概一两 MB,在普通 CPU 上跑一次前向推理只要几毫秒。我用笔记本的 CPU 实测,每 30ms 音频一帧,推理耗时大约 2~5ms,完全能满足实时检测的需求。情感陪聊机器人本来就在本地跑着大模型对话服务,Silero VAD 这点资源消耗几乎可以忽略不计。接入方式也友好。官方提供了 PyTorch 版本,直接加载一个预训练模型文件调用即可,也支持 ONNX 导出,方便在移动端或嵌入式设备上部署。我这次用的是 PyTorch 版本,因为机器人主服务本来就是个 Python 进程,不用额外引入其他运行时。3. 核心设计:用“状态机”管理对话的完整生命周期3.1 为什么对话必须是一个状态机,而不是简单的“听到就答”如果只是“检测到声音-开始识别-检测到安静-停止识别-调大模型-播放回复”,这个流程写出来不超过 50 行。但它有一个隐藏问题:机器人回复的时候,它自己也在发出声音。这个声音离麦克风可能只有几十厘米远,Silero VAD 一定识别为“人声”。如果不加处理,机器人就会变成一边说话一边听自己说话,最后自己打断自己,陷入鬼打墙。所以对话流程必须设计成带状态的状态机。不同状态下,VAD 检测结果的意义完全不同:空闲态:没有人说话,机器人也不出声。此时 VAD 检测到人声,说明用户开始讲话了,进入“聆听态”。聆听态:机器人闭嘴不说话,专心听用户输入。VAD 从“有声”变“无声”并持续一段时间,判定为说完,进入“思考态”。思考态:大模型正在生成回复,此时不检测用户语音,避免误触发。播放态:机器人通过扬声器播报回复,此时 VAD 的检测结果直接丢弃,防止自听自说。这四个状态形成完整的闭环,任何一个环节出问题,都是状态切换条件设置不合理导致的。我把所有状态切换涉及的参数列出来,后面调参就是调这些值。参数含义影响speech_start_threshold连续多少帧检测到语音,判定为“说话开始”太大会延迟响应,太小会被环境音误触发silence_end_threshold连续多少毫秒检测到静音,判定为“说话结束”太短会截断停顿,太长会让反应变慢min_speech_duration最短语音长度,低于此长度视为无效(如咳嗽)过滤短促噪声max_speech_duration最长语音长度,超时强制截断防止用户长篇大论导致响应无限延迟3.2 双工播放的取舍:播放时到底要不要开麦克风睡前那会儿,我纠结了很久:理想状态下,机器人说“我今天遇到一件特别开心的事”时,用户可能会在中间插一句“真的假的?”。如果机器人认真听完并回应,体验是最好的,但实现难度会高很多——需要在播放的同时做语音打断,而且还要能区分“用户插话”和“机器人自己的回声”。做了个简单的权衡后,我决定 Day 13 先不做完整打断,只做“播报期间的静默抑制”。具体来说:机器人播放回复时,麦克风保持开启,但 VAD 结果不参与状态切换。播放结束后进入一个很短的“恢复聆听”窗口,大约 300ms,让环境回声消散。在恢复聆听窗口之后,VAD 才重新开始正常检测。这样实现的复杂程度低很多,已经解决了“自己打断自己”这个最严重的问题。真正的双工打断打算放到 Day 20 之后再搞,等 VAD 的稳定性测够了,再引入播放流回声消除也不迟。4. 代码实现与调试实录:从能跑通到真正好用4.1 Silero VAD 的基本接入Silero VAD 在 CPU 上的接入方式非常简单。我用的版本是目前最新的 v5 版,加载方式和早期版本略有差异,这里直接贴我现在跑通的写法:import torch import torchaudio model, utils torch.hub.load( repo_or_dirsnakers4/silero-vad, modelsilero_v5, force_reloadFalse, trust_repoTrue ) ( get_speech_timestamps, save_audio, read_audio, VADIterator, collect_chunks ) utils # 读取本地音频文件检测,这里用于离线验证 wav torchaudio.load(test.wav)[1] speech_timestamps get_speech_timestamps(wav, model, sampling_rate16000) print(speech_timestamps)注意采样率。Silero VAD 官方支持 8k、16k、24k 等采样率,我用的是 16k。麦克风采集到的原始数据如果不匹配,需要先做重采样,否则检测结果会很怪——明明在说话,却输出一大段静音。4.2 流式检测的核心逻辑离线检测只是验证模型好不好使,真实场景下不能等音频全部录完再检测,那样就没法实时判断了。必须流式地一帧一帧喂进去,每帧得出一个“是不是人声”的概率。核心逻辑是维护一个 512 帧的滑窗,每次拿到新帧就调用模型推理,再结合上一节的状态机做状态迁移。这里我写了一个 VADIterator 的底层替代方案,不依赖官方的 iterator,而是自己控制状态,这样能更灵活地调整静默计时:import torch import numpy as np import collections class StreamingVAD: def __init__(self, model, threshold0.5, sample_rate16000): self.model model self.threshold threshold self.sample_rate sample_rate # 每个 chunk 是 512 个采样点,对应 32ms self.chunk_frames collections.deque(maxlen512) self.audio_buffer b self.is_speech False self.silence_counter 0 def process_chunk(self, chunk_bytes): # 传入一个 1024 字节的 PCM 16bit 音频块(即 512 个采样点) self.audio_buffer chunk_bytes if len(self.audio_buffer) 1024: return None # 取 512 采样点,转 float 张量 samples np.frombuffer(self.audio_buffer[:1024], dtypenp.int16) self.audio_buffer self.audio_buffer[1024:] tensor torch.from_numpy(samples.astype(np.float32) / 32768.0) tensor tensor.unsqueeze(0) # (1, 512) confidence self.model(tensor, self.sample_rate).item() self.chunk_frames.append(confidence) return confidence def has_speech(self, current_confidence): # 当前帧的概率连续多帧超过阈值,才认为是说话开始 recent list(self.chunk_frames)[-10:] if len(recent) 3: return False return (np.array(recent) self.threshold).mean() 0.8这里有几个细节值得解释。第一,chunk_frames是一个固定长度 512 的滑窗,里面存的是最近 512 帧的置信度。为什么要保留这么多帧?因为我需要统计“最近一段时间的说话占比”,而不是只看当前一帧。咳嗽、爆炸声可能让某一帧置信度飙到 0.9,但如果它只是 15ms 的瞬态噪声,周围帧全是很低的置信度,那就不该判定为说话。用滑窗平均值,天然具备滤波能力。第二,为什么判定“说话结束”要单独用一个silence_counter,而不是直接看当前帧置信度低于阈值就判定结束?因为神经网络输出有抖动,一句话内部的短暂停顿也可能让置信度掉到阈值以下接一帧再回来。如果一掉就判结束,一句话可能被切成两半。正确的做法是:连续静音超过一个时间窗口才算结束。我这边设置为 800ms 的静音窗口。4.3 状态机的具体实现核心状态切换我单独写了一个类,和音频的帧读取逻辑解耦:class ConversationStateMachine: def __init__(self): self.state IDLE # IDLE, LISTENING, THINKING, PLAYING self.silence_ms 0 self.speech_ms 0 self.max_silence_ms 800 # 尾部静默判定值 self.min_speech_ms 300 # 最短说话时长,过滤咳嗽 self.max_speech_ms 15000 # 最长说话时长,避免无限录音 def feed_frame(self, has_speech, frame_duration_ms32): if self.state IDLE: if has_speech: self.speech_ms frame_duration_ms if self.speech_ms self.min_speech_ms: self.state LISTENING self.speech_ms 0 return ON_SPEECH_START else: self.speech_ms 0 elif self.state LISTENING: if has_speech: self.speech_ms frame_duration_ms self.silence_ms 0 if self.speech_ms self.max_speech_ms: self.state THINKING return ON_FORCE_STOP else: self.silence_ms frame_duration_ms if self.silence_ms self.max_silence_ms: self.state THINKING self.silence_ms 0 return ON_SPEECH_END return None这段代码把边界条件吃得很透。注意min_speech_ms的作用。Silero VAD 对打喷嚏、咳嗽、挪椅子的声音经常给出很高的语音概率。如果从第一款检测到语音就立刻进入聆听状态,机器人会被环境音反复触发。但加了 300ms 的最短语音时长之后,短促的噪声还没来得及让状态机切换,就已经恢复了安静,误触发被直接过滤掉。这个参数不是你随便拍的,它取决于你场景里最常见的噪声时长。我用一台便利店的商场环境音测试过,空调低频声不会触发,但转头时衣领摩擦麦克风会触发,后来把最短语音时长从 100ms 提高到 300ms 才稳定下来。4.4 和语音识别、大模型、语音合成的全链路整合VAD 状态机跑通之后,把它接进整个对话链路是另一个大工程。我画一条完整的时序线,方便理清整个流程:麦克风持续采集音频,每 32ms 一个 chunk 喂给 VAD。VAD 在空闲态捕获到足够长的语音,唤醒整个对话进程。系统开始录制音频,同时继续喂 VAD。VAD 判定语音结束(或超时),系统停止录制,把 PCM 数据交给 ASR 转文字。文字送入情感对话大模型,拿到回复文本。回复文本交给 TTS 合成语音,同时状态机进入播放态。播放结束后,短暂静默,状态机回到空闲态。这里面有一个工程实现的细节:录音和 VAD 用的是同一个麦克风流,但当 VAD 判定“说话结束”时,录音缓冲区尾部可能还包含一部分静音数据。如果把这些静音直接丢给 ASR,会白白增加识别时间,甚至让 ASR 在末尾多出一段不存在的“嗯”“啊”。所以我在停止录音后做了一个轻量的后处理:用 Silero VAD 的get_speech_timestamps对整段录音做一次离线检测,裁掉首尾的静音,只保留真正的语音区间再交给 ASR。这个操作花不到 10ms,但 ASR 的识别准确率肉眼可见地提升了一截,尤其用户说话前后爱清嗓子的时候。4.5 音量激活与 VAD 的配合还有一个容易被忽略的点:大部分麦克风在完全静音时,采集到的不是真正的 0,而是有一层底噪。如果系统把“有语音”的标准只交给 VAD 模型,底噪可能会让 VAD 不定时输出一个低置信度的“语音”信号,干扰状态机。所以我在 VAD 前面加了一个保险开关——只有当前音频帧的 RMS(均方根能量)高于一个最小音量阈值时,才把这帧数据真正送入 VAD 模型。def rms(frame_bytes): samples np.frombuffer(frame_bytes, dtypenp.int16) return np.sqrt(np.mean(samples.astype(np.float64) ** 2)) def is_louder_than_noise(rms_value, noise_floor800): return rms_value noise_floor这里的noise_floor不是随便定的。我实测在不同环境下的底噪水平:安静的卧室大约 200~400,带空调的客厅大约 600~900,靠马路开窗大概能到 1500。如果你的noise_floor设置在 200,在安静的卧室里没问题,但开空调后空调声反而会被当成语音,导致 VAD 被疯狂唤醒。所以我建议直接在代码里做成自适应:每次空闲态持续超过 3 秒时,取这段时间音频 RMS 的 95 分位作为新的底噪基线,再加 20% 的余量。这样环境变化时,系统不用重启也能自动调整。5. 实测调优:那些让 VAD 从“能用”到“好用”的关键调整5.1 第一批条件:阈值、静默时间、最短语音时长Silero VAD 自带的置信度阈值默认 0.5。但我在实测中发现,阈值设成 0.5 对于情绪低落的轻声说话,很容易漏检。因为情感陪聊场景下,用户可能真的就是半躺在床上很轻声地抱怨几句,音量远比正常对话要低。把阈值降到 0.3 之后,轻声说话确实能被捕捉到了,但代价是环境中的电视声、雨声、远处的说话声也会频繁触发。试了两轮后,我最终定在 0.4 左右,算是在灵敏度和误触发率之间找到了一个平衡点。这里要特别说一句:阈值不是全局固定就完事。我在代码里针对不同状态用了不同的阈值。比如空闲态需要非常灵敏,有人开口就得立刻捕捉,阈值设 0.35;但在聆听态,确认说话是否结束时,阈值提高到 0.5,减少把正常句内停顿误判成结束的概率。同一个模型,两个阈值,状态机的表现好了很多。5.2 尾部静默时常:对交互节奏的影响“用户说完话多久之后机器人开始处理”这个参数叫max_silence_ms,我调得最久。最开始设 1200ms,体验是:用户说完之后,机器人大概有 1 秒多的“呆滞期”,那种对话中的冷场感特别明显,好像机器人根本没在听。后来缩短到 600ms,响应确实快了,但遇到用户在句子里思考,比如“我昨天…嗯…其实也没什么事”,中间的“嗯”停顿超过 600ms,语音就被截断了,后半句没录进去。最终我设了 800ms,并且加了一个静态判断:如果 VAD 输出的置信度虽然没有超过 0.4 的阈值,但超过了 0.25,认为是“可能语音”状态,此时不重置静默计时,而是延长 100ms 的判定窗口。这样既允许用户在句中有轻微的停顿思考,又不至于让机器人反应太拖沓。代价是代码多了一小段状态判断,但实际体验明显流畅了。5.3 常见问题速查表:直接把问题对应到改什么参数现象原因解决方案机器人被环境音无端唤醒空闲态阈值过低调高空闲态的置信度阈值,或提高底噪过滤的noise_floor用户轻声说话机器人听不到阈值过高或底噪过滤过度调低阈值、降低noise_floor,或自适应底噪基线改为 90 分位一句话被截成两段尾部静默时间太短增大max_silence_ms,或增加“可能语音”延长期机器人回复时自己打断自己未处理回声或播放态仍响应播放态强制丢弃 VAD 结果,播放结束后加 300ms 静默恢复窗口识别内容开头多出“嗯/啊”录音起始时包含了用户的语气词录音裁切时先用 Silero 离线检测裁剪首尾静音用户连说 20 秒没反应超出最大录音时长设置max_speech_ms超时强制截断,并异步处理这些参数没有标准答案,因为每个人的麦克风、环境噪声、说话习惯都不同。提供一个我自用的“调参三板斧”:先调阈值找到合适灵敏度,再调尾部静默找到合适的反应速度,最后调最短语音时长滤掉噪声。这三个参数的优先级是从高到低的,每次只改一个,测一个场景,不要同时调三个,否则永远不知道是哪个改动起的作用。5.4 延迟控制:把“等待感”降到最低连续对话体验的另一个关键是端到端延迟。从用户说完最后一句话到机器人开始播放回复,我拆解了各个阶段的耗时:阶段耗时等待静默判定平均 800ms(取决于用户说话节奏)录音裁切与格式转换约 10msASR 云端识别约 150~300ms大模型生成回复约 300~800msTTS 首包播放约 100~200ms合计大约 1.4~2.1 秒。对于情感陪聊,这个延迟勉强能接受,但用户还是会感觉到“这个人反应有点慢”。后来我做了个小的优化:把“等待静默判定”和“语音识别”并行化。具体是,当检测到用户语音的置信度明显下降、且沉默达到 400ms 时,先把这几百毫秒的音频送到 ASR 做“半截识别”,ASR 会返回正在识别的中间结果。如果后面还有语音补充,再继续喂增量。这样,等到正式判定结束时,ASR 已经返回了大部分文字,大模型甚至已经开始生成了。整体延迟从接近 2 秒降到了 1.2 秒以内,这个优化非常值得做。6. 关于“先本地判定,再云端识别”的架构思考很多做语音交互的朋友会问我:为什么不在云端一次性把 VAD 和 ASR 都做了,省得像现在这样本地跑一个模型,还要自己管状态机?我是这么理解的:VAD 和 ASR 的职责完全不同。ASR 是把语音变成文字,它需要“把整段话听完”才能给出高质量结果,为了保证识别精度,它会留出大量的尾部静默窗口,一般至少 1~2 秒。这个窗口对语音输入法无所谓,因为用户本来就会按着麦克风说完,然后松手等结果。但对于自动连续对话,1~2 秒的等待就是致命的,它会打断聊天的自然节奏。VAD 则是“实时决策”,它只需要判断现在是不是有人声,不需要理解内容,所以可以做得很小、很快,在本地以毫秒级延迟运行,支撑状态切换。本地 VAD 相当于一个智能开关,负责控制麦克风这个工具的开启和关闭;云端 ASR 负责把开着的这段时间录下来的东西转成文字。两者解耦,各管一段,系统架构反而更清晰。另一个考虑是稳定性。网络抖动时,云端 ASR 可能会延迟返回结果,但如果本地 VAD 还在正常工作,至少对话的“有没有人在说话”这个基本判断不会受影响,可以做本地兜底。比如网络断了,VAD 依然可以检测到用户说完了,然后提示“网络开小差了”,而不是傻等云端。7. 写在最后:让机器学会“听完”才是一切的开始Day 13 结束的时候,我把机器人翻过来覆过去测了十几轮。它在卧室的静音环境下表现近乎完美,我只要正常说话,它就能自动接话;我沉默超过两三秒,它就安静地等着,透出一种“我在陪你”的气质。这大概就是 VAD 做对了之后该有的感觉。我个人经验是:VAD 在语音机器人的整个技术栈里,代码量最少,但决定体验的上限。它能掩盖或者放大 ASR、大模型的其他问题。VAD 太激进,系统就像抢话的人;VAD 太保守,机器人又显得迟钝木讷。调好的状态,是在现场的空气里都能感觉到“自然”两个字。这一天的另一个收获是,我发现 VAD 做完之后,机器人的“情感”反而更显性了。因为它能捕捉到用户沉默的时长和节奏——是犹豫、是思考、还是不想说话。这些信息在手动按键时代是完全丢失的。后面如果有空,我计划把这些沉默特征也输入给大模型,让机器人能感知对话节奏的情绪张力。在真正处理好“听完”这件事之前,一切让回复变得更聪明的手段,其实都像在对聋子说话。
