如何為企業微調 LLM

這篇教你用 LoRA 或 QLoRA 為企業任務微調 LLM，從定義任務、整理資料到訓練與評估都能照步驟完成。

這篇給需要把大型語言模型調成企業專用能力的開發者與 ML 團隊。照著做完，你會拿到一套可執行的決策框架、資料格式、QLoRA 訓練流程，以及可上線前使用的評估清單。

它適合先做提示詞工程、再決定是否微調的團隊。你會從資料準備一路做到可驗證的模型輸出，不必先猜要用哪種訓練法。

開始之前

• Python 3.11+
• PyTorch 2.2+
• Hugging Face Transformers 4.40+，文件請見 官方文件
• Hugging Face Datasets 2.19+
• PEFT 0.11+
• TRL 0.9+
• CUDA 12.1+，若使用 NVIDIA GPU 訓練
• 一個 Hugging Face 帳號與 access token
• 一個可存取的模型 repo，例如 Llama 或 Mistral
• 至少 500 筆高品質標註樣本，建議 1,000 到 5,000 筆
• 一張 24 GB VRAM GPU 可跑 QLoRA，或一張 A100 80 GB 跑更大規模訓練

Step 1: 定義任務邊界

這一步的產出是「單一任務說明書」，讓模型只學一件事，而且能被明確驗收。先選一個任務，例如客服票單分類、合約條款擷取，或針對單一資料庫的 SQL 生成。

把輸入與輸出格式寫死，並判斷這件事是不是值得微調。若提示詞、少量範例與結構化輸出仍然不穩，才進入訓練；若需求每天變動或依賴即時資訊，就留在檢索系統，不要硬塞進模型。

驗收時，你應該拿到一份一行版任務定義、固定輸出 schema，以及成功標準清單，例如 accuracy、格式符合率或延遲。

Step 2: 整理指令回應資料

這一步的產出是「訓練資料集 v1」，讓模型學會你要的回答方式。把每筆資料整理成 instruction、可選 input、以及預期 output，並讓整份資料的語氣與欄位名稱保持一致。

{
  "instruction": "Classify this support ticket by urgency and category.",
  "input": "Our production database is down and 500 users can't log in.",
  "output": "Urgency: Critical\nCategory: Infrastructure Outage\nReasoning: Production system failure affecting active users requires immediate escalation."
}

品質比數量更重要。少量但精準的樣本，通常比大量雜訊資料更有效；同時要先切出 held-out test split，避免訓練完才發現沒有真實提升。

驗收時，你應該能抽查 20 筆資料，看到相同結構、相同語氣與相同 label 命名。

Step 3: 選擇 LoRA 或 QLoRA

這一步的產出是「訓練方案決策」，要和你的硬體與預算對齊。對多數企業團隊來說，LoRA 是預設選項；若你想在單張 GPU 上微調更大的模型，QLoRA 會更合適。

LoRA 會凍結 base weights，只訓練小型 adapter matrix，成本低且保留大部分原模型能力。QLoRA 再加入 4-bit quantization，可把 GPU 記憶體需求壓低，讓 70B 等級模型更容易嘗試，但會有些許效能折衷。

模型選擇上，先從 Llama 3.1 8B 或 Mistral 7B 開始；只有在任務需要更深推理或更廣語言覆蓋時，才往更大模型升級。

驗收時，你應該明確知道目標模型、adapter 方法，以及訓練前需要多少 GPU 記憶體。

Step 4: 設定並啟動訓練

這一步的產出是「可重現訓練作業」，最後會生成一個 fine-tuned adapter 或 checkpoint。用 PEFT 管 LoRA 設定，並用 TRL 跑 supervised fine-tuning，能讓流程標準化，也方便重跑。

from peft import LoraConfig
from trl import SFTTrainer
from transformers import TrainingArguments

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

training_args = TrainingArguments(
    output_dir="./fine-tuned-model",
    num_train_epochs=3,
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,
    learning_rate=2e-4,
    bf16=True,
    logging_steps=10,
    save_strategy="epoch"
)

trainer = SFTTrainer(
    model=model,
    args=training_args,
    train_dataset=train_dataset,
    peft_config=lora_config,
    dataset_text_field="text",
    max_seq_length=2048
)

trainer.train()

學習率先保守，epoch 數也先少一點。若模型開始過擬合或忘掉一般能力，就降低 learning rate、加入通用指令樣本，或縮短訓練時間。

驗收時，你應該看到 training loss 持續下降、checkpoint 存進輸出目錄，而且訓練過程沒有 GPU memory error。

Step 5: 評估並安全部署

這一步的產出是「可上線評分卡」與「部署工件」，用來判斷模型是否真的能進 production。先拿 held-out examples 測試，再和 base model 比較；如果有需要，也可拿更強的參考模型，例如 GPT-4o，在同一任務上對照。

至少檢查四件事：任務準確率、輸出格式符合率、對對抗樣本的 hallucination rate，以及對未微調任務的 regression。若模型只是在訓練樣式上表現好，就還不能上線。

結果穩定後，把 adapter 或 merged model 打包，加上 inference monitoring，並決定最終系統是否要把 fine-tuning 與 RAG 結合，以處理即時知識。

驗收時，你應該拿到 pass/fail scorecard、部署工件，以及 rollback plan。

常見錯誤

• 資料太雜。修法是先清理標籤、統一輸出格式，再縮小資料集後重新訓練。
• 太早做 full fine-tuning。修法是先用 LoRA 或 QLoRA，只有在確定需要極限表現且硬體充足時才升級。
• 跳過評估。修法是保留 held-out test set，並檢查格式符合率，不要只看 loss。

接下來可以看什麼

當第一個模型可用後，下一步是比較 fine-tuning 與 RAG 在你的場景中的分工，再補上監控、版本管理與資料更新規則，讓模型能隨業務變化持續可用。