音频转文字怎么实现？从Whisper到SenseVoice的语音识别技术全拆解

语音识别（ASR）已经从实验室走进日常开发。本文拆解一条完整的"音频转文字"技术链路：音频如何预处理成模型可吃的格式、Whisper 与 SenseVoice 两种主流模型的原理差异、以及浏览器端与服务端两种落地方式的取舍。全程附可运行代码，适合想自己搭转写服务的开发者。

一、为什么需要"音频转文字"

会议纪要、课程笔记、采访整理、视频字幕，一个共同痛点是：信息在音频里，不在文本里。你没法搜索一段录音，也没法直接引用它。把音频转成文字，等于给非结构化数据补上了索引。

我的使用场景很典型：录了 1 小时的产品评审，会后想搜"带宽"这个词在哪提过——没有转写稿，只能从头听。转成文字后，全文搜索、逐句定位、直接贴进文档，效率完全不是一个量级。

这件事的工程难点在三点：

  1. 音频格式五花八门，要先统一成模型能吃的格式
  2. 识别模型要选对（通用 vs 特定语言优化）
  3. 落地方式要选对（本地隐私优先 vs 服务端速度优先）

下面逐层拆解。

二、ASR 的基本原理：音频怎么变成文字

语音识别可以抽象成一句话：把声学信号映射成文本序列。现在主流是端到端模型，输入是波形（或频谱），输出直接是 token 序列，中间不需要音素、词典这些手工环节。

音频从文件到模型输入，通常要过三道预处理：

原始音频 → 重采样(16kHz) → 转单声道 → 归一化成 Float32 → 模型推理

为什么是 16kHz？因为语音的能量主要集中在 0–4kHz 频段，16kHz 采样率（Nyquist 频率 8kHz）足够覆盖，又比 44.1kHz 少一大半数据。这是 Whisper 等模型的标准输入约定，几乎所有 ASR 模型都要求 16kHz 单声道。

三、方案一：Whisper，开箱即用的通用模型

Whisper 是 OpenAI 开源的语音识别模型，覆盖 99 种语言，核心设计是 encoder-decoder transformer 架构，并且做成了 multitask：同一个模型既能转写、又能翻译、还能输出时间戳和语言识别。

它有几个规格：tiny/base/small/medium/large，参数量从 39M 到 1550M 递增。识别质量与模型大小强相关，large 明显强于 tiny，但显存需求也水涨船高。

自建服务用 Python 侧很简单：

import whisper

model = whisper.load_model("base")  # 可选 tiny/base/small/medium/large
result = model.transcribe("meeting.wav", language="zh")

print(result["text"])                       # 全文
for seg in result["segments"]:
    print(f"[{seg['start']:.1f}s - {seg['end']:.1f}s] {seg['text']}")

输出里自带时间戳分段，生成 SRT 字幕非常方便。我跑下来 base 模型在普通 CPU 上大概 1:2 的实时率（1 分钟音频约 2 分钟处理），medium 明显更慢但准确率上一个台阶。

关键结论：Whisper 的优势是通用性和多语言覆盖，一句话"零训练直接用"；代价是模型偏重、CPU 推理偏慢。适合语言混杂、对准确率要求高的场景。

四、方案二：SenseVoice，更快的中文强项模型

SenseVoice 是阿里通义实验室开源的语音识别模型，特点跟 Whisper 形成鲜明对比：

维度 Whisper SenseVoice
架构 Encoder-Decoder Transformer Encoder + 非自回归解码
中文准确率 好 更强（中文专用优化）
推理速度 偏慢 快（非自回归逐帧并行输出）
语言覆盖 99 种 中英日韩粤语为主
富文本标签 无 自带情感/事件标签（笑、掌声、噪音）

"非自回归"是关键差异：Whisper 的解码器像写文章一样逐字生成，SenseVoice 则一次性并行输出整段标签序列，所以速度能快一个数量级。官方数据是 1 小时音频最快 6 分钟出稿，实际部署中确实快很多。

