系統該重寫還是改造？Google 用一則模型新聞打臉多數人

最近看到一則技術報告，Google DeepMind 沒有從零訓練新模型，而是把現成的語言模型改造成擴散式生成架構，花掉的預算不到原本訓練成本的一成。結果數獨這種需要「先想後寫、寫錯能改」的題目，原版完全解不出來，改造版正確率衝到八成五。這不是一則單純的AI新聞，這是一堂關於「到底該重寫還是改造」的實戰課，剛好是我每個月都要跟客戶吵一輪的話題。

一般語言模型的死穴，跟你們家舊系統一樣

原本的模型是逐字往外吐，字一送出去就收不回來，算數學算到一半發現前面錯了，只能硬著頭皮在後面補救。這跟很多企業內部系統一模一樣：資料一旦寫進去，流程一旦跑下去，發現邏輯錯了也只能疊補丁，不敢往回改，因為誰也不知道改了會炸掉哪個下游。改造後的版本一次處理256個token，定稿前可以回頭修正早期的錯誤，這才是真正解決問題的方式，不是靠事後補丁，是讓系統本身有「反悔」的能力。

重寫是最貴的選項，但也是最多人選的選項

我接過不少案子，客戶開口就是「這套系統跑了五六年，介面醜、邏輯亂，全部砍掉重寫」。聽起來很爽，但重寫代表你要把五年來所有業務邊界情況、例外規則、跟前任工程師留下的神秘註解全部重新理解一次，成本跟風險都是指數級。Google這次示範的是另一條路：核心模型骨架不變，只換掉「怎麼產生輸出」的方式，訓練預算壓到原本的十分之一以下，效果在特定任務上反而超車。企業系統很多時候問題不在資料結構或核心邏輯，而在輸出跟串接的方式太笨，這種情況根本不需要重寫。

• 先問問題出在哪一層：資料模型錯了才需要動骨架，流程慢、格式亂通常只是輸出層的問題
• 估算改造成本佔重寫成本的比例，低於三成就該優先試改造
• 小範圍先驗證，別一次把全系統都下注在一個新架構上
• 保留舊系統當備援，改造失敗要能隨時退回，這比任何酷炫架構都重要

代價一定有，別被成功案例騙了

這次的擴散模型也不是萬能，品質還是輸原版，偶爾會卡在重複迴圈一直吐同一個詞，同時處理超過三十幾個請求，速度優勢就整個消失。Google自己都標明這是實驗性模型。這提醒我們，改造不是沒有代價的魔法，是拿明確的限制去換明確的成本節省。企業導入AI或系統改造前，一定要先把限制條件寫清楚，不是等上線出包才發現「原來這招在高併發場景會爆」。

會重寫的人到處都是，敢在舊東西上動刀改造的人不多。前者花的是錢，後者花的是判斷力。