我測了兩天，證明「換更好的引擎」降了一個錯誤

準備錄實驗素材那天，我打開對話視窗跟他說：等一下每段話講兩次，第一次按鍵盤右下角那個麥克風。

他回我：iPhone 有那個東西？

那一刻我的實驗死了。我設計了三組對照，其中一組叫「現況組」——而現況組從來不存在。我查了程式碼，確認過那個功能該怎麼運作；我沒查的是，這個人根本沒在用它。

我原本要測什麼

我在幫自己的知識庫系統做語音輸入。走路的時候按住講一段話，鬆手，它應該變成當天的紀錄。

聽不聽得懂從來不是重點。真正卡住的是專有名詞——人名、專案代號、自己發明的縮寫——這些字在通用語音模型的訓練資料裡幾乎不存在，它只會挑一個發音接近的常見詞給你。我紀錄裡有個團隊代號，十次有九次被聽成一個完全無關的詞，每次都要人工回去改。

摩擦沒有被消除，只是被搬到後面去了。

所以我打算換一顆更好的引擎。手上有一台自架的推論機器，跑著比手機內建大得多的模型，端點打得通。剩下的就是證明它比較好。

有基準、有單一變數推進、有最終方案。這個設計是錯的，而且錯得很不明顯——我要繞很久才會發現。

第一次翻車：我查了程式碼，沒查人

上面那個對話發生在正式開錄前十分鐘。

我對 A 組的認知是「使用者現在就是這樣輸入的」。這個認知從哪來？我 grep 了 bot 的原始碼，確認它怎麼處理進來的訊息——這一步做對了。

我沒做的是問一句「你平常是怎麼傳的」。

他從來沒用過鍵盤聽寫，一直是長壓輸入欄那個麥克風傳語音訊息。而 bot 的 handler 只認文字、照片、文件三種——語音訊息進來，沒有任何一段程式碼接得住。它們被靜默丟棄，而且不回任何訊息。

所以他過去每一次「用講的記一下」，都以為記進去了，實際上一句話都沒留下。這個洞比實驗本身嚴重，我當天先把它補起來：不轉錄，先存檔，至少不再遺失。

至於實驗，A 組不再是「現況」了。它變成一個從沒被試過的候選方案：如果手機內建聽寫夠準，最省事的解法是使用者改變操作習慣，一行程式碼都不用寫。

這個角色轉換，後來變成整件事的關鍵。

第二次翻車：我的系統污染了我自己的對照組

錄第一段的時候。

A 組的文字要進到知識庫裡才好比對，所以我讓他直接傳進去。傳進去之後我打開檔案一看——專有名詞已經被自動改對了，句子還被重新整理成條列。

原因很蠢，但值得記：我的知識庫本身就掛著一層路由，任何進來的文字都會被 LLM 順過一次，順便修正專有名詞、整理成結構。這是我自己設計的，每天都在用，好用到我完全忘了它存在。

等於 A 組在進場之前，就先被 C 組處理過一次了。原文不可復原，那一段只能重念。我把 A 組改走一條專用旁路——訊息開頭帶特定前綴就原文逐字落檔，禁止校正、禁止結構化。

基礎設施會自己動手，它從來不是一根安靜的管子。 還有一層更麻煩的含意：這條路由平常就在自動校正我所有的紀錄，意味著知識庫裡既有的文字都不是原始輸入。以後拿它們當語料的分析，都得先記得這件事。

第三次翻車：差點把 kill 線設計掉

C 組的後修要由誰來做？最順手的當然是我自己——直到我想起朗讀腳本是我寫的，每一段的標準答案我都知道。我來做後修，那叫開卷考。

分數虛高還算小事。真正致命的是誤修數會恆為 0。

先解釋一下誤修。後修層是一個 LLM，它讀轉錄出來的文字，用知識庫的上下文判斷哪些詞被聽錯了。它會修對，也會把本來對的改成錯的——冷門正確詞被改成常見詞，這是這類方案最真實的風險。而且誤修比漏修危險：漏修的錯誤讀起來很怪，一眼看得出來；誤修的錯誤讀起來很通順，只是它是假的。

我的 kill 線有兩條，第二條就是「誤修數超過修對數的三分之一就收掉」。

如果由知道答案的人來做後修，這條線永遠不會被觸發。我等於在實驗開始前，先把自己最想量的那個風險刪掉了。

改由一個沒看過腳本的 agent 執行，只給它知識庫的專有名詞表——上線後它拿得到的東西——和轉錄的原始輸出。

分數出來了，然後兩條線同時成立

15 段素材，每段 15 到 40 秒，在走路的時候錄的。刻意不在安靜房間念稿，那會同時高估所有組別，測不出差距。

評分不用 WER。中文的 WER 對這個問題沒有鑑別度——斷詞、同音字、贅字全部會污染分數。我改成數三種錯誤：專有名詞錯幾個、數字錯幾個、語意被破壞幾處。

C 組修對 27 處，誤修 0 處。

然後我盯著這張表看了很久，因為它同時觸發了兩件相反的事。

成功指標達成：我事前寫的成功線是「C 的專名錯誤 ≤ A 的一半，且誤修 = 0」。0 ≤ 15.5，誤修 0，過了。

kill 線也觸發了：另一條 kill 線是「B 的專名錯誤 ≥ A 的 70%」。A 是 31，70% 是 21.7，B 是 24。觸發。

