语音转文字的错误率，在英语场景下已经低到能用了。但换成乌尔都语、斯瓦希里语这类资源匮乏的语言，错漏百出是常态。Umair Ali Khan博士最近公布了一套双遍LLM后处理方案，把多个主流模型的词错误率（Word Error Rate）压了下去，而且适配新语言只需要改提示词。
核心思路很朴素：第一遍修拼写和一致性，第二遍补上下文逻辑。两遍分工明确，不抢活。Khan在Medium专栏详细拆解了实现路径，我们按时间线还原这套方案是怎么从问题清单里长出来的。
第一步：先给错误分类，别急着动手
Khan团队先跑了大量转写样本，把高频错误归类。拼写错误最常见，比如"accomodate"少写一个m。一致性错误次之，同一个人名前后三种写法。最隐蔽的是上下文错误：复合词该不该加连字符、功能词（介词、冠词）有没有漏掉，这些单靠局部文本判断不了。
传统后处理用规则引擎硬编码，新语言来了得重写规则。Khan的解法是把规则换成LLM的推理能力，用提示词封装语言知识，换语言时只换提示词。
第一遍：拼写和一致性修复
TranscriptEnhancer组件的第一遍处理，输入是原始转写文本，输出是"干净版"。提示词设计得很克制：只修明显拼写错误，统一专有名词写法，不碰句子结构。
Khan特别提到一个细节：第一遍要"保守"。LLM有幻觉倾向，给太多自由度会擅自改写正确内容。提示词里加了明确约束——"如果拼写存在争议，保留原样"。
实测下来，第一遍单独跑能把纯拼写类错误清掉七成以上。但复合词拆分错误、连字符滥用这些问题，第一遍基本不动，留给第二遍。
第二遍：上下文推理补漏
第二遍的输入是第一遍的输出，加上一个关键上下文窗口。Khan把前后各50词喂给LLM，让它判断"longterm"该写成"long-term"还是"long term"，"New York based"要不要加连字符变成"New York-based"。
功能词缺失是另一块硬骨头。口语转写常漏掉"the""a""of"，第一遍看不出来，第二遍结合上下文能补个七七八八。Khan举了个例子：原文本"meeting scheduled next Monday"，第二遍会推断成"the meeting is scheduled for next Monday"。
两遍串联后，词错误率降幅明显。Khan没公布具体数字，但强调"across multiple speech-to-text models"都有效，说明方案不挑底层模型。
适配新语言：只改提示词，不动代码
这套架构的最大卖点是语言迁移成本极低。Khan在文章第6节专门讲适配流程：准备该语言的常见错误样本，重写两遍提示词里的示例和约束，跑一批测试集调优。
不需要重新训练模型，不需要标注大量数据。对于缺乏语音语料的小语种，这是现阶段最现实的提质路径。Khan本人的背景也印证了这点——他的GitHub主页列着乌尔都语NLP项目，这套方案显然是从实际痛点里磨出来的。
TranscriptEnhancer的代码结构他没完全开源，但核心逻辑讲得很透：两遍调用同一LLM，用不同系统提示词区分角色，中间状态缓存避免重复计算。工程上没什么黑魔法，胜在把LLM的推理能力用在了对的环节。
语音转文字的赛道，头部玩家都在卷端到端模型。Khan的方案反其道而行，承认现有模型的局限，用轻量后处理补短板。对于预算有限、又要支持多语言的团队，这种"缝合"思路可能比追新模型更务实。
最后留个细节：Khan在提示词里埋了一个自检指令，让LLM输出修改理由。调试时能看到第一遍为什么把"color"改成"colour"，第二遍为什么加了那个"the"。这种可解释性设计，在LLM应用里比准确率本身更难能可贵。
如果你的产品要支持小语种语音输入，会先赌下一代ASR模型，还是试试这种双遍后处理？
热门跟贴