目錄：

• 為什么用微調和RAG對比

• 微調和RAG的優劣勢對比

• 技術方案分析案例

為什么用微調和RAG對比

開始可能有小伙伴會問我，為什么要拿微調和RAG進行對比，我自己的理解，主要是因為這個兩個所代表的其實是在現實情況中對系統的調優方案，即調整模型內和調整模型外。

縱觀整個算法領域，對模型內部調整，不外乎是那幾種方案，特征變化帶來的模型結構調整（特征可以是隱式的內部特征，也可以是輸入端或輸出端的顯式調整），以及通過數據變化帶來的內部參數更新。無論是哪種方案，都會很大程度地影響模型的預測效果，一般情況，會為以模型為中心的系統效果帶來很大的影響。

模型外的調整，不外乎就是增加一些外部的組件，例如規則、檢索模塊等，從而讓整個系統的效果帶來一些變化，在全新版本大模型時代，大模型為我們提供了更靈活的輸入接口，即我們可以用prompt的方式靈活指導模型輸出，可以給參考材料、額外信息、提特別要求甚至是通過描述、樣例的方式即可讓大模型的輸出符合我們預期。

而RAG的出現，一方面是因為大模型具有很強的指令生成能力，另一方面是模型內調整在現實應用情況一些局限性，從而形成了一個目前重要的應用思路，實踐上最鮮明的兩個特點，一個是內容批量的可控性和及時性，另一個是這種更新并不需要更新模型參數從而規避效果波動的風險。至于規則等的方案，某種程度上，其實就是RAG的一種特殊情況，例如什么情況需要觸發什么回復策略的約束。

因此，我自己是認為，要去權衡RAG，不得不把他和微調進行對比，探索兩者各自的優勢，進一步在方案選型的時候，從感性理解到理性對比判斷。

微調和RAG的優劣勢對比

這里我寫我的分析調研總結過程吧，然后匯總結論。

論文討論

首先是論文層面，有一篇論文對這方面進行了討論：“Fine-Tuning or Retrieval?，Comparing Knowledge Injection in LLMs”，這又是一篇微軟的論文（怎么最近老是無意間碰到微軟的論文，頻率很高），這篇論文本身是從信息注入的角度來進行討論的，從文章的實驗看來，微調的效果始終比不過RAG的效果，而究其原因，作者在前文中其實有提到具體的表現，摘錄一下：

• 領域知識不足。對未接觸過的內容，效果就會很差。

• 信息過時。知識的更新只取決于訓練集的截止時間。

• 記憶力問題，對訓練過程接觸的知識，很大可能會忘記（說白了就是沒學會），對已經學會的知識，也可能因為后續的訓練而遺忘。

• 推理失敗。對已有知識，可能也會因為使用失敗而讓回答出現問題。

另外還發現了一篇還不錯的論文，RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture（嗯，這篇也是微軟的），這里面也是做了比較多的實驗和嘗試，給出一些基于實驗的分析，這篇更像是一篇調研報告，挺建議大家回頭去精讀的，我這里把比較重要的這張圖擺出來。

這篇相比上面一篇，分析的維度更豐富了，有考慮成本等問題，但論文的分析還是有一定局限性，很多情況其實不會考慮到現實情況的很多問題，例如，數據數量和質量問題，實際業務需求等。

社區討論

有關社區的討論，一般是通過百度谷歌等渠道來檢索類似的文章討論，另外知乎、微信搜索也是不錯的渠道。我找到的比較好的討論，我都列舉出來吧：

• 何時應微調 LLM？何時又該使用 RAG？：https://www.zhihu.com/question/638730387

• 如何選擇最適合你的LLM優化方法：全面微調、PEFT、提示工程和RAG對比分析：https://zhuanlan.zhihu.com/p/661830285

• 大模型優化：RAG還是微調？https://blog.csdn.net/qq_41929396/article/details/132689632

• RAG與微調—哪個是提升LLM性能的最佳工具？https://zhuanlan.zhihu.com/p/679528711

• 專補大模型短板的RAG有哪些新進展？這篇綜述講明白了：https://www.jiqizhixin.com/articles/2024-01-08-8

這里盡量不要讀個一兩篇就完事了，最好多讀幾篇，能理解的更加全面完整。

匯總結論

這里我分幾個方面來進行對比吧。

首先是知識層面，這個應該是RAG使用者最關心的。

• RAG對知識的更新時間和經濟成本更低。不需要訓練，只需要更新數據庫即可。