SenseVoice 的输出还带一层"富文本"信息，除了文字还能识别出笑声、掌声、背景噪音这类事件标签，对会议场景的还原度更高。

五、工程落地：音频预处理 + 模型推理

不管用哪个模型，前置的音频处理是共通的。真实场景里你拿到的是 MP3、M4A、甚至视频文件，得先抽出音频并转成 16kHz 单声道 WAV。

用 FFmpeg 一步到位：

# 视频/任意音频 -> 16kHz 单声道 WAV
ffmpeg -i input.mp4 -ac 1 -ar 16000 -c:a pcm_s16le output.wav

前端（浏览器）场景则用 FFmpeg WASM 提取音频，再手动解码 WAV 头、重采样成 Float32 数组喂给模型。核心伪代码：

// 读取 WAV 头：声道数、采样率、位深
const numChannels = header.getUint16(22, true);
const sampleRate  = header.getUint32(24, true);
const bitsPerSample = header.getUint16(34, true);

// Int16 -> Float32（除以 32768）
let float32 = new Float32Array(int16.length);
for (let i = 0; i < int16.length; i++) float32[i] = int16[i] / 32768.0;

// 立体声降单声道（左右声道平均）
// 非 16kHz 时线性插值重采样
// 然后：transcribe(float32, 16000)

关键结论：预处理参数错误是转写结果离谱的头号原因。采样率不对、声道没合并、位深算错，模型吃进去的就是"变声"音频。先把数据流调对，再谈模型。

六、本地 vs 服务端：两种落地方式的取舍

这是"音频转文字"落地的关键决策，直接影响隐私和速度：

维度 本地/浏览器端 服务端
隐私 数据不出设备 需上传
速度 受设备性能限制（约 1:1 实时率） 快（GPU/专用优化）
模型 Whisper（模型约 150MB 按需下载） 可上更大模型或专用引擎
成本 无服务器成本 需要算力
适用 敏感数据、短音频 长音频、批量、多人对话

两者各有适用场景。本地方案胜在隐私和零服务器成本，适合短音频和敏感内容；服务端方案胜在速度和多角色对话这类重能力。

比如 91aitool.cn 的音频转文字工具，就是两种都给了：本地模式用浏览器 Whisper 纯前端处理不传服务器，服务端模式用 SenseVoice 引擎、1 小时音频约 6 分钟出稿，还支持 SRT 字幕和多人对话模式输出。对我这种偶尔转个会议录音的人来说，省了自己部署一整套 Whisper/SenseVoice 的功夫。

image

七、常见问题

为什么转出来的中文总有几个字错？

一是模型选择，中文场景 SenseVoice 或 Whisper large 明显强于 Whisper tiny/base；二是预处理，确认音频是 16kHz 单声道；三是专业术语，可以在转写后做关键词后处理替换。

多说话人的音频怎么区分谁在说话？

纯识别模型不做说话人分离。要区分说话人需要额外的 diarization（说话人日志）模块，先用嵌入向量聚类出"谁在说"，再与转写文本对齐。很多工具标榜的"对话模式"就是这个能力。

视频转文字和音频转文字有区别吗？

没有本质区别，视频先抽音频流再走同一套转写链路。这也是 FFmpeg 在前面的预处理里出现的原因。

浏览器跑模型会不会很慢？

首次要下载模型（约 150MB），之后每次推理受设备 CPU 影响，短音频可以接受，长音频体验较差。这就是为什么长音频更适合走服务端。

八、总结

"音频转文字"本质是一条三层的工程链路：统一预处理（16kHz 单声道）→ 模型选择（通用 vs 中文优化）→ 落地方式（本地隐私 vs 服务端速度）。Whisper 胜在通用开箱即用，SenseVoice 胜在中文和速度。具体选哪个，取决于你的音频长短、语言构成和隐私要求——没有万能方案，但把预处理这层做对，任何模型的表现都会上一个台阶。

参考资料

posted @ 2026-08-01 09:38  小义同学  阅读(1)  评论(0)    收藏  举报