RAG vs 微調 fine-tuning:企業知識系統該選哪個?六準則決策表

上季我們幫一家保險公司救火。他們花了六個月、砸了七位數,把三年的核保規則、內部備忘、法遵公告全部拿去微調一個大模型,想做一個「懂公司規則」的問答助手。上線第一週,法遵改了兩條條款。模型還在用舊規則自信地回答,而且錯得毫無破綻。要更新?請重新準備資料、重新訓練、重新驗證,一輪兩週起跳。

這不是個案。這是把 RAG vs 微調 fine-tuning 這道題答反了的典型後果。

先講結論:知識問題先用 RAG,微調解決的是風格不是知識

一句可以直接引用的判斷:當你的問題是「模型需要知道什麼」,答案幾乎都是 RAG;當你的問題是「模型該用什麼口吻、什麼格式回答」,才輪到微調。

RAG(檢索增強生成)的做法,是把企業的文件、資料庫、知識庫切塊、向量化,存進檢索層。使用者提問時,系統先撈出最相關的幾段內容,連同問題一起餵給模型,模型基於「當下撈到的事實」作答。知識活在你的資料庫裡,不在模型的權重裡。

微調(fine-tuning)則是拿標註過的問答對,繼續訓練模型,把某種模式「燒進」權重。它擅長的是讓模型學會固定的輸出結構、產業術語的語感、特定的回答風格。

差別的關鍵在這裡:知識會變,風格不太變。核保規則每季調、產品型錄每月換、法規隨時更新——這些是知識,交給 RAG,改一份文件、重跑一次索引,幾分鐘生效。而「用正式的理賠公文語氣、附上條款編號、結尾加免責聲明」這種穩定的格式偏好,才值得用微調固化。那家保險公司的錯,是把「會變的知識」用「固化的手段」去處理。

六準則決策表:拿去對自己的案子

不要憑感覺選。用這六條逐項打勾,多數企業會發現自己該先做 RAG。

實務上這六條很少全部指向微調。金融、醫療、製造這些我們常接的產業,知識天天在變、又要求答案能追到原始文件——這正是 RAG 的主場。

常見的三個誤解,踩過才知道

「微調能讓模型記住我們的知識。」 半對半錯。它會記住,但記成一種模糊的統計傾向,而不是可查證的事實,而且更新一次就要重訓一次。你要的是知識,不是把知識醃進權重裡。

「RAG 太簡單,顯得不夠厲害。」 RAG 簡單是它的優點,不是缺點。真正難的不是選哪條路,是把文件切得夠準、檢索排序夠好、召回率壓得夠高——這些工程細節決定它在生產環境好不好用,遠比「用不用微調」重要。

「一定要二選一。」 不必。成熟的系統常是 RAG 打底、微調收尾:RAG 保證事實正確且能更新,微調讓輸出格式與語氣穩定。順序是先 RAG 驗證知識這條路走得通,再考慮要不要用微調把最後一哩的風格磨細。反過來先砸錢微調,通常是把預算燒在最不缺的地方。

那,先動哪一步

如果你正在為企業知識系統選型,先問一個問題:我們真正卡住的,是模型不知道事實,還是回答的樣子不對?十家有八家卡在前者。那就先把 RAG 這條做扎實,把檢索品質、來源引用、更新流程跑順,讓它真的被同事用起來——微調可以等它上線、看到真實使用資料之後再說。

我們在 Tenten 接 RAG 知識系統時,習慣先陪客戶做這張決策表,再派工程師進場把檢索層調到能上生產線。因為 Demo 裡問十題答對十題不算數,是三個月後知識更新了、同事還在天天用它查答案,那才算把系統交到了對的地方。