LLM 微調把通用模型變專用工具

我把企業 LLM 微調拆成一套可直接抄的流程，從資料準備到模型選擇都講白。

我拿 LLM 在 production 跑了一陣子，才發現 demo 跟真的上線是兩回事。前者很會講漂亮話，後者一碰到真實政策、產品文件、客服語氣，就開始「差一點」。它不是完全答錯，它是用對了詞，卻踩錯了規則；看起來很自信，實際上剛好錯在最要命的地方。這種錯最煩，因為你不是立刻爆炸，而是慢慢把時間燒光。

我後來越來越確定，很多團隊對 fine-tuning 的想像都歪掉了。太早微調，想把應該交給檢索的事硬塞進權重；太晚微調，則是一直改 prompt，改到最後模型還是在錯的格式、錯的語氣、錯的邊界上打轉。我兩種都看過，真的很像在拿膠帶補水管。不是不能補，是你補錯地方。

這次把我拉回正軌的是 AI Multiple 的 enterprise LLM fine-tuning 指南。它講得很直白：模型如果缺的是最新事實，先想 retrieval；模型如果有事實、但行為不對，才輪到 fine-tuning。這個切法很實用，少走很多冤枉路。

先別把 fine-tuning 當資料垃圾桶

If your LLM doesn’t have access to the facts needed in your domain, either train a new LLM, switch to a domain-specific one, or use RAG to retrieve facts. If it has relevant facts but needs to answer in a different style and tone, follow certain output formats, or use certain tools, then fine-tuning is the right approach.

翻譯一下就是：微調不是知識庫，也不是拿來塞最新政策、產品規格、PDF 亂碼的地方。模型如果缺的是「現在的事實」，我寧可先接 RAG 或其他檢索系統；如果它知道大方向，但就是老愛講錯格式、講錯口氣、講錯工具流程，這時候才是 fine-tuning 的場子。

我之前做過一個客服助理案子，團隊第一個反應就是拿 tickets 去微調。聽起來很勤勞，實際上很危險。因為 tickets 裡面有過期政策、有例外條款、有一堆人類自己也講不清楚的語句。你把這些直接灌進去，模型只會學到一種更有自信的混亂。

後來我們改成兩層：上面一層用檢索抓最新政策文件，下面一層只微調回答格式跟語氣。結果很明顯，系統更好維護，因為事實會變，但行為變得比較慢。這就是我現在最在意的分工：事實交給 retrieval，行為交給 fine-tuning。

實操寫法很簡單：

• 答案依賴最新文件、政策、產品資料時，先用 RAG，不要先想訓練。
• 模型知道答案，但老是答錯格式、分類邊界、語氣或工具調用時，再考慮微調。
• 兩者都要時，就分層做，不要硬混成一鍋。

這個判斷做對，很多訓練預算直接省掉，還少掉一堆「怎麼又要重跑」的會議。

資料要新，因為世界本來就會變

AI Multiple 提到企業會把 real-time web data 放進資料準備，原因很簡單：模型訓練完就固定在那個時間點，不會自己知道昨天政策改了、術語換了、流程重寫了。這句話看起來平常，但很多團隊真的還活在「模型學完就應該懂所有事」的幻想裡。

我自己的理解是，training data 不是越多越好，而是越像模型真正在工作的世界越好。你如果做法律、金融、醫療，或任何偏專業的 domain，我會想要最近的術語、真實的工作流程、還有使用者真的會問的句型。web data 的價值不是乾淨，是新，而且夠像人會怎麼講。

我看過太多團隊只餵內部文件，結果模型講話像 2019 年的政策手冊。那種語氣一看就知道是「有學到，但沒活在現場」。而且很多 hallucination 不是模型天生愛亂掰，是它缺了一塊，然後用看起來合理的東西補上去。這種補法最可怕，因為它很順。

AI Multiple 舉的例子是法律科技公司抓最近法院判決和法律部落格。這方向我認同。你不是在蒐集文本而已，你是在蒐集 domain 的形狀：怎麼引用、怎麼下定義、怎麼講例外、怎麼說才像圈內人。

實操寫法我會這樣做：

