InterMIND 频道里的一条语音消息,会变成每位队友都能用自己的语言阅读的文字消息。第一步是语音转文字。主办方自己的 IT 部门或客户的审核人员会问的,并不是"它有多准",而是"这是谁的服务,音频会发往哪里"。
简短的回答是:Azure AI Speech,即默认 AI 网关的语音服务,运行在 InterMIND 位于 Sweden Central 的自有 Azure 租户中。组织可以选择的另外两个网关的语音服务,我们也在同样的音频上做了测量,让这个选择依据的是数字,而不是偏好。本文给出这一选择背后的数据:同一天内,同样的 153 条音频分别经过 Azure AI Speech、Google Cloud Speech-to-Text 和 Amazon Transcribe。文中还说明了每个 API 的两个事实,它们比一个百分点的准确率更重要。
InterMIND 中的每一项 AI 功能,包括会议回顾、文档摘要、写作助手、Ask AI 以及会议中的 Mia,都运行在组织选定的同一个语言模型网关上。默认是 EU Data Zone 中的 Azure OpenAI,也可以选择 EU 多区域端点上的 Google Vertex AI,或法兰克福的 Amazon Bedrock,均在 InterMIND 自己的租户中。我们在在您自己的云网关上运行会议 AI中解释了其中的考虑:对大多数组织来说,该网关已经在获批的子处理方清单上,因此新增一项 AI 功能不会给清单增加任何新公司。
目前,默认网关上的语音消息转文字遵循同一规则。三个网关各自在语言模型旁边都有一项语音服务,这正是本文要测量的对象:
| 网关 | 语音服务 | 本次测试所用区域 | API 接收录音的方式 |
|---|---|---|---|
| Azure OpenAI(Microsoft) | Azure AI Speech,快速转写 API | Sweden Central | 一次请求即可处理最长 5 小时、500 MB 的文件(快速转写文档,2026 年 9 月核查) |
| Google Vertex AI(Google Cloud) | Cloud Speech-to-Text v2,Chirp 3 模型 | eu 多区域 | 同步识别限制为 60 秒和 10 MB;更长的音频需通过批量识别或流式识别处理(同步限制、Chirp 3,2026 年 9 月核查) |
| Amazon Bedrock(AWS) | Amazon Transcribe,流式 | eu-central-1(法兰克福) | 通过 HTTP/2 或 WebSocket 建立流式会话;输入为 PCM、FLAC 或 Ogg-Opus(流式文档,2026 年 9 月核查) |
在所有情况下,识别器都会被告知说话人自己的语言,也就是成员在个人资料中设置的语言。在我们的测试中,自动语言识别在短音频上表现不可靠:一条四秒的俄语语音被识别成了英语。产品目前就是以这种方式调用 Azure 的,测试中调用另外两家的方式与此相同。
测试集。 17 种语言的 153 条音频:136 个对话回合,加上 17 段正式文本。对话回合来自两段商务对话(一次合同谈判和一次每日站会),由产品的两种合成语音以十种语言说出。正式文本取自我们公开翻译基准中的 FLORES-200 商务语句,由合成语音朗读,每种语言一段,时长 71 至 109 秒。对话回合时长为 3 至 30 秒,与真实语音消息的长度相当。
指标。 词错误率(WER),即相对参考文本被替换、插入或删除的词所占的比例,计算前会统一大小写、标点和空白;中文和日语按字符比较。我们同时记录了字符错误率,结论一致。
测试框架。 一个脚本、一台机器,于 2026-09-16 用一小时完成,每个引擎处理全部 153 条音频。Azure 和 Amazon Transcribe 都是整条音频一次处理。Google 的同步识别器最长接收 60 秒,因此 17 条正式音频在静音处被切成不足 55 秒的片段,再把转写结果拼接起来;136 条对话音频则整条处理。Amazon Transcribe 要求音频按实时节奏输入,因此测试框架以四倍于实时的速度向它送入音频;下文的延迟数字因此是由送入速度决定的下限,而不是该服务本身的表现。
这不是什么。 测试用的是安静环境下的合成语音,而不是在车里用手机录的现场录音;只测了一天,每条音频只跑一次。这是在我们自己的翻译流程所使用的音频上、用我们的用户书写的语言所做的对比,并不是一份排行榜。
每种语言所有音频的平均 WER;每个引擎都为全部 153 条音频返回了转写结果。
| 语言 | 音频数 | Azure AI Speech | Google Chirp 3 | Amazon Transcribe |
|---|---|---|---|---|
| 阿拉伯语 | 13 | 32% | 46% | 26% |
| 中文 | 13 | 3% | 3% | 8% |
| 捷克语 | 1 | 1% | 2% | 3% |
| 荷兰语 | 1 | 2% | 2% | 3% |
| 英语 | 21 | 2% | 5% | 2% |
| 法语 | 13 | 5% | 11% | 12% |
| 德语 | 13 | 7% | 9% | 13% |
| 印地语 | 13 | 10% | 10% | 12% |
| 匈牙利语 | 1 | 9% | 7% | 8% |
| 意大利语 | 1 | 1% | 1% | 3% |
| 日语 | 13 | 6% | 5% | 5% |
| 韩语 | 1 | 9% | 11% | 11% |
| 波兰语 | 1 | 1% | 1% | 2% |
| 葡萄牙语(巴西) | 13 | 5% | 4% | 6% |
| 俄语 | 21 | 14% | 10% | 14% |
| 西班牙语 | 13 | 6% | 5% | 6% |
| 土耳其语 | 1 | 4% | 3% | 4% |
| 全部 153 条音频 | 153 | 9% | 10% | 10% |
| 仅对话回合 | 136 | 9% | 11% | 10% |
| 仅正式文本 | 17 | 4% | 5% | 5% |
| 处理时间 ÷ 音频时长 | 0.10 | 0.22 | 0.41(受送入速度限制) |
只有一条音频的语言(仅有正式文本)列出仅为完整起见;单条音频的数字只是一个数据点,不代表比率。
三个理由,按决定性的先后排列。
1. 默认网关是 Azure。 尚未选择网关的组织,其 AI 功能运行在 EU Data Zone 中的 Azure OpenAI 上,因此其语音消息由同一租户中的 Azure AI Speech 转写。没有额外的子处理方,也没有额外的区域。Microsoft 声明,Azure Speech 不会在 Speech 资源所在区域之外存储或处理数据(区域页面,2026 年 9 月核查);我们的资源位于 Sweden Central,该区域已列入快速转写支持的区域。
2. API 的形态适合语音消息。 InterMIND 中的一条语音消息最长可达十分钟(语音消息)。Azure 的快速转写在一次请求中接收整条录音。Google 的同步识别在 60 秒处截止,所以十分钟的语音消息需要通过存储桶做批量识别,或使用流式会话;Amazon Transcribe 支持流式处理,但接收的是 PCM、FLAC 或 Ogg-Opus,而不是手机和浏览器录制所用的格式,因此音频要先转码。这两个问题都能解决,测试框架就解决了它们,但每条语音消息的处理路径上都因此多出了更多环节。
3. 数据并不反对这个选择。 9% 对 10% 和 10%,这个测试集上没有任何引擎好到足以成为把语音消息移出默认网关的理由。如果 Google 或 Amazon 的错误率只有一半,本文会如实说明。
如果您的组织选择 Google Vertex AI 或 Amazon Bedrock 作为网关,您的 AI 功能就运行在那里。这些组织中的语音消息目前只以录音形式送达,没有转写文本:正如本文所示,我们已经测量了 Google Cloud Speech-to-Text 和 Amazon Transcribe,但尚未把它们接入产品。相关权限和集成代码已经具备;当它们进入每条语音消息的处理路径时,本文会随之更新。在此之前,Vertex AI 或 Bedrock 组织中的语音消息是一段可播放的录音;把网关切换到 Azure 的组织,从切换之后发送的语音消息起即可获得转写文本。
InterMIND 使用哪项语音转文字服务?
聊天中的语音消息使用 Azure AI Speech(快速转写 API),运行在 InterMIND 位于 Sweden Central 的自有 Azure 租户中,即默认 AI 网关的语音服务。会议中的实时语音是另一条路径:它运行在 InterMIND 自己的媒体引擎 Mind API 上,托管于法国的 OVH,不会接触任何云语音服务(一场会议在哪里运行)。
Azure AI Speech 比 Google Speech-to-Text 或 Amazon Transcribe 更准确吗?
在我们由 17 种语言的 153 条语音消息音频组成的测试集上,用同一个测试框架、在同一天测量,Azure AI Speech 的平均词错误率为 9%,Google Cloud Speech-to-Text(Chirp 3)为 10%,Amazon Transcribe 为 10%。按语言来看,顺序会变化:Azure 在法语、英语和中文上最低,Amazon Transcribe 在阿拉伯语上最低,Google 在俄语上最低。换一组录音,排名可能不同;上面的表格是我们这组数据的依据。
什么是词错误率,这里是如何计算的?
词错误率是被替换、插入和删除的词数,除以参考文本中的词数。比较之前,我们会统一大小写、标点和空白;中文和日语按字符比较,因为这些文字不以空格分词。9% 的错误率意味着大约每 11 个词中有一个与参考文本不同。
语音消息的音频会离开欧盟吗?
不会。录音存储在 InterMIND 位于欧盟的对象存储中,转写它的语音服务运行在欧盟区域:Azure 上是 Sweden Central,Google Cloud 上是 eu 多区域,AWS 上是法兰克福。完整的相关方与区域清单见子处理方页面和信任中心页面。
为什么不在应用中于客户端识别语音,让音频不离开手机?
我们也测量过,时间是 2026 年 9 月。启用本地处理的 Chrome 内置识别器,在各产品语言的 17 条正式音频中一条也没有识别出来,而且客户端识别器的语言覆盖范围远比上表中的 17 种语言狭窄。随着各平台的改进,客户端识别是我们会继续重新测量的方向;就目前而言,能为每位成员、每种语言都奏效的是网关这条路径。
我们的组织可以选择由哪项语音服务来转写语音消息吗?
不能单独选择:组织管理员在"集成"页面选择的是 AI 网关。在默认网关上,语音消息由 Azure AI Speech 转写。在 Vertex AI 和 Amazon Bedrock 上,语音消息暂不转写,见上文相关章节。
语音消息最长可以多长,API 有限制吗?
最长十分钟。Azure 的快速转写在一次请求中接收最长 5 小时、500 MB 的文件,因此一条语音消息只需一次调用即可转写。Google 的同步识别接收 60 秒和 10 MB,这就是测试框架要在静音处把较长音频切成片段的原因。
为什么要告诉识别器说话人的语言,而不是让它自行检测?
因为语音消息很短。在一条四秒的音频上,自动语言识别可能返回错误的语言:一条俄语测试语音就被识别成了英语;而成员的个人资料语言几乎每次都是对的。识别器会得到该语言;只有在语言未知时,才会得到房间内的各种语言作为候选。
会议音频是由同一项服务转写的吗?
不是。会议中的实时语音由 InterMIND 自己的引擎(Mind API)识别并翻译,运行在承载通话的媒体服务器上,托管于法国的 OVH,见一场会议在哪里运行。云网关看到的是文字,绝不会看到通话的音频(在您自己的网关上运行会议 AI)。
你们会再次发布结果吗?
测试框架只需一条命令即可运行,每个引擎的权限也都已就位,因此当供应商推出新模型时,可以重新测量这张表。当结果改变了整体格局时,本文会更新并标注日期。
资料来源:Microsoft:Azure AI Speech 快速转写(learn.microsoft.com)和 Speech 区域表(learn.microsoft.com);Google Cloud:Chirp 3 模型(docs.cloud.google.com)、同步识别限制(docs.cloud.google.com)和支持的语言(docs.cloud.google.com);AWS:Amazon Transcribe 流式处理(docs.aws.amazon.com)、端点与配额(docs.aws.amazon.com)和支持的语言(docs.aws.amazon.com);均于 2026 年 9 月核查。测量:InterMIND 语音基准测试,2026-09-16,153 条音频,17 种语言。
只为实际使用的成员付费:InterMIND 改为按活跃成员计费
Pro 和 Business 不再销售需要手动分配的席位。您可以邀请整个团队;每次续订时,系统会统计过去 28 天内活跃的成员,并仅按这一人数计费。长期未活动的成员保留访问权限,且不产生任何费用;会议访客和外部频道参与者始终免费。本文介绍如何界定“活跃”、计费周期内人数如何变化、续订前通知函的内容,以及您的账单页面将发生哪些变化。
在会议中主动行动的 AI 会议助手:Teams Facilitator、Zoom AI Companion、Google Meet Gemini 与 InterMIND 在会议现场做什么(2026)
AI 记录工具在通话结束后撰写纪要,而 AI 会议助手在会议进行中就开始工作:提醒与会者上次的决定,在承诺被说出的那一刻就记录下来,在主持人提出要求时安排后续会议,并在会议结束前提出下一步建议。本文依据各厂商的官方文档,介绍 Microsoft Teams(Facilitator)、Zoom(AI Companion、ZoomMate)、Google Meet(Ask Gemini、后续步骤)和 InterMIND(Mia)中的具体表现,并附有与 AI 参与者共同开会的操作指南。
