← 返回博客
Ai预计阅读 11 分钟

微软将部分转录延迟降至 100 毫秒。这改变了转录的用途。

发布于 2026年10月5日
微软将部分转录延迟降至 100 毫秒。这改变了转录的用途。

2026 年 10 月 2 日,微软 AI 发布了 MAI-Transcribe-2-Streaming,这是一款语音识别模型,可在 60 种语言上以仅略超 100 毫秒的速度返回部分转录结果。它在 Artificial Analysis 的最终转录准确度和部分转录准确度两项排名中均位列第一。截至今年年底,其推广价为每小时音频 0.54 美元。

该公司还发布了 MAI-Voice-2.1 和 MAI-Voice-2.1-Flash,覆盖 23 种语言和 26 个区域设置。该模型可通过 Azure Speech、Microsoft Foundry、MAI Playground、OpenRouter(ID 为 microsoft/mai-transcribe-2)、Vercel 和 Azure Voice Live 使用,LiveKit 集成则标注为即将推出。

100 毫秒是一道门槛,而非基准测试中的奇观。它处在人们感知为“即时”的边缘。低于这一阈值,界面就能在用户还在说话时作出响应,而这正是“生成文档的产品”与“参与对话的产品”之间的差别。

青色灯光下精细金色网罩中麦克风振膜的极端特写

为什么最终准确度从来不是故事的全部

语音识别多年来一直是一个成熟品类,而各类排行榜大多只衡量一件事:当说话人停止后,模型对一段完整话语的还原有多准确。这一指标回答的是转录服务关心的问题,却没有回答实时产品关心的问题。

一个只在说话人说完后才显示文字的会议助手,不过是一台排版更好的录音机。而一个能在文字到达时即时显示的会议助手,可以高亮当前说话人、在某人名字被提及的那一刻将其呈现、在话题仍处于讨论中时触发搜索,并让用户在句子进行到一半时回滚查看而不丢失位置。所有这些都取决于部分延迟,而非最终准确度。

部分准确度才是更难的问题,也是 Artificial Analysis 如今单独追踪的指标。在句子尚未完整时就生成一个稳定的猜测,意味着你必须做出一个可能随后需要修正的判断。频繁修正的模型会产生闪烁跳动的文本,这比等待更糟。而过于激进地定稿的模型则会在屏幕上留下错误。对部分结果进行排名,奖励的是那种能足够频繁地把中间文本做对、从而让读者可以信任眼前内容的模型。

微软宣称在两个榜单上都位列第一,意味着它没有用中间结果的稳定性去换取最终正确性——而这正是模型通常用来换取部分结果速度的方式。这种组合才是这次公告真正的重点。

100 毫秒这个数字

流式识别中的端到端延迟是一条链条,而非单一数字。音频以帧的形式到达。端点检测模型判断一段话语可能已经结束。识别模型生成文本。下游系统将其渲染出来。每一个环节都会增加延迟,而总延迟决定了体验是否感觉实时。

微软的 100 毫秒数字涵盖的是模型自身的输出,依据的是该公司自己的测量和 Artificial Analysis 的排名,而非独立的延迟审计。真正有意义的比较在于:这个数字能否在实时产品所创造的条件下成立——这与孤立地用秒表测一次是不同的问题:多位说话人、背景噪声、糟糕的会议麦克风,以及 60 种语言同时涌入同一条流水线。厂商很少公布这些条件下的延迟分布,而恰恰是这些条件决定了会议产品在一场真实会议中是否可用。

定价结构则是故事的另一半。每小时音频 0.54 美元是贯穿到年底的推广价,这说明微软预计会调整它。其战略意图不难看出。流式转录是每一个会议助手、呼叫中心分析产品和实时字幕服务的输入层。成为覆盖 60 种语言的最便宜的快速选项,是一种分发策略,而输入层的分发具有黏性,因为第二个更换供应商的团队必须针对另一套中间结果行为重建自己的处理逻辑。

它与什么竞争

微软并非进入一片空白的领域。Deepgram、AssemblyAI 和 Speechmatics 都已围绕流式准确度和低延迟建立起业务,而谷歌和亚马逊也把有竞争力的识别能力打包进各自的云技术栈。现实中的买家,是那些已经在 Azure 上运行的开发者:他们看重 MAI-Transcribe-2-Streaming 能够与 MAI 家族的其他成员一起出现在 Foundry 和 OpenRouter 中,并且宁愿不要为单个组件再维护一段供应商关系。

MAI-Voice-2.1 的发布在这里同样重要,而且这种搭配是刻意的。语音识别和语音合成是同一场对话的两端,同时销售两者的平台可以推销一条完整的流水线:音频输入、转录输出、响应合成、语音返回。在合成一侧新增 23 种语言和 26 个区域设置,拓宽了这条流水线能作为单一产品出售的市场数量。

快速的部分结果给产品设计带来什么变化

一旦中间文本能在十分之一秒内到达,一组过去显得不合理的界面决策就会变得寻常。

先看打断。如果转录结果只有在说话人停止后才定稿,系统就必须等到静音才能对所说的话采取行动,这意味着在它能够回应之前,对话已经继续了。有了快速的部分结果,系统可以在指令被说出的那一刻就识别并插话,这正是人们期望房间里另一个人做出的行为。支持打断(barge-in)的语音代理依赖于此。那些需要跟上语速快的人、而不是落后三句话的实时字幕系统也是如此。

搜索是第二个受益者。一个能在转录边生成边搜索的会议助手,可以在项目名称被提到的瞬间调出相关文档,而此时讨论仍在进行。这与一小时后才产出可搜索笔记的录音机是根本不同的产品。

结构化提取是第三个。如果部分文本足够可靠,下游模型可以在会议结束前就开始阅读,边听边标注决策和行动项。这里的收益来自能在参与者仍记得自己本意时审阅输出,而非来自原始速度。

这些行为中的每一项都提高了部分稳定性的重要程度。一份每秒自我改写两三次的转录,会让这三项功能都变得烦人而非有用,这也是为什么微软此次公告中更深层的故事,是它在部分准确度上的排名,而非延迟数字本身。

有趣的风险在哪里

转录准确度数据通常以总体百分比呈现,而总体百分比掩盖了底层的分布。在带口音的语音、句子中途的语言切换、儿童声音以及非标准麦克风上的表现,各模型之间差异极大,而这些恰恰是实时产品最可能被使用的条件。一个平均分很高的模型,对于某个客户会在句子说到一半切换语言的特定呼叫中心来说,仍可能是错误的选择。

第二个风险更具战略性。一旦转录快到、便宜到可以持续运行,自然的下一步就是让它一直运行。一个每小时只花五毛钱的模型,让持续聆听变得可以负担,而按分钟计费的定价模式做不到这一点;而持续聆听意味着对设备附近所说一切的环境录音。这是一个数据治理决策,没有任何准确度排行榜会替购买这项技术的团队做出。

MAI-Transcribe-2-Streaming 是一件真正有用的基础设施,而部分准确度的排名是值得关注的部分,因为它衡量的是实时产品实际依赖的指标。仍未解决的是,厂商测得的 100 毫秒数字,能否在一个声学条件糟糕、四个人同时抢话的房间里站得住脚。这是每一位买家在把生产流水线交给它之前,都会私下进行的测试。

相关文章