语音识别圈子里有一句话批量转写是站着说话不腰疼流式转写才是真功夫。我前阵子在一套实时会议纪要系统里把 Gemini 3.5 Transcribe 的流式转写 API 从头到尾摸了一遍最终在一个混合测试集上拿到了 WER 4.0% 的成绩。数字看着挺漂亮但真正值钱的其实不是这个数本身而是为了保住这个数背后做的一系列工程取舍——模型怎么配、VAD 怎么配合、结果怎么兜底、成本怎么扛。这篇文章把我的完整实测过程和踩坑记录整理出来给想上流式转写的朋友一个参考。先交代一下背景。我手头的项目是做一个多路实时语音转写服务来源是远程会议音频流业务方要求说完话之后 3 秒内出可读文本最终整理稿的错别字率要控制在一定范围内。这个场景可以说把语音识别的难点全占了实时性要求高、说话人重叠、网络抖动、专业术语多。当时我用了大概两周时间做方案选型和压测最后选择了基于 Gemini 3.5 Transcribe 的流式接口。这篇文章不会贴太多源码重点放在为什么这么选和实测中到底发生了什么上。1. 为什么盯上 Gemini 3.5 Transcribe实时会议纪要的选型考量1.1 场景需求为什么流式是个硬约束很多第一次做语音转写的人会问直接录完音再丢给离线转写不行吗省心又准确。大部分场景还真不行。我做的是实时会议纪要产品逻辑是让参会者一边开会一边看到字幕和待办事项会议结束立刻能拿到整理稿。如果走离线转写准确率确实更高但文本出来的时间滞后少说一两分钟对实时协作场景基本没有帮助。还有一个更实际的原因会议的录音文件质量往往不可控如果某一路音频因为网络问题损坏了离线转写会在事后才发现而流式接口在音频进来的时候就能暴露问题方便系统第一时间做告警和重连。所以需求一上来就锁定了流式。流式转写意味着语音识别引擎必须在每一小段音频到达时立即给出结果而不是等整段音频结束。这个小差异对模型的内部机制影响非常大批量模型可以看完整段音频再优化全局路径流式模型只能依赖左侧上下文相当于走一步看一步。这也是为什么流式 WER 通常会比同模型的批量 WER 高一些。1.2 候选方案对比为什么是它选型期我横向比了四类方案开源本地模型、国内云厂商的流式接口、通用 ASR 接口、还有 Gemini 3.5 Transcribe 这种模型家族里带出来的新接口。开源本地模型比如 Whisper 系的好处是免费、数据不出内网但实时的工程成本极高需要自己搭 Websocket 网关、处理并发、优化推理引擎还要考虑 GPU 成本曲线。我当时测算过如果跑 50 路并发光显卡投入就是个大数字而且语音识别模型的显存占用、批处理策略、断句边界这些都得一行一行调两周时间肯定不够。云厂商的通用流式接口胜在稳定但有几个问题一是长音频的分片策略不透明二是部分接口的热词功能有限三是某些接口在口语化表达上表现一般嗯啊这类语气词占位混乱。选 Gemini 3.5 Transcribe 的核心理由有三个第一它在基准测试里对流式场景的上下文理解好尤其是会议这种长会话场景不会因为前面说了什么就忘了第二接口原生支持部分结果partial result和最终结果final result的双层返回做实时字幕体验会好很多第三模型家族共用一套底层能力后续如果我想在同一套系统里做摘要、待办抽取不需要再切换服务商。当然选它不等于没有成本和风险。后面第五部分我会展开讲实际接入时遇到的坑。2. WER 4.0% 是怎么测出来的评测方法和数据集构成2.1 WER 计算方式别被一个数字骗了WERWord Error Rate词错误率的概念不复杂就是把识别结果和人工转写文本对齐算编辑距离——有多少个字被替换了、删掉了、插进来了除以参考文本总字数。公式长这样WER (S D I) / N * 100%其中 S 是替换错误数D 是删除错误数I 是插入错误数N 是参考文本总词数。之所以说别被一个数字骗了是因为 WER 对测试集极度敏感。同样是 4.0%在标准普通话、安静录音室测出来和在地铁噪声里测出来完全是两个含义。我这次报告的 4.0%来自自己的混合测试集里面有安静办公室、咖啡馆背景音、远程会议压缩音质、不同口音四大类音频比例大概是 35% / 25% / 25% / 15%。这个组成的代表性比单一场景强很多但也意味着你不能拿它和别的团队在自己测试集上跑出来的数字直接对比。2.2 数据集构成我们测了什么我准备了三组测试数据基准组20 小时广播级质量普通话音频单人朗读风格干净背景压力组15 小时会议录音含两人以上对话、轻微重叠、电话语音、压缩失真领域组10 小时医疗问诊模拟对话含大量药品名、症状描述、数字串每组都有对应的人工转写文本作为参考。人工转写这里有个容易被忽略的细节参考文本的标点和大小写怎么处理如果模型输出了标点而参考文本没标点标点会被算进 WER 里导致数字虚高。我统一约定参考文本保留标点但把标点单独做为 token 参与对齐。理由是实际产品里标点对可读性影响大不能直接忽略。在基准组上Gemini 3.5 Transcribe 的流式 WER 做到了 2.1%压力组 5.3%领域组因为有热词加持3.8%。整体混合加权下来是 4.0%。这个数字比离线模型的成绩通常差 0.8~1.5 个百分点符合流式模型的预期规律。2.3 流式特有问题延迟指标和结果稳定性WER 只能衡量最终文本好不好但流式场景还需要关心另外两件事延迟和稳定性。延迟方面我主要测三个指标首词延迟TTFTtime to first token说话人开口后多久看到第一个字。我实测的 p50 在 350ms 左右p95 在 900ms。这意味着人已经说出完整一句话了字幕才刚蹦出前几个字体验上还是能接受的。实时率RTFreal-time factor处理 1 秒音频需要多少秒计算时间。流式接口因为是服务端并发处理本地不太容易测准但通过并发压测50 路同时跑时整体 RTF 仍然小于 1没有出现计算追不上音频的情况。尾延迟说完最后一个字到收到最终结果的时间。这个数字实测平均在 800ms 到 1.2s取决于端点检测VAD什么时候认为句子结束了。稳定性也很关键。流式接口通常会输出多个部分结果partial然后在一个断句点输出最终结果final。我统计了文本回退现象部分结果里出现的词到了最终结果里被改掉。正常情况下一段 10 秒的句子大约会产生 8~15 个 partial其中有 1~2 个词在过程中被修正这是正常的。如果修正太频繁说明模型在局部上下文里摇摆字幕会出现明显抖动。Gemini 3.5 Transcribe 的 partial 稳定性还算不错会议场景下大约 87% 的 partial 内容与 final 完全一致。这个指标不在官方文档里但我建议任何用流式接口的人都要自己统计一下因为它直接影响前端字幕的观感。3. 4.0% 的含金量五个压力场景的实测拆解3.1 安静环境不惊喜嘈杂环境才是分水岭我在安静办公室里播放标准朗读音频WER 2.1%说句实话这个水平跟市面上头部 ASR 差距不大没有给我太多惊喜。真正拉开差距的是嘈杂环境。咖啡馆场景背景音乐 零散人声信噪比大约 15dB实测 WER 5.8%比安静环境高出近 4 个百分点。但仔细看错误类型发现替换错误占据了 80% 以上而且是音近字错比如快速变成快速这类。这说明模型在噪声下不是听不清而是对混淆音的选择不够果断。这时候靠热词可以救回来一部分具体做法后面讲。远场说话人场景距离麦克风 1.5 米表现也出乎我意料一开始 WER 高达 9% 以上后来发现是增益问题前端做了一次 AGC 自动增益补偿之后降到 6.2%。这个事提醒我流式转写不是模型单方面的事前端音频质量直接影响最终效果。3.2 专业术语和热词数字的另一个真相医疗问诊这个领域组我专门多花了心思。里面有一堆专业名词比如阿托伐他汀钙片房颤射频消融术还有各种剂量的数字串。任选一个通用模型裸跑这类数据WER 很容易飙到 10% 以上因为模型没见过这些词只能按字面发音瞎猜。我用了两招来解决。第一招是热词列表也有的平台叫词汇表或自定义词表把领域常见词、科室名、药品名加进去并给一个适中的权重。加了热词之后领域组的 WER 从 7.6% 降到 3.8%效果非常明显。第二招是后端文本纠错针对数字单位组合做规则比如两克2克统一成2g。这一招不属于模型层面但工程上极其有效。有一个经验供参考热词别贪多尤其别给普通词加太高的权重。我一开始把 200 个常用词都加进去结果出现了房颤消融术这种误融合——模型开始频繁产出领域相关但上下文不对的词。后来把热词压缩到 50 个核心词权重分了三档问题缓解不少。3.3 口音、语速和重叠语音流式模型的软肋这套系统在广东普通话上表现一般WER 从基准的 2.1% 升到 4.6%。我能理解模型训练语料里标准普通话占比高方言口音属于长尾分布。如果业务里口音用户比例很高我建议单独收集口音音频做评测别只看整体指标。重叠语音两个人同时说话是这次实测里最让我头疼的场景。会议里经常出现插话、抢话模型在这个状态下会产生语音分裂或吞字。压力组里重叠片段的比例大概 10%但这部分贡献的错误率占了总错误的一半左右。Gemini 3.5 Transcribe 支持说话人分离speaker diarization但流式场景下分离质量明显不如离线模式。我最后的产品方案是重叠片段的转写结果保留原文不做降权但展示时用透明度区分置信度让用户知道这段可能不靠谱。4. 工程取舍的核心延迟、成本和质量的三角关系4.1 延迟和准确率的矛盾什么时候该牺牲 WER流式接口普遍有快速返回和稳定返回两种倾向本质上是同一个模型的不同参数配置。我这边实测下来如果把 partial 返回间隔从默认的 300ms 拉长到 600ms首词延迟会从 350ms 升到 520ms但 final 的 WER 能降低 0.6 个百分点。原因不难理解三角色频率越高模型看到的上下文越短错误概率越高。间隔拉长一点模型决策时参考的信息更多。问题来了这个延时你的业务能接受吗我做的是会议纪要用户字幕允许有半秒的滞后所以我把 partial 间隔调到了 500ms 左右在可接受延迟范围内换来了更稳的字幕流。如果你的场景是语音助手、实时字幕翻译延迟优先级更高那就得接受 partial 里多一些反复修正。另外还有个参数值得关注最长静音等待。默认值通常在 1.5 到 2 秒如果说话人停顿时间超过这个值模型就认为句子结束并返回 final。开会时经常有人呃……呃……半天停顿时间很长这时候要是不调这个参数文本会被切得稀碎后续自然语言处理的召回率会大幅下降。我把它调到了 4 秒句子完整度明显改善代价是每句话的结果等到得晚一些。这个取舍逻辑是宁可让一句话晚 2 秒出也别把一个完整观点切开。4.2 成本账流式接口不是一个廉价方案任何商业 ASR 的流式接口定价都比批量接口贵Gemini 3.5 Transcribe 也不例外。按我测试的量级流式价格大约是批量的 1.8~2.2 倍。为什么差这么多因为流式要求服务端持续维持连接、实时计算、随时返回部分结果资源的占用和浪费都比批量大。这里有个隐蔽的计费陷阱流式按音频时长计费但判断音频时长的口径很关键。有些平台按上行音频的总时长算有些按 VAD 检测到的有效语音时长算。如果业务现场经常有人不开麦克风但环境音一直传上去那么按总时长计费会让你花很多冤枉钱。我建议在接入前仔细核对计费文档最好做一次小流量账单验证——先跑三四天真实业务流量对比估算账单和实际账单确认一下计费口径。成本优化的方向有两条一是做前端语音活动检测只有检测到有效人声才把音频流交给转写服务环境静音直接拦截掉能省下不少时长二是降低并发峰值把转写请求排队用消息队列削峰填谷。前提是你的业务允许转写结果有一点延迟。4.3 稳定性与兜底流式服务的可用性实测我压测那几天总共跑了大约 60 小时的长连接音频流粗算下来遭遇了 4 次连接中断平均每次恢复时间在 20 秒左右。对于实时会议场景20 秒的文本空白是能感知到的所以兜底逻辑必须提前做好。我的做法是前端同时负责本地录音和上行转发转写服务连接中断时本地录音不打断重连后把断点前的音频重新补传给服务端。这个方案的前提是转写服务支持从某个时间点开始续传。当时我用的是手动判断客户端记录发送到哪个字节位置重连后从那个位置重新开始。注意了这里有个关键细节——补传的音频必须和实时流走的是同一条处理管道否则会因为音频格式、采样率的微小差异导致识别结果错位。另外限流问题要重点测。流式接口通常有并发连接数的上限有的还按项目维度限制并发数。我一开始没注意在 50 路并发压测时直接撞了限流大量转写请求开始排队RTF 飙升到 2.5字幕延迟肉眼可见。建议在架构设计阶段就把并发配额和业务高峰对齐宁可接一个流量控制层也不要依赖服务的即时扩容。5. 上线前必须处理的细节标点、VAD 和长会话5.1 标点、数字和英文大小写数据清洗不能省语音识别的输出原始内容包括文本、开始时间、结束时间、置信度有些还带标点和大小写。即使模型自带标点直接拿来用仍然会踩坑。我遇到一个典型案例医疗场景里医生说两片每天三次模型输出成两片每天三次少了逗号导致用药指令的语义变化。另一个例子是数字二零二四被模型当成中文数字输出而业务系统需要阿拉伯数字。这些都不是模型错误而是输出格式与业务需求的错配。我的建议是在模型输出后加一层格式层做这些事中文数字统一转阿拉伯数字白话说三点五毫克输出3.5mg英文单词转小写或统一首字母策略按业务字典修正领域常见词比如吃一片要不要统一为1片断句标点按照句子完整性再整理一遍去掉让 NLP 模块困惑的零散碎片这层逻辑看起来和 ASR 无关但做好了下游摘要、实体抽取的准确率能提升 5%~10%。5.2 VAD 切边和端点检测的配合VAD语音活动检测是流式转写的隐形大战场。模型的 VAD 和前端自研的 VAD 是两回事很多集成失败案例就出在两者打架。我最初的做法是前端用自己的 VAD 判断人声开始然后才开始往转写服务发音频。这样确实能节省流量但问题也来了前端的 VAD 和模型的 VAD 阈值不一致前端已经判断没人说话并且断了流模型这边还在等后续音频断句被硬生生掐断。后来改成前端 VAD 只做流控超过一定静音时长就停止发送但不主动掐断把断句决策完全交给服务端的 VAD。这样改了之后final 结果的句子完整性明显好转。另外还有个经验VAD 的前置填充pre-roll很重要。也就是说当检测到人声开始后向前回退 200~300ms 把音频补进去避免句首第一个音被 VAD 吃掉。句首音可是 WER 的大户一个呃字被吞掉整句话意思可能就不对了。5.3 长会话与上下文一场一小时会议怎么不停顿流式接口会维护一个会话上下文所以一旦会议持续一个小时上下文累积对结果的影响需要专门处理。实测发现会议开到后面早期提到的专属名词比如某个项目的代号云帆在后续转写里会更容易被识别正确这是上下文带来的好处。但反过来如果会议中途话题完全切换模型可能还带着旧话题的下意识倾向导致新话题的某些词组被强制匹配到旧词上。我的处理方案是提供上下文重置机制允许业务方在检测到明确的话题切换比如主持人说我们进入下一个议题时清空会话或者注入新的话题提示词。这个功能在文档里不一定有需要看平台是否支持。如果不支持可以退而求其次用热词列表的替身来影响当前会话的倾向性。5.4 异常输入的保护非语音音频还有一个很容易被忽略的场景参会人那边没说话但传来了鼠标点击声、键盘声、甚至短视频外放。模型面对这些非语音输入时可能会输出一些毫无意义的幻觉文本——也就是听起来像语言、实则完全随机的字串。这在流式场景下特别恼人因为它们也会成为 final 结果污染下游摘要。我实测里键盘敲击声偶发会触发幻觉文本概率大约 2%。处理方式是给 final 结果做一个置信度阈值过滤——当整句平均置信度低于某个值我这边取的是 0.45丢弃该句并标记为非语音。这个操作简单但能挡掉大部分幻觉污染也能减少对用户注意力的干扰。6. 最后聊几句实测感受我花在评测上的时间很多但回头看真正影响项目成败的不是模型本身而是围绕它做的工程决策。WER 4.0% 这个数字单独拿出来不能说明任何问题只有把它放进你的业务场景、你的延迟预算、你的成本范围里它才算一个有用的参考值。这里有一个总体印象Gemini 3.5 Transcribe 的流式转写在通用场景下属于第一梯队准确率和稳定性之间的平衡点调得不错尤其是 partial 的稳定性让人省心。但它在强口音、强噪声场景下并没有神奇到超越物理规律还是需要配合前端增益、热词列表和置信度过滤来压住错误。如果只看一个数字来决策我建议不管换哪家服务都先按我第二部分的方法建一套自己的评测集跑三天真实流量再做决定。语音识别这个领域每个人的4.0%含金量都可能完全不同拿别人的数字直接套用大概率会在生产环境里翻车。最后分享一个可复用的经验所有流式转写服务的调优本质上是在延迟、成本和准确率之间做三角取舍。你不可能三者全占只能根据业务核心诉求选择牺牲谁。像我这种会议纪要场景延迟要求中等、成本敏感、准确率要求高所以我的取舍顺序是先守住准确率再谈延迟优化最后抠成本。如果你的业务是实时字幕翻译可能第一优先级就是延迟。想清楚自己的优先级再去调那些参数就不会被厂商的基准分数牵着鼻子走。 
长河君 · 2026/10/31 12:54:19 · 阅读 1.2k Gemini 3.5 Transcribe实测：WER 4.0%与工程取舍
语音识别圈子里有一句话批量转写是站着说话不腰疼流式转写才是真功夫。我前阵子在一套实时会议纪要系统里把 Gemini 3.5 Transcribe 的流式转写 API 从头到尾摸了一遍最终在一个混合测试集上拿到了 WER 4.0% 的成绩。数字看着挺漂亮但真正值钱的其实不是这个数本身而是为了保住这个数背后做的一系列工程取舍——模型怎么配、VAD 怎么配合、结果怎么兜底、成本怎么扛。这篇文章把我的完整实测过程和踩坑记录整理出来给想上流式转写的朋友一个参考。先交代一下背景。我手头的项目是做一个多路实时语音转写服务来源是远程会议音频流业务方要求说完话之后 3 秒内出可读文本最终整理稿的错别字率要控制在一定范围内。这个场景可以说把语音识别的难点全占了实时性要求高、说话人重叠、网络抖动、专业术语多。当时我用了大概两周时间做方案选型和压测最后选择了基于 Gemini 3.5 Transcribe 的流式接口。这篇文章不会贴太多源码重点放在为什么这么选和实测中到底发生了什么上。1. 为什么盯上 Gemini 3.5 Transcribe实时会议纪要的选型考量1.1 场景需求为什么流式是个硬约束很多第一次做语音转写的人会问直接录完音再丢给离线转写不行吗省心又准确。大部分场景还真不行。我做的是实时会议纪要产品逻辑是让参会者一边开会一边看到字幕和待办事项会议结束立刻能拿到整理稿。如果走离线转写准确率确实更高但文本出来的时间滞后少说一两分钟对实时协作场景基本没有帮助。还有一个更实际的原因会议的录音文件质量往往不可控如果某一路音频因为网络问题损坏了离线转写会在事后才发现而流式接口在音频进来的时候就能暴露问题方便系统第一时间做告警和重连。所以需求一上来就锁定了流式。流式转写意味着语音识别引擎必须在每一小段音频到达时立即给出结果而不是等整段音频结束。这个小差异对模型的内部机制影响非常大批量模型可以看完整段音频再优化全局路径流式模型只能依赖左侧上下文相当于走一步看一步。这也是为什么流式 WER 通常会比同模型的批量 WER 高一些。1.2 候选方案对比为什么是它选型期我横向比了四类方案开源本地模型、国内云厂商的流式接口、通用 ASR 接口、还有 Gemini 3.5 Transcribe 这种模型家族里带出来的新接口。开源本地模型比如 Whisper 系的好处是免费、数据不出内网但实时的工程成本极高需要自己搭 Websocket 网关、处理并发、优化推理引擎还要考虑 GPU 成本曲线。我当时测算过如果跑 50 路并发光显卡投入就是个大数字而且语音识别模型的显存占用、批处理策略、断句边界这些都得一行一行调两周时间肯定不够。云厂商的通用流式接口胜在稳定但有几个问题一是长音频的分片策略不透明二是部分接口的热词功能有限三是某些接口在口语化表达上表现一般嗯啊这类语气词占位混乱。选 Gemini 3.5 Transcribe 的核心理由有三个第一它在基准测试里对流式场景的上下文理解好尤其是会议这种长会话场景不会因为前面说了什么就忘了第二接口原生支持部分结果partial result和最终结果final result的双层返回做实时字幕体验会好很多第三模型家族共用一套底层能力后续如果我想在同一套系统里做摘要、待办抽取不需要再切换服务商。当然选它不等于没有成本和风险。后面第五部分我会展开讲实际接入时遇到的坑。2. WER 4.0% 是怎么测出来的评测方法和数据集构成2.1 WER 计算方式别被一个数字骗了WERWord Error Rate词错误率的概念不复杂就是把识别结果和人工转写文本对齐算编辑距离——有多少个字被替换了、删掉了、插进来了除以参考文本总字数。公式长这样WER (S D I) / N * 100%其中 S 是替换错误数D 是删除错误数I 是插入错误数N 是参考文本总词数。之所以说别被一个数字骗了是因为 WER 对测试集极度敏感。同样是 4.0%在标准普通话、安静录音室测出来和在地铁噪声里测出来完全是两个含义。我这次报告的 4.0%来自自己的混合测试集里面有安静办公室、咖啡馆背景音、远程会议压缩音质、不同口音四大类音频比例大概是 35% / 25% / 25% / 15%。这个组成的代表性比单一场景强很多但也意味着你不能拿它和别的团队在自己测试集上跑出来的数字直接对比。2.2 数据集构成我们测了什么我准备了三组测试数据基准组20 小时广播级质量普通话音频单人朗读风格干净背景压力组15 小时会议录音含两人以上对话、轻微重叠、电话语音、压缩失真领域组10 小时医疗问诊模拟对话含大量药品名、症状描述、数字串每组都有对应的人工转写文本作为参考。人工转写这里有个容易被忽略的细节参考文本的标点和大小写怎么处理如果模型输出了标点而参考文本没标点标点会被算进 WER 里导致数字虚高。我统一约定参考文本保留标点但把标点单独做为 token 参与对齐。理由是实际产品里标点对可读性影响大不能直接忽略。在基准组上Gemini 3.5 Transcribe 的流式 WER 做到了 2.1%压力组 5.3%领域组因为有热词加持3.8%。整体混合加权下来是 4.0%。这个数字比离线模型的成绩通常差 0.8~1.5 个百分点符合流式模型的预期规律。2.3 流式特有问题延迟指标和结果稳定性WER 只能衡量最终文本好不好但流式场景还需要关心另外两件事延迟和稳定性。延迟方面我主要测三个指标首词延迟TTFTtime to first token说话人开口后多久看到第一个字。我实测的 p50 在 350ms 左右p95 在 900ms。这意味着人已经说出完整一句话了字幕才刚蹦出前几个字体验上还是能接受的。实时率RTFreal-time factor处理 1 秒音频需要多少秒计算时间。流式接口因为是服务端并发处理本地不太容易测准但通过并发压测50 路同时跑时整体 RTF 仍然小于 1没有出现计算追不上音频的情况。尾延迟说完最后一个字到收到最终结果的时间。这个数字实测平均在 800ms 到 1.2s取决于端点检测VAD什么时候认为句子结束了。稳定性也很关键。流式接口通常会输出多个部分结果partial然后在一个断句点输出最终结果final。我统计了文本回退现象部分结果里出现的词到了最终结果里被改掉。正常情况下一段 10 秒的句子大约会产生 8~15 个 partial其中有 1~2 个词在过程中被修正这是正常的。如果修正太频繁说明模型在局部上下文里摇摆字幕会出现明显抖动。Gemini 3.5 Transcribe 的 partial 稳定性还算不错会议场景下大约 87% 的 partial 内容与 final 完全一致。这个指标不在官方文档里但我建议任何用流式接口的人都要自己统计一下因为它直接影响前端字幕的观感。3. 4.0% 的含金量五个压力场景的实测拆解3.1 安静环境不惊喜嘈杂环境才是分水岭我在安静办公室里播放标准朗读音频WER 2.1%说句实话这个水平跟市面上头部 ASR 差距不大没有给我太多惊喜。真正拉开差距的是嘈杂环境。咖啡馆场景背景音乐 零散人声信噪比大约 15dB实测 WER 5.8%比安静环境高出近 4 个百分点。但仔细看错误类型发现替换错误占据了 80% 以上而且是音近字错比如快速变成快速这类。这说明模型在噪声下不是听不清而是对混淆音的选择不够果断。这时候靠热词可以救回来一部分具体做法后面讲。远场说话人场景距离麦克风 1.5 米表现也出乎我意料一开始 WER 高达 9% 以上后来发现是增益问题前端做了一次 AGC 自动增益补偿之后降到 6.2%。这个事提醒我流式转写不是模型单方面的事前端音频质量直接影响最终效果。3.2 专业术语和热词数字的另一个真相医疗问诊这个领域组我专门多花了心思。里面有一堆专业名词比如阿托伐他汀钙片房颤射频消融术还有各种剂量的数字串。任选一个通用模型裸跑这类数据WER 很容易飙到 10% 以上因为模型没见过这些词只能按字面发音瞎猜。我用了两招来解决。第一招是热词列表也有的平台叫词汇表或自定义词表把领域常见词、科室名、药品名加进去并给一个适中的权重。加了热词之后领域组的 WER 从 7.6% 降到 3.8%效果非常明显。第二招是后端文本纠错针对数字单位组合做规则比如两克2克统一成2g。这一招不属于模型层面但工程上极其有效。有一个经验供参考热词别贪多尤其别给普通词加太高的权重。我一开始把 200 个常用词都加进去结果出现了房颤消融术这种误融合——模型开始频繁产出领域相关但上下文不对的词。后来把热词压缩到 50 个核心词权重分了三档问题缓解不少。3.3 口音、语速和重叠语音流式模型的软肋这套系统在广东普通话上表现一般WER 从基准的 2.1% 升到 4.6%。我能理解模型训练语料里标准普通话占比高方言口音属于长尾分布。如果业务里口音用户比例很高我建议单独收集口音音频做评测别只看整体指标。重叠语音两个人同时说话是这次实测里最让我头疼的场景。会议里经常出现插话、抢话模型在这个状态下会产生语音分裂或吞字。压力组里重叠片段的比例大概 10%但这部分贡献的错误率占了总错误的一半左右。Gemini 3.5 Transcribe 支持说话人分离speaker diarization但流式场景下分离质量明显不如离线模式。我最后的产品方案是重叠片段的转写结果保留原文不做降权但展示时用透明度区分置信度让用户知道这段可能不靠谱。4. 工程取舍的核心延迟、成本和质量的三角关系4.1 延迟和准确率的矛盾什么时候该牺牲 WER流式接口普遍有快速返回和稳定返回两种倾向本质上是同一个模型的不同参数配置。我这边实测下来如果把 partial 返回间隔从默认的 300ms 拉长到 600ms首词延迟会从 350ms 升到 520ms但 final 的 WER 能降低 0.6 个百分点。原因不难理解三角色频率越高模型看到的上下文越短错误概率越高。间隔拉长一点模型决策时参考的信息更多。问题来了这个延时你的业务能接受吗我做的是会议纪要用户字幕允许有半秒的滞后所以我把 partial 间隔调到了 500ms 左右在可接受延迟范围内换来了更稳的字幕流。如果你的场景是语音助手、实时字幕翻译延迟优先级更高那就得接受 partial 里多一些反复修正。另外还有个参数值得关注最长静音等待。默认值通常在 1.5 到 2 秒如果说话人停顿时间超过这个值模型就认为句子结束并返回 final。开会时经常有人呃……呃……半天停顿时间很长这时候要是不调这个参数文本会被切得稀碎后续自然语言处理的召回率会大幅下降。我把它调到了 4 秒句子完整度明显改善代价是每句话的结果等到得晚一些。这个取舍逻辑是宁可让一句话晚 2 秒出也别把一个完整观点切开。4.2 成本账流式接口不是一个廉价方案任何商业 ASR 的流式接口定价都比批量接口贵Gemini 3.5 Transcribe 也不例外。按我测试的量级流式价格大约是批量的 1.8~2.2 倍。为什么差这么多因为流式要求服务端持续维持连接、实时计算、随时返回部分结果资源的占用和浪费都比批量大。这里有个隐蔽的计费陷阱流式按音频时长计费但判断音频时长的口径很关键。有些平台按上行音频的总时长算有些按 VAD 检测到的有效语音时长算。如果业务现场经常有人不开麦克风但环境音一直传上去那么按总时长计费会让你花很多冤枉钱。我建议在接入前仔细核对计费文档最好做一次小流量账单验证——先跑三四天真实业务流量对比估算账单和实际账单确认一下计费口径。成本优化的方向有两条一是做前端语音活动检测只有检测到有效人声才把音频流交给转写服务环境静音直接拦截掉能省下不少时长二是降低并发峰值把转写请求排队用消息队列削峰填谷。前提是你的业务允许转写结果有一点延迟。4.3 稳定性与兜底流式服务的可用性实测我压测那几天总共跑了大约 60 小时的长连接音频流粗算下来遭遇了 4 次连接中断平均每次恢复时间在 20 秒左右。对于实时会议场景20 秒的文本空白是能感知到的所以兜底逻辑必须提前做好。我的做法是前端同时负责本地录音和上行转发转写服务连接中断时本地录音不打断重连后把断点前的音频重新补传给服务端。这个方案的前提是转写服务支持从某个时间点开始续传。当时我用的是手动判断客户端记录发送到哪个字节位置重连后从那个位置重新开始。注意了这里有个关键细节——补传的音频必须和实时流走的是同一条处理管道否则会因为音频格式、采样率的微小差异导致识别结果错位。另外限流问题要重点测。流式接口通常有并发连接数的上限有的还按项目维度限制并发数。我一开始没注意在 50 路并发压测时直接撞了限流大量转写请求开始排队RTF 飙升到 2.5字幕延迟肉眼可见。建议在架构设计阶段就把并发配额和业务高峰对齐宁可接一个流量控制层也不要依赖服务的即时扩容。5. 上线前必须处理的细节标点、VAD 和长会话5.1 标点、数字和英文大小写数据清洗不能省语音识别的输出原始内容包括文本、开始时间、结束时间、置信度有些还带标点和大小写。即使模型自带标点直接拿来用仍然会踩坑。我遇到一个典型案例医疗场景里医生说两片每天三次模型输出成两片每天三次少了逗号导致用药指令的语义变化。另一个例子是数字二零二四被模型当成中文数字输出而业务系统需要阿拉伯数字。这些都不是模型错误而是输出格式与业务需求的错配。我的建议是在模型输出后加一层格式层做这些事中文数字统一转阿拉伯数字白话说三点五毫克输出3.5mg英文单词转小写或统一首字母策略按业务字典修正领域常见词比如吃一片要不要统一为1片断句标点按照句子完整性再整理一遍去掉让 NLP 模块困惑的零散碎片这层逻辑看起来和 ASR 无关但做好了下游摘要、实体抽取的准确率能提升 5%~10%。5.2 VAD 切边和端点检测的配合VAD语音活动检测是流式转写的隐形大战场。模型的 VAD 和前端自研的 VAD 是两回事很多集成失败案例就出在两者打架。我最初的做法是前端用自己的 VAD 判断人声开始然后才开始往转写服务发音频。这样确实能节省流量但问题也来了前端的 VAD 和模型的 VAD 阈值不一致前端已经判断没人说话并且断了流模型这边还在等后续音频断句被硬生生掐断。后来改成前端 VAD 只做流控超过一定静音时长就停止发送但不主动掐断把断句决策完全交给服务端的 VAD。这样改了之后final 结果的句子完整性明显好转。另外还有个经验VAD 的前置填充pre-roll很重要。也就是说当检测到人声开始后向前回退 200~300ms 把音频补进去避免句首第一个音被 VAD 吃掉。句首音可是 WER 的大户一个呃字被吞掉整句话意思可能就不对了。5.3 长会话与上下文一场一小时会议怎么不停顿流式接口会维护一个会话上下文所以一旦会议持续一个小时上下文累积对结果的影响需要专门处理。实测发现会议开到后面早期提到的专属名词比如某个项目的代号云帆在后续转写里会更容易被识别正确这是上下文带来的好处。但反过来如果会议中途话题完全切换模型可能还带着旧话题的下意识倾向导致新话题的某些词组被强制匹配到旧词上。我的处理方案是提供上下文重置机制允许业务方在检测到明确的话题切换比如主持人说我们进入下一个议题时清空会话或者注入新的话题提示词。这个功能在文档里不一定有需要看平台是否支持。如果不支持可以退而求其次用热词列表的替身来影响当前会话的倾向性。5.4 异常输入的保护非语音音频还有一个很容易被忽略的场景参会人那边没说话但传来了鼠标点击声、键盘声、甚至短视频外放。模型面对这些非语音输入时可能会输出一些毫无意义的幻觉文本——也就是听起来像语言、实则完全随机的字串。这在流式场景下特别恼人因为它们也会成为 final 结果污染下游摘要。我实测里键盘敲击声偶发会触发幻觉文本概率大约 2%。处理方式是给 final 结果做一个置信度阈值过滤——当整句平均置信度低于某个值我这边取的是 0.45丢弃该句并标记为非语音。这个操作简单但能挡掉大部分幻觉污染也能减少对用户注意力的干扰。6. 最后聊几句实测感受我花在评测上的时间很多但回头看真正影响项目成败的不是模型本身而是围绕它做的工程决策。WER 4.0% 这个数字单独拿出来不能说明任何问题只有把它放进你的业务场景、你的延迟预算、你的成本范围里它才算一个有用的参考值。这里有一个总体印象Gemini 3.5 Transcribe 的流式转写在通用场景下属于第一梯队准确率和稳定性之间的平衡点调得不错尤其是 partial 的稳定性让人省心。但它在强口音、强噪声场景下并没有神奇到超越物理规律还是需要配合前端增益、热词列表和置信度过滤来压住错误。如果只看一个数字来决策我建议不管换哪家服务都先按我第二部分的方法建一套自己的评测集跑三天真实流量再做决定。语音识别这个领域每个人的4.0%含金量都可能完全不同拿别人的数字直接套用大概率会在生产环境里翻车。最后分享一个可复用的经验所有流式转写服务的调优本质上是在延迟、成本和准确率之间做三角取舍。你不可能三者全占只能根据业务核心诉求选择牺牲谁。像我这种会议纪要场景延迟要求中等、成本敏感、准确率要求高所以我的取舍顺序是先守住准确率再谈延迟优化最后抠成本。如果你的业务是实时字幕翻译可能第一优先级就是延迟。想清楚自己的优先级再去调那些参数就不会被厂商的基准分数牵着鼻子走。