Fine-tuning 實作指南：從資料準備到模型部署的安全流程

什麼是 Fine-tuning？

Fine-tuning（微調）是把一個已經訓練好的 AI 模型，用你自己的資料再做一輪訓練，讓它學會你需要的特定行為或知識。

用駕訓班的比喻來說：預訓練（Pre-training）像是在駕訓班學會開車的基本技能。Fine-tuning 像是拿到駕照後，開始跑你每天上班的路線——你已經會開車了，但需要熟悉特定路線的紅綠燈、彎道、和停車位置。

技術上，Fine-tuning 是用一組標註好的資料（通常是 input-output pairs），在預訓練模型的基礎上繼續訓練。訓練的過程會調整模型的部分或全部參數，讓模型在你的特定任務上表現更好。

Fine-tuning 和 Prompt Engineering 的差異在於：Prompt Engineering 不改變模型本身，只是透過指令告訴模型你要什麼。Fine-tuning 改變了模型的參數，讓它從「根本上」學會新的行為。就像是 Prompt Engineering 是每次開車前看導航，Fine-tuning 是把路線記在腦裡不用再看導航。

Fine-tuning 和 RAG（檢索增強生成）的差異在於：RAG 不改變模型，而是在模型回答時附上相關的參考資料。Fine-tuning 改變模型的行為模式。RAG 適合「讓模型知道新資訊」，Fine-tuning 適合「讓模型學會新的行為方式」。

什麼時候需要 Fine-tuning？

不是每個 AI 應用都需要 Fine-tuning。多數時候，好的 Prompt Engineering 或 RAG 就夠了。Fine-tuning 的成本和複雜度都比較高，應該在確認其他方法不夠用的時候才做。

需要 Fine-tuning 的場景：

你需要模型持續使用特定的輸出格式。例如你的客服系統需要 AI 每次都用固定的 JSON 結構回傳分類結果和信心分數，Prompt 的格式指令有時候會被忽略，Fine-tuning 可以讓模型穩定地遵循格式。

你需要模型理解專業領域的用語。法律、醫療、金融領域有大量的專業術語和特定用法，Fine-tuning 可以讓模型更準確地理解和使用這些用語。

你需要降低延遲或成本。Fine-tuned 的小模型（7B-13B 參數）在特定任務上可能表現接近未 Fine-tune 的大模型（70B+），但推論成本低很多。如果你有一個高頻呼叫的場景（每秒處理幾百個請求），Fine-tuning 小模型可以大幅降低 API 費用。

你需要模型學會特定的語氣或風格。品牌有固定的溝通風格，每次在 Prompt 裡寫風格指南太長也太不穩定，Fine-tuning 可以把風格「嵌入」模型中。

不需要 Fine-tuning 的場景：

你只是想讓模型知道你公司的產品資訊——用 RAG 把產品文件當作參考資料傳給模型就好。

你的需求用 Prompt 就能穩定達成——先在 Prompt Engineering 上花時間，確認真的不夠用再考慮 Fine-tuning。

你的資料量太少（少於 100 筆高品質範例）——資料太少的 Fine-tuning 效果不穩定，甚至可能讓模型表現變差。

資料準備：最關鍵的一步

Fine-tuning 的效果 80% 取決於資料品質。「垃圾進、垃圾出」在 Fine-tuning 中特別明顯——如果你的訓練資料本身有錯誤、不一致、或偏差，Fine-tuned 的模型會忠實地學會這些問題。

資料格式

多數平台接受 JSONL 格式，每一行是一筆訓練範例：

{"messages": [{"role": "system", "content": "你是一個客服分類助手"}, {"role": "user", "content": "我的訂單還沒到"}, {"role": "assistant", "content": "類別：物流問題\n優先度：中\n建議回覆：查詢物流狀態並回覆預計到貨時間"}]}

每筆範例包含：系統提示（定義角色）、使用者輸入、期望的 AI 輸出。AI 輸出就是你要模型學會的「正確答案」。

資料品質檢查

