2026 年 RAG 與微調怎麼選：決策指南與架構比較

2026 年，RAG 與微調的真實戰況

如果你在 LLM 應用圈待得夠久，過去兩年一定聽過這種說法：「RAG 只是把文件貼到 prompt 上，真正的模型客製化得靠微調。」過了一年，反方又跳出來喊：「微調已死，長上下文加檢索才是王道。」兩邊都沒講到重點。

2026 年真正有趣的故事，不是誰壓倒誰，而是兩者之間的界線正在消失。OpenAI 已經逐步關閉其託管式微調平台，多數生產團隊轉向開源權重模型加上自管的 LoRA / QLoRA。Anthropic 工程團隊正式發表「context engineering（脈絡工程）」宣言，把檢索放進更宏觀的「策展模型輸入」這個學問裡。Chroma 對 context rot（脈絡衰退）的研究也持續指出：就算視窗拉到 100 萬 tokens，模型對內容的精確回憶率依然會隨長度下滑。檯面下，幾乎所有認真在做產品的團隊，兩件事都做——用微調處理語氣、格式與工具呼叫，再用檢索處理事實查詢。

這篇是我希望 2025 年初有人能遞給我的決策框架。有立場、貼近實際部署狀況、也不會假裝有單一正解。

2026 年打破舊框架的三個關鍵變化

三件事的影響力比任何新模型發表都來得大：

1. 長上下文不再是稀有品。Gemini 1.5 Pro、Claude Sonnet 4.5、GPT-5、Llama 4 Maverick 都已支援 100 萬以上 tokens。單價雖然降了，但注意力問題沒解——根據 Chroma 的研究，每多塞一個 token，模型對內容的精確回憶能力就下降一點。視窗變大不代表回憶變準，只代表稻草堆變大，針更容易藏起來。
2. OpenAI 棄守微調平台。官方最佳化指南明寫：「本平台不再開放給新用戶」。這是頂級實驗室的訊號：他們押注的預設生產組合已轉向「prompt + 檢索 + 評測」。微調沒消失，只是搬家到開源權重模型與 HuggingFace TRL、axolotl、Unsloth 等工具上。
3. 「Prompt 工程」升級成「脈絡工程」。Anthropic 的說法最清楚：與其雕琢一句聰明指令，不如策展整個輸入狀態——系統提示、工具、檢索片段、訊息歷史——把這些視為有限且會消耗注意力預算的資源。檢索是脈絡工程中負責拉進新事實的那一塊，微調則負責塑造行為模式。

微調在 2026 年到底在做什麼

微調會動到模型權重。實務上，幾乎沒人在前沿模型上做全參數微調了。現在主流是三種變體：

• 監督式微調（SFT）：給模型數千組（輸入、理想輸出）配對，讓它學會某種風格、欄位格式或輸出結構。
• 直接偏好最佳化（DPO）：給模型（好回應、壞回應）配對，讓它自己學偏好。多數團隊覺得這比 RLHF 更穩也更便宜。
• 強化式微調（RFT）：由評分員對模型的推理過程打分，再把高分輸出強化回去。這是 OpenAI 現在處理法律、醫療這類高推理領域的推薦做法。

微調值得做的兩個必要條件：

• 你有一種行為、格式或推理模式，能用 1k 到 100k 筆範例表達。
• 你無法靠 prompt 加幾個範例就穩定得到那種行為。

微調做不好的事：

• 塞進每週更新的新事實。模型會真的忘記你教它的東西，舊事實也會腐壞。
• 把模型「變聰明」。拿小模型微調不可能在困難推理上贏過 GPT-5。
• 當知識庫又大又動態的時候，取代檢索。

一個具體例子：中型 SaaS 客服 Copilot

把抽象拉回地面，這是一個在 2026 年幾乎變成中型 SaaS 客服團隊標配的部署樣態。基礎模型是微調過的 8B 或 14B 開源權重變體（Llama 4 Scout、Qwen 3 或 Mistral Small）。微調覆蓋三件事：公司回應格式（招呼、致歉、解決步驟、升級頁尾）、拉取工單歷史與知識庫的工具呼叫 schema，以及品牌語氣——以 15k 到 30k 筆精選客服對話紀錄為基礎調校。

