过去两年你可能用过不少AI转录工具，从会议记录到视频字幕，识别准确率高得让人意外。很多人没注意到，这些产品背后大概率是同一套模型家族在发力——OpenAI在2022年开源的Whisper系列，直接刷新了开放语音识别的基准。它的架构很值得拆开看一看，既因为写进产品时会踩到一些固定的坑，也因为里面藏着一个相当聪明的多任务合并技巧。

我听到一个反复出现的抱怨：语音明明说得很清楚，可转录结果会在某个整30秒附近重复一词，或者缺掉半句话。这个bug的根源，其实就埋在Whisper处理音频的第一个固定选择里。要理解这一点，得从音频是怎么变成“图片”说起。

Whisper不会直接吞原始波形采样点。给一段音频，它做的第一件事是算出对数梅尔频谱图，把一维信号变成二维的表征：横轴是时间，纵轴是频率，点的深浅代表能量强度。所有输入都会被重采样到16 kHz，然后用25毫秒宽的窗口、10毫秒一步的步幅，切成一连串高度重叠的短帧。每一帧里，计算80个频率通道的能量，这个频率尺度模拟人耳对音高的感知。最终得到一个形如图像的张量。把语音当成图像来处理，这也是为什么卷积层和transformer能够直接派上用场。

变完图像后，进入整个架构里最硬的一个约束：Whisper只认30秒的时间窗。不是可选项，是写死进模型结构里的设定。短于30秒的音频会被静音补长到30秒，长于30秒的则要切段，分别跑模型，最后再把文本拼接起来。这个机制直接催生了前面那种bug——如果切割点恰好落在一个词中间，或者一句子的延续处，模型在接缝处就很容易失去上下文。生产系统中往往会前置一个语音活动检测模块，迫使切割发生在自然停顿处，避免切到音节中间。如果你在日志里看到某个30秒整数倍的时间戳上重复出现相同短语，或者有一小段录音人间蒸发，30秒的粗暴分割通常就是首要嫌疑。

说完这个令人头疼的固件设计，再来看架构上非常漂亮的解法。频谱图先送进编码器：两层卷积提取局部特征，叠加上位置编码，再接一堆transformer块。编码器的任务是把声音画面抽象成一串内部表征，剥离掉谁在说话、说的是什么语言，只留下“说了什么”的信息。这部分处理完，切换到解码器，自回归式地一个接一个生成文字token，每一步都关注编码器的输出。这就是翻译模型里常见的编码器-解码器transformer骨架，Whisper直接复用了，因为它在训练时就接触过多语言翻译任务。

这里有一个很多人最早没注意到的多任务技巧。通常一个语音处理流水线需要挂好几个模型：一个检测语种，一个做转录，一个负责翻译，还有一个专门打时间戳。Whisper把这些任务收进同一个解码器里，靠的是在序列开头插入特殊的任务token。用一组提示token告诉解码器“当前任务是转录，语种是西班牙语”，解码器就按转录模式输出；换成“翻译成英语”，同一个解码器便切换到翻译通路。没有额外的分类头，没有分支网络，模型容量被高度共享。

现在可以把正方和反方观点摆在一起来看。正方会指着多任务统一设计说，这是优雅的工程整合，把语种识别、转录、翻译、时间戳对齐压缩进一个结构中，减少了部署时串联多个模型的维护成本和延迟。反方则会把焦点移回30秒硬窗口，指出这种设计把上下文切割的问题直接推给了调用方，任何基于原生Whisper搭建的产品都会饱受断句不准之苦，需要额外搞一套边界检测和缝合逻辑，而这是模型本身没有解决的。双方说的都是事实，只不过一个在看模型结构内部的整洁度，另一个在盯落地时的边界效应。

我的判断是，Whisper家族的吸引力正在于它用一个编码器-解码器架构覆盖了多个语音任务，这件事的复杂度控制得相当克制。而那30秒的固定窗口则更像是研究原型的印记，从这个角度它算不上缺陷，而是一桩明码标价的技术债——知道它存在，提前挂上语音活动检测、段边界词汇迁移这类补丁，转录质量就不会被它拖累。所以理解这四步，不只是在拆一个开源模型，更是弄清楚当音频流进模型到文字流出的过程中，哪些环节由模型自己优雅地解决，哪些环节必须靠工程手段去兜底。