提示詞工程、RAG、微調的差異在哪？看問題該選哪一個

多數人以為，想讓 AI 更懂自己的產業或產品資料，直覺反應就是「那就去微調一個專屬模型」。這個想法聽起來合理，卻剛好把順序弄反了——提示詞工程、微調、RAG 這三個方法裡，多數情況下微調根本輪不到出場，甚至該是最後才考慮的一步，不是第一步。

這三個詞，常被混著講成「同一件事的三種做法」，好像只是換一個難度等級。但實際上它們改的其實是三個不同的部分：一個改你怎麼下指令、一個改 AI 當下看得到什麼資料、一個改 AI 本身的反應方式。多數人卡關的地方，不是分不清這三個詞各自是什麼，而是不知道自己遇到的問題該對應哪一個。

先弄清楚提示詞工程、微調、RAG 的差異，再照著問題的性質去挑方法，才不會把時間和資源花在錯的地方。這篇就從三者各自改動 AI 的哪一塊開始拆，一路拆到怎麼挑、怎麼疊加使用。

提示詞工程、RAG、微調，各自在改 AI 的哪一塊？

把提示詞工程、微調、RAG 當成同一件事的三種難度版本，是最容易走偏的起點。它們其實對應到 AI 系統裡三個不同的部位：提示詞工程改的是「你怎麼問」，RAG 改的是「AI 當下能查到什麼資料」，微調改的是「AI 本身的行為與反應模式」。

這三個旋鈕各管各的，不是三選一的競爭關係。IBM 官方在比較三者時，把它們各自定義成解決不同層面的問題：提示詞工程透過優化輸入的指令，引導模型給出使用者要的結果；RAG 讓 AI 連上一個資料庫，自動檢索相關內容再回答，拉高答案的準確度；微調則是用特定領域的資料重新訓練模型，提升它在某個下游任務上的表現。三者不互相排斥，實務上常常一起搭配使用，這一點會在文章最後一節再展開。

先看提示詞工程改的是什麼、能做到哪裡、天花板又卡在哪個位置。

提示詞工程：換個問法，答案就更準

換一句問法，同一個模型給出的答案品質常常差一大截，這背後靠的正是提示詞工程，做法是不去動模型本身，單靠指令的寫法讓它給出更好的答案。常見的技巧包括把任務描述講清楚、附上一兩個範例輸出（業界稱為少樣本學習，few-shot）、指定輸出的格式，或者要求模型一步步推理再給出結論（業界稱為思維鏈，Chain-of-Thought）。

假設你請 AI 寫一則產品文案，只丟出「幫我寫一則產品文案」這幾個字，AI 多半只能寫出四平八穩、看不出品牌調性的內容；但如果把任務描述講清楚、附上一個範例輸出，並指定字數與語氣，同一個模型就能寫出貼近需求的版本。差別不在模型變聰明了，而在指令把「你要什麼」講得夠具體。

Google 官方發布、Kaggle 平台收錄的〈Prompt Engineering〉白皮書（作者 Lee Boonstra，2024 年發布）系統整理了這類技巧，從零樣本、少樣本提示，到思維鏈、角色提示等進階做法都涵蓋在內。OpenAI 官方的模型優化指南也把給清楚指令、給範例輸出、補充上下文資料，列為撰寫有效提示詞的具體做法。

提示詞工程是三者裡門檻最低、最快能驗證有沒有用的一種，改一次、測一次，幾分鐘就有結果。但它的天花板也很明顯，模型本身沒學過的知識，不管指令下得再漂亮都補不出來。這個限制，正好是下一個方法要補的位置。

RAG：讓 AI 先查資料，再回答

如果提示詞工程解決的是「問法夠不夠好」，RAG（Retrieval-Augmented Generation，檢索增強生成）解決的則是「AI 知不知道這件事」。做法是讓 AI 在回答前，先從外部資料庫或文件庫裡查出相關內容，再把查到的資料一起交給模型，由模型根據這些資料生成答案。

模型本身沒訓練過的資料、公司內部才有的資料、需要隨時更新的資料，都可以用 RAG 補進去，而且不必重新訓練模型本身。它靠的是向量資料庫做語意檢索，依照文字背後的意思去比對，而不是單純比對關鍵字有沒有出現，這也是 RAG 能找到「意思相近但用詞不同」內容的原因。

RAG 這個概念最早由 Lewis 等人在 2020 年發表的研究〈Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks〉提出，發表於 NeurIPS（國際重要的人工智慧學術會議之一）。這篇研究的核心主張，是把模型訓練時學到的「參數化記憶」，和外部可即時檢索的「非參數化記憶」結合在一起，讓生成結果更具體、更符合事實，也能減少 AI 一本正經胡說八道的情況（業界稱為幻覺）。

