Google 发布 Gemini 3.5 Transcribe 实时转写模型，流式 WER 4.0%丨日报

本期编辑：@三水、@鲍勃

01 有话题的技术

1、Google 发布实时语音转写模型 Gemini 3.5 Transcribe：流式 WER 4.0%，最终转写延迟较 Chirp 3 降低 70%

Gemini 3.5 利用智能转录功能处理语音中的断句现象

Gemini 3.5 语音转录功能可让你在 macOS 系统的 Gemini 应用中，通过语音分析文件、生成图像以及搜索

Google 发布新一代语音转写模型 Gemini 3.5 Transcribe，面向 Voice Agent、实时字幕和通话分析等场景。相比此前的 Chirp 3，新模型不只做逐字 ASR，而是直接把原始语音整理成可用文本：能处理自我纠正、去除「嗯」「啊」等口头填充词、自动排版，并结合自定义词汇提升专业术语和订单号、邮编等实体的识别准确率。

同时提供实时和录音两条 API：gemini-3.5-transcribe-live 通过 Live API 提供亚秒级双向流式转写；gemini-3.5-transcribe 通过 Interactions API 处理会议、通话录音等内容，并支持说话人区分和词级时间戳。
准确率与延迟同时提升： Artificial Analysis 测得流式转写平均 WER 为 4.0%，非流式为 2.6%；相比 Chirp 3，最终转写结果的输出时间缩短 70%。
支持 85+ 语言和实时语言切换： 模型可自动识别 85 种以上语言，并处理不同口音、方言及对话中的语言切换；预录音频目前支持最多 3 名说话人的稳定区分，3 人以上仍属实验能力。
实时语音开发生态已经接入： Agora 等平台已通过 Gemini Live API 提供集成，替开发者处理底层实时音频流、连接和媒体传输等基础设施，使其可以直接围绕转写结果构建 Voice Agent 和语音交互界面。
转写开始与屏幕上下文和 Agent 工作流结合： 在 Google Antigravity 和 Gemini macOS 应用中，模型可以结合当前屏幕、聊天记录和文件名改善识别，还可通过函数调用把文件分析、图片生成等任务交给其他 Gemini 模型执行。

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5-transcribe/

(@Google)

2、微信视觉团队开源多模态嵌入模型 WeMM-Embedding：统一文本、图片和视频检索，9B 在 MMEB-v2/v3 排名第一

微信视觉团队开源多模态嵌入模型 WeMM-Embedding，用一套向量表示统一处理文本、图片、视频、视觉文档及图文混合内容，可直接用于跨模态搜索与推荐。相关技术已广泛应用于微信视频号、公众号、朋友圈和电商等业务场景，此次开放 2B、4B、9B 三个规模的模型权重与推理代码。

9B 模型在两代 MMEB Benchmark 中均排名第一： WeMM-Embedding-9B 在 MMEB-v2 的 78 个数据集上平均得分 80.6，在 MMEB-v3 的 190 项任务上综合得分 59.5；其中覆盖图片、视频、视觉文档、文本及 Agent 检索等不同任务。
一种模型统一不同模态的「检索表示」： 文本可以直接搜索图片或视频，图片、视频和视觉文档也能映射到同一个向量空间，不需要分别维护独立的文本、图像和视频检索模型。目前暂不支持音频输入。
支持按部署需求缩短向量维度： WeMM-Embedding 使用 Matryoshka Embedding，可在推理后直接截取更短的向量降低存储和检索成本；其中 2B 模型将向量压缩到 256 维时，在 MMEB-v2 图片和视频任务上仍保留完整维度 98.7% 的性能。
开发者可直接接入现有推理框架： 项目已经提供 Transformers、Sentence Transformers、vLLM 和 SGLang 的推理与服务示例，模型权重同步发布至 Hugging Face。

https://github.com/Tencent/WeMM-Embedding

3、开源实时 ASR 引擎 hayamimi：仅用 CPU 完成多语言转写，日语实测 CER 5.8%、停说约 100ms 出最终字幕

日本开发者 oboroge 开源实时多语言语音转写引擎 hayamimi（早耳），不依赖 GPU 和云端 API，在本地 CPU、2GB 以内内存即可运行。它没有用单一 Whisper 覆盖所有语言，而是先识别当前语种，再把音频路由给不同的专用 ASR 模型，在低资源设备上兼顾实时性和识别准确率。

