Gemini 3.5 Transcribe 上线前，先给语音转动作加一道提交门禁

Google 推出了预览版 Gemini 3.5 Transcribe，同时覆盖录音文件和实时音频流。发布材料重点介绍了 85 种以上语言、语码转换、说话人标注、时间戳，以及对姓名、数字和其他字母数字内容的改进。这些能力很实用，却也容易让产品团队走一条危险的捷径：看到一份流畅的转录稿，就默认系统已经取得了执行动作的权限。

设想一次订阅服务的客服通话。用户说：“把续费日期改到 5 月 14 日，但先不要从新卡扣款。”临时转录漏掉了否定词，又把这句话错归到同事名下，并在文字被修订前就送进计费工具。即使最终稿非常准确，产品结果仍然可能已经出错。

小团队今天应该做的改变，是把识别结果和执行权限拆开。一份转录稿可能已经足以用于搜索或整理笔记，却还不够资格更新 CRM、创建工单、发送消息或触发付款。是否放行，应取决于真实语音任务、关键字段是否稳定、说话人是否有权发出指令、转录是否已经定稿，以及动作能否撤销并核对结果。

本文给出一套建议执行的 24 个用例“语音转动作”发布门禁。我们没有为本文调用 Gemini 3.5 Transcribe，没有复现 Google 的发布数据，也没有做供应商横评。下文所有夹具、阈值和结果字段，都是留给团队自行运行的模板，不是 Y Build 的实测成绩。

这次发布了什么，又没有证明什么

Google 的 Gemini 3.5 Transcribe 模型文档列出两个预览版接口：处理音频文件的 gemini-3.5-transcribe，以及处理实时流的 gemini-3.5-transcribe-live。两者都支持 85 种以上语言的自动识别，并允许在同一会话内切换语言，但功能并不对等。文件模式支持词级时间戳，实时模式不支持；启用时间戳可能降低转录准确率；实时模式不支持说话人分离；文件模式最多支持 8 位说话人，而 3 位及以上的归属仍被标记为实验性能力。

DeepMind 发布公告称该系统针对多语言转录进行了优化，并公布了 Google 所选评估中的改进。这些数字属于一手厂商发布证据，不能直接预测你的麦克风、用户口音、产品专名、通话构成、静音模式、网络链路和动作参数表上的表现。

因此，稳妥的结论只是：市场上出现了一个覆盖面广、与产品场景高度相关的新候选。它不等于“85+ 语言”在每种语言上的质量都相同；说话人标签也不等于身份已经得到确认；平均错误率更低，更不等于下游自动化已经安全。

一份转录至少有四种状态

不少团队只保存一个 transcript 字符串，随着新音频到达不断覆盖。这样的数据结构，恰好抹掉了自动化最需要保留的差异。

至少要区分四种状态：

1. 临时：语音还在输入时产生的片段，之后可能改写、延长或撤回。
2. 定稿：识别服务已关闭该片段。这里的“最终”只表示协议内不再修改，不代表内容一定正确。
3. 已核验：产品规则、确定性解析器或人工已经核对了这次动作真正依赖的字段。
4. 已授权：产品确认当前用户和说话人有权请求这一项具体效果。

这四层不是可以互换的标签，而是不断累积的证据。只有同时满足“已定稿、已核验、已授权”的片段，才能支撑不可逆或对外可见的动作。定稿回答“文字还会不会变”；核验回答“必要含义是否被正确恢复”；授权回答“这个人能不能要求系统这样做”。三个问题必须分别回答。

Speaker 2 这样的标签只是说话人分离，不是身份认证。时间戳只能证明片段位置，不能证明语义可信。句子读起来流畅，也不能证明音频里真的出现过这句话。发布门禁必须把这些类型边界一直保留到工具调用之前。

为什么平均词错率不能当发布门禁

词错率（WER）会按照参考文本统计替换、删除和插入，仍然是有用的基础指标。NIST OpenSAT 评估计划也使用 WER 衡量自动语音识别。但 WER 默认每个词的权重相同，产品后果却绝不会平均分配。

把“周二”识别成“周四”，把 $15 识别成 $50，或把“不要”变成“要”，都可能让一份整体准确的转录失去价值。一小时会议的平均 WER 很低，不代表唯一的决策句没有出错。像“是”或“不是”这样很短的发言，也可能在时长加权指标里几乎消失。

