Umair Khan用2遍LLM把語音轉寫錯誤率砍半

語音轉文字的錯誤率，在英語場景下已經低到能用了。但換成烏爾都語、斯瓦希里語這類資源匱乏的語言，錯漏百出是常態。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模型，還是試試這種雙遍后處理？