語音轉(zhuǎn)文字的錯誤率，在英語場景下已經(jīng)低到能用了。但換成烏爾都語、斯瓦希里語這類資源匱乏的語言，錯漏百出是常態(tài)。Umair Ali Khan博士最近公布了一套雙遍LLM后處理方案，把多個主流模型的詞錯誤率（Word Error Rate）壓了下去，而且適配新語言只需要改提示詞。

核心思路很樸素：第一遍修拼寫和一致性，第二遍補(bǔ)上下文邏輯。兩遍分工明確，不搶活。Khan在Medium專欄詳細(xì)拆解了實現(xiàn)路徑，我們按時間線還原這套方案是怎么從問題清單里長出來的。

第一步：先給錯誤分類，別急著動手

Khan團(tuán)隊先跑了大量轉(zhuǎn)寫樣本，把高頻錯誤歸類。拼寫錯誤最常見，比如"accomodate"少寫一個m。一致性錯誤次之，同一個人名前后三種寫法。最隱蔽的是上下文錯誤：復(fù)合詞該不該加連字符、功能詞（介詞、冠詞）有沒有漏掉，這些單靠局部文本判斷不了。

傳統(tǒng)后處理用規(guī)則引擎硬編碼，新語言來了得重寫規(guī)則。Khan的解法是把規(guī)則換成LLM的推理能力，用提示詞封裝語言知識，換語言時只換提示詞。

第一遍：拼寫和一致性修復(fù)

TranscriptEnhancer組件的第一遍處理，輸入是原始轉(zhuǎn)寫文本，輸出是"干凈版"。提示詞設(shè)計得很克制：只修明顯拼寫錯誤，統(tǒng)一專有名詞寫法，不碰句子結(jié)構(gòu)。

Khan特別提到一個細(xì)節(jié)：第一遍要"保守"。LLM有幻覺傾向，給太多自由度會擅自改寫正確內(nèi)容。提示詞里加了明確約束——"如果拼寫存在爭議，保留原樣"。

實測下來，第一遍單獨跑能把純拼寫類錯誤清掉七成以上。但復(fù)合詞拆分錯誤、連字符濫用這些問題，第一遍基本不動，留給第二遍。

第二遍：上下文推理補(bǔ)漏

第二遍的輸入是第一遍的輸出，加上一個關(guān)鍵上下文窗口。Khan把前后各50詞喂給LLM，讓它判斷"longterm"該寫成"long-term"還是"long term"，"New York based"要不要加連字符變成"New York-based"。

功能詞缺失是另一塊硬骨頭�？谡Z轉(zhuǎn)寫常漏掉"the""a""of"，第一遍看不出來，第二遍結(jié)合上下文能補(bǔ)個七七八八。Khan舉了個例子：原文本"meeting scheduled next Monday"，第二遍會推斷成"the meeting is scheduled for next Monday"。

兩遍串聯(lián)后，詞錯誤率降幅明顯。Khan沒公布具體數(shù)字，但強(qiáng)調(diào)"across multiple speech-to-text models"都有效，說明方案不挑底層模型。

適配新語言：只改提示詞，不動代碼

這套架構(gòu)的最大賣點是語言遷移成本極低。Khan在文章第6節(jié)專門講適配流程：準(zhǔn)備該語言的常見錯誤樣本，重寫兩遍提示詞里的示例和約束，跑一批測試集調(diào)優(yōu)。

不需要重新訓(xùn)練模型，不需要標(biāo)注大量數(shù)據(jù)。對于缺乏語音語料的小語種，這是現(xiàn)階段最現(xiàn)實的提質(zhì)路徑。Khan本人的背景也印證了這點——他的GitHub主頁列著烏爾都語NLP項目，這套方案顯然是從實際痛點里磨出來的。

TranscriptEnhancer的代碼結(jié)構(gòu)他沒完全開源，但核心邏輯講得很透：兩遍調(diào)用同一LLM，用不同系統(tǒng)提示詞區(qū)分角色，中間狀態(tài)緩存避免重復(fù)計算。工程上沒什么黑魔法，勝在把LLM的推理能力用在了對的環(huán)節(jié)。

語音轉(zhuǎn)文字的賽道，頭部玩家都在卷端到端模型。Khan的方案反其道而行，承認(rèn)現(xiàn)有模型的局限，用輕量后處理補(bǔ)短板。對于預(yù)算有限、又要支持多語言的團(tuán)隊，這種"縫合"思路可能比追新模型更務(wù)實。

最后留個細(xì)節(jié)：Khan在提示詞里埋了一個自檢指令，讓LLM輸出修改理由。調(diào)試時能看到第一遍為什么把"color"改成"colour"，第二遍為什么加了那個"the"。這種可解釋性設(shè)計，在LLM應(yīng)用里比準(zhǔn)確率本身更難能可貴。

如果你的產(chǎn)品要支持小語種語音輸入，會先賭下一代ASR模型，還是試試這種雙遍后處理？