说话人指标也有同样的聚合陷阱。原始的 Balanced Error Rate 论文指出，按时长统计的说话人分离错误可能低估短片段和发言较少者的错误。当发言最少的人恰好是审批人、反对者或账户所有者时，这个缺口就会直接进入产品风险。

WER 可以保留，但至少要增加以下产品指标：

• 关键字段错误率：单独检查姓名、日期、金额、单位、否定词、标识符和同意用语；
• 动作字段精确匹配：完成规范化后逐字段比对，账户或金额错误不能拿部分分；
• 说话人与权限匹配：确认这段话是否来自有资格执行该动作的人；
• 修订逃逸率：统计有多少动作曾从后来被修改的文本中生成或提交；
• 无音频依据内容率：标出没有可听依据的文字；
• 拒答质量：证据不足时，系统能否主动澄清，而不是补全一个看似合理的答案。

不要再把它们合成一个加权总分。零容忍字段必须继续作为硬门禁。

先选择一个有后果的语音任务

假设一个四人 SaaS 团队正在为订阅客服产品加入语音入口。通话中，助手可以起草摘要、提取账户名称、建议修改续费日期，并准备一封确认消息。现有人工流程要求账户所有者批准任何计费变更。

产品里的效果可以分成四类：

这张表可以阻止一个常见设计错误：给笔记和扣款设置同一个置信度阈值。系统完全可以用较粗糙的转录改善搜索，同时拒绝从同一份文字直接推导计费动作。

场景名称必须来自真实产品。如果你的任务属于临床听写、紧急调度、法律证据、无障碍服务、招聘筛选或金融建议，这套轻量协议不够用。此类场景需要专业验证，并接受适用的法律或监管审查。

建一套 24 用例夹具，而不是只测干净录音

准备 8 类夹具，每类录制 3 个独立样本。24 个用例无法估算罕见故障率，但足够小，团队可以逐个检查原始音频、中间转录、候选动作、确认界面和最终产品状态。

所有参与录音的人都必须同意测试。至少选择一种与生产环境接近的麦克风和声学路径。加入通用听写模型不太可能熟悉的产品名、多位数字编号、小数金额、容易发生地区格式混淆的日期；如果用户确实会混合语言，再加入自然的语码转换句子。

语码转换评估研究显示，音译和文本规范化等评估选择，会影响指标与人工判断之间的相关性。因此，不要把一套偏向英语的分词器当成通用裁判。原始文本和版本化的规范化流程都要保存，准备上线的每种语言还应由流利使用者复核。

语音动作凭证

每个用例都要生成一份凭证。转录只是凭证的输入之一，不能替代凭证本身。

voice_action_receipt:
  fixture_id: "renewal-correction-en-ja-02"
  provider:
    model: "pin-exact-model-id"
    api_mode: "file|live"
    region: "record-service-region"
  audio:
    source_hash: ""
    consent_record: "consent/test-speaker-02.md"
    captured_at_utc: ""
    retention_class: "delete-after-qa"
  transcript:
    provisional_events: []
    finalized_text: ""
    finalized_at_utc: ""
    speaker_segments: []
    critical_fields:
      renewal_date: { value: null, source_span: "", verified: false }
      payment_instruction: { value: null, source_span: "", verified: false }
    revisions: []
    unsupported_content: []
  authority:
    authenticated_actor: ""
    claimed_speaker: ""
    allowed_effects: []
    confirmation_event: null
  proposed_effect:
    tool: "billing.change_renewal_date"
    arguments: {}
    idempotency_key: ""
    reversible_until: ""
  outcome:
    decision: "draft|clarify|confirm|commit|refuse"
    committed_at_utc: null
    observed_terminal_state: null
    rollback_tested: false

source_span 是关键字段。审稿人必须能从 renewal_date 跳回产生该字段的具体音频和转录片段。如果系统说不清某个动作参数来自哪里，就不应准备这项动作。

置信度留空，也比伪造确定性更可靠。Gemini 文档说明了支持哪些功能，却没有提供一个适用于所有场景的逐词校准置信度协议。如果供应商没有暴露经过校准的置信度，就不要用 token 概率、句子流畅度或 LLM 的自评分去拼一个出来。

用两阶段路径处理真实动作

更安全且仍然实用的架构，不是“禁止语音自动化”，而是用两阶段流程让低风险辅助保持流畅，同时约束高后果动作。

第一阶段：准备。 只消费已定稿的片段。提取候选字段并保留来源片段，判断效果类别，检查说话人权限。系统可以起草笔记或确认单，但不能执行效果。