檢索那一側，系統索引了說明中心、公開文件、內部 runbook，以及過去 90 天已結案的工單。混合檢索（BM25 + 稠密）加 cross-encoder 重排在 top-10 大約打到 88% 召回率。代理式 RAG 把整個包起來：模型自己決定這個問題到底要不要檢索、要查什麼、要不要再追一個精煉查詢，以及何時升級給真人。評測流水線每晚對 500 個切出來的工單跑一輪，計 groundedness、格式符合度，以及 CSAT 代理指標。

結果是每張結案工單的推論成本大約 0.012 美元，groundedness 比前一代純微調版本高出 23 分，碰到檢索毫無相關內容時會禮貌拒絕並升級，不再硬答。2026 年這些都不算稀奇，只是認真出貨的團隊走到這條成熟曲線之後長出來的樣子。

RAG 在 2026 年到底在做什麼

檢索增強生成是在推論時從模型外部拉進相關脈絡，塞進 prompt。陽春版（切塊、嵌入、餘弦相似度、抓 top-k 丟進 prompt）只是地板，不是天花板。2026 年的天花板長這樣：

• 混合檢索：把 BM25 關鍵字搜尋跟稠密向量結合，再用 cross-encoder（像 bge-reranker-v2、Cohere Rerank 3.5）做第二輪重排。
• 代理式 RAG：模型自己決定何時檢索、查什麼、要不要重搜。LangGraph、LlamaIndex workflow、Anthropic 的 tool-use API 全部支援這種模式。
• 晚期互動模型：像 ColBERT v2 不把整段池化成一顆向量，而是為每個 token 都編碼。在技術文件上的召回率明顯提升。
• 元資料感知過濾：把檢索範圍限制在特定租戶、時間區間或存取權限內。多租戶企業環境的標配。

RAG 的強項是它能回答模型訓練時根本不存在的内容，而且能附上引用出處。這兩件事在合規、客服、內部搜尋等場景都非常重要。它的失敗模式也很特定：切塊切斷句子、語意相似度撈到主題相近但事實錯誤的段落、模型在檢索內容上「跨塊幻覺」而不是憑空捏造。

沒人談的混合現實

多數「RAG vs 微調」的辯論被框架成二選一。生產環境的真實答案幾乎都是兩者並用，有順序：

1. 先做 prompt 加檢索。把 RAG 管線架起來，用評測衡量 groundedness（依據性）與回答品質。多數團隊在完全不微調的狀況下就能做到七到八成。
2. 只在檢索撐不住的時候加微調。如果模型一直產出錯的 JSON schema、漏掉領域專屬的格式慣例、或不願意呼叫某個工具，這時候才微調。如果它一直幻覺出知識庫裡其實有的事實，那是檢索管線的問題，不是微調能救的。
3. 把微調當行為塑造器，把檢索當知識注入器。它們回答的是不同問題。

一個好用的心智模型：微調教模型「怎麼」回答，RAG 告訴它「答案是什麼」。當團隊把兩者混為一談，就會開始用 Q&A 配對去微調——而這些題目只要檢索做對就會答對；同時真正需要的格式、結構、行為問題，檢索根本幫不上忙。

決策指南：你的情境該用哪一招（或兩招）

照順序走：

• 知識每週甚至每天都在變？檢索是強制選項，微調追不上。
• 答案需要附上具體來源？用檢索搭引用。微調會把來源吃掉。
• 模型需要嚴格遵守某個欄位結構、語氣或格式？用範例微調。few-shot prompt 在超過幾百筆範例後會崩。
• 你在高 QPS 場景下要省錢？把小模型微調成窄任務專家再路由過去。一個 7B 模型加上 500 筆微調範例，在固定任務上能逼近大很多的有 prompt 支援的模型，推理成本只剩十分之一。
• 受限於地端或 air-gapped 環境？通常只能走「開源小模型 + 領域微調」這條路。
• 在打造會呼叫工具的代理人？針對工具呼叫可靠度做微調。檢索本身就是一種工具，模型得學會何時該呼叫它。

比較表

