whisper-guard — 砍掉 87% Whisper 幻覺的不是大模型,是一個 400 行的規則引擎
Whisper 最會騙你的時刻,是它最心虛的時刻。
用過 Whisper 的人大概都撞過這個牆:一段明明安靜無聲的停頓,轉錄結果卻憑空冒出「謝謝觀看」、「記得訂閱」,或者同一句話像跳針一樣重複十幾遍。這不是 bug,是模型的天性——它在沒有有效輸入的時候,還是會硬擠出一點東西來。你可以想成一個被訓練到「必須開口」的人,被丟進一個沒人講話的房間,他不會閉嘴,他會開始編。Whisper 訓練資料裡塞了海量的 YouTube 字幕,所以它編出來的,往往就是那幾句最常出現的片尾台詞。
碰到這種狀況,工程師的直覺反應幾乎是反射性的:那就再串一個 LLM 在後面,讓它讀一遍轉錄結果,把不通順、明顯亂入的句子清掉。畢竟 2026 年了,什麼問題不是丟給大模型解決的?
這個直覺是錯的。而且錯得很乾脆。
一個 benchmark,把直覺打回原形
whisper-guard 這個專案的作者跑了一組對照實驗,數字攤開來看,很難不被嚇到。
同一份音檔,原始 Whisper 跑出來有 16 次幻覺,耗時 47.7 秒。接著試「只加 LLM 後處理」這條多數人會選的路:幻覺數字是多少?16 次。一次都沒少。減少幅度 0%,而耗時從 47.7 秒暴增到 106.1 秒。你花了兩倍的時間跟一筆 API 帳單,換來的是完全一樣的垃圾。
然後是另一條路:只掛一個叫 whisper-guard 的規則引擎,不碰任何大模型。幻覺從 16 次掉到 2 次,砍掉 87.5%,耗時 46.5 秒——比原本還快了一點點,因為它把整段該丟的東西提早丟了。
兩條路的對比放在一起,會逼你重新問一個問題:為什麼那個看起來更聰明、更現代的方案,徹底沒用?
因為你搞錯了這是哪一種問題
關鍵在這句話:幻覺不是語意問題,是統計問題。
LLM 後處理之所以無效,是因為它在用「讀不讀得通」的標準去抓幻覺。但「謝謝觀看」本身就是一句完全通順、語法正確、語意清楚的中文。在 LLM 眼裡它毫無破綻——它就是一句正常的話,只是剛好不該出現在那裡而已。你叫一個只會判斷「這句話合不合理」的東西,去抓一句「本身很合理但位置錯了」的話,它當然抓不到。
真正暴露幻覺的,是它背後那串模型自己吐出來的統計訊號。Whisper 每轉一段都會附帶幾個指標:這段是靜音的機率(no_speech_prob)、平均對數機率(avg_logprob,反映模型有多沒把握)、壓縮比(compression_ratio,反映重複程度)。幻覺片段在這幾個數字上會露出馬腳——靜音機率高得異常、模型信心低到不行、文字重複到壓縮比爆表。這些訊號 LLM 後處理根本看不到,因為它只拿到最後那串文字,模型轉錄當下的「猶豫」早就被丟掉了。
換個比喻。判斷一份口供是不是說謊,你可以讀內容,也可以看測謊儀。LLM 後處理是事後讀逐字稿,whisper-guard 是直接接測謊儀的指針。內容可以編得天衣無縫,指針騙不了人。
四層管線,前面攔住就不往下走
whisper-guard 整套東西不到 400 行 Python,零外部依賴,只用標準庫的 re、dataclasses、typing。它的做法是一條四層過濾管線,依序往下,前一層攔住的就短路掉、不浪費後面的力氣。
第一層先看整批:如果所有片段的平均靜音機率高到超過 0.6,代表這整段大概根本沒人講話,直接整批拒絕。第二層逐段檢查那三個統計指標——靜音機率超過 0.8、信心低於 -1.5、壓縮比高於 3.0 的,丟掉。第三層處理重複:把文字切成小塊算唯一比率,低於 0.35 就判定為跳針。第四層用正規表示式抓「哈哈哈哈哈」這種 2 到 4 字元重複三次以上的字元迴圈,清乾淨。
裡頭有個小設計值得偷學:第二層如果拿得到時間資訊,會對短於 1.6 秒的片段自動套用更嚴格的信心門檻(-1.7 而不是 -1.5)。為什麼?因為幻覺最愛長在短暫的靜音縫隙裡。這不是亂調參數,是把「幻覺出現的規律」直接寫進判斷邏輯——這種對問題本身的觀察,比任何模型都難複製。
接進去也簡單。轉錄完把 segment 丟給 guard.process(),回傳一個 GuardResult,告訴你過了沒、清理後的文字、保留幾段、拒絕原因是什麼。所有門檻都能透過 GuardConfig 自己調。
1 | from faster_whisper import WhisperModel |
字幕生成、會議記錄、Podcast 批次轉錄、語音助手送進 LLM 前的前處理——只要中間有 Whisper,靜音片段就是幻覺的溫床,這道閘門就有地方放。
它不是萬靈丹,也不假裝是
得講清楚邊界,免得你抱著錯的期待去裝。
whisper-guard 抓的是「在統計指標上露馬腳」的幻覺。如果哪天模型編出一句各項指標都正常、單純就是語意亂掉的句子,它抓不到——那種才真的需要 LLM 補一刀。所以 benchmark 裡最猛的組合其實是「先 VAD 切靜音、再 Guard 過濾、最後 LLM 收尾」,幻覺壓到剩 1 次(-93.8%)。規則引擎跟大模型不是二選一,是各守各的關,先用便宜又準的擋掉九成,剩下那一成棘手的再請大模型出馬。
它也還沒上 PyPI,README 寫的 pip install whisper-guard 目前裝不到,只能從 GitHub 裝;內建的贅詞過濾只放了四個中文詞,英文要自己補;版本號連 pyproject.toml 跟 __init__.py 都還沒對齊。這是個很年輕的專案。但反過來說,400 行、零依賴、邏輯全攤在眼前,你看不順眼直接 fork 來改,成本低到不像話。
真正該帶走的,不是這個工具
whisper-guard 本身只解一個很窄的問題。但它示範的那個判斷,適用範圍寬得多:動手解之前,先問清楚「這是哪一種問題」。
幻覺這件事,表面上看是「模型輸出了錯的內容」,聽起來像個語意問題,於是你很自然地想找一個更懂語意的東西來收拾——大模型。但它的本質是統計問題,是模型在低信心狀態下的副產物。問題的類型一旦看錯,你選的工具再強也使不上力,就像拿著全世界最好的測謊儀,卻跑去逐字逐句讀那份早就編好的口供。
下次再遇到「直覺上該丟給 AI」的狀況,值得先停一秒:我要解的,到底是模型擅長的那種問題,還是一個被包裝成 AI 問題、其實幾十行規則就搞定的東西?這一秒,常常就是 46 秒跟 106 秒的差別。
原文來源:whisper-guard - GitHub
相關專案:arkiv、faster-whisper