第二阶段：提交。 把关键字段以可检查的形式展示给用户。对相应效果取得明确确认，把确认绑定到幂等键和有效期，再交给独立检查同一权限的工具策略执行。最后读取真实终态，而不是相信一条长得像成功结果的模型回复。

实时转录中，临时文本必须与动作队列隔离。“改成 5 月 14 日——不是 5 月 4 日”应该产生一次修订事件，而不是留下两个互相竞争的日期。如果系统已经根据 5 月 4 日准备了工具调用，就必须先让旧方案失效，再接受替代值。

批量音频也不能因为已经定稿就自动取得权限。录音里可能包含引述、另一台设备播放的声音，或多位参与者。产品必须分清自己是在总结一个音频文件，还是在接受某个已认证用户的指令。

把“幻觉”当成效果问题来测试

基于语言模型的识别器可能生成没有对应声学依据、却十分通顺的文字。Careless Whisper 研究检查了 Whisper 转录，并报告其样本中约 1% 的音频转录包含整段凭空出现的短语或句子；研究还发现，非发声停顿占比更高的语音面临更不均衡的风险。这个结果只适用于研究中的模型、样本和时间，绝不是 Gemini 3.5 的实测错误率。

真正可以迁移的是方法：用静音和不确定内容测试无依据输出，并评分最终效果，而不是只看文字。至少加入三组负向对照：

1. 房间里有噪声，但没有人说话；
2. 一句未完成的指令后出现长停顿；
3. 低音量背景人声，但并未对产品说话。

通过测试的系统不能从这些对照中产生有权限的指令。即使识别器输出了文字，动作层也必须拒绝升级。这样才能把识别错误与隔离失败分开。一段被明确标为草稿的转录幻觉已经值得重视；如果同一句话真的改动了账户，它就变成了系统级事故。

说话人标签只能辅助路由，不能证明身份

说话人分离回答的是“哪一组声学特征在什么时候发言”，不是“此人对应哪个法律身份或账户身份”。重叠语音、很短的确认、转接电话、共享设备和重放音频，都会放大这道缺口。

测试时加入一段很短的账户所有者确认，并让一段更长的无权限发言打断它。可以记录按时长加权的分离错误，但每一段带权限含义的语音还要单独评分。Balanced Error Rate 提案之所以有价值，正是因为短片段或少发言者很容易消失在聚合时长里。产品门禁可以更简单：任何授权词被归错说话人，该用例直接失败。

身份认证应该来自产品会话、明确的升级验证或可信业务流程，而不能来自自动生成的 Speaker 1 标签。如果确实要使用声纹，还需要单独评估重放、合成语音、同意、备用路径和账户恢复。本文不把说话人分离当作生物识别控制。

把隐私也写进夹具

音频包含的不只是文字，还可能泄露旁人、背景活动、地点线索、健康信息、情绪和与身份相关的声音特征。如果数据流程图里只画转录文本，就会漏掉原始文件、临时事件、运营工具、供应商日志、应用追踪和派生动作参数。

Google 的 Gemini API 附加服务条款区分免费与付费服务，并明确提醒不要向免费服务提交敏感信息。零数据保留指南还列出按功能变化的例外和配置：Interactions API 需要显式关闭存储；Live API 如果启用会话恢复，包含文字、音频和视频的会话状态最多可能保留 24 小时；Files API 中的文件需要主动删除。这些是当前供应商文档，不代表你可以跳过对具体账户、地区、合同和 API 路径的核查。

NIST Privacy Framework提供了更广泛、以结果为导向的隐私风险管理方法。放进本次夹具时，要把数据路径写具体：

• 记录谁同意了录音，以及是否可能录到旁人；
• 列出所有存储产物和派生字段；
• 给每项数据指定负责人、用途、访问边界和删除触发条件；
• 测试实时会话中途撤回同意；
• 删除一个测试用例，并核对供应商、应用、日志和派生存储；
• 防止生产原始音频误入自愿贡献的模型改进数据集。

一份从未经历删除演练的隐私说明，只是政策主张，不是运营证据。

放行规则不能用平均分稀释

用同一组输入，分别测试当前基线和新候选。固定模型标识、接口模式、地区、客户端版本、规范化代码、工具参数表和确认界面。流式或带随机性的用例需要重复到足以暴露修订行为，但不要把 24 个样本包装成统计代表性。

所有硬门禁都通过后，才能放行：