按语言动态选择 ASR 模型： 日语、中文、韩语、粤语以及英语和 24 种欧洲语言分别调用更适合的模型，其余约 1600 种语言则回退到 Meta Omnilingual ASR；所有模型均以 INT8 ONNX 形式通过 sherpa-onnx 在 CPU 上运行。
停说后约 100ms 即可确认字幕： 用户说话过程中约每 0.5 秒更新一次临时字幕；日语场景下，停止说话后最终结果平均约 100ms 输出。项目在真实广播日语上的 CER 为 5.8%，同一批音频中 Whisper Large v3 Turbo 为 13.8%。
支持二次转写提高最终文本质量： 在检测到约 2 秒停顿后，系统会重新批量解码最近几句话，生成更干净的最终转写，在实时字幕和更高准确度文本之间做两阶段处理。
已经包含说话人标签和实时翻译： 可为不同发言轮次添加 S1、S2 等说话人标签，并将日语实时翻译为英语、中文或韩语；同时提供浏览器 Dashboard、OBS 字幕层和 WebSocket 音频输入，可直接接收手机或 ESP32 等设备传来的麦克风音频。

https://github.com/oboroge0/hayamimi

4、Yutori 发布 27B 电脑操作模型 Navigator n2：从浏览器扩展到完整桌面，可在 GUI、命令行和代码之间自主切换

Yutori 发布新一代 27B 电脑操作模型 Navigator n2。相比此前主要面向浏览器操作的 n1/n1.5，n2 将执行范围扩展到 Linux、macOS 和 Windows 完整桌面环境，并不再限定 Agent 只能「像人一样点击界面」，而是让模型根据任务主动选择 GUI、命令行、工具调用或代码执行，以更少步骤完成长流程任务。

在 Audacity 软件中进行音频编辑

从 Browser-use 升级为完整电脑操作： n2 可以连续操作桌面应用、浏览器和 CLI，也能在需要时直接编写短代码。例如批量重命名文件时，可直接执行脚本，而不是重复进行大量鼠标点击。
重点训练「什么时候该用哪种接口」： 模型不仅获得 GUI、CLI、工具和代码的操作能力，还针对长任务训练动态切换策略，避免 Agent 在效率较低的界面上反复操作，或频繁切换工具却无法推进任务。
多个电脑操作 Benchmark 进入前沿水平： n2 在 OSWorld 2.0 获得 65.2%，OSWorld-Verified 为 85.3%，MyPCBench 为 82.6%，MacAgentBench 为 83.1%，WeaveBench 为 70.3%；其中 OSWorld-Verified、MyPCBench、MacAgentBench 和 WeaveBench 均超过博客列出的其他对比模型。
用电脑操作 Agent 反过来生产训练数据： Yutori 在过去两个月生成超过 1 万个、覆盖数百款应用的任务，并让 Agent 参与任务探索、验证器生成和失败案例分析，再将新发现的问题加入下一轮训练，形成「模型生成训练任务—训练更强模型」的循环。
API 已开放，主打更低的电脑操作成本： Navigator n2 输入价格为每百万 Token 0.5 美元、缓存输入 0.05 美元、输出 4 美元；在 OSWorld 2.0 测试中，官方给出的平均单任务 API 成本为 1.46 美元。

https://yutori.com/blog/introducing-n2

02 有亮点的产品

1、RealWear 推出语音优先 AI 操作系统 Ari OS：让智能眼镜、手机和网页共享同一套对话与上下文

工业智能眼镜公司 RealWear 推出 Ari OS，一套面向真实工作环境的语音优先 AI 操作系统。它不要求用户不断打开 App、查菜单或低头看屏幕，而是通过自然语言理解用户意图，再结合眼前的视觉信息、企业服务和历史上下文完成任务；同一段对话还可以在智能眼镜、手机和网页之间连续进行。

语音是主要入口，但不是单纯的语音助手： 用户可以直接询问信息、联系人或操作步骤，Ari 根据需要用语音回答，也可以把下一步操作、资料等视觉内容直接显示在智能眼镜视野中。
上下文可以跨设备延续： Ari Mobile 将同一套 AI 体验带到手机，Ari Chat 则提供浏览器入口；用户此前的对话、上下文和技能不会因为摘下智能眼镜或更换设备而中断。
Ari Cloud 统一管理 Agent 所需的长期上下文： 对话、技能、连接器、记忆、文档和设备都集中在云端管理，使 Ari 能持续调用用户和企业已有的信息，而不是每次从零开始一轮语音问答。
开始连接真实企业工作流： Ari OS 首批支持邮件、日历、联系人和 Microsoft Teams；面向企业的 Ari Business 还允许 IT 和运营团队管理设备、配置用户，并针对一线工作流程开发自定义技能。

Ari OS 目前已在 RealWear Navigator Z1 智能眼镜上开放，并同步提供 Ari Mobile 和 Ari Chat；更多 RealWear 设备和企业技能将在后续加入。

https://www.realwear.com/press-releases/ari-os

2、Alma 演示语音驱动电脑操作：不用鼠标和画笔，对着 MS Paint 说话即可完成绘画

https://alma.inc/paint

(@tiramisurabhi@X)

3、Google XR 提出 AgentHands：让 Voice Agent 边说边「用手比划」，把语音指令落到真实空间和物体上

AgentHands 演示：为 AI 智能体赋予富有表现力且同步的手部手势，实现 XR 环境下具备空间感知的对话交互

