RAG vs Fine-Tuning：何時該使用哪一種？
大多數團隊在使用 LLM 時，都會遇到同一個瓶頸。Prompt engineering 一開始很有效，但隨著應用程式持續擴展，只是不斷將更多內容塞進越來越長的提示中，並無法有效擴充。到了這個階段，通常會出現兩條路：透過 Retrieval-Augmented Generation（RAG）將模型連接至資料，或透過 fine-tuning 調整模型本身。雖然兩者經常一起討論，但它們實際上解決的是截然不同的問題。
簡單來說：當模型缺少所需知識時，使用 RAG；當模型缺少所需行為時，使用 fine-tuning。 RAG 會在查詢時從外部知識庫擷取事實，因此答案能維持最新狀態，並附上來源。Fine-tuning 則會使用精選的訓練範例調整模型權重，改變的是模型回應的方式（語氣、格式與風格），而不是模型所知道的內容。
這項一行規則涵蓋了大多數決策，但細節仍然很重要，尤其是成本、幻覺，以及如何讓答案保持最新狀態。接下來我們將介紹這兩種方法，以及各自適用的情境。
什麼是 RAG？
RAG 會將 LLM 連接至外部知識來源，並讓每個答案都以擷取到的內容為依據。整個流程分為三個步驟。當使用者提出問題時，系統會：
- 從已建立索引的知識庫中擷取最相關的段落
- 將這些段落加入提示中
- 根據該內容產生回應
假設我們已將 Progress Software 的 2026 年第二季財報建立索引，接著有人詢問：「2026 財政年度的營收指引是多少？」系統會從報告中擷取指引相關段落，連同問題一起提供給模型。答案會引用實際數字，也能附上確切的來源段落。
RAG 的核心特點是模型本身不會改變。只要更新知識庫中的文件，下一個答案就會反映最新內容。
什麼是 Fine-Tuning？
Fine-tuning 是以預先訓練好的模型為基礎，使用精選的輸入與輸出範例繼續訓練。模型權重會調整，以符合這些範例中的模式。訓練資料通常以 JSONL 格式提供，每一行都是一段對話，清楚示範模型應如何回應：
{"messages": [
{"role": "system", "content": "You are a support assistant for FinTrack."},
{"role": "user", "content": "How do I export my transactions?"},
{"role": "assistant", "content": "Happy to help! Head to Settings > Data,
choose Export, and pick CSV or JSON. Exports cover the last 24 months."}
]}提供幾百個這樣的範例後，模型便會學會其中的模式：問候方式、簡潔的步驟式結構，以及產品專用術語。訓練完成後，模型預設就能產生這種風格的內容，而不需要在每個提示中加入冗長指示。
這正是 fine-tuning 擅長的領域：語氣、輸出格式、特定領域用語，以及遵循企業內部風格。它不擅長的是扮演知識儲存庫。訓練範例中的事實不一定會被可靠地記住，模型在產生內容時也可能將資訊混合或記錯。Fine-tuning 等同於將知識凍結在訓練時點。當 2027 財政年度的指引取代 2026 財政年度的指引時，fine-tuned 模型仍會回答舊數字，直到我們重新訓練模型為止。
有一項實務上的注意事項：OpenAI 正逐步停止向新使用者提供其 fine-tuning 平台。這項技術本身仍可透過其他供應商及開放原始碼模型使用；但如果你採用 OpenAI 技術堆疊，RAG 就更適合作為預設方案。
RAG 與 Fine-Tuning 如何比較？
兩者的差異幾乎會出現在每個實務面向：
| 面向 | RAG | Fine-Tuning |
| 資料新鮮度 | 更新文件後，答案會立即更新 | 內容會凍結在訓練時點；需要重新訓練才能更新 |
| 更新成本 | 成本低，只需重新建立變更內容的索引 | 每次更新都需要重新訓練並進行評估 |
| 引用來源 | 答案可以引用確切的來源段落 | 沒有來源；答案來自模型權重 |
| 幻覺風險 | 較低，因為答案是以擷取到的文字為依據 | 對於訓練集以外的事實，風險不變，甚至可能更高 |
| 工程投入 | 需要索引流程、擷取調整，以及提示組裝 | 需要資料集整理、訓練、評估與版本管理 |
| 所需資料量 | 可直接使用現有文件 | 通常需要 50 至 100 個以上、經過整理的理想輸出範例 |
| 延遲 | 在產生答案前增加資料擷取步驟 | 不增加延遲；只需呼叫一次模型 |
我們的看法是：對公司知識進行問答是大多數團隊實際上正在建置的功能，因此 RAG 應該是預設方案。僅僅是能夠引用來源，就足以讓 RAG 適用於任何使用者需要驗證答案的情境；而對於每季或更頻繁變動的內容，更新方式（重新建立文件索引，而不是排程新的訓練流程）更是關鍵。當輸出本身就是產品時，Fine-tuning 仍然非常有價值，例如必須輸出嚴格 JSON schema 的分類器，或必須呈現明確品牌風格的助理——不過各供應商提供的功能與工具不盡相同。
可以結合 RAG 與 fine-tuning 嗎？
可以，而且兩者結合通常會比單獨使用其中一種更強，因為它們解決的是不同問題。支援團隊可以使用數百個評分最高的回覆來 fine-tune 模型，讓回應符合公司的語氣與格式規範。接著，這個 fine-tuned 模型會放在 RAG 流程後方，從最新的產品文件中擷取資訊。Fine-tuning 提供行為，擷取流程則提供事實。文件變更時，答案也會隨之更新，不需要重新訓練。
Progress Agentic RAG
大家對 RAG 最常見的疑慮不是概念，而是基礎架構。有人必須建置 embedding models、向量資料庫、分段與索引流程，以及擷取邏輯，接著還要持續維護整套系統。Progress Agentic RAG 解決方案透過提供 RAG-as-a-Service，消除了這項疑慮。只要將文件上傳至 Knowledge Box，平台就會自動處理內容擷取、分段、embeddings 與索引。
由於 Agentic RAG 能與任何 LLM 搭配使用，因此上述混合策略能自然地實現。我們今天可以將擷取流程連接至標準模型，之後再改用 fine-tuned 模型，而不需要修改知識庫。知識層與行為層彼此獨立，這正是理想的架構。
除此之外，最適合使用擷取功能的情境，就是答案位於近期有人編輯過的文件中：
- 以即時產品文件為基礎的客戶支援。如果產品在星期二更新了匯出流程，答案也必須同步更新。Fine-tuned 模型會持續重複舊步驟，直到我們重建資料集並重新訓練。
- 投資人與財務問題。當 2027 財政年度的指引取代 2026 財政年度的指引時，每個數字都需要附上來源段落。模型權重無法提供引用來源。
- 政策與法遵查詢。稽核人員詢問三月採用的是哪一個版本的費用政策。擷取流程會回傳原始條款，而 fine-tuned 模型產生的答案則無法讓人追溯。
Fine-tuning 在這三種情境中都能發揮實際作用，協助調整回覆的呈現方式；但底層的查詢工作，仍應交由擷取流程處理。
常見問題
RAG 比 fine-tuning 便宜嗎？
通常是，尤其從長期來看更是如此。RAG 會產生持續性的擷取與索引成本，但更新知識的成本只相當於重新建立文件索引。Fine-tuning 則需要投入資料集整理、訓練與評估成本，而且每次模型需要學習新內容時，都必須重複完整流程。對於快速變動的內容而言，fine-tuning 的成本會迅速累積。
Fine-tuning 能避免模型產生幻覺嗎？
不能。Fine-tuning 調整的是模型的回應方式，而不是答案的真實性。Fine-tuned 模型可能會用完美的品牌語氣，自信地產生錯誤事實。像 RAG 一樣，讓答案以擷取到的文件為依據，是降低幻覺更直接的方法，因為模型使用的是真實文字，而不是自身記憶。
可以將 RAG 與 fine-tuned 模型搭配使用嗎？
可以。RAG 不受特定模型限制，因此產生答案的步驟可以使用任何 LLM，包括你自行 fine-tune 的模型。這種搭配在正式環境中相當常見：fine-tuned 模型負責語氣與格式，擷取流程則確保事實保持最新。Progress Agentic RAG 解決方案直接支援這種做法，讓你可以使用自己的模型。
總結
RAG 與 fine-tuning 回答的是不同問題。RAG 會從即時知識庫擷取資訊，改變模型能夠知道的內容，讓答案保持最新、可引用且有依據。Fine-tuning 則透過精選範例進行訓練，改變模型的行為，適合用來調整語氣、格式與風格。當問題是知識時，優先選擇 RAG；當問題是行為時，選擇 fine-tuning；當兩者都需要時，就將兩者結合使用。
Progress Agentic RAG 處理了擷取面向，不需要你自行建置整套流程。你可以開始免費試用，為自己的文件建立索引；或預約即時示範，由 Progress AI 專家帶你深入了解。
