👁 83 次阅读
一、先搞清楚它是什么：不是 ChatGPT 语音，是独立的语音转文本模型
2026年8月26日，Google 在官方博客发布了 Gemini 3.5 Transcribe，定位是『迄今最精准的语音转文本模型』，同时进入 Google AI Studio、Gemini API 和 Gemini Enterprise Agent Platform 的公开预览。它不是 Gemini App 里的语音对话能力，而是一个模型 ID 明确的独立 ASR 模型，有两个型号：
gemini-3.5-transcribe：离线录音转文本，走 Interactions API，支持说话人标注和词级时间戳gemini-3.5-transcribe-live：实时流式转文本，走 Live API over WebSocket
官方给出的核心能力有六项：85+ 种语言自动检测（支持句中和句间的跨语言切换）、自定义词表（最多 1000 条术语）、说话人区分（最多 8 人，3 人及以上的归因标注属于实验性功能）、词级时间戳、智能转录（清理『嗯啊』类填充词并重新排版）、以及大小写标点与逆文本归一化（例如把 twenty six million dollars 自动转为 $26M）。
为什么值得花篇幅讲它？语音转文本这件事已经做了很多年，但『转出来的东西能直接用』这一步长期没解决：转写稿里塞满嗯呃、『我是说』，自己说错了话也不会自动纠正，标点全靠猜。Gemini 3.5 Transcribe 把这条路拆成两种模式：verbatim 保留原样，smart 负责清理。
官方给的 smart 模式示例：音频说 Um, so for the meeting, I think we should, uh, invite Alice and, wait no, Bob and Carol. ，verbatim 输出保留全部填充词与犹豫，smart 输出直接变成 For the meeting, I think we should invite Bob and Carol. 。再比如散乱的会议要点 First item review budget second item finalize timeline third item send recap，smart 会输出成 1/2/3 的列表。
精度与速度的官方数据（来自 Ars Technica 报道）
Ars Technica 在报道中引用的数字：新版比前代引擎 Chirp 3 从语音到最终成稿大约快 70%；实时语音识别错误率降到 5.5%，Chirp 3 是 7.32%。
| 指标 | Chirp 3（前代） | Gemini 3.5 Transcribe | 出处 |
|---|---|---|---|
| 实时识别错误率（WER） | 7.32% | 5.5% | Ars Technica |
| 语音到成稿速度 | 基准 | 约快 70% | Ars Technica |
| 支持语言数 | — | 85+ 种（自动检测） | 官方博客 |
要提醒一点：5.5% 的实时错误率，在中文口语、专业术语、多人同时说话的场景里仍会出错。官方也明确说了 smart 模式会改变你原话的措辞，所以法律口供、医疗病历、法庭记录这类必须逐字留存的场景，一定用 verbatim。另外 smart 与时间戳、说话人标注互斥——这条限制直接决定了后面第三步的选题范围。
二、第一步：拿到 API Key 并跑出第一段转写
官方推荐入口是 Google AI Studio。整个接入有三件事：申请密钥、上传音频、调用模型。注意音频要先走 Files API 上传再传 URI，不能直接内联 base64。
from google import genai
client = genai.Client()
audio_file = client.files.upload(file="path/to/sample.mp3")
interaction = client.interactions.create(
model="gemini-3.5-transcribe",
input=[
{
"type": "audio",
"uri": audio_file.uri,
"mime_type": audio_file.mime_type,
}
],
)
print(interaction.output_text)纯 REST 写法（不用 SDK），先通过 Files API 上传拿到文件 URI，再传给模型：
curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
-H "x-goog-api-key: *** \
-H "Content-Type: application/json" \
-d '{"model": "gemini-3.5-transcribe", "input": [{"type": "audio", "uri": "YOUR_FILE_URI", "mime_type": "audio/mp3"}]}'
这一步跑通之后，你就有了最短的可用管线。接下来所有进阶都在这 10 行代码上加分支。
三、第二步：两种转录模式到底选哪个
这是整篇教程里最影响产出的一个决策点，两个模式都在 generation_config.transcription_config.mode 里配置。
verbatim：默认值，逐字保留
完整保留一切：填充词（um、uh、like、you know）、重复、停顿、说一半又改口的部分。需要原文存档时用这个。
smart：智能整理，面向阅读
官方文档把它拆成三项处理：去填充词与口吃；行内自我纠正（把『周二，其实不是，周三两点』直接改成『周三下午2点』）；结构化排版（把散乱的口语要点排成编号列表）。
官方原文的两个对比示例：
| 原始音频 | verbatim 输出 | smart 输出 |
|---|---|---|
| Um, so for the meeting, I think we should, uh, invite Alice and, wait no, Bob and Carol. | Um so for the meeting I think we should uh invite Alice and wait no Bob and Carol. | For the meeting, I think we should invite Bob and Carol. |
| First item review budget second item finalize timeline third item send recap | first item review budget second item finalize timeline third item send recap | 1. Review budget 2. Finalize timeline 3. Send recap |
参数互斥矩阵：这张表决定了你不会白调一次 API
官方在 Parameter reference 和 Limitations 两节里明确了三组互斥关系，混用会被 API 直接拒绝：
| 特性 | verbatim | smart | 说明 |
|---|---|---|---|
| 自定义词表 custom_vocabulary | 可用 | 可用 | 最多 1000 条，官方建议 100 条以内效果最好 |
| 说话人标注 diarization_mode | 可用 | 不支持 | 最多 8 人，3 人及以上为实验功能 |
| 词级时间戳 timestamp_granularities | 可用 | 不支持 | Live API 侧只支持语句级时间戳 |
这里有一个真实的取舍：客服质检既要可读，又要知道是谁在哪一秒说的。但官方设计里，能给你说话人标签的模式（verbatim）输出的是未整理的原文，能整理的模式（smart）拿不到说话人信息。所以正确做法是走 verbatim + diarization_mode 拿标签，再用脚本清理填充词，别指望一个模式解决全部。
# verbatim + 说话人标注 + 词级时间戳
interaction = client.interactions.create(
model="gemini-3.5-transcribe",
input=[{"type": "audio", "uri": audio_file.uri, "mime_type": audio_file.mime_type}],
generation_config={
"transcription_config": {
"mode": {
"type": "verbatim",
"diarization_mode": "speaker",
"timestamp_granularities": ["word"],
}
}
},
)
# 智能整理模式
interaction = client.interactions.create(
model="gemini-3.5-transcribe",
input=[{"type": "audio", "uri": audio_file.uri, "mime_type": audio_file.mime_type}],
generation_config={
"transcription_config": {"mode": "smart"}
},
)时长上限：开了功能反而变短
官方 Limitations 写明：普通单请求音频最长 1 小时；一旦启用说话人标注或词级时间戳，上限降到 30 分钟。做长会议转写时，要么本地切段，要么放弃时间戳/说话人功能换全长。
词表上限的实用建议
官方写的是最多 1000 条，但同时写了最佳效果通常在 100 条以内。客服和会议场景的正确做法是只放专有名词、品牌名、缩写字，别塞常见词——官方 Best practices 明确说只放领域术语、品牌、专名，不要放日常词。
四、第三步：音频格式与语言参数
官方文档列了 13 种 MIME 类型，覆盖了常见录音场景：
| 类别 | MIME 类型 |
|---|---|
| 常见音频 | audio/wav、audio/mp3、audio/m4a、audio/aac、audio/ogg、audio/flac、audio/mpeg、audio/webm |
| 无损与专业 | audio/aiff、audio/l16 |
| 电话语音 | audio/alaw、audio/mulaw（G.711 A-law / μ-law，呼叫中心录音常见） |
| 低带宽实时 | audio/opus（WebRTC / 会议工具常用） |
关于格式有一个容易踩的坑：很多会议工具的原始导出是 Opus 或 ALAW，很多人第一反应是转成 MP3 再上传。其实这些格式官方都直接支持，转码只会多花 CPU 和一次质量损失，没必要。
语言参数的两种用法
官方写法：language_codes 传空数组或不传，模型自动检测语言，并支持句中跨语言切换；如果你确定语种，传 BCP-47 代码能提高准确率。
# 自动检测（不传或空数组）
"transcription_config": {"language_codes": []}
# 指定语种（中文场景）
"transcription_config": {"language_codes": ["zh-CN"]}中文用户建议明确传 zh-CN，别依赖自动检测——自动检测虽然官方号称支持 85+ 种，但在中英混说且混说得比较乱的场景里，指定语种通常更稳。
五、第四步：Live API 做实时转写，三种 VAD 策略怎么选
需要实时字幕、语音助手、直播场景时，用 gemini-3.5-transcribe-live 走 Live API。它和 Conversational Live Agent 共用 WebSocket 双向流，但角色完全不同。
| 特性 | Live Agent | Live Transcription |
|---|---|---|
| 主要角色 | 会听、会推理、会回话的对话助手 | 实时语音转文本管线 |
| 响应模态 | 语音和文本 | 流式文本转写 |
| 交互方式 | 轮流对话，有停顿检测和打断 | 边说边持续处理 |
| 支持特性 | Function calling、Google Search、系统指令 | 词表偏置、语言检测、手动/混合 VAD、智能转录 |
| 输入流 | 多模态：音频、视频、图像、文本 | 仅音频（原始 16-bit PCM） |
Python 最短接入：
import asyncio
from google import genai
from google.genai import types
client = genai.Client()
model = "gemini-3.5-transcribe-live"
config = types.LiveConnectConfig(
response_modalities=["TEXT"],
input_audio_transcription=types.AudioTranscriptionConfig(
language_codes=[], # 自动检测语言
),
)
async def main():
async with client.aio.live.connect(model=model, config=config) as session:
print("Session established with Live Transcription")
async for response in session.receive():
server_content = response.server_content
if server_content and server_content.input_transcription:
print("Transcript:", server_content.input_transcription.text)
if __name__ == "__main__":
asyncio.run(main())WebSocket 直连写法：
const API_KEY = "YOUR_API_KEY";
const MODEL_NAME = "gemini-3.5-transcribe-live";
const WS_URL = `wss://generativelanguage.googleapis.com/ws/google.ai.generativelanguage.v1beta.GenerativeService.BidiGenerateContent?key=${API_KEY}`;
const websocket = new WebSocket(WS_URL);
websocket.onopen = () => {
websocket.send(JSON.stringify({
setup: {
model: `models/${MODEL_NAME}`,
generationConfig: { responseModalities: ['TEXT'] },
inputAudioTranscription: { languageCodes: [] }
}
}));
};
三种 VAD 策略
VAD（Voice Activity Detection）决定什么时候算『说完了一句』。官方给了三档：
| 策略 | 机制 | 适用场景 |
|---|---|---|
| 自动 VAD（默认） | 服务器端检测说话的起止 | 大多数场景，无需配置 |
| 混合 VAD | 服务器端自动检测说话起点（带前缀音频填充，避免首字被截断）+ 客户端检测静音后发 audio_stream_end 立刻定稿 | 对延迟敏感、需要零延迟定稿的场景 |
| 手动 VAD（推键） | 禁用自动 VAD，用 activity_start / activity_end 显式控制边界 | 对讲机、直播字幕按钮 |
混合 VAD 的四个步骤（官方原文描述）：1) 服务器端自动 VAD 检测说话起点，带前缀音频填充防止首字丢失；2) 客户端本地 VAD 检测到说话停止时立即发 audio_stream_end；3) 服务器把这个信号当作立即定稿的提示，跳过默认的服务端静音等待时间；4) 客户端 VAD 失效时服务端 VAD 作为兜底。
注意：Live API 不支持词级时间戳，只发语句级时间戳（interim_input_transcription 和 input_transcription 字段）。要词级时间戳必须走离线路径。
六、能力边界速查表：一次看全
| 维度 | 具体规格 | 注意 |
|---|---|---|
| 支持语言 | 85+ 种，支持句中跨语言切换 | 明确语种时传 language_codes 更稳 |
| 说话人标注 | 最多 8 人，3 人及以上为实验功能 | 仅 verbatim 模式可用 |
| 词级时间戳 | 仅离线 API 支持，Live API 只有语句级 | 开启后时长上限从 1 小时降到 30 分钟 |
| 自定义词表 | 最多 1000 条，100 条以内效果最好 | 与说话人标注、词级时间戳互斥 |
| 智能转录 | 去填充词、自我纠正、结构化排版 | 会改变原措辞，不可用于原文留存场景 |
| 音频时长 | 普通 1 小时；开启说话人/时间戳后 30 分钟 | 长会议需切段 |
| 音频格式 | 13 种 MIME（含 ALAW/MULAW 电话录音） | 不必强制转 MP3 |
| Flex / Priority 推理 | 不支持 | 模型页明确标注 Not supported |
七、成本怎么算：一分钟录音到底多少钱
官方定价页对 Transcribe 有两个计费口径：按 token 和按分钟，按分钟口径更适合直觉计算。
| 计费口径 | 价格 | 说明 |
|---|---|---|
| 音频输入 | 2.00 美元 / 百万 token 或 0.003 美元 / 分钟 | 25 音频 token / 秒 |
| 文本输出 | 12.00 美元 / 百万 token 或 0.002 美元 / 分钟 | 175 文本 token / 分钟 |
| 混合折算 | 约 0.005 美元 / 分钟 | 官方标注为混合费率估算 |
| Live Transcribe 混合折算 | 约 0.009 美元 / 分钟 | 实时流的混合费率 |
| 免费层 | 不收费 | 输入输出均为免费额度 |
按 0.005 美元/分钟折算，10 小时会议录音约 3 美元；按 0.009 折算的实时场景，10 小时约 5.4 美元。如果批量处理，Batch API 有 50% 折扣，但要确认对应计费口径是否可叠加——官方定价页列的 Batch 折扣适用于文本模型口径，Transcribe 模型建议直接按分钟口径测算。
一个容易被忽略的条款
定价页 Used to improve our products 这一列，免费层是 Yes，付费层是 No。也就是说免费层默认允许 Google 用你的内容改进产品。企业敏感录音（客户数据、内部会议）请走付费层，或者在接入前核对 Terms 的原文。
八、四个真实场景的参数组合
| 场景 | 模型 | 推荐参数 | 说明 |
|---|---|---|---|
| 客服录音质检 | 离线 | mode=verbatim + diarization_mode=speaker + timestamp_granularities=[word] + language_codes=[zh-CN] | 必须原文 + 要知道谁在哪一秒说；注意 30 分钟上限 |
| 播客字幕制作 | 离线 | mode=verbatim + timestamp_granularities=[word]，再用后处理清理填充词 | smart 与时间戳互斥，所以走 verbatim 再加清洗脚本 |
| 实时直播字幕 | Live | response_modalities=[TEXT] + 自动 VAD | WebSocket 流式，输出 interim + final 两类转写 |
| 会议纪要生成 | 离线 | mode=smart + custom_vocabulary（放公司术语、人名、产品名） | 输出可直接交付，但要接受措辞被改写 |
九、上手决策树
需要原文存档？
→ 是 → verbatim
→ 需要知道谁说的？ → + diarization_mode="speaker"（≤30 分钟）
→ 需要精确到词？ → + timestamp_granularities=["word"]（≤30 分钟）
→ 术语多？ → + custom_vocabulary（100 条以内，与上两项互斥）
→ 否 → smart（自动整理，无法拿到说话人和词级时间戳）
需要实时字幕？
→ Live API + gemini-3.5-transcribe-live
→ VAD 策略：默认自动 / 混合（低延迟） / 手动（对讲机）
→ 注意：只有语句级时间戳，没有词级三个最容易踩的坑
- 把 smart 和 diarization_mode 同时传进去——会被 API 直接拒绝，官方 Limitations 里明写了这组互斥。
把 custom_vocabulary 和时间戳同时传——同样互斥，官方原文：API 会拒绝同时指定这两项的请求。
以为 smart 输出可以逐字引用——官方明确说它会改变原话措辞，法务/医疗/庭审场景必须回退到 verbatim。
十、总结：一句话记忆点
Gemini 3.5 Transcribe 的核心卖点是把『语音转文本』和『文本后处理』合在一个模型里做了两档：verbatim 留原文，smart 出成品。代价是这两档互斥于说话人标注和词级时间戳，且开启后时长上限减半。
接入路径只有三步：申请密钥 → 上传音频拿 URI → 读 output_text。进阶参数只有五个：language_codes、custom_vocabulary、mode（verbatim/smart）、diarization_mode、timestamp_granularities。参数怎么组合，看上面那张互斥矩阵就够了。
最后提醒一次数据来源：官方博客与 Google AI for Developers 文档是能力、参数、限制、定价的权威来源；精度与速度的对比数字来自 Ars Technica 的独立报道。
参考来源：
1. Google 官方博客《Introducing Gemini 3.5 Transcribe》：https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe
2. Google AI for Developers《Audio transcription – Interactions API》：https://ai.google.dev/gemini-api/docs/transcribe
3. Google AI for Developers《Live transcription with Gemini Live API》：https://ai.google.dev/gemini-api/docs/live-api/live-transcribe
4. Google AI for Developers《Gemini Developer API pricing》：https://ai.google.dev/gemini-api/docs/pricing
5. Ars Technica《Google announces Gemini 3.5 Transcribe for AI-powered speech-to-text》：https://arstechnica.com/ai/2026/08/google-announces-gemini-3-5-transcribe-for-ai-powered-speech-to-text
注：Google 官方文档 Last updated 2026-09-23（转写文档）/ 2026-08-26（Live 转写文档），文中数字以官方当日发布为准，可能随版本更新变化。