RAG vs Fine-Tuning：何時該用哪個？（附實測數據）
多數 rag vs fine tuning 的建議都跳過了唯一一個在同一任務上實測兩者的實驗。Balaguer 等人在 arXiv:2401.08406（被引用 162 次）中，用一組農業 QA 資料集同時跑了兩種方法：fine-tuning 帶來超過 6 個準確度百分點，RAG 在此之上再疊加 5 個百分點。他們的 Table 18 顯示 GPT-4 原始得分 75%，fine-tuned 後 81%，加上檢索後達 86%。那為什麼我們仍然建議多數團隊從 RAG 開始？因為新鮮度、引用來源和下面的成本計算，比 1 個百分點的準確度差距更能決定專案走向。
重點摘要
- 知識頻繁變動或回答必須附帶來源時，RAG 是預設選擇；fine-tuning 在格式一致性和延遲上勝出。
- Fine-tuning 的成本集中在前期（訓練）；RAG 的成本按查詢計算（embedding 加額外輸入 token）。
- 同任務實測證據：fine-tuning 加了 6 個百分點，RAG 再疊 5 個百分點，混合方案優於任何單一方法。
- 寫任何訓練程式碼之前，先跑五項檢查（資料新鮮度、標註樣本、延遲、引用、團隊技能）。
該用 RAG 還是 Fine-Tuning？（快速結論）
知識頻繁變動或回答需要附帶引用來源時，選 RAG。需要一致的輸出格式、低延遲，且手上有數百筆標註樣本時，選 fine-tuning。部署成熟後兩者都用。RAG 修改的是模型讀取的上下文；fine-tuning 修改的是模型本身。多數團隊需要的是前者，不是後者。
一句話記住：RAG 改變模型讀到什麼，fine-tuning 改變模型是什麼。根據你的任務真正需要哪個來決定。
| 方法 | 適用情境 | 不適用情境 | 前期成本 | 每次查詢成本 | 更新難度 |
|---|---|---|---|---|---|
| Prompt engineering | 行為接近目標，知識屬通用型 | 回答需要私有或即時資料 | 數小時迭代 | 僅 token 費用 | 修改 prompt，重新部署 |
| RAG | 事實會變、需要引用、資料須保持私有 | 需要低於 100ms 延遲 | 低：建立索引 | Embedding 加額外輸入 token | 重建索引，不需重新訓練 |
| Fine-tuning | 固定格式、語氣或延遲預算；有標註樣本 | 知識每週都在變 | 中高：資料準備加訓練 | 通常較高的 token 費率 | 每次漂移都要完整重訓 |
| 混合（兩者） | 成熟產品：格式控制加即時事實 | 原型階段，預算尚未確定 | 以上兩者 | 以上兩者 | 兩套系統要維護 |
NVIDIA 的 RAG 詞彙表對檢索端有清楚的教科書定義。但定義不會幫你選架構，證據才會，所以從證據開始。
證據說了什麼？同一任務、兩種方法、實測比較
在 Google 搜尋這個關鍵字排名前五的結果中，唯一有同任務實測比較的是 Balaguer et al. 2024，一項被引用 162 次的 Microsoft Research 研究。團隊用同一個農業 QA 任務跑了 RAG 管線、fine-tuned 模型和兩者混合，再讓 GPT-4 評分。結果 fine-tuning 單獨使用略勝 RAG 單獨使用，而兩者疊加的效果比任何單一方法都好出一截。
農業案例研究（arXiv:2401.08406）
這篇研究於 2024 年 1 月提交，由 Angels Balaguer 和 15 位共同作者完成，探討如何為農民提供地區專屬的洞察。他們的管線從 PDF 擷取資訊、產生問答對，並評估 Llama2-13B、GPT-3.5 和 GPT-4 在有無檢索下的表現。
Balaguer 等人報告 fine-tuning 帶來超過 6 個百分點的準確度提升，與 RAG 可累加，RAG 再貢獻 5 個百分點。混合管線優於任何單一方法。他們的 Table 18 顯示 GPT-4 的排序：無輔助 75%、RAG 80%、fine-tuned 81%、fine-tuned 加 RAG 86%。注意 80% 和 81% 多麼接近；RAG 單獨和 fine-tuning 單獨只差 1 個百分點，而混合方案領先兩者 5 個百分點。在一個實驗中，fine-tuned 模型利用其他地區的知識回答地區性問題，將答案相似度從 47% 提升到 72%。
經濟面證據
Snorkel AI 發表的研究（2022 年 11 月）涵蓋成本面。在一項 100 分類法律基準測試（LEDGAR，80,000 筆合約條款）上，fine-tuned RoBERTa 模型表現與 fine-tuned GPT-3 相當，但體積小 1,400 倍、使用不到 1% 的標註資料，推理成本僅為 fine-tuned GPT-3 的 0.1%，約千分之一。總建置成本：程式化標註 $1,915 vs 人工標註加 GPT-3 fine-tuning $7,418。一個注意事項：那是分類任務，不是生成式 QA，所以比例僅供方向性參考。
我們的解讀
我們的解讀：他們的設定是 fine-tuning 能得到的最友善情境，結果也只贏了 1 個百分點。Balaguer 等人在固定的 PDF 語料庫上訓練，並在同一個凍結語料庫上評估，所以權重學到的東西不會在實驗中途過期。多數生產環境的知識庫不會這樣靜止不動。一個回答上週發佈問題的客服機器人，每個重訓週期都要重新賺回那 6 個百分點，而餵給 RAG 的索引當天下午就能更新。這就是為什麼我們把 1 個百分點的準確度優勢視為這個決策中最弱的輸入，而把新鮮度視為最強的。證據無法推廣的地方：Snorkel 的結果是分類基準，兩項研究都沒有測試語氣或格式控制，而那仍然是 fine-tuning 最強的論據。
| RAG | Fine-tuning | 混合 | |
|---|---|---|---|
| 任務準確度（Balaguer et al.，歸因） | +5 百分點，累加於 fine-tuning 之上（非單獨對比基準線） | 比基準線 +6 百分點 | 三者最佳：GPT-4 達 86%，vs fine-tuned 81%、RAG 80%、基準 75% |
| 成本結構（Snorkel 加公開定價） | 按查詢：embedding 加上下文 token | 前期：發表案例中 $1,915-$7,418；小模型推理成本為 fine-tuned GPT-3 的 0.1% | 兩者都付 |
| 更新難度 | 重建文件索引 | 完整重訓 | 兩者 |
| 引用支持 | 原生支援 | 無 | 透過檢索端原生支援 |
Fine-tuning 是正確答案的頻率比團隊想像的低，多數說「fine-tune」的專案其實意思是「檢索」。
RAG 如何運作？何時它會贏？
RAG（retrieval-augmented generation）從你掌控的文件中回答問題，而非依賴模型訓練時記住的一切。由 Lewis et al. 於 2020 年首次提出後，它成為知識工作的預設方案，因為知識存在模型之外：更新索引，隔天每個答案就跟著變，不需重訓。
管線分四步：
- 擷取。 將文件（PDF、wiki、工單）解析為語料庫。
- 切塊與 embedding。 切成數百 token 的塊，用 embedding 模型將每塊轉為向量。
- 檢索。 查詢時找出 top-K 最相似的塊，加上關鍵字比對以命中 SKU 和錯誤碼等精確字串。
- 增強與生成。 將那些塊塞進 prompt，讓 LLM 附帶來源回答。
RAG 在三個軸線上勝出：新鮮度（重建索引而非重訓）、引用（每個答案指向來源塊）、資料控制（客戶資料永遠不進入訓練流程）。如果你想要完整的建置教學，這裡有逐步建置 RAG 應用的方法。
一個關於檢索品質的警告：管線的好壞取決於 embedding 和檢索策略的組合。Anthropic 的 Contextual Retrieval 實測在普通設定下 top-20 檢索失敗率為 5.7%，加上 contextual embedding 和 BM25 後降至 2.9%，再加 reranker 後降至 1.9%。如果精確比對查詢持續失敗，混合搜尋（BM25 vs 向量）是解法。
Fine-Tuning 何時會贏？（PEFT 是什麼？）
當問題在於模型「怎麼回答」而非「知道什麼」時，fine-tuning 勝出：一致的輸出格式、品牌語氣、或沒有檢索往返的硬性延遲預算。它也是小模型經濟學的槓桿。上述 Snorkel 的「GPT-3 品質、0.1% 成本」結果之所以存在，是因為有人 fine-tune 了一個小模型，而非部署一個大模型。
完整 fine-tuning vs PEFT（LoRA / QLoRA）
完整 fine-tuning 更新模型的每一個權重。昂貴、緩慢，大型實驗室以外很少見。幾乎所有人都改用 PEFT（parameter-efficient fine-tuning）。LoRA（Hu et al. 2021）凍結基礎權重，只訓練一個小型低秩轉接器，通常佔參數量的 0.1-1%。QLoRA 在此之上加入 4-bit 量化，讓 13B 模型能裝進一張消費級 GPU。一個相關術語值得了解：continuous pretraining，模型先在原始領域語料上繼續預訓練（無監督），再對標註樣本做監督式 fine-tuning。
一個最小的 LoRA 設定，出自 Hugging Face PEFT 文件：
from peft import LoraConfig, get_peft_model
config = LoraConfig(
r=16, # low-rank dimension; 8-64 typical
lora_alpha=32, # scaling factor, commonly 2x r
target_modules=["q_proj", "v_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM",
)
model = get_peft_model(base_model, config)
model.print_trainable_parameters()
# trainable params: ~13M || all params: 6.7B || trainable%: 0.19資料集準備、epoch 數和評估方法，參見我們的逐步 fine-tuning 指南。
風險是真實的：小資料集上的過擬合（幾百筆樣本可能記住而非學會）、過期（權重將知識凍結在訓練截止點）、以及無來源歸因（fine-tuned 模型無法出示證據）。如果這三項中任何一項是交易破壞者，你剛剛把自己說回了 RAG。
RAG vs Fine-Tuning vs Prompt Engineering：其他方法怎麼定位？
三者是階梯，不是對手。Prompt engineering 修改指令，RAG 修改模型讀取的上下文，fine-tuning 修改權重。OpenAI 自己的 fine-tuning 指南將 fine-tuning 放在最後：先做評估、再調 prompt、只有 prompt 不夠用時才訓練。兩個較新的選項補齊了工具箱。
| 方法 | 修改什麼 | 適用情境 | 不適用情境 | 成本結構 | 投入時間 |
|---|---|---|---|---|---|
| Prompt engineering | 指令 | 行為已達 90% | 需要私有或快速變動的事實 | 僅 token | 數小時 |
| RAG | 查詢時讀取的上下文 | 即時或可引用的知識 | 嚴格延遲；沒有可檢索的內容 | 每次查詢 token 加索引 | 數天 |
| Fine-tuning（LoRA） | 權重 | 格式、語氣、延遲、小模型部署 | 無標註資料；知識持續漂移 | 前期訓練；每次重訓續費 | 數週 |
| CAG（cache-augmented） | 預載快取的上下文 | 小型穩定知識庫；有 prompt 快取可用 | 語料超過可快取大小 | 寫入快取一次，之後讀取便宜 | 數天 |
| Agent 加工具使用 | 模型能做什麼 | 回答需要即時操作或計算 | 靜態答案就夠用 | 每步 token；快速累加 | 數週 |
一個值得指出的混淆：MCP server 和 agent 框架是編排，不是客製化。它們決定模型能存取哪些工具和來源，但不改變模型如何回答。你可以在 agent 內跑 RAG 管線，同時 fine-tune 底層模型，許多生產系統兩者都做。「vs mcp」「vs agents」的比較是類別錯誤。
RAG 比 Fine-Tuning 便宜嗎？真實成本模型
簡答：在現實查詢量下，是的。Fine-tuning 的帳單在前期（標註資料加訓練），RAG 的帳單按查詢到（embedding 加額外輸入 token）。OpenAI 的 fine-tuning 文件按 token 收取訓練費，但 token 費跟標註樣本的人工成本比是零頭。以下是公開定價的計算。
| 項目 | 何時付費 | 公開定價 |
|---|---|---|
| 託管 API 訓練（gpt-4o-mini） | 每個模型版本一次 | $3.00 / 1M 訓練 token（OpenAI 2024-25 定價）→ 1.5M token ≈ $4.50 |
| 標註訓練資料 | 前期，漂移時續費 | 程式化 $1,915 vs 人工 $7,418（Snorkel 發表案例） |
| Fine-tuned 模型推理 | 每次查詢 | 約 2 倍基準：$0.30/$1.20 vs $0.15/$0.60 / 1M（gpt-4o-mini，OpenAI 2024-25） |
| 語料 embedding（RAG） | 每次語料更新一次 | $0.02 / 1M token（text-embedding-3-small）→ 10M token 語料 = $0.20 |
| 檢索上下文（RAG） | 每次查詢 | 約 2,000 額外輸入 token × $0.15/1M = 每次查詢 $0.0003 |
損益兩平問題：多少次查詢後，RAG 的累計按查詢稅負等於 fine-tuning 的投資？
break_even = training_cost / per_query_retrieval_delta
= $1,915 / $0.0003
≈ 6.4 million queries每月 50,000 次查詢的話，那是十年以上。對多數產品而言，fine-tuning 的投資永遠無法僅靠 token 節省回本；你做 fine-tuning 是為了格式和延遲，不是為了在成本上贏過 RAG。當月查詢量超過數百萬或檢索上下文非常大時，數學才會翻轉。注意不對稱性：fine-tuning 的帳單在每次資料漂移迫使重訓時續費，而 RAG 隨查詢量乘以塊大小線性擴展。如果每次查詢的花費才是真正的擔憂，先從降低每次查詢的 LLM 成本開始；如果你確實要走訓練路線，先比較 fine-tuning 工具再簽支票。
一個新鮮度備註：截至 2026 年 7 月，OpenAI 的 fine-tuning 文件指出託管平台正在對新用戶逐步關閉，現有用戶在未來數月保留訓練權限。這是團隊傾向開放模型 PEFT 或純 RAG 的又一個原因。
做決定前的 5 項檢查
寫任何訓練程式碼之前，先跑這五個是或否的檢查；答案的模式比任何基準測試都更可靠地指向 RAG、fine-tuning 或混合。誠實作答，然後計數。
- 知識變動速度是否超過你能重訓的速度？是 → RAG。每次文件更新都重訓不是維運方案。
- 你有幾百筆標註樣本嗎？沒有 → RAG 或 prompt engineering。用 40 筆樣本做 fine-tuning 是記住，不是學習。
- 有硬性延遲預算嗎？很緊 → 傾向 fine-tuning。跳過檢索往返可省 50-200ms。
- 回答必須附帶引用或稽核軌跡嗎？是 → RAG。Fine-tuned 模型無法指向來源塊。
- 團隊有 ML 技能加 GPU 或 API 預算來訓練嗎？沒有 → RAG。一個你能重建的索引勝過你無法重訓的權重。
1、4、5 多為「是」→ RAG。2 和 3 多為「是」且領域穩定 → fine-tuning。答案分歧，或產品成熟且有真實流量 → 混合（下一節）。這份清單的重點是用證據決策，而不是用你本月動態牆上正在流行的技術。
RAG 和 Fine-Tuning 可以一起用嗎？
可以，而且對成熟部署而言，混合模式是常態，不是例外。Fine-tune 用於領域流暢度和輸出格式（怎麼說），檢索用於推理時的即時事實（說什麼）。Balaguer 等人在農業任務上精確報告了這一點：混合管線優於任何單一方法，RAG 的 5 個百分點增益疊加在 fine-tuning 的 6 個百分點之上。
我們建議的成熟度路徑：從 prompt engineering 開始，回答需要私有或即時資料時加入 RAG，只有當格式不一致或延遲開始在生產環境造成痛點時才加 fine-tuning。直接跳到 fine-tuning，你會在不知道檢索是否已經解決問題之前就先付了訓練稅。
混合模式不是妥協；對成熟部署而言它就是預設，fine-tune 管格式，檢索管事實。
如何評估你的贏家？
像選資料庫一樣選贏家：在你的工作負載上量測，不是憑感覺。方法一段話就能說完，涵蓋真正決定結果的四個數字。
- 保留問題集。 100-300 筆真實使用者問題。不用合成的，絕不用訓練或索引時見過的。
- 忠實度與答案正確性。 忠實度問的是答案是否基於檢索到的上下文；答案正確性問的是答案是否真的對。這對組合由 RAGAS 推廣，能同時捕捉幻覺和檢索遺漏。
- p95 延遲，不是平均值。檢索增加一次往返；量測尾部。
- 每 1,000 次查詢的成本，token 加基礎設施，實測而非猜測。
- 漂移時重跑。 新文件、新模型快照、新季度：重跑問題集。
完整的指標拆解（含工具）在我們的 LLM 評估指南。
關於作者
Mert Batur 是 Techsy.io 的聯合創辦人，團隊為 B2B 客戶打造 AI agent、自動化系統和語音/SDR 管線。他撰寫 Techsy 團隊在生產環境實際使用的 LLM 工具堆疊文章。歡迎在 LinkedIn 聯繫。
常見問題
RAG 和 fine-tuning 可以一起用嗎？
可以。Fine-tune 用於輸出格式和領域流暢度，保留檢索用於推理時的即時事實。Balaguer 等人在農業 QA 任務上實測了這種混合方案，發現它優於任何單一方法，準確度增益可累加。多數成熟的生產系統最終都在這裡：權重管怎麼說，檢索管說什麼。
什麼時候不該用 fine-tuning？
當知識變動速度超過重訓速度、標註樣本不到幾百筆、回答必須附帶引用或稽核軌跡、或沒有預算在資料漂移時重訓，就跳過 fine-tuning。這四種條件描述了多數早期產品，這就是為什麼 RAG 通常是正確的第一步。
Fine-tuning 被推翻了吗？
沒有，但它的領地縮小了。長上下文窗口和便宜的 RAG 吸收了 2023 年需要 fine-tuning 的用例。剩下的是真實需求：嚴格輸出格式、品牌語氣、無檢索往返的延遲預算、小模型經濟學。如果你的問題是模型怎麼回答而非知道什麼，fine-tuning 仍然是工具。
何時該用 RAG vs fine-tuning？
回答依賴私有或頻繁更新的知識，或需要引用時，用 RAG。需要一致的格式、語氣或延遲，且有足夠標註樣本時，用 fine-tuning。產品成熟後兩者都用。如果不確定，從 RAG 開始：它比一次訓練更容易撤回。
RAG 比 fine-tuning 便宜嗎？
前期是的。RAG 的成本按查詢計算（embedding 加額外輸入 token），fine-tuning 訓練和標註資料收一次費，之後每次重訓續費。以公開定價計算，在我們的試算範例中損益兩平約在 640 萬次查詢，所以在典型查詢量下，RAG 在產品生命週期內都更便宜。
RAG 在幻覺問題上比 fine-tuning 好嗎？
通常是，但不是免費的。RAG 將答案錨定在檢索到的塊上，所以你可以引用來源並稽核失敗。但糟糕的檢索會污染答案：Anthropic 實測在普通設定下 top-20 檢索失敗率為 5.7%，加上 contextual retrieval 和 reranking 後降至 1.9%。Fine-tuning 則可能將錯誤燒進權重，無從追蹤。
RAG vs fine-tuning vs prompt engineering：差別在哪？
Prompt engineering 修改你發送的指令。RAG 修改模型在查詢時讀取的上下文。Fine-tuning 修改模型的權重。每一種都是比前一種更大的干預：先試 prompt，知識是瓶頸時加檢索，只有格式、語氣或延遲仍然痛時才訓練。
如何評估 RAG vs fine-tuning 的效能？
建立一組 100-300 筆真實使用者問題的保留集，在上面評分兩種方法：忠實度（是否基於上下文？）、答案正確性（是否正確？）、p95 延遲、每 1,000 次查詢的成本。文件或模型快照變更時重跑。合成問題會讓兩種系統都好看；真實問題才能區分它們。
對新知識的多跳問題，fine-tuning vs RAG？
RAG，搭配更好的檢索。機制決定了這一點：fine-tuned 模型只能對權重吸收過的內容進行推理，所以它從未見過的知識無論訓練得多好都不可觸及。檢索在查詢時把缺失的片段交給它。問題是單次檢索很少能收集到每一跳，所以要規劃查詢分解或迭代式檢索加 reranker，而非單次 top-K 查詢。
結論
回顧，不含模糊用語：
- RAG 是變動知識和引用回答的預設選擇。Fine-tuning 是格式、語氣和延遲的專家。
- 同任務證據（Balaguer et al.）顯示 fine-tuning +6 百分點、RAG 再疊 +5 百分點，混合最佳。我們建議從 RAG 開始，依據是新鮮度、引用和成本，不是那個計分板。
- 成本計算在現實查詢量下有利於 RAG：我們的試算範例中損益兩平約在 640 萬次查詢。
- 用五項檢查做決定，不要用習慣。
選了 RAG？參見我們的 RAG 工具排名清單，了解管線周圍的工具堆疊。