• 先設資料來源規則，再談訓練，不要反過來。
• 優先選最近、權威、可追溯的來源，不要只追求量。
• 做 dedupe，刪 boilerplate、近重複頁、低訊號內容。
• 保留 source log，之後才講得清楚每筆資料從哪來。

如果這步偷懶，你不是在訓練聰明模型，你是在把噪音教得更像樣。

hallucination 不是消失，是被你訓練到比較老實

AI Multiple 說高品質真實資料可以降低 hallucination，這方向沒錯，但我會講得更精準一點：fine-tuning 不會把 hallucination 從宇宙裡刪掉，它只是把模型在你要的地方收斂得比較像樣。

也就是說，模型會少在你示範過很多次的地方亂猜。你給的例子一致，它就學會一致；你給的例子亂七八糟，它就學會更精緻地亂七八糟。很多人以為模型不穩是因為參數不夠，其實常常是 supervision 本身就很爛。

我之前做過一個文件抽取流程，base model 抽欄位其實不差，但它老愛幫缺值腦補。後來我們在 fine-tune 資料裡刻意放了很多「unknown」「not provided」「N/A」的例子，並且讓模型知道什麼時候要留白，結果最危險的誤判少很多。不是完美，但已經夠把風險壓下去。

這裡最容易踩雷的是：團隊看到 hallucination，就以為模型要更多知識。很多時候不是。它需要的是更強的拒答模式、更清楚的輸出 schema，或是更多例子告訴它「沒資料就別硬掰」。fine-tuning 很擅長教這種邊界。

實操寫法我會這樣落地：

• 放 negative examples，明確示範什麼不要答。
• 把 abstention 寫進資料：unknown、blank、escalate 都要有。
• 評估不要只看 accuracy，也要看 false confidence。

如果你只看 exact match，會錯過真正危險的地方：模型講得很順，但其實在漂。

模型怎麼選，先看控制權，不是先看名氣

來源裡有個很務實的分岔：要嘛用雲端供應商提供的 managed fine-tuning，要嘛用 open-source model 在 on-prem 自己訓。這其實就是大多數 enterprise 真正在做的選擇，只是大家常常講得很高尚，像在選哲學，其實是在選限制條件。

翻譯一下就是：模型選擇不是只看 benchmark，也不是只看誰名字比較大，而是看你的資料放哪裡、誰能碰、你能不能接受訓練與推論的營運成本。如果你要供應商幫你把訓練流程包起來，managed tuning 比較省事；如果你的資料很敏感、很受監管、不能隨便搬，open-source on-prem 才比較像正解。

AI Multiple 提到 Google Vertex AI、Anthropic Claude 搭配 Amazon Bedrock，以及 OpenAI fine-tuning 狀態的變動。這些工具會變，但你要解的問題不會變：你到底能不能把資料、治理、部署，整條鏈接住。

我看過不少團隊先挑一個 benchmark 很漂亮的模型，結果真的要上線時才發現 fine-tuning 路徑不合規、不好管、或是根本接不上既有 infra。那時候再換，成本比一開始選錯還痛。性能只是其中一軸，營運順不順才是另一軸。

實操寫法很直接：

• 想快一點落地，就先看 managed tuning。
• 資料 locality、auditability、客製 infra 比較重要，就看 open-source on-prem。
• 訓練前先測推論成本，別只看 training cost，預算通常死在後面。

我真的建議你先跑 deployment path，再決定要不要訓練。這件事我踩過坑，不想你也踩。

資料清理才是主菜，訓練只是收尾

AI Multiple 把流程拆成 dataset prep、model choice、tuning，這個順序我大致同意，但我會再講狠一點：dataset 才是產品，training run 只是儀式。

也就是說，你的例子不是收集回來就好，而是要被設計成「能教會模型的樣子」。如果你在調客服回覆，每筆資料要有 input、ideal output、以及你要它遵守的語氣。如果你在做 classification，label 一致性比文筆漂亮更重要。如果你在做 tool use，動作順序比句子多華麗都沒用。

我看過太多資料集，表面上都「相關」，實際上完全不能訓練。語氣每筆都不一樣、label 邊界模糊、同一筆資料混好幾個任務。模型學到的不是能力，是混亂。這不是模型壞掉，是 supervision 壞掉。

