該微調，還是該做 RAG？拆解強化 AI 的成本、時效與決策順序

當一個 AI 應用在公司內部跑不準，團隊裡最常冒出來的第一個念頭，是「我們乾脆訓練一個自己的模型」。聽起來很合理：模型不懂我們的東西，那就拿我們的資料去教它。

但史丹佛 AI 系統設計課程裡，教授給的建議幾乎相反：微調這件事，能不做就不做。

這不是因為微調沒用，而是因為大多數團隊遇到的問題，根本不是微調能解的。把問題診斷錯，接下來投進去的時間和算力就會打水漂。這篇文章想把「強化一個大型語言模型」這件事的底層邏輯講清楚：你手上有三條路，它們解的是不同的問題，成本和時效也差很多。先弄懂差別，再決定動哪一個。

我們團隊最常被問的一題

我們團隊在替品牌設計資料分析與行銷自動化的 AI 應用時，最常被問到的，就是「要不要訓練一個品牌專屬的模型」。

這個問題背後，其實藏著一個更基本的誤解：把「模型答得不好」直接等於「模型不夠強，需要重練」。實際上，一個 AI 應用答不好，可能是它讀不到正確的資料，可能是它的指令寫得不清楚，也可能真的是它的能力天花板到了。三種病因，三種藥方。先分清楚病因，是省錢的第一步。

強化 AI 的三條路：先分清楚知識不夠，還是行為不對

要讓一個基礎模型在你的場景變得更好用，主流做法有三條，由便宜到昂貴排序：

1. 提示詞工程（Prompt Engineering）：不改模型，只改你給它的指令。最便宜、最快，能轉移到任何新模型。
2. 檢索增強生成（RAG, Retrieval-Augmented Generation）：不改模型，但在它回答前，先去你的資料庫撈出相關片段塞進指令裡。解決「模型不知道你的東西」。
3. 微調（Fine-tuning）：用你的資料再訓練模型，改變它的行為。完整微調（full fine-tuning）會更新整個模型的權重；後面會談到的 LoRA、QLoRA 這類做法則多半凍結基礎模型，只更新一小部分參數。解決「模型該用什麼風格、什麼格式、什麼行為來完成任務」。

這三條路最重要的分界，是一個問題：你要補的是知識，還是行為？

知識的問題長這樣：模型不知道你公司最新的退費政策、不知道你這季新上架的商品、不知道你內部的專有名詞。這是「它讀過的東西裡沒有這些」。

行為的問題長這樣：模型知道該講什麼，但語氣不對、格式不穩、每次輸出長短不一、不照你要的步驟走。這是「它知道內容，但表現方式不符合你的要求」。

這張表看起來簡單，卻是整個決策的軸心。AWS 在它的 RAG 與微調比較指南（AWS Prescriptive Guidance，現行文件）裡給的判斷準則也是同一句話：要做「以自家文件為基礎的問答」，優先從 RAG 出發；微調留給「需要模型學會一種新任務或新表現方式」的場景。

把這個軸心記住，後面的成本與時效討論才有意義。

退費政策 vs 法律摘要：兩個情境看懂該選哪條路

抽象的判斷準則，放進兩個具體情境就清楚了。

情境一，電商客服的退費問答。顧客問「我這筆訂單還能不能退」，模型要根據你公司當下的退費政策回答。退費政策會改，可能這個月剛調過。這是典型的知識問題，而且是會變動的知識。如果你用微調把這季的政策訓練進模型，下季政策一改，你得重訓一次，成本高又慢。這種情況通常優先用 RAG 或工具查詢，而不是把會過期的政策燒進模型權重：政策文件更新了，你只要把新版丟進資料庫，模型下一秒就讀得到。

情境二，把一份冗長的合約自動整理成固定格式的重點摘要。這裡的知識（合約內容）每次都由使用者當場提供，模型缺的不是知識，是「穩定產出某種特定格式、特定深度的摘要」這個行為。如果你已經試過把要求寫進指令，模型還是時好時壞，這就是微調可以著力的地方：用幾十份「合約對應到理想摘要」的範例，把這個任務的手感訓練進去。

兩個情境的差別不在難度，在病因。一個是知識會過期，一個是行為要穩定。診斷對了，工具自然就選對了。

RAG 到底怎麼運作：從語意距離到分塊

