LoRA vs fine-tuning vs RAG:哪個解哪個問題

預設 LLM 不做你要的事時,你有三個真實選項:RAG(在 runtime 給它相關 context)、加例子的 prompt engineering(prompt 裡更好指令)、或 fine-tuning(改模型權重)。LoRA 是 fine-tuning 的特定種類,比完整 fine-tuning 便宜很多。大部分團隊在 RAG 才是對的答案時伸手 fine-tuning。大部分團隊在 LoRA 已經夠時伸手完整 fine-tuning。

三個方法概覽

RAG(Retrieval-Augmented Generation) — runtime 撈相關文件、放 prompt 裡、模型根據它們回答。模型本身不變。好給:知識問題、動態資訊、引用來源。

Fine-tuning(完整或 LoRA) — 調模型權重讓它行為不同。模型行為永久改變。好給:風格、格式、特定任務 pattern。

Prompt engineering — prompt 裡更好指令跟例子。沒權重改變、沒檢索。好給:大部分東西,意外地。

各解什麼問題

「模型不知我公司產品」 → RAG。runtime 撈產品文件;模型用它們回答。

「模型用正式語言;我要輕鬆」 → 先 prompt engineering。「用輕鬆友善語氣回應」大部分時候 work。Prompt-only 到不了再 fine-tune。

「模型不跟我精確 JSON schema」 → 先帶例子的 prompt engineering。大部分現代模型 schema 指令做得好。需要 99% 可靠性而 prompt-only 給你 95% 才 fine-tune。

「模型不知專業醫療術語」 → RAG 配醫療來源。除非很大規模運作,fine-tuning 殺雞用牛刀。

「模型對我們用途太慢」 → 較小模型 + fine-tune 讓它在你具體任務上配對較大模型品質。這是真實 fine-tuning 用途。

「模型講我們不要它講的話」 → 先 prompt engineering 跟輸出過濾。產品高量的話 fine-tune 內化品牌 voice 跟政策。

LoRA 是什麼

LoRA(Low-Rank Adaptation)是 fine-tuning 技術,只更新少量參數,透過插入可訓練「adapter」矩陣到模型。產生小檔案(~10-100MB),套用時修改基底模型的行為。

比完整 fine-tuning 的優勢:

• 訓練便宜 10-100 倍
• 訓練快很多(幾小時 vs 幾天)
• 較小 artifact(MB vs GB)
• 多個 LoRA 能在同基底模型上換進換出
• 較不可能災難性忘記原能力

劣勢:

• 略不如完整 fine-tuning 強大
• 需要基底模型可用(不能只 ship LoRA)
• 有時抓不到深行為改變

2026 年 90% fine-tuning 需求,LoRA 是對選擇。

RAG 贏 fine-tuning 的時候

• 資訊在你已有或能蒐集的文件裡
• 資訊會變(時事、價格、政策隨時間更新)
• 你需要引用 / 可驗證性
• 你需要不重訓加新資訊
• 你沒幾千訓練例子

RAG 也建得快(幾天、不是幾週)又較容易更新。

Fine-tuning 贏 RAG 的時候

• 你需要一致輸出格式(永遠嚴格 JSON、永遠帶這些 tag)
• 你需要 prompt 裡難描述的特定風格或 voice
• 你需要從多例子內化隱性知識
• 延遲重要而加 RAG context 太慢
• 成本重要而系統 prompt + 撈到 chunk 每 query 太貴

經典 fine-tuning 用途:品牌的語氣配對。「像 Apple 行銷文案那樣寫」 — RAG 能供例子,但 fine-tuning 把風格烤進去。

你實際需要兩者的時候

很多 production 系統兩者都用。例子:為你品牌 voice fine-tune 的客服 agent + 對你 help docs 的 RAG。Fine-tuning 確保一致 voice;RAG 確保新鮮準確資訊。

經典錯誤

團隊聽到「fine-tune」立刻想做。Fine-tuning 聽起來技術又厲害。現實:

• 80% 嘗試 fine-tuning 的團隊本可用更好 prompt 跟 RAG 解決問題
• 15% 真的需要 fine-tuning 但該用 LoRA
• 5% 需要完整 fine-tuning

Fine-tune 前問:我真的耗盡 prompt engineering 了嗎?我試過 RAG 嗎?我有幾百個高品質訓練例子嗎(沒的話,你不能好好 fine-tune)?

成本實況

• RAG:建便宜(幾天)。推論成本是 API + 檢索(通常每 1k query $5 以下)。
• LoRA fine-tuning:一次性訓練 run $100-1000。自架的話推論便宜很多。
• 完整 fine-tuning:有意義模型上每訓練 run $5,000-50,000+。加服務基礎建設。
• Prompt engineering:免費。

大部分產品,prompt engineering 然後 RAG 涵蓋需求。Fine-tuning 留給替代品明顯不夠的證實場景。

什麼時候不要用 fine-tuning

• 你沒評估資料顯示 prompt + RAG 不夠
• 你有 500 個高品質例子以下(不夠好好 fine-tune)
• 你要模型知的資訊定期變
• 你沒工程能力維護 fine-tune 模型
• 你 provider 6 個月內會發比你 fine-tune 還好的新基底模型

什麼時候不要用 RAG

• 資訊小到適合放 context(總共 < 10 萬 token)
• 資訊不變、能放系統 prompt
• 檢索會加太多延遲
• 你實際需要模型改行為,不只是有新資訊

決策樹

• 新資訊 / 動態資料:RAG
• 新風格 / 行為 / 格式:先 prompt engineering、需要的話 fine-tune
• 風格 + 特定格式 + 規模:LoRA fine-tuning
• 需要常更新知識庫:RAG
• 高量產品的品牌 voice:LoRA fine-tuning + RAG 給事實
• 合規 / 特定術語:RAG 配策展來源

下一步

• 識別你實際問題:缺資訊、錯風格、不一致格式?
• 先試 prompt engineering;量到哪
• 資訊問題,建基本 RAG;量改進
• 行為問題,只在 prompt + RAG 不夠時 fine-tune
• Fine-tune 的話,從 LoRA 開始;只把完整 fine-tuning 當升級考慮