微調 vs RAG 這個題目，多半不是以問句出現，而是直接以一句結論登場：我們要拿自己的資料去微調一個模型。這大概是企業 AI 裡最花錢的一句話，而且多數時候是錯的。不是每次都錯，但確實多數如此。這句話背後幾乎只有兩種真實情況：模型不清楚我們公司的事，或者模型回答的方式不合我們的要求。前者用微調來解很糟糕，後者用微調來解很貴。

在微調、RAG 與提示詞之間做取捨，並不是工程師的口味問題。這三者處理的是完全不同類別的毛病，一旦選錯，換來的會是好幾個月的工，而最初那句抱怨依舊原樣擺在那裡。

最能省下預算的一條原則： 如果毛病出在模型不知道某件事，就用檢索。如果毛病出在模型知道，但回答的風格、格式或篇幅不對，先把提示詞改好，真的無效時才輪到微調。微調教的是行為，不是事實；把微調拿來灌知識的團隊，最後只會得到一個用新文風理直氣壯講錯話的模型。

微調 vs RAG vs 提示詞：各自負責什麼

這三者的分工，其實比外界討論的樣子單純很多。

提示詞改的是你每次送出請求時附帶的那段指令。它決定語氣、格式、結構與推理方式，也能順手夾帶少量上下文。它立刻生效，除了 token 之外沒有額外開銷，而且在正式環境裡幾秒鐘就能改掉。

檢索會在請求進來的當下，從你自己的內容裡撈出相關素材，在模型作答前先塞進上下文。這讓模型能碰到它在訓練時根本沒見過的資訊，包括今天早上才剛改掉的東西。模型本身一個字都沒動，你改的只是交到它手上的材料。運作原理可以參考我們的檢索增強生成 說明。

微調是拿你想要的行為的範例去調整模型權重。碰到那種很難用文字講清楚、卻很容易示範的固定格式、語氣與任務專屬模式，微調確實管用。但它不適合拿來教事實，因為這樣學到的事實無法更新、無法稽核、也無法標註出處，而且模型引用錯了也不會主動告訴你。

會混淆是因為三者都會改變輸出。但只有檢索會改變模型知道什麼。

各自要花多少錢

以下數字對應的是英國市場上一個中型商業應用的典型交付情形。

提示詞。 以天為單位而非以週為單位，通常落在 1,000 到 5,000 英鎊，其中包含你應該同步做出來的評估集。執行成本就是 token 的錢；系統提示詞拉長會讓它稍微上升，而提示詞快取大致抵得掉這一段。

檢索。 四到十二週，常見落在 15,000 到 60,000 英鎊，看來源內容有多亂而定。建置成本主要壓在資料匯入這一段：把文件從各個系統裡撈出來、做出合理的切塊、處理權限讓使用者只撈得到他有資格看的東西，還要讓索引維持在最新狀態。執行成本另外要算上向量儲存，以及每次請求都略為變大的上下文。

微調。 兩到八週的工程加上資料集，常見落在 20,000 到 80,000 英鎊。訓練算力往往是裡面最小的一筆；真正的成本在於做出數百到數千筆高品質範例，而那是懂這個領域的人一筆一筆做出來的人力工。執行成本也可能更高，因為微調過的模型常常有價差，或是需要專屬的主機資源。

重點就在這個不對稱上。提示詞便宜到就算你頗有把握它不夠用，也值得先試一輪，因為那套評估機制你反正躲不掉，而且你會順便弄清楚真正的失敗型態是什麼。

該用什麼順序去試

照順序走完，比一步跳到終點便宜，就算你最後真的走到終點也一樣。

先把評估集做出來。 三十到一百筆真實輸入，配上已知正確的輸出。少了這個，你根本判斷不出任何調整到底有沒有效，後面每一個決定都只是猜。這就是我們在 OpenAI API 整合指南 裡描述的同一套評測體系。

接著把提示詞改好。 格式講明確，在提示詞裡直接放幾個好輸出的範例，並交代答案不確定時該怎麼處理。相當高比例的「模型不夠好」的抱怨，在這一步就消失了，特別是囉嗦與結構這兩類。

再來換一個更大或不同的模型試試。 這通常比任何客製化工程都便宜，評估起來大概就一個下午。我們談換掉 OpenAI 的那篇，寫了怎麼把這個比較做得可靠。

如果失敗的是知識，就加上檢索。 當模型是在回答你們產品、規章或文件相關的問題時答錯或乾脆拒答，這一步才是真正的解方。

如果失敗的是行為，才輪到微調。 走到這裡，你手上已經有評估集、調好的提示詞，必要時還有一條檢索流程。如果輸出在風格或結構上還是搆不到要求，而且你用幾百筆範例把想要的行為示範出來，比用文字描述來得容易，那微調就是對的工具。

