SLM 微調把企業 AI 變可用

我拆 CogitX 的 SLM 微調 playbook，整理成企業訓練、評估、部署都能直接照抄的模板。

我看企業團隊把大模型硬塞進流程一陣子了，老實講，開局都差不多：先接一個看起來很聰明的 API，再堆一串 prompt，兩週後大家開始翻白眼。模型太愛講、太貴、太慢，或是明明要的是固定格式，它卻一直往泛用回答那邊飄。我也看過不少團隊想靠更多 system message、更多 guardrail、更多「再調一次」去補洞，最後只是把問題包裝得更漂亮而已。

我後來才慢慢想通：很多企業問題不是「需要更聰明的模型」，而是「需要一個更小、但行為更準的模型」。這也是我會去看 CogitX 這篇文章的原因。它不是在賣情懷，講的是成本、延遲、治理、部署控制這些很無聊但很真實的事。企業 AI 最常卡住的，通常也就是這些事。

我下面拆的，不只來自 CogitX，也會順手拉幾個我認為真正有用的參考：Hugging Face PEFT、vLLM、QLoRA。這些東西放一起看，才比較像真的在做產品，不是只在做 demo。

企業不是為了好玩才微調

「The motivations are operational, not ideological. Cost, latency, data governance, and deployment control are driving forces.」

翻譯一下就是：大多數團隊不是因為想養模型才去微調，而是被現實逼的。API 帳單太兇，回應時間慢到使用者抱怨，法務說資料不能出境，或是上游供應商偷偷改了行為，結果你們的工作流整個歪掉。

我自己在支援自動化跟內部 copilots 上也碰過同樣的模式。第一版永遠是通用大模型加一點 prompt，demo 的時候很體面。流量一上來，邊界案例一出現，問題就爆了：同一個合約條款抓不到、同一種 ticket 分類錯、同一個欄位格式一直亂掉。這時候再談 fine-tuning，就不再是 ML 愛好者的興趣，而是系統設計的一部分。

CogitX 把這件事講得很直白：如果任務窄、重複、又對延遲或治理敏感，那小模型加正確訓練資料，通常比硬撐大模型更合理。這不代表「全部都要微調」，而是說預設思路應該先看經濟性跟控制權，不要先拜模型大小。

實操寫法很簡單：先把失敗模式寫清楚。到底是每次成本太高、首 token 太慢、輸出格式一直漂、還是資料不能離開內網？你只要把痛點說準，才知道微調是不是在解題，還是在幫團隊找事做。

• 任務廣、需求常變、還在探索期，就先用 API LLM。
• 任務固定、重複量大、格式敏感，就考慮 SLM 微調。
• 兩者都要時，就把 retrieval 跟 behavior shaping 分開處理。

真正值得微調的，通常都是很無聊的任務

CogitX 提到的好案例很務實：ticket 分類、entity extraction、文件路由、結構化摘要、HR policy Q&A 這種。這就是很多團隊卡住的地方。他們想把模型訓成萬能助理，然後驚訝為什麼它沒有變成更強的通用模型。因為本來就不是這樣玩的。

白話講，微調最強的地方不是「教它知道整個世界」，而是「教它學會一個模式」。如果你的答案大多是把輸入映射成 schema、label set、固定語氣，那訓練通常比 prompt 工程更穩。反過來，如果答案依賴即時資料、政策一直變，那微調就會很笨重。

我在文件處理上見過這種差異很明顯。基礎模型大多看得懂字，但它還是會吐出半殘 JSON、自己發明欄位，或漏掉下游系統要求的正規化規則。你一旦用乾淨的範例去微調，模型就不太會亂演了。它變得沒那麼聰明，卻剛好是你要的樣子。

實操寫法：先挑一批最適合被訓練的工作，條件是重複、可量化、而且 prompt 你已經調到有點煩。只要你能用 schema、label 或固定回覆格式定義成功，這種任務就比「做個 assistant」更適合拿來微調。

• 適合：分類、抽取、路由、模板化摘要。
• 不適合：即時事實、開放式研究、快速變動政策。
• 灰區：需要 retrieval 又要格式穩定的 domain copilot。

LoRA 和 QLoRA 讓這件事終於像樣

CogitX 把 LoRA 跟 QLoRA 拉進來，我覺得很對。對大多數企業團隊來說，full fine-tuning 太重、也太貴。LoRA 是把 base model 凍住，只訓練低秩 adapter 權重；QLoRA 更進一步，把 base model 用 4-bit 量化載入，再用較高精度訓練 adapter。這讓 7B 級模型在比 full precision 小得多的硬體上就能微調。