完整的 AgentHands 系统工作流程，展示了从用户语音输入到第一人称视角观察，再到 LLM 生成的手势事件以及同步的 XR 渲染过程的整个过程

Google XR 发布研究原型 AgentHands，为 XR 中的对话 Agent 加入与语音同步的虚拟手势。相比只用语音告诉用户「看这里」「转动这个旋钮」，AgentHands 会结合用户视线和空间环境，直接在对应物体旁完成指向、描边、模拟操作等动作，把原本需要用户自己理解的空间关系变成可视化演示。该研究已发表于 CHI 2026。

先让 Agent 知道「你在看什么」： 系统结合眼动注视与场景重建，把植物、电脑、3D 打印机等真实物体注册成带有 3D 位置的对象，使后续语言和手势都能准确指向现实空间中的目标。
LLM 在生成回答时同时生成手势事件： 除了文本回复，模型还会插入对应的 GestureEvents，选择指向、模拟形状与动作、表达情绪等不同手势，并确定手势应出现的位置和时间。
手势与 TTS 按词级时间戳同步： XR 设备本地解析语音时间戳，让虚拟手在 Agent 说到「这里」「向上抬」「转动」时同步完成对应动作，而不是播放一段与语音分离的预设动画。
实验显示空间指引比纯语音更容易理解： 12 名参与者分别完成兰花养护和 3D 打印机操作任务。与相同内容的纯语音 Agent 相比，加入手势后，用户在定位物体、理解复杂动作和注意安全警告等方面均获得显著改善，同时降低了理解和记忆操作步骤的负担。

https://research.google/blog/agenthands-generating-interactive-hand-gestures-for-spatially-grounded-agent-conversations-in-xr/

(@GoogleResearch)

4、OpenAI Build Week 生活应用组冠军 Second Voice：无需预先录制语音，让构音障碍者把含糊表达转成可确认的完整句子

Second Voice 获得 OpenAI Build Week「Apps for Your Life」组第一名。它面向构音障碍用户，不要求像传统个性化语音辅助工具那样先录制大量训练语句，而是从第一次使用开始，将不清晰或残缺的语音转写结果，与个人常用语和当前对话场景一起交给 GPT-5.6，推断用户真正想表达的内容。

不是直接「纠正」ASR，而是重建整句话： 系统将原始转写、个人常用语和当前上下文交给 GPT-5.6，生成 2–3 个按置信度排序的候选句子，用户可直接选择或修改。
在 TTS 开口前增加明确确认： 用户选定句子后，系统才会通过 TTS 将其说出来，避免 AI 在理解错误时直接替用户发声，这个「先确认、再说话」的闭环是产品核心交互设计。
无需为每个用户单独训练语音模型： Second Voice 的目标是做到零语音注册、零训练录音即可使用，将个性化主要放在个人常用语和场景上下文层，而不是重新训练 ASR。
一次评测反而暴露了「上下文过度纠错」的问题： 开发者最初加入个人上下文后，WER 从 22.3% 恶化到 32.0%；随后将流程改为优先相信声学转写证据、使用结构化输出，并允许模型在证据不足时不做猜测，避免个人上下文覆盖真实语音内容。
整个项目使用 Codex 构建： 包括 Python 后端、Whisper 转写流程、浏览器状态机以及 GPT-5.6 的句子重建逻辑。团队下一步计划继续降低实时转写延迟，并根据反复出现的场景自动建议新的个人常用语。

https://devpost.com/software/second-voice-uk1peq

03 有态度的观点

1、 AssemblyAI：Voice Agent 的 Turn Detection 不是「延迟问题」，而是「节奏问题」

AssemblyAI 提出了一个很有意思的判断：Voice Agent 的自然感，不应该只优化平均响应延迟，更应该优化延迟的「波动」。

比如，一个每次都稳定在 400ms 后接话的 Agent，可能比一个平均只有 300ms、但偶尔需要 1.2 秒才回应的 Agent 更自然。因为人可以逐渐适应稍慢的对话节奏，却很难适应一个时快时慢、无法预测什么时候会接话的系统。

这也重新定义了 Turn Detection（轮次检测）的目标：它不是简单判断「沉默了多少毫秒」，而是判断用户这句话到底说完没有。固定静音阈值只能在「更快响应」和「更少打断」之间做取舍；语义 Endpointing 则会结合转录内容、标点以及语调等信息，理解这次停顿究竟是话说完了，还是用户只是换气、思考或还准备继续说。

所以真正值得关注的指标，可能不是「平均 Endpointing 延迟是多少」，而是它能否稳定地踩准人类对话的节奏，以及那些最慢的长尾延迟到底有多长。对于 Voice Agent 来说，「什么时候开口」本身就是模型能力的一部分。

https://www.assemblyai.com/blog/turn-detection-endpointing-voice-agent

（@AssemblyAI）

写在最后：

我们欢迎更多的小伙伴参与「RTE 开发者日报」内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示：个人观点，仅供参考