Azure AI Speech 对比 Google Chirp 3 与 Amazon Transcribe：基于 153 条语音笔记的评测，以及 InterMIND 为何在贵组织的自有云网关上运行语音转文字（2026）
InterMIND 频道中的一条语音笔记会变成一条文本消息，每位团队成员都能以自己的语言阅读。其第一步是语音转文字，而 IT 和合规审核人员向我们提出的问题不是“它的准确率有多高”，而是“这是谁的服务，音频会发往哪里”。
简短的回答：Azure AI Speech，即默认 AI 网关的语音服务，运行在 InterMIND 位于 Sweden Central 的自有 Azure 租户中——而组织可以选择的另外两个网关的语音服务，在同一组音频片段上进行了测量，因此选择基于数据，而非偏好。本文展示了该选择背后的数据——在同一天，通过 Azure AI Speech、Google Cloud Speech-to-Text 和 Amazon Transcribe 处理相同的 153 个片段——以及关于每个 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 的方式，测试也以相同方式调用另外两个服务。