# Fine-tuning 能取代 RAG 做 KB 檢索嗎 — 它真正學到的東西，以及純 IR 勝出的時機 > 知識庫檢索能不能用 Fine-tuning 取代 RAG：Fine-tuning 真正學到的是什麼、純 IR 或長脈絡勝出的時機，以及各自的成本。 - Source: https://oharu121.com/zh-tw/blog/rag-vs-finetuning-kb-search/ - Published: 2026-08-11T15:07:58+09:00 - Tags: RAG, LLM, 生成式 AI, 機器學習 --- ## 引言 用 RAG 建置知識庫（KB）檢索系統的人不少，我也是其中之一。某天，一個很單純的疑問冒了出來。 > 「如果拿一個小型的本地模型，用我們的內部文件做 Fine-tuning，是不是就能做到跟 RAG 一樣的事，而且模型更小、更便宜？」 讓模型針對它要參考的文件量身打造，檢索基礎設施和向量資料庫就都不需要了。直覺上似乎說得通。但實際上並非如此，原因在於 **Fine-tuning 學到的是行為而不是事實**，因此它無法提供 KB 檢索真正需要的東西。反而站得住腳的是相反的一課：只要需求夠窄，比完整 RAG 更單純的做法往往更好。從這個疑問出發，我依序想清楚了另外三個問題：Fine-tuning 能不能替代 RAG、Fine-tuning 到底在做什麼、以及除了 RAG 是不是真的沒有別的選擇。 希望這些整理，對抱著同樣疑問的人有幫助。 ## 疑問 1：Fine-tuning 能不能取代 RAG 實際查下去之後才發現，這個直覺並不太站得住腳。Fine-tuning 和 RAG 一開始要解決的，本來就是不同的問題。 **Fine-tuning 學的是「行為」，不是「事實」** Fine-tuning 調整模型的權重，改變它的風格、輸出格式、語氣，以及執行任務的模式。它不擅長的，是把特定的事實嵌進去、之後還能穩定地取出來。 用內部文件做 Fine-tuning，模型會學會「講話像內部文件」，但面對具體問題時，它照樣會給出流暢、自信而錯誤的答案。RAG 的做法剛好相反：把事實以原文的樣子，保存在可檢索的儲存中。 *Image: Fine-tuning 把內部文件燒進權重裡，面對報支規定的問題給出自信但錯誤的「每餐 200 美元」，而 RAG 把同一批文件放在可檢索的索引中，回答 150 美元並標示出處為 Expense Policy v3.2* **為什麼 RAG 適合 KB 檢索** 整理下來，RAG 適合 KB 檢索系統的理由可以歸成三點：依據與出處、更新成本低，以及靠檢索脈絡壓下幻覺。在 KB 裡，**能追溯出處這件事的價值特別大**。 *Figure — WhyRagSuitsKb: 同樣的答案出現兩次，但只有一邊說得出它從哪裡來。* **「更便宜、更小」這個直覺的陷阱** 「針對自家文件特化的小模型，應該又便宜又小」這個想法很吸引人，但有幾個漏洞。 - Fine-tuning 並不會讓模型在任何有意義的層面變小。決定模型大小的是你需要的推理與語言能力，而不是你餵了多少領域文字。小模型就算用你的文件量身打造，仍然是一個不擅長綜合與遵守指示的小模型。 - 建置與維護 Fine-tuning 有實際成本：資料準備、運算、評估，以及每次文件更新都要重新訓練。RAG 完全避開了這些。 - RAG 的推論成本（檢索到的片段會讓提示詞變長）確實值得擔心，但通常還是比自己養一條訓練管線便宜。 *Figure — RagVsFinetuning: RAG 把事實留在模型外面，Fine-tuning 則把行為收進模型裡。* **Fine-tuning 真正有用的場合** 這些都不代表 Fine-tuning 沒有意義。和 RAG 搭配起來，它其實很有效。 - 教出一致的輸出格式、語氣與領域術語（行話） - 改善模型*運用*檢索脈絡的方式（RAFT，也就是 Retrieval-Augmented Fine-Tuning，以及類似做法），並提升對查詢的理解 - 把每次都要重複的指示寫進權重裡，讓提示詞變短 所以成熟的做法是「事實交給 RAG，行為交給（必要時輕量的）Fine-tuning」，而不是拿它來取代 RAG。 *Figure — WhatFinetuningAdds: RAG 提供事實，Fine-tuning 改變模型運用與表達它們的方式。* ## 疑問 2：Fine-tuning 到底在做什麼 到這裡為止我都寫著「Fine-tuning 改變的是行為」，但老實說，有一部分我一直沒有真正想通。 > 「Fine-tuning 不就是拿自家資料，把 ChatGPT 或 Claude 這類產品模型稍微調一下嗎？如果行為的改變就只有這樣，那用提示詞不就夠了？」 這個疑問來自**我不知道基礎模型的存在**。 **我們在用的模型，早就被 Fine-tuning 過了** 查下去之後最讓我意外的是，ChatGPT、Claude 這類產品模型並不是 LLM 的「成品」。它們是 LLM 經歷過大規模 Fine-tuning 之後的樣子。在它們背後的**基礎模型**（預訓練完成的模型），和我們每天接觸的東西完全是兩回事。 *Image: 從預訓練的基礎模型出發，經過監督式微調、獎勵模型與 RLHF 的大規模 Fine-tuning，再經對齊與產品整合，最後成為我們每天使用的 ChatGPT、Claude、Gemini 等產品的四階段流程圖* **基礎模型是什麼** 基礎模型是用網路上大量的文字（網頁、書籍、程式碼等），以「預測下一個字」這個任務訓練出來的。這段預訓練讓它獲得語言的基礎能力，包括文法、知識與推理模式。 但基礎模型只是一台文字補完引擎。給它一個問題，它不會回答，而是試著把問句接下去。它不遵守指示、不回答問題，也不拒絕有害的要求。它有語言能力，卻不知道怎麼進行對話。 *Image: 基礎模型被問到法國首都時並不回答，而是生成三種問句的接續文字；旁邊列出它不會做的事：不遵守指示、不回答問題、不拒絕有害要求、也無法進行對話* **是 Fine-tuning 讓模型變得能用** 把基礎模型變成「有用的助理」的，是被稱為後訓練的 Fine-tuning 階段。 1. **指令微調（instruction tuning）**：用大量的（問題, 回答）配對，教會它「被問就要答」「要遵守指示」這類對話模式。 2. **RLHF（以人類回饋進行的強化學習）**：由人類評分者判斷哪些回答好、哪些不好，再依這些判斷調整模型的輸出。有用而安全的回應就是這樣被強化的。 也就是說，**我們對著打提示詞的對象，本身就是龐大 Fine-tuning 的產物**。當初覺得「提示詞就夠了」，其實是站在 Fine-tuning 的成果上面。 **錢花在哪一邊：預訓練 vs Fine-tuning** 建置一個 LLM 大致有兩個階段，兩者的成本差了好幾個數量級。 | 觀點 | 預訓練（建置基礎模型） | Fine-tuning（後訓練） | | --- | --- | --- | | 做什麼 | 用大量文字學習「預測下一個字」 | 學習對話、遵守指示與安全性 | | 運算成本概估 | 數千萬到數億美元 | 數百萬美元（含 RLHF） | | 需要的基礎設施 | 數千到數萬張 GPU、數個月 | 數十到數百張 GPU、數天到數週 | | 需要的資料 | 數兆個 token 的通用文字 | 數萬到數十萬筆高品質的（指示, 回答）配對，加上人類評分 | | 進入門檻 | 非常高（資金、基礎設施、資料、專業人才） | 相對低（可以直接用開放的基礎模型） | 預訓練的成本壓倒性地高，全世界大概只有數十家公司能自己做。相對地，Fine-tuning 可以從開放的基礎模型（例如 Llama、Mistral）出發，因此新公司也構得著。 **新模型變強，是靠哪一邊** 看完這些之後，還有一個問題。像 GPT-3 到 GPT-4、Claude 2 到 Claude 3 這樣，新模型變得明顯更聰明時，貢獻比較大的是預訓練還是 Fine-tuning？ 簡短的答案是：**預訓練決定能力的天花板，Fine-tuning 決定你能靠這個天花板多近**。 - **跨世代的大跳躍**（GPT-3 到 GPT-4、Claude 2 到 Claude 3）幾乎全部來自預訓練的進步。更多運算資源、更好的資料、更大的模型規模、架構上的改良，這些提升的是基礎模型的底子，也就是推理的深度、知識的廣度與程式理解力。基礎模型沒有的能力，Fine-tuning 沒辦法事後裝上去。 - **同世代內的改善**（GPT-4 到 GPT-4o、Claude 3 Opus 到 Claude 3.5 Sonnet）則可能大幅得益於更好的 Fine-tuning 與後訓練。在相同或相近的基礎模型上，更好的 RLHF 資料、更精緻的訓練方法，以及巧妙的蒸餾，都可能讓基準測試分數明顯提升。 所以預訓練設定「能有多聰明」的上限，Fine-tuning 決定「這份聰明能被引出多少」。兩者是互補而不是替代。一句話總結：新模型之所以強，是因為**更好的 Fine-tuning 疊在更好的基礎模型上面**。 **新公司想擁有自家模型的現實路徑** 把成本結構看清楚之後，「我們想要自己的模型」有哪些選項也就浮現了。 1. **從預訓練開始**：數千萬美元起跳。需要前沿實驗室等級的資金與基礎設施。現實上只有數十家公司做得到。 2. **開放基礎模型加上自家 Fine-tuning**：數萬到數百萬美元。可以打造出針對自家領域特化的模型。多數 AI 新創走的就是這條路。 3. **產品模型 API 加上提示詞工程**：每月數百到數千美元。門檻最低，但模型不是你的。 *Image: 三條使用 LLM 的路線並列，標出成本與掌控程度：從零開始預訓練需要一千萬到一億美元並擁有完全掌控權，開放基礎模型加上自家 Fine-tuning 需要一萬到一百萬美元，產品模型 API 加上提示詞工程每月一百到一萬美元但掌控權最低* 所以「在 Fine-tuning 上花數百萬美元」從來就不是為了改變個性。它是**把一個只會補完文字的基礎模型，變成能當助理用的那道工序**，而這道工序本身就創造了產品的核心價值。 **企業為什麼還要再做 Fine-tuning** 也有公司會在產品模型之上再做 Fine-tuning。這不是「改個性」，而是有很強的實務理由。 - **可靠度**：提示詞是「請求」，Fine-tuning 是「訓練」。在數百萬次的正式呼叫中，5% 的失敗率可能是致命的。 - **新能力**：工具使用模式、結構化擷取、領域推理。只靠提示詞做不穩的事情，可以教得會。 - **降低成本**：與其每次都在提示詞裡塞 3,000 個 token 的指示，不如把它們寫進權重裡，用 50 個 token 就解決。規模一大，差距就很可觀。 - **蒸餾（distillation）**：用龐大而昂貴的模型的輸出，去 Fine-tune 一個又小又便宜的模型，用很低的成本拿到大部分的能力。 *Image: 蒸餾的三個步驟：龐大而昂貴的教師模型產生高品質輸出，這些提示詞與輸出的配對被收集為訓練資料，接著微調一個小型的學生模型來模仿它們；最後教師能力為 100%，學生約 90%，執行成本則低 10 到 100 倍* 大致的原則是「**先用提示詞，撞到牆了再 Fine-tuning**」。提示詞達不到的可靠度、複雜到寫不完的行為、長提示詞開始變貴的規模，走到那一步再投資，然後靠推論成本的下降回收。 | 觀點 | 提示詞工程 | Fine-tuning | | --- | --- | --- | | 能給的範例數量 | 幾個 | 數萬筆 | | 一致性與可靠度 | 以「請求」為基礎，會浮動 | 以「訓練」為基礎，比較高 | | 賦予新能力 | 有限 | 可以 | | 提示詞長度與推論成本 | 容易愈長 | 可以寫進權重並縮短 | | 能力在模型之間的移轉 | 做不到 | 可以透過蒸餾 | ## 疑問 3：除了 RAG 真的沒有別的選擇嗎 確認「事實交給 RAG」之後，下一個疑問是：RAG 是唯一的正解嗎？這裡幫上忙的，是把「RAG 到底是什麼」拆開來看。 **把 RAG 拆成兩個階段** RAG 不是一整塊，而是兩個階段黏在一起。 1. **檢索（retrieval）**：找出相關的文字。這正是古典的 ML 與資訊檢索（IR）：BM25、嵌入、重排序器、向量檢索。不需要推理。 2. **生成（generation）**：由 LLM 讀取檢索到的文字，並合成一個答案。 所以「要 ML 還是要 RAG」是個假二分法。ML（機器學習）*就是* RAG 的檢索那一半。真正的設計問題是：「我真正需要哪些階段，而每個階段又需要做到多精緻」。 這樣看，依需求而生的替代方案就清楚了。 *Figure — ArchitectureDecisionFlow: 三個問題就能決定：要不要合成、語料庫多大、需不需要多跳。* **依情境選擇** - **如果只需要「找到」，就把 LLM 拿掉**：如果目標只是找出正確的文件或段落，古典 IR（BM25 加上密集檢索器再加上重排序器）本身就能構成完整的系統。不用生成、沒有幻覺、便宜、快，而且可稽核。很多「KB 檢索」的需求其實就是這種，有些甚至是後來硬加上 LLM 才被過度設計的。 - **如果語料庫很小，跳過檢索直接用長脈絡**：以現在的大型脈絡視窗來說，只要知識大致塞得下，就可以把整份都放進提示詞裡（搭配提示詞快取，成本也不高）。不需要向量資料庫、不需要切塊、也不會漏檢。對於小而穩定的語料庫，這比 RAG 更單純。它會在規模變大時垮掉，垮在成本、延遲，以及「lost in the middle」，也就是長輸入中段材料的召回率下降。 - **如果關係很重要，用 GraphRAG 或知識圖譜**：對於需要跨多份文件串接事實（多跳）的問題，單純的向量 RAG 會很吃力，因為它是各自獨立地取回每個片段。建置並查詢知識圖譜，或使用 GraphRAG，會更合適。建置與維護成本也比較高。 - **如果查詢複雜或需要多步驟，用智能體式檢索**：與其做一次「檢索完就生成」，不如讓模型反覆地搜尋、閱讀、修正查詢、再搜尋。面對難題很強，但每次查詢更慢也更貴。 | 需求 | 建議做法 | 需要生成（LLM） | | --- | --- | --- | | 只要找到文件或段落 | 純 IR（BM25 加密集檢索加重排序器） | 不需要 | | 小而穩定的語料庫 | 長脈絡（加上提示詞快取） | 需要（不需要檢索） | | 多跳、關係 | GraphRAG 或知識圖譜 | 需要 | | 複雜、多步驟的查詢 | 智能體式檢索 | 需要 | | 在大型且持續變動的語料庫上合成答案 | RAG | 需要 | **老實說的總結** 老實說，針對「在大型且持續變動的語料庫上，回傳有依據、即時而且合成過的答案」這個組合，沒有東西能取代 RAG。那本來就是 RAG 的工作。 但當需求更窄的時候，比 RAG 更單純的做法通常會勝出。這就是我學到的一課。錯不在「選了 RAG」，而在於明明便宜的子集就夠用，卻伸手去拿全副武裝的 RAG。所以實務上該問的不是「什麼能打敗 RAG」，而是「使用者真的需要一個合成過的答案嗎、語料庫又有多大多穩定」。這兩個答案就決定了架構。 **和前面幾節怎麼對得上** 前面說 Fine-tuning 不擅長嵌入事實、因為那是 RAG 的工作，這個說法是狹義而正確的。同時，如同疑問 2 所呈現的，Fine-tuning 的「改變行為」涵蓋的範圍非常廣：從把基礎模型變成助理，到可靠度與新能力，再到透過蒸餾降低成本。 ## 再深入一點：如果降低成本才是真正的目的 回到最初的動機，我真正在意的其實是把成本壓下來。在這件事情上，有些做法比 Fine-tuning 更有效。 - 把 RAG 背後的生成模型換成更小、更便宜的 - 提升檢索品質（更好的切塊、重排序、混合檢索），讓送出去的 token 更少 - 快取嵌入 - 自行架設一個小型的開放模型（例如 7 到 8B 這個級距）當作 RAG 的生成器 這樣就能得到「針對使用情境量身打造的小型本地模型」，而不必放棄依據。 有一點要提醒：如果你的「KB 檢索」其實是查找而不是生成，也就是找出正確的段落，那麼最大的收穫幾乎全部都在檢索這一側，選哪個 LLM 幾乎沒有差別。 ## 總結 從「能不能用 Fine-tuning 更便宜地取代 RAG」這個很單純的疑問出發，我最後落在這些結論上： - Fine-tuning 學的是「行為」，不是「事實」。為 KB 檢索提供事實是 RAG 的工作，成熟的做法是**兩者並用**，而不是拿其中一個取代另一個。 - RAG 不是一整塊。它是檢索（古典 ML 與 IR）加上生成（LLM）。如果需求很窄，純 IR、長脈絡、GraphRAG 或智能體式做法，往往在單純度上勝出。 - 實務上該問的不是「什麼能打敗 RAG」，而是「需不需要一個合成過的答案」以及「語料庫有多大、多穩定」。 - 我們在用的產品模型 ChatGPT 與 Claude，本身就是把大規模 Fine-tuning 套用在基礎模型上的結果。預訓練（數千萬到數億美元）與 Fine-tuning（數百萬美元）的成本差了好幾個數量級，而使用開放模型降低了進入門檻。原則是先用提示詞，撞到牆了再 Fine-tuning。 - 如果目的是降低成本，換更小的生成模型、提升檢索品質、快取嵌入，以及自行架設，都比 Fine-tuning 更有效。 做決定的起點其實很簡單：使用者要的是一個答案還是一份文件，以及語料庫有多大、更新得多頻繁。先把這兩件事定下來，架構的選擇就會容易得多。