一致性。同類型的問題應該有一致的回答格式。如果有些範例用條列式、有些用段落式、有些格式混亂，模型學到的行為也會不一致。

正確性。每一筆範例的「正確答案」都應該經過人工驗證。不要用另一個 AI 的輸出當作訓練資料——除非你已經驗證過那些輸出的品質。

多樣性。訓練資料要涵蓋你預期模型會遇到的各種情境。如果你的資料全部是退貨相關的客訴，Fine-tuned 的模型遇到帳務問題時表現就會很差。

平衡性。如果你有三個分類（退貨、帳務、物流），每個分類的範例數量不要差太多。1000 筆退貨、50 筆帳務、50 筆物流的資料集會讓模型嚴重偏向把所有問題都分成退貨。

資料量建議

OpenAI 建議至少 50-100 筆高品質範例就可以看到改善，但飛飛的經驗是 300-500 筆是比較穩定的起點。如果是複雜的任務（例如多步驟的推理或長文本生成），可能需要 1,000 筆以上。

資料量不足時，可以用以下方法擴充：

把既有的好範例做變化（paraphrasing）——同一個問題用不同的措辭問，答案保持一致。

從生產環境中收集真實案例——你的客服系統已經累積了大量的真實對話，篩選品質好的案例做為訓練資料。

讓 AI 產生初始的訓練資料，然後由人工逐筆審核和修正——這比從零開始寫快，但審核環節不能省。

Fine-tuning 方法比較

Full Fine-tuning

調整模型的所有參數。效果最好，但需要的 GPU 記憶體和時間也最多。一個 7B 參數的模型做 Full Fine-tuning 至少需要 4 張 A100 80GB GPU。適合：大型團隊、有充足 GPU 資源、需要最佳效果。

LoRA（Low-Rank Adaptation）

只訓練模型參數的一小部分（通常是原始參數的 0.1%-1%），大幅降低記憶體需求。一個 7B 模型用 LoRA 可以在單張 A100 甚至 RTX 4090 上訓練。效果通常能達到 Full Fine-tuning 的 90-95%，是目前最主流的方法。

QLoRA 是 LoRA 的進階版，先把模型量化到 4-bit 再做 LoRA 訓練，進一步降低記憶體需求。一個 13B 模型用 QLoRA 可以在 24GB VRAM 的消費級顯示卡上訓練。

Adapter Tuning

在模型的每一層之間插入小型的「轉接器」模組，只訓練這些轉接器。概念和 LoRA 類似，但實作方式不同。

使用平台的 Fine-tuning API

OpenAI 和 Google 提供雲端 Fine-tuning 服務，你上傳資料就好，不需要管 GPU。這是入門門檻最低的方式，但你無法控制訓練的細節，成本也比自己跑高。

主流 Fine-tuning 平台

OpenAI Fine-tuning API

支援 GPT-4o mini 和 GPT-4o 的 Fine-tuning。上傳 JSONL 格式的訓練資料，設定超參數（epoch 數、learning rate multiplier），等待訓練完成。Fine-tuned 模型透過和一般 API 相同的端點呼叫，計費略高於基礎模型。

優點：最簡單，不需要任何 ML 知識就能上手。缺點：模型是閉源的，你無法下載或遷移到其他平台；訓練過程的控制有限；長期成本可能很高。

Google Vertex AI

支援 Gemini 模型的 Fine-tuning。流程和 OpenAI 類似，但整合在 Google Cloud 生態系中。如果你的系統已經在 GCP 上，整合比較方便。

Hugging Face + 自有 GPU