微調：讓 AI 的本能反應整個改變

提示詞工程改的是問法，RAG 補的是知識，微調（Fine-tuning）動的則是模型本身。做法是拿一批特定領域或特定任務的範例資料，對一個已經訓練好的基礎模型再進行一輪訓練，直接調整模型內部的參數。

微調改的是行為，而不是單純補知識。經過微調的模型，不需要每次都被下一長串指令，也能穩定用某種語氣、某種格式輸出。代價是需要準備品質夠高的訓練資料，需要運算資源，而且如果之後資料又變了，得重新再訓練一次。

OpenAI 官方的模型優化指南在說明微調時指出，微調可以讓模型穩定用特定格式回應，也能訓練出更小、更便宜、反應更快的模型，在特定任務上打平原本用量更大的模型；還能用機密或專屬的資料訓練模型，不必每次都把這些資料寫進提示詞裡。這份指南也列出監督式微調等好幾種不同的微調做法，微調本身不是單一做法，而是一個家族。

三個方法的成本、時間、資料更新彈性，一次看懂

提示詞工程、RAG、微調，如果只看名稱，很難判斷哪一個才是你現在該優先處理的問題。把三者攤開來比，才看得出彼此的定位差在哪裡。

這個成本排序，背後不是誰刻意訂了一張價目表，而是各自需要的基礎建設不一樣。提示詞工程只花時間試文字，幾乎不需要額外投資；RAG 要建置檢索系統、維運資料庫，才有中等程度的成本；微調要準備訓練資料、投入運算資源，模型訓練完之後還要持續維護，成本自然是三者中最高的。

把 RAG 和微調放在一起比，微調通常比較貴，因為它牽涉到實際訓練模型，不只是多加一層檢索。提示詞工程則幾乎不必額外花錢，自己寫、自己測，除了人力時間之外沒有其他支出；即使找人專門研究優化，規模也遠比建置 RAG 或訓練模型小得多。

這是不是代表小公司、小團隊完全不用碰後面兩種方法？其實不必想得這麼絕對，差別只在於順序，先把提示詞工程用到位，真的碰到知識不夠或行為不穩定的問題，才考慮往下一層走。

資料常常更新、還要讓 AI 講得出處：RAG 最合適

產品規格常常更新、客服問答庫天天都有新問題、法規條文三不五時修改、內部政策文件版本一直換，這種場景最適合優先想到 RAG。另一種常見情境是資料量太大，大到根本沒辦法一次全部塞進提示詞裡，這時候也得靠 RAG 先篩選出真正相關的段落，再交給模型處理。

理由很直接，資料一旦更新，只要重新索引到資料庫裡，AI 馬上就能反映最新版本，不必重新訓練模型。而且因為答案是從指定的文件裡檢索出來的，系統可以回頭指出這句話是從哪一份文件來的，在客服對答、法規查詢這類需要交代根據的場景，這一點特別重要。

不過 RAG 的效果好壞，高度取決於資料庫本身整理得好不好，這個前提常被忽略。如果丟進去檢索的文件雜亂無章、版本混雜、內容互相矛盾，AI 檢索出來的東西一樣會不準，RAG 救不回一個沒整理好的資料庫。

RAG 也確實比單純的提示詞工程更不容易讓 AI 亂講話，但那要建立在檢索品質夠好的前提上。Lewis 等人的研究指出，結合外部可檢索的資料，能讓生成結果更具體、更符合事實，減少憑空捏造的情況；IBM 官方的說明也把可回溯出處、適合需要即時知識的場景，列為 RAG 的優勢之一。資料沒整理好，RAG 一樣救不了。

希望 AI 的語氣、格式永遠一致：靠微調定型

提示詞工程和 RAG 處理的都是「AI 這次回答夠不夠好」，但有一種情況，問題不是知識不夠，而是行為不夠穩定，例如每次輸出的品牌語氣飄忽不定，固定格式的表單、報告，格式老是跑掉，又或者同一類任務量大到每次都要下同一套落落長的指令，才想到微調。

微調可以把原本要在提示詞裡反覆交代的規則，直接內化成模型的預設反應。做完之後，提示詞可以變短，輸出也更穩定，不必每次都提醒模型該用某種語氣、某種格式。

不過有一點要提醒，微調改的是行為，不是知識。它不會讓模型突然多懂什麼新知識，如果資料之後大幅變動，等於要重新跑一次訓練，不適合資料常常變動的場景。這跟前一節講的 RAG 剛好形成清楚的對比，一個適合資料常變的場合，一個適合行為需要穩定的場合。

