做语音转写这几年，最常被问到的问题不是“识别准确率多少”，而是“为什么它老把我说的名字写错”。这两件事其实是同一个问题的两面：整体错误率（WER）这个数字在慢慢变好看，最近有研究团队公布了一个2.6% 的 WER，放在几年前属于“朗读语料专用”的水平，现在被搬到了更接近真实口语的场景里，同时还带了一个新能力——自动帮你改口误，也就是把“我我我觉得这个方案——不对，是那个方案”这种带毛刺的原话，整理成一句干净的话。这篇文章我想把这套东西拆开讲：2.6% 这个数字是在什么口径下算出来的、剩下的错误到底集中在哪几类、自动改口误背后的判定逻辑是什么、以及如果你是工程侧的人，怎么在自己项目里复现一套“评测 + 纠错”的流水线。做过会议记录、访谈整理、客服质检、字幕生成的朋友，应该都能直接用上。
1. 把 2.6% 这个数字掰开看：WER 的口径比数值本身更重要
看到一个新低错误率，第一反应不该是“厉害”，而是“它跟我的场景差多远”。我见过太多团队拿公开榜单的数字去对标自己的业务，最后发现对方测的是近讲朗读、自己是远场会议室，中间差了一个数量级的难度。所以在讨论 2.6% 之前，先把度量本身讲清楚，这一步不做，后面所有的优化都是盲人摸象。
1.1 一次手工验算：WER 到底怎么算出来的
WER 的全称是词错误率，公式本身简单到不像话：
WER = (S + D + I) / N其中S是替换（识别成了别的词）、D是删除（漏了词）、I是插入（多出词），N是参考文本的词数。分母用的是“标准答案”的长度，不是识别结果的长度，这点很多人会记混，导致自己算出来的数字跟平台对不上。
拿一句短的走一遍。参考文本是“今天下午三点开会”，识别结果给出“今天上午三点开会吧”：
| 参考 | 识别 | 类型 |
|---|---|---|
| 今天 | 今天 | 正确 |
| 下午 | 上午 | 替换 S=1 |
| 三点 | 三点 | 正确 |
| 开会 | 开会 | 正确 |
| - | 吧 | 插入 I=1 |
N=4，S=1，I=1，WER = 2/4 = 50%。一句话的 WER 就是这么容易被拉到 50%，所以评测集少于 200 句基本没有统计意义，随便一句错的就能让数字跳好几个点。我自己做内部评测时，起步就是 300 到 500 句，并且按场景分层，最后看分场景的子集指标，而不是只看一个总数。
中文还有个额外麻烦：到底是按“词”算还是按“字”算。按词算就得先分词，而分词标准不一致会凭空造出错误——参考文本把“人工智能”切一个词，识别结果切成“人工/智能”，字面完全一样却可能被判成错误。所以中文场景我更倾向用字错误率（CER），把每个汉字和标点当作一个 token，误差来源干净得多。看到“2.6%”这种数字，第一件事是确认它是英文词级 WER 还是中文字级 CER，是两个完全不同的东西。
1.2 为什么同一个模型能测出 3% 也能测出 25%
下面这张表是我自己整理的对标口径清单，不同团队报数时基本都在这几个维度上有偏移：
| 维度 | 宽松口径（数字好看） | 严格口径（贴近真实） | 典型差距 |
|---|---|---|---|
| 说话方式 | 朗读、念稿 | 自发口语、边说边想 | 2 到 4 倍 |
| 录音条件 | 近讲耳麦 | 远场阵列、手机免提 | 2 到 5 倍 |
| 说话人 | 单人、标准口音 | 多人、带方言口音 | 1.5 到 3 倍 |
| 是否重叠 | 无重叠 | 有抢话、插话 | 局部翻倍 |
| 文本处理 | 做了数字、标点归一 | 原样比对 | 10% 到 30% 差异 |
| 是否用外部语言模型 | 开了重打分 | 纯声学输出 | 5% 到 15% 差异 |
我做过一个内部测试，同一套模型，在朗读稿上 CER 是 3.1%，切到真实会议的远场录音（8 人圆桌、有空调噪声、有抢话），CER 直接飙到 18.7%。模型没变，变的只是测试集。所以当某个团队宣布“WER 降到 2.6%”时，如果它同时说明了“在近场朗读语料上”，这个数字是可信的；如果它宣称“在各种真实场景都达到 2.6%”，那大概率是口径做了手脚，或者用了极窄的领域语料。
我自己的经验是：真实自发口语场景下，字错误率能做到 8% 到 12% 已经是很能打的水平，2.6% 这个量级更适合理解成“在受控条件下逼近了人工转写的水平”，而不是“所有场景都不用人工校对了”。
1.3 从 25% 压到 2.6%，最后剩下的错误长什么样
这一点特别关键。错误率下降的过程不是均匀的，它是先扫掉大批“低级错误”，最后卡在一批“硬骨头”上。按我的观察，从 20% 压到 5% 的阶段，主要是声学模型和语言模型的常规进步在起作用；从 5% 压到 2.6% 这一段的收益，几乎全部来自三处：
- 专有名词与人名：这类词在通用语料里出现频次极低，模型没有先验，只能靠上下文偏置或者热词表救；
- 数字、时间、金额、单位：“两千万”和“两千万零”的区别、电话号码的连读切分，都是典型坑；
- 口语自身产生的非流利：重复、重启、自我修正、填充词，这类东西在标准答案里怎么标注本身就是个争议。
前两类是“识别错了”，第三类严格说不是识别错，而是“识别对了但不该出现在最终稿里”。过去的评测集大多在标注时就悄悄把填充词抹掉了，所以模型从来没被要求处理这个问题。这次同时提“自动改口误”，本质上就是把第三类错误正式纳入优化目标——这也解释了为什么它值得单独拿出来讲。
2. 转录出错的真实分布：先分类，再谈修
我在项目里排查识别问题时有个习惯：不看整体错误率，先把错误逐条过一遍，手工打上来源标签。一般过 200 条就能看出趋势。不做这一步，你根本不知道该去调声学端、语言端还是后处理端，很容易陷入“换个模型试试”的循环，试了七八个版本，指标原地打转。
2.1 声学层：远场、口音、噪声、抢话
这一类错误的特征是连人耳听都费劲。典型场景是会议室里的远场麦克风：说话人离麦三米，声音经过墙面反射，混响时间拉到 0.5 秒以上，前一个字的尾音糊到后一个字上。加上空调、投影仪风扇的稳态噪声，以及隔壁工位的说话声，声学特征被污染得很厉害。
我遇到过最棘手的是重叠说话。两个人同时开口，模型只能输出一路结果，通常会产出一个融合了两边内容的“缝合怪”句子。这种情况下 WER 之类的指标意义不大，因为参考文本本身就没法标。我的处理方式是引入说话人分离（把音频按说话人切成段）再逐段识别，代价是延迟增加、切分错误会传导到识别端，但整体比硬扛要好。
口音这一块要单独提。普通话带南方口音、带儿化、带方言词汇混入，都会显著抬高错误率。可行的缓解手段是用目标人群的少量数据做领域自适应，哪怕只有 5 到 10 小时带标注的微调数据，也能把该人群的错误率压低三到四成。这一步的性价比远高于换一个更大的通用模型。
2.2 语言层：专有名词、同音词、数字、中英混说
这一类最让人抓狂，因为音频明明清晰，人耳一听就懂，模型就是写错。原因不在声学，在语言模型的先验不够。
同音词是重灾区：“期中”和“期终”、“实时”和“实施”、“权限”和“全险”。单看一句“下周进行期终考试”和“下周进行期中考试”，声学特征几乎一样，只能靠上下文判断。人名和机构名更麻烦，一个生僻的员工姓名，模型可能给出三个不同的错误写法，同一个文档里前后不一致。
数字的处理尤其要注意。中文口语里“一千二”表示 1200，“十二”和“一十二”是同一个意思，电话号码“幺三八”里的“幺”要还原成“一”。这些如果交给模型端处理，模型会倾向于输出它训练时见过的高频形式；交给后处理端处理，规则又很难覆盖全。我的建议是统一在一层归一化里做，别让它分散在模型、后处理、导出三个地方，否则一旦出问题根本查不清是谁改的。
中英混说在技术团队里几乎是默认状态：“这个 feature 我们先 prioritize 一下”。这类句子的错误往往出在语种切换点上，前面中文的发音习惯会污染后面英文单词的声学建模。可行的做法是在解码时启用多语种联合建模，或者在热词表里把常用英文术语全部登记进去。
2.3 说话人自己制造的“非流利”：口误、重复、自我修正
这一层是我最想重点聊的，因为它就是“自动改口误”要解决的对象。日常说话根本不像写文章，一段真实的口语转写出来是这样的：
我觉得这个方案呢，就是，嗯，从成本上来看，其实是，呃，稍微有点，有点超预算了，不过——不对，我重新说一下，如果按季度摊销的话是可以接受的。
这句话里有五种不同的现象：
| 类型 | 例子 | 处理倾向 |
|---|---|---|
| 填充词 | 嗯、呃、那个、就是说 | 一般删除 |
| 重复 | “有点，有点” | 合并为一个 |
| 错误开头 | “我觉得这个方案呢” 后接重启 | 删除废弃片段 |
| 自我修正 | “不过——不对，我重新说一下” | 保留修正后的内容 |
| 延长音、拖音 | “这个——” | 一般不保留 |
关键在于，这五类的处理策略并不一样，一刀切地删是不行的。比如“那个”在“那个方案”里是指示代词，是实词，删了就变味；而在“那个，我想问一下”里就是纯填充词。这类判断必须有上下文，这也是为什么纯规则方案很难做好、而模型方案又有过度修改风险的原因。
3. 自动纠口误的实现路径：检测、判定、改写三段式
很多人的第一反应是“把嗯呃啊这些词加到一个停用词表里，直接正则替换掉”。我一开始也这么干过，结果在一个访谈项目上翻车了：受访者说“我不是那个意思”，被处理成“我不是意思”。这个坑让我彻底放弃了粗暴删除的思路，转而去做正经的三段式流水线。
3.1 为什么不能直接按停用词表删
除了上面那个语义误伤的例子，直接删还有三个隐藏代价。
第一是时间戳错位。字幕场景里每个词都带着起止时间，你删掉了“嗯”，前后两个词的时间间隔就出现了一个空洞，播放时字幕会突然跳一下。正确的做法是删词的同时把时间区间合并给相邻词，这个逻辑必须在数据结构层面处理好，不能只改字符串。
第二是破坏可追溯性。原始转写是证据，改过的文本是成品，这两者必须能对应上。医疗、法务、质检这类场景，客户会问“原话到底是怎么说的”，如果你的后处理是原地覆盖，就再也答不上来了。所以我坚持后处理输出一份 diff，记录每一次删除和替换的位置与理由。
第三是过度清洗导致语体失真。访谈类内容里，受访者的犹豫和停顿本身就是信息，全部抹掉会让文本读起来像新闻稿，失去了口语的真实感。有些客户明确要求“保留语气词，只清理明显的重复”，这种需求用可配置的清洗强度就能满足，前提是你的流水线是分级的，而不是一个正则一把梭。
3.2 检测环节：把“要不要动”变成一个可训练的问题
检测阶段的目标，是给转写文本里的每个 token 打一个标签，判断它属于“保留内容”还是“非流利片段”。业界常用的是序列标注思路，标签集大致是这几种：
O：正常内容，不动；FILL：填充词；REPEAT：重复片段；REPAIR：被修正掉的废弃片段；EDIT：修正后保留的内容。
训练数据从哪来？最直接的办法是人工标注。我做过一版，规则是：让标注员对着音频听，把每一处“说话人自己推翻或停顿”的地方框出来，同时标出保留哪一段。500 条左右的标注就能训出一个可用的基线，成本大概两三个人天。
除了模型，还有一批廉价但有效的信号可以直接当特征用：
- 词本身是否属于高频填充词集合；
- 该词前后的停顿时长（从强制对齐拿到，超过 300ms 的停顿是重要线索）；
- 是否存在相邻重复（“我我”“就是就是”）；
- 该词是否是句首孤立成分；
- 识别置信度（很多填充词发音含糊，置信度偏低）。
把这几条做成规则打分再加模型兜底，是投入产出比最高的组合。纯规则能把 70% 的显性填充词捞出来，剩下的交给模型，误伤率能控制在可接受范围。
3.3 改写环节：删除式与改写式的边界在哪
检测出来之后，怎么改就是 второй个决策点。这里有两种策略，适用场景完全不同。
删除式最保守：只删，不增不改。它保证了“不会引入原文没有的信息”，代价是遇到自我修正时会留下语义断裂。比如“周三，不对，周四”，删掉“周三不对”变成“周四”，这没问题；但“我建议延期，不是，我是说推迟到下个月”，删掉前半段后语义是完整的，可如果删错了位置就会变成“我建议延期到下个月”，意思全变了。
改写式能力强得多，可以让模型做句子重组。风险也随之放大：模型可能顺手把“大概三百万”改成“三百万”，把模糊限定词吃掉；也可能把口语里的否定语气抹平。我在实际项目里给改写式加了几条硬约束，写进 prompt 里效果很稳：
你是语音转写后处理器。输入是一段带口误的原始转写。 必须遵守： 1. 只允许删除填充词、重复片段、被说话人自己推翻的废弃内容； 2. 允许合并重复词、补全省略的主语，但不得新增原文没有的事实； 3. 人名、机构名、数字、时间、金额、否定词一律不得修改； 4. 每一处修改输出一条理由，格式：原文片段 -> 修改后，理由； 5. 若判断不确定，保持原样，宁可不改。第 5 条是最重要的。我宁可让模型放过一半的口误，也不要它自作主张改错一处关键信息。实践下来，加这条约束后，语义漂移的案例从每百句两三处降到了接近零。
3.4 一个可执行的判断清单
在规则层，我总结了一张速查表，用来处理那些模型也拿不准的边界情况：
| 现象 | 处理动作 | 备注 |
|---|---|---|
| 句首的“那个”“就是”后接停顿 | 删除 | 有停顿才删，无停顿大概率是实词 |
| 词内重复（“我我觉得”） | 合并 | 保留一次即可 |
| 短语重复（“这个方案，这个方案”） | 合并 | 若两次之间有修正内容则保留后者 |
| “A，不对，B”结构 | 保留 B | 前提是 A 明显被推翻 |
| “A，或者说，B” | 两者都保留 | 这是补充说明，不是修正 |
| 句尾的“啊”“吧”“呢” | 保留 | 语气助词承载态度，不属于口误 |
| 数字前的犹豫词 | 删除犹豫词，保留数字 | 数字优先级最高 |
提示：表里每一条都是我自己踩过坑之后加进去的。“或者说”被当成修正删过一次，客户当场指出原意是“两个都对”，这类补充关系在整个体系里必须有单独一档。
4. 在自己项目里复现：评测流水线加纠错后处理
前面讲的是原理，这部分讲怎么落地。我给的建议是：先做评测，再做纠错。顺序反了会非常痛苦，因为你没有度量，就无法判断后处理到底是帮忙还是添乱。
4.1 评测集怎么造才不骗自己
自建评测集有几个硬要求，我按重要性排：
第一，冻结。评测集造好之后打上版本号，任何人不得用它调参。这一条被违反的概率极高，因为团队赶进度时最容易“顺便拿测试集看看效果”。我见过一个项目，模型迭代了六版指标一直在涨，上线后原地爆炸，最后发现测试集里的句子在训练数据里出现过。
第二，分层。至少按“录音条件”和“说话人类型”分两层。近场和远场分开报，标准口音和带口音分开报。合并报一个总数看起来漂亮，但会掩盖掉你最需要修的那一块。
第三，场景覆盖。拿会议场景举例，我的评测集构成大致是：常规议题讨论 40%、含大量专有名词的技术评审 25%、含数字与时间点的排期会 20%、含抢话的自由讨论 15%。这个比例是按业务真实占比配的，不是拍脑袋。
第四，双人标注。同一段音频由两个人独立转写，然后再对齐一次，把两人不一致的地方拿出来定夺。这一步很枯燥，但能暴露出“到底什么算标准答案”这类争议，比如口头禅要不要标、数字用阿拉伯还是汉字。
4.2 归一化与错误率计算的可复现代码
归一化是评测里最容易被忽略、也最容易导致数字失真的环节。参考文本写成“3 点”，识别输出“三点”，字面上一个是数字一个是汉字，不归一化就会被判成错误，白白贡献一个 S。
import re import unicodedata PUNCT = r"[，。！？、；：""''（）《》…—\-,.!?;:\"'()\[\]{}]" CN_NUM = {"零": "0", "一": "1", "二": "2", "两": "2", "三": "3", "四": "4", "五": "5", "六": "6", "七": "7", "八": "8", "九": "9"} def normalize(text: str) -> str: # 1. 全角转半角、兼容字符归一 text = unicodedata.normalize("NFKC", text) # 2. 英文统一小写 text = text.lower() # 3. 去掉标点，统一为空格 text = re.sub(PUNCT, " ", text) # 4. 单个汉字数字直接映射（仅处理 0-9 单字，复杂数字交给专门模块） text = "".join(CN_NUM.get(ch, ch) for ch in text) # 5. 压缩空白 text = re.sub(r"\s+", " ", text).strip() return text def tokenize_zh(text: str) -> list: # 中文按字切，英文按词切 return re.findall(r"[a-z0-9]+|[\u4e00-\u9fff]", text)第 4 步只处理单字数字，像“一百二十三”这种必须交给专门的数字规范化模块，否则拼出来是“1百23”这种四不像。这个取舍我建议保持保守：归一化宁可做少，不可做错，做多了会把真实错误掩盖掉。
接下来是编辑距离和 S/D/I 统计，这段代码我几乎每个项目都会重写一遍，直接抄走就行：
def align_stats(ref: list, hyp: list): n, m = len(ref), len(hyp) dp = [[0] * (m + 1) for _ in range(n + 1)] for i in range(1, n + 1): dp[i][0] = i for j in range(1, m + 1): dp[0][j] = j for i in range(1, n + 1): for j in range(1, m + 1): cost = 0 if ref[i - 1] == hyp[j - 1] else 1 dp[i][j] = min( dp[i - 1][j] + 1, # 删除 dp[i][j - 1] + 1, # 插入 dp[i - 1][j - 1] + cost # 替换或正确 ) # 回溯，统计 S / D / I i, j, sub, dele, ins = n, m, 0, 0, 0 while i > 0 or j > 0: if i > 0 and j > 0 and dp[i][j] == dp[i - 1][j - 1] + (ref[i - 1] != hyp[j - 1]): if ref[i - 1] != hyp[j - 1]: sub += 1 i, j = i - 1, j - 1 elif i > 0 and dp[i][j] == dp[i - 1][j] + 1: dele += 1 i -= 1 else: ins += 1 j -= 1 return sub, dele, ins def wer(ref_text: str, hyp_text: str) -> float: ref = tokenize_zh(normalize(ref_text)) hyp = tokenize_zh(normalize(hyp_text)) if not ref: return 0.0 if not hyp else 1.0 s, d, i = align_stats(ref, hyp) return (s + d + i) / len(ref)跑完一批数据后，我建议至少看三个数字：整体 WER、句错误率（SERR，即有多少比例的句子至少错了一处）、以及实体准确率。SERR 特别有用，因为用户感知到的不是字的错误率，而是“这句话有没有毛病”。有时候 WER 只降了 1 个点，SERR 却降了 5 个点，说明改动集中修好了长句，体感提升会很明显。
4.3 热词表的正确用法与副作用
专有名词错误占比高的时候，热词表是最快的止血手段。做法是把项目里高频出现的人名、产品名、术语整理成列表，在解码时给这些词额外的权重。我用下来的经验是：
规模控制在几百到两千之间。超过两千，误触发开始明显增加，一些生僻词会被硬塞进毫不相关的句子里，反而制造新的替换错误。权重不要一上来就拉满，先用小权重试，看误触率再调。热词表要定期洗牌，项目结束的人名、下线的产品名及时剔除，不然会持续制造噪声。
还有个更隐蔽的坑：热词表对同音误替换几乎无效。假设一个人名叫“李岩”，模型听成“李延”，你把这个词加热词，模型下次可能输出“李言”——它知道这里应该是一个具体的人名，但后缀拿不准。这时候正确的解法是同时把“李岩”“李延”“李言”都放进候选，配合后处理的一致性检查，保证同一份文档里写法统一。我一般会在文档级别做一次实体归一化：全文统计出现次数，取最高频写法作为标准，其余变体统一替换。
4.4 后处理的三道闸门
我把纠错后处理设计成三道串行的闸门，每道只做自己那一层的事，互不越权。
第一道是规则闸门，处理确定性极高的模式：词内重复合并、连续填充词删除、句首孤立填充词删除。这一层不调用任何模型，毫秒级，可解释性最强。
第二道是置信度闸门，把识别置信度偏低的片段标记出来，交给人工复核队列，而不是自动修改。低置信度片段本身就不该被自动改写，那是拿不确定的结果去污染成品。
第三道是模型闸门，用第 3.3 节那个 prompt 跑一遍，输出 diff 和理由。这一层的产出必须可回滚，我一般把原始文本、修改后文本、diff 三段都存下来，出问题能秒级定位。
三道闸门的顺序不能换。如果先跑模型再跑规则，模型的输出会被规则二次修改，diff 就对不上了，回溯时根本说不清某处改动是谁做的。
5. 实际踩过的坑：指标好看不等于能用
这部分是我最想分享的，因为每一个坑都是真实交付里翻出来的，文档里基本不会写。
5.1 WER 降了，下游任务反而变差
有个信息抽取的项目，识别端从 9% 优化到 6%，我们挺高兴，结果下游的要素抽取 F1 掉了 4 个点。排查了两天才发现问题：识别端改进主要来自语言模型变得更“流畅”，它开始自动补全一些没听清的词，输出的句子读起来通顺，但补错了。而抽取模型恰好依赖那些“完整的”关键短语，错一个就整条抽不出来。
这件事给我的教训是：优化目标要跟着业务指标走。如果你的下游是信息抽取，那么实体准确率比整体 WER 重要得多；如果下游是人工校对，那么“错误集中的地方是否显眼”比“错误总数”更重要。我现在做优化，都是先把下游指标建起来，再回头调识别。
5.2 过度纠错把说话人的原意改了
访谈类内容里这个问题特别敏感。受访者说“我不太确定这个方案是不是可行”，后处理把它“优化”成“这个方案不可行”——从流畅度看是变好了，但语气从“存疑”变成了“否定”，这是不可接受的语义漂移。
根因是模型默认“口语的犹豫=噪声”，而实际上犹豫本身携带信息。我的应对是按场景配置清洗强度：会议记录可以激进一些，访谈、医疗、法务必须保守，只删纯填充词和显性重复，任何涉及否定、程度、情态的词语一律不动。这个配置是产品决策，不是技术决策，得跟业务方一起定。
5.3 时间戳与清洗后的文本对不上
这个坑在做字幕时几乎必踩。删掉了“嗯”，但没有合并时间区间，播放到那一帧时字幕会闪一下或者提前消失。更麻烦的是句子级别的重新断句：改写式处理可能把两句话合成一句，原来挂在前一句话上的时间戳就不能直接用了。
我的处理办法是在后处理阶段维护一张词级对应表，记录每个原始 token 的起止时间和它的归宿（保留 / 删除 / 合并到某个新 token）。删除的 token 把时间区间让给相邻的保留 token，合并的 token 取并集。这张表平时不用管，一旦客户投诉时间轴错位，几秒钟就能定位到具体是哪一次合并出的问题。
5.4 “自动改口误”碰上多人对话就失灵
单人在讲，口误修正逻辑很顺。一旦变成三四个人讨论，问题就来了：A 说了一半被 B 打断，A 又接着说完，这时候“重复”和“重启”的边界完全变了。模型很容易把 B 的插话当成了 A 的口误给删掉。
现在的解法是先做说话人日志，把每一段按说话人切开，在单说话人的片段内部做口误判定，跨说话人的边界一刀不切。代价是抢话激烈时切分粒度不够，偶尔会漏掉一些修正，但比起删掉别人的发言，宁可漏。
5.5 中文数字与单位是永远的痛
“两点五”是 2.5，“两点半”是 2:30，“两点五十分”是 2:50。这三个短语在口语里的声学差异很小，模型经常互相串。金额更麻烦：“一千二百”和“一千二百多”差了两个字，意思差了一截，偏偏“多”是轻声，远场录音里几乎听不见。
对这类问题，我现在不指望模型自己搞定，而是在后处理里加一层领域规则的交叉校验：如果同一个会议里出现了明确的金额上下文（比如讨论预算），就把该段所有数字候选列出来做一次人工确认前的标记。这个做法不优雅，但比在客户面前翻车强。
6. 关于 2.6% 与自动纠错这件事我的看法
做了几年这类项目，我对这类“错误率新低”的消息态度比较冷静。2.6% 是有意义的，它说明在受控条件下，机器转写已经能逼近人工的水平，剩下的差距更多是工程问题而不是算法问题——专有名词靠热词表和领域自适应、数字靠归一化规则、口语毛刺靠后处理流水线，这些都是可落地的手段。但真实业务场景的复杂度不会因为一个数字下降而消失：远场混响、多人抢话、方言口音、专业术语，每一项都在把难度往上抬。我给自己定的期待是，在中等难度的会议场景里，把字错误率稳定在 8% 到 12%、把句子错误率压到 30% 以下，同时配一套好用的置信度标记让校对效率提升三倍，这个目标比追求一个榜单数字实在得多。
至于“自动改口误”，我认为它的价值被低估了。它真正解决的问题不是“让文本更好看”，而是让转写结果可以直接进入下游流程。以前带口误的原始转写必须过一遍人工清洗才能用来做摘要、做抽取、做检索，这一步人力成本极高。现在如果能把清洗的准确率做到九成以上、剩下的部分靠置信度挑出来人工确认，整个链路的效率提升是数量级的。我的建议是，如果你正准备上这套能力，先从“只删填充词和显性重复”这种低风险的动作开始跑，把 diff 和回滚机制做扎实，再逐步放开改写权限。一次放开到改写式，出问题的概率高得吓人。
最后再分享一个小技巧：给自己的纠错流水线做一个“反向测试集”。做法是把干净的书面句子人为加上填充词、重复、错误开头，再让流水线去还原，看能不能原样返回。这个测试能极快地暴露出过度修改的问题——如果模型把没加毛刺的句子也改了，那它在真实数据上一定会改坏东西。我靠这个方法在半天内定位到了三个过度激进的规则，比在真实数据上慢慢找快得多。
