当AI一边听你说话一边猜你是谁

你有没有想过，如果开一个三人视频会议，AI字幕要同时做两件事：一边把你说的话变成文字，一边猜清楚这句话到底是谁说的？

听起来好像不难，人耳都能做到。但对机器来说，这其实是两套完全不同的活儿。转文字是听发音、拼词语,判断说话人是听声纹、记身份。传统做法是把这两件事拆成两个系统:一个专门做语音识别,一个专门做说话人分离,俩系统各干各的,最后再拼到一起。

这套拆分方案用了很多年，直到最近才有团队琢磨:能不能让一个模型同时把这两件事做了?微软研究院今年发布的VibeVoice-ASR就是这么个统一模型，它能一口气处理长达60分钟的录音，边转文字边分角色，效果相当不错。

但这里藏着一个问题,如果你仔细想想会议字幕这个场景就会发现: VibeVoice-ASR得等录音结束才能出结果。这就好比你开完一整场两小时的会,然后才拿到一份完整的会议记录。可现实中的语音助手、实时字幕、同声传译,都等不起这一个多小时。它们需要的是"话音刚落，字幕就出来了，还知道是谁说的"。

这就是本文要讲的VibeVoice-ASR-Streaming要解决的问题：怎么让一个模型，在语音还没说完的情况下，就一边转写、一边分角色，还要做到跟人对话时那种自然的反应速度。

**这篇论文做的事情，是把一个只能"听完再答"的模型，改造成能够"边听边答"，而且两件事（转写和分角色）依然放在同一个大脑里完成。**

这事儿难在哪儿

先说说这件事到底哪里棘手。

普通的语音识别，靠的是声学和语言模型的配合，前面的音频对当前这个词的识别帮助有限，主要靠邻近上下文。但说话人识别不一样。

设想一场四十分钟的会议，A在第2分钟发过言，然后沉默了十五分钟，到第17分钟又开口了。系统必须记得"这个声音是A"，才能给第17分钟的这句话贴上正确的标签。如果系统只记得最近几秒的对话，那A第二次开口时，系统很可能会把他错认成一个新出现的人，或者张冠李戴认成别人。

**说话人身份的确认，靠的不是当下这一句话，而是整场对话累积下来的记忆。**

这就好比你去参加一个多人饭局，中途有人临时离席去接了个电话，十分钟后回来继续插话。你之所以能一下子认出"这还是刚才那个人"，靠的不是他这句话说得多标准，而是你脑子里对他声音、语气、说话习惯的持续记忆。如果你是个"金鱼记忆"的人，每隔几分钟就忘记之前谁说过什么，那么这场饭局里的每一次插话对你来说都像是陌生人开口，你根本没法把发言串联起来。

在此之前，业内已经有两条技术路线分别摸索这个问题，但谁都没有把两件事同时解决。第一条路线是让基于大语言模型的语音识别系统学会"边听边写"，比如BESTOW、SpeechLLM-XL、Uni-ASR这些工作，它们把语音切成一小段一小段，同步生成文字，还会把之前说过的内容留在记忆里，但它们主要针对单人说话的场景，没有处理多人身份识别的问题。

大语言模型：一种通过海量文本训练出来的人工智能系统，具备理解和生成自然语言的能力，也可以经过改造去处理语音这类"类似语言"的信号。

第二条路线专攻多人实时识别，从早期的SURT、t-SOT，到后来给每个人挂上"声纹嵌入"标签的做法，再到把说话人识别单独做成一个在线模块、跟识别系统拼接起来的方案（比如Sortformer、Streaming Sortformer）。这条路线的问题是，它总得额外挂一个说话人识别的零件，没法用一个模型直接端到端搞定。

**VibeVoice-ASR-Streaming想做的，就是把这两条路线合并成一条：一个模型，边听边转写，边转写边分角色，全程不需要额外挂一个说话人识别模块。**

这套方法怎么设计的

先看整体架构。

模型的输入音频会先经过两套编码器处理。一套叫声学编码器，另一套叫语义编码器，二者的输出拼在一起，投喂给一个基于Qwen2.5的大语言模型主干网络。

声学编码器*：捕捉声音的音色、音高等物理特征，属于"这个人的嗓子听起来什么样"。

语义编码器*：捕捉与文字内容对齐的语义特征，属于"这句话在说什么内容"。二者结合，模型才能既听清内容，也辨清是谁在说。

这里有个具体的数字：音频以24kHz采样，经过压缩后，每133.3毫秒生成一帧特征，也就是每秒7.5帧。整篇论文里所有跟"分块大小""预读长度"相关的设置，都是这133.3毫秒的整数倍。

