RAG是大語言模型、自然語言處理、知識問答、智能客服、企業知識庫和 AI 應用開發中非常重要的一個術語，全稱是 Retrieval-Augmented Generation，通常翻譯為“檢索增強生成”。它用來描述一種讓大語言模型先從外部資料中檢索相關內容，再基于這些內容生成答案的方法。換句話說，RAG 是在回答：模型怎樣在不完全依賴自身參數記憶的情況下，利用外部知識回答問題。

如果說普通大語言模型主要依靠訓練階段學到的參數知識來生成回答，那么 RAG 更強調“先找資料，再組織答案”。它把檢索系統和生成模型結合起來，讓模型在回答問題前，先從文檔、數據庫、網頁、知識庫或業務資料中取回相關片段，再把這些片段放入上下文窗口，作為生成答案的依據。

因此，RAG 常用于企業知識庫問答、合同分析、論文問答、客服機器人、代碼庫問答、政策查詢、醫學資料檢索、產品文檔助手和私有數據問答中，是理解大語言模型落地應用的重要基礎概念。

一、基本概念：什么是 RAG

RAG 是一種“檢索 + 生成”的大語言模型應用方法。它的基本流程可以概括為：

用戶問題 → 檢索相關資料 → 放入上下文窗口 → 大語言模型生成答案

圖 1：RAG 工作流程總覽

例如，用戶問：

這份合同中關于違約責任是怎么規定的？

如果直接讓大語言模型回答，它可能不知道這份合同的具體內容。

RAG 的做法是：先從合同文檔中檢索與“違約責任”相關的段落，再把這些段落連同用戶問題一起交給模型，讓模型基于檢索到的內容回答。

從通俗角度看：RAG 像是給模型配了一個資料檢索助手。模型不是憑空回答，而是先翻資料，再根據資料整理答案。

RAG 中的三個關鍵詞是：

? Retrieval：檢索，找到與問題相關的資料

? Augmented：增強，把檢索內容作為額外上下文提供給模型

? Generation：生成，由模型組織語言并回答問題

因此，RAG 不是一個單獨的模型結構，而是一種把外部知識和大語言模型結合起來的應用框架。

二、為什么需要 RAG

RAG 之所以重要，是因為大語言模型雖然能力很強，但仍然有明顯邊界。

1、模型參數知識可能過時

大語言模型的知識主要來自訓練數據。

如果某些信息在模型訓練之后才出現，模型參數中通常沒有這些新信息。

例如：

? 最新政策

? 最新產品說明

? 最新公司制度

? 最新論文

? 最新業務數據

RAG 可以通過外部知識庫實時檢索，把新資料提供給模型。

2、模型不知道私有資料

企業內部文檔、合同、會議紀要、項目資料、客戶記錄通常不在模型訓練數據中。如果不把這些資料提供給模型，模型無法可靠回答相關問題。

RAG 可以連接企業知識庫，讓模型基于私有資料回答。

3、減少憑空編造

大語言模型可能在信息不足時生成看似合理但不真實的內容，這通常稱為幻覺。

RAG 通過提供檢索證據，可以讓模型更有依據地回答問題。

從通俗角度看：RAG 的價值不是讓模型“更會猜”，而是讓模型“有資料可查”。

4、突破上下文窗口限制

外部知識庫可能非常大，不可能全部放進上下文窗口。

RAG 的做法不是把整個知識庫塞給模型，而是根據問題只取回最相關的片段。這讓模型可以在有限上下文窗口內使用大規模外部知識。

三、RAG 的基本流程

RAG 的基本流程通常包括五步：

準備知識庫 → 切分文檔 → 向量化與索引 → 檢索相關片段 → 生成答案

圖 2：RAG 的知識準備流程

1、準備知識庫

知識庫可以來自多種來源，例如：

? PDF 文檔

? Word 文檔

? 網頁內容

? 產品手冊

? 合同文本

? 論文資料

? 數據庫記錄

? 代碼倉庫說明

這些資料需要先整理成可檢索文本。

從通俗角度看：知識庫就是 RAG 系統的“資料柜”。

2、切分文檔

長文檔通常不能直接作為一個整體檢索和放入上下文。因此，需要把文檔切分成較小片段。

例如：

完整文檔 → 片段 1 → 片段 2 → 片段 3 → ...

每個片段通常稱為 chunk。

chunk 的大小會影響檢索效果。

如果 chunk 太短，可能缺少上下文。

如果 chunk 太長，可能包含太多無關內容。

3、向量化與索引

為了讓系統能根據語義相似性檢索內容，通常會把每個文檔片段轉換成向量。這個過程稱為 embedding。

可以簡單表示為：

其中：

? chunk 表示文檔片段