用 Hugging Face 的 transformers 和 PEFT（Parameter-Efficient Fine-Tuning）函式庫，在自己的 GPU 或租用的雲端 GPU 上訓練開源模型（Llama、Mistral 等）。彈性最高，但需要 ML 工程能力。

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM, TrainingArguments

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3-8B")
lora_config = LoraConfig(r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"])
model = get_peft_model(model, lora_config)

Together AI / Anyscale

提供雲端的開源模型 Fine-tuning 服務，介於 OpenAI（全托管）和自建（全自己來）之間。你可以選擇模型和訓練參數，但不需要管 GPU 基礎設施。

模型評估與品質控制

Fine-tuning 完成後，不能直接上線。需要用模型沒看過的測試資料來評估效果。

評估方法

留出測試集。把資料分成訓練集（80%）和測試集（20%），用測試集評估 Fine-tuned 模型的表現。測試集的資料分布要和訓練集一致。

和基礎模型比較。用同樣的測試問題分別丟給基礎模型（加上好的 Prompt）和 Fine-tuned 模型，比較兩者的表現。如果 Fine-tuned 模型沒有明顯優於基礎模型+Prompt，可能代表你的訓練資料有問題，或者這個任務用 Prompt Engineering 就夠了。

人工抽查。從測試集中隨機抽 50 筆結果做人工審核。量化指標（accuracy、F1 score）有時候不能完全反映品質，人工看一遍才能發現格式不一致、語氣不對、或者在邊界案例上的奇怪行為。

常見的失敗模式

過擬合。模型在訓練資料上表現很好，但遇到沒見過的輸入就表現很差。通常是因為訓練資料太少或訓練太多個 epoch。

忘記原有能力。Fine-tuning 可能讓模型在你的特定任務上變好，但在其他任務上變差。這叫 catastrophic forgetting（災難性遺忘）。LoRA 相對於 Full Fine-tuning 較不容易出現這個問題。

學到錯誤的模式。如果訓練資料中有系統性的錯誤（例如所有投訴都被標記為「低優先度」），模型會忠實地學會這個錯誤。

資料安全與模型保護

訓練資料的安全

Fine-tuning 的資料通常包含你的業務資訊、客戶資料、或專業知識——這些都是敏感資料。

使用雲端平台做 Fine-tuning 時，資料會上傳到平台的伺服器。確認平台的資料處理政策：資料是否用於改善平台的服務？訓練完成後資料是否刪除？有沒有 SOC 2 或 ISO 27001 認證？

敏感資料脫敏。如果訓練資料包含客戶個資（姓名、電話、身分證字號），先做脫敏處理。Fine-tuning 的目的是讓模型學會行為模式（例如客訴分類的邏輯），不是讓它記住特定客戶的資訊。

台灣的個資法同樣適用於 AI 訓練資料。如果你用客戶的個人資料來 Fine-tune 模型，需要符合個資法的蒐集、處理和利用規範，包括取得當事人同意或符合法定例外情形。

模型的安全

Fine-tuned 模型可能被攻擊者利用：

模型萃取（Model Extraction）。攻擊者透過大量的 API 查詢，試圖複製你的 Fine-tuned 模型的行為。對策：設定 API 速率限制，監控異常的查詢模式。

訓練資料外洩。Fine-tuned 模型可能在某些 prompt 下「背誦」訓練資料的內容。如果訓練資料包含敏感資訊，這是嚴重的安全問題。對策：訓練資料脫敏、在輸出端加入過濾。

對抗性攻擊。攻擊者可能構造特定的輸入，讓 Fine-tuned 模型產出錯誤或有害的結果。Fine-tuned 模型可能比基礎模型更容易受到這類攻擊，因為它的行為模式更窄，攻擊面更明確。

安全與限制

Fine-tuning 不是一次性的工作。模型部署後，你需要持續監控它的表現，定期用新的資料重新訓練。業務邏輯改變了、新的產品上線了、客戶的問法改變了，都可能需要更新訓練資料。

Fine-tuning 不能讓模型學會它預訓練階段沒有學過的基礎能力。如果基礎模型的中文能力本來就弱，Fine-tuning 不會讓它的中文變好——它只是在既有能力的基礎上調整行為。選基礎模型時就要確認它在你的語言和領域上有足夠的基礎。

小型團隊的建議路線：先試 Prompt Engineering → 不夠用試 RAG → 還不夠用再做 Fine-tuning。每一步都驗證效果，不要直接跳到 Fine-tuning。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題