兩條線在問不同的問題，所以它們可以同時成立。

kill 線問的是「換引擎有沒有用」——幾乎沒有。B 比 A 只降 23%，落在我開工前就寫死的噪音區間裡：兩組音檔不同源，只有兩倍以上的量級差距才算有效信號。成功線問的是「加後修有沒有用」——41 降到 2。

價值來源是後修層，不是引擎。

但我還是不能歸因，因為第四格從來沒被測過

上面那個結論其實還站不太住。

因為 C 相對 A 同時改了兩件事：換了引擎，又加了後修。C 大勝，我沒辦法把功勞分開。B 比 A 只好一點點是強烈的暗示——但只是暗示。

畫成 2×2 就很清楚了：

我測了三格。缺的那格是「不換引擎、只加後修」——也就是最便宜的那一格。

遞增疊加的設計為什麼會騙人？因為相鄰兩臂之間確實只差一個變數：A 到 B 只換引擎，B 到 C 只加後修。它感覺起來像對照實驗。但整體看，它只是三個點在測一條線，永遠算不出「不換引擎的條件下，後修自己值多少」。

而如果後修自己就夠了，換引擎那一整條的工程成本全是浪費——外部服務依賴、音檔上傳管線，還有簡繁轉換（那顆引擎會偶發吐簡體字，15 段裡有兩段）。

補這一格幾乎免費：A 組的輸出還在，後修流程做 C 組時已經建好，套上去跑一次就好。

我跑了。

後修層降 27 到 38 個錯誤。換引擎在沒有後修時降 12 個，在有後修的條件下降 1 個。

一個。

我為了那個「1」，原本準備蓋一整條管線。

為什麼後修層贏這麼多

因為它做的是純語音模型結構上做不到的事。

那個 agent 修對的四處裡，有這些：一個不存在的英文詞被還原成某專案的代號、一個發音相近的詞被改成「優化」、一串被聽成「R P 一八」的東西被還原成健身術語的「RPE 8」。

這些靠的全是語意推斷。它讀知識庫裡的上下文，判斷「在這個人的紀錄裡，這個位置該出現的是什麼」。任何純語音引擎都做不到，因為它們沒有你的知識庫。

還有一個更窄的判準：如果你要換的那顆引擎沒有提供餵入領域詞彙的介面，那換誰都差不多。我測的那顆就是這樣，端點只吃音檔和語言參數，沒地方塞人名。

最後一次翻車：四格量的都是同一個指標

我根據 2×2 做了裁決：走最便宜的那格，手機內建聽寫加後修層。外部服務不用碰了，音檔管線省下來，連簡繁轉換這個坑都直接不存在。

然後拿去給使用者複核，被推翻了。

理由一句話就說完：手機內建聽寫這條路，前提是他要改變操作習慣。而整場實驗從頭到尾，A 組之所以存在，就是因為他從來沒用過那個功能。

語音訊息是按住、講、放開。鍵盤聽寫要開輸入框、點麥克風、盯著文字跑完、按送出——走路的時候還得看螢幕。我算的是一次性的工程成本，沒算每天都要付的摩擦成本。

2×2 拆對了變數，但四格量的都是同一個指標：錯誤數。 當候選方案真正的差異在別的維度上，只比主指標就會選錯。

實驗的結論本身沒變——後修是槓桿，引擎不影響準度。改的是推論：既然引擎不影響準度，這一維就該由摩擦決定，而摩擦這維是自架引擎贏。零行為改變，音檔本來就在存，邊際成本只剩一個 HTTP call。

最後上線的是「語音訊息 → 自架引擎 → 後修層」。隔天用同樣那 15 段素材對生產環境做了一次盲評：誤修 0，三類錯誤合計 3。實驗量到的東西在生產上重現了。

如果你也在調同一顆旋鈕

我從這兩天帶走三條，都是給下一次的我。

第一條寫成規則：任何「換掉 X，而且加上 Y」的假設，開工前先畫 2×2，確認四格都會被測到。真有一格不打算測，那就在筆記上明寫「不測哪格、因此哪個主效應無法歸因」——讓它是個判斷，不是疏忽。

四格全量同一個指標，等於沒量到候選方案真正的差異。這是我這次栽得最重的地方——沒被量到的那一維，通常就是最後推翻你的那一維。

還有一條沒那麼漂亮。查程式碼只告訴我系統能做什麼，沒告訴我人實際上在做什麼，我把前者做對了，後者整個漏掉。

有件事值得帶出這個故事之外：大部分「模型不夠聰明」的狀況，其實是模型不知道你的業務在講什麼。它不知道你的產品叫什麼、你的客戶怎麼稱呼那個流程、內部那個三個字的縮寫是什麼意思。換一顆更大的模型救不了這件事。你得把自己的上下文餵給它。

如果你正在評估這件事

如果你手上有一個 AI 功能準確率卡住，而現在的討論是「要不要換更貴的模型」，那大概值得先停一下。是它聽不清楚，還是它不知道你在講什麼？這兩件事的解法完全不一樣，成本差一個量級。

我做技術諮詢，這類「先確認問題在哪」的對話通常十分鐘就有結論。沒有簡報，不賣套裝方案，如果你的狀況根本不用動 AI 我也會直說。

到 mattchang.dev 加我的 LINE，直接描述你的狀況就好。那個帳號本身也是我自己蓋的——你跟它對話的體驗，就是你正在評估的那個東西的 live demo。