? v 表示該片段的向量表示

然后，這些向量會被存入向量索引或向量數據庫中，便于快速檢索。

4、檢索相關片段

當用戶提出問題時，系統也會把問題轉換成向量：

其中：

? query 表示用戶問題

? q 表示問題向量

然后系統計算問題向量與文檔片段向量之間的相似度，選出最相關的若干片段。

常見相似度計算方式之一是：

其中：

? q 表示問題向量

? v 表示文檔片段向量

? q · v 表示點積

? ‖q‖ 和 ‖v‖ 表示向量長度

cosine(q, v) 越大，通常表示語義越相近。

5、生成答案

檢索到相關片段后，系統會把它們與用戶問題一起組織成提示詞，交給大語言模型生成答案。

可以概括為：

問題 + 相關片段 → 大語言模型 → 答案

從通俗角度看：檢索負責“找材料”，生成負責“組織表達”。

四、RAG 與上下文窗口的關系

RAG 與上下文窗口關系非常密切。上下文窗口是模型一次能夠看到的最大 token 范圍。

外部知識庫可能很大，但模型不能一次讀取全部內容。

因此，RAG 的核心做法是：只把當前問題最相關的內容放進上下文窗口。

可以簡單表示為：

大知識庫 → 檢索篩選 → 少量相關片段 → 上下文窗口 → 生成答案

從通俗角度看：上下文窗口像模型當前的工作臺，RAG 像從資料柜中挑出最相關文件放到工作臺上。

這意味著：

? RAG 不是把整個知識庫塞進模型

? RAG 依賴檢索質量

? 放入窗口的片段要足夠相關

? 片段數量不能無限增加

? 需要為模型輸出預留 token 空間

如果上下文窗口被無關片段占滿，模型可能反而更難回答。

因此，RAG 的關鍵不是“放得越多越好”，而是“放得越準越好”。

五、RAG 中的切分、Embedding 與向量檢索

RAG 的效果很大程度取決于文檔切分和檢索質量。

1、文檔切分

文檔切分的目標是把長文檔拆成適合檢索和放入上下文窗口的片段。

常見切分方式包括：

? 按固定長度切分

? 按段落切分

? 按標題層級切分

? 按語義結構切分

? 按代碼函數或類切分

例如，一份產品手冊可以按章節和小節切分。

一份代碼文檔可以按模塊、函數或類切分。

從通俗角度看：切分不是隨便剪開文本，而是盡量讓每個片段保持完整含義。

2、Embedding 表示

每個片段會被轉換成向量表示。

如果兩個片段語義相近，它們在向量空間中的距離通常更近。

例如：

“合同解除后的賠償責任”

這兩個片段雖然字面不同，但語義可能相關，向量檢索有機會把它們關聯起來。

3、向量檢索

向量檢索會根據用戶問題找到語義相近的文檔片段。

例如，用戶問：

離職后還能使用公司資料嗎？

系統可能檢索到：

? 保密義務條款

? 離職交接規定

? 數據安全制度

? 知識產權歸屬說明

這說明向量檢索不只是關鍵詞匹配，而是嘗試根據語義相關性找資料。

不過，向量檢索也不是萬能的。

如果問題表達模糊、文檔切分不合理、Embedding 模型不適配領域，檢索結果可能不準確。

六、RAG 的常見增強方式

基礎 RAG 流程比較簡單，但真實應用中通常需要增強檢索和生成質量。

1、關鍵詞檢索與向量檢索結合

向量檢索擅長語義相似，但有時會漏掉精確關鍵詞。

關鍵詞檢索擅長精確匹配，但不理解深層語義。

因此，實際系統中常使用混合檢索：

關鍵詞檢索 + 向量檢索 → 合并候選片段

例如，查詢合同條款編號、產品型號、函數名、法律條文時，關鍵詞檢索非常重要。

2、重排序

初步檢索可能返回很多候選片段。重排序會進一步判斷哪些片段最適合作為回答依據。

可以理解為：

? 粗檢索：先找一批可能相關的片段

? 重排序：再挑出最相關的片段

從通俗角度看：檢索像“海選”，重排序像“復篩”。

3、查詢改寫

用戶問題有時比較口語化、模糊或缺少關鍵詞。

查詢改寫會把用戶問題改寫成更適合檢索的形式。

例如：

用戶問題：這個能退嗎？

改寫后：產品退貨條件、退款規則、售后政策

這有助于檢索系統找到更相關資料。

4、引用來源

為了提高可信度，RAG 系統通常會在答案中附上來源片段、文檔標題或頁碼。這可以讓用戶檢查答案依據。

從實踐角度看，RAG 最好不僅給答案，還要給證據。

