一小时不等于一个音频文件：大规模长音频语音处理的工程实践

VMEG 每天处理数万项 AI 视频本地化任务，其中约 10% 的视频时长超过一小时。我们处理过的最长项目超过三小时，涉及数十位说话人和复杂的多语言对话。

在这样的规模下，我们总结出一条重要经验：

长音频语音处理的瓶颈不在 AI 模型，而在工程系统。

常见误区

现代语音模型的能力仍在不断增强。

更大的上下文窗口。

更低的词错误率（WER）。

支持更长的音频。

人们很容易认为，处理一小时的视频，无非就是处理六十段一分钟的视频。

事实并非如此。

长音频语音会带来许多短录音中根本不存在的问题。

• 说话人身份随时间漂移。
• 时间戳误差不断累积。
• 术语前后不一致。
• 分块边界截断句子。
• 翻译丢失上下文。
• 微小错误不断叠加，最终形成明显的质量问题。

此时的挑战已经不再是模型能否转录这段音频？

而变成：

整个系统能否从第一秒到最后一秒始终保持一致？

长视频的问题不止一种

与短视频不同，长录音很少因为某个模型的单次错误而失败。

更常见的情况是，质量在整条处理链路中逐步下降。

典型问题包括：

一处错误的说话人边界看似无关紧要。

但如果错误继续传递到翻译、配音和口型同步环节，观众会立刻察觉。

因此，生产系统需要优化的是错误累积，不能只关注单个模型的准确率。

为什么商业 API 仍存在实际限制

如果你使用过商业语音 API，很可能遇到过音频时长、说话人数量、请求载荷大小或流式会话方面的限制。这些限制因服务提供商而异，也会随时间调整，但它们反映的是底层相同的工程权衡，并非随意设置的约束。

常见限制包括：

• 最长音频时长
• 最多可区分的说话人数量
• 请求载荷限制
• 流式会话超时
• GPU 显存限制
• 延迟与成本考量

与其把这些限制视为产品缺陷，不如将它们看作一项事实的佐证：长音频语音处理仍是一个持续演进的系统工程问题。

例如：

（服务能力会不断变化，部署前请务必核对最新文档。）

切分音频很容易。

合并却不容易。

大多数工程师最初设想的是：

split(audio, every=5 minutes)

问题解决了。

实际情况却是：

分块 1

今天我们要讨论未来……

分块 2

……的多语言 AI 系统。

此时就会出现：

• 句子被截断
• 标点发生变化
• 时间戳偏移
• 翻译质量下降

这些错误正是切分操作本身引入的。

再考虑说话人的情况。

分块 1

Host
Guest
Host

分块 2

Speaker A
Speaker B

Speaker A 究竟是谁？

如果缺乏全局推理，

同一个人在两小时的录音中可能被识别成三个不同的身份。

更大的上下文窗口无法解决所有问题

近年来，语音基础模型不断扩大上下文窗口。

这是一项重要进展。

但更大的上下文窗口并不会自动解决生产环境中的挑战。

系统仍然需要：

• 从失败的任务中恢复
• 并行处理视频
• 优化 GPU 利用率
• 支持时长超出模型限制的录音
• 维持说话人身份一致
• 保持术语一致
• 生成易于阅读的字幕

随着录音时长增加，

编排的重要性会逐渐超过推理本身。

处理长视频带来的工程经验

在每天处理数万项本地化任务的过程中，有几项工程原则反复证明了自身价值。

按语义分块，而不是按时间分块

五分钟通常不是最佳分块边界。

与任意时间戳相比，在自然停顿、句子结尾和话题转换处进行分块，能显著改善后续环节的处理效果。

语义分块可以减少处理链路后续的修正工作。

每个分块都需要上下文

相邻分块之间应保留一定重叠。

重叠过少会导致：

• 遗漏单词
• 时间戳跳变
• 说话人不连续

重叠过多则会产生重复内容，并增加合并复杂度。

如何取得适当平衡是一个优化问题，没有固定规则。

局部准确不代表整体质量可靠

每个分块单独处理时，都可能达到很高的转录准确率。

