做转录这行的都清楚ASR最让人抓狂的从来不是识别不出来而是识别出来了但错得莫名其妙。一段四十分钟的访谈人声清清楚楚转出来文本里人名错三个、数字错两个、中英混说的地方直接糊成一团你还得逐句对着音频校一遍——本来想省时间结果比自己听打还累。所以当看到ASR转录总出错、新模型WER降到2.6%、还能自动帮你改口误这类消息时多数人的第一反应是数字挺好看第二反应才是这跟我的活儿有什么关系。这篇就把这件事掰开说清楚WER 2.6% 是在什么口径下测出来的、口误自动修正到底动了文本的哪一层、以及普通团队怎么在自己的转录流水线里落地这套思路。核心关键词就三个——ASR转录质量、WER指标、口误修正全文都围着它们转。适合谁看正在做会议记录、访谈整理、课程字幕、客服质检、播客转写这类业务的技术同学也适合不写代码、但要判断要不要换引擎要不要上自动修正的产品和运营。不讲虚的讲能抄作业的部分。1. 先别急着高兴WER 2.6% 到底是个什么概念1.1 把 WER 的公式摊开才知道这数字有多难WER 全称词错误率公式本身朴素得不像个指标WER (S D I) / NS 是替换错误substitution该念 A 念成了 BD 是删除错误deletion音频里有但文本里漏了I 是插入错误insertion音频里没有但文本里多了N 是参考文本的词总数。注意分母是参考文本的词数不是识别结果词数——这一点很多人第一次做评估时会搞混导致算出来的数偏高或偏低。中文场景更常用 CER字错误率因为中文分词本身有歧义词这个单位不牢靠。CER 的分母是参考文本的字数通常不含标点。我一般两个都算对外汇报用 CER 更贴近中文用户感知对内做模型对比用 WER 更稳定。举个具体例子。参考文本 100 个字识别结果里错了 3 个字1 个替换、1 个删除、1 个插入插入的字也算那 CER 就是 3%。听起来不高但换算成实际工作量一场两小时、约 2.5 万字的会议转录3% 意味着750 处要改的地方。这就是为什么99% 准确率这种话在业务侧没什么说服力——分母太大了尾巴上那点错误足够让人加班。所以看到 2.6%先别急着换算成能省多少人力先问三个问题这是 WER 还是 CER、测试集是朗读还是自然对话、有没有用外部语言模型重打分。这三个条件一变同一个模型能差出好几倍。1.2 测试集口径决定一切朗读语音和真实会议是两个世界业内公开结果里2.6% 这种量级的数字绝大多数出现在朗读式、近场、干净录音、单一说话人的测试集上。这类数据的特点是发音清晰、语速均匀、没有背景噪声、没有重叠说话、没有口头禅。模型在这种数据上做到 2%~3% 很正常甚至人类标注员之间的一致性差异也有 2% 上下——也就是说到了这个区间你很难分清是模型错了还是标注标准本身有分歧。但业务里的音频长什么样我手上跑过的真实数据大概是这个分布音频类型典型 WER 区间主要错误来源近场朗读、播客单人3%~6%专有名词、数字视频会议、双人对话8%~15%重叠说话、口音、网络丢包多人圆桌、远场麦克风15%~25%混响、串音、抢话电话客服、8k 窄带20%~35%带宽损失、方言、背景音带口音中英混说20%~40%语码转换、音译不一致这张表不是精确统计是我这几年做项目攒下来的经验区间用来做预期管理足够。它的价值在于当有人跟你说某模型 WER 只有 2.6%你可以直接反问在我的会议场景下是多少。如果对方拿不出场景化评测那这个数字对你就只是个营销素材。提示任何模型选型都必须在自己的真实音频上跑一遍评测集。至少 200 条、覆盖你业务里最难的 20%否则不要签字。1.3 从能听清到能直接用差的不是那几个点真正决定转录文本能不能直接用的往往不是整体 WER而是实体错误率和结构化完整度。我在项目里做过拆解一段会议转录整体 CER 12%看起来很差但把错误按类型拆开填充词和重复占了 6 个点专有名词占 3 个点数字占 2 个点真正的语义错误只有 1 个点。这意味着什么意味着去掉 6 个点的填充词和重复文本可读性会立刻上一个台阶而这恰恰就是自动帮你改口误要解决的问题。它不提升声学识别能力但它把能听清的废话删掉让剩下的内容更接近可直接使用的稿子。所以这两个能力降低 WER 口误修正是互补的不是一回事。顺带说一个常被忽略的点标点和断句。WER 计算通常会把标点去掉再比但在实际交付里一段没有标点的三千字文本基本没法读。字幕场景还额外要求断句长度适配单行显示。这些不计入 WER的东西才是用户真正感知到的质量。2. 自动改口误到底改了什么把口误拆成三层2.1 第一层是填充词最好处理也最容易误伤填充词filler就是那些不承载语义的语气垫片中文里的那个就是说嗯呃然后然后英文里的 um、uh、you know、like。它们在自然口语里密度很高一场随意聊天里每分钟出现五到十次很正常。处理方式最朴素词表匹配 位置判断。但直接全局删除会出问题我踩过两次坑。第一次是把那个方案里的那个当填充词删了变成方案语义虽然还在但语气变了第二次更糟把用户说的我说的是那个这个词里面的那个删掉直接改变了被引用的内容。后来我改成三条规则只在词前后都是停顿、且不充当指示代词时删除。判断指示代词靠上下文简单做法是看后面是否紧跟名词且中间无停顿。句首的然后保留一次连续出现才删。因为句首然后有时是真实的时序连接词。引用、列举、代码口述场景整段跳过修正。这一条最重要宁可漏删不可错删。填充词删除的收益是立竿见影的一段口语化访谈删掉填充词后字数能少 8%~15%可读性提升非常明显。这也是为什么我建议把口误修正作为独立模块而不是直接依赖模型输出——独立模块可配置、可回滚、可针对业务调规则。2.2 第二层是重复和卡顿需要靠时间和文本双重判断重复分两种。一种是音节级口吃比如这个这个这个项目处理起来简单连续相同词超过两次就压成一次。另一种是短语级重启我们需要在下周……我们需要在下周五之前把方案定下来这种前半截是被废弃的草稿删掉前半截才是干净文本。难点在于判断哪一截是废弃的。我的经验是靠三个信号重复片段之后的版本更长、更完整通常后者是最终意图。中间有停顿标记ASR 的时间戳间隔大于 300ms 就要警觉。出现了修正引导词比如不对应该说准确讲我重说一遍。三个信号里有一个成立就可以把前面的片段标记为候选删除有两个成立基本可以放心删。只有时间戳没有文本特征的建议只做高亮提示交给人工决定别自动删。这里有个实操细节删掉片段之后时间戳必须同步调整否则字幕会错位。我在一个项目里见过最典型的事故——文本改对了但字幕时间轴没跟着改导致后面整段字幕提前了两秒用户投诉字幕和声音不同步。所以修正模块的输出必须是文本 时间戳 修改日志三元组不能只给文本。2.3 第三层是自我修正动了它就要承担责任自我修正是最危险的一层。我建议我们周五——不周四发版正确的最终文本是我建议我们周四发版。但要生成这个结果模型必须理解不这个词的否定作用域并且知道被否掉的是周五。这类修正在会议纪要里非常有用因为口头表达里说错再改的比例相当高。但它的风险也最大一旦误判就会把用户真实表达的两个选项压成一个甚至压成相反的意思。我见过一个反例原话是这个方案我不建议周五上线周四更合适如果规则只抓周四更合适就把前面删了直接变成这个方案周四上线更合适意思完全变了。所以我的做法是分级处理只删重复和填充词对自我修正只标记不自动改适合法务、医疗、审计类场景。明确修正引导词不对说错了我改一下 短距离前后 10 个字内时自动改适合会议纪要、访谈整理。全自动改写只建议在纯内部、可回溯的场景用且必须保留原始音频链接和一键还原。注意任何自动修正都必须保留原文。可回溯是这条流水线的底线不是可选项。3. 落地实操把一条可用的转录流水线搭起来3.1 音频预处理与切分参数选错后面全白搭模型再强也救不了烂输入。我现在的标准预处理流程是这样的采样率统一到 16kHz、单声道、16bit PCM。这条几乎是所有语音模型的事实标准。有人图省事直接传 44.1kHz 立体声模型内部会重采样多花算力还容易引入相位问题。转码命令我一般用ffmpeg -i input.mp4 -vn -ac 1 -ar 16000 -sample_fmt s16 -f wav output.wavVAD 切分块长 20~30 秒重叠 0.5 秒。为什么要重叠因为切点很容易落在字中间重叠区能让模型在边界上有上下文。30 秒是权衡结果太短则上下文不足、专有名词识别率下降太长则显存吃紧、且一旦某块失败重试成本高。实测 25 秒加 0.5 秒重叠是比较稳的配置。响度归一化到 -23 LUFS 左右避免一段声音大一段声音小导致识别质量抖动。这一步很多人跳过但在多人会议录音里收益明显。去混响和降噪要克制。我吃过亏为了压掉空调噪声开了强降噪结果人声的高频被削掉齿音消失反而让四和十更难分辨。经验是降噪强度只用中档且必须 A/B 对比降噪前后的 CER涨了就退回去。3.2 上下文偏置与热词注入专有名词的错率能砍掉一半真实业务里最痛的错误不是通用词是人名、产品名、项目代号、专业术语。这类词在通用语料里出现频率极低模型没见过自然识别不准。解决办法是上下文偏置contextual biasing把业务词表喂给解码器。两种常见注入方式解码时偏置。把词表转成发音序列在解码图里给这些路径加权。优点是生效直接缺点是权重调不好会幻觉——模型过度倾向输出词表里的词把正常语音硬掰成热词。我一般把偏置权重设在中低档且词表控制在 500 条以内太长了会稀释效果。解码后纠错。用编辑距离 拼音相似度做兜底替换。比如识别出李红涛而词表里有李宏涛拼音完全相同、编辑距离为 1就可以替换。这一层要设阈值编辑距离超过 2、或拼音声母不同的不改。# 基于拼音相似度的热词纠错简化示意 from pypinyin import lazy_pinyin def pinyin_sim(a, b): pa, pb lazy_pinyin(a), lazy_pinyin(b) if len(pa) ! len(pb): return 0.0 hit sum(1 for x, y in zip(pa, pb) if x y) return hit / len(pa) def correct(text, hotwords, thresh0.85): for hw in hotwords: if hw in text: continue for i in range(len(text) - len(hw) 1): seg text[i:i len(hw)] if pinyin_sim(seg, hw) thresh: text text[:i] hw text[i len(hw):] break return text这段代码很粗糙只做示意——真实场景要加词性判断、要避免替换掉本来就是对的词、要记录修改日志。但方向就是它拼音是中文热词纠错最有效的桥因为同音近音错误占了中文识别错误的很大一块。3.3 口误修正模块写成可配置的规则链别写成一个黑盒我倾向于把修正做成一条顺序执行的规则链每条规则独立开关、独立计数。这样出问题能定位到具体哪条规则也能按业务场景组合不同策略。推荐的处理顺序是标点与断句恢复先做因为后面规则依赖句子边界数字与单位规范化ITN把一千二百三十转成1230填充词删除配置化词表默认开启连续重复压缩同一片段出现 3 次以上压成 1 次自我修正处理默认关闭按场景开启热词纠错拼音相似度顺序不能随便换。先做填充词删除再做自我修正是因为填充词会干扰前后 10 字的距离判断先做标点再做其他是因为句边界是很多规则的前提。每次修正都要写日志格式建议{位置, 原文, 修正后, 规则名, 置信度, 是否需人工复核}这份日志的价值在后期的错误归因跑一个月你就能知道哪条规则误伤最多该关掉或调阈值。没有日志的自动修正系统等于给自己埋雷。3.4 结果校验置信度、时间戳与人工复核队列自动化的终点不是全自动是把人工放在最该放的地方。我的做法是给每段文本算一个综合风险分信号含义处理建议模型平均置信度低于阈值声学不确定进人工队列出现低置信度实体人名/数字关键信息可能错单独高亮修正模块改动超过 3 处文本被大改附带原文对照音频重叠率高、信噪比低输入质量差整段标记待核时间戳间隔异常5s 静音可能漏识别回听确认这套分级的结果是大约 70% 的片段可以低风险直出20% 需要看一眼高亮处10% 必须回听。比起全量校对人力投入能降六七成——这才是这类技术真正的价值所在不是不用人是让人只做机器做不了的事。4. 常见问题与排查实录坑都在这了4.1 高频问题速查表现象大概率原因排查动作数字频繁错十四↔四十语速快、齿音弱、降噪过强关降噪复测看是否恢复专有名词全错未注入热词或权重过高检查偏置词表与权重中英混说段落糊成一片模型未做语码转换训练分段检测语种分别送不同模型长音频后半段质量骤降未分块或分块过长改 25 秒分块加重叠字幕整体偏移修正文本未同步时间戳检查修正模块输出三元组文本通顺但语义反了自我修正规则误删关闭自动改写改标记模式同一段两次识别结果不同解码随机性或模型版本不一致固定随机种子锁定版本号标点缺失、整段一逗到底未接标点恢复模块单独加标点模型4.2 几个容易被忽略的细节版本锁定。这类模型迭代很快接口背后可能悄悄换版本。我遇到过一次周五晚发版周一发现所有历史转录风格变了原因是上游引擎更新。解决办法是所有请求带上版本标识且本地保留一份固定版本的模型做对照。没有版本锁定的流水线等于把质量交给运气。长音频的内存与超时。两小时音频一次性送进去多数接口会超时或截断。正确做法是本地切分 并发 结果按序拼接。并发数别开太猛我一般按服务端限流的一半来设否则大量请求被拒后重试反而更慢。说话人分离的坑。多人场景下光有文本不够得知道谁说的。分离diarization错误会直接导致纪要张冠李戴。我的经验是分离结果一定要和文本时间戳对齐校验遇到某人在同一时刻说两句话这种矛盾自动标记为低置信。另外说话人数在 5 人以上时分离准确率下降明显建议提前告知用户多人场景建议分轨录音。中英混说的处理。这是中文业务里最麻烦的一块。同一句话里这个 feature 我们下周 release通用中文模型经常把英文识别成音近的中文字。我的做法是先做语种片段检测把纯英文片段单独送英文模型中文片段送中文模型边界处用重叠加权合并。费力但效果比单模型硬扛好得多。4.3 效果评估怎么做才不失真评估集的建设比模型选择更重要。我见过太多团队犯同一个错拿一段自己录的干净音频测了 95% 准确率上线后被真实数据打回原形。我现在的评估集按这个比例构建50% 日常业务音频真实场景随机抽25% 困难样本带口音、有噪声、重叠说话、中英混说15% 实体密集样本人名、数字、术语多的场景10% 已知历史事故样本每次线上出问题都回灌进来每次模型或规则变更全量跑一遍看三个指标整体 CER、实体错误率、修正模块的误伤率把本来对的地方改错了的比例。第三个指标最容易被忽略但它直接决定用户信任度——改错一次用户就会关掉自动修正再也不开。提示误伤率高于 1% 的规则一律下线或降到仅标记模式。宁可少改不可改错。5. 成本与选型什么规模该调接口什么规模该自建5.1 算一笔账RTF、并发和真金白银RTF实时率等于处理时长除以音频时长。RTF 0.05 意味着 1 小时音频用 3 分钟处理完。这个数直接决定你的成本结构。假设每天 200 小时音频RTF 0.05单卡每小时能处理 20 小时音频理论上 10 小时算力就能跑完一天的量——听起来很宽裕但真实业务有峰值早会后和下班前两个时段可能占全天 60% 的量所以并发要按峰值算不能按均值算。我一般按均值的三倍配并发。成本对比大概是这样量级示意不含带宽和存储方案单小时成本适用规模隐性成本调商用接口中日处理 50 小时按量计费量大后线性增长自建小模型低日处理 200 小时运维、模型更新、GPU 闲置混合难易分流低到中任意分流逻辑的复杂度混合方案是我最推荐的简单音频走小模型或低档接口难音频走高精度模型。用 VAD 结果、信噪比、重叠率做个初判简单样本占 70%成本能直接砍掉一半而整体质量只降一点点。判断逻辑很简单信噪比高于阈值、无重叠、单说话人的走便宜通道其余走高精度通道。5.2 什么时候该自己动手改规则什么时候该换模型这条判断线我总结成一句话如果错误是有规律的改规则如果错误是随机的换模型。有规律的错误长这样专有名词全错、数字总在特定口音上错、英文单词被识别成音近中文。这类问题规则层能解决投入小见效快。随机的错误长这样各种词随机错、清晰录音也错、换个说话人就崩。这说明模型的声学能力不够规则再怎么调也没用该换模型或者加数据微调了。还有一个折中手段常被低估多模型投票ROVER 思路。同一段音频用两个不同模型跑逐词对比一致的直接采信不一致的标记出来。实测能把实体错误率压下去一截代价是双倍算力。用在关键字段人名、金额、日期上性价比很高不值得全篇用。最后分享一个我踩了很多次坑才养成的习惯每次改动都留一个 20 条的金标准样本先跑它再跑全量。这 20 条覆盖了你业务里最刁钻的情况——最难的口音、最密的术语、最糟糕的录音环境。如果这 20 条的指标没有退步再放量退步了先别管整体指标多漂亮回去查原因。这套小成本回归测试帮我避免了至少三次线上事故比任何自动化监控都实在。至于口误自动修正这类能力我现在的态度是默认开填充词和重复压缩默认关语义级改写。前者几乎无风险且体感提升明显后者风险收益比不划算除非场景明确允许。技术能做到什么是一回事敢不敢让它替用户做决定是另一回事——这条线上保守一点永远不吃亏。
