什麼是 RAG 架構?完整定義與詳細實務範例

RAG 架構是負責儲存、檢索外部資訊並將其提供給 LLM 的一組元件;本指南將詳細解說 10 種類型,從基本 RAG、混合式 RAG 到代理式 RAG 與 GraphRAG,並提供兩個逐步範例。

Diagram of the types of RAG architecture branching from a central hub: basic, hybrid, adaptive, corrective (CRAG), self-RAG, multimodal, agentic, GraphRAG, HyDE, and branched.

RAG 即檢索增強生成(retrieval augmented generation),是 LLM 運用外部資訊來擴充並改善輸出內容的過程。RAG 架構則是實現 RAG 所需的一組元件與連結。

RAG 可分為數種不同類別,每一種都採用各自獨特的架構。從本質上來說,RAG 系統的架構決定了資訊以何種獨特方式被儲存、檢索並提供給 LLM。

什麼是 RAG 架構?

RAG 架構是驅動特定 RAG 系統運作的底層元件配置(以及這些元件的相關功能)。所有這類架構都建立在一個基礎範本之上,這個範本通常被稱為「簡易」或「單純」RAG。

以下是基礎 RAG 架構的概要說明:

  • 資訊來源:這是儲存外部資訊的地方,可能是搜尋索引、代表大量資訊的向量資料庫,或是原始文件儲存庫。
  • 檢索元件:這是用來查詢資訊來源的機制。舉例來說,RAG 系統可能會使用簡單的關鍵字搜尋來找出相關的文字區塊,或使用較複雜的向量查詢來執行相似度搜尋。
  • 協調元件:這一層是以 LLM 為基礎的應用程式中,負責針對使用者提示詞啟動 RAG 管線的部分,可與 LLM 協同運作,也可獨立運作。它也會將檢索到的資訊彙整成擴充後的提示詞。

RAG 架構元件通常分為兩條路徑。匯入路徑會接收資料,並將其整理成可供搜尋的資訊來源。向量資料庫是最廣泛使用的應用之一,它會將大量文字轉換成可搜尋的向量嵌入儲存庫。

檢索路徑會接收使用者的提示詞,並產生用於搜尋資訊來源的查詢。接著,協調器會將檢索到的資訊加入 LLM 的上下文輸入中。在代理式與混合式 RAG 架構中,可能會有多條檢索路徑。

RAG 架構的類型

將 RAG 視為一個個截然不同的架構,其實容易造成誤解。大多數工程師會採用模組化方法,依據特定使用情境實作個別元件。雖然可以大致劃出界線,但必須注意的是,各種架構模型之間有相當大的重疊。

1. 基本 RAG

基本 RAG 又稱為「單純」或「簡易」RAG,是其他類型 RAG 的架構範本。

其底層流程相對簡單:使用者輸入提示詞後,協調器會判斷是否需要外部資訊(可獨立判斷,或與 LLM 協同判斷),並據此擬定並送出檢索查詢。

外部資訊來源通常是向量資料庫,但也可能是 SQL 資料庫、Web API、知識圖譜,甚至是「原始」文件儲存庫。這些額外資訊接著會被加入 LLM 的輸入上下文中。

除了 SQL 查詢和 API 之外,檢索方法大致可分為兩種類型:

  • 詞彙搜尋(關鍵字搜尋):這是一種簡單的 RAG 形式,會從使用者查詢中擷取關鍵字,再與包含這些關鍵字的文字段落進行比對。在現代管線中,協調器可能會透過所謂的稀疏向量查詢來完成這項工作,但這種查詢無法捕捉語意。
  • 密集向量搜尋(語意搜尋):密集向量嵌入能夠捕捉語意。協調器查詢密集向量資料庫時,可以同時捕捉使用者提示詞與來源資訊的語意。

記憶的運用也是 RAG 架構的重要一環。它指的是 LLM 如何利用先前對話中的上下文來建構檢索查詢,使查詢立基於整段討論(或多段討論)的更廣泛脈絡中。大多數聊天機器人都以對話式 RAG 為標準做法,不過某些使用情境(例如回覆支援工單)可能會採用單一問題 RAG。

2. 混合式 RAG

混合式 RAG 結合兩種不同類型的檢索,通常是關鍵字檢索與語意檢索。關鍵字搜尋會找出相符的詞彙,而向量搜尋則會找出意義相關的段落。