我現在會先過這份清單，過不掉就不訓練：

• 把 label 跟輸出格式統一。
• 刪除重複與近重複樣本。
• 依任務切資料，不要只依來源切。
• 保留一份能反映 production failure 的 test set。

最後那點很重要。你的 evaluation set 如果太乾淨，跑出來會很好看，但一上線就爛掉。我反而喜歡把難例放進去，讓模型在最容易出事的地方先證明自己。

持續微調可以做，但前提是你真的有版本控管

來源裡提到 checkpoints 和 continuous tuning，這提醒我一件事：fine-tuning 不一定只能做一次。有些 domain 變得很快，模型也該跟著更新。

翻譯一下就是：如果你的產品、法規、術語、流程一直在變，靜態模型凍一年再一次大改版，通常只會製造更多驚喜。這種情境下，持續微調是合理的，但前提是你要有版本、回滾、和明確的評估門檻。

我對 continuous tuning 一直很保留，因為它聽起來很優雅，實際上很容易變成一個沒有基準的移動目標。今天加一批資料，明天改一個 prompt，後天有人說效果怪怪的，但沒人知道是哪一步造成的。這種系統最貴，因為你根本不知道問題在哪。

我比較喜歡 checkpoint 的原因很無聊：它讓我能回頭。新一輪 tuning 如果傷到某個重要 slice，我要能比對上一版，然後立刻停損。這種 boring engineering，通常才是真正能活下來的做法。

實操寫法我會這樣定：

• dataset、prompt、checkpoint 一起版本化。
• 每次 tuning 後都跑 slice-based evaluation。
• 保留 last good model 的 rollback 路徑。

這不帥，但很管用。企業 workflow 最怕的不是慢，是沒人知道自己到底在改什麼。

可抄的模板

# Enterprise LLM Fine-Tuning Playbook（可直接抄版）

## 1) 先判斷要不要微調
只有在模型「知道大方向，但行為不對」時才微調。

適合微調的情況：
- 語氣不對
- 格式不對
- 分類邊界不穩
- 工具調用順序錯
- 拒答/轉人工規則不一致

不適合微調的情況：
- 需要最新政策
- 需要即時產品資訊
- 需要可追溯引用
- 需要頻繁更新的事實

## 2) 任務定義只寫一句話
範例：
"把客服問題分類成 12 類，並用公司標準語氣輸出答案。"

## 3) 資料欄位固定
每筆訓練資料至少包含：
- input
- ideal_output
- label
- source
- version
- notes

## 4) 資料清理規則
訓練前先做：
- 去重
- 去近重複
- label 正規化
- 移除矛盾樣本
- 刪除低訊號 boilerplate
- 分離不同任務

## 5) 模型選擇
- managed fine-tuning：要快、要省事、供應商治理能接受
- open-source on-prem：資料不能亂跑、要 audit、要自建 infra

## 6) 微調方法
- supervised fine-tuning：學輸入到輸出的固定行為
- preference tuning：學會偏好更好的答案
- continuous tuning：只有在 domain 常變時才用

## 7) 評估指標
至少要看：
- 核心任務準確率
- 格式符合率
- 拒答品質
- hallucination rate
- edge case 表現
- false confidence

## 8) 上線前鎖版本
每次 release 都要綁：
- model version
- dataset version
- evaluation report
- rollback plan
- owner

## 9) 範例訓練資料
{
  "input": "Customer asks whether refund is available after 45 days.",
  "ideal_output": "Refunds are available within 30 days of purchase. After that window, we can offer store credit if the item meets policy requirements.",
  "label": "billing_policy",
  "source": "policy-doc-v12",
  "version": "2026-06",
  "notes": "Do not invent exceptions; escalate if policy is unclear."
}

## 10) 一句話總結
facts 用 retrieval，behavior 用 fine-tuning，版本控管用 checkpoints。

這份模板就是我最想直接丟給團隊的版本。它不花俏，但很能避免你把模型訓練成一台會講話的事故機器。

原始來源是 AI Multiple 的 LLM Fine-Tuning Guide for Enterprises，我這篇是根據它的觀點做拆解與重組；案例、措辭和可抄模板是我的整理，不是原文逐字翻譯。