简介面向语音信号处理与机器学习初学者的 MATLAB 说话人识别工程包可用于课程设计、期末大作业与毕业设计也可作为理解声纹识别流程的入门案例。项目基于端点检测、MFCC 特征提取与 GMM 模型训练展开代码采用参数化编程并以模块化函数组织参数可方便修改注释详细并附赠可直接运行的案例数据适合在 MATLAB 2014a/2019b/2024b 中快速复现。压缩包共 56 个文件约 4.5MB其中 25 个 .m 脚本覆盖分帧、加窗、端点检测、特征比对等核心步骤19 个 .wav 语音样本用于训练与测试10 个 .mat 数据文件保存模型参数与中间结果另有 GUI 界面 .fig 文件便于观察交互效果。训练脚本、演示程序与 GUI 界面齐备能够展示从训练到识别的完整链路。已有 41 人浏览学习对正在完成语音相关设计或希望快速搭建说话人识别实验的读者有直接参考价值。1. 说话人识别是个黑匣子但 zip 里装的应该是一条完整流水线拿到「说话人-识别.zip」这个包你首先要搞清楚一件事说话人识别Speaker Recognition和语音识别Speech Recognition是两码事。语音识别回答的是“他说了什么”说话人识别回答的是“谁在说话”。这个 zip 如果是一个正经工程包里面装的应该是从音频预处理、特征提取、模型推理到注册/验证闭环的整套代码而不是一个孤零零的模型文件。打开压缩包第一眼先别急着找预训练权重先看目录结构里有没有train.py、inference.py、config.yaml这类文件这决定了你拿到的是能跑通的流水线还是一个需要自己补全周边代码的半成品。这套东西能解决的实际问题很具体门禁声纹验证、会议记录里区分说话人、智能音箱的多用户识别、甚至取证场景下的语音比对。适合的读者是已经被“准确率 95%”这种话打动、但还没被“训练 200 轮后过拟合”毒打过的人。我见过太多人拿到语音相关的 zip 包解压后直接python main.py然后被一堆缺依赖、路径错误、维度不匹配的报错劝退。这篇文章就是把你从“解压了”带到“跑通了、能改了、敢部署了”这一步。2. 拆解「说话人-识别.zip」先看目录结构再定落地策略2.1 一套标准说话人识别工程的文件清单与角色划分一个能落地的说话人识别 zip通常不是单文件而是一个多目录工程。我经手过的方案里最常见的目录结构长这样speaker-recognition/ ├── config/ │ └── config.yaml ├── data/ │ ├── enroll/ # 注册音频每个说话人一个子目录 │ └── test/ # 测试音频待验证的语音 ├── models/ │ ├── encoder.py # 声纹嵌入网络 │ └── classifier.py # 训练时的分类头 ├── train.py ├── infer.py ├── utils/ │ ├── audio.py # 加载、重采样、静音裁剪 │ └── metrics.py # 等错误率 EER / 最小决策代价 minDCF └── requirements.txt这里有一个容易被忽略但决定成败的角色划分data/enroll和data/test目录。注册Enrollment和验证Verification是说话人识别的两条腿。注册阶段是给每个说话人录入若干条语音提取出他的声纹嵌入向量embedding存成“声纹模板”验证阶段是拿一条新的语音提取嵌入向量和模板做相似度计算。如果你解压后发现没有 enrollment 和 test 的目录划分那你得自己在后续流程里搭出这套逻辑。这个工程分层的设计不是拍脑袋。把特征提取、模型推理、相似度计算解耦最大的好处是你在生产环境替换任何一块都不会牵一发动全身。比如你把 PyTorch 模型换成 ONNX 导出版本只需要改infer.py里加载模型的那一段不需要碰注册逻辑。我建议你拿到 zip 后先按这个角色划分给每个目录贴上标签哪些是训练期用的哪些是推理期用的哪些是训练和推理都要用的公共模块。这个动作能帮你省掉后面大量的排查时间。2.2 声纹嵌入向量的核心地位从分类问题到度量学习说话人识别的模型训练表面上是一个分类任务给 N 个说话人的语音让模型学会预测这语音属于 N 个人中的哪一个。但真正部署时模型末端的 softmax 分类器会被扔掉只保留中间的嵌入层。原因在于分类器只能识别训练时见过的 N 个人而真实需求是“新来的第 N1 个人也能注册”这叫开集识别open-set recognition。所以你会看到工程里训练时用nn.CrossEntropyLoss但推理时走的是嵌入向量 余弦相似度cosine similarity。嵌入向量是模型把一段语音压成的固定维度向量常见的有 128 维或 192 维。这个向量的质量直接决定了识别效果同一个人的不同录音向量应该聚在一起不同人的录音向量应该离得远。这就是度量学习metric learning的思想它不关心“你是谁”只关心“你和谁更像”。这里有一个参数你必须重视嵌入向量的维度。维度太低区分度不够不同人的向量容易挤在一起维度太高计算余弦相似度的开销变大而且容易过拟合到训练集的噪声上。我一般会在 128 和 256 之间做消融实验观察 EER等错误率越低越好的变化。如果你的 zip 里encoder.py输出的嵌入维度是 512先别急着改跑一遍推理看效果再考虑降维。2.3 解压后第一个动作核对环境依赖而不是直接训练很多人在这一步翻车。requirements.txt里写着torch、torchaudio、librosa但没写版本号或者写的是你机器上装不了的版本。这里有一条血泪经验先创建独立的虚拟环境再安装依赖不要直接pip install -r requirements.txt装到全局环境里不然你的项目之间会互相打架。# 基于 conda 创建独立环境Python 版本以项目说明为准 conda create -n speaker python3.9 -y conda activate speaker # 先装 PyTorch带 CUDA 版本按你的显卡驱动选 pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu118 # 再装项目的其余依赖 pip install -r requirements.txt第一段命令先建环境并激活第三段安装指定 CUDA 版本的 PyTorch目的是让模型能用上 GPU 加速。第二段命令安装项目依赖注意requirements.txt里不能包含torch相关的行否则会把刚才装好的版本覆盖成默认的 CPU 版。逻辑说明训练和推理都要走 PyTorch 的torchaudio做音频的加载和特征提取这个库的版本和 PyTorch 是绑定的装错一个另一个必然报错。参数说明cu118对应 CUDA 11.8如果你机器上的显卡驱动只支持 CUDA 12.x把这个 index URL 改成cu121。如果你压根没有 NVIDIA GPU把--index-url参数去掉装 CPU 版但训练 200 轮的心态会崩掉。3. 把 zip 变成能用的模型搭建训练流水线的关键步骤3.1 数据预处理采样率、静音裁剪和特征提取解压后的数据如果已经是整理好的wav文件那恭喜你省掉了最脏的活。但更多时候你会碰到采样率不统一、前后有静音、甚至格式混着mp3和wav的音频。我的做法是写一个统一的预处理脚本把所有的音频标准化。import librosa import soundfile as sf import os def preprocess_audio(input_path, output_path, target_sr16000, trimTrue): 标准化音频统一采样率、裁剪静音、转 wav # 加载音频并重采样到 16kHz y, sr librosa.load(input_path, srtarget_sr, monoTrue) # 静音裁剪去掉首尾静音段保留中间有效语音 if trim: y_trimmed, _ librosa.effects.trim(y, top_db30) else: y_trimmed y # 归一化到 [-1, 1]避免不同录音音量差异过大 y_norm y_trimmed / (np.max(np.abs(y_trimmed)) 1e-8) # 写入标准格式 sf.write(output_path, y_norm, target_sr, subtypePCM_16) print(fProcessed: {input_path} - {output_path}, dur{len(y_norm)/target_sr:.2f}s)这段代码做了三件事。librosa.load里srtarget_sr强制把所有音频重采样成 16kHz 单声道这是说话人识别最常见的采样率因为人声的有效频段集中在中低频16kHz 足够用还能降低计算量。librosa.effects.trim的top_db30表示把低于峰值 30dB 的首尾段落视为静音并去掉这个值是我试过比较稳的参数太大会把轻声开头的语音切掉太小则裁剪不干净。最后的归一化是防止不同人录音设备音量不同导致模型学习到音量偏差。一个容易被忽略的细节librosa加载mp3时会引入解码误差不同码率的mp3解码出来的波形差异可能影响声纹特征。所以我坚持把所有格式统一转成wav用PCM_16编码避免后续训练的输入不稳定。3.2 训练脚本的三个关键参数帧长、embedding 维度和 batch size训练一个说话人识别模型train.py里最核心的不是网络结构而是三个参数音频分帧的窗长frame length、embedding 维度和 batch size。它们决定了模型看到的是多长的语音片段、用多大的向量表示说话人、以及一次更新参数时看多少样本。# train.py 中的核心配置示例 config { sample_rate: 16000, frame_length: 2.0, # 每次输入模型的音频长度单位秒 n_mels: 80, # Mel 滤波器组数量用于生成 fbank 特征 embedding_dim: 192, # 声纹嵌入向量维度 batch_size: 64, num_epochs: 100, lr: 1e-3, lr_scheduler: cosine, }frame_length这个参数很多人不在意但它对效果的影响非常大。训练时模型并不是吃一整段几十秒的录音而是随机切 2 秒的小片段。片段太短比如 0.5 秒模型学不到足够的音色和韵律特征片段太长比如 5 秒batch 里的样本多样性下降而且训练速度变慢。frame_length2.0是业界比较常见的取值短至 1 秒也能跑但 EER 通常会高一些。embedding_dim前面提过这里是 192 维。注意一点embedding 维度和n_mels80不是一个东西。n_mels是声学特征图的维度你可以把 80 路的 fbank 特征理解成 80 行的一幅“频谱图”embedding_dim是模型把整幅图压缩成的向量长度。如果你改了n_mels模型第一层卷积的输入通道也要跟着改这个别漏。batch_size64在 80 张 Mel 图、2 秒长度、80 维特征的情况下一张 24GB 显存的显卡能吃得下。显存不够就减半但不要低于 16否则梯度更新太频繁loss 会震荡。3.3 训练过程中的观察点loss 下降不等于模型收敛训练说话人识别模型最容易被骗的指标是 loss。CrossEntropyLoss降到 0.1 以下看起来很美但很可能模型只是在背训练集里的说话人标签而不是学到了“声音特质”。我的判断习惯是每 5 个 epoch 跑一次验证集算 EER而不是傻等训练结束。# 训练过程中每 5 个 epoch 自动评估验证集的 EER python train.py --config config.yaml --eval-every 5 --save-best-only这段命令的关键是--eval-every 5它让训练循环每 5 轮中断一次加载当前权重到验证集上计算等错误率 EER。--save-best-only表示只在 EER 比历史最优值低时覆盖保存模型这样即使后面过拟合了你手里也保留着最有价值的那一版权重。我不建议跑满num_epochs100再来评估那等于盲人摸象你根本不知道模型在哪个阶段开始从“泛化”滑向“死记硬背”。训练时还有一个观察点如果训练 loss 稳步下降但验证集 EER 不降反升说明模型已经过拟合了。这时候不是调模型结构而是回数据层面增加数据增强加噪、变速、混响或者调大batch_size提高梯度估计的稳定性。如果训练 loss 和验证 EER 一起不降那才是模型结构或学习率的问题优先检查lr是不是设大了导致的震荡。4. 跑通验证流程从注册到比对的完整推理链路4.1 注册阶段的实操每人的注册语音该录几条、怎么处理说话人识别的部署阶段第一步是注册enrollment。这个过程是在给每个用户建立声纹模板模板的质量直接决定了以后能不能认出他。我见过最偷懒的做法是拿一条 3 秒的音频注册然后对着系统喊破喉咙也识别不出来。常见做法是每人注册 3 到 5 条语音每条 5 秒以上内容最好不太一样。为什么要多条因为单条语音只覆盖了这个人某一种发音状态语速、语调、响度而真实场景下他说话是千变万化的。多条语音提取出来的多个 embedding不能直接拼接存起来而是取它们的平均向量作为模板。有些工程会在取平均后做向量归一化让模板向量的模长为 1方便后续余弦相似度就是简单的向量点积。import torch import torch.nn.functional as F def enroll_speaker(model, audio_paths, devicecuda, embedding_dim192): 注册一个说话人洗多条语音的 embedding取均值得到声纹模板 embeddings [] for path in audio_paths: # 加载并预处理音频假设已重采样到 16k waveform load_audio(path) # 返回 (batch1, time) 的张量 with torch.no_grad(): emb model(waveform.to(device)) # 输出 (1, embedding_dim) embeddings.append(emb.squeeze().cpu()) # 取均值后做 L2 归一化向量模长为 1 template torch.mean(torch.stack(embeddings), dim0) template F.normalize(template, p2, dim0) return template.numpy()代码里的torch.mean是对多条语音的 embedding 逐元素求平均这样得到的是一个“平均音色”。最后一步F.normalize的p2表示 L2 范数归一化模板向量的长度被压成 1。这个操作的直接收益是后面算余弦相似度时cos(a, b) a · b少一步除法计算更快。参数说明embedding_dim必须和模型输出的维度一致不然torch.stack会因形状不一致报错。这里有一个推理阶段的陷阱——模型训练时输入是随机裁剪的 2 秒片段但注册时你喂进去的可能是 8 秒、10 秒的完整音频。如果模型不做滑窗聚合它会直接吃下整段音频导致特征分布和训练时不一致。常见做法是在load_audio里把长音频切段每段 2 秒分别提取 embedding 后再平均而不是只取开头 2 秒。4.2 验证阶段的相似度打分余弦相似度的阈值设多少注册完模板验证阶段就是拿新录音提取 embedding和所有已注册模板算余弦相似度得分超过阈值就判定为同一个人否则拒绝。import numpy as np def verify_speaker(embedding, templates, threshold0.5): 验证说话人算 cosine similarity超过阈值则通过 templates: dict, {speaker_id: np.ndarray} # L2 归一化保证余弦相似度 点积 embedding embedding / (np.linalg.norm(embedding) 1e-8) scores {} for speaker_id, template in templates.items(): # template 已经归一化直接点积 score np.dot(embedding, template) scores[speaker_id] score best_speaker max(scores, keyscores.get) best_score scores[best_speaker] # 超过阈值才认为是注册过的人否则拒绝 if best_score threshold: return best_speaker, best_score else: return None, best_score上面这段代码的核心在np.dot那行因为注册阶段的模板已经做了 L2 归一化而输入 embedding 在函数第一行也做了同样的归一化所以点积的结果就等于余弦相似度。这里的关键不在计算在于threshold0.5是怎么定出来的。直接用 0.5 是拍脑袋我一般做法是拿验证集画出正负样本对的相似度分布找到两者的交叉点作为阈值初值再根据误拒FRR和误识FAR的业务容忍度上下调整。门禁场景误识比误拒危险得多阈值就往高调比如 0.6会议纪要分人场景宁可多标几个人让用户自己选阈值可以降到 0.4。4.3 把推理链路封装成服务批量验证与实时流式识别本地脚本跑通了推理到部署这一步又有一道坎怎么把单条验证变成能对外服务的接口。常见做法是用 FastAPI 包一个 HTTP 服务内部维持一个全局的模板字典接收音频文件后返回说话人 ID 和得分。from fastapi import FastAPI, UploadFile import numpy as np import soundfile as sf import io app FastAPI() # 全局维护的注册模板字典加载模型、初始化 templates_db {} model load_model(models/best_checkpoint.pt) app.post(/verify) async def verify(file: UploadFile): # 读取上传的音频并转为 numpy 数组 audio_bytes await file.read() waveform, sr sf.read(io.BytesIO(audio_bytes), dtypefloat32) # 重采样到 16k、截取/切段、提取 embedding embedding extract_embedding(model, waveform, sr) # 和所有模板比对返回结果 speaker_id, score verify_speaker(embedding, templates_db, threshold0.5) return {speaker_id: speaker_id, score: float(score), accepted: speaker_id is not None}这段代码把前面两步串成了一个 HTTP 接口。sf.read的dtypefloat32是把音频数据以 32 位浮点读入PyTorch 模型默认输入也是float32避免类型不匹配报错。extract_embedding是你自己的逻辑里面要做切段、聚合和训练时的frame_length2.0保持一致。templates_db是一个全局字典生产环境下应该换成 Redis支持动态增删注册模板不然新增一个用户得重启服务。5. 「说话人-识别.zip」落地避坑实录五个最常见的翻车点5.1 解压后中文路径导致的加载失败现象代码运行到加载音频或保存模型时报FileNotFoundError或编码错误路径里带中文的文件夹全部读取失败。原因很多开源代码的内部用的是os.path.join 字符串拼接在 Windows 下如果项目路径含中文Python 默认的utf-8编码和gbk文件系统编码对不上就会炸。解决把整个项目的根目录改成纯英文路径比如D:\speaker-recognition。如果项目结构不允许动在代码开头加一段强制指定编码的配置import sys import locale # Windows 下强制使用 UTF-8 处理路径 sys.stdout.reconfigure(encodingutf-8) sys.path [p.encode(unicode_escape).decode() if os.path.basename(p) else p for p in sys.path]这段代码的核心是sys.stdout.reconfigure它把标准输出的编码强制改为 UTF-8让报错信息能看到中文路径真正的问题。最省事的做法还是整个路径不要出现中文别跟自己的系统过不去。5.2 预训练权重与代码结构对不上key 名字冲突现象加载官方或随包附带的.pt文件时报Missing key(s) in state_dict或unexpected key。原因zip 里的代码和权重可能来自不同版本比如encoder.py的卷积层命名从conv1改成了features.conv1旧权重里所有 key 都对不上。解决加载权重时打印冲突的 key然后做 key 映射checkpoint torch.load(models/pretrained.pt, map_locationcpu) state_dict checkpoint[model_state_dict] if model_state_dict in checkpoint else checkpoint # 打印 mismatched keys定位差异 from collections import OrderedDict new_state_dict OrderedDict() for k, v in state_dict.items(): # 兼容旧版本命名去掉或替换前缀 new_k k.replace(encoder., ) if k.startswith(encoder.) else k new_state_dict[new_k] v model.load_state_dict(new_state_dict, strictFalse)这段代码的strictFalse是最后的保底手段它允许模型加载时忽略权重中不存在的层和缺失的层。但注意如果缺失的层是最后一个全连接分类头且你已经换了新数据集这是正常的如果缺失的是卷积层那模型可能完全跑不出有效结果。用strictFalse前一定先打印出哪些层被跳过了。5.3 训练 loss 下降但验证 EER 居高不下现象训练集 loss 从 3.0 稳定降到了 0.2但跑验证集时 EER 一直在 20% 以上和模型“学过”的表现完全不像。原因最典型的是数据泄露或过拟合。数据泄露常见于数据集划分不当比如同一个人的不同录音片段同时出现在训练集和验证集里训练时模型见过验证集的“脸”但验证时换一段没见过的录音就露馅。过拟合则是模型把说话人 ID 和特定录音环境绑定了背景噪声、设备响应都成了“身份特征”。解决回到数据划分检查有没有按说话人 ID 分组划分而不是按文件随机划分。用speaker_id做 group 级别的分割保证同一个人的所有录音只出现在训练集或验证集其中之一。同时加数据增强# 在训练时随机加噪声降低模型对录音环境的过拟合 def add_noise(waveform, noise_level0.005): noise torch.randn_like(waveform) * noise_level return waveform noisenoise_level0.005是一个比较克制的取值太大会把语音本身的特征淹没太小起不到增强效果。加了增强后模型被迫去学“人声本身”而不是“录音环境”验证 EER 通常会明显下降。5.4 多人同时说话时识别结果不稳定现象两人同时说话的场景下系统时而识别 A、时而识别 B而且得分都不高。原因如果把多说话人语音直接切段提取 embedding模型实际拿到的是混合声学特征它并不具备分离多个声源的能力。说话人识别模型从设计上假设输入是单说话人语音这个假设一被打破输出就是随机的。解决在识别前接一个语音活动检测VAD加声源分离的前置模块把混合音频按说话人分离成多路单说话人语音再各自走现有的注册-验证流程。常见做法是先切段每段只保留能量最高的说话人假设近距离说话人能量占优而不是把整段混合语音直接丢给模型。这个场景下调整阈值是没用的问题出在前端数据质量。5.5 测试集准确率 95%实际用起来像失忆现象在测试集上 EER 只有 3%但现场录一段语音总是识别失败或误识。原因测试集的录音条件和实际部署场景不一致。测试集可能是同型号手机在安静房间里录的而现场是客服坐席背景有键盘声、同事说话声、电话铃声。声学特征分布已经变了模型在分配律偏移下失效。解决落地前用目标场景的设备录一批“模拟真实数据”加入到注册库和测试集里做 domain adaptation。具体做法是把现场采集的音频作为测试集对比当前模型的 EER如果显著高于开发集就要用少量现场数据微调模型。这个“少量”我一般控制在 5 到 10 分钟每设备类型只微调最后两层不重训整个网络。6. 进阶用法用说话人日志Speaker Diarization做会议纪要的说话人分段到这里你已经跑通了注册-验证闭环但真实世界里音频往往不是“一人一段”而是多人交叉说话。我的习惯是在验证之前加一道说话人日志步骤把一整段会议录音切成连续片段每个片段标注是哪个人在说。这个方向用的是同一套 embedding 模型但需要做分割聚类这里有一个实用技巧直接调用你 zip 里的 embedding 提取函数配合滑窗切段 聚类不引入额外框架。具体做法是把录音按 1.5 秒滑窗、0.5 秒步进切段每段提取 embedding然后对这些 embedding 做凝聚层次聚类Agglomerative Clustering距离阈值决定了“不同的人”的粒度。聚类的簇数不用提前指定靠距离阈值自然形成。我的血泪教训是聚类完一定要回头看一眼每一段的长度太短的簇小于 1 秒基本是噪声或语气词误切直接丢弃不然合并到正文里会干扰后续的说话人标记。另一个常用的进阶技巧是“注册库动态更新”。真实用户的状态会变——感冒、衰老、在不同设备上说话都会让声纹向量偏移。我一般会保留用户最近的 20 次成功验证的 embedding超过 20 条时用滑动窗口重新计算模板均值而不是永远用第一次注册的旧模板。这个机制能显著降低长期使用后的误拒率代价是实现时多维护一份向量缓存。你在改这个逻辑的时候要特别留意别把验证失败的音频也更新进模板否则系统会被慢慢“毒化”越用越认不出原来的主人。最后说一个我个人的习惯每次调完阈值或更新了模板我会用一段 30 秒的“幽灵录音”包含多人重叠说话、咳嗽声、键盘声的混合音频做压力测试确保系统在这种输入下不会崩出离谱的高分误报。这个测试不追求准确识别只验证健壮性。说话人识别这个方向做到 90% 的是一个模型做到 99% 的是一整套工程后者才是 zip 里真正值钱的部分。希望这篇笔记能帮你把包里的东西顺利变成线上可用的能力少走我当年走过的弯路。本文还有配套的精品资源点击获取