但合并后的转录文本仍可能存在：

• 说话人身份不一致
• 句子重复
• 标点冲突
• 时间戳不稳定

全局优化与局部推理同样重要。

多模态推理优于仅依赖声学信息的处理链路

传统长音频处理链路主要依赖声学嵌入，有时会辅以轻量级语言后处理。

在生产环境中，仅靠音频通常不够。

人们通常会结合多种信号，自然判断当前说话的人是谁：

• 声音特征
• 对话走向
• 视觉线索
• 对话语义
• 话轮交替模式

VMEG 采用了同样的思路。

我们的处理链路不会只依赖声学相似度，而是结合音频、转录文本和视觉上下文，再使用大语言模型（LLM）对整段对话进行全局推理。

系统不仅会判断：

哪些人的声音听起来相似？

还会结合更多信息进行判断：

根据对话、场景和上下文，最有可能是谁在说话？

这层额外的推理机制显著提升了访谈、纪录片、网络研讨会、播客和多语言对话中的说话人一致性。

因此，与传统方案相比，我们的说话人分离准确率提升到了 5 倍。

可靠性本身就是一项功能

长时间运行的任务终有失败的时候。

网络会出现故障。

模型会超时。

云服务会重试。

最糟糕的结果，是从头重新运行一条长达三小时的处理链路。

因此，VMEG 将本地化视为一个工作流，而不是一次独立的推理请求。

每个阶段都会生成可供审核的中间结果：

• 转录文本
• 说话人归属
• 时间戳
• 字幕分段
• 翻译
• 配音

每项产物都可以单独重新生成、修正或审核，无需重新运行整条处理链路。

这能显著改善质量保障，同时降低工程成本。

不能只看词错误率

语音 AI 过去通常关注各组件的指标。

语音识别

→ 词错误率（WER）

说话人分离

→ 说话人分离错误率（DER）

翻译

→ BLEU / COMET

这些指标仍然很有价值。

但用户不会直接感受到 WER。

他们感受到的是最终视频的效果。

一个 DER 略差的系统，仍可能制作出明显更好的本地化视频，因为：

• 字幕更易阅读
• 说话人身份始终一致
• 合成声音不会突然切换
• 翻译能自然保留对话含义

未来的评估体系应更多衡量整个本地化体验的质量，而不是孤立地评估单个模型的表现。

结语

扩大上下文窗口无法彻底解决长音频语音处理问题。

处理更长的音频文件也无法彻底解决这个问题。

选择更好的语音模型同样不够。

随着模型持续进步，真正的挑战逐渐转向系统建设：如何在数小时音频、数十位说话人、多种语言和复杂的下游工作流中始终保持一致。

VMEG 的实践表明，理想的处理效果需要扎实的工程系统与多模态 AI 推理相结合。处理链路应能持续优化输出、保留上下文，并确保每个阶段都透明且可审核。

因为在生产环境中，用户不会评价单个模型。

他们评价的是最终视频。

参考资料

以下资料有助于进一步了解长音频语音处理、说话人分离和生产级语音系统：

语音识别与基础模型

• Whisper：https://github.com/openai/whisper
• WhisperX（强制对齐与说话人分离）：https://github.com/m-bain/whisperX

说话人分离

• pyannote.audio：https://github.com/pyannote/pyannote-audio
• NVIDIA NeMo Speaker Diarization：https://docs.nvidia.com/nemo-framework/user-guide/latest/nemotoolkit/asr/speaker_diarization/intro.html
• SpeechBrain：https://speechbrain.github.io/

基准测试与数据集

• DIHARD Challenge：https://dihardchallenge.github.io/
• AMI Meeting Corpus：https://groups.inf.ed.ac.uk/ami/corpus/
• VoxConverse：https://github.com/joonson/voxconverse

云端语音服务

• Microsoft Azure Speech：https://learn.microsoft.com/azure/ai-services/speech-service/
• Google Cloud Speech-to-Text：https://cloud.google.com/speech-to-text
• Amazon Transcribe：https://aws.amazon.com/transcribe/
• Deepgram Documentation：https://developers.deepgram.com/