在 LLM 上蓋東西的團隊最後都會問同一個問題:我們該不該微調?通常是在 prompt 已經膨脹到 3000 token、模型還是不穩、有人讀到部落格說微調解決一切之後。
通常答案是:不。或更精確說:還不要。Prompt 工程、RAG、few-shot 範例 —— 按這個順序 —— 解決 90% 的「模型沒做我要它做的事」問題。微調是剩下 10% 的對的答案,把那 10% 做對需要知道你真的在那 10% 裡。
這是決策樹。
各個技巧實際在做什麼
快速複習:
- Prompt 工程。 改 prompt 的措辭、結構、範例,引出更好回應。不改模型、不要資料、不要訓練。
- Few-shot prompting。 Prompt 工程的子集:在 prompt 裡塞 2-10 個 input/output 配對,教格式跟行為。
- RAG。 檢索相關文件、注入 prompt 當 context、模型用它們回答。加知識,不加行為。
- 微調。 拿基底模型在你的資料上繼續訓練。改模型實際權重,跨呼叫持續,不需要每次 prompt 都送範例。
各自解不同問題。
決策樹
給一個問題,按順序走這個清單。別跳步。
第 1 步:更好 prompt + few-shot 範例
大部分「模型錯了」問題是 prompt 問題。試:
- 更具體。 「總結這個」→「用 3 個 bullet 總結這個,每個 bullet 用動作動詞開頭。」
- 加 few-shot 範例。 給模型看 3-5 個你要的 input/output 配對。
- 用更強模型。 Claude Sonnet 有時在同一 prompt 上贏 Haiku;付 4× 跳過工程。
- 約束輸出。 用結構化輸出 / tool use / JSON mode 強制形狀。
- 重讀你的 system prompt。 超過 1000 token 大概在某處自相矛盾。
解:格式遵守、語氣、簡單分類、基本抽取、大部分「請用這個風格回答」問題。
第 2 步:RAG
如果問題是「模型不知道我的資料」—— 內部文件、最近事件、客戶特定脈絡 —— 95% 時候 RAG 才是答案。微調修不了這個,模型需要在推論時拿到實際資訊。
解:「回答關於我們公司的問題」、「參考我們的文件」、「總結這個特定文件」。
第 3 步:更好的 tool use / agent 設計
如果模型「能力缺失」—— 不能搜網路、不能跑程式、不能更新 DB —— 給它工具。別微調它來假裝有能力。
解:「我要它真的做事」、「我要它抓最新資料」、「我要它跟我們系統互動」。
第 4 步:微調
現在才考慮微調。到這裡你已經試完便宜選項了。微調對的時機:
- 格式 / 行為一致而 prompt 強制不可靠。 你要每個輸出長得完全像 X,即使 10 個 few-shot 加結構化輸出,5% 還是漂掉。
- 你的 prompt 太長以致成本不划算。 每次請求送 5000 token prompt 很貴,微調把行為烤進權重,prompt 降到 200 token。
- 延遲重要而 token 是瓶頸。 同上,進的 token 少 = 回應快。
- 隱私 / 合規需要本地跑。 自家部署的微調開源權重模型。
- 基底模型搞砸的特定領域語言。 法律術語、醫療縮寫、交易詞彙,基底模型預設用門外漢解釋。
微調不可靠地教新事實。如果模型要知道你公司的 API endpoint,微調勉強可以但 RAG 更好。微調教行為,不教知識。
真實數字
2025 年一個我合作的團隊跑這個實驗。任務:把客服工單分到 18 個類別。
- 基線(Sonnet 沒範例): 71% 準確率。
- + 5 個 few-shot 範例: 84% 準確率。
- + 帶類別描述的更強 system prompt: 88% 準確率。
- 換 Opus: 92% 準確率。(每千次分類 $60 vs $5。)
- 800 個標記範例上微調 Haiku: 91% 準確率。(每千次分類 $0.40。)
微調 Haiku 在 1/150 成本下打平 Opus 準確率。那就是微調賺到的時候 —— 規模、可量差距、穩定任務上。
如果他們是 100 次分類/天,微調的力氣不值得。他們是 50,000/天,數學很殘酷。
微調失敗(或浪費時間)的時機
已知反 pattern:
- 少於 200 個範例微調。 你會教風格不教能力,省時間。
- 微調來教事實。 「我的產品 2026 年三月上線」—— 微調不會可靠編碼這個。用 RAG。
- 沒驗證的合成資料微調。 LLM 生的訓練資料有 bug,模型學到 bug。
- 微調代替 debug prompt。 Prompt 迭代修得了的東西,先做那個。微調一個不穩問題只是讓它變成你不容易改的不穩問題。
- 在 RAG + 開源權重就夠用時微調前沿閉源模型。 永遠鎖在那廠商的定價。
LoRA 在開源權重上呢?
LoRA 顯著改變數學。對比 GPT-4 全微調,Llama 3.3 70B 上 LoRA:
- 訓練便宜 100×。
- 部署便宜 1000×。
- Adapter 200MB,好換好版本控制。
- 同樣的根本取捨(還是教行為、不教事實)。
有 LoRA,「微調值得嗎?」門檻大幅降低。5,000 次分類/天的團隊可能在 LoRA 上打平,在前沿 API 微調上打不平。
微調的隱藏成本
大家忘記的三個成本:
- 維護。 基底模型定期更新。你的微調版本不會免費拿到那些升級。Llama 3.4 出貨在你任務上好 8%,你必須重微調。
- 評測債。 微調需要 hold-out 測試集。之前沒評測就現在要蓋,大部分團隊跳過然後後悔的三天工作。
- Catastrophic forgetting。 窄微調讓模型在通用任務上變差。產品擴展到訓練分布之外時,你會看到沒預期的 regression。
務實操作順序
對任何「模型沒做我要它做的事」問題:
- 把你的 prompt 大聲念出來,清楚嗎?
- 加 3-5 個 few-shot 範例。
- 試下一個更強模型(Haiku → Sonnet → Opus),記成本差。
- 加結構化輸出 / tool use 約束形狀。
- 如果是知識問題:加 RAG。
- 如果是能力問題:加工具。
- 現在對你的 eval set benchmark,差距多大?
- 差距小或可以付更大模型錢:停,你完了。
- 差距大、任務穩定、有 500+ 標記範例:微調。
- 微調了,跑同一個 eval set,比較。要願意 roll back。
什麼時候完全不要微調
- MVP 之前。 最快迭代是 prompt + 基底模型,別把自己鎖在下個月會改的權重上。
- 資料集很小。 200 個以下只是風格轉移,用 few-shot。
- 需求快速變動。 產品需要每週變,你微調不了那麼快。黏 prompt。
- 你還沒量 prompt 工程夠不夠。 沒 eval set 你就矇眼飛,微調讓 bug 更難找。
下一步
- 本 Learn 庫的「在本機微調 Llama」那篇。
- Fine-tuning vs RAG —— Microsoft Research 文章,仍然相關。
- PEFT survey(Hu et al, 2024)—— LoRA、DoRA、adapter 方法總覽。
- 查這些詞:catastrophic forgetting、instruction tuning、parameter-efficient fine-tuning、LoRA vs RAG。