也可能會使用其他形式的檢索,例如知識圖譜遍歷或 SQL 資料庫查詢。這個流程通常由路由邏輯引導,形式可能是預先編寫的規則,或由模型對問題進行分類(不過也可以同時執行多條管線)。

協調器會合併結果,並可能先重新排序,再將結果傳給 LLM。重新排序是為檢索到的文字區塊指派相關性分數的過程,讓 LLM 優先採用最適用的資訊。

3. 自適應 RAG

在自適應 RAG 中,路由元件會根據使用者提示詞的需求選擇檢索策略,接著由協調器執行所選的工作流程。

在原始框架(Adaptive-RAG)中,會由較小型的模型擔任分類器,在不檢索、單步驟檢索或多步驟檢索之間做出選擇。現在有些架構則改用生成式模型或規則式啟發法。

這是一種熱門架構,因為它會根據提示詞的複雜度與需求分配運算資源,減少簡單提示詞中不必要的檢索步驟。這種架構常見於需要處理多種問題類型的助理。

4. 修正式 RAG(CRAG)

修正式 RAG 會先評估檢索到的資訊,再將其加入 LLM 的上下文輸入。檢索評估器會評估檢索到的資訊是否相關且實用。其獨特的架構特色在於,在生成答案之前設有明確的「評估與修正」階段。

如果發現資訊不完整或與提示詞無關,就會觸發額外的請求。這些請求可能會採用與原始請求不同的檢索方法,例如網路搜尋或知識圖譜遍歷。

修正式 RAG 常見於醫學和法律等重視準確性的領域。不過,它需要額外的資訊來源,以補充原先檢索到的段落。

5. Self-RAG

在 Self-RAG 中,模型可在收到初始上下文輸入後自行發起請求。系統會使用反思 token,根據檢索到的證據評估生成的答案,並視需要透過協調器送出進一步的請求。反之,LLM 也可能判斷完全不需要檢索。

它與修正式 RAG 的不同之處在於,LLM 會評斷自己的輸出、判斷是否需要檢索以及檢索到的文字是否有用,並監控自己的答案,視需要加以修改。相較之下,修正式 RAG 則是在生成之前評估檢索資訊的品質。

這種架構特別適合複雜的深入研究型提示詞。由於它將(對檢索資訊的)相關性評估整合到答案生成中,因此很適合需要以證據為基礎進行回應的提示詞。

6. 代理式 RAG

代理式 RAG 是指在 AI 代理程式平台中執行的任何形式 RAG。模型會運用其推理能力判斷所需的資訊類型,並從可用的檢索選項中做出選擇。

檢索可視需要多次觸發,而且模型可以選擇為較複雜的查詢指派 AI 代理程式。舉例來說,LLM 可以要求查詢資料庫以找出供應商,觸發文件搜尋以找到相關合約,最後再進行網路搜尋,透過公開來源驗證聯絡資訊。

代理式 RAG 是 Perplexity、ChatGPT、Claude 等主流聊天機器人主要採用的架構實作。由於這些平台讓核心模型能夠使用多種工具與 RAG 管線,模型可以選擇最適合特定提示詞的檢索形式。

7. 多模態 RAG

多模態 RAG 能跨不同類型的媒體檢索上下文。這是一種重要的 RAG 形式,因為它讓 LLM 能夠取用圖表和錄音等原本無法存取的資訊。

其底層架構與其他系統相同。舉例來說,索引管線可能會將圖片直接轉換為嵌入,以便供搜尋使用。接著,代理式 RAG 系統可以將這些圖片連同語意相關的文字一併檢索,並提供給視覺語言模型進行雙重處理。

8. GraphRAG

GraphRAG 會搭配向量搜尋使用知識圖譜,以檢索與實體相關的資訊。通常,協調器會使用關鍵字擷取(有時則是初步的向量搜尋)找出相關的起始實體,也就是所謂的節點。接著,圖譜檢索器會遍歷知識圖譜,以建構更廣泛的上下文。

舉例來說,當使用者要求詳細分析某個產品類別時,LLM 可能會觸發向量搜尋來識別特定實體(產品)。接著,協調器會觸發知識圖譜搜尋,找出供應商、零售據點、評論等相關實體。

9. 分支式 RAG

混合式 RAG 架構能夠使用不同的檢索方法,而分支式 RAG 則是指同時執行多個查詢(稱為分支)的過程。每個分支可以查詢不同的資訊來源,也可以讓多個分支以不同的查詢或篩選條件同時查詢相同的來源。代理式 RAG 架構經常會使用分支式 RAG。

