LLM 模型選型怎麼做？快 8–10 倍，為什麼我們還是放棄了這個設定

MUSE 的 JSON Prefill 曾讓推論快 8–10 倍，欄位正確率卻從 81.2% 降到 72.9%。這次 LLM 模型選型實驗讓我學到：該放棄的不是模型，而是會犧牲任務核心能力的設定。

我們曾把一個 LLM 流程加速 8–10 倍。

單看 token 與延遲，這是一個明顯的效能改善；但最後，我們主動停止採用這個設定。

不是因為它不夠快，也不是因為 MUSE 整體無法使用；問題是，它縮短的不只是等待時間，也包含模型完成全文掃描、來源範圍判斷與文字裁切所需的推理步驟。

那時我們正在處理一種內部文件擷取任務。它不是單純 OCR：模型要讀取 PDF 或文件影像、判斷文件類型、按照指定來源範圍逐欄擷取，最後回傳結構化 JSON。金額、期間、人名、文號和勾選狀態，只要錯一個字，該欄位就應判為錯誤；無法可靠辨識時回傳 null 是合理行為，但清楚可辨的內容若被遺漏，同樣是任務失敗。

所以這篇想記下的，不是「MUSE 最後被放棄了」。更精確地說，被停止採用的是 MUSE + JSON Prefill、略過 reasoning 的候選設定。後來正常的 MUSE 仍在正式比較裡，且欄位品質具競爭力，只是單份文件的後端處理時間較長。

真正留下來的，是一個我以後選模型時都會再問一次的問題：如果加速削弱了產品不能失去的能力，這個加速是否仍值得採用？

JSON Prefill 降低延遲，卻可能改變任務所需的判斷行為

這次 A/B 實驗只改了一個變因。