也就是說，你不需要一整座 GPU 農場才有辦法從微調拿到價值。你需要的是一條正常的訓練管線、夠代表性的資料，以及一個本來就已經接近任務的模型。這也是為什麼 PEFT 這類工具很重要，它把 adapter-based training 變成預設路線，而不是要 infra 團隊陪研究部門玩的一次性專案。

我以前待過一些團隊，微調討論一開始就死掉，原因很單純：大家以為 fine-tuning 就是燒 cluster 預算。那是舊觀念了。現在這類方法的瓶頸通常不是算力，而是 dataset 乾不乾淨，能不能真的教出你要的行為。

實操寫法：如果你是從零開始，先用 PEFT 做 LoRA。只有在你有很明確的理由時，才往更複雜的方法走。若你在意 serving throughput，再看像 vLLM 這種 adapter-aware runtime，或參考 S-LoRA 這類多 adapter 方案。

Instruction tuning 才是在學你公司的說話方式

CogitX 對 instruction-response pairs 的重視，我完全同意。很多團隊太愛先看 rank、batch size、learning rate，卻沒先檢查 examples 一不一致。這順序根本反了。

instruction tuning 的意思很單純：你拿真實工作長相的指令和答案去訓練。不是原始文本，不是亂剪的片段，而是實際會發生的請求與你想要的輸出。如果客服要的是禮貌、簡潔、還要帶升級邏輯，那就訓練那種回答；如果法務流程需要的是固定 JSON，那就訓練那個 JSON。

翻白話一點，模型學的其實是你公司的習慣：語氣、格式、拒答方式、什麼時候該停嘴，這些都能訓練。這也是為什麼 instruction tuning 很適合企業場景。企業不太在乎創意爆發，企業在乎的是每次都一樣、不要亂來。

我自己碰過 procurement assistant 一直愛寫長篇大論，但下游系統只吃結構化欄位。prompt 當然可以救一下，但只救一天。最後還是靠微調，因為模型看夠了正確輸出長什麼樣，才會停止自由發揮。

實操寫法：用真實工作流長出訓練例子，不要只拿 synthetic toy prompt。每一筆 sample 都只回答一件事：人類問這個問題時，模型應該怎麼做？如果你自己都寫不出理想答案，代表你還沒準備好訓練目標。

資料品質才是全部，synthetic data 只能當配菜

CogitX 花很多篇幅講資料準備，我也覺得這才是應該花時間的地方。他們提到 internal documents、conversation logs、synthetic data 當主要來源，這方向沒問題。但重點不是「資料越多越好」，而是「資料要乾淨、一致、夠代表性」。

簡單講，小而乾淨的資料集，常常會贏過大而髒的資料集。去重很重要，schema 正規化很重要，PII 移除很重要，還有每個例子的 instruction style 要一致。如果 label 很模糊，模型就學會模糊；如果輸出常常不一樣，模型就會變得不穩定。

synthetic data 這點可以留著用，但要用對。CogitX 提到 Scale AI 的 NeurIPS 2024 研究方向，我看法也差不多：synthetic data 有用的前提，是它要建立在真實來源上，再用合理策略擴增。你如果只是叫模型憑空亂造，然後把那堆東西當訓練資料，最後通常只是把錯誤放大。

實操寫法：synthetic generation 用來補 coverage，不要拿來取代 domain truth。先從真實工作流抽一小包 gold set，再圍繞它生成變體。進訓練前，先用 schema 跟 domain rules 驗過一次。

• 來源優先順序：內部文件、人工標註輸出、對話紀錄。
• 訓練前先做欄位統一、格式正規化、去重。
• gold evaluation set 要跟 training data 分開鎖住。

RAG 和微調不是互斥，是分工

CogitX 這段我很認同，因為這大概是企業架構最常被講歪的地方。大家老愛把 retrieval-augmented generation 跟 fine-tuning 當成兩派在吵架，好像只能選一邊。其實它們解的是不同問題。

如果知識變很快、需要引用來源、或不同使用者能看的資料不一樣，那 RAG 比較對。若是行為本身要變：格式、語氣、路由邏輯、拒答風格、領域模式辨識，那微調比較對。你如果想用微調去做即時知識查詢，那是在用錯工具；你如果想靠 RAG 教模型怎麼做人，那也是錯的。

白話講，最實際的企業系統通常是兩個一起上。RAG 提供新鮮事實和可追溯性，微調負責讓模型在拿到 context 之後，照你要的方式回話。這比硬逼單一機制扛全部，合理太多。