模型处理音频的方式是"切块"：把连续的语音流切成一段一段固定长度的音频块，每处理完一块就生成对应的一段文字，文字里既包含转写内容，也标注了说话人。处理完这一块，继续处理下一块，前面所有的音频和文字都留在模型的"记忆"里，供后面的判断参考。

这个设计里有个细节值得展开讲讲：每处理完一个音频块，模型并不是马上就开始生成文字，而是要先"多听一点点"，读取额外0.5秒（4帧）的未来音频，这部分叫做预读，读完之后才开始生成这一块对应的文字。

预读*：在正式转写某一段语音之前，让模型提前多听一小段紧随其后的音频，用来消解句子边界处的歧义。比如一个词还没说完就被切断在两个块之间，预读能帮模型看到词的后半部分，减少误判。

为什么要引入预读？因为语音块切分是硬性的，一刀切下去，可能正好切在一个词或一句话的半截。如果不给模型多看一眼，它就得在信息不全的情况下匆忙下判断，容易出错。

这就像你在嘈杂的餐厅里听人说话，服务员突然端着盘子从你俩中间穿过去，挡了半秒钟。这半秒钟对方说的话你没听清，但如果你能"倒回去"或者"稍等半秒钟"再理解这句话，准确率显然会高很多。论文里的实验也证实了这一点：预读时间从0秒加到0.5秒，几乎在所有测试集上，转写准确率和说话人识别准确率都在稳步提升，而且是"读得越多、听得越准"，到0.5秒时这个提升趋势都还没有停下来的迹象。

那如果完全不给预读会怎样？论文的对比实验里，去掉预读之后，五个测试集的平均转写错误率从24.66涨到27.18，说话人识别的综合错误率更是从31.55涨到35.88，两项指标都明显变差。这说明这0.5秒的"多听一下"绝非可有可无，它实实在在地在帮模型少犯错。

**这套方法最核心的一点是，转写文字和说话人标签是同一个生成过程里吐出来的，不是两步走。**

模型每生成完一段文字，会用一个专门的结束符号标记"这一块的文字说完了"，然后把控制权交还给音频输入流，继续处理下一块。整个过程像接力赛一样，音频和文字交替出现在模型的输入输出序列里。

说话人标签放在哪里也是个讲究的设计。论文里选择把标签放在每段话的开头，比如"说话人0：你好"，而不是放在结尾"你好：说话人0"。这样做的好处是，标签从这段话的第一个字就已经确定了，不用等这句话说完才知道是谁说的。有意思的是，论文专门做了对比实验，发现把标签放在开头还是结尾，对最终准确率的影响其实微乎其微，两种方式打了个平手。但放在开头的好处是能让下游应用（比如实时字幕显示）第一时间就知道该给这句话贴上谁的名字，这对用户体验是有实际价值的。

训练是怎么做出来的

模型不是一步到位训出来的，而是分三个阶段循序渐进。

第一阶段是非流式训练，也就是让模型先在"能看到完整录音"的条件下，把多人转写和说话人识别的基本功底打好。这一步不考虑实时性，纯粹是把两项核心能力立住。

第二阶段是流式预训练，这时候开始把训练样本改造成一段一段切块的形式，让模型习惯"只能看到部分音频，还要接受预读限制"这种新的工作方式。这一步用了大约42万小时的中英文语音数据，规模相当庞大。

第三阶段是流式微调，换成一批更精挑细选、体量小得多（约1.3万小时）的数据，专门打磨用户实际会体验到的细节，比如转写的措辞习惯、说话人标签是否稳定一致、专有名词是否能准确识别。

**这种"先学会基本功，再适应流式约束，最后精修细节"的三段式训练路径，本质上是把一个复杂的学习任务拆解成循序渐进的几步，而不是让模型从零开始同时学会所有事情。**

这让我想到学开车的过程。你不会一上来就在暴雨天的高速公路上练习倒车入库，通常是先在空地上学会基本的方向盘和油门刹车配合（对应第一阶段），再逐步加入路况限制比如限速和跟车距离（对应第二阶段），最后才在真实复杂路况里磨练细节判断，比如什么时候该让行、什么时候该变道（对应第三阶段）。如果一上来就让新手直接上高速练所有技能，大概率是学得慢、出的错也多。

论文还专门量化了"从离线模型改造成流式模型"到底要付出多大代价。同样是7B参数规模的模型，流式版本相比非流式版本，在纯转写准确率上大约下降0.75到3.53个百分点，但在同时考虑说话人识别的综合指标上，下降幅度达到5.13到6.67个百分点，明显更大。

