Fine-tuning（微調）

更新時間：2026-08-12

導讀

Fine-tuning（微調） 在你提供的高品質示範上繼續訓練基礎模型，使輸出在固定格式、語氣、分類邊界或領域術語上更穩定。OpenAI 託管流程：上傳 JSONL → 建立 fine-tuning job → 獲得 ft:... 模型 ID。可微調基礎模型列表、資料格式、訓練與推理單價以 Fine-tuning 文件 與 定價頁 為準——產品線持續調整，範例 model 名需對照文件替換。

先問：你真的需要微調嗎？

需要最新外部知識？ ──是──→ 優先 RAG（Embeddings + Responses）
       │
       否
       ↓
Prompt + JSON Schema 已穩定？ ──是──→ 不必微調
       │
       否
       ↓
有大量標註、分布穩定、prompt 已榨乾？ ──是──→ 考慮 Fine-tuning

路徑	更適合
Prompt + 結構化輸出	格式可控、樣例可放進 context
RAG	知識頻繁更新、需引用來源
工具 / Responses API	查 DB、調 HTTP、執行程式碼
Fine-tuning	海量穩定樣本、風格 / 分類 / JSON 合規率不達標
Agents SDK	多步編排、handoff，非權重訓練

微調不會讓模型自動掌握新事實；事實錯誤仍靠 RAG 或工具。

訓練資料：JSONL 規範

監督微調通常用 JSONL，每行一條。Chat 類模型多為 messages 陣列：

{"messages": [
  {"role": "system", "content": "你是工單分類器，只輸出一行 JSON，無 markdown。"},
  {"role": "user", "content": "快遞三天沒到，要投訴"},
  {"role": "assistant", "content": "{\"intent\":\"logistics\",\"priority\":\"high\"}"}
]}

資料品質清單

• 複雜任務常需 500+ 高品質樣本；先用 50 條 smoke train 驗證格式
• assistant 即標準答案，格式一致、無多餘寒暄
• 覆蓋拒答、歧義、邊界 case
• 90/10 訓練 / 驗證拆分，避免同一使用者句式洩漏
• 去除 PII，遵守版權與 API 資料政策
• 不含未文件化欄位或錯誤 role 順序（常見失敗原因）

訓練 Job 工作流

步驟	操作	注意
1. 上傳	POST /v1/files（purpose: fine-tune）	大小與行數限制見文件
2. 建立	POST /v1/fine_tuning/jobs	base_model 必須在可微調列表
3. 監控	輪詢 status	failed 時下載 error file
4. 呼叫	model="ft:..."	與基礎模型呼叫方式相同

from openai import OpenAI

client = OpenAI()
job = client.fine_tuning.jobs.create(
    training_file="file-abc123",
    model="gpt-4o-mini-2024-07-18",  # 以文件可微調列表為準
    validation_file="file-def456",
)
print(job.id, job.status)

超參（epochs、learning_rate_multiplier 等）以文件推薦為起點，在小驗證集上網格搜尋。

評估：超越 training loss

維度	做法
對照基線	held-out 集對比「最佳 prompt + 基礎模型」
格式合法率	JSON parse、schema 校驗通過率
業務指標	F1、準確率、人工滿意度
安全回歸	harmful 請求拒答能力不能變差
線上 A/B	5% canary，對比延遲、成本、錯誤率

loss 下降 ≠ 業務變好；以 held-out 業務指標 為準。

上線、版本與成本

• 版本快照：保留 ft:... ID、訓練集 hash、超參與評估報告
• 並存策略：新 ft canary 放量，指標下滑即切回基礎模型
• 成本：訓練費（token × epochs）+ 推理費（通常高於同檔基礎模型）；用 定價頁 估算 ROI
• 重訓觸發：業務規則變更、新意圖占比超閾值、評估連續下滑
• 安全：微調不能替代 moderation；敏感輸出仍要審核

與其他能力組合

使用者輸入 → RAG 檢索 context → ft 模型輸出 JSON → 伺服器端 schema 校驗 → 落庫
多步流程 → Agents SDK 編排 → 僅在「分類 / 格式化」節點呼叫 ft 模型

常見問題

只有 100 條資料夠嗎？

簡單二分類可能夠，但易過擬合。必須留驗證集；若不如 prompt 基線，應停止擴大訓練。

微調模型怎麼呼叫？

Chat / Responses 的 model 填 ft:... 完整 ID；SDK 用法與基礎模型一致。

能否微調 embedding 模型？

以官方當前產品為準；多數 RAG 場景優先調 chunking、混合檢索與 rerank。

Job 失敗如何排查？

下載 error file；常見為 JSONL 格式錯誤、單條超長、非法 role、空 assistant。

訓練資料會被 OpenAI 用於訓練嗎？

查閱最新 API data usage 與企業協議；Enterprise 政策可能不同。

官方資源

• Fine-tuning 指南
• Fine-tuning API Reference
• OpenAI Platform
• API 定價

下一步閱讀

• Embeddings（嵌入）
• Prompt Engineering 指南
• Responses API 繁體指南
• 文字生成（Text Generation）

行動路徑

今天：收集 5 條「prompt 優化仍失敗」的樣例，區分知識缺口 vs 格式 / 風格問題。明天：若屬後者，手寫 20 行 JSONL 提交 smoke job。本週：在 held-out 50 條上對比基礎模型 vs ft 的格式合法率，再決定是否擴大資料與上線。