面向	微調	RAG
主要目的	調整行為、格式、語氣、工具呼叫	注入新事實或私有知識
知識新舊	訓練時凍結，更新昂貴	即時；直接從資料源拉
引用出處	原生不支援	引用自然來自段落本身
算力成本	前期 GPU 訓練貴；推論便宜	索引便宜；單次查詢較貴
資料需求	1k 到 100k 筆高品質範例	整理過的知識庫與切塊策略
失敗模式	行為悄悄漂移、格式崩壞	跨段落幻覺、漏抓脈絡
適合場景	穩定任務、嚴格結構、工具呼叫	動態知識、合規、客服
不適合	頻繁變動的事實	大規模行為或風格客製化

微調底層到底長什麼樣

走開源權重路線的團隊，現代配方是在量化後的基底上跑 LoRA 或 QLoRA。你把基底權重凍結，注入小的低秩 adapter 矩陣到注意力層，只訓練這些 adapter。一個 70B 模型做全參數微調要 140 GB GPU 記憶體，QLoRA 在 4-bit 量化下可以舒服地塞進一張 48 GB 顯卡，adapter 本身只占幾百 MB。

HuggingFace transformers Trainer（2026 年中的現行主要版本）給的預設值已經很合理：Ampere+ 硬體自動用 bf16 混合精度、DataCollatorForLanguageModeling 做動態 padding、gradient checkpointing 省記憶體，以及 eval-then-save 策略自動載入最佳 checkpoint。訓練迴圈本身通常不是難點，難點幾乎都發生在上游——資料集策展、schema 定義、以及你要拿來衡量品質的評測集。

多數團隊實戰有效的流程：

1. 在寫任何訓練程式碼之前先把評測管線架好。沒辦法量就沒辦法改。
2. 訓練資料從真實生產軌跡整理出來，不要用更大的模型合成。多數論文沒說的是：人為策展跟合成之間的落差比想像中大得多。
3. 先跑一輪小規模 LoRA 實驗（幾百步）驗證 loss 曲線有動、格式確實學進去，再放大成完整訓練。
4. 訓練結束後，把基底模型跟微調模型在同一份輸入上跑完整評測，比較 groundedness、格式符合度，以及任何領域專屬評分。
5. 把微調模型掛在 feature flag 後面上線，先比對線上指標再決定是否正式啟用。

成本現實（取自 2026 年實際部署數字）

價格變動快，但整體形狀夠穩定可以拿來規劃。一個 7B 開源權重模型用 LoRA 微調約 20k 筆範例，在一張 A100 / H100 上跑下來，雲端 GPU 成本大約 50 到 300 美元。70B 模型的全參數 SFT 落在 2k 到 8k 美元。強化式微調因為評分員算力與重複取樣，再貴一個量級。

RAG 成本主要壓在索引那一邊（一次性的嵌入生成與儲存）加上推論時的 token 費用。一個中型企業 RAG 系統索引 1000 萬份文件，初期大約花 5k 到 20k 美元，之後每次查詢 0.005 到 0.05 美元，其中大部分其實是 LLM 的 token 費，不是檢索系統本身。

實戰上穩定有效的模式：先一次性把錢花在檢索基礎設施，再針對窄任務反覆微調。永遠不要反過來。

常見錯誤

• 用 Q&A 配對微調來「教」事實。這是最常見的錯誤。微調會把事實烤進權重，接著就過時。事實走 RAG，行為走微調。
• 兩邊都還沒評測就先選邊站。沒有可量化的基準線，你根本不知道微調或檢索到底有沒有幫助。先把評測架起來，再決定動哪個開關。
• RAG 沒做重排。純靠餘弦相似度在技術文件上會漏太多東西。加一個 cross-encoder 重排，或直接換成晚期互動檢索。
• 切塊切一次就忘記管。切塊策略是 RAG 品質的最大單一槓桿。依文件結構切、句子視窗檢索、父文件檢索，全部都比固定大小切片好。
• 無視脈絡衰退。把 20 萬 tokens 的檢索內容塞進 prompt，只會讓模型變差，不會變好。積極策展。
• 把不同租戶或權限混在同一個向量索引。排名之前一定要先用元資料過濾，否則會跨用戶洩漏資料。

不該選微調的時機

• 所謂「知識」其實只是幾百頁說明文件。Prompt 加檢索就能輕鬆處理。
• 你還在迭代 schema 或產品形狀。微調會讓你太早被鎖死。
• 你沒有評測集來衡量微調有沒有用。不要蒙眼飛行。
• 團隊沒有 GPU 基礎建設或相關經驗。在開源權重模型上自管微調不是假日 side project。

