RAG、微調 Fine-tuning 還是 Agent?企業知識應用的三條路線選型

先給一個能直接拿去用的判斷句:RAG 適合知識天天在變、答案必須附出處的場景;微調 Fine-tuning 適合知識穩定、你要的是固定語氣或格式的場景;Agent 適合任務需要「查完再做動作、跨多個系統」的場景。三者不是誰取代誰,大多數上線系統最後是混著用。

但真正決定選型的,不是這句話,是底下三個軸。

RAG vs Fine-tuning vs Agent:先搞懂它們在做什麼

RAG(檢索增強生成)是讓模型在回答前,先去你的知識庫撈相關段落,再根據撈到的內容作答。模型本身沒被改,改的是「它手上有什麼資料」。

微調 Fine-tuning 是拿你的資料去再訓練模型,把知識與風格「燒進」權重裡。回答時不用外掛資料,反應快、語氣一致,但知識是訓練當下那一刻的快照。

Agent 則是上層的編排:它會拆解任務、決定要不要查資料(常常就是呼叫 RAG)、要不要呼叫某個 API、要不要分好幾步做。它是「會做決策與動作」的那一層,而不只是回一段文字。

看清楚這點,你就知道它們常常是疊起來的:一個 Agent 內部用 RAG 取知識,再用一個微調過的小模型負責特定格式輸出。

第一軸:知識更新頻率

這是最容易一刀切開三條路線的軸。

我們去年接一家醫療器材商的案子。他們的產品仿單、法規函釋、經銷合約條款,幾乎每個月都在改。一開始內部團隊很興奮地說要微調一個「懂我們產品的模型」。我們把話擋下來了。原因很簡單:知識每月變,而微調一輪從資料清洗到驗證要兩三週,你等於永遠在追一個跑掉的目標,而且每次都要重花錢重跑。

這種情境,RAG 幾乎是唯一合理解。知識庫換一份新文件,系統下一秒就用新的答。更新成本趨近於零。

反過來,如果你的知識半年、一年才動一次——比如公司內部固定的客服話術、品牌語氣規範、標準免責聲明——微調就開始有優勢,因為它把這些「不會變的東西」內化了,回答又快又穩,不必每次都去檢索。

Agent 在這一軸上其實是中性的:它自己不儲存知識,而是決定「什麼時候該去拿最新的」。知識變不變,交給它底下掛的 RAG 或工具去扛。

第二軸:可解釋性

金融和醫療的客戶,問的第一個問題往往不是「準不準」,是「它為什麼這樣答,能不能給我看根據」。

這一軸上 RAG 幾乎完勝。因為答案是根據撈出來的具體段落生成的,你可以把來源文件、頁碼、原文一起附上去。稽核來查、法遵要簽核,你攤得出證據鏈。

微調就尷尬了。知識燒進權重之後,你很難說清楚某個答案是從哪份訓練資料來的,它是一團統計後的結果。模型答錯時,你甚至不容易定位是哪筆資料教壞的。在受監理的產業,這種「說不清楚」本身就是風險。

Agent 的可解釋性取決於你怎麼設計。好處是它的每一步決策、每一次工具呼叫都可以被記錄成一條軌跡(trace),你能重播它「先查了什麼、再做了什麼」。壞處是步驟一多,出錯的環節也變多,你要花力氣把這條軌跡做得可讀、可稽核,否則它會變成一個更難debug的黑盒。

第三軸:成本

成本要拆成兩塊看:建置成本,跟每次呼叫的推論成本。

路線	建置成本	每次推論成本	知識更新成本	可解釋性
RAG	中(要建向量庫與檢索管線)	中高(每次都塞入檢索到的長 context)	極低(換文件即可)	高(可附出處)
微調 Fine-tuning	高(資料標註+訓練+驗證)	低(prompt 短、反應快)	高(要重訓)	低(權重黑盒)
Agent	高(編排、工具串接、測試)	高(多步驟、多次呼叫累加)	依底層工具而定	中(靠 trace,需刻意設計)

這張表最容易被忽略的一格,是 Agent 的推論成本。一個任務跑五步,就是五次模型呼叫加上工具往返,token 是疊加的。Demo 的時候你只跑一次沒感覺,等每天幾萬次請求上來,帳單會教你做人。我們有個案子就是因為 Agent 的步驟沒收斂,月成本比預估高了三倍,後來把其中兩步換成微調小模型直接輸出,才壓回來。

所以到底怎麼選

把三個軸疊起來,決策其實很清楚。知識常變、又要出處,選 RAG。知識穩定、要的是速度與一致語氣,選微調。任務要跨系統、查完還要動手做事,才動用 Agent——而且通常是包著 RAG 一起用。

我們自己進場時,幾乎不會讓客戶一開始就上 Agent。先用 RAG 把「答得準、答得出來源」這件事跑穩,拿到真實使用率數據,再判斷哪些高頻、格式固定的環節值得微調換取成本,最後才在確定有跨系統動作需求時,把 Agent 疊上去。順序反過來,通常就是那種 Demo 很漂亮、上線三個月使用率卻卡在個位數的專案。技術選型從來不是選最潮的,是選在你這三個軸上,一年後還撐得住的那一條。