多數專案會停在第三步或第四步。省下來的就是這一段。

微調真的划算的情況

確實有真實的適用場合，全盤否定它，跟第一步就伸手去拿它一樣不對。

大量而且格式必須一致的結構化輸出。 當每一則回覆都得照著一套很死的格式走，而那套格式用提示詞寫起來又極為冗長時，微調過的模型產出得更穩定，輸入 token 也少得多，量一大就把成本賺回來了。

特定的語氣或產業文體。 法律文件撰寫、臨床紀錄、受監理的金融溝通：這些文體有很強的行規，同行一眼認得出來，卻很難寫進指令裡。

界線細微、講不出規則的分類。 當你的團隊標得出一致的標籤，卻說不清楚判準到底是什麼，那正是拿範例去訓練要解決的事。

高流量下的成本壓縮。 一個較小的微調模型，在某一件很窄的任務上追平大型通用模型，可以把單次請求的成本壓下來一大截。只有當流量大到省下的錢超過建置與維護的支出時，這筆帳才划得來。

貫串這幾種情況的都是行為，不是知識。你如果能用一段文字把要求講清楚，就寫進提示詞；你如果只能做給它看，那就訓練它。

沒有人會報進去的成本

微調的商業評估裡，有三項長期負擔幾乎都被略過。

資料集會老化。 微調後的模型反映的是它看過的那批範例。等產品、規章或內部行文慣例一改，那批範例就過期了，而模型還是會理直氣壯地照舊做。定期重訓要當成常態支出編進預算，不是一次付清的項目。

你被綁在某一個基礎模型上。 微調是掛在特定版本上的。等這個版本停止支援，或是出現更好的模型，你得重訓一次才搬得動，這是提示詞方案完全沒有的實質轉換成本。

評估從可選變成必要。 用提示詞的時候，退步你用肉眼就看得出來。換成微調模型，你沒辦法翻進去看行為為什麼變了，那套評估機制就成了你手上唯一的量測工具。

檢索也有規模小一點的同類負擔：索引要持續維持在最新狀態，權限要隨著人員異動保持正確，資料匯入要是無聲無息斷掉，也得有人察覺。比重訓便宜，但不是免費。

先做診斷，再開始建置

Mecanik 把檢索系統、評估機制與微調流程一併放在 AI 整合服務 裡交付，而我們的第一件事，是先確認你手上碰到的到底是這三類問題中的哪一類。

這個診斷通常只是一段很短的合作，而且它經常以一個花費遠低於你原本規劃的建議收場。要是微調真的就是答案，我們會直說，並且誠實地把資料集這段工作的範圍講清楚，因為那才是決定成敗的地方。想看更完整的預算輪廓，我們的 AI 整合成本指南 把建置成本與營運成本分開列出來了。

用你們使用者會講的話，告訴我們模型到底哪裡做得不對，我們會告訴你這三件事裡是哪一件。

相關文章: AI 軟體開發 - 2026 年英國企業指南 、自架 Kimi K3：硬體、成本與資料主權 、2026 年 Drupal 遷移：成本、選項與期限 、打造 OpenAI API 聊天機器人：2026 指南 。

常見問題

我該用公司資料去微調模型嗎？ 通常不該。微調教的是行為而不是事實，用這種方式學到的知識沒辦法更新、標註出處或稽核。如果問題在於模型不清楚你們的產品、規章或文件，檢索才是正確做法，建置和維護的花費也比較低。

微調和 RAG 差在哪裡？ 檢索是在請求進來的當下，從你的內容裡撈出相關素材放進上下文，所以模型可以根據它訓練時從未見過的資訊作答。微調則是拿範例去調整模型權重，改的是它的行為方式，而不是它知道什麼。

微調要花多少錢？ 以一個中型商業應用來說，通常落在 20,000 到 80,000 英鎊，需要兩到八週的工程。訓練算力往往是裡面最小的一筆，大部分成本花在做出數百到數千筆高品質範例，而那需要真正懂這個領域的人來做。

建一套 RAG 系統要花多少錢？ 常見落在 15,000 到 60,000 英鎊，期程四到十二週，主要看來源內容有多亂。大部分工都花在資料匯入、切塊、處理權限讓使用者只撈得到有資格看的東西，以及讓索引維持在最新狀態。

這幾種做法該照什麼順序試？ 先做評估集，接著改提示詞，再換更大或不同的模型，如果失敗跟知識有關就加上檢索，只有在失敗跟行為有關時才最後考慮微調。多數專案在走到最後一步之前就已經解決了。