既然 RAG 是大多數場景的起手式，值得把它的基礎原理講清楚。它沒有想像中神秘。

第一步，把文件變成向量。系統用一個 embedding 模型，把每一段文字轉成一串數字，這串數字叫向量。向量的用處是：意思相近的文字，在數學空間裡的距離會比較近。舉例來說，「副作用」和「不良反應」字面不同，但 embedding 會把它們放在很接近的位置。這讓 RAG 有機會找出語意相近的片段，比對的是語意距離，不是關鍵字是否完全相同；但要提醒一點，向量相似度對數字、商品型號、版本號、否定語句這類精確查詢常會失準，實務上仍需搭配關鍵字搜尋與結構化條件補強。RAG 這個名稱與代表性架構，由 Lewis 等人在 2020 年的 RAG 論文（發表於 NeurIPS 2020）系統化提出，更廣義的「用檢索補模型知識」概念則早於這篇論文，後來這套框架成為幾乎所有企業知識問答的標準解法。

第二步，存進向量資料庫。你把所有文件的向量都存起來，等使用者提問。

第三步，檢索加生成。使用者問問題時，系統先把問題也轉成向量，去資料庫裡找距離最近的幾個片段，然後把這些片段連同一句指令一起交給模型，指令大致是：根據以下資料回答，資料裡找不到就說不知道。這一步是 RAG 控制幻覺的關鍵。要留意的是，RAG 只能提高模型根據指定資料回答的機率，無法保證模型絕對只照資料走，因此實務上還要搭配引用標註、找不到就拒答的規則、檢索品質評估與答案驗證，才能把幻覺壓到可接受的範圍。AWS 在文件裡用的字眼也是「降低幻覺風險」而非「消除」。

這裡有一個常被略過、卻很關鍵的技術細節：分塊（Chunking，把長文件切成適合檢索的小片段）。文件如果很長，不能整份轉成一個向量，那樣檢索時命中率會很差。基本做法是把文件切成固定大小的片段，各自轉向量。進階做法是多層次存儲：同時保留整篇、每個章節、每個段落的向量，檢索時先定位到對的章節，再往下鑽到對的段落。分塊切得好不好，往往直接決定 RAG 準不準，這也是很多 RAG 系統上線後發現不準的真正原因，問題出在資料怎麼被切，不在模型。

光靠向量相似度通常不夠。實務上 RAG 的準確度還取決於整套檢索策略：商品型號、數字、否定句、專有名詞這些單靠語意距離容易漏的查詢，常要搭配關鍵字搜尋（keyword search）、用標籤過濾範圍的 metadata filtering、把初步結果重新排序的 reranker，以及把命中率量化出來的檢索評估（retrieval eval）。把這些環節補齊，RAG 才會從「能跑」變成「夠準」。

既然 context window 越來越大，為什麼還需要 RAG？

這是現在很常見的質疑。模型的上下文窗口（context window，模型一次能讀進的文字量）已經大到上百萬 token，那還何必檢索，直接把整份資料全塞進去不就好了？

有兩個理由，RAG 短期內不會被取代。

第一個理由是準確度。把資料全塞進去，不代表模型會好好用。史丹佛團隊 2023 年那篇 Lost in the Middle（迷失在中間）的研究發現一個反直覺的現象：當關鍵資訊放在一長串輸入的開頭或結尾，模型找得到；一旦放在中間，模型的表現會明顯下滑，即使是號稱支援長上下文的模型也一樣。具體來說，把一年份的會議記錄整包丟進去，問裡面某個埋在中段的小細節，模型有時就是會漏掉。RAG 先檢索、只把最相關的片段交給模型，等於幫模型把重點挑到它看得清楚的位置。這不代表長上下文沒有價值，而是說長上下文的真實表現要用任務 eval（針對任務設計的評測題組）去驗證，不能只看官方標的 token 上限。

第二個理由是延遲與成本（latency）。每次都把上百萬 token 全部讀一遍，又慢又貴。這就像搜尋引擎不會每次查詢都重爬整個網路，而是靠事先建好的索引快速定位。RAG 扮演的就是那個索引的角色，檢索效率高、而且資料更新時只動資料庫、不用動模型。準確度加上效率，這兩點讓 RAG 即使在長上下文時代依然是基礎建設。

微調的四個地雷：為什麼教授說能不做就不做

回到微調。它有它的用處，問題出在代價常被低估。把四個地雷攤開來看，就懂為什麼建議「能不做就不做」。

