甚麼是 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 數據庫、網絡 API、知識圖譜,甚至是「原始」文件庫。這些額外資訊隨後會被加入 LLM 的輸入上下文中。

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

  • 詞彙搜尋(關鍵字搜尋):這是一種簡單的 RAG 形式,會從用戶查詢中擷取關鍵字,再與包含這些關鍵字的文字段落進行配對。在現代管道中,編排器可能會透過所謂的稀疏向量查詢來完成這項工作,但這種查詢並不會捕捉語意。
  • 稠密向量搜尋(語意搜尋):稠密向量嵌入能夠捕捉語意。編排器查詢稠密向量數據庫時,可以同時捕捉用戶提示和來源資訊的含義。

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

2. 混合式

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

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

編排器會合併結果,並可能在傳送給 LLM 之前將其重新排序。重新排序是為檢索到的區塊評定相關性分數的過程,讓 LLM 優先處理最適用的資訊。

3. 自適應 RAG

在自適應 RAG 中,路由組件會根據用戶提示的要求選擇檢索策略,然後由編排器執行所選的工作流程。

在原始框架(Adaptive-RAG)中,會由一個較小的模型充當分類器,在不檢索、單步檢索或多步檢索之間作出選擇。現時有些架構則改用生成式模型或基於規則的啟發式方法。

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

4. 糾正式 RAG(CRAG)

糾正式 RAG 會先評估檢索到的資訊,然後才將其加入 LLM 的上下文輸入。檢索評估器會判斷檢索到的資訊是否相關且有用。其獨特的架構特點,是在生成答案之前設有明確的「評估及糾正」階段。

如果發現資訊不完整或不適用於該提示,系統便會觸發額外請求。這些請求可能會採用有別於原始請求的檢索方法,例如網絡搜尋或知識圖譜遍歷。

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

5. 自我反思 RAG(Self-RAG)

在 Self-RAG 中,模型可以在接收初始上下文輸入後發起請求。系統會使用反思標記(reflection tokens),根據檢索到的證據評估所生成的答案,並在有需要時透過編排器發送進一步的請求。反之,LLM 亦可能判斷完全不需要檢索。

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

這種架構特別適合複雜的深入研究式提示。由於它將(對檢索資訊的)相關性評估融入答案生成過程,因此非常適合需要以證據為本作答的提示。

6. 代理式 RAG

代理式 RAG 是指在代理式平台環境中執行的任何形式的 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(假設性文件嵌入,Hypothetical Document Embeddings)

HyDE 是一種創新的 RAG 形式:LLM 會先撰寫一份假設性的文字文件,描述理想答案可能的樣子,然後利用這份「假設性文件」建立查詢,以實現更準確的檢索。雖然相關知識並未體現在 LLM 參數中,但其理據在於,與簡短問題或含糊的提示相比,類似答案的段落可能更能配對到相關文件。

簡單 RAG 架構示例:向量數據庫

基本 RAG 是更複雜架構類型的基礎。以使用向量數據庫的簡單 RAG 系統為例,來源文件會被分割成較小的片段(區塊),並轉換成稠密嵌入。當用戶輸入提示時,編排器會生成查詢並將其編碼,然後查詢數據庫以找出相關段落。

以下是整個過程的逐步拆解:

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

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

代理式 RAG 是指代理式平台內 RAG 系統的底層架構。代理式 RAG 流程往往較為複雜,因為 AI 代理程式可以根據提示的性質調用不同的工具和管道,並在有需要時部署多個 AI 代理程式。

以下是該過程的實際例子:

  1. 用戶輸入一個需要對某個主題進行深入研究的複雜問題。在這個例子中,假設提示是「根據重大地緣政治動態,預測公司未來六個月的盈利。」
  2. LLM 推斷需要結合多種跨越不同內容類型的 RAG 查詢。
  3. 系統部署了三個不同的 AI 代理程式,分別負責 (a) 向量搜尋、(b) 網絡資料佐證(web grounding),以及 (c) 圖像(多模態)搜尋。
  4. 這些 AI 代理程式會透過編排器,使用可用的檢索工具搜尋相關資訊,例如新聞報道和內部財務數據。
  5. LLM 會將檢索結果與每個 AI 代理程式的研究問題進行比對,並按相關性排序。
  6. LLM 會評估這些資訊,並在資訊有所欠缺時,透過個別 AI 代理程式觸發額外搜尋。
  7. 檢索到足夠資訊後,LLM 會根據現有的財務數字(從內部文件中檢索所得)生成多個情境預測,並調用計算機工具推算每個情境的盈利。
  8. LLM 會利用檢索到的資訊和計算結果生成最終答案,並在有需要時引用來源。

RAG 的下一步是甚麼?

目前的創新主要集中於提升現有 RAG 架構的深度和速度、改善多媒體檢索的準確性,以及建構專為處理即時最新資訊而設計的系統。

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

  • 跨多個來源的深入研究:這是一種能夠規劃搜尋、在不同來源之間執行多個分支、評估檢索到的證據,並自我優化所生成答案的 RAG 架構。能夠執行所有這些任務的代理式 RAG 正變得越來越快,也越來越具成本效益。
  • 多模態應用:檢索管道處理圖像和影片的能力日益提升,越來越能夠在複雜的多模態數據(例如長篇影片和進階圖表)中精準定位特定類型的資訊。
  • 以持續變化的資訊作為答案依據:基於 LLM 的應用程式可以利用即時資訊來源(例如影像串流和感應器)來提供輸入上下文。系統亦可以生成多層面的資訊網絡(例如透過 GraphRAG),以解讀這些數據。

RAG 是基於 LLM 的應用程式賴以運作的根本。它讓各類用戶(從一般消費者到專業領域的企業)都能克服幻覺、訓練數據不完整,以及無法取得專業內部知識等問題。

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