目錄
- 怎麼使用這篇指南
- 全域架構圖
- 世代對比總覽
- Gen 1-3：Naive → Advanced → Modular
- Gen 4: Self-RAG
- Gen 5: CRAG（Corrective RAG）
- Gen 6: Graph RAG
- Gen 7: Speculative RAG
- Gen 8: Agentic RAG
- Gen 9: Multi-Agent RAG
- Gen 10: LongRAG
- 後十代：Agentic / Reasoning RAG（2025-）
- 前沿：MCP 工具整合（2025 協議層）
- 前沿：Agent Memory
- 前沿：Multimodal RAG
- 檢索策略快速選型
- Hybrid Search：BM25 + Vector + RRF
- HyDE：假設答案搜尋
- Multi-Query Expansion
- Cross-Encoder Reranking（含 Listwise 新線）
- ColBERT：Late Interaction
- SPLADE：學習型稀疏向量
- RRF：多路結果融合
- MMR：多樣性重排
- Contextual Retrieval
- Query Classification
- Semantic Caching
- Text-to-SQL Router
- 基礎設施決策順序
- Chunking 策略
- Embedding 模型選型
- 向量資料庫選型
- Prompt 設計
- Streaming
- 個性化與記憶
- 品質營運的優先順序
- 評估框架
- LLM-as-Judge
- 常見失敗模式
- Guardrails
- 可觀測性
- 成本優化
- A/B 測試
- 冷啟動
- RAG vs Fine-tuning
- MVP 路線：最快把 RAG 跑起來
- 品質提升路線：讓答案更準確
- 進階架構路線：處理更複雜的問題
- 生產營運路線：穩定地跑在線上
- 前沿探索路線：看看未來
- 最後一句話
- 更新紀錄
- 參考資料
你搜尋「RAG」，會得到幾百篇文章，每篇都在講不同的東西。
有人在講 Naive RAG 的三步驟，有人在講 Graph RAG 的知識圖譜，有人在講 Agentic RAG 的 ReAct loop，有人在講 Reranking 和 Embedding 模型選型。這些全部都叫 RAG，但它們解決的問題完全不同，適用的場景也天差地遠。
問題不是資訊太少，是資訊太碎。
這篇文章是一張地圖。它不會深入任何單一主題——每個主題都有對應的專文。它做的事情是：讓你站在高處，看清整個 RAG 技術體系的全貌，然後根據你的需求，選對路線走進去。
誰需要這篇指南：正在建 RAG 系統的工程師、想了解 RAG 全貌的技術主管、以及在各種 RAG 變體之間迷路的任何人。不管你是從零開始還是已經有一個在跑的系統想要改進，這篇都能幫你定位。
怎麼使用這篇指南
- 先看全域架構圖：理解十代 RAG 和周邊技術的關係
- 找到你的階段：你在建 MVP？在優化品質？在搞生產營運？
- 跳到對應章節：每個章節會給你 2-4 段概述 + 關鍵洞察
- 點進專文：想深入的主題，每個都有獨立的完整文章
全域架構圖
RAG 技術體系全景
┌─────────────────────────────────────────────────────┐
│ │
│ ┌─────────── 十代演化 ──────────────────────────┐ │
│ │ │ │
│ │ Gen 1: Naive RAG (搜尋+生成) │ │
│ │ ↓ │ │
│ │ Gen 2: Advanced RAG (前處理+後處理) │ │
│ │ ↓ │ │
│ │ Gen 3: Modular RAG (可組合 DAG) │ │
│ │ ↓ │ │
│ │ Gen 4: Self-RAG (LLM 自己決定要不要搜尋) │ │
│ │ ↓ │ │
│ │ Gen 5: CRAG (搜尋結果不對就重試) │ │
│ │ ↓ │ │
│ │ Gen 6: Graph RAG (知識圖譜推理) │ │
│ │ ↓ │ │
│ │ Gen 7: Speculative RAG (小模型打草稿) │ │
│ │ ↓ │ │
│ │ Gen 8: Agentic RAG (自主 Agent) │ │
│ │ ↓ │ │
│ │ Gen 9: Multi-Agent RAG (多 Agent 協作) │ │
│ │ ↓ │ │
│ │ Gen 10: LongRAG (長上下文取代細切) │ │
│ │ │ │
│ └───────────────────────────────────────────────┘ │
│ ┌────── 後十代：Agentic Era（2025-） ────────┐ │
│ │ 推理×檢索交織 + RL 訓練 + 多輪工具調用 │ │
│ │ Search-R1 / REX-RAG / AlignRAG / GTA-RAG │ │
│ │ Deep Research（產品化）+ MCP（協議層） │ │
│ └───────────────────────────────────────────┘ │
│ │
│ ┌─── 檢索策略 ───┐ ┌─── 基礎設施 ───┐ │
│ │ BM25 + Vector │ │ Chunking │ │
│ │ HyDE │ │ Embedding │ │
│ │ Multi-Query │ │ Vector DB │ │
│ │ Cross-Encoder │ │ Prompt Design │ │
│ │ ColBERT / SPLADE│ │ Streaming │ │
│ │ RRF / MMR │ │ Memory │ │
│ │ Semantic Cache │ └────────────────┘ │
│ │ Text-to-SQL │ │
│ │ Late Chunking │ ┌─── 品質與營運 ───┐ │
│ └─────────────────┘ │ Evaluation │ │
│ ┌─── 前沿 ────────┐ │ Guardrails │ │
│ │ Agent Memory │ │ Observability │ │
│ │ Multimodal RAG │ │ Cost / A/B Test │ │
│ └─────────────────┘ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────┘世代對比總覽
| 世代 | 一句話描述 | 核心強項 | 適用場景 |
|---|---|---|---|
| Gen 1: Naive | 搜尋 → 塞進 prompt → 生成 | 最簡單、最快能跑 | MVP、PoC、內部工具 |
| Gen 2: Advanced | 加上 query rewrite、reranking、chunk 優化 | 品質大幅提升 | 生產環境第一版 |
| Gen 3: Modular | 把 pipeline 拆成可組合模組 | 彈性、可測試 | 需要客製化的產品 |
| Gen 4: Self-RAG | LLM 自己判斷要不要搜尋 | 減少不必要的檢索 | 混合知識型問答 |
| Gen 5: CRAG | 搜尋結果不好就自動修正重試 | 容錯能力 | 開放域問答 |
| Gen 6: Graph RAG | 知識圖譜 + 向量搜尋 | 關係推理 | 法規、醫療、複雜知識網 |
| Gen 7: Speculative | 小模型平行打草稿，大模型驗證 | 延遲低、成本低 | 高吞吐量場景 |
| Gen 8: Agentic | 自主 Agent + ReAct loop | 多步推理 | 複雜研究型問題 |
| Gen 9: Multi-Agent | 多個專業 Agent 分工協作 | 規模化、專業化 | 企業級多領域系統 |
| Gen 10: LongRAG | 大 chunk + 長上下文模型 | 保留完整語境 | 長文件、法律合約 |
| 後十代：Agentic Era | 推理×檢索交織 + RL 訓練 + 多輪工具調用 | 自主研究、跨工具整合 | 複雜研究、企業深度問答 |
後十代目前沒有共識的 Gen 11 編號，建議視為「Agentic Era」新階段而非線性續編。命名與世代劃界可參考兩份 2025 年綜述：Towards Agentic RAG with Deep Reasoning 與 Reasoning RAG via System 1 or System 2。
成熟度光譜
不是每一代都同樣成熟。在選擇時，你也要考慮技術的生產就緒程度：
- 已驗證（大量生產案例）：Gen 1 Naive、Gen 2 Advanced、Gen 3 Modular
- 漸趨成熟（有生產案例但仍在快速演化）：Gen 5 CRAG、Gen 6 Graph RAG（GraphRAG 已至 v3.1.2）、Gen 8 Agentic RAG、Gen 9 Multi-Agent（主流 agent 框架都已內建 supervisor / orchestrator 模式）
- 早期採用（主要停留在論文與實驗，通用框架支援有限）：Gen 4 Self-RAG（需要特製訓練）、Gen 7 Speculative（需要自備 draft 小模型）、Gen 10 LongRAG
- 前沿驗證中（2025-）：Agentic/Reasoning RAG（如 Search-R1 的 RL 多輪搜索、AlignRAG 的 test-time critique）與 MCP 協議 工具整合，已有產品化案例（OpenAI Deep Research），但仍在快速演化，不建議視為穩定基線
Part 1：RAG 十代演化
Gen 1-3：Naive → Advanced → Modular
Gen 1: Naive RAG
最原始的 RAG：把使用者的問題拿去做向量搜尋，找到最相關的幾個 chunk，全部塞進 prompt，讓 LLM 生成答案。三個步驟：Indexing → Retrieval → Generation。
架構一句話：Query → Embed → Vector Search → Top-K Chunks → LLM → Answer
它能跑，但問題很多。Query 和 document 的語義不一定對齊，chunk 的切法影響巨大，找回來的結果可能不相關，LLM 可能無視 context 自己幻覺。每一個環節都是潛在的失敗點。大多數團隊會在 Naive RAG 上卡兩到三週，然後意識到「光是塞進去」不夠。
Gen 2: Advanced RAG
Advanced RAG 的核心改進是在 Retrieval 前後各加一層處理。前處理：query rewriting、HyDE、multi-query expansion，讓搜尋更精準。後處理：reranking、compression、deduplication，讓送進 LLM 的 context 品質更高。
架構一句話：Query → Pre-process → Retrieve → Post-process → Generate
這是大多數生產系統的起點。單純加上 Cross-Encoder reranking，通常就能明顯改善送進 LLM 的 context 品質。提升幅度沒有普適數字——它取決於你的 base retriever 有多弱、top-K 拉多大、以及資料的同質程度，所以請在自己的資料上量，不要照抄別人部落格的百分比。如果你只能做一件事來改善 Naive RAG，加 reranking。
Gen 3: Modular RAG
Modular RAG 把整個 pipeline 拆成獨立模組——Routing、Retrieval、Reranking、Generation 各自是一個可替換的元件。你可以把它想成一個 DAG（有向無環圖），每個節點負責一件事，節點之間透過標準介面串接。
架構一句話：Query → Router → [Module A | Module B | Module C] → Merge → Generate
這讓你可以 A/B 測試單一元件、根據 query 類型動態切換策略、甚至在不同模組間做 fallback。大部分成熟的 RAG 產品最終都會走向 Modular 架構，因為你總會遇到「這類問題要走不同路徑」的需求。
→ 深入閱讀：RAG 的三個世代：從 Naive 到 Modular → 深入閱讀：Modular RAG Pipeline：把 RAG 設計成可組合的 DAG
Gen 4: Self-RAG
Self-RAG 的關鍵突破是：LLM 自己決定要不要檢索。
傳統 RAG 不管什麼問題都去搜尋，但很多問題 LLM 自己就知道答案——「Python 的 list comprehension 怎麼寫」不需要搜尋。Self-RAG 訓練模型輸出特殊的 reflection token：[Retrieve] 決定要不要搜尋，[ISREL] 判斷搜尋結果是否相關，[ISSUP] 判斷生成的答案是否有 context 支持。
User Query
↓
LLM: 需要搜尋嗎？ ──→ [No Retrieve] → 直接生成
↓ [Retrieve]
搜尋 → 結果相關嗎？ ──→ [ISREL=No] → 丟棄，換一批
↓ [ISREL=Yes]
生成答案 → 有 context 支持嗎？ ──→ [ISSUP=No] → 重新生成
↓ [ISSUP=Yes]
輸出最終答案Self-RAG 的好處是減少不必要的搜尋（降低延遲和成本），同時在需要搜尋時確保結果品質。缺點是需要特殊訓練——你不能拿任何一個現成的通用 API 模型直接用，必須有 fine-tune 過、會輸出 reflection token 的模型（原論文釋出的是基於 Llama 2 微調的權重）。
適用場景：知識庫內容和 LLM 自身知識有大量重疊時，Self-RAG 能避免冗餘搜尋。如果你的問題幾乎都需要搜尋（例如企業內部文件問答），那 Self-RAG 的好處不大。
Gen 5: CRAG（Corrective RAG）
CRAG 解決的問題很直接：搜尋結果不好怎麼辦？
Naive RAG 搜到什麼就用什麼，即使結果根本不相關。CRAG 在 Retrieval 後面加了一個 Evaluator，用一個輕量級模型（或 LLM）對搜尋結果打分。如果分數高，直接用；如果分數低，觸發修正策略——放寬搜尋條件、換一個搜尋引擎、甚至用 web search 作為 fallback。
架構一句話：Query → Retrieve → Evaluate(相關/不確定/不相關) → [Use | Refine | Web Search] → Generate
這個「搜不到就修正」的機制讓 RAG 系統在面對 edge case 時不會直接失敗，而是自動嘗試不同策略。CRAG 論文在四個短文／長文生成資料集上都回報了顯著提升，但幅度隨資料集和底層 retriever 差異很大——它證明的是「加了修正層會更穩」，不是某個固定的百分比。
CRAG 的實用價值在於它不需要改你現有的搜尋引擎——它是在搜尋結果出來之後加的一層。這意味著你可以在任何現有的 RAG 系統上「加裝」CRAG，而不需要重新設計 pipeline。
→ 深入閱讀：CRAG：檢索失敗時，自動放寬條件重試
Gen 6: Graph RAG
向量搜尋擅長找「語義相似的段落」，但它不擅長關係推理。
「這個藥物和那個藥物有交互作用嗎？」「這條法規引用了哪些其他法規？」「這個人在這家公司擔任什麼職位，這家公司又跟哪些公司有合作關係？」——這些問題需要的不是找到相似的文字，而是沿著關係鏈走。
Graph RAG 把文件中的實體和關係抽取出來，建成知識圖譜（Knowledge Graph），然後在檢索時同時查向量索引和圖譜。向量搜尋負責找到相關的文件片段，圖譜負責找到相關的實體關係，兩者合併後送進 LLM。
架構一句話：Query → [Vector Search + Graph Traversal] → Merge Context → Generate
Microsoft 的 GraphRAG 論文進一步提出了 Community Summary 的概念：對圖譜中的社群（高度互連的節點群）預先生成摘要，讓系統能回答那些需要「全局理解」的問題。
Graph RAG 的建置成本比純向量搜尋高得多——你需要做實體抽取、關係建模、圖譜維護。但在法規遵循、醫療知識、企業組織關係等「關係密集」的領域，這個投資是值得的。
→ 深入閱讀：GraphRAG：把知識做成圖，讓 LLM 沿著關係推理 → 深入閱讀：GraphRAG 3.x vs LightRAG vs HippoRAG 2：索引成本、增量與記憶的三軸選型
Gen 7: Speculative RAG
Speculative RAG 借鑑了 Speculative Decoding 的思路：用小模型做初步工作，大模型做最終驗證。
具體做法：一個小型、經過蒸餾的 specialist model（原論文用的是 7B 級別）同時生成多個候選答案草稿，每個草稿基於不同的 retrieved chunk 子集。然後一個大型 generalist model 一次性評估所有草稿，選出最好的那個。兩邊具體用哪個模型不重要，重要的是「小的多、大的一次」這個結構。
Retrieved Chunks: [C1, C2, C3, C4, C5]
↓
小模型（平行）:
Draft 1 (基於 C1, C2)
Draft 2 (基於 C2, C3)
Draft 3 (基於 C4, C5)
↓
大模型（一次驗證）: 選 Draft 2 → 最終答案好處是延遲低（小模型跑得快，而且是平行的）和成本低（大模型只做一次驗證，不做完整生成）。Speculative RAG 論文在 PubHealth 上回報準確率最多提升 12.97 個百分點（76.60 對 63.63，是絕對差不是相對提升）、延遲降低 50.83%；但這是該資料集上的最佳值，TriviaQA、MuSiQue、PopQA、ARC-Challenge 的幅度都小得多，不要當成通例。另外要注意：這個數字的前提是你有一個蒸餾過的 specialist 小模型，不是隨便抓一個 7B 就有。
關鍵洞察：Speculative RAG 本質上是用 compute parallelism 換 latency。如果你的瓶頸是 GPU 不夠而不是延遲太高，這個模式反而會讓事情更糟。
→ 深入閱讀：Speculative RAG：用小模型平行打草稿，大模型一次驗證
Gen 8: Agentic RAG
前面所有世代的 RAG 都是單次流程：query 進來，跑一遍 pipeline，答案出去。Agentic RAG 打破了這個限制——它讓 LLM 變成一個自主 Agent，可以多次搜尋、反思、調整策略。
核心機制是 ReAct loop（Reasoning + Acting）：LLM 先思考（「這個問題需要什麼資訊？」），然後行動（搜尋、呼叫 API、計算），觀察結果，再決定下一步。這個 loop 可以跑多輪，直到 Agent 認為它有足夠的資訊來回答。
Agentic RAG 特別適合複雜的研究型問題——那些需要拆解成多個子問題、從不同來源收集資訊、最後綜合成答案的問題。缺點是延遲高（可能跑 3-10 輪），成本高（每輪都是一次 LLM call + 搜尋），而且 Agent 可能走偏。
架構一句話：Query → Agent(Think → Act → Observe → Think → ...) → Answer
除了 ReAct，還有 Plan-and-Execute 模式：先讓 LLM 制定完整計劃，再逐步執行。這在需要系統性資訊收集的場景中表現更好。
什麼時候該用 Agentic RAG？一個簡單的判斷標準：如果使用者的問題需要超過一次搜尋才能回答（例如「比較 A 公司和 B 公司的營收成長率」需要分別搜尋兩家公司），就該考慮 Agentic RAG。
→ 深入閱讀：Agentic RAG：讓 LLM 自己決定要不要再搜尋一次 → 深入閱讀：Plan-and-Execute：先規劃再執行的 RAG 模式
Gen 9: Multi-Agent RAG
當系統需要覆蓋多個專業領域，單一 Agent 很難做好所有事情。Multi-Agent RAG 的做法是：每個領域一個專業 Agent，再加一個 Orchestrator 負責分配和彙整。
例如一個企業知識問答系統：HR Agent 專門搜尋人事制度文件，Legal Agent 搜尋法規合約，Tech Agent 搜尋技術文件。使用者的問題先到 Orchestrator，Orchestrator 判斷該問哪個 Agent（或同時問多個），等結果回來後合併成最終答案。
架構一句話：Query → Orchestrator → [Agent_HR | Agent_Legal | Agent_Tech] → Merge → Answer
Multi-Agent 的優勢是每個 Agent 可以有自己的搜尋策略、自己的 prompt、自己的知識庫，互不干擾。挑戰是 Agent 之間的通訊協議設計、結果合併的邏輯、以及整體延遲的控制。
在實務中，Multi-Agent RAG 最大的坑不是技術，而是「agent 之間的責任邊界怎麼劃」。如果兩個 agent 的知識領域有重疊，orchestrator 不知道該問誰，結果反而比單一 agent 更差。
→ 深入閱讀：Multi-Agent RAG：多個專業 Agent 協作的分散式檢索架構
Gen 10: LongRAG
LongRAG 挑戰了一個 RAG 的基本假設：chunk 一定要切小嗎？
傳統 RAG 把文件切成 256-512 token 的小 chunk，因為早期 LLM 的 context window 小（4K-8K），塞不下太多。但現在的模型動輒 128K-1M context window，這個限制已經不存在了。
LongRAG 的做法是用大 chunk（甚至整份文件），搭配長上下文模型。好處是保留了完整的語境——不再有「答案被切在兩個 chunk 的邊界」的問題。搜尋的精準度要求也降低了，因為 chunk 大，命中率自然高。
架構一句話：Query → Coarse Retrieval (大 chunk) → Long-Context LLM → Answer
代價是 token 用量暴增（大 chunk 意味著送進 LLM 的 token 數多），延遲也會增加。LongRAG 適合那些對完整性要求高、對成本不那麼敏感的場景，例如法律合約分析、長篇論文問答。
一個有趣的趨勢：長上下文模型的 context 上限持續擴大、每 token 價格持續下降，LongRAG 的成本劣勢正在縮小。具體的上限和價格幾個月就變一次，這裡不列數字——請直接查你使用的供應商的官方文件。
但「塞更多 context」不等於「答得更好」。長上下文模型在超長輸入下仍有位置偏誤和注意力稀釋的問題，塞進去不代表模型讀得到。所以務實的折衷是：小型知識庫直接走大 chunk + 長上下文，大型知識庫仍然需要傳統的 chunking + retrieval，並且不管走哪條路都要用評估集驗證，而不是假設「context 夠大就沒事」。
→ 深入閱讀：LongRAG：用長上下文模型重新思考 RAG 的 Chunking 策略
後十代：Agentic / Reasoning RAG（2025-）
如果說 Gen 1-10 是「檢索→生成」單次管線的逐步增強，2025 年後的集群則是推理與檢索的雙向交織：模型在逐步推理中自主產生多次搜索查詢，並用 RL 訓練出「何時搜、搜什麼、怎麼用結果」的能力。這不是某一個 Gen 的細分，兩份獨立綜述把它定義為新範式（Towards Agentic RAG with Deep Reasoning 的 Synergized RAG-Reasoning、Reasoning RAG via System 1/2 的 Reasoning Agentic RAG）。
技術起點是 Search-R1（2025-03）：用 RL（retrieved token masking + outcome reward）訓練 LLM 在推理中自主多輪搜索，Qwen2.5-7B 較 RAG baseline 提升顯著。其後分支包括 REX-RAG（policy correction 解決 RL dead-end）、GTA-RAG（graph-trajectory 蒸餾）、Interact-RAG（把檢索從黑盒查詢變成可操縱的語料庫交互）、AlignRAG（test-time critique 對齊推理與證據）。本節不列論文細節，細節交由專文展開，這裡只做分界與轉手。
產品與協議層的落地同樣重要：OpenAI Deep Research（2025-02-02，基於 o3 優化版的多步瀏覽 + Python 工具 agent）把 Agentic RAG 推向端到端研究產品；MCP（Model Context Protocol）（Anthropic 2024-11-25 開源）把「檢索」從向量庫查詢泛化為統一的工具/數據源調用（Resources / Tools / Prompts），2025 年已被 ChatGPT、Claude、VS Code、Cursor 等採納，並被 LangGraph 1.2.11 等編排框架整合。在十代分類中，這屬於基礎設施的世代躍遷，而非單一技巧。
務實提醒：Agentic tricks 並非無條件更強。Agent-Orchestrated Adaptive RAG 的對比研究顯示，query decomposition 在結構化域有提升但在多跳任務上可能降 ranking precision，reflection 提 citation 精度但伴隨高延遲。是否採用此世代，取決於你的問題是否真的需要多輪推理與跨工具調用。
→ 深入閱讀：Agentic / Reasoning RAG：從 Search-R1 到 Deep Research 與 MCP 的推理×檢索新範式
前沿：MCP 工具整合（2025 協議層）
2024-11 Anthropic 開源的 MCP 把 RAG 的「檢索」從向量庫查詢泛化為統一的工具/數據源調用。Host / Client / Server 三件套 + Resources / Tools / Prompts 三能力 + Sampling / Roots / Elicitation 能力協商，讓一個 MCP server 可被多個 agent 框架復用。2025 年已被 ChatGPT、Claude、VS Code、Cursor 採納，LangGraph（1.2.11 持久化/ human-in-the-loop / streaming 的 orchestration runtime）、CrewAI 與 AutoGen 0.7 均已整合。導航建議：新系統以 MCP 為主、自製 tool-use 為輔，注意宿主授權與工具描述不可信的風險。
前沿：Agent Memory
RAG 本質上是唯讀的——系統從知識庫裡讀資料，但不會寫回去。Agent Memory 把 RAG 升級成讀寫系統。
Agent 在與使用者互動的過程中，會把學到的偏好、事實、決策寫進記憶存儲。下次互動時，這些記憶和知識庫一起被檢索。這讓 Agent 能夠持續學習和個性化，而不只是一個無狀態的問答機器。
記憶系統通常分三層：Working Memory（當前對話的 context）、Episodic Memory（過去對話的摘要）、Semantic Memory（抽取出的事實和偏好）。這三層加上外部知識庫，構成了 Agent 的完整認知系統。
→ 深入閱讀：Agent Memory 系統：從 RAG 到 Read-Write 記憶的演化
前沿：Multimodal RAG
文字只是知識的一種形式。很多企業的知識散佈在 PDF 裡的圖表、簡報裡的架構圖、產品照片、甚至影片和錄音中。
2025 年後的主線已從「OCR→文字再索引」轉向視覺直嵌：ColPali（ICLR 2025）用 VLM 直嵌頁面圖 + ColBERT late interaction 做文檔檢索，Qwen2.5-VL（2025-01-26，3B/7B/72B，動態解析度 + 1hr 影片理解）可作 backbone；舊的 colpali-engine 已棄用，官方建議遷至 Sentence Transformers v6 的 MultiVectorEncoder。評估建議用 ViDoRe V2（V1 已飽和 >90% nDCG@5，新版含盲上下文 / 長跨文檔查詢）。
實務上，multimodal RAG 最大的挑戰不是模型能力，而是 pipeline 的複雜度——PDF 解析、表格抽取、圖片 OCR、影片逐幀分析，每一步都可能出錯；視覺直嵌雖保真，但多向量儲存膨脹，token pooling（pool factor 3 降 66.7% 向量保 97.8% 性能）等壓縮是必備配套。
→ 深入閱讀：Multimodal RAG：把圖片也納入知識庫
Part 2：檢索策略
檢索是 RAG 系統的心臟。用錯策略，後面的 LLM 再強也救不回來。以下是主要的檢索策略，以及它們各自解決的問題。
檢索策略快速選型
| 你的問題 | 該用什麼 | 為什麼 |
|---|---|---|
| 向量搜尋漏掉精確關鍵字 | Hybrid Search (BM25 + Vector) | 兩種搜尋互補 |
| Query 和文件的用詞不同 | HyDE | 用假設答案橋接語義差距 |
| 單一 query 覆蓋面不足 | Multi-Query Expansion | 多角度搜尋 |
| Top-K 結果排序不準 | Cross-Encoder / Listwise Reranking | 精準重排；2025 後可試 jina-reranker-v3.5 |
| 需要速度又要精準度 | ColBERT | Late interaction 折衷 |
| BM25 太笨但需要稀疏向量 | SPLADE | 學習型稀疏向量（v3 為新基線） |
| 多路結果要合併 | RRF / DBSF | 排名融合，免訓練；Qdrant Hybrid 實測二者皆勝單路 |
| 結果太同質化 | MMR | 相關性 + 多樣性 |
| Chunk 脫離上下文 | Contextual Retrieval / Late Chunking | 加 context 前綴 vs 先編碼後切塊（零 LLM 成本） |
| 不同問題要走不同路徑 | Query Classification | 入口分流 |
| 重複問題太多 | Semantic Caching | 語義快取 |
| 答案在結構化資料中 | Text-to-SQL Router | SQL 比搜尋準 |
Hybrid Search：BM25 + Vector + RRF
向量搜尋擅長語義匹配，但會漏掉精確的關鍵字。BM25 擅長關鍵字匹配，但不懂語義。Hybrid Search 兩者並用，再透過 RRF（Reciprocal Rank Fusion）合併排名。這是目前生產系統最常見的搜尋架構。
→ Hybrid Search：用 BM25 + 向量搜尋彌補彼此的盲區
HyDE：假設答案搜尋
使用者的問題和文件的語言風格不同，導致向量搜尋的 recall 不高。HyDE 先讓 LLM 生成一個「假設的答案」，再用這個假設答案去搜尋。因為假設答案和真實文件的語言風格更接近，recall 通常會改善——但提升幅度高度依賴領域和 base retriever（原論文是在零樣本、無標註資料的設定下和 Contriever 比較），在有標註資料可以微調 retriever 的場景，HyDE 的優勢會縮小。
Multi-Query Expansion
一個問題可能有多種問法。Multi-Query 讓 LLM 把原始問題改寫成 3-5 個不同角度的 query，每個都去搜尋，最後合併結果。這能覆蓋到單一 query 漏掉的文件。
→ Multi-Query Expansion：一個問題，多個角度搜尋
Cross-Encoder Reranking（含 Listwise 新線）
向量搜尋用的是 bi-encoder——query 和 document 各自算 embedding 再比較，快但不精準。Cross-Encoder 把 query 和 document 拼在一起送進模型，精準度高很多，但慢。通常的做法：先用向量搜尋拉回 top-50，再用 Cross-Encoder rerank 取 top-5。2025 年後出現 jina-reranker-v3/v3.5（0.6B listwise，BEIR 63.20 相當於 4B 水準，半結構化 +9.6，延遲進一步優化）：把 query 與多個候選放同一上下文窗口做 causal attention，在候選間直接比大小，適合半結構化與需跨文檔比較的場景；請在自家標註集上對照驗證，不要照抄榜單數字。
→ Cross-Encoder Reranking：讓最相關的文件排到前面
ColBERT：Late Interaction
ColBERT 是 bi-encoder 和 cross-encoder 之間的折衷。它為 query 和 document 的每個 token 都算一個 embedding，在搜尋時做 token-level 的交互比對。比 bi-encoder 精準，比 cross-encoder 快。
SPLADE：學習型稀疏向量
BM25 靠的是 term frequency，SPLADE 用 BERT 學出每個 token 的權重，產生稀疏向量。它同時具備關鍵字匹配（稀疏）和語義理解（學習型）的優點。2024 年的 SPLADE-v3 在 MS MARCO 上取得更強的稀疏基線，可作為 Hybrid 段中「BM25 之後的可量化升級選項」，先量 BM25 收益再決定是否上 learned sparse。
RRF：多路結果融合
當你有多個搜尋結果列表（例如 BM25 的結果和向量搜尋的結果），RRF 用一個簡單的公式根據排名位置合併它們。不需要分數標準化，不需要訓練，即插即用。2025 年 Qdrant 的 Hybrid 實測顯示，dense+sparse 雙路 + RRF/DBSF 在 5 數據集上多數勝單路，額外延遲約 0.6–1.47ms（單容器單併發基準，供參考，實際需自測）——「先量再上 learned sparse」仍是穩健決策流。
MMR：多樣性重排
如果搜尋結果的 top-5 都在講同一件事，你等於浪費了 4 個 context slot。MMR（Maximal Marginal Relevance）在排名時同時考慮相關性和多樣性，確保結果覆蓋不同面向。
Contextual Retrieval
Anthropic 提出的 Contextual Retrieval 方法：在 indexing 階段，對每個 chunk 加上一段 context（「這段出自某份文件的某個章節，在講某個主題」）。搜尋時這段 context 一起被比對，大幅提升 chunk 的可定位性。2024-09 的官方數據顯示，Contextual Embeddings + Contextual BM25 可將失敗率從 5.7% 降至 1.9%（含 rerank），前置成本約 $1.02/1M tokens（僅作基準，實際依 chunk 大小與模型而異）。
零 LLM 成本的替代是 Late Chunking：先對整份文件做一次 transformer 編碼，再切 chunk 再 mean-pool，讓每個 chunk 向量天然帶有跨 chunk 的上下文，無需對每塊調用 LLM 生成前置語句，適合長上下文 embedding 模型（32K 窗口）與預算有限的場景；超長文件或語意高度獨立的 chunk 則收益遞減。兩者不是互斥，導航建議按成本與窗口大小二選一或對照實測。
→ Contextual Retrieval：幫每個 Chunk 加上「這段在說什麼」 → 深入閱讀：Late Chunking vs Contextual Retrieval：先編碼後切塊的零成本替代與實作對比
Query Classification
不是所有問題都該走同一條路。事實型問題用精確搜尋，分析型問題用深度搜尋，閒聊直接回覆不搜尋。Query Classification 在 pipeline 入口做分類，根據問題類型選擇不同策略。
→ Query Classification：讓 RAG 知道該怎麼回答這個問題
Semantic Caching
語義相近的問題（「台北天氣如何」和「現在台北氣溫多少」）不需要跑兩次完整 pipeline。Semantic Cache 用向量相似度判斷新 query 是否和之前的某個 query 足夠接近，如果是，直接返回快取的答案。
→ Semantic Caching：語義相近的問題只跑一次 RAG
Text-to-SQL Router
有些問題的答案在結構化資料中（資料庫），用向量搜尋反而不如直接寫 SQL。Text-to-SQL Router 判斷問題是否適合轉成 SQL query，如果是，走資料庫路線而不是 RAG。
→ Text-to-SQL Router：精確查詢不走 RAG
Part 3：基礎設施
RAG 的效果有一半取決於基礎設施的選擇——chunk 怎麼切、embedding 用哪個、向量資料庫怎麼選。這些決定在專案初期就會做出，之後要改的成本很高。
基礎設施決策順序
建 RAG 系統時，基礎設施的決策有先後順序。先決定 Chunking 策略（因為它影響後面所有環節），然後選 Embedding 模型（因為一旦選了就很難換——換模型意味著重新 embed 所有文件），接著選向量資料庫，最後設計 prompt。
Chunking → Embedding → Vector DB → Prompt Design → Streaming
↑ ↓
└──── 如果效果不好，通常要從這裡開始改 ────────────────┘Chunking 策略
切塊方式直接決定 RAG 能不能找到答案。切太小會失去上下文，切太大會混入噪音。常見策略包括：固定大小、基於段落/句子、遞迴切分、語義切分（根據 embedding 相似度判斷分界點）。沒有「最佳大小」——要根據你的文件類型和問題類型實驗。
→ Chunking 策略：切塊方式決定 RAG 能不能找到答案
Embedding 模型選型
繁體中文的 RAG 系統，embedding 模型的選擇特別重要。BGE-M3 是常見的起點——它同時支援 dense、sparse 和 multi-vector 檢索，繁中表現也不錯。但 embedding 模型的排行榜換得很快，別把任何一個模型當定論：選型要看語言覆蓋、維度大小、最大 token 長度、以及最重要的——在你自己的資料上跑出來的 benchmark。2025-2026 年值得對照的新線包括 jina-embeddings-v5-text（蒸餾+任務對比，sub-1B 小模型 32K 上下文）、jina-embeddings-v4（3.8B 多模雙模式，圖表/表格 SOTA）與 Jina-ColBERT-v2（late interaction 多向量），建議以「小/高效 vs 多模/視覺 vs 多向量」三分支對照 BGE-M3 的選型表，而非單點替換。
→ BGE-M3：為什麼這個 Embedding 模型適合繁體中文 RAG
向量資料庫選型
向量資料庫的功能矩陣變動很快，任何寫死的比較表都會在幾個月內過期，所以這裡不列表。真正穩定的是取捨軸：全託管還是自架、單機還是分散式、是否原生支援 hybrid search 與 metadata filtering、以及部署位置（雲端 region 還是邊緣）。先用這幾個軸把候選收斂到兩三個，再去各家官方文件（Pinecone、Weaviate、Qdrant、Cloudflare Vectorize）確認當下的功能與定價。2025-2026 值得關注的增量：Qdrant 1.19 的 Turbo4（4-bit 純量化、9× 儲存降、三級 memory tiers pinned/cached/cold）與 Weaviate 1.30 的 BlockMax WAND（詞彙搜尋最高 10× 加速、multi-vector GA + 量化），以及 Qdrant Hybrid RRF/DBSF 實測的前述延遲數據——量化與混合檢索已成預設值，不是選配。
→ Vector Database 選型：Pinecone、Weaviate、Qdrant、Vectorize 怎麼選
Prompt 設計
RAG 的 prompt 設計不只是「把 context 塞進去」。要注意：context 和 instruction 的位置安排、引用格式、如何指示 LLM 在 context 不足時說「我不知道」、以及如何讓 LLM 標註答案來源。好的 prompt 設計能讓同一批 retrieved chunks 產出品質差異巨大的答案。
→ RAG Prompt Engineering：System Prompt 和 Context 怎麼設計
Streaming
使用者不想等 10 秒才看到完整答案。SSE（Server-Sent Events）讓 LLM 的回答邊生成邊顯示，大幅改善使用者體驗。實作時要注意 streaming 狀態下的 citation 處理、error handling、以及 abort 機制。
→ RAG Streaming：SSE 讓 LLM 回答邊生成邊顯示
個性化與記憶
讓 RAG 系統記住使用者的偏好——語言風格、常問的主題、上次對話的脈絡。這不只是 chat history，而是從對話中抽取結構化的偏好資料，在下次搜尋和生成時作為額外的 context。
Part 4：品質與營運
RAG 系統上線只是開始。真正的挑戰是：怎麼知道它表現好不好？怎麼防止它出包？怎麼在控制成本的同時持續改進？
品質營運的優先順序
如果你剛上線，建議按這個順序建立品質基礎設施：
- Evaluation（先能衡量，才能改善）
- Failure Modes（知道會在哪裡壞）
- Guardrails（防止最嚴重的錯誤）
- Observability（出問題時能找到原因）
- Cost Optimization（在品質穩定後再省錢）
- A/B Testing（有了基線後才能比較）
評估框架
你不能改善你不能衡量的東西。RAGAS（最新 v0.4.3（2025-01-13），不存在所謂 2.0；0.4 為 collections API + BasePrompt 的破壞性遷移）、DeepEval、TruLens 是三個主流的 RAG 評估框架，各自提供不同的指標：Faithfulness（答案是否忠於 context）、Relevance（檢索結果是否相關）、Answer Correctness（答案是否正確）。建議在 CI 中跑自動化評估，每次 pipeline 變更都有數字，並用 RAGTruth（~18k word-level 幻覺語料）與 FinanceBench（金融領域基準）作幻覺分類與領域矩陣補充。
→ RAG 評估框架：RAGAS、DeepEval、TruLens 怎麼用
LLM-as-Judge
當你沒有大量 human-labeled 測試資料時，可以用另一個 LLM 來評估 RAG 的輸出。Self-Reflection 讓生成答案的 LLM 自己評分，LLM-as-Judge 用一個獨立的 LLM 評分。兩者都有偏差，但作為快速迭代的訊號已經夠用。
→ Self-Reflection + LLM-as-Judge：讓 AI 評估自己的回答
常見失敗模式
RAG 系統有十種以上的常見失敗模式：chunk 切錯位導致答案不完整、embedding 語義偏移、reranking 反而把對的結果排掉、LLM 無視 context 自己幻覺、context window 塞太滿反而降低品質。知道這些 failure mode 才能針對性地修。
Guardrails
RAG 系統的輸入和輸出都需要防護。輸入端：防止 prompt injection、過濾敏感查詢。輸出端：檢查 hallucination、過濾有害內容、確保答案有 citation 支持。Guardrails 不是 nice-to-have，是生產系統的必要條件。
可觀測性
RAG pipeline 有很多環節，任何一個出問題都會影響最終答案。可觀測性的目標是讓這個黑盒子變透明：每一次查詢的每一步（query rewrite 的結果、搜尋回來的 chunks、reranking 後的順序、LLM 的完整 prompt）都要能追蹤和回放。
→ RAG Observability：讓黑盒子變透明的逐節點追蹤 → RAG 可觀測性工具全景
成本優化
RAG 的成本主要來自三個地方：embedding 計算、向量搜尋、LLM 生成。每一個都有優化空間——embedding cache、chunk 壓縮、小模型 + 大模型分層、semantic caching、token quota 系統。目標是在不犧牲品質的前提下，把每次查詢的成本壓到最低。
→ RAG 成本優化：把每次查詢的花費壓到最低 → RAG 配額系統
A/B 測試
你換了一個 reranking 模型，品質變好了還是變差了？你把 chunk size 從 512 改成 1024，效果如何？RAG 的 A/B 測試比 web A/B 測試複雜得多——你要比較的是兩個完整 pipeline 的表現，指標是語義層面的（答案品質），不是點擊率。
→ RAG A/B 測試：怎麼科學地比較兩個 Pipeline 配置
冷啟動
新系統上線時，知識庫是空的或很少。怎麼讓系統在這個階段也能用？常見策略：預載公開知識、用 LLM 自身知識做 fallback、引導使用者上傳文件、用 few-shot 範例展示系統能力。
RAG vs Fine-tuning
不是所有問題都該用 RAG 解決。如果知識是靜態的、query pattern 是固定的、而且你有足夠的訓練資料，fine-tuning 可能更適合。實務上最強的做法是兩者結合：fine-tune 讓模型學會「怎麼用 context」，RAG 提供最新的 context。
怎麼選 RAG 世代？
面對十個世代，最常見的問題是：「我該用哪一代？」
答案取決於你的問題複雜度和資源限制：
你的問題需要幾次搜尋就能回答？
只要一次 ──→ Gen 1-3 (Naive/Advanced/Modular)
│ ├─ 剛起步？ → Gen 1 Naive
│ ├─ 品質不夠？ → Gen 2 Advanced
│ └─ 需要彈性？ → Gen 3 Modular
│
有時不需要搜尋 ──→ Gen 4 Self-RAG
│
搜尋結果常常不對 ──→ Gen 5 CRAG
│
需要關係推理 ──→ Gen 6 Graph RAG
│
延遲要求很高 ──→ Gen 7 Speculative RAG
│
需要多步推理 ──→ Gen 8 Agentic RAG
│
多個專業領域 ──→ Gen 9 Multi-Agent RAG
│
文件很長且不能切碎 ──→ Gen 10 LongRAG
│
需要推理×檢索交織/跨工具整合 ──→ 後十代 Agentic Era（Search-R1 / MCP / Deep Research）重要提醒：世代不是線性升級。Gen 10 不一定比 Gen 2 好——它們解決不同的問題。一個設計良好的 Advanced RAG（Gen 2）在大多數場景下會比一個設計糟糕的 Agentic RAG（Gen 8）表現更好。選擇世代的依據是你的問題特性，不是越新越好。
閱讀路線推薦
根據你的目標，選一條路線走：
MVP 路線：最快把 RAG 跑起來
如果你要在最短時間內建一個能用的 RAG 系統：
- RAG 的三個世代 — 理解基本架構
- Chunking 策略 — 把文件切好
- BGE-M3 Embedding — 選對 embedding 模型
- Vector Database 選型 — 選一個向量資料庫
- RAG Prompt Engineering — 寫好 prompt
品質提升路線：讓答案更準確
如果你的 RAG 已經在跑，但答案品質不夠好：
- Hybrid Search — 彌補向量搜尋的盲區
- Cross-Encoder Reranking — 提升排名精準度
- HyDE — 改善 recall
- RAG 評估框架 — 用數字衡量改進
- RAG 常見失敗模式 — 找到具體問題點
進階架構路線：處理更複雜的問題
如果你需要的不只是簡單的問答：
- CRAG — 搜尋失敗的容錯機制
- Agentic RAG — 多步推理
- GraphRAG — 關係推理
- Speculative RAG — 低延遲高吞吐
生產營運路線：穩定地跑在線上
如果你要把 RAG 系統上生產：
- RAG Guardrails — 輸入輸出防護
- RAG Observability — 全鏈路追蹤
- RAG 成本優化 — 控制花費
- RAG A/B 測試 — 科學地比較配置
前沿探索路線：看看未來
如果你想了解 RAG 的最新發展：
- Multi-Agent RAG — 多 Agent 協作
- LongRAG — 長上下文新思路
- Agent Memory — 讀寫記憶系統
- Multimodal RAG — 多模態知識庫（含 ColPali 視覺直嵌與 ViDoRe V2 評估）
2025-：後十代 Agentic Era（推理×檢索交織 + RL，多輪工具調用）與協議層 MCP 正在形成中，專文將陸續補上（Search-R1 / Interact-RAG / GraphRAG 3.x 選型），本導航屆時回填
→ 深入閱讀連結。
最後一句話
RAG 不是一個技術，是一個技術體系。
不要試圖一次學完所有東西。找到你現在最需要解決的問題，沿著對應的路線走進去，把那一塊搞懂、搞穩，再往下一個主題前進。
這篇指南會持續更新。每當有新的專文發布，這裡會同步加上連結。
更新紀錄
- 2026-08-25：新增「後十代：Agentic Era（2025-）」全域框與專節（Search-R1/REX-RAG/AlignRAG、Deep Research、MCP）、補 Late Chunking vs Contextual Retrieval 對比與 listwise reranker（jina v3.5）、重寫 Embedding/Vector DB 2025 增量（jina-v5/v4、Qdrant Turbo4、Weaviate BlockMax WAND、Hybrid 實測）、重寫 Multimodal 為視覺直嵌（ColPali/Qwen2.5-VL/ViDoRe V2）並新增 MCP 前沿節、闢謠 RAGAS 版本
- 2026-08-25：補上句內官方來源連結（BGE-M3 / Vector DB 四家 / Anthropic Contextual Retrieval / RAGAS·DeepEval·TruLens）與 GraphRAG 內鏈，利於溯源
- 2026-08-19：對照官方文件逐篇查證翻新，移除易腐內容，並收進「RAG 技法大全」系列
參考資料
- Retrieval-Augmented Generation for Large Language Models: A Survey — Gao et al. (2023)，涵蓋 Naive RAG、Advanced RAG、Modular RAG 三代演化的完整綜述
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection — Asai et al. (2023)，Self-RAG 原始論文，自主決定是否檢索的反思機制
- Corrective Retrieval Augmented Generation — Yan et al. (2024)，CRAG 論文，透過評估器修正不良檢索結果
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization — Edge et al. (2024)，Microsoft GraphRAG 原始論文，知識圖譜加強全域查詢
- Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG — Singh et al. (2025)，Agentic RAG 系統分類學與演化路徑綜述
- Searching for Best Practices in Retrieval-Augmented Generation — Wang et al. (2024)，RAG pipeline 各元件最佳組合的實驗性研究
- Multi-Head RAG: Solving Multi-Aspect Problems with LLMs — Besta et al. (2024)，利用多頭注意力機制提升多面向查詢的檢索準確率
- Speculative RAG: Enhancing Retrieval Augmented Generation through Drafting — Wang et al. (2024)，小模型平行打草稿、大模型一次驗證的加速架構
- Precise Zero-Shot Dense Retrieval without Relevance Labels — Gao et al. (2022)，HyDE 原始論文，用假設文件橋接 query 與 document 的語義差距
- Towards Agentic RAG with Deep Reasoning: A Survey (2025) — 後十代 Agentic/Reasoning RAG 世代劃界與 Synergized RAG-Reasoning 分類
- Reasoning RAG via System 1 or System 2: A Survey (2025) — 以 System 1/2 區分 predefined vs agentic reasoning，佐證 Agentic Era 劃界
- Search-R1: Training LLMs to Reason and Leverage Search Engines with RL (2025) — RL 訓練的自主多輪搜索，Agentic Era 技術起點
- Introducing Contextual Retrieval — Anthropic (2024-09-19)，Contextual Embeddings + BM25 與成本基準
- Late Chunking: Contextual Chunk Embeddings — Jina AI (2024)，先編碼後切塊的零 LLM 成本替代
- Qdrant 1.19 — TurboQuant Datatype & Memory Tiers (2026-08-05) — 量化與 memory tiers
- Hybrid Search in Qdrant (2026-08-24) — RRF/DBSF 混合檢索實測
- Weaviate 1.30 Release (2025-04-08) — BlockMax WAND 與 multi-vector GA
- GraphRAG Releases v3.1.2 / GraphRAG Docs — Microsoft (2025-08-21 現行 3.1.x，四查詢 Global/Local/DRIFT/Basic)
- Model Context Protocol Specification 2025-06-18 / Introducing the Model Context Protocol — 協議層官方來源
- ColPali: Efficient Document Retrieval with Vision Language Models (ICLR 2025) / colpali GitHub — 視覺直嵌路線與棄用遷移
- Qwen2.5 VL (2025-01-26) / ViDoRe V2 — 多模態 backbone 與評估基準
- RAGTruth: A Hallucination Corpus / FinanceBench — 幻覺分類與金融領域補充
- BGE-M3 — BAAI/bge-m3 / jina-embeddings-v3/v4/v5-text / Jina-ColBERT-v2 / SPLADE-v3 — Embedding 與稀疏檢索官方/論文來源
Loading...