第一個地雷，資料成本高。微調要的是高品質、而且標註乾淨的範例。依 OpenAI 的微調指南（2026 年現行文件），監督式微調的技術最低門檻是 10 筆範例，但常見要從 50 至 100 筆高品質示範開始才看得到明顯改善，而且建議先用 50 筆乾淨範例搭配 eval 來判斷值不值得擴充。品質遠比數量重要，幾十筆乾淨範例往往勝過幾百筆雜訊範例。湊出這批乾淨資料，本身就是一個不小的工程。另外要提醒，OpenAI 已把自家 fine-tuning 平台列為逐步下線，實際可用性請以最新官方文件為準，這也說明把行為綁死在單一廠商微調服務上的風險。

第二個地雷，容易過度擬合與災難性遺忘。當你用一批很窄的資料把模型訓練得很專，它在這個任務上變強，卻可能失去原本的通用能力。Databricks 在它的 微調實務指南（Databricks，現行文件）裡把這稱為微調最常見的技術難題：模型可能背下訓練範例、遇到沒看過的輸入就表現失常，甚至忘掉預訓練時學到的廣度。這也是為什麼業界發展出 LoRA、QLoRA 這類只動一小部分參數的參數高效微調（PEFT）方法，目的就是在學新任務的同時，盡量不破壞模型原本的本事。

第三個地雷，時效性差。這點對商業環境最致命。你花兩個月微調好一個模型，下個月新一代基礎模型推出，它的能力可能直接超過你辛苦微調的版本。你的投資還沒回本就被時代超車。

第四個地雷，性價比低、難以轉移。提示詞和 RAG 的設計，幾乎可以無痛搬到新模型上；微調的成果綁死在某一個模型上，換模型就得重來。這在模型每隔幾個月就跳一級的當下，是很大的隱性成本。

那什麼時候才該微調？要先把一個常見誤解講清楚：法律、科學這類容錯極低的領域，需要的多半是可追溯來源、最新法規與案例、引用與人工審核，這些靠 RAG 與驗證機制才撐得起來，微調反而不是首選。微調真正能著力的，是需要穩定分類、固定摘要格式、特定推理流程或專屬語氣這類行為層面的需求；當基礎模型在你的任務上怎麼調指令都吃力、行為就是上不去，這時微調帶來的穩定才值得那個成本。判斷準則很單純：你補的若是會變動或需要引用的知識，用 RAG；你要的若是穩定不變的行為、而且指令真的試到底了，才考慮微調。

一條從便宜到昂貴的決策順序

把上面的東西收斂成一條可執行的順序。核心精神是：永遠從最便宜、最容易回退的方法開始，證明它不夠用了，再往上爬一級。

1. 先試提示詞工程。把對象、格式、重點寫清楚，能解就解，成本幾乎是零。
2. 提示詞救不了、而問題是「模型不知道我的資料」，就上 RAG。先把資料整理乾淨、切好塊、建好索引。
3. RAG 也救不了、而問題是「行為與風格就是不穩」，再評估微調。動手前先用測試案例證明前兩步真的不夠，並優先用 PEFT 這類低破壞性的方法。
4. 兩者可以併用。RAG 負責即時、會變動的知識，微調負責穩定的任務行為，在高價值場景組合起來常是最佳解。

這個順序的價值，在於它逼你先把問題診斷清楚，而不是一開始就跳到最貴的選項。三家來源的建議方向接近但各有重點：AWS 對自家文件問答建議先用 RAG；Databricks 建議從提示詞工程起步、必要時才採 PEFT 這類低破壞性微調；OpenAI 則強調先建立 eval，再判斷微調是否真的比基礎模型加提示詞更好。共通的精神是依成本與複雜度由低到高嘗試，把錢花在真正的病因上。

對品牌來說，這條順序還隱含一個前提常被忽略：不管你最後選 RAG 還是微調，餵進去的資料品質決定一切。RAG 撈到的若是破碎、重複、過期的資料，它只會更快、更有自信地給出錯的答案。我們 91APP CDMP 團隊在替品牌建知識型 AI 應用時，第一件事從來不是挑模型，而是把跨通路的會員與商品資料先歸戶、清乾淨、結構化，讓 RAG 有一個值得檢索的底座。這也是為什麼我們一直強調，第一方資料的整理，是 AI 應用真正的起跑線，這點在我們先前談 AI 行銷為什麼失敗 與 AI 代理購物時代的資料困局 時都反覆驗證過。

