🎯 什麼情境該想到我
當提示工程與 RAG 都試過還不夠，開始考慮「要不要微調一個模型」時。
⚙️ 怎麼用（先分清問題屬於哪一類）
- 缺「知識/事實」 → 用 RAG（換文件即可更新，別微調）。
- 缺「行為/風格/格式」（要固定語氣、特定輸出樣式、遵循領域慣例）→ 微調較合適。
- 順序：提示工程 → RAG → 微調。越後面越貴、越慢、越難維護。
- 微調前提：要有足量、高品質的標註資料 + 可靠的 工具-AI系統評估 來證明它真的更好。
★ 書中的一句話原則
《AI 工程》第 7 章：
「簡單說，微調是為了形式，RAG 是為了事實。」
- RAG 給模型外部知識，讓答案更準確、更有資訊量，可以緩解幻覺。
- 微調幫助模型理解並遵循語法與風格。書特別提醒：有足夠的高品質資料時，微調可能減少幻覺；但資料品質差時，反而會讓幻覺變嚴重。
★ 兩種問題都有時：先做 RAG
書的建議：模型同時有資訊問題和行為問題時，先從 RAG 開始。理由：
- RAG 比較容易——不需要整理訓練資料，也不需要託管微調後的模型。
- 做 RAG 時先從簡單的關鍵字檢索（如 BM25）開始，不要一開始就上向量資料庫。
- RAG 的效果提升可能比微調更大：書引用 Ovadia 等人（2024）的研究，在 MMLU 的幾乎所有題目類別中，RAG 對 Mistral 7B、Llama 2-7B、Orca 2-7B 三個模型的表現都優於微調。
★ 兩者可以疊加，但不保證有效
同一份研究中，在微調過的模型上再加 RAG，只有 43% 的情況比單用 RAG 更好；另外 57% 的情況沒有改善。所以「兩個都上」不是預設答案，要用評估集驗證。
★ 什麼問題適合微調：書中的例子
| 問題 | 為什麼微調有用 |
|---|---|
| 輸出格式錯誤，例如產生的 HTML 無法編譯 | 模型在訓練資料中看到的 HTML 不夠，微調可以讓它接觸更多 |
| 語意解析：把自然語言轉成結構化格式 | 強大的現成模型處理 JSON、YAML、regex 這類常見語法沒問題，但對網路上範例很少的語法（小眾工具的 DSL、複雜語法）表現較差 |
| 輸出技術上正確，但缺少團隊需要的細節與風格 | 用符合要求的範例微調，讓輸出更貼近需求 |
★ 決策流程
問題是「模型不知道某些事」？
├─ 是 → RAG（先從 BM25 開始）
└─ 否，是「模型不照我要的方式回答」？
├─ 先試提示工程（加範例、指定格式、結構化輸出）
├─ 還是不行，而且有 ≥ 數百筆高品質範例 → 微調（先試 LoRA 這類參數高效方法）
└─ 沒有足夠資料 → 回頭改善提示，或先蒐集資料
微調的具體技術選擇 → LoRA 與 QLoRA、PEFT 方法比較；微調的副作用 → 災難性遺忘。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 微調不會「教模型新事實」得可靠（仍會幻覺）；事實類需求優先 RAG。微調也會綁死模型版本、增加維運負擔。
🔗 相關工具
- 工具-提示工程 —— 三段順序的第一段，成本最低；多數「模型不聽話」的問題到這裡就解決了，不必走到微調
- 工具-RAG檢索增強生成 —— 判定屬於「缺知識/事實」時的正解：換文件就能更新，別為了灌事實去微調
- 工具-AI系統評估 —— 微調的硬前提，沒有可靠評估集就無法證明微調後真的比較好，只是換個貴的方式瞎調
- 工具-LLM微調實作路線 —— 判定「該微調」之後的下一步：Full／LoRA／QLoRA 怎麼選、要多少顯存
- 工具-不重訓就改掉模型的一條錯誤知識 —— 第三條路：只錯一兩個事實時，模型編輯比微調更精準、比 RAG 更不依賴外部檢索