普通 WER、关键字段错误、说话人错误、澄清率、人工复核时间、得到可用草稿的延迟，以及取得授权后完成提交的延迟，都要分开报告。新候选可能让笔记更准确，同时增加确认摩擦。这仍然可以支持“仅草稿”的有限上线，但不能据此放开自动动作。

最终只用四种决策：draft-only（仅草稿）、limited-action（有限动作）、hold（暂缓）或 reject（拒绝）。决策必须写清具体产品面，不能因为一个会议笔记用例通过，就把整个模型品牌推广到全部语音流程。

上线前要逐项检查的失败模式

临时文本进入了动作队列。 最终界面已经显示正确，后台却还排着一项过期动作。

把“定稿”误当成“真实”。 协议不再修改，只能证明文字稳定，不能证明内容正确。

说话人编号被升级成账户身份。 系统只完成了声学聚类，却悄悄获得了从未证明过的权限。

自我修正被识别成第二条指令。 原值和替代值同时留在下游状态中。

好看的 WER 隐藏了唯一的危险词。 否定词、金额、单位、日期或编号恰好出错。

人工确认重复了原始歧义。 界面只问“是否继续”，却不展示规范化字段和将要发生的效果。

把工具返回当成最终结果。 工具回复成功，但业务状态没有变化、重复变化，或改错了记录。

原始音频活得比声明用途更久。 应用删除了转录，供应商文件、可恢复会话、调试日志或评估数据集仍然存在。

这套协议适合什么，又不适合什么

当语音会被转换成结构化输入，用于客服、排期、CRM 更新、订单准备、现场运营、会议跟进或其他产品动作时，可以使用这套门禁。尤其适合团队从“转录并展示”迈向“转录并执行”的阶段。

对于会离开产品边界的效果，本文有意采用更保守的规则。只要用户能在使用前修改，私有草稿可以容忍更多不确定性。商业承诺、以用户身份发送的消息、权限修改或破坏性动作，则必须取得逐字段确认，并由独立工具策略再次检查。

这套协议不是 Gemini 3.5 Transcribe 的独立 benchmark，不是全语言公平性证明，不是声纹评估，不是合规认证，也不能替代行业专家。产品仍处于预览阶段，功能行为、价格、保留控制、限制和模型别名都可能变化。在公开任务和语料上被独立复现之前，Google 公布的性能仍然是厂商证据。

48 小时 Build Lab 执行计划

第 0–4 小时： 选定一个语音任务并给所有效果分级。明确哪些输出只能留在草稿，哪些必须经过核验、授权和明确确认。

第 4–10 小时： 由同意参与的说话人准备 8 类夹具。在运行候选前，冻结参考转录、关键字段、说话人权限、预期决策和删除说明。

第 10–18 小时： 记录临时、修订和定稿事件。先用功能开关挡住动作准备。加入来源片段、幂等键和终态读取。

第 18–28 小时： 用同一套 24 个用例测试基线与候选。让目标语言的流利使用者复核语码转换和关键字段，逐个检查负向对照和说话人权限用例。

第 28–36 小时： 只执行合成数据或沙盒动作。主动制造改口、重复投递、超时、确认失败、无权限说话人和回滚场景，证明临时文字或无依据内容无法逃逸。

第 36–42 小时： 追踪同意、存储、日志、保留和删除。重复一次删除，直到每个已列出的副本和派生记录都有可观察终态。

第 42–48 小时： 签署 draft-only、limited-action、hold 或 reject 凭证。记录已测语言、麦克风、声学条件、效果类别、模型 ID、接口模式和触发重测的条件。

Gemini 3.5 Transcribe 降低了接入丰富语音输入的成本。正因为接入更容易，发布决策才应该更严格。一份转录可以很早就开始帮助产品，但在取得用户的行动权限之前，必须走完更长的证据链。

参考资料

1. Google DeepMind：Intelligent transcription with Gemini 3.5 Transcribe
2. Google AI for Developers：Gemini 3.5 Transcribe 模型文档
3. Google AI for Developers：Gemini Developer API 的零数据保留说明
4. Google AI for Developers：Gemini API 附加服务条款
5. NIST：OpenSAT 2020 Evaluation Plan
6. Koenecke 等：Careless Whisper: Speech-to-Text Hallucination Harms
7. Liu、Yu：BER: Balanced Error Rate for Speaker Diarization
8. Hamed 等：Benchmarking Evaluation Metrics for Code-Switching Automatic Speech Recognition
9. NIST：Privacy Framework