当你能熟练调用 AI 接口处理文本以后再回头看音视频数据会有一个很直观的感受它仍然是最难处理的“非结构化数据”。文本可以随便切、随便拼但音频一旦牵涉到说话人、口音、背景噪声、多种语言混用整个转录流程就会变得异常复杂。Gemini 3.5 Transcribe 发布的信息里最值得关注的一个关键词就是“多语言转录”。这个能力看起来没有聊天机器人那么炫却切中了大量音视频业务团队的痛点。这里先给一个明确判断Gemini 3.5 Transcribe 的价值不在“又多了一个语音识别引擎”而在于它把语音识别、语言判断、上下文理解放在了同一条模型链路里让开发者不再需要手工组装三套工具。本文会从问题背景、核心概念、环境准备、代码接入、结果验证、常见排错和工程建议几个维度展开。如果你正在做会议纪要、字幕生成、客服质检、播客内容结构化这篇文章会直接给你一条可以落地的接入路径。1. 为什么多语言转录值得重新做一遍很多人对“转录”有一个误会以为转录就等于语音识别。在单语场景下这种理解问题不大但一旦进入多语言场景转录任务的复杂度就不再是“把声音变成文字”这么简单了。一个最常见的场景是跨国会议老板用中文发言同事用英文回应中间偶尔还会冒出一个日语产品名。传统 ASR 不管配置成中文还是英文都会在语言切换的位置出问题。结果是本该生成一段干净纪要的音频最后得到一段夹杂大量错别字、连人名和专有名词都拼不对的文本。过去解决这个问题业界常规做法是三步走先用语音识别引擎把音频转成文本这一步通常只能按一种主语言识别。再对识别结果做语言检测判断哪一段是中文、哪一段是英文。如果业务要求统一语言还要把文本再交给翻译服务。这条链路不是不能用但它有一个天生的毛病每一步都可能出错而错误会沿着链路不断叠加。比如语音识别的断句边界可能跟翻译模型的断句边界不一致最后不仅语言标记是乱的连字幕时间轴都会整体偏移。Gemini 3.5 Transcribe 真正有吸引力的地方就在这里它把“识别出说了什么、判断是哪一种语言、理解上下文语义”放在同一个模型链路里完成。从工程角度看这是把三个服务变成一个模型调用省掉的不只是代码量更是整套链路的调试成本。所以我的判断是Gemini 3.5 Transcribe 不是单纯追赶“识别率”的升级而是把多语言转录从“拼装流水线”变成“原生能力”。如果你之前被多语言识别问题折磨过这个变化值得认真评估。2. 多语言转录的核心概念与适用场景2.1 转录、语音识别和多语言转录到底有什么区别先把概念边界说清楚。语音识别ASRAutomatic Speech Recognition通常指“音频到文本”的转换核心评价指标是字错误率。它关心的是“每个字是不是听对了”。转录Transcribe是一个更宽泛的概念包含语音识别但还会涉及说话人区分、标点恢复、语言标记、文本规范化、时间戳对齐等。也就是说转录不仅要知道“说了什么”还要知道“谁说的、怎么说、什么时候说的”。多语言转录则是在转录的基础上额外增加了一项能力识别文本中的多种语言并准确标注。真正的难点不是“模型认识几种语言”而是“模型能不能在同一个音频里准确判断语言切换点”。举个例子一段音频是这样的0.0 到 3.0 秒中文3.0 到 6.5 秒英文6.5 到 8.0 秒中文如果模型判断语言切换点偏了 0.5 秒或者把英文内容按中文发音去解码转录结果就会连续出错。所以这里真正考验的是模型对语言边界的感知能力而不只是词汇量大小。2.2 什么样的项目真正需要多语言转录不是所有音视频项目都需要多语言转录但以下几类场景会非常依赖它。场景原来的痛点多语言转录带来的变化跨国会议纪要中英混合发言被当成单语识别结果大量乱码直接标出每段语言纪要可直接归档分享海外客服质检客户讲中文客服讲英文质检系统无法自动理解按语言区分对话双方再统一做质检规则匹配播客和视频字幕嘉宾来自不同国家制作字幕要手动切语言输出带时间戳的转录文本字幕生成效率大幅提升音视频内容搜索转录文本如果不准确用户搜不到关键内容语言标注准确后可以按“语言 关键词”过滤翻译转写流水线先识别再翻译断句不一致导致翻译质量下降一次转录拿到带语义上下文的长段落翻译更连贯如果你的业务只是“单语种录音转文字”比如一个纯中文访谈那用传统 ASR 可能更简单没必要引入大模型转录。但凡是数据里已经有中英混合、粤普混合、中英日专有名词混用多语言转录就是刚需。2.3 Gemini 3.5 Transcribe 与普通 ASR 的差异用大白话说普通 ASR 的目标是“听见”Gemini 3.5 Transcribe 的目标是“听懂之后把语言理清楚”。这里有一个容易被忽视的技术背景传统 ASR 是典型的“声学模型 语言模型”架构输出文本通常只有一个主语言。例如你部署一个中文识别模型它在遇到英文句子时会把英文单词近似成中文发音去解码部署一个英文识别模型又会出现相反的问题。Gemini 3.5 Transcribe 如果按照多语言转录的产品定位去理解它更接近大模型直接对音频 token 做多语言解码。这种架构的变化使得它不需要你在调用前硬性指定主语言而是可以在同一段音频里动态判断每一句该用哪种语言解释。从原理上讲这种能力来自大规模多语言语料训练。它不只是认识中文、英文各自长得什么样还知道这两种语言在同一个上下文里如何交替出现。这是传统 ASR 很难做到的。3. 环境准备与前置条件在写代码之前先把环境准备好。这里以 Python 为例因为 Python 在音视频处理和 AI 接口调用场景下生态最完整。3.1 运行环境操作系统Windows 10/11、macOS 或 Linux 均可。Python 版本建议 Python 3.9 或更高版本。包管理工具推荐使用 pip 和 venv。网络要求可以正常访问 AI 服务的 API 地址。如果你还没有创建项目目录可以先执行下面两条命令mkdir gemini-transcribe-demo cd gemini-transcribe-demo python -m venv venv激活虚拟环境# Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate3.2 安装依赖下面是我的建议依赖清单。注意版本号是演示用参考值实际安装时请以官方最新文档为准不需要完全照抄。# 项目路径requirements.txt # 版本号是演示参考值实际以官方最新文档为准 google-genai0.5.0 python-dotenv1.0.0安装命令pip install -r requirements.txtpython-dotenv是用来读取.env环境变量的主要作用是避免把 API Key 硬编码在代码里。这是一个工程好习惯也方便在部署时统一管理密钥。3.3 准备 API 密钥调用 Gemini 3.5 Transcribe 接口需要有效的 API Key。操作路径通常是登录 AI 服务控制台创建或选择一个项目然后在 API Key 管理页面生成新的密钥。把密钥写在.env文件里# 项目路径.env GEMINI_API_KEY你的API密钥 GEMINI_ENDPOINThttps://generativelanguage.googleapis.com这里要特别提醒.env文件一定不要提交到 Git 仓库。建议在.gitignore中加上.env。下面是一条基本的安全清单不要在前端 HTML、JavaScript 或移动端代码里直接暴露 API Key。不要把 API Key 写在博客示例代码的字符串常量里。如果担心密钥泄露尽快在控制台撤销并重新生成。在服务端环境变量或密钥管理服务中保存密钥。对密钥规划好权限只授予这个项目需要的最小范围。4. 核心流程拆解接入 Gemini 3.5 Transcribe 的核心流程可以拆成六步读取本地音频文件。把音频内容编码后放到请求中。调用 Gemini 3.5 Transcribe 模型。解析返回的转录文本。写入 SRT 字幕或 JSON 结构。对结果做质量检查。下面逐个说清楚。4.1 读取音频文件音频文件可能是mp3、wav、m4a、flac等格式。不同模型支持的音频格式会有差异建议在请求前确认格式必要时先用ffmpeg转成 wav 或 mp3。比如ffmpeg -i input.m4a -ar 16000 -ac 1 output.wav这里把音频转换成 16kHz 采样率、单声道能显著减小文件体积同时降低传输耗时。对语音识别类任务来说16kHz 单声道已经能覆盖绝大多数语音内容。4.2 构建请求内容大多数生成式 AI 接口都支持多模态输入音频可以作为“内联数据”直接传给模型。需要注意音频文件如果太大单次请求会超时。一般建议把单次请求的音频控制在几十秒到几分钟以内长音频需要分段处理。4.3 调用与解析调用 Gemini 模型时建议把 temperature 设为 0。转录任务属于事实提取类任务不需要创造性输出温度越低越不容易产生幻觉也越能保持原文内容稳定。如果你发现转录结果里出现带有主观色彩的改写大概率是温度设置的问题。4.4 输出结构化多语言转录落地时最有用的是结构化输出。建议在 prompt 里明确要求模型返回 JSON包含start、end、language、text四个字段。这样后续生成字幕、做关键词匹配、按语言过滤都会非常方便。5. Gemini 3.5 Transcribe 完整示例代码实现下面是一套可以直接运行的完整示例代码。代码里的模型 ID 以官方最新文档为准在当前发布信息中模型名称为gemini-3.5-transcribe。5.1 音频转录示例# 项目路径transcribe_demo.py import os import json from pathlib import Path from dotenv import load_dotenv from google import genai from google.genai import types # 读取 .env 环境变量 load_dotenv() client genai.Client( api_keyos.getenv(GEMINI_API_KEY), endpointos.getenv(GEMINI_ENDPOINT, https://generativelanguage.googleapis.com), ) PROMPT 请对这段音频进行多语言转录。 要求 1. 识别并保留原始语言不要翻译。 2. 当同一段音频出现多种语言时按说话片段标注语言代码如 zh、en、ja。 3. 输出严格的 JSON 数组不要输出其他解释文字。 4. 格式如下 [ { start: 0.0, end: 3.2, language: zh, text: 识别出的文本 } ] def transcribe_audio(audio_path: str) - str: audio_file Path(audio_path) if not audio_file.exists(): raise FileNotFoundError(f音频文件不存在: {audio_path}) # 读取音频文件字节 audio_bytes audio_file.read_bytes() # 构建多模态请求 response client.models.generate_content( modelgemini-3.5-transcribe, contents[ PROMPT, types.Part.from_bytes( dataaudio_bytes, mime_typeaudio/mpeg, ), ], configtypes.GenerateContentConfig( temperature0.0, ), ) return response.text def save_srt(transcript_json: str, output_path: str) - None: 把 JSON 格式的转录结果转换为 SRT 字幕文件。 segments json.loads(transcript_json) srt_lines [] for index, seg in enumerate(segments, start1): start format_srt_time(seg[start]) end format_srt_time(seg[end]) text f[{seg[language]}] {seg[text]} srt_lines.append(f{index}\n{start} -- {end}\n{text}\n) Path(output_path).write_text(\n.join(srt_lines), encodingutf-8) def format_srt_time(seconds: float) - str: 把秒数转换为 SRT 字幕时间格式。 ms int((seconds - int(seconds)) * 1000) h, remain divmod(int(seconds), 3600) m, s divmod(remain, 60) return f{h:02d}:{m:02d}:{s:02d},{ms:03d} if __name__ __main__: result transcribe_audio(sample_meeting.mp3) print(result) save_srt(result, sample_meeting.srt)这段代码的逻辑分成三块transcribe_audio读取音频并调用 Gemini 3.5 Transcribe 模型。save_srt把返回的 JSON 转录结果转成 SRT 字幕。format_srt_time把3.2秒这样的浮点数转成00:00:03,200字幕格式。跑起来之前先在项目目录放一个测试音频文件比如sample_meeting.mp3。然后执行python transcribe_demo.py如果一切正常终端会打印出 JSON 数组同时项目目录下会生成sample_meeting.srt文件。5.2 使用 curl 调用接口如果你不想用 Python也可以用 curl 直接调用。把音频文件转成 Base64 编码后放到请求体里。注意下面的接口路径需要以官方文档为准。curl -X POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-transcribe:generateContent \ -H Content-Type: application/json \ -H x-goog-api-key: $GEMINI_API_KEY \ -d { contents: [ { role: user, parts: [ { text: 请对这段音频进行多语言转录并标注每段语言代码。 }, { inline_data: { mime_type: audio/mpeg, data: BASE64_AUDIO_DATA } } ] } ], generationConfig: { temperature: 0.0 } }生成 Base64 音频数据可以用这条命令base64 -i sample_meeting.mp3 | tr -d \n但在真实项目中我更推荐用 Python SDK。原因有三个Python SDK 会处理请求细节出错信息更容易排查。长音频切分、重试、并发都要写代码只靠 curl 难以维护。后续接字幕生成、内容结构化还需要 JSON 解析Python 更方便。5.3 长音频分段处理示例Gemini 3.5 Transcribe 如果同时限制单次请求的音频时长就需要对长音频做分段。下面是一个伪代码级的处理框架你可以按实际项目调整。# 项目路径batch_transcribe.py from pathlib import Path from transcribe_demo import transcribe_audio, save_srt # 伪代码根据实际音频工具实现分段逻辑 def split_audio_segments(audio_path: str, segment_seconds: int 60): 把音频按固定秒数切分返回每段临时文件的路径。 # 在实现中你可以用 ffmpeg 命令行完成 # ffmpeg -i audio.mp3 -f segment -segment_time 60 -c copy segment_%03d.mp3 pass def transcribe_long_audio(audio_path: str): segments split_audio_segments(audio_path) all_results [] for segment_file in segments: result transcribe_audio(segment_file) all_results.append(result) # 假设每段结果都是 JSON 数组这里做简单拼接 import json merged [] for result in all_results: merged.extend(json.loads(result)) save_srt(json.dumps(merged, ensure_asciiFalse), long_audio.srt) return merged分段有一个关键点如果音频断句可能跨片段最好在每段之间保留 1 到 2 秒重叠切分时不要切在说话中间。比较稳妥的方案是先用简单的静音检测找分段点再按分段点从原文件截取而不是盲目按固定秒数切。固定 60 秒切分的方案适合已经录制好的、节奏稳定的音频比如播客、课程。如果是对讲类音频分段则可能把一句完整的话截成两半导致转录质量下降。这一点需要在实际项目里做针对性测试。5.4 输出格式与 prompt 设计上面代码里我用了很长一段 prompt 来要求 JSON 结构化输出。这里有一个实践经验转录模型的 prompt 越具体输出越稳定。尤其是“不要输出其他解释文字”这句能有效避免模型在 JSON 前后加多余说明。如果你的业务里需要多语言统一翻译可以把 prompt 改成“将英文部分翻译为中文只保留中文输出”。如果你想保留原文就让模型按语言输出。这个选择会直接影响下游使用建议在上线前就跟业务方确认清楚。6. 运行结果与效果验证6.1 预期输出假设测试音频里是一段中英混合对话转录结果的 JSON 可能长这样[ { start: 0.0, end: 3.2, language: zh, text: 各位好今天我们主要讨论一下海外市场的上线计划。 }, { start: 3.2, end: 7.1, language: en, text: Sure. Lets share the launch timeline with everyone. }, { start: 7.1, end: 9.8, language: zh, text: 好的那就先从时间线开始。 } ]注意这不是我声称的一定会出现的输出而是一个结构示例。实际结果会因音频质量、说话人口音、文件格式和模型版本而不同。关键验证点有两个语言代码是否正确。中英混合音频应该能准确标出zh和en。时间戳是否对齐。播放音频时字幕出现的时机应与说话内容基本吻合。6.2 用代码验证时间戳对齐如果你生成了一堆转录结果想批量检查时间戳是否合理可以用下面这个方法# 校验时间戳是否单调递增 def validate_segments(segments): previous_end 0.0 for seg in segments: if seg[start] previous_end - 0.5: return False, f时间戳重叠: {seg} previous_end seg[end] return True, 时间戳校验通过时间戳重叠超过一定阈值通常是分段或模型输出不稳定造成的需要回到音频切分环节检查。6.3 如何判断转录质量转录质量不能只看“能不能识别出几个词”要从三个维度综合评估语义完整性是否能把一句完整的话切成一句完整文本而不是拆成碎片。语言准确性多语言段落是否按正确语言解码尤其是中文英文交界处。专有名词产品名、人名、地名是否保持一致。专有名词最容易在 ASR 链路里被改写。建议准备一个不超过 30 秒的固定测试音频集包含不同口音、不同语言组合、不同噪声环境。每次更新模型版本或调整 prompt 后都先跑一遍固定音频集再上线。这是控制转录质量回归最直接的方法。7. 常见问题与排查思路多语言转录接入时最常见的问题不是“API 不会调”而是“调通了但结果不可用”。下面整理了一份排查清单。问题现象可能原因排查方式解决方案接口返回 404 或模型不存在模型 ID 输入错误或官方模型列表有调整查看官方文档中的最新模型 ID改掉模型名按文档最新值填写返回 400 参数错误请求里缺少必要字段或音频格式不受支持查看错误消息里的具体字段名补充字段使用 wav/mp3 等受支持格式识别结果全是同一语言提示词没有要求输出语言标记检查返回文本里是否包含 language 字段在 prompt 中显式要求标注每段语言中文识别夹英文错误中英混合但语言切换点判断失败单独用中英交替的 10 秒样本测试在 prompt 中说明“可能会中英混用请按段落识别语言并保留专有名词”长音频请求超时单次音频文件过大查看文件大小与请求耗时改用分段处理或异步任务接口返回空文本音频静音段过长、音质过低或采样率异常试听音频查看波形和采样率用 ffmpeg 转成 16kHz 单声道后重试输出有额外解释文字prompt 未强调“只输出 JSON”查看返回文本首尾内容在 prompt 中加“不要输出解释文字”成本超预期大量音频反复重试查看调用日志和每次音频时长增加缓存相同音频不重复调用排查时有一个顺序建议先确认网络和鉴权再确认文件和格式再确认模型 ID最后才调 prompt。不要一上来就反复改 prompt那样会浪费很多时间。8. 最佳实践与工程建议8.1 音频预处理是转录质量的天花板同样的模型给它一段有回声、低音量、电话录音的音频和给它一段干净录音效果差距巨大。建议把音频预处理放到 pipeline 的第一步统一转成 16kHz、单声道、16bit 的 PCM/WAV。用噪音抑制工具去掉明显底噪。对过长的静音段做压缩。对音量过低的音频做响度归一化。这一步看起来耗时但能显著减少下游重试次数。尤其多语言转录对“清晰度”要求不低人声不干净模型连语言边界都难判断。8.2 敏感音频数据的授权问题如果转录内容涉及客户录音、内部会议、医疗访谈等场景必须先确认你拥有处理和使用这些音频数据的权限。在使用 Gemini 3.5 Transcribe 这类外部 AI 服务时要把敏感信息脱敏后再上传或者选择本地化部署方案。对于企业内部项目最稳妥的做法是先做数据分类把包含身份证号、银行卡号、病历号的音频单独处理。在音频上传前用脱敏工具把敏感部分静音或替换成提示音。在传输层启用加密在服务端配置访问白名单。定期轮换 API 密钥确保权限最小化。8.3 缓存机制很多业务场景中同一段音频可能被多次调用。比如会议结束后产品、运营、客服可能都会拉取同一份转录结果。建议在服务端加一层缓存以音频文件的 MD5 值作为 key。import hashlib import json from pathlib import Path def get_audio_md5(audio_path: str) - str: block_size 1024 * 1024 md5 hashlib.md5() with open(audio_path, rb) as f: while chunk : f.read(block_size): md5.update(chunk) return md5.hexdigest() def read_cache_or_transcribe(audio_path: str, cache_dir: str cache): audio_id get_audio_md5(audio_path) cache_file Path(cache_dir) / f{audio_id}.json if cache_file.exists(): return json.loads(cache_file.read_text(encodingutf-8)) result transcribe_audio(audio_path) Path(cache_dir).mkdir(parentsTrue, exist_okTrue) cache_file.write_text(result, encodingutf-8) return json.loads(result)这里要注意如果业务要求实时性缓存时间可以设置短一些如果音频内容不可变缓存可以长期保留。使用缓存之前也要先确认版权和数据合规方面允许长期保存转录结果。8.4 错误重试与降级外部 AI 接口调用难免遇到限流或临时故障重试时需要注意对超时错误做指数退避重试避免短时间内频繁请求。对 4xx 参数错误不要盲目重试先修复请求内容。如果主服务不可用可以降级到本地 ASR保证基础功能不中断。把失败请求记录到日志系统方便事后分析。单纯的“失败就重试 3 次”不够。更合理的策略是第一次失败 - 等 1 秒重试 第二次失败 - 等 4 秒重试 第三次失败 - 等 16 秒重试 第三次仍然失败 - 写入失败队列进入人工补偿流程8.5 多语言转录的工程化输出转录结果最终会交给不同系统消费建议统一封装成结构化的转录对象而不是到处传字符串。一个紧凑的转录对象可以包含audio_id: 音频唯一标识 segments: 分段数组 - start - end - language - text - speaker_id可选 - confidence可选 created_at: 创建时间 model_version: 模型版本这样下游消费方只依赖数据字段不依赖具体接口格式。后续切换模型或升级 prompt 时只要字段兼容上层代码就不需要大改。9. 一份可直接使用的接入清单与其做长篇总结不如直接给你一份可执行的接入清单。这篇文章写到这里核心就是把“Gemini 3.5 Transcribe 支持多语言转录”这个信息翻译成可以直接落地的工程动作。第一步确认你的场景确实需要多语言转录而不是普通单语 ASR。如果音频以单语为主传统 ASR 更简单成本也更低。第二步准备测试音频集。至少准备三段分别是纯中文、纯英文、中英混合各 30 秒左右音质尽量贴近真实业务数据。第三步搭建环境并跑通transcribe_demo.py。先不要追求完整业务逻辑确认 API 能通、模型能返回结构、语言标记能输出即可。第四步验证 SRT 字幕是否与音频对齐。如果时间戳偏移超过预期回到音频预处理环节检查。第五步针对真实业务音频压缩、切分、脱敏、缓存、重试几步都做好之后再评估成本和准确率决定是否放大到生产环境。多语言转录这个方向未来会有更多模型跟进。但工具会变底层的问题和工程方法不会变要理解语言边界、要做预处理、要处理好长音频、要保护敏感数据、要保持输出结构化。把这几件事做好不管换成哪个模型你的接入链路都能复用。