• RAG對知識的掌控力會更強，相比微調更不用擔心學不到或者是遺忘的問題。

• 但是如果模型強缺乏某個領域的知識，足量數據的微調才能讓模型對該領域有基本的概念，如果不具備領域知識基礎，RAG仍舊無法正確回答。

然后是具體任務效果的問題。

• RAG相比微調能更容易獲得更好的效果，突出的是穩定性、可解釋性。

• （有點經驗之談了）對任務模式比較簡單的任務，微調能觸碰到更高的上限，但是對訓練、數據等方面的要求會更苛刻。

• 幻覺方面，RAG從各種實測來看，短板基本都在檢索模塊，只要檢索不出大問題，整體效果還是RAG比較有優勢的。

第三塊來聊成本了，現實應用很難避開成本的問題。

• 訓練角度，RAG的成本就是更新數據庫，但是微調就需要大量的顯卡、時間資源。

• 推理角度，考慮到RAG本身需要檢索，而且檢索層為了確保檢索準確，還需要很多額外工作，所以推理的耗時會比微調多，但具體多多少，就要看檢索模塊的復雜程度了，如果這里面還需要額外調大模型，那成本就會多很多，如果只是小模型之類的，那這個增加可以說是忽略不計。微調后的大模型直接使用，和原本模型的耗時一致。

• 系統拓展角度。隨著項目的發展，大模型訓練不一定能支撐多任務，而拿著大模型訓好幾個，對部署而言并不方便。

上面的內容所體現出來的，更多是RAG的優勢，看起來似乎微調就沒有什么好處了。但事實并非如此，RAG還是有很多不適用的環境的。

• RAG依賴知識庫。如果不具備構造知識庫的條件，那RAG無從談起，例如沒有具體的業務數據，或者是機器不支持支撐檢索之類的。

• 業務需求并非對知識依賴。例如某些業務的話術生成，更多是對語言風格的約束，此時要么通過prompt解決，要么就是構造業務數據來進行訓練即可，根本沒有構造RAG的必要。

• 依賴實時信息而非固有信息。直接舉例，對話摘要應該是大模型具有的比較強的能力，這種任務更多是依賴收到的對話記錄，而非一些固有存儲好的內容，此時通過工程手段直接把信息獲取導入到模型即可，不需要把對應內容入庫了。如果對對話摘要的內容不滿意，則應該是通過prompt和微調來解決。當然有人可能會說通過few-shot的方式，可以用RAG，這個當然是可以的，但就不是必須了。

• 指令不生效或者領域知識完全不具備。這個不多解釋了，大模型此處是短板，那即使是RAG，把答案擺在面前，也解決不了問題。

• 內容會受到檢索結果局限。有些創造性的任務，本身是想通過大模型獲取新的靈感，然而檢索結果給到大模型后，大模型往往容易受到限制，這個限制在有些時候是好事，但并非所有時候。

技術方案分析案例

借助兩個比較典型的案例，大家應該能體會這兩者的區別了。

產品百科問答

電商場景下，客服都要具備一個能力，就是產品百科問答，用戶會需要咨詢某些商品的屬性等細節消息，這是一個很具體的場景了。然而實際我們需要面對的，除了這個功能本身，還需要解決一個問題，即商品信息是需要更新和變化的，例如新商品上架、價格優惠修改等，這個信息是需要快速反映在問答系統中的，此時我們RAG非常有必要性。

• 商品信息的更新，不定期且頻繁，這種更新通過微調來做，敏捷度不足，風險也比較高。

• 知識如果是結構化，本身用于微調訓練并不方便，需要轉化，但是數據庫存儲則比較方便。

• 商品型號很多很接近，容易混淆，大模型很容易出現“張冠李戴”現象。

日常工作工具

寫周報、靈感、工作日志、修改一份材料、查錯查重、話術推薦、會議紀要之類的，類似這些問題，我們更多的日常使用方式就是prompt+大模型完成，我們做起來非常自然，可能頂多會根據自己的需求加一些例子，但往往不會優先考慮RAG。

• 對固有信息要求不高，甚至沒有需求。

• 供給檢索的數據，如果不是因為產品本身的信息收集，一般情況下很難獲取，對RAG而言可以說是無米之炊了。

• 類似靈感的任務，案例反而可能限制模型發揮。

• 要求的更多是指令的執行能力，這個如果不具備，很可能就要考慮通過微調來整了。