**这说明流式改造带来的性能损失，主要体现在说话人识别上，而不是转写文字本身。**

这个结果其实挺符合直觉的：转写文字主要依赖近距离的语音语言线索，而说话人识别依赖的是跨越很长时间的持续记忆和积累的声纹信息，一旦被切成一段一段处理，这种连续性记忆自然会打折扣。

块大小和模型规模的取舍

论文还做了一个挺实用的对比实验：语音块切多大合适？

他们测试了两种切法，一种是22帧（约2.9秒）一块，一种是15帧（约2.0秒）一块，在同样的0.5秒预读条件下对比效果。结果是，更大的块（2.9秒）在所有测试集、所有模型规模下都表现更好，五个测试集平均下来，转写准确率提升1.3到1.5个百分点，说话人识别综合指标提升接近3到4个百分点。

这个现象背后的逻辑并不复杂：块越大，模型一次能看到的连续语音信息越多，判断起来自然更准，尤其是说话人身份这种需要"多听一会儿才能确认"的判断，块小了信息量不够用。

但更大的块也不是没有代价。**块越大，意味着模型攒够一整块音频才能开始处理，用户等待第一个结果出来的时间也就越长。**这是一个典型的"准确率换延迟"的权衡：15帧块的预期延迟是1.53秒，22帧块则是2.00秒，差了将近半秒。

这就跟点外卖是一个道理。你可以选择"凑够三份餐一起送"，配送员一趟能带更多、效率更高，但你得多等一会儿才能吃上饭；你也可以选择"一份餐立刻送"，虽然快，但配送员跑单趟的效率没那么高，累积起来的总成本反而可能更高。VibeVoice-ASR-Streaming选择了2.9秒这个块大小作为正式发布的默认配置，某种程度上是在"够快"和"够准"之间找了一个中间点。

模型规模这边，从1.5B参数增加到7B参数，带来的提升同样是说话人识别方面更明显：综合指标平均降低了11到13个百分点，而纯转写准确率只提升了4到5个百分点左右。这再一次印证了前面的判断，说话人识别这件事，对模型的"记忆容量"和"推理深度"要求更高。

跟真实产品比成绩

说了这么多设计细节，最终还是要看实际效果怎么样，尤其是跟市面上已经在用的那些实时转写产品比一比。

论文选了四个部署中的流式语音识别系统作为对比对象，分别是Gemini 3.5 Transcribe Live、GPT Realtime Whisper、GPT Live Transcribe，以及ElevenLabs Scribe v2 Realtime，还有微软自家的Azure ConversationTranscriber和谷歌云的Speech-to-Text。测试场景覆盖了四个会议录音基准（中文的AliMeeting和AISHELL-4，英文的AMI两种录音条件）以及一个覆盖九种语言的多语言对话测试集MLC-Challenge。

单纯看转写准确率（不考虑说话人识别），7B版本的VibeVoice-ASR-Streaming在AISHELL-4、AliMeeting、AMI-IHM三个测试集上拿到最好成绩，只有在AMI-SDM这个测试集上被Gemini 3.5 Transcribe Live压过一头。五个测试集综合平均下来，本文模型的错误率是24.66%，Gemini排第二是25.23%，GPT Realtime Whisper是39.31%，差距已经拉得比较开了。

再看更看重身份判断能力的综合指标（转写加说话人识别一起算），一共13个评测场景里，VibeVoice-ASR-Streaming拿到最好或并列最好成绩的场景有12个。相比Azure ConversationTranscriber，在四个会议测试集上领先2.39到12.45个百分点；在MLC-Challenge的九种语言平均值上，从27.06直接降到22.75。

延迟这块的对比更是直观。VibeVoice-ASR-Streaming的预期延迟是2.00秒，而Azure ConversationTranscriber实测的延迟是8.21秒，谷歌的系统更慢，第一次给出说话人标签要等9.12秒，如果算上后续标签修正稳定下来的时间，甚至要等到51.06秒。

**这个差距背后其实反映了两种完全不同的技术路线思路：谷歌的系统是"先猜一个答案，之后不断根据新信息修正"，而VibeVoice-ASR-Streaming是"边听边判断，尽量一次就判断准"。**

论文里专门分析了谷歌系统这种"先猜后改"策略的代价：如果用谷歌系统第一次给出的标签打分，说话人识别综合错误率是46.65%（以AMI-SDM为例），但等它把整段录音处理完、把标签修正到最终版本再打分，错误率能降到32.11%，差了14.5个百分点之多。也就是说，谷歌的系统靠"拖时间换准确率"，把最终判断往后拖了近一分钟，才把误判率压下来。而VibeVoice-ASR-Streaming不靠拖时间，靠的是转写文字本身的语言和上下文线索来辅助判断身份，就像人在听对话时，往往不是单纯凭声音辨认是谁，而是结合这个人说话的内容、语气、逻辑习惯一起判断。