我看過 compliance workflow 這樣做得很好：retrieval layer 拉最新 policy，fine-tuned model 負責把答案整理成法務要的格式。這樣拆比起只靠一串 prompt 祈禱模型聽話，清楚很多。

實操寫法：先問兩題。第一，這個任務需不需要新鮮知識？需要就上 retrieval。第二，這個任務需不需要穩定行為？需要就微調。如果兩題都要，直接組合，不要假裝只能二選一。

部署才是把理論打回現實的地方

CogitX 提到 on-prem serving、quantization、inference tooling，這些才是實戰裡真正會咬人的地方。訓練只是前半段；如果模型慢、難更新、也無法監控，專案還是會死。

也就是說，部署限制應該從第一天就反推模型選擇。用 vLLM 在單張 GPU 上服務一個 7B 模型，跟用大型 hosted API，營運故事完全不同。前者讓你有更多控制、更低延遲、更好的資料駐留；後者省事，但你要自己承擔 uptime、patching、adapter versioning 和 rollback。

我看過團隊低估這一段，然後很快後悔。他們訓練出一個還不錯的 adapter，上線後才發現沒人定義怎麼先用 production inputs 驗證，再切版本。這種時候，模型改進就會直接變成支援事故。

實操寫法：把 model release 當 software release 管。base model、adapter、dataset、evaluation set 都要版本化。rollback 路徑先放好。production 裡要量 latency、throughput、failure rate，不要只看 offline accuracy。

可抄的模板

## 企業 SLM 微調 playbook

### 1) 先挑對任務
只在以下情況考慮微調：
- 重複性高
- 範圍明確
- 可量化
- 對格式、語氣、路由敏感

不要微調來做：
- 即時事實查詢
- 開放式研究
- 快速變動政策
- 廣義助理

### 2) 定義你要的行為
用一句話寫清楚：
- 輸入類型
- 輸出 schema
- 語氣
- 拒答規則
- 升級規則

例：
「收到客服單後，分類問題、抽取實體，並回傳符合 JSON 格式的五類標籤之一。」

### 3) 建資料集
來源：
- 內部文件
- 人工標註的工作輸出
- 對話紀錄
- 以真實例子為基礎的 synthetic variants

資料規則：
- 移除 PII
- 語意去重
- 格式正規化
- 保留獨立的 gold eval set
- 拒絕模糊標籤

### 4) 用 instruction tuning 格式
用 instruction-response pairs 訓練。

例：
{
  "instruction": "抽出合約雙方與生效日期。",
  "context": "This Agreement is entered into as of January 1, 2025...",
  "response": "{\"parties\":[\"Acme Corp\",\"Vertex Ltd\"],\"effective_date\":\"2025-01-01\"}"
}

### 5) 先從 LoRA 或 QLoRA 開始
預設建議：
- base model：7B 到 8B 的開源模型
- fine-tuning 方法：LoRA
- GPU 記憶體吃緊：QLoRA
- serving：vLLM 或相容的 adapter-aware runtime

### 6) 上線前先評估
同時看兩種：
- 任務指標：exact match、F1、schema validity、routing accuracy
- 人工審查：邊界案例、語氣、拒答行為

沒有 held-out eval set，不要上線。

### 7) 判斷 RAG 要不要留著
適合用 RAG 的情況：
- 事實常變
- 需要引用來源
- 不同使用者權限不同

適合用微調的情況：
- 行為要穩定
- 輸出格式要精準
- 延遲很重要

兩者都需要時，就一起用。

### 8) 像軟體一樣部署
追蹤：
- base model version
- adapter version
- dataset version
- eval set version
- latency
- throughput
- rollback path

### 9) 上線檢查清單
- [ ] schema validation 通過
- [ ] PII 已移除
- [ ] eval set 已鎖定
- [ ] rollback 已測試
- [ ] 壓力下 latency 已量測
- [ ] 邊界案例有人審
- [ ] monitoring alerts 已定義

### 10) 簡單決策規則
任務窄而重複，就微調。
任務需要新鮮事實，就加 RAG。
兩者都要，就組合。
任務廣又不穩，就不要硬上微調。

這就是我會直接丟給團隊的版本。它不花俏，但它會逼大家先問對問題，這通常就是最缺的那一步。

原始來源是 https://cogitx.ai/blog/fine-tuning-slms-for-enterprise-use-cases。我這篇是衍生拆解，核心框架來自原文，模板跟實戰整理是我自己為開發者重組過的版本。

另外我參考了 Hugging Face PEFT、vLLM、QLoRA、S-LoRA 這幾個公開資源，方便你真的把這套流程接進工作裡。