微調能不能讓 AI 更懂你的產業，答案要看「懂」指的是什麼。如果是指讓 AI 用固定的說話方式、固定的格式回應，微調確實做得到；但如果是指讓 AI 跟上產業裡常常變動的資訊，微調不是適合的工具，這種情況該用 RAG。

OpenAI 官方的模型優化指南裡，把讓模型穩定用特定格式回應、縮短提示詞、適合大量重複任務，列為微調的具體效益，這些描述談的其實都是同一個重點，微調解決的是行為一致性的問題，不是知識廣度的問題。

預算有限、想先驗證可行性：從提示詞工程開始

多數需求，其實光是把提示詞寫好，就能達到堪用的水準，而且幾乎沒有額外成本，改一次、測一次，幾分鐘就有結果。這也是為什麼，提示詞工程通常是預設的起手式。

常見的提示詞技巧，大致可以分成幾類：把任務描述講清楚（包含目的、對象、限制條件）、附上一兩個範例輸出（少樣本學習）、要求輸出遵守特定格式（像是固定的欄位或結構）、必要時要求模型一步步推理再給結論（思維鏈）。這幾種技巧不是互斥的，同一份提示詞裡可以疊加使用。

舉個例子，同樣是「幫我寫一封客訴回覆信」，如果只丟這句話，AI 給出的答案往往中規中矩；但如果把任務描述、範例、格式都寫進提示詞裡，像下面這樣：

角色:你是一家線上書店的客服人員
任務:針對顧客反映的到貨延遲問題,寫一封回覆信
語氣:誠懇、不卑不亢,避免制式官腔
格式:開頭致歉,中段說明原因與後續處理,結尾附上補償方案,總字數在150字以內
範例輸出:「您好,關於這次到貨延遲造成的不便,我們深感抱歉……」(僅示意開頭語氣,實際內容依訂單狀況調整)Code language: plaintext (plaintext)

同一個模型，拿到這樣的提示詞，寫出來的回信會明顯更貼近你要的語氣與格式，前提不是換一個更聰明的模型，而是把需求交代得更完整。

把這些技巧都用到位了，答案還是不準，這通常代表問題不是「問法」出了狀況。如果 AI 給的答案方向對，但內容不是它該知道的，例如公司內部最新的規定、還沒公開的資料，問題出在知識不夠，該找 RAG；如果 AI 每次的語氣、格式都不穩定，同一件事換個問法就跑掉，問題出在行為不夠穩定，該找微調。先確認卡在哪一層，比繼續反覆調整提示詞更有效率。

三個方法不是單選題，而是能疊加的分層架構

把前面幾種情境攤開來看，實務上多數成熟的 AI 應用，很少只用一種方法解決問題，而是三層疊加：先用提示詞工程把「怎麼問」寫清楚，再用 RAG 補上模型原本不知道的最新或專屬資料，如果還有行為不夠穩定的地方，最後才用微調，把常見任務內化成模型的預設反應。

這三層可以只用一層，也可以三層都疊上去，端看問題出在哪裡。而且這個領域還在持續演進，檢索與生成不再只是「查一次、答一次」的單向流程，已經開始出現讓 AI 自己判斷要不要查、查哪裡、查完再檢查一次答案對不對的做法，業界稱為 agentic RAG（代理式 RAG）。

IBM 官方對 agentic RAG 的說明裡，把它定義為在 RAG 流程中加入 AI 代理人，讓檢索與生成從固定規則式的一次性查詢，變成能自主判斷、反覆優化的過程。換句話說，AI 不再只是被動接受一份檢索結果就照著回答，而是可以自己決定要不要再查一次、換個角度查。

不過不管技術怎麼演進，判斷順序不會變。先確認問題出在指令、知識還是行為哪一層，再對症選方法——這也呼應最前面說的，多數時候輪不到微調先出場，它該是排在最後才被考慮的那一步。

提示詞工程、RAG、微調，從來不是要選邊站的三個對手，而是同一套判斷順序底下的三個工具。多數時候，問題出在「怎麼問」，把提示詞寫清楚就能解決；需要補知識，再往 RAG 走；真正需要讓 AI 的行為整個定型，才輪到微調出場。走到提示詞工程加 RAG，就已經能處理大部分場景，微調留給真正需要的那一小塊。

下次遇到 AI 給的答案不夠好，先別急著想是不是該去微調，回頭問自己一句，問題出在指令、知識，還是行為？答案通常比想像中更靠近提示詞工程，而不是那條看起來最厲害、卻也最貴的路。