10. HyDE(假設性文件嵌入)

HyDE 是一種創新的 RAG 形式,由 LLM 建立一份假設性的文字文件,描述理想答案可能的樣貌。這份「假設性文件」接著會被用來建立查詢,以提升檢索的準確度。雖然 LLM 參數中並未包含相關知識,但其背後的理念是,類似答案的段落可能比簡短問題或模稜兩可的提示詞更能比對到相關文件。

簡易 RAG 架構範例:向量資料庫

基本 RAG 是更複雜架構類型的基礎。以使用向量資料庫的簡易 RAG 系統為例,來源文件會被切分成較小的片段(文字區塊),並轉換成密集嵌入。使用者輸入提示詞時,協調器會產生查詢、將其編碼,然後查詢資料庫以找出相關段落。

以下逐步說明整個流程:

  1. 使用自動化匯入管線與 BERT 等嵌入模型,將大量文字轉換為向量。
  2. 資料庫應用程式會整理向量、建立索引並加以儲存,以便快速搜尋。
  3. 使用者在聊天機器人(例如 Perplexity)中輸入提示詞。
  4. 應用程式協調器會(使用嵌入模型)將提示詞編碼,以從向量資料庫檢索相關資訊。
  5. 向量資料庫傳回相關的文字區塊,協調器將其加入輸入上下文(即「大型提示詞」),再提供給 LLM。
  6. LLM 運用這些額外的上下文,並結合其內部知識(儲存在參數權重中)來生成答案。

進階 RAG 架構範例:代理式 RAG

代理式 RAG 是指 AI 代理程式平台中 RAG 系統的底層架構。代理式 RAG 流程往往較為複雜,因為 AI 代理程式可以根據提示詞的性質呼叫不同的工具與管線,必要時還會部署多個 AI 代理程式。

以下是這個流程的實際範例:

  1. 使用者輸入一個需要針對某個主題進行深入研究的複雜問題。在這個範例中,假設提示詞是「考量重大地緣政治動態,預測公司未來六個月的獲利。」
  2. LLM 經推理後判斷,需要結合跨越不同內容類型的多種 RAG 查詢。
  3. 部署三個不同的 AI 代理程式,分別負責 (a) 向量搜尋、(b) 網路資料佐證,以及 (c) 圖片(多模態)搜尋。
  4. 這些 AI 代理程式會透過協調器,使用可用的檢索工具搜尋新聞報導和內部財務資料等相關資訊。
  5. LLM 會將檢索結果與每個 AI 代理程式的研究問題進行比較,並依相關性加以排序。
  6. LLM 會評估這些資訊,並在資訊不足之處,透過個別 AI 代理程式觸發額外的搜尋。
  7. 檢索到足夠的資訊後,LLM 會根據現有的財務數據(從內部文件中檢索而來)產生各種情境預測,並呼叫計算機工具來推估每種情境的獲利。
  8. LLM 運用檢索到的資訊與計算結果產生最終答案,並視需要引用來源。

RAG 的下一步是什麼?

目前的創新重點在於提升現有 RAG 架構的深度與速度、改善多媒體檢索的準確度,以及打造能夠處理即時最新資訊的系統。

以下是目前正在形塑研究方向的三大趨勢:

  • 跨多個來源的深入研究:這種 RAG 架構能夠規劃搜尋、在不同來源間執行多個分支、評估檢索到的證據,並自我最佳化生成的答案。能夠執行上述所有任務的代理式 RAG 正持續變得更快速、更具成本效益。
  • 多模態應用:檢索管線處理圖片和影片的能力越來越好,也越來越能在長篇影片和進階圖表等複雜的多模態資料中,精準找出特定類型的資訊。
  • 讓答案立基於持續變化的資訊:LLM 應用程式可以運用即時資訊來源(例如影像串流和感測器)來提供輸入上下文。系統也可以產生多面向的資訊網路(例如透過 GraphRAG)來解讀這些資料。

RAG 是 LLM 應用程式運作的基礎。它讓各式各樣的使用者,從一般消費者到在專業領域工作的企業,都能克服幻覺、訓練資料不完整,以及無法取得專業內部知識等問題。

正因如此,RAG 系統及其底層架構是 AI 研究中發展最快速、也最令人興奮的領域之一。