七、RAG 與微調的區別

RAG 經常和微調一起被比較。二者都可以讓模型更適合特定任務，但方式不同。

圖 3：RAG 與微調的區別

1、RAG：把知識放在外部

RAG 不一定改變模型參數。

它通過檢索外部資料，把相關內容放入上下文窗口，讓模型基于這些內容回答。

從通俗角度看：RAG 是讓模型“開卷考試”。

它適合：

? 知識經常變化

? 文檔很多

? 需要可追溯來源

? 企業私有知識問答

? 不希望頻繁訓練模型

2、微調：把能力寫進參數

微調會繼續訓練模型參數，讓模型更適合某類任務、語氣、格式或領域表達。

從通俗角度看：微調是讓模型“專項訓練”。

它適合：

? 固定輸出格式

? 特定任務風格

? 專業表達習慣

? 分類、抽取等穩定任務

? 想讓模型內化某種行為模式

3、二者可以結合

RAG 和微調不是互斥關系。

很多系統會同時使用：

? 微調：讓模型更會按要求回答

? RAG：讓模型回答時有最新資料依據

從通俗角度看：微調提升模型“答題方式”，RAG 提供“答題資料”。

如果問題是“模型不知道某份新文檔內容”，通常優先考慮 RAG。

如果問題是“模型不會按固定格式輸出”，可以考慮微調或提示詞工程。

八、RAG 的優勢、局限與使用注意事項

1、RAG 的主要優勢

RAG 最大的優勢是可以利用外部知識。

它讓模型不必只依賴訓練時記住的知識，而可以基于當前檢索到的資料回答。

其次，RAG 適合知識更新。

文檔更新后，只要更新索引或知識庫，模型就可以檢索到新內容。

再次，RAG 便于溯源。

答案可以附帶來源片段，讓用戶知道結論來自哪里。

從通俗角度看，RAG 的優勢在于：它讓大語言模型從“閉卷回答”變成“帶資料回答”。

2、RAG 的主要局限

RAG 也有局限。

首先，檢索錯了，答案就容易錯。

如果相關片段沒有被檢索到，模型可能無法正確回答。

其次，檢索到了不等于模型一定用得好。

如果上下文很長、片段沖突或信息組織混亂，模型仍可能誤解。

再次，RAG 對文檔質量依賴很強。

如果原始文檔過時、錯誤、重復或結構混亂，系統回答也會受到影響。

此外，RAG 不等于完全消除幻覺。

它可以降低幻覺風險，但不能保證模型永遠忠實引用資料。

3、使用 RAG 時需要注意的問題

使用 RAG 時，需要注意：

? 文檔切分要盡量保持語義完整

? 檢索結果要與問題高度相關

? chunk 過短會丟上下文，過長會引入噪聲

? 關鍵詞檢索和向量檢索可以結合使用

? 重要場景應提供引用來源

? 文檔更新后要同步更新索引

? 對沖突資料要提示不確定性

? 不要把整個知識庫直接塞進上下文窗口

? 需要讓模型明確“基于資料回答，不要編造”

從實踐角度看，RAG 的質量取決于整個鏈路，而不僅僅取決于大語言模型本身。

九、Python 示例

下面給出一個極簡 RAG 思路示例，用來幫助理解它的基本流程。

示例 1：用關鍵詞模擬簡單檢索

這個例子只是演示：

用戶問題 → 找相關文檔片段

真實 RAG 系統通常不會只靠簡單關鍵詞，而會使用 embedding、向量數據庫和重排序等方法。

示例 2：模擬把檢索結果放入提示詞

這個例子展示了 RAG 中常見的提示詞組織方式：

檢索資料 + 用戶問題 + 回答要求

其中，“只根據資料回答”可以降低模型憑空發揮的風險。

示例 3：模擬向量檢索的流程

下面示例只展示流程，不實現真實 embedding 模型。

真實 RAG 系統中：

? embed(query) 會生成問題向量

? embed(chunk) 會生成片段向量

? 系統會從大量片段中快速找出相似度最高的內容

? 通常還會加入重排序、過濾和引用來源

示例 4：在 token 預算內選擇片段

這個例子說明：RAG 需要在有限上下文窗口中選擇片段。并不是檢索到的內容都要放進去，而是優先放入相關性高、信息密度高的片段。

小結

RAG 是“檢索增強生成”的方法，它讓大語言模型先從外部知識庫中檢索相關資料，再基于這些資料生成答案。它適合企業知識庫問答、長文檔分析、私有資料查詢和需要可追溯來源的場景。對初學者而言，可以把 RAG 理解為：讓模型從“閉卷答題”變成“先查資料再答題”。

“點贊有美意，贊賞是鼓勵”