什么是RAG，RAG學習和實踐經驗

最近寫的RAG內容已經挺多了，然而內容逐漸變得零散，我今天給大家總結一下RAG的有關內容，同時給大家把有關內容串起來。當然，串起來的更多是概述和摘記，讓大家對RAG的基礎有更整體的了解，詳情大家可以根據需要再展開了解，我也會在合適的位置加上原文鏈接。

之前的文章算下來是三萬多字，加上這篇應該能超過4萬了，也特此記錄一下自己在RAG這塊的學習和實踐經驗。

內容目錄：

概念。

從baseline到技術拓展。（basleine和高級RAG升級）

調優方案。（論文視角和實踐視角）

效果評估。

微調和RAG的權衡。

RAG是否會消亡。（本文私貨）

概念

首先還是得介紹什么是RAG（Retrieval-Augmented Generation）指的是通過將檢索模型和生成模型結合在一起，從而提高了生成內容的相關性和質量。說到概念，嚴謹的，我照舊摘錄來自一篇綜述的解釋：

In the era of Large Language Models, the specific definition of RAG refers to the model, when answering questions or generating text, first retrieving relevant information from a vast corpus of documents. Subsequently, it utilizes this retrieved information to generate responses or text, thereby enhancing the quality of predictions.

說白了就是有檢索和對檢索的使用，基本都可以說是RAG了（極端的，某種程度上，詞典匹配，也算是一種RAG）。

正因為需要包含檢索以及后續大模型的使用，所以RAG和原來常規的深度學習研究不太一樣，他不是一個深度模型，更像是一個系統，系統里面可以有多個組件，一般的結構可用下面這張圖來表示。

但概念解釋我不想止步于此，在這里我想進一步挖掘，RAG這個概念的起源。早在2020年就已經有人提及RAG的概念（Retrieval-augmented generation for knowledge-intensive nlp tasks，他的首版發布在arxiv于2020年5月，如果有更早的歡迎大家再提出）（這篇論文后面有時間，我也想拿出來詳細講講），當年還是seq2seq的時代，但實驗就已經發現，通過檢索，能快速從海量知識中找到和原本問題相關的知識，借助知識帶來的信息能讓最終的生成效果能夠得以提升。

從baseline到技術拓展

baseline

最基礎的RAG，就是上圖左邊的Naive RAG，基本只包含兩個部分，即檢索和生成，為了讓大家更好地理解RAG整體結構，我自己寫了一版基礎RAG項目，這里最大程度還原最基礎RAG的結構，同時也給了一定的調優空間，github地址：https://github.com/ZBayes/basic_rag，講解我分成了兩篇文章：

心法利器[104] | 基礎RAG-向量檢索模塊（含代碼）

心法利器[105] 基礎RAG-大模型和中控模塊代碼（含代碼）

里面有幾個比較關鍵的點，著重拿出來講一下。

這個項目是奔著大型RAG項目去寫的。所以里面會劃分服務而不是一個流程全部寫完，注意看服務和代碼文件的拆分，還有具體服務是怎么串起來的。

服務是用tornado寫的簡單版，當然換成別的服務組件也可以，例如flask、fastapi等。

里面有幾個部分：離線的灌數據模塊，一般就是腳本；檢索模塊是在線的檢索，目前使用的是最簡單的向量召回；大模型模塊用的是一個chatglm，直接封裝服務就好了。

很多位置我都為后續的迭代留了空間，例如向量檢索這里，我切分了很多層，searcher、vec_searcher、vec_index，就是給了很多空間，一個searcher可以有很多不同的索引和索引類型，vec_searcher是向量檢索，下面可以有多個vec_index，對應不同的向量模型。

技術拓展

有關RAG的拓展，往往會在naive基礎上分為兩個階段，高級RAG和模塊化RAG。