• 兩組都使用 muse-glimmer-30b
• 使用同一份資料集、同一個任務
• OCR 都關閉
• A 組讓模型正常回答
• B 組預先在 assistant 訊息放入 JSON 開頭 {，讓模型直接續寫 JSON

表面上，JSON Prefill 只是在 assistant 訊息預先放入一個 {；它實際改變的卻不只是 Prompt 長度。正常情況下，模型可自行選擇 reasoning 與答案通道；預先放入 { 後，模型必須直接續寫答案，reasoning 在這個結構下沒有機會出現。

效能改善十分明確，但品質代價也同樣明確：

• MUSE baseline：以原本 token 與速度作為基準，欄位正確率為 81.2%。
• MUSE + JSON Prefill：推理／生成 token 減少約 90–93%，速度提高約 8–10 倍，欄位正確率則降至 72.9%。

若只檢視延遲與 token，這個設定看起來足以直接進入候選部署名單。

但欄位正確率下降了 8.3 個百分點，而且錯誤不是平均散落在各種小地方。它集中在 matchedKeywords、期間等欄位：需要掃完全文、辨識來源範圍、把文字完整裁出來的地方。

這個錯誤分布不像是零星的字元辨識失誤，更接近模型在完成全文檢查前就開始生成答案。

8.3 個百分點值不值得換？要先看它犧牲了什麼

「速度和正確率本來就要取捨」沒有錯，但不足以支持部署決策。

真正該問的不是：快 8–10 倍，值不值得換 8.3 個百分點？而是：那 8.3 個百分點裡，少掉的是哪一種能力？

如果退步的是標點、低風險格式，或可由確定性規則修正的欄位，或許仍值得繼續優化。但這次退步的是全文掃描、來源範圍判斷與逐字擷取；這些都是任務本身的核心能力，不能視為只要補一條 Prompt 就能忽略的次要誤差。

我後來把判斷寫得更直接一點：

如果退步的是可局部修補的輸出，就繼續優化；如果退步的是模型完成任務的方法，就停止該設定，換模型或換 Pipeline。

MUSE Prefill 屬於後者。它不是把答案寫得比較短，而是讓模型更常跳過完成任務所需的判斷。

放棄一個設定，不等於停止模型實驗

停止 Prefill 路線後，我們沒有據此否定 MUSE，而是把問題重新改寫：哪一種模型、OCR、Prompt 與部署設定的組合，能在品質、速度與可靠性之間落在可接受的邊界？

後續另一輪正式比較，使用 36 份文件與 199 個人工確認欄位。它和前面的 Prefill A/B 並非同一份完整歸檔結果，因此不能串成一條「模型持續進步」的曲線；但它很適合說明後來的搜尋方向。

• Gemma，不加 OCR：欄位正確率 68.8%、每份後端時間 9.7 秒；25/36 份需修改。
• MUSE，不加 OCR：欄位正確率 92.5%、每份後端時間 124.3 秒；7/36 份需修改。
• Gemma + Surya OCR：欄位正確率 85.4%、每份後端時間 15.6 秒；17/36 份需修改。
• QWEN3.8-27B，關思考、MTP OFF：欄位正確率 95.5%、每份後端時間 38.6 秒；4/36 份需修改，35/36 份成功。
• QWEN3.8-27B，關思考、MTP ON：欄位正確率 95.5%、每份後端時間 27.7 秒；4/36 份需修改，35/36 份成功。

這張決策圖不會告訴我哪一個模型在所有情境都最好，卻讓我不再只問「如何繼續壓低同一個模型的延遲」。

Gemma 的後端時間最短，但未使用 OCR 時有 25/36 份文件需要修改；MUSE 的欄位正確率較高，但每份文件的後端時間達 124.3 秒；QWEN3.8 目前是品質最好的候選之一，但仍出現一次 HTTP 400，代表上線前必須設計重試、fallback 或人工接手機制。至於 MTP ON 比 OFF 快 28.2%，目前只來自單輪觀察，且 PDF 渲染時間同時變動，不能將差異全數歸因於 MTP。

LLM 模型評估，不能只看 valid-only 的高分

我後來才更確定：JSON 合法，只是最低條件。

一個流程就算順利回傳 JSON，還是可能：

• 漏掉本來看得清楚的欄位
• 從不該讀取的表頭、附件或頁首頁尾取值
• 沒掃完指定範圍的關鍵字
• 把手寫金額或期間辨識錯誤
• 因為 HTTP、parse、repair 或 retry 問題，讓部分文件未完成處理

因此，「成功回傳的文件裡，平均正確率是多少」不能單獨作為部署依據。若將 ERROR 移出分母，分數會產生選樣偏誤；使用者真正面對的是整批文件中，有多少仍需人工補正或重新處理。

對這類任務來說，至少要把評估拆成四層：

• 可執行性：每份文件有沒有完成？JSON 能不能解析？
• 任務品質：應填欄位是否完整且正確？
• 風險控制：金額、期間、姓名、編號等高風險欄位是否安全？
• 作業效益：p50／p95 延遲、人工修改文件數和修改量是否下降？

只要任一層未達門檻，即使整體平均很高，也不足以證明它適合上線。

什麼時候該繼續優化，什麼時候該換模型？

我會繼續優化同一個模型或設定，如果：

• 錯誤集中在少數欄位，而且有明確的 Prompt、來源切片或確定性規則可以修正。
• 高風險欄位沒有變差，差異主要是格式、標點或低風險文字。
• 加速後已接近驗收門檻，而且錯誤可以可靠偵測、重試或安全轉人工。
• 效能瓶頸主要位於模型推論，而不是 PDF 渲染、排隊、網路或重試。

但我會停止一條路線，如果：

• 錯誤落在任務核心能力或高風險欄位。
• 它出現系統性行為，例如固定漏掃全文、忽略來源範圍或提早作答。
• 為了補救它，需要累積大量例外規則，維護成本已抵銷速度收益。
• 同樣條件下，另一個模型或 Pipeline 已形成明顯的品質、速度或可靠性優勢。

這些規則看起來不複雜，但這次實驗讓我明白：許多「先把延遲降下來再說」的優化，可能延後我們發現模型沒有完成核心任務的時間點。

一個 LLM 實驗怎樣才算做完？

現在每次要開始模型選型前，我會先檢查七件事。程式跑完不算，能支持下一個決定才算。

1. 問題：這次要決定什麼？最低品質、最大等待時間和不可接受風險是什麼？
2. 資料：資料集、Ground Truth、難例集和 holdout 是否能被固定與追溯？
3. 對照：Prompt、模型版本、OCR、參數、硬體與暖機條件是否一致？一次是否只改一個變因？
4. 完成率：每份文件的 HTTP、Schema、parse、repair、retry、fallback 是否都有留下？
5. 指標：除了欄位正確率，是否也看 coverage、文件成功率、高風險欄位 gate、人工修改量與端到端 p50／p95？
6. 診斷：知道錯在哪種文件、哪個欄位、哪個來源區段嗎？還是只有一個總平均？
7. 決策：能不能重現？結論是採用、保留研究、停止設定還是換模型？下一輪要解除哪個不確定性？

我把它濃縮成一句話：問題、資料、對照、完成率、指標、診斷、決策。

快，不是唯一的答案

這次真正產出的不是一個「被淘汰的模型」。

而是一套更完整的判斷方式：速度、正確率、規則遵循、失敗率和人工成本，必須放在同一張決策表上評估。單一字元辨識錯誤，與模型開始跳過全文掃描，代表的是兩種不同層級的風險。

停止採用一個設定，也不代表實驗失敗。它只是縮小搜尋空間，讓下一輪實驗更接近可安全交付給使用者的方案。

至於 MUSE Prefill 的逐文件原始結果、完整計時拆分和多輪重跑，仍是後續要補的證據。這篇記錄的是目前能確定的決策脈絡，而不是把尚未驗證的因果關係包裝成結論。

如果你也正在做 LLM 模型選型，或曾遇過「整體分數很高，卻仍缺乏上線把握」的情況，歡迎到 Threads 和我分享。我會繼續記錄模型、Prompt、OCR 與評估流程中實際遇到的限制與判斷。