Gemini 3.5 Transcribe 发布之后多语言转录这个方向又一次成为开发者的关注重点。过去做音频转写常见做法是先接一个语音识别模型把语音转成文本再单独做语言识别、翻译和文本清洗如果音频里同时出现中文、英语、日语、粤语还要处理语言切换、专有名词、数字单位链路会变得非常长。Gemini 3.5 Transcribe 这类能力目标是把“听懂音频内容”和“输出目标语言文本”放到同一个多模态模型调用中处理。对开发者而言它既可以当普通语音转文字接口用也可以把转录结果直接接到翻译、摘要、内容检索、客服质检等下游流程。这篇文章围绕 Gemini 3.5 Transcribe 的功能定位详细讲解如何从环境准备开始完成一个多语言音频转录的最小应用并说明参数控制、验证方法、常见问题和生产落地建议。1. 先理解 Gemini 3.5 Transcribe 在转录链路中的位置1.1 转录不是单纯的“语音转文字”很多刚接触转录的开发者会把“转录”理解成 ASR也就是 Automatic Speech Recognition。实际上转录要解决的问题比 ASR 更宽。转录不仅要把语音变成文字还要尽量保留说话人想表达的语义尤其当音频中包含多种语言、方言口音、专业术语、数字、人名和地名时单纯 ASR 的输出往往需要大量后处理。例如一段会议录音里有人用中文说“上季度营收增长 15%”紧接着用英语说“we need to align the roadmap”。传统链路需要先判断每一段语音属于哪种语言再分别调用中英文识别模型最后还要做语言边界切分。如果识别模型对语言切换敏感度不高输出就很容易出现“中英混杂但语义错乱”的情况。Gemini 3.5 Transcribe 这类多模态转录方案的思路不同。它不一定把“语音识别”“语言识别”“文本生成”作为独立模块而是把音频作为输入在生成文本的过程中同时理解音频内容和上下文。这样一来中英文混说、口语化表达、带口音的专有名词都有机会在同一个生成过程中被处理。1.2 传统转录链路与多模态转录链路的差异传统方案通常由多个模型或服务拼接而成。比如先做语音活动检测判断哪些片段有人声再做语音识别得到带时间戳的文本紧接着做语言识别判断每一段是什么语言最后用机器翻译或规则替换来统一目标语言。这种链路的优点是每个环节都可以单独优化、单独替换模块边界清晰。缺点也很明显错误会在链路中累积传播。前面 ASR 识别错一个词后面的翻译和关键词提取都可能跟着错。另一个问题是延迟和成本多个服务串行调用每次都要处理一遍音频或中间文本。使用 Gemini 3.5 Transcribe 时典型的流程会大幅缩短。开发者把音频文件或音频字节流传给模型在提示词里说明输出格式和语言要求模型直接返回结构化文本。下面是两种链路的核心对比。对比项传统 ASR 翻译链路多模态模型单次转录模块数量通常需要 2 到 4 个服务一次模型调用语言切换处理依赖语言识别和边界切分模型根据音频内容直接生成错误传播上游错误会向下游扩散单次生成错误保留在同一层调试难度需要逐个服务排查主要看提示词、参数和模型输出扩展灵活性可以自由替换子模块扩展方式受模型能力限制这里的重点不是说明多模态方案一定全面优于传统方案。实际项目中需要考虑成本、延迟、可控性和数据隐私。如果团队已经有成熟的 ASR 管线不一定需要推翻重来。如果你要做的是多语言音频的内容理解和结构化输出那么直接调用 Gemini 3.5 Transcribe 能减少很多拼接工作。1.3 本文适合谁能获得什么这篇内容适合正在做音频内容处理、会议纪要、视频字幕、客服质检或访谈文本分析的开发者。读者最好具备基础 Python 能力了解 HTTP API 和 JSON 数据结构但不一定需要深入 NLP 背景。读完这篇文章后你会得到一套可复现的接入流程怎么准备音频、怎么写最小代码、怎么控制输出格式、怎么验证结果、出现问题后按什么顺序排查。文中的代码和配置主要用来说明思路落地到你自己项目时需要结合实际 API 版本、模型 ID 和调用方式做调整。2. 环境准备与依赖配置2.1 确认 API 可用性和模型 ID在写代码之前第一件事是确认当前账号能访问的模型列表。Gemini 系列的模型 ID 会在不同控制台、不同时间段发生变化。项目标题里提到的 Gemini 3.5 Transcribe 是功能名称实际调用时控制台或 API 文档展示的模型 ID 可能是gemini-3.5-transcribe也可能是类似gemini-3.5-transcribe-latest的标识。建议按以下顺序确认登录对应的 AI 开发控制台或云平台控制台。打开模型列表或模型库页面确认当前账号可用的模型 ID。查看接口文档中关于音频输入的说明确认支持的音频格式和最大时长。申请或确认 API 密钥已经创建并且权限范围允许调用该模型。这里要特别提醒不要直接在代码里硬编码模型 ID 和 API 密钥。学习环境可以先临时写在配置里但正式项目必须外置。否则模型升级或密钥轮换时代码和配置耦合在一起维护成本会高很多。2.2 安装 Python SDK 和辅助工具我用 Python 示例来演示因为多数做媒体处理和 AI 应用的团队都会选择 Python。官方 SDK 常用的是google-genai安装命令如下pip install google-genai安装完成后可以用下面这段代码检查 SDK 是否能正常导入from google import genai print(genai.__version__)如果输出版本号说明 SDK 安装成功。如果你的项目使用了虚拟环境先激活虚拟环境再执行安装。安装后建议把依赖写入requirements.txtpip freeze requirements.txt除了 SDK还需要准备音频处理工具。FFmpeg 不是必须的但实际项目中非常有用。因为 Gemini 3.5 Transcribe 对音频格式和采样率有要求而录音文件往往来自手机、录音笔或视频导出格式五花八门。用 FFmpeg 统一转码能避免大量格式解析问题。ffmpeg -version如果提示找不到命令在 Ubuntu/Debian 系统上可以安装sudo apt update sudo apt install ffmpeg在 macOS 上可以使用 Homebrewbrew install ffmpegFFmpeg 的具体用途会在后面音频准备部分展开。2.3 项目目录结构建议在开始写代码前先把项目目录搭好。最小目录可以这样设计audio-transcriber/ ├── main.py ├── requirements.txt ├── config.yaml └── input/ └── sample.wav实际项目中config.yaml用来保存模型 ID、API 密钥、请求参数和输出目录。下面是一个示例配置api_key_env: GEMINI_API_KEY model_id: gemini-3.5-transcribe temperature: 0.2 max_output_tokens: 4096 audio_dir: ./input output_dir: ./output注意配置里不直接写密钥而是写环境变量名。真正读取密钥时从环境变量获取import os api_key os.environ.get(GEMINI_API_KEY) if not api_key: raise ValueError(GEMINI_API_KEY is not set)这里把密钥放到环境变量是为了避免把密钥提交到 Git 仓库。如果在 Jupyter Notebook 里调试临时写入密钥可以接受但一旦进入团队协作必须把密钥和代码分开。3. 最小实现把一段多语言音频交给 Gemini3.1 准备一段适合测试的音频刚开始做测试时不要直接拿一个小时的会议录音去跑。多语言转录涉及音频解码、长文本生成和上下文窗口第一步最好用短音频验证链路是否通。建议准备一段 30 到 60 秒的音频内容包含两种以上语言。最方便的方式是自己在安静环境下录制例如先用中文说几句话再用英语说几句话中间停顿一下。这样可以很容易判断转录结果是否正确区分了语言边界。如果手头的音频是 m4a、mp3 或视频里的音轨先转成 WAV 格式便于后续处理和问题排查。转换命令参考ffmpeg -i input.m4a -ar 16000 -ac 1 -sample_fmt s16 sample.wav参数含义如下-ar 16000采样率设置为 16kHz。这个采样率对语音识别和模型处理通常足够。-ac 1单声道减少数据量。-sample_fmt s1616 位整数编码是常见的音频编码格式。转码完成后可以用 FFprobe 确认音频信息ffprobe sample.wav输出里能看到采样率、声道数和编码格式。确认无误后把文件放到input目录。3.2 编写最小转录代码在main.py中写入以下代码。这个示例演示的是完整调用流程实际项目里建议把配置读取、请求构建、结果保存拆分成函数。import os from google import genai from google.genai import types # 1. 读取 API Key api_key os.environ.get(GEMINI_API_KEY) if not api_key: raise ValueError(GEMINI_API_KEY is not set) # 2. 初始化客户端 client genai.Client(api_keyapi_key) # 3. 读取音频文件 audio_path input/sample.wav with open(audio_path, rb) as f: audio_bytes f.read() # 4. 构造请求内容 response client.models.generate_content( modelgemini-3.5-transcribe, contents[ types.Part.from_bytes( dataaudio_bytes, mime_typeaudio/wav, ), 请转录这段音频。保留原始说话语言不要翻译。, ], configtypes.GenerateContentConfig( temperature0.2, ), ) # 5. 输出结果 print(response.text)这段代码的核心逻辑分四步读取密钥、初始化客户端、把音频字节和提示词一起传入、打印返回文本。这里要注意的是mime_type必须和音频实际格式匹配。如果音频是 mp3需要改成audio/mpeg如果是 wav就是audio/wav。格式不匹配时模型可能无法解析音频内容。运行命令export GEMINI_API_KEY你的密钥 python main.py如果你的密钥已经在环境变量中可以省略export。3.3 预期输出格式如果没有额外指定结构化输出模型返回的文本可能是自由文本。例如大家好今天会议主要讨论 Q3 的增长计划。 We need to align the roadmap with the engineering team. 中文部分目标是在十月底完成功能上线英文部分需要同步给海外团队。能看到中英文内容但时间戳和段落边界并不固定。为了把结果用于会议纪要或字幕生成通常需要在提示词里明确输出格式。这个环节放在下一节详细展开。最小实现跑通后首先要确认三个问题音频有没有被正确解析、模型有没有输出目标语言、返回内容有没有被截断。如果这三个都没有问题再进入参数调优和多文件处理。4. 关键参数与输出控制4.1 模型请求参数说明GenerateContentConfig中常用的参数包括temperature、max_output_tokens、top_p、response_mime_type和response_schema。这些参数对应模型生成文本时的随机性、长度限制和输出结构。参数含义常见取值调大影响调小影响temperature控制生成内容的随机性0 到 1转录通常用 0.1 到 0.3结果更发散可能出现改写更稳定更贴近原始语音内容max_output_tokens限制输出文本长度根据音频时长和内容量设置能输出更长文本但耗时增加可能截断后半段内容top_p采样范围默认通常为 1保留更多候选词输出更集中response_mime_type指定返回格式text/plain、application/json无无response_schema定义结构化输出结构JSON Schema 对象无无对转录场景temperature不要设置太高。转录和创作不同转录要尽量贴近实际语音内容而不是发挥想象力。推荐从0.2起步如果发现模型把口语改成书面语导致内容偏差可以进一步降低到0.1。max_output_tokens要结合音频长度判断。一段 60 秒的中英混说话音输出可能在 300 到 800 个 token 之间。如果音频较长可以按每 10 分钟音频对应 3000 到 5000 个 token 做预估。实际项目建议先跑一小段观察返回的usage_metadata再调整。4.2 用提示词控制多语言转录规范模型对返回文本格式的理解很大程度上来自提示词。第一次做多语言转录建议把规则写清楚。下面是一个比较完整的提示词模板请转录这段音频并遵循以下规则 1. 保留说话人使用的原始语言不要翻译成其他语言。 2. 如果同一句中文里夹带了英文专有名词英文单词按原样输出。 3. 分离不同语言的段落用空行隔开。 4. 纠正明显的口语填充词例如“嗯”“那个”可以适当删除。 5. 不要总结音频内容不要添加解释。这段提示词的作用是控制模型的“转录”倾向。模型本身具备一定的改写能力如果不加约束可能会把中文口语转成更书面化的表达或者把英文翻译成中文。明确要求“不要翻译”“保留原始语言”能显著减少这类问题。需要注意提示词不是魔法。如果音频本身嘈杂、口音过重或者语言种类超出模型支持范围提示词也无法完全纠正。提示词只能影响模型如何理解输入不能提升音频质量。4.3 结构化输出JSON 和时间戳把转录结果用于字幕、会议纪要或知识库时最好让模型返回 JSON而不是自由文本。这样下游解析不需要做大量字符串处理。在 SDK 中可以指定response_mime_type和response_schema。下面是一个结构化输出的示例配置config types.GenerateContentConfig( temperature0.2, response_mime_typeapplication/json, response_schema{ type: object, properties: { language: {type: string}, segments: { type: array, items: { type: object, properties: { start: {type: number}, end: {type: number}, text: {type: string} } } } } } )这里的response_schema定义一个包含语言和分段数组的对象。每段包含开始时间、结束时间和文本内容。加入时间戳后输出的 JSON 类似{ language: mixed, segments: [ { start: 0.0, end: 4.2, text: 大家好今天会议主要讨论 Q3 的增长计划。 }, { start: 4.5, end: 8.1, text: We need to align the roadmap with the engineering team. } ] }这种结构非常适合直接写入字幕文件或数据库。如果你的 SDK 版本不支持字典形式的response_schema可以改用 Pydantic 模型或只使用response_mime_type在提示词里描述 JSON 字段结构。一个重要提醒要求模型输出 JSON 时最好同时设置response_mime_type并给出 schema。只靠提示词写“输出 JSON”有时也能成功但稳定性不如显式配置。如果模型返回内容开头还带着“ json”说明结构化配置没有完全生效需要在提示词里追加“只输出 JSON不要使用 Markdown 代码块”。5. 多语言场景的工程化处理5.1 长音频分段策略Gemini 3.5 Transcribe 虽然可以处理音频但上下文窗口和输入长度仍然有限。几分钟的音频可以直接传一小时的会议音频直接传很可能超时或截断。实际项目中建议先对音频做分段处理。分段方式一般有两种固定时长分段和静音检测分段。固定时长分段最简单适合快速实现ffmpeg -i long_audio.wav -ar 16000 -ac 1 -f segment -segment_time 300 -y part_%03d.wav这个命令会把long_audio.wav按每 300 秒切分成多个 WAV 文件文件名依次是part_000.wav、part_001.wav。静音检测分段更智能适合演讲、会议这类有自然停顿的音频。用 FFmpeg 的 silencedetect 可以找到静音点再根据静音点切分。这个方案复杂一些但能避免把完整句子切断。分段后需要注意一个细节如果句子被从中切断模型转录时可能丢掉上下文。例如一个人说“这个项目我们要分成三个 phase”如果“phase”被切到下一段第一段转录成“这个项目我们要分成三个”语义就不完整。解决思路是分段时保留前后重叠比如每段结束前多保留 5 秒转录后再去掉重复部分。5.2 批量转录与并发控制处理多个音频文件时不需要手动循环后串行等待。可以用线程池并发调用但要注意 API 的并发配额。并发太高会触发限流表现为RESOURCE_EXHAUSTED或429。下面是一个简单的批量转录代码框架import os from concurrent.futures import ThreadPoolExecutor, as_completed def transcribe_file(file_path): with open(file_path, rb) as f: audio_bytes f.read() response client.models.generate_content( modelgemini-3.5-transcribe, contents[ types.Part.from_bytes(dataaudio_bytes, mime_typeaudio/wav), 请转录这段音频保留原始语言按 JSON 格式返回。, ], configtypes.GenerateContentConfig( temperature0.2, response_mime_typeapplication/json, ), ) return file_path, response.text audio_files [ os.path.join(input, f) for f in os.listdir(input) if f.endswith(.wav) ] with ThreadPoolExecutor(max_workers4) as executor: futures [executor.submit(transcribe_file, f) for f in audio_files] for future in as_completed(futures): file_path, text future.result() print(file_path, text)max_workers不要一开始就设置很大。建议从 2 到 4 开始观察请求成功率和响应延后再调。如果接口没有明确说明并发限制保守一点是更好的选择。批量处理时还要考虑失败重试。网络抖动、暂时性限流都会导致单条失败。重试时不要马上重试应该采用指数退避。例如第一次等 1 秒第二次等 2 秒第三次等 4 秒。以下是一个简单的重试逻辑import time def call_with_retry(client, *args, max_retries3, **kwargs): for attempt in range(max_retries): try: return client.models.generate_content(*args, **kwargs) except Exception as exc: error_text str(exc) if RESOURCE_EXHAUSTED in error_text and attempt max_retries - 1: time.sleep(2 ** attempt) continue raise这个函数会在这类限流错误时等待并重试。其他错误直接抛出避免掩盖真正的问题。5.3 转录结果的后处理和对齐模型返回的 JSON 不一定完全符合预期。常见问题包括时间戳缺失、段落顺序错乱、文本里仍有口语填充词。后处理阶段需要做几件事。第一把返回的 JSON 解析成 Python 对象并做字段校验。import json def parse_response(text): data json.loads(text) if segments not in data: raise ValueError(segments field missing in response) return data如果模型返回的是 Markdown 代码块包裹的 JSON需要先清理def clean_json_text(text): text text.strip() if text.startswith(json): text text[len(json):].strip() if text.endswith(): text text[:-3].strip() return text第二对不同语言段落做统计。例如统计中英文段落分别有多少条或者统计每个说话人的片段时长。这些信息可以用于后续的会议纪要和时长分析。第三把分段结果写入字幕格式。如果 JSON 里有开始时间和结束时间可以转换成 SRT 格式1 00:00:00,000 -- 00:00:04,200 大家好今天会议主要讨论 Q3 的增长计划。 2 00:00:04,500 -- 00:00:08,100 We need to align the roadmap with the engineering team.转成 SRT 后可以导入视频剪辑软件或字幕工具进一步人工校对。6. 运行验证与结果分析6.1 验证维度转录任务没有绝对的“对错”只能通过多个维度评估质量。尤其在多语言场景里不能只看中文部分是否准确还要看语言边界是否正确、专有名词是否保留、时间戳是否合理。可以按照这几个维度来验证维度说明验证方式转录完整度音频中的主要内容是否都被转录出来对比原音频检查是否有整句遗漏语言正确性中文段落是不是中文英文段落是不是英文抽样检查段落语言专有名词准确度人名、地名、产品名、品牌名是否拼写正确对照原始资料或人工听写数字准确度金额、百分比、日期、版本号是否准确重点听数字部分时间戳一致性文本时间点是否和音频实际位置吻合跳转到对应时间点听一下格式完整性JSON 是否能被正确解析字段是否齐全用代码解析并校验 schema如果只把文本打印出来看很可能会漏掉时间戳错位和数字错误。建议每次都跑一遍自动解析再人工抽检。6.2 抽样校验流程对一批音频文件不需要每条都完整对照。可以采用分层抽样按音频时长分层分别抽长音频和短音频。每个文件随机抽 3 个时间点每个时间点听 10 到 15 秒。对比转录文本和音频内容记录错误类型。计算错误率不需要精确到字按“这句话是否可理解”评判即可。如果抽样错误率高于预期先不要盲目调整参数。先看错误集中在哪里是特定语言、特定口音还是特定专有名词再针对性修改提示词或预处理流程。6.3 性能与成本观察实际调用后需要关注两个数据响应时间和 token 消耗。SDK 的响应对象里通常包含usage_metadata可以用来读取输入 token 和输出 token。print(response.usage_metadata)输出大致类似UsageMetadata(prompt_token_count1200, candidates_token_count680, total_token_count1880)这个数据很有价值。你可以根据音频时长统计出“每分钟音频大约消耗多少 token”从而预估成本。不同模型定价不同不要在文章里写具体价格数字而是建议每次调用后记录 token 消耗。积累一周数据后就能做出相对准确的成本模型。性能方面短音频响应会很快但如果每次都传完整字节长音频的时间会明显增加。对长时间音频优先采用分段和并发而不是单独依赖一次请求。7. 常见问题排查7.1 请求超时或者等待时间过长现象调用模型后长时间没有返回最终抛出超时异常。排查顺序确认音频文件大小。几 MB 的文件通常不会太慢几十 MB 的音频可能已经达到接口限制。确认是否在循环里串行处理大量文件。如果文件很多单个文件并不慢但整体用时很长。查看日志确认阻塞点是网络请求还是模型生成。处理建议对音频做压缩和转码降低码率。分段处理减少单次请求的负载。在 SDK 调用中设置更长的超时时间但要权衡整体等待时间。7.2 返回内容乱码、被截断或缺少后半段现象转录结果不完整或者输出到一半突然结束。可能原因max_output_tokens设置太小输出被截断。音频太长模型上下文窗口不够。提示词要求输出复杂 JSON导致输出超过限制。检查方式先打印response.usage_metadata看输出 token 是否接近max_output_tokens。如果接近说明是长度限制。处理建议增大max_output_tokens或者把音频切成更小的片段。如果 JSON 输出复杂可以简化 schema先保证核心文本不丢。7.3 模型无法解析音频文件现象返回内容为空或者提示类似“无法处理音频输入”的错误。可能原因mime_type与音频实际格式不匹配。音频编码格式不被支持。音频文件损坏或为空。检查方式file sample.wav ffprobe sample.wav确认音频格式和编码。如果是 wav 文件确认编码是否是 PCM如果是 mp3确认文件是否能正常播放。处理建议统一用 FFmpeg 转成 16kHz、单声道、16 位 WAV。这是最稳妥的输入格式。7.4 输出语言不是目标语言现象中文音频被输出成英文或者英文音频被翻译成中文。可能原因提示词没有明确要求保留原始语言。temperature过高模型在做“创作性改写”而不是转录。音频内容本身包含混合语言模型判断错了主语言。处理建议在提示词里加一句“按音频实际使用的语言转录不要翻译”。同时把temperature降到 0.2 或更低。7.5 密钥、权限和配额错误常见错误关键字包括错误关键字含义处理方向API_KEY_INVALIDAPI Key 无效检查密钥是否被截断、是否有多余空格PERMISSION_DENIED当前密钥没有权限访问该模型检查模型 ID 是否正确、账号权限是否开启RESOURCE_EXHAUSTED配额耗尽或并发超限降低并发、增加退避重试、查看配额遇到这类错误时不要反复重试同一个请求。先检查密钥和配额再决定是否扩大并发。8. 生产落地注意事项与最佳实践8.1 学习环境与生产环境的差异本地调试时可以直接读文件、打印响应。生产环境需要额外考虑很多东西。学习环境可以这样写API 密钥写在环境变量里甚至在 Notebook 中临时赋值。直接同步调用等待结果。输出打印到控制台。失败后手动重试。生产环境至少要改成这样密钥从密钥管理服务读取定期轮换。调用任务放入队列异步处理结果回调或落库。输出保存到对象存储或数据库保留原始音频和结果 JSON。失败任务自动重试记录日志和监控指标。对音频内容做权限控制避免敏感数据泄露。关注点学习环境生产环境密钥管理环境变量密钥管理服务、定期轮换调用方式同步阻塞异步队列、任务表结果保存打印输出落库、对象存储失败处理手动重试自动重试、死信队列日志无结构化日志、追踪 ID监控无请求量、成功率、耗时、token 消耗8.2 上线前检查清单上线一个多语言转录服务建议按下面的清单逐项检查音频格式是否统一。所有输入音频是否都经过格式校验和转码。文件大小是否受限。是否有上传大小限制超出后是否提示用户分段。API 密钥是否安全。是否已经从代码仓库移除是否配置了密钥轮换。模型 ID 是否正确。线上和测试环境是否使用同一模型 ID是否需要固定版本。输出 schema 是否稳定。下游解析是否对缺失字段有兜底。失败重试是否合理。重试次数、退避时间、失败告警是否配置。token 消耗是否被观测。是否记录了每次调用的用量用于成本控制。敏感信息是否脱敏。音频和转录文本中是否包含身份证号、手机号、银行卡号等敏感内容。人工校验流程是否明确。自动转写结果是否需要人工抽检抽检比例是多少。回滚方案是否就绪。如果模型返回质量下降是否可以通过配置切换模型或降级到旧链路。这个清单不一定要全部满足才能上线但每一项都需要有明确负责人或决策记录。否则在生产环境踩到问题排查成本会很高。8.3 下一步扩展方向Gemini 3.5 Transcribe 跑通后可以围绕转录结果做更多扩展。第一翻译。多语言转录结果已经带语言标签可以接翻译接口把中文会议记录翻译成英文输出双语对照版本。第二摘要。用转录文本生成结构化摘要例如“本次会议讨论了三件事”“待办事项有五条”。摘要比转录文本更适合管理层快速阅读。第三关键词和标签提取。把转录文本输入另一个分类或抽取模型自动打标签方便后续检索。第四说话人分离。如果多语言转录结果包含不同人声可以在音频预处理阶段做声纹特征分析再和转写文本合并形成“谁说了什么”的会议记录。第五RAG 检索。把转录文本切块后写入向量数据库后续用户可以基于会议内容提问例如“上次会上关于预算的结论是什么”。这些扩展方向不一定全部需要自己实现。关键是先把转录底座做稳定包括音频格式、调用参数、数据结构、监控指标和人工校验流程。底座稳定后后续每加一个功能都会更顺畅。实际项目中最值得记住的一点是转录不是机器单方面的事情。无论模型多强都需要在链路里设计验证和纠错环节。多语言场景尤其如此因为语言边界、口音和专有名词的错误往往不会像语法错误那样容易发现。建议从最小音频开始逐步扩大测试集用数据来驱动模型和提示词调整而不是一次性把复杂音频全部塞进一个请求里。 Gemini 3.5 Transcribe多语言音频转录实战指南
Gemini 3.5 Transcribe 发布之后多语言转录这个方向又一次成为开发者的关注重点。过去做音频转写常见做法是先接一个语音识别模型把语音转成文本再单独做语言识别、翻译和文本清洗如果音频里同时出现中文、英语、日语、粤语还要处理语言切换、专有名词、数字单位链路会变得非常长。Gemini 3.5 Transcribe 这类能力目标是把“听懂音频内容”和“输出目标语言文本”放到同一个多模态模型调用中处理。对开发者而言它既可以当普通语音转文字接口用也可以把转录结果直接接到翻译、摘要、内容检索、客服质检等下游流程。这篇文章围绕 Gemini 3.5 Transcribe 的功能定位详细讲解如何从环境准备开始完成一个多语言音频转录的最小应用并说明参数控制、验证方法、常见问题和生产落地建议。1. 先理解 Gemini 3.5 Transcribe 在转录链路中的位置1.1 转录不是单纯的“语音转文字”很多刚接触转录的开发者会把“转录”理解成 ASR也就是 Automatic Speech Recognition。实际上转录要解决的问题比 ASR 更宽。转录不仅要把语音变成文字还要尽量保留说话人想表达的语义尤其当音频中包含多种语言、方言口音、专业术语、数字、人名和地名时单纯 ASR 的输出往往需要大量后处理。例如一段会议录音里有人用中文说“上季度营收增长 15%”紧接着用英语说“we need to align the roadmap”。传统链路需要先判断每一段语音属于哪种语言再分别调用中英文识别模型最后还要做语言边界切分。如果识别模型对语言切换敏感度不高输出就很容易出现“中英混杂但语义错乱”的情况。Gemini 3.5 Transcribe 这类多模态转录方案的思路不同。它不一定把“语音识别”“语言识别”“文本生成”作为独立模块而是把音频作为输入在生成文本的过程中同时理解音频内容和上下文。这样一来中英文混说、口语化表达、带口音的专有名词都有机会在同一个生成过程中被处理。1.2 传统转录链路与多模态转录链路的差异传统方案通常由多个模型或服务拼接而成。比如先做语音活动检测判断哪些片段有人声再做语音识别得到带时间戳的文本紧接着做语言识别判断每一段是什么语言最后用机器翻译或规则替换来统一目标语言。这种链路的优点是每个环节都可以单独优化、单独替换模块边界清晰。缺点也很明显错误会在链路中累积传播。前面 ASR 识别错一个词后面的翻译和关键词提取都可能跟着错。另一个问题是延迟和成本多个服务串行调用每次都要处理一遍音频或中间文本。使用 Gemini 3.5 Transcribe 时典型的流程会大幅缩短。开发者把音频文件或音频字节流传给模型在提示词里说明输出格式和语言要求模型直接返回结构化文本。下面是两种链路的核心对比。对比项传统 ASR 翻译链路多模态模型单次转录模块数量通常需要 2 到 4 个服务一次模型调用语言切换处理依赖语言识别和边界切分模型根据音频内容直接生成错误传播上游错误会向下游扩散单次生成错误保留在同一层调试难度需要逐个服务排查主要看提示词、参数和模型输出扩展灵活性可以自由替换子模块扩展方式受模型能力限制这里的重点不是说明多模态方案一定全面优于传统方案。实际项目中需要考虑成本、延迟、可控性和数据隐私。如果团队已经有成熟的 ASR 管线不一定需要推翻重来。如果你要做的是多语言音频的内容理解和结构化输出那么直接调用 Gemini 3.5 Transcribe 能减少很多拼接工作。1.3 本文适合谁能获得什么这篇内容适合正在做音频内容处理、会议纪要、视频字幕、客服质检或访谈文本分析的开发者。读者最好具备基础 Python 能力了解 HTTP API 和 JSON 数据结构但不一定需要深入 NLP 背景。读完这篇文章后你会得到一套可复现的接入流程怎么准备音频、怎么写最小代码、怎么控制输出格式、怎么验证结果、出现问题后按什么顺序排查。文中的代码和配置主要用来说明思路落地到你自己项目时需要结合实际 API 版本、模型 ID 和调用方式做调整。2. 环境准备与依赖配置2.1 确认 API 可用性和模型 ID在写代码之前第一件事是确认当前账号能访问的模型列表。Gemini 系列的模型 ID 会在不同控制台、不同时间段发生变化。项目标题里提到的 Gemini 3.5 Transcribe 是功能名称实际调用时控制台或 API 文档展示的模型 ID 可能是gemini-3.5-transcribe也可能是类似gemini-3.5-transcribe-latest的标识。建议按以下顺序确认登录对应的 AI 开发控制台或云平台控制台。打开模型列表或模型库页面确认当前账号可用的模型 ID。查看接口文档中关于音频输入的说明确认支持的音频格式和最大时长。申请或确认 API 密钥已经创建并且权限范围允许调用该模型。这里要特别提醒不要直接在代码里硬编码模型 ID 和 API 密钥。学习环境可以先临时写在配置里但正式项目必须外置。否则模型升级或密钥轮换时代码和配置耦合在一起维护成本会高很多。2.2 安装 Python SDK 和辅助工具我用 Python 示例来演示因为多数做媒体处理和 AI 应用的团队都会选择 Python。官方 SDK 常用的是google-genai安装命令如下pip install google-genai安装完成后可以用下面这段代码检查 SDK 是否能正常导入from google import genai print(genai.__version__)如果输出版本号说明 SDK 安装成功。如果你的项目使用了虚拟环境先激活虚拟环境再执行安装。安装后建议把依赖写入requirements.txtpip freeze requirements.txt除了 SDK还需要准备音频处理工具。FFmpeg 不是必须的但实际项目中非常有用。因为 Gemini 3.5 Transcribe 对音频格式和采样率有要求而录音文件往往来自手机、录音笔或视频导出格式五花八门。用 FFmpeg 统一转码能避免大量格式解析问题。ffmpeg -version如果提示找不到命令在 Ubuntu/Debian 系统上可以安装sudo apt update sudo apt install ffmpeg在 macOS 上可以使用 Homebrewbrew install ffmpegFFmpeg 的具体用途会在后面音频准备部分展开。2.3 项目目录结构建议在开始写代码前先把项目目录搭好。最小目录可以这样设计audio-transcriber/ ├── main.py ├── requirements.txt ├── config.yaml └── input/ └── sample.wav实际项目中config.yaml用来保存模型 ID、API 密钥、请求参数和输出目录。下面是一个示例配置api_key_env: GEMINI_API_KEY model_id: gemini-3.5-transcribe temperature: 0.2 max_output_tokens: 4096 audio_dir: ./input output_dir: ./output注意配置里不直接写密钥而是写环境变量名。真正读取密钥时从环境变量获取import os api_key os.environ.get(GEMINI_API_KEY) if not api_key: raise ValueError(GEMINI_API_KEY is not set)这里把密钥放到环境变量是为了避免把密钥提交到 Git 仓库。如果在 Jupyter Notebook 里调试临时写入密钥可以接受但一旦进入团队协作必须把密钥和代码分开。3. 最小实现把一段多语言音频交给 Gemini3.1 准备一段适合测试的音频刚开始做测试时不要直接拿一个小时的会议录音去跑。多语言转录涉及音频解码、长文本生成和上下文窗口第一步最好用短音频验证链路是否通。建议准备一段 30 到 60 秒的音频内容包含两种以上语言。最方便的方式是自己在安静环境下录制例如先用中文说几句话再用英语说几句话中间停顿一下。这样可以很容易判断转录结果是否正确区分了语言边界。如果手头的音频是 m4a、mp3 或视频里的音轨先转成 WAV 格式便于后续处理和问题排查。转换命令参考ffmpeg -i input.m4a -ar 16000 -ac 1 -sample_fmt s16 sample.wav参数含义如下-ar 16000采样率设置为 16kHz。这个采样率对语音识别和模型处理通常足够。-ac 1单声道减少数据量。-sample_fmt s1616 位整数编码是常见的音频编码格式。转码完成后可以用 FFprobe 确认音频信息ffprobe sample.wav输出里能看到采样率、声道数和编码格式。确认无误后把文件放到input目录。3.2 编写最小转录代码在main.py中写入以下代码。这个示例演示的是完整调用流程实际项目里建议把配置读取、请求构建、结果保存拆分成函数。import os from google import genai from google.genai import types # 1. 读取 API Key api_key os.environ.get(GEMINI_API_KEY) if not api_key: raise ValueError(GEMINI_API_KEY is not set) # 2. 初始化客户端 client genai.Client(api_keyapi_key) # 3. 读取音频文件 audio_path input/sample.wav with open(audio_path, rb) as f: audio_bytes f.read() # 4. 构造请求内容 response client.models.generate_content( modelgemini-3.5-transcribe, contents[ types.Part.from_bytes( dataaudio_bytes, mime_typeaudio/wav, ), 请转录这段音频。保留原始说话语言不要翻译。, ], configtypes.GenerateContentConfig( temperature0.2, ), ) # 5. 输出结果 print(response.text)这段代码的核心逻辑分四步读取密钥、初始化客户端、把音频字节和提示词一起传入、打印返回文本。这里要注意的是mime_type必须和音频实际格式匹配。如果音频是 mp3需要改成audio/mpeg如果是 wav就是audio/wav。格式不匹配时模型可能无法解析音频内容。运行命令export GEMINI_API_KEY你的密钥 python main.py如果你的密钥已经在环境变量中可以省略export。3.3 预期输出格式如果没有额外指定结构化输出模型返回的文本可能是自由文本。例如大家好今天会议主要讨论 Q3 的增长计划。 We need to align the roadmap with the engineering team. 中文部分目标是在十月底完成功能上线英文部分需要同步给海外团队。能看到中英文内容但时间戳和段落边界并不固定。为了把结果用于会议纪要或字幕生成通常需要在提示词里明确输出格式。这个环节放在下一节详细展开。最小实现跑通后首先要确认三个问题音频有没有被正确解析、模型有没有输出目标语言、返回内容有没有被截断。如果这三个都没有问题再进入参数调优和多文件处理。4. 关键参数与输出控制4.1 模型请求参数说明GenerateContentConfig中常用的参数包括temperature、max_output_tokens、top_p、response_mime_type和response_schema。这些参数对应模型生成文本时的随机性、长度限制和输出结构。参数含义常见取值调大影响调小影响temperature控制生成内容的随机性0 到 1转录通常用 0.1 到 0.3结果更发散可能出现改写更稳定更贴近原始语音内容max_output_tokens限制输出文本长度根据音频时长和内容量设置能输出更长文本但耗时增加可能截断后半段内容top_p采样范围默认通常为 1保留更多候选词输出更集中response_mime_type指定返回格式text/plain、application/json无无response_schema定义结构化输出结构JSON Schema 对象无无对转录场景temperature不要设置太高。转录和创作不同转录要尽量贴近实际语音内容而不是发挥想象力。推荐从0.2起步如果发现模型把口语改成书面语导致内容偏差可以进一步降低到0.1。max_output_tokens要结合音频长度判断。一段 60 秒的中英混说话音输出可能在 300 到 800 个 token 之间。如果音频较长可以按每 10 分钟音频对应 3000 到 5000 个 token 做预估。实际项目建议先跑一小段观察返回的usage_metadata再调整。4.2 用提示词控制多语言转录规范模型对返回文本格式的理解很大程度上来自提示词。第一次做多语言转录建议把规则写清楚。下面是一个比较完整的提示词模板请转录这段音频并遵循以下规则 1. 保留说话人使用的原始语言不要翻译成其他语言。 2. 如果同一句中文里夹带了英文专有名词英文单词按原样输出。 3. 分离不同语言的段落用空行隔开。 4. 纠正明显的口语填充词例如“嗯”“那个”可以适当删除。 5. 不要总结音频内容不要添加解释。这段提示词的作用是控制模型的“转录”倾向。模型本身具备一定的改写能力如果不加约束可能会把中文口语转成更书面化的表达或者把英文翻译成中文。明确要求“不要翻译”“保留原始语言”能显著减少这类问题。需要注意提示词不是魔法。如果音频本身嘈杂、口音过重或者语言种类超出模型支持范围提示词也无法完全纠正。提示词只能影响模型如何理解输入不能提升音频质量。4.3 结构化输出JSON 和时间戳把转录结果用于字幕、会议纪要或知识库时最好让模型返回 JSON而不是自由文本。这样下游解析不需要做大量字符串处理。在 SDK 中可以指定response_mime_type和response_schema。下面是一个结构化输出的示例配置config types.GenerateContentConfig( temperature0.2, response_mime_typeapplication/json, response_schema{ type: object, properties: { language: {type: string}, segments: { type: array, items: { type: object, properties: { start: {type: number}, end: {type: number}, text: {type: string} } } } } } )这里的response_schema定义一个包含语言和分段数组的对象。每段包含开始时间、结束时间和文本内容。加入时间戳后输出的 JSON 类似{ language: mixed, segments: [ { start: 0.0, end: 4.2, text: 大家好今天会议主要讨论 Q3 的增长计划。 }, { start: 4.5, end: 8.1, text: We need to align the roadmap with the engineering team. } ] }这种结构非常适合直接写入字幕文件或数据库。如果你的 SDK 版本不支持字典形式的response_schema可以改用 Pydantic 模型或只使用response_mime_type在提示词里描述 JSON 字段结构。一个重要提醒要求模型输出 JSON 时最好同时设置response_mime_type并给出 schema。只靠提示词写“输出 JSON”有时也能成功但稳定性不如显式配置。如果模型返回内容开头还带着“ json”说明结构化配置没有完全生效需要在提示词里追加“只输出 JSON不要使用 Markdown 代码块”。5. 多语言场景的工程化处理5.1 长音频分段策略Gemini 3.5 Transcribe 虽然可以处理音频但上下文窗口和输入长度仍然有限。几分钟的音频可以直接传一小时的会议音频直接传很可能超时或截断。实际项目中建议先对音频做分段处理。分段方式一般有两种固定时长分段和静音检测分段。固定时长分段最简单适合快速实现ffmpeg -i long_audio.wav -ar 16000 -ac 1 -f segment -segment_time 300 -y part_%03d.wav这个命令会把long_audio.wav按每 300 秒切分成多个 WAV 文件文件名依次是part_000.wav、part_001.wav。静音检测分段更智能适合演讲、会议这类有自然停顿的音频。用 FFmpeg 的 silencedetect 可以找到静音点再根据静音点切分。这个方案复杂一些但能避免把完整句子切断。分段后需要注意一个细节如果句子被从中切断模型转录时可能丢掉上下文。例如一个人说“这个项目我们要分成三个 phase”如果“phase”被切到下一段第一段转录成“这个项目我们要分成三个”语义就不完整。解决思路是分段时保留前后重叠比如每段结束前多保留 5 秒转录后再去掉重复部分。5.2 批量转录与并发控制处理多个音频文件时不需要手动循环后串行等待。可以用线程池并发调用但要注意 API 的并发配额。并发太高会触发限流表现为RESOURCE_EXHAUSTED或429。下面是一个简单的批量转录代码框架import os from concurrent.futures import ThreadPoolExecutor, as_completed def transcribe_file(file_path): with open(file_path, rb) as f: audio_bytes f.read() response client.models.generate_content( modelgemini-3.5-transcribe, contents[ types.Part.from_bytes(dataaudio_bytes, mime_typeaudio/wav), 请转录这段音频保留原始语言按 JSON 格式返回。, ], configtypes.GenerateContentConfig( temperature0.2, response_mime_typeapplication/json, ), ) return file_path, response.text audio_files [ os.path.join(input, f) for f in os.listdir(input) if f.endswith(.wav) ] with ThreadPoolExecutor(max_workers4) as executor: futures [executor.submit(transcribe_file, f) for f in audio_files] for future in as_completed(futures): file_path, text future.result() print(file_path, text)max_workers不要一开始就设置很大。建议从 2 到 4 开始观察请求成功率和响应延后再调。如果接口没有明确说明并发限制保守一点是更好的选择。批量处理时还要考虑失败重试。网络抖动、暂时性限流都会导致单条失败。重试时不要马上重试应该采用指数退避。例如第一次等 1 秒第二次等 2 秒第三次等 4 秒。以下是一个简单的重试逻辑import time def call_with_retry(client, *args, max_retries3, **kwargs): for attempt in range(max_retries): try: return client.models.generate_content(*args, **kwargs) except Exception as exc: error_text str(exc) if RESOURCE_EXHAUSTED in error_text and attempt max_retries - 1: time.sleep(2 ** attempt) continue raise这个函数会在这类限流错误时等待并重试。其他错误直接抛出避免掩盖真正的问题。5.3 转录结果的后处理和对齐模型返回的 JSON 不一定完全符合预期。常见问题包括时间戳缺失、段落顺序错乱、文本里仍有口语填充词。后处理阶段需要做几件事。第一把返回的 JSON 解析成 Python 对象并做字段校验。import json def parse_response(text): data json.loads(text) if segments not in data: raise ValueError(segments field missing in response) return data如果模型返回的是 Markdown 代码块包裹的 JSON需要先清理def clean_json_text(text): text text.strip() if text.startswith(json): text text[len(json):].strip() if text.endswith(): text text[:-3].strip() return text第二对不同语言段落做统计。例如统计中英文段落分别有多少条或者统计每个说话人的片段时长。这些信息可以用于后续的会议纪要和时长分析。第三把分段结果写入字幕格式。如果 JSON 里有开始时间和结束时间可以转换成 SRT 格式1 00:00:00,000 -- 00:00:04,200 大家好今天会议主要讨论 Q3 的增长计划。 2 00:00:04,500 -- 00:00:08,100 We need to align the roadmap with the engineering team.转成 SRT 后可以导入视频剪辑软件或字幕工具进一步人工校对。6. 运行验证与结果分析6.1 验证维度转录任务没有绝对的“对错”只能通过多个维度评估质量。尤其在多语言场景里不能只看中文部分是否准确还要看语言边界是否正确、专有名词是否保留、时间戳是否合理。可以按照这几个维度来验证维度说明验证方式转录完整度音频中的主要内容是否都被转录出来对比原音频检查是否有整句遗漏语言正确性中文段落是不是中文英文段落是不是英文抽样检查段落语言专有名词准确度人名、地名、产品名、品牌名是否拼写正确对照原始资料或人工听写数字准确度金额、百分比、日期、版本号是否准确重点听数字部分时间戳一致性文本时间点是否和音频实际位置吻合跳转到对应时间点听一下格式完整性JSON 是否能被正确解析字段是否齐全用代码解析并校验 schema如果只把文本打印出来看很可能会漏掉时间戳错位和数字错误。建议每次都跑一遍自动解析再人工抽检。6.2 抽样校验流程对一批音频文件不需要每条都完整对照。可以采用分层抽样按音频时长分层分别抽长音频和短音频。每个文件随机抽 3 个时间点每个时间点听 10 到 15 秒。对比转录文本和音频内容记录错误类型。计算错误率不需要精确到字按“这句话是否可理解”评判即可。如果抽样错误率高于预期先不要盲目调整参数。先看错误集中在哪里是特定语言、特定口音还是特定专有名词再针对性修改提示词或预处理流程。6.3 性能与成本观察实际调用后需要关注两个数据响应时间和 token 消耗。SDK 的响应对象里通常包含usage_metadata可以用来读取输入 token 和输出 token。print(response.usage_metadata)输出大致类似UsageMetadata(prompt_token_count1200, candidates_token_count680, total_token_count1880)这个数据很有价值。你可以根据音频时长统计出“每分钟音频大约消耗多少 token”从而预估成本。不同模型定价不同不要在文章里写具体价格数字而是建议每次调用后记录 token 消耗。积累一周数据后就能做出相对准确的成本模型。性能方面短音频响应会很快但如果每次都传完整字节长音频的时间会明显增加。对长时间音频优先采用分段和并发而不是单独依赖一次请求。7. 常见问题排查7.1 请求超时或者等待时间过长现象调用模型后长时间没有返回最终抛出超时异常。排查顺序确认音频文件大小。几 MB 的文件通常不会太慢几十 MB 的音频可能已经达到接口限制。确认是否在循环里串行处理大量文件。如果文件很多单个文件并不慢但整体用时很长。查看日志确认阻塞点是网络请求还是模型生成。处理建议对音频做压缩和转码降低码率。分段处理减少单次请求的负载。在 SDK 调用中设置更长的超时时间但要权衡整体等待时间。7.2 返回内容乱码、被截断或缺少后半段现象转录结果不完整或者输出到一半突然结束。可能原因max_output_tokens设置太小输出被截断。音频太长模型上下文窗口不够。提示词要求输出复杂 JSON导致输出超过限制。检查方式先打印response.usage_metadata看输出 token 是否接近max_output_tokens。如果接近说明是长度限制。处理建议增大max_output_tokens或者把音频切成更小的片段。如果 JSON 输出复杂可以简化 schema先保证核心文本不丢。7.3 模型无法解析音频文件现象返回内容为空或者提示类似“无法处理音频输入”的错误。可能原因mime_type与音频实际格式不匹配。音频编码格式不被支持。音频文件损坏或为空。检查方式file sample.wav ffprobe sample.wav确认音频格式和编码。如果是 wav 文件确认编码是否是 PCM如果是 mp3确认文件是否能正常播放。处理建议统一用 FFmpeg 转成 16kHz、单声道、16 位 WAV。这是最稳妥的输入格式。7.4 输出语言不是目标语言现象中文音频被输出成英文或者英文音频被翻译成中文。可能原因提示词没有明确要求保留原始语言。temperature过高模型在做“创作性改写”而不是转录。音频内容本身包含混合语言模型判断错了主语言。处理建议在提示词里加一句“按音频实际使用的语言转录不要翻译”。同时把temperature降到 0.2 或更低。7.5 密钥、权限和配额错误常见错误关键字包括错误关键字含义处理方向API_KEY_INVALIDAPI Key 无效检查密钥是否被截断、是否有多余空格PERMISSION_DENIED当前密钥没有权限访问该模型检查模型 ID 是否正确、账号权限是否开启RESOURCE_EXHAUSTED配额耗尽或并发超限降低并发、增加退避重试、查看配额遇到这类错误时不要反复重试同一个请求。先检查密钥和配额再决定是否扩大并发。8. 生产落地注意事项与最佳实践8.1 学习环境与生产环境的差异本地调试时可以直接读文件、打印响应。生产环境需要额外考虑很多东西。学习环境可以这样写API 密钥写在环境变量里甚至在 Notebook 中临时赋值。直接同步调用等待结果。输出打印到控制台。失败后手动重试。生产环境至少要改成这样密钥从密钥管理服务读取定期轮换。调用任务放入队列异步处理结果回调或落库。输出保存到对象存储或数据库保留原始音频和结果 JSON。失败任务自动重试记录日志和监控指标。对音频内容做权限控制避免敏感数据泄露。关注点学习环境生产环境密钥管理环境变量密钥管理服务、定期轮换调用方式同步阻塞异步队列、任务表结果保存打印输出落库、对象存储失败处理手动重试自动重试、死信队列日志无结构化日志、追踪 ID监控无请求量、成功率、耗时、token 消耗8.2 上线前检查清单上线一个多语言转录服务建议按下面的清单逐项检查音频格式是否统一。所有输入音频是否都经过格式校验和转码。文件大小是否受限。是否有上传大小限制超出后是否提示用户分段。API 密钥是否安全。是否已经从代码仓库移除是否配置了密钥轮换。模型 ID 是否正确。线上和测试环境是否使用同一模型 ID是否需要固定版本。输出 schema 是否稳定。下游解析是否对缺失字段有兜底。失败重试是否合理。重试次数、退避时间、失败告警是否配置。token 消耗是否被观测。是否记录了每次调用的用量用于成本控制。敏感信息是否脱敏。音频和转录文本中是否包含身份证号、手机号、银行卡号等敏感内容。人工校验流程是否明确。自动转写结果是否需要人工抽检抽检比例是多少。回滚方案是否就绪。如果模型返回质量下降是否可以通过配置切换模型或降级到旧链路。这个清单不一定要全部满足才能上线但每一项都需要有明确负责人或决策记录。否则在生产环境踩到问题排查成本会很高。8.3 下一步扩展方向Gemini 3.5 Transcribe 跑通后可以围绕转录结果做更多扩展。第一翻译。多语言转录结果已经带语言标签可以接翻译接口把中文会议记录翻译成英文输出双语对照版本。第二摘要。用转录文本生成结构化摘要例如“本次会议讨论了三件事”“待办事项有五条”。摘要比转录文本更适合管理层快速阅读。第三关键词和标签提取。把转录文本输入另一个分类或抽取模型自动打标签方便后续检索。第四说话人分离。如果多语言转录结果包含不同人声可以在音频预处理阶段做声纹特征分析再和转写文本合并形成“谁说了什么”的会议记录。第五RAG 检索。把转录文本切块后写入向量数据库后续用户可以基于会议内容提问例如“上次会上关于预算的结论是什么”。这些扩展方向不一定全部需要自己实现。关键是先把转录底座做稳定包括音频格式、调用参数、数据结构、监控指标和人工校验流程。底座稳定后后续每加一个功能都会更顺畅。实际项目中最值得记住的一点是转录不是机器单方面的事情。无论模型多强都需要在链路里设计验证和纠错环节。多语言场景尤其如此因为语言边界、口音和专有名词的错误往往不会像语法错误那样容易发现。建议从最小音频开始逐步扩大测试集用数据来驱动模型和提示词调整而不是一次性把复杂音频全部塞进一个请求里。