高級的RAG能很大程度優化原始RAG的問題，在索引、檢索和生成上都有更多精細的優化，主要的優化點會集中在索引、向量模型優化、檢索后處理等模塊進行優化，模塊化RAG是對高級RAG的一種升級，這里面集成了大量優化策略，并將這些策略進行重組，形成完整的模塊獨立完成特定功能，很多內容和前面的高級RAG提及的內容很接近，只是更加模塊化，如搜索模塊、記憶模塊、額外生成模塊、任務適配模塊、對齊模塊、驗證模塊等，因為RAG本身是一個高度組織性的項目，因此在迭代過程中，是允許且需要對這些模塊進行優化和調整的，可以增減、調整各個模塊。

具體有什么調優方案，我在下一個章節展開說。

調優方案

說到調優，無論是學術界還是工業界，可謂是八仙過海各顯神通，但是科研和工業界各自會呈現不同的傾向性，所以這里我分兩個大塊來講，分別是學術界和工業界的思路。

學術界

學術界自然離不開綜述，1月份我對綜述（Retrieval-Augmented Generation for Large Language Models: A Survey）進行了詳細的講解，字數有7千多（前沿重器[41] | 綜述-面向大模型的檢索增強生成（RAG）），文章里對RAG的升級路徑進行了詳細解釋，其中重點從檢索模塊、生成模塊、整體等角度對RAG目前的關鍵技術進行了講解，為RAG的調優提供了大量思路。簡單摘錄一下：

檢索模塊重在關注向量模型的合理表征（領域微調和下游任務微調）、query和文檔語義空間的匹配（query改寫、實體mask等策略）、大模型和檢索模塊協同的優化。

生成模塊關注檢索的后處理（重點信息提取、檢索結果重排）、生成結果的處理等角度。

整體調優從調優階段（入手點）、數據來源和調優思路三個角度來分析具體的調優方法。

里面的內容過多，不好展開，詳情大家可以看我的講解（前沿重器[41] | 綜述-面向大模型的檢索增強生成（RAG））或者是綜述原文（Retrieval-Augmented Generation for Large Language Models: A Survey）。

另外值得提起的是兩篇RAG比較有代表性的文章，這里給出我的解讀以及思考，分別是self-RAG（前沿重器[42] | self-RAG-大模型決策的典型案例探究）和CRAG（前沿重器[43] | 谷歌中科院新文：CRAG-可矯正的檢索增強生成），具體他們是怎么做的以及我是怎么分析和看待的，都在這里了。

工業界

工業界也有一篇綜述，不過里面體提到的方案和思路更加偏向應用，所以我想把這篇放在工業界（https://pub.towardsai.net/advanced-rag-techniques-an-illustrated-overview-04d193d8fec6），我也寫了解讀文章（前沿重器[40] | 高級RAG技術——博客閱讀）。

和前面的綜述類似，這里也提到了基礎RAG、高級RAG和區別，然后就展開解釋各個模塊的優化了：

離線文檔處理。

文檔內容增強。

索引構建和選擇。

檢索策略多樣性和合并。

查詢后處理。

多輪和聊天引擎。

查詢路由和智能體。

響應合成。

模型微調。

這些結構里，能看到很多現實應用才會遇到的特定問題，例如檢索策略多樣性和合并，工業界和學術界的視角差異還是很大的，工業界更傾向于拆分分別處理，既能更方便特異化處理提升上限，也方便進行分工推進工作，而學術界其實并沒有那么擅長尤其是這種橫向的拆分，確實是不夠學術優雅。

而且，我自己也根據自己的經驗提供了很多優化思路，專門有寫文章（心法利器[106] 基礎RAG-調優方案），盡管現在來看還有很多可以聊的部分（后面有機會我再寫?。?，但這篇也很實用了，希望對大家有多幫助，里面提了很多實踐和分析數據才會發現的優化點。我是分為檢索調優、prompt、后處理、微調這幾個方面去談的。

除此之外，知識的處理也是一個非常重要的一環，尤其現在大模型出來后，文檔處理能力提升還挺明顯的，我正好寫了一篇文章，主要是串講知識的處理和使用流程，同時介紹了里面的常用方案，大家可以在有個大框架的基礎上進一步深入學習（心法利器[110] | 知識文檔處理和使用流程）。