給技術決策者的檢查清單

要替一個 AI 應用選強化路線時，動手前先過這幾個問題：

1. 先問病因：模型答不好，是讀不到正確資料（知識），還是表現方式不對（行為）？這一題決定大方向。
2. 知識會不會變？會變、要即時更新的知識，幾乎一律 RAG，別用微調把會過期的東西燒進權重。
3. 提示詞試到底了嗎？很多「以為要微調」的問題，其實是指令沒寫清楚，先把對象、格式、重點補齊。
4. 資料乾淨嗎？上 RAG 前先確認資料有歸戶、去重、結構化，分塊策略也想清楚，這比選哪個模型更影響成敗。我們團隊在 用 RAG 強化客戶成功服務 與 破解 AI 自動化的隱藏陷阱 的實作裡，最常卡住的環節都在資料而不在模型。
5. 真要微調，先算總帳：資料標註成本、過度擬合風險、換模型重來的代價，都算進去，再決定值不值得。

結語

強化一個大型語言模型，說到底是一道診斷題，而非採購題。最貴的選項不一定是最好的選項，最早被想到的「自己訓練一個模型」往往是最該被質疑的那一個。

把問題拆成知識與行為兩類，從最便宜的提示詞開始往上爬，讓 RAG 處理會變動的知識、把微調留給少數真正需要穩定行為的場景，這條順序能幫你把預算花在刀口上。當每個品牌都用得到同樣強的模型，最後拉開差距的 從來不是誰的模型比較大，而是誰的資料比較乾淨、誰把問題診斷得比較準。

常見問題

Q1：RAG 和微調可以同時用嗎？ 可以，而且在高價值場景常是最佳解。RAG 負責提供即時、會變動的知識，微調負責讓模型的任務行為更穩定。兩者解的是不同問題，組合起來能互補。一般建議仍是先把 RAG 做好，確認行為層面還有缺口，再加上微調。

Q2：我的資料量很小，能微調嗎？ 資料少更要小心。監督式微調最少要數十筆高品質範例，且品質遠比數量重要。資料量小又雜時，微調很容易過度擬合，模型會背下範例、遇到新輸入就失常。資料不足的情況下，通常 RAG 或提示詞工程是更安全的選擇。

Q3：既然上下文窗口越來越大，是不是就不需要 RAG 了？ 短期內不會。一是準確度，研究顯示資訊放在長上下文的中段時模型容易漏讀，RAG 先把最相關的片段挑出來反而更準；二是延遲與成本，每次讀上百萬 token 又慢又貴，RAG 像搜尋引擎的索引，檢索效率高、更新只動資料庫。

Q4：RAG 為什麼有時候還是會答錯？ 最常見的原因不在模型，在資料與分塊。如果文件切塊切得不好、資料本身破碎或過期、或檢索沒命中正確片段，模型拿到的就是錯的素材，自然會答錯。改善 RAG 的準確度，多半要從清理資料和優化分塊策略下手。

Q5：什麼情況下才真的值得微調？ 當你需要極高的精確度與一致性，例如法律、科學這類容錯極低的領域，或基礎模型在你的任務上怎麼調指令都吃力時。判斷準則是：補的是會變動的知識就用 RAG，要的是穩定不變的行為、而且提示詞已經試到底，才考慮微調。

Q6：對品牌來說，導入這類 AI 應用的第一步該做什麼？ 不是挑模型，是整理資料。不管最後用 RAG 還是微調，餵進去的資料品質決定成效。先把跨通路的會員與商品資料歸戶、去重、結構化，讓系統有一個值得檢索或學習的乾淨底座，這一步做好了，後面選哪條技術路線才有意義。

把這個決策放回更大的脈絡，可以回頭看 LLM 的四個限制與擴增地圖 理解 RAG 與微調各自補的是什麼，再用 提示詞工程不是寫咒語 確認最便宜的那一步是否已經試到底。

延伸閱讀

1. AI 行銷為什麼失敗？90% 企業忽略的數據品質與 CDMP 關鍵整合
2. Agentic Commerce 的資料困局：為什麼 CDP 升級成 CDMP 是零售品牌的下一步
3. 當每個品牌都用得到 AI，最後拉開差距的是什麼？