RAG 不只一種：一次看懂 16 種 RAG 架構與應用場景
談到生成式 AI，RAG（Retrieval-Augmented Generation，檢索增強生成）已經成為企業導入大型語言模型時的重要技術。它的核心概念並不複雜：在大型語言模型回答問題之前，先從外部資料來源檢索相關資訊，再將找到的內容與使用者問題一起交給模型生成答案。
這種「先找資料，再回答問題」的設計，可以補足大型語言模型知識過時、無法掌握企業內部資訊，以及容易產生幻覺等缺點。不過，RAG 並不是一套固定不變的架構。隨著資料型態、任務複雜度、即時性、隱私、產業規範與系統規模不同，RAG 已逐漸發展成一系列可以組合使用的設計模式。
本文整理 16 種常見的 RAG 類型，說明它們的核心機制、主要價值、適用情境與導入時應注意的問題。
需要先說明的是，這 16 種類型並不是業界統一認證的正式分類標準。其中有些屬於技術架構，有些是檢索策略，有些則是應用情境。實務上，它們通常不是互斥選項，而是可以疊加組合。
一、Standard RAG：最基礎的檢索增強生成
Standard RAG，也就是標準 RAG，是大多數企業建立知識庫問答系統時的起點。其基本流程是將文件切割成多個段落，轉換為向量後存入向量資料庫。當使用者提出問題時，系統先找出語意最相近的文件片段，再將這些內容交給大型語言模型產生答案。
早期 RAG 論文曾提出 RAG-Sequence 與 RAG-Token 等生成方式，但現代企業系統所稱的 Standard RAG，通常泛指單次查詢、單次檢索與單次生成的基本架構。
這種方式的優點是實作相對簡單，能快速建立概念驗證版本，也能讓模型回答企業內部文件、產品手冊、FAQ 或制度規章等問題。常見工具包括 Hugging Face Transformers、LangChain、LlamaIndex及各種向量資料庫。
不過，標準 RAG 對複雜問題的處理能力有限。如果問題需要多次查詢、跨文件推理、工具操作或權限判斷，單次檢索通常不足以產生可靠答案。
二、Agentic RAG：讓 AI 主動決定下一步
Agentic RAG 在傳統 RAG 之上加入 AI Agent 的自主決策能力。系統不再只是收到問題後直接搜尋，而是先分析使用者的意圖，再決定是否需要檢索資料、使用哪一個資料來源、呼叫哪些工具，以及是否需要進一步查證。
例如，使用者詢問某份維護合約今年應開立多少發票時，Agentic RAG 可以先查找合約文件，再擷取金額、履約期間與付款條件，接著呼叫計算工具完成分期與稅額計算，最後將結果整理成表格。如果資料不足，它還可以主動要求使用者補充。
Agentic RAG 適合研究助理、企業工作助理、進階客服、合約處理、財務分析及跨系統工作流程。不過，它的成本、延遲與系統風險也高於標準 RAG，因此必須加入工具權限、操作稽核、流程限制及人工覆核機制。
三、Graph RAG：從文件片段進一步理解知識關係
傳統向量檢索擅長找出語意相似的內容，卻不一定能掌握人物、組織、產品、事件與文件之間的關係。Graph RAG 透過知識圖譜建立實體與關聯，讓系統不只知道「哪些內容相似」，也能理解「哪些事物彼此有關」。
例如，在醫療情境中，可以建立病人、診斷、藥物、檢驗、手術與時間之間的關係；在合約管理中，則可以連結客戶、專案、合約、服務項目、付款期程與負責部門。
Graph RAG 特別適合法律、醫療、製造、工程與組織知識管理等關係複雜的領域。常見技術包括 Neo4j、Stardog、Apache Jena，以及結合知識圖譜與大型語言模型的 Graph RAG 框架。
它的主要挑戰是建置成本較高。實體抽取、關係定義、資料更新及圖譜治理都需要持續維護，並不是導入圖形資料庫就能自然獲得正確推理能力。
四、Modular RAG：將 RAG 拆成可替換的模組
Modular RAG 將文件解析、資料清洗、分段、索引、查詢改寫、檢索、重新排序、權限過濾、生成與結果驗證拆成不同模組。每個模組可以獨立調整或替換，不必將整套系統綁死在單一框架上。
這種設計適合大型企業、多人協作或需要長期演進的產品。例如，企業可以先使用一般向量模型，未來再替換成適合繁體中文或特定產業的模型；也可以針對不同資料來源使用不同解析流程。
微服務、Docker、Kubernetes與事件訊息平台可以支援模組化架構，但它們只是工程工具，並不等於 Modular RAG 本身。真正的重點在於介面標準化、模組邊界與可替換性。
模組化能提高擴充性，但也會增加部署、監控、版本管理與系統整合的複雜度。因此，小型概念驗證不一定需要一開始就採用完整微服務架構。
五、Memory-Augmented RAG：讓系統記得過去
Memory-Augmented RAG 加入外部記憶機制，使系統可以保存並檢索過去的對話、使用者偏好、任務狀態或重要決策。
記憶通常可以分成短期記憶與長期記憶。短期記憶用來維持目前對話的連續性；長期記憶則可能保存使用者習慣、過去專案、常用格式與重要背景資訊。
這種架構適合個人助理、客戶服務、長期專案協作與個人化推薦。常見儲存方式包括 Redis、關聯式資料庫、文件資料庫與向量資料庫。
但記憶不是保存得越多越好。系統必須處理資料過期、錯誤記憶、敏感資訊、使用者同意與刪除權等問題。如果沒有記憶治理，錯誤內容可能反覆影響後續回答。
六、Multi-Modal RAG：讓檢索不再侷限於文字
Multi-Modal RAG 將檢索範圍從文字擴展到圖片、音訊、影片、表格、工程圖與醫療影像。系統可以同時理解不同形式的資料，再將它們組合成回答。
例如，在工程審圖情境中，系統可以同時讀取二維 PDF 圖面、零件圖片與 Feature Graph JSON；在會議管理中，也可以結合錄音逐字稿、簡報與附件；在醫療領域，則可能同時參考影像、報告與結構化檢驗資料。
Multi-Modal RAG 適合影片摘要、圖像描述、文件審查、教育、製造與醫療應用。相關技術包括 CLIP、多模態嵌入模型、OCR、語音辨識與視覺語言模型。
其難點在於不同模態之間的對齊。單純將圖片轉成文字並不代表真正理解圖片，表格、座標、版面與物件關係也可能在轉換過程中遺失。
七、Federated RAG：從分散資料來源取得資訊
Federated RAG 的重點是資料不必全部集中到同一個知識庫。系統可以向不同部門、不同組織、不同地區或不同權限域的資料來源提出查詢，再將結果整合起來。
這種架構適合醫療、金融、政府與跨組織協作場景，尤其適用於資料不能任意搬移或集中儲存的環境。
不過，Federated RAG 不應直接等同於 Federated Learning。前者主要處理分散式檢索與答案整合，後者則著重於模型在不集中原始資料的情況下進行訓練。兩者可以搭配，但並不是同一種技術。
Federated RAG 的真正挑戰包括跨來源身分驗證、權限控管、資料格式一致性、延遲、結果去重、可信度排序及稽核追蹤。
八、Streaming RAG：讓最新資料即時進入回答
Streaming RAG 適合資料持續變動，而且答案必須反映最新狀態的場景。它會持續接收並處理即時事件，讓系統能夠檢索最新資訊。
常見應用包括金融行情、資安事件、設備監控、新聞追蹤、客服工單與社群媒體分析。Apache Kafka、Amazon Kinesis與 Spark Streaming 可以協助建立資料串流管線。
但 Streaming RAG 不只是資料進得快。企業還必須處理索引更新延遲、重複事件、事件順序、時間有效性與舊資料失效等問題。否則，系統可能同時檢索到互相矛盾的新舊資訊。
九、ODQA RAG：面向開放領域的問答系統
ODQA 是 Open-Domain Question Answering 的縮寫，代表系統需要回答跨領域、範圍廣泛的問題。它的資料來源可能包括搜尋引擎、百科資料、新聞、公開網站與大型文件庫。
這類系統重視廣泛覆蓋能力與動態檢索，適合通用搜尋、研究輔助與虛擬助理。Elasticsearch、Haystack、Hugging Face Transformers及搜尋 API 都可以成為實作的一部分。
相較於企業內部 RAG，ODQA 更難控制來源品質。系統需要處理網站可信度、資訊時效性、來源衝突、惡意內容與引用追蹤，否則即使成功找到資料，也不代表答案可靠。
十、Contextual Retrieval RAG：根據情境重新理解問題
Contextual Retrieval RAG 會參考對話歷史、使用者角色、目前任務與既有條件，重新理解使用者的問題，再執行檢索。
例如，使用者接著詢問「那第二年的金額呢？」如果系統只搜尋這句話，幾乎不可能找到正確答案。情境檢索會先將問題改寫成「某份兩年期維護合約第二年度應開立的發票金額」，再進行搜尋。
這種方式適合對話式 AI、客服機器人與長流程工作助理。它與 Memory-Augmented RAG 有關，但兩者重點不同：記憶增強著重保存過去資訊，情境檢索則著重利用目前脈絡改善查詢。
風險在於錯誤脈絡可能污染檢索。如果系統誤解「那份合約」指的是哪一份文件，後續回答即使計算正確，也會建立在錯誤對象之上。
十一、Knowledge-Enhanced RAG：結合結構化知識
Knowledge-Enhanced RAG 將一般文件檢索與結構化知識來源整合，例如知識圖譜、主資料、詞彙表、本體模型、規則庫或企業資料庫。
它能讓模型在回答問題時，同時參考非結構化文件與明確定義的知識。例如，醫療系統可以透過本體模型理解疾病、藥物與檢驗項目的分類；工程系統則可整合材料規格、公差標準與零件關係。
這種方法能提高事實準確性與領域一致性，適合法律、醫療、教育與製造等專業場景。常見技術包括 OWL、Apache Jena、知識圖譜與各類 Embedding 工具。
Knowledge-Enhanced RAG 和 Graph RAG 有部分重疊，但前者範圍更廣，不一定要使用圖形資料庫，也可以整合結構化資料表、規則或領域詞彙。
十二、Domain-Specific RAG：針對特定產業深度設計
Domain-Specific RAG 是針對特定領域建立的 RAG 系統。它不只是更換資料來源，而是從文件解析、術語、分段方式、Embedding、查詢策略、提示詞、驗證規則到輸出格式，都依照產業需求設計。
例如，醫療 RAG 必須處理縮寫、診斷代碼、時間軸與資料隱私；法律 RAG 必須辨識條文層級、版本效力與管轄區域；工程 RAG 則可能涉及 BOM、尺寸、公差、材料與圖面版本。
這類系統具有較高的相關性與可信度，也更容易符合產業規範。然而，導入成本通常高於通用型 RAG，並需要領域專家參與資料治理、測試與驗收。
十三、Hybrid RAG：結合關鍵字與語意檢索
Hybrid RAG 將多種檢索方法結合起來，最常見的是全文關鍵字檢索與向量語意檢索。
向量檢索擅長找到語意相近的內容，但對產品代碼、合約編號、醫療代碼與精確名稱不一定敏感；關鍵字檢索擅長精確匹配，卻可能找不到使用不同說法表達的相同概念。兩者結合後，可以兼顧精確度與召回率。
實作時通常還會加入 Metadata Filter 與 Reranker，先依權限、日期、部門及文件類型縮小範圍，再重新排序檢索結果。
Hybrid RAG 是企業知識庫中非常實用的選擇。Elasticsearch、OpenSearch及支援混合搜尋的向量資料庫都可以使用。它的難點在於如何調整不同檢索分數的權重，而不是單純把兩組結果合併。
十四、Self-RAG：讓模型檢查自己的回答
Self-RAG 在回答流程中加入自我反思與品質判斷。模型會評估是否需要檢索、找到的內容是否足以支持回答、答案是否符合來源，以及是否需要重新搜尋或修正。
這種架構可以改善答案的事實性與連貫性，適合教育、研究、內容生成與高準確度問答。
不過，模型的自我檢查不等於客觀驗證。模型可能對錯誤答案表現得非常有信心，因此高風險場景仍需搭配規則驗證、來源引用、第二模型檢查或人工覆核。
此外，Fine-tuning 與 Human-in-the-Loop 可以協助實作 Self-RAG，但它們並不是 Self-RAG 的必要條件或專屬工具。
十五、HyDE RAG：先假設答案可能長什麼樣子
HyDE 是 Hypothetical Document Embeddings 的縮寫。它的做法是先根據使用者問題產生一段「假設性文件」或可能的答案，再將這段內容轉換成向量，用來搜尋真正的相關文件。
它適合處理問題描述過短、用詞與文件差異很大，或隱含語意較強的查詢。因為假設性文件通常包含較完整的領域詞彙，所以有機會找到原始問題直接搜尋時無法命中的內容。
HyDE 可以提高召回率，但也可能受到假設內容誤導。如果模型一開始做出錯誤假設，檢索方向就可能偏離。因此，實務上通常會將原始查詢與 HyDE 查詢並行使用，再合併及重新排序結果。
十六、Recursive／Multi-Step RAG：將複雜問題拆成多次檢索
Recursive RAG 或 Multi-Step RAG 適合無法透過一次搜尋回答的問題。系統會將複雜問題拆成數個子問題，根據前一步取得的資訊決定下一步要搜尋什麼，最後再整合所有證據。
例如，要回答「哪些跨年度維護合約尚未完成請款，而且負責專案已有未結工單」，系統可能先搜尋合約與請款狀態，再查詢專案負責人，接著取得工單資料，最後才產生完整答案。
這種架構能處理比較、歸納、因果分析與跨資料來源推理。不過，多步驟流程也會累積錯誤，任何一步理解錯誤，都可能影響後續結果。因此，系統需要保留每一步的查詢、證據與判斷依據。
這 16 種 RAG 可以如何分類？
若從設計目的來看，這些 RAG 類型大致可以分成五個方向。
第一類是基礎檢索架構，包括 Standard RAG 與 ODQA RAG，適合建立基本問答與搜尋能力。
第二類是互動與自主性強化，包括 Agentic RAG、Contextual Retrieval RAG、Memory-Augmented RAG 與 Self-RAG，主要解決任務決策、對話連續性、個人化及答案檢查問題。
第三類是知識與推理強化，包括 Graph RAG、Knowledge-Enhanced RAG、HyDE RAG，以及 Recursive／Multi-Step RAG，重點是改善知識關係、召回能力與多步驟推理。
第四類是系統與工程能力強化，包括 Modular RAG、Streaming RAG、Federated RAG 與 Hybrid RAG，主要處理系統擴充、即時更新、分散資料來源與檢索品質。
第五類則是針對資料型態或產業特性進行強化，包括 Multi-Modal RAG 與 Domain-Specific RAG。
RAG 類型不是選擇題，而是組合題
企業在規劃 RAG 時，不必從 16 種類型中選出唯一答案。真正的系統通常會同時具備多種特徵。
例如，醫院內部知識庫可能採用 Domain-Specific RAG 處理醫療術語，以 Hybrid RAG 結合全文與向量搜尋，再透過 Federated RAG 查詢不同院區的資料。如果要處理影像與報告，還可以加入 Multi-Modal RAG。
企業合約管理系統則可能先使用 Modular RAG 建立可維護的架構，透過 Contextual Retrieval RAG 理解使用者目前正在處理的合約，再由 Agentic RAG 呼叫計算器、工作流或 ERP 系統。
因此，RAG 架構設計的核心並不是追求名稱最多或技術最複雜，而是確認目前要解決的是哪一個問題。
導入 RAG 時應該評估哪些指標？
評估 RAG 系統時，不應只看最後回答是否通順。更重要的是拆開檢索與生成兩個階段進行測量。
檢索層面應關注召回率、排序品質、來源涵蓋率、權限過濾正確性及索引更新時間。生成層面則應評估答案正確性、來源支持程度、引用準確性、幻覺率與拒答能力。
系統營運方面還要衡量回應延遲、模型成本、索引成本、資料更新成本、可用性與維護難度。若應用於醫療、法律、金融或企業機密資料，還必須加入權限、稽核、資料主權、保存期限與人工覆核機制。
換句話說，企業需要評估的不是「有沒有使用 RAG」，而是這套 RAG 是否能持續提供正確、可追溯、符合權限而且成本可控的答案。
結語：從知識問答走向企業工作系統
RAG 已經不再只是把文件放進向量資料庫，再交給大型語言模型回答問題。它正在逐步演進成一套整合資料、知識、推理、記憶、工具與工作流程的企業 AI 架構。
對剛開始導入的團隊而言，可以先從 Standard RAG 與 Hybrid RAG 建立可靠的搜尋基礎；當問題涉及長期互動、跨文件推理或系統操作時，再逐步加入 Memory、Graph、Multi-Step 或 Agentic 等能力。
最重要的是，RAG 的價值不在於採用了多少種技術名稱，而在於能否讓使用者更快取得可信答案，並將答案進一步轉化為可以執行、驗證與追蹤的企業工作流程。
一句話總結：RAG 不是單一技術，而是一個可以依照任務複雜度、資料型態、產業規範與工程條件持續組合、擴充及演進的架構家族。