有一篇比較取巧地query拓展的文章（前沿重器[38] | 微軟新文query2doc：用大模型做query檢索拓展），屬于對搜索有用，現在視角看對RAG領域也有很大的優化收益，所以在這里也重提，非常推薦大家在早期項目上使用這個方案，雖然多了一次大模型調用的代價，但是效果提升還挺明顯，值得推薦。趁此機會也補充說明一下，在之前已經有一篇類似的論文，HyDE（Precise Zero-Shot Dense Retrieval without Relevance Labels），這篇我沒出解讀，感覺重復不少，我就不重寫了，但仍很推薦大家也讀讀看。

效果評估

效果評估是算法的重要一環，我也對這塊內容進行了詳細調研和經驗總結（心法利器[109] | RAG效果評估經驗）。類似的，我也是從學術界和實際場景應用兩個角度分別闡述兩者的評估方案，并從快速驗證、穩定評估和問題定位三個角度，給出實踐場景下的建議。

方案選擇和權衡

RAG只是大模型的一種使用方法，檢索技術能快速從海量知識中找到和原本問題相關的知識，借助知識帶來的信息能讓最終的生成效果能夠得以提升，因此RAG本質上并非大模型的專屬，從而可以發現大模型不是非RAG不可，RAG也不是非大模型不可，RAG只是大模型的一種打開方式，他所解決的，是對知識的依賴，這可以是知識的可見性（能懂大模型之前沒見過或者沒學好的東西）、及時性（新知識）、存在性（不會的能拒絕）等問題。

而它的使用時機，以及和微調之間的權衡，詳細地討論可以參考這篇文章（心法利器[108] | 微調與RAG的優缺點分析），在這里我有通過論文、社區等角度匯總了多方觀點，并通過案例分析的方式給出了我的答案。

RAG（檢索增強生成）會不會消亡呢

另外，我想在這里駁斥一個社區經常談及的問題：“RAG（檢索增強生成）會不會消亡呢？”（https://www.zhihu.com/question/637421964），這個問題的背景是目前的大模型Context Length變大，RAG就可能會消失。這個問題我本想專門寫文章，但又感覺不夠長，寫一半成了廢案，于是就放在這里吧，還挺合適的。

第一，這個問題能問出來，說明對RAG背后所希望解決的問題理解不足吧，RAG所要解決的是知識依賴的問題，知識依賴這個事和大模型Context Length的關系并不緊密。

第二，知識依賴這不只是大模型的問題，而是整個領域都要面對的問題。在很早之前（都是21年那會的文章了），我就寫過一篇文章（心法利器[45] | 模型需要的信息提供夠了嗎），從一個更高角度來聊信息傳遞給模型的重要性，模型要是不知道，那讓他干的事就很可能會辦不好，而向模型傳遞信息，一般有兩個方法，一個是訓練，一個是特征，對應到現在大模型的場景，那就是微調和prompt，前者通過大量相似相關的數據案例告訴模型讓模型照著預測，后者則是把規則描述講給模型聽或者把關鍵信息直接傳給模型，降低他的推理壓力，只要關鍵信息沒有提供給模型，那效果就好不了，過去的bert是這樣，現在的大模型也是這樣。

第三，同樣是模型的問題。無論是大模型，還是之前的小模型，對信息反饋的及時性，仍舊不足。大家或多或少都會發現，一些去年前期發布的開源模型，或多或少都對新的知識并不了解，其根本問題就是，沒有學習到新知識，要學習新知識，不得不經過嚴格的訓練和評估才能上線，且還要面對遺忘的問題，要做實時的難度非常大，這里就是第二點提出的微調方向。要解決這種，不得不依賴外部信息的支持，然后通過第二點提到的prompt的方式輸入到模型中，而這些知識，無法繞開檢索來進行。舉個例子，某些商店的上架商品信息，天氣日期、新聞等的一些實時性要求高的知識，就只能通過數據庫來存儲，數據庫的更新可以非常敏捷，查詢后配合prompt交給大模型來解決了。

綜上，只要上面的知識依賴、知識更新問題沒有解決，那RAG就仍有一席之地。至于RAG內部說到的搜索，可以說是從來沒大火過但是又一直在喝湯的領域了。

審核編輯;黃飛