这个思路的转变蛮有意思。传统的说话人识别是纯粹的声学问题，把声音编码成向量，然后聚类，声音听得越久，聚类结果越准，所以"等久一点"天然就是提升准确率的办法。但一个同时处理文字和声音的端到端模型，判断依据不只是声纹，还包括这句话符不符合这个人平时的说话逻辑、话题的连贯性等等语言层面的线索，所以它不需要靠拖延来换准确率，能在两三秒内就把判断定下来。

这套设计目前还有哪些短板

诚实地说，这个系统并不是万能的。

论文自己也列出了几条明确的限制。第一是语言覆盖有限，因为训练数据的词级时间对齐依赖一个叫Qwen3-ForcedAligner的工具，这个工具支持的语言有限，所以整套系统目前只在十种语言上训练和评测过。

第二是长时间的说话重叠处理得不够好。如果两个人同时说话且持续时间较长，模型只能把这些重叠的语音按顺序串成一条输出流，这在真实的对话里其实是硬伤，因为真人对话经常会有抢话、插话、笑声打断这种情况，而模型没法真正做到"并行输出两条语音流"，只能把重叠部分强行排成先后顺序。

第三是录音长度上限，目前发布的模型只支持最长8分钟的录音，这主要是受限于计算资源，不是架构本身的天花板。随着对话变长，模型需要记住的历史信息也线性增长，计算开销跟着涨。

第四是首包延迟的问题。论文里反复强调的2.00秒延迟，其实是"稳定状态"下的预期值，第一次要出结果，得先等一整块音频（2.9秒）加上预读（0.5秒）都凑齐，也就是3.5秒才能等到第一段输出，之后才能进入每2秒左右出一段结果的稳定节奏。这中间的启动延迟怎么压缩，论文也承认还没解决。

这些限制说明，这套系统离"完美实时字幕"还有距离，但至少证明了一件事：把转写和说话人识别塞进一个模型里同时做流式处理，这条路是走得通的，而且效果已经能打过市面上一些已经商用的产品。

写在后面

读完这篇论文，我觉得最值得琢磨的一点，不是那些具体的准确率数字，而是那个关于"说话人识别靠什么"的重新理解。

我们下意识会觉得，认出一个人的声音，靠的就是声纹，就是那种物理层面的音色特征。但这篇论文的实验结果暗示了另一种可能：当一个模型同时处理文字内容和声音信号时，它对身份的判断会自然融合进语言层面的线索，比如这个人平时怎么组织句子、习惯用什么词、话题连贯性如何。这也是为什么它不需要靠"拖延时间攒更多声音样本"来提升准确率，而是能在两三秒内就把判断敲定，这跟纯粹的声学聚类方法是两种完全不同的逻辑。

还有个细节我觉得挺值得单独拎出来说：说话人标签放在句首还是句尾，实验证明准确率几乎没差别。这个结果乍一看有点反直觉，因为按照常识，句尾应该能看到更多上下文，判断应该更准才对。但论文给出的解释是，这个模型判断身份靠的不只是声学证据，语言证据（内容本身）同样重要，所以放在哪都差不多。这个小小的"意外的平局"，其实侧面印证了前面那个关于"身份判断靠什么"的核心观点。

这篇论文没有解决的长时间重叠语音问题，我觉得倒是个值得持续追问的方向。真实对话里的抢话、打断、笑场，这些"不守规矩"的语音现象才是日常交流的常态，而不是例外。一个只能把重叠语音强行排成先后顺序的系统，在真正嘈杂的多人聊天场景里，可能还是会露怯。这大概也是接下来这条技术路线要继续啃的硬骨头。

Q&A

Q1：VibeVoice-ASR-Streaming是什么？

A：它是微软研究院提出的一种流式语音识别模型，能一边听语音一边实时转写文字，同时判断这句话是谁说的，不需要额外的说话人识别模块。

Q2：VibeVoice-ASR-Streaming和普通语音识别有什么区别？

A：普通语音识别只管转文字，说话人识别通常靠单独的系统事后处理。VibeVoice-ASR-Streaming把两件事放进同一个模型里同步完成，而且是边说边出结果，延迟只有2秒左右。

Q3：VibeVoice-ASR-Streaming目前还有哪些不足？

A：目前只支持十种语言，最长只能处理8分钟录音，长时间的多人抢话重叠场景处理得不够好，首次出结果也需要等待约3.5秒的启动延迟。