不該選 RAG 的時機

• 任務純粹是行為類型——分類情緒、抽結構欄位、摘要風格。不需要外部知識。
• 知識庫太小或太亂，不值得為它架檢索管線。微調或更好的 prompt 會比半吊子 RAG 強。
• 延遲預算很緊（100ms 以下）。檢索加重排再加生成，總延遲可能會超過你能負擔的範圍。
• 你沒辦法維持知識庫品質。在過期資料上做檢索比不做更糟。

下手前的實戰清單

• 先把任務拆清楚：哪部分是行為，哪部分是知識。兩者解法不同。
• 在動任何系統之前，先用 200 筆以上真實生產 prompt 建好評測集。
• 跑一版陽春 RAG 基線，啟用混合搜尋加重排，量 groundedness。
• 如果檢索已經到天花板（評測在 85% 以上），先別急著微調——把錢投在更好的切塊、重排或查詢改寫上。
• 如果檢索已經見頂，行為或格式還是會出包，就在小型乾淨的範例集上微調。
• 每次調整後重跑完整評測。某個面向的小進步常常換來另一個面向的大退步。

「乾脆用長上下文就好」是現在最該躲的陷阱

有個 2026 年特別值得點名的陷阱：長上下文前沿模型一出，很多人就想跳過檢索，直接把所有東西倒進 100 萬 token 視窗。我訪談過的好幾個團隊 2026 年初真的這樣幹，在 demo 階段感覺超棒，丟上生產之後數字卻令人失望。這個模式一直重複：上下文變長、雜訊變多、精確回憶變差。

Chroma 的脈絡衰退研究把這個梯度畫得很清楚。回憶精確率會隨著上下文裝滿而以非線性方式下滑，而且下滑最嚴重的，正好就是當初讓你想用長上下文的那種事實查詢題型。Anthropic 把脈絡視為有限注意力預算的框架才是對的心智模型：每多塞一塊檢索內容，都是對模型細心閱讀能力的一筆稅。

實戰原則：就算有 100 萬 token 視窗，困難事實查詢任務的檢索內容最好壓在 3 萬 token 以內，重推理型任務壓在 1 萬 token 以內。剩下的預算留給對話歷史、系統指令、工具定義——不要繼續塞文件。

我對未來 12 個月的押注

長上下文會繼續長大，但脈絡衰退會繼續咬人。檢索基礎建設會更「代理化」——手工調的管線變少，由模型驅動的查詢精煉變多。微調會圍繞 LoRA / QLoRA 收斂到開源權重模型上，託管式微調會從常態變成例外。「RAG vs 微調」這個框架會從資深工程師的對話裡悄悄消失，換成一個更乾淨的問題：這個模型需要知道什麼、它應該怎麼表現？知識走檢索，行為走微調。把這個分工內化的團隊，會比還在吵選哪個的團隊更快交貨。

常見問題

2026 年微調死了嗎？
沒有，但角色變窄了。頂級實驗室的託管式微調正在退場；開源權重加 LoRA / QLoRA 的微調反而比以往更活躍。微調現在是行為與格式的槓桿，不是注入知識的工具。

RAG 能完全取代微調嗎？
行為、欄位一致性、工具呼叫可靠性這幾項不行。檢索沒辦法教模型怎麼遵守你的格式，它只能給模型填進內容的素材。

怎麼判斷我的 RAG 管線夠不夠好？
在切出來的評測集上量 groundedness、回答相關性、引用準確率。三項都過 85%，檢索就算到位了；接下來的紅利多半來自切塊或重排，不是微調。

該微調小開源模型，還是直接呼叫前沿 API 加檢索？
任務窄、高量、對延遲敏感，就選小模型微調，省錢又快。任務開放、多領域、低頻重複，前沿 API 加檢索幾乎一定更簡單也更好。

團隊最常犯的單一錯誤是什麼？
還沒建評測就動手微調。沒有評測根本不知道微調是幫了忙、害了事、還是根本沒差。先有評測，再選槓桿。

最後一句

RAG vs 微調這個問題本身沒那麼有趣。真正的問題是：你的系統裡哪些是行為，哪些是知識。回答得出來，架構就自己會長出來。