把 RAG 拆成可逐項比較的技法：切塊與索引、稀疏與稠密檢索、排序融合、agentic 與進階模式、生成端控制、真實查詢會踩的坑，以及評估、成本與可觀測性。每篇只談一個決定，讀完能拼成一條自己的 pipeline。
RAG 已經從簡單的「搜尋+生成」演化成涵蓋十個世代的技術體系，2025 年後更進入 Agentic/Reasoning RAG 新階段。本文是系統化導航：從 Naive RAG 到 Multi-Agent/LongRAG 的十代演化、後十代 Agentic Era（Search-R1/RL 搜索、MCP 協議、GraphRAG 3.x、視覺直嵌）、檢索策略、Chunking、Embedding、Reranking、評估框架、可觀測性、成本優化。每個主題都有對應專文深入。
Naive RAG 夠用但有很多問題，Advanced RAG 針對性修補，Modular RAG 重新架構讓系統可組合、可配置。了解三個世代，才能理解現代 RAG 系統為什麼長這樣。
RAG 和 Fine-tuning 解決的是不同問題。RAG 給模型新知識，Fine-tuning 改變模型的行為風格。大多數情況是兩者都用，而不是選一個。
RAG 不是固定的三步流程，而是一組可以動態啟用、跳過、重排的步驟。Pipeline as Code 讓系統在不重新部署的情況下調整行為。
切太大找不準，切太小失去上下文。Chunking 是 RAG 最被低估的環節，策略選錯，後面再多優化都是白費。
文件切塊後，每個 chunk 失去了它在原文件中的上下文。Contextual Retrieval 在索引時，用整份文件為每個 chunk 各自生成一段上下文再前綴進去，解決 chunk 孤島問題。
Embedding 模型的選擇直接影響 RAG 的搜尋品質。BGE-M3 的多語言訓練、1024 維向量、同系列 Reranker，是繁中 RAG 的實用選擇。
向量資料庫的選型比 LLM 選型更受部署平台限制。先確認平台和規模需求，再看功能特性，不要只看 benchmark。
PageIndex 不切 chunk、不做 embedding、不存向量，靠 LLM 推理一份 LLM 自己寫的目錄樹，在 FinanceBench 上由開發方自評拿到 98.7%。它解的不是向量 RAG 的同一個問題——是『在一份結構清楚的厚文件裡找對的那一節』。
攀岩路線有大量圖片資訊（路線圖、岩壁照片），純文字 RAG 遺漏了這些。Multimodal RAG 讓圖片也能被搜尋和理解。
向量搜尋抓語義，BM25 抓關鍵字，兩者用 RRF 融合才能同時照顧模糊查詢和精確術語。
BM25 只認識查詢裡出現的詞，SPLADE 能推斷相關詞彙並加入搜尋，在保持關鍵字搜尋精確性的同時獲得部分語義能力。
Bi-Encoder 太粗糙，Cross-Encoder 太慢，ColBERT 的 Late Interaction 在兩者之間找到平衡：token 級別的相互比較，但可以預先計算文件向量。
用 LLM 先生成一份「理想答案」，再把這份假設文件 embed 去搜尋，比直接搜尋查詢本身效果更好。
複雜查詢只用一個向量搜尋容易漏掉相關文件，讓 LLM 改寫成 3-5 個子查詢並行搜尋，召回率顯著提升。
不是所有問題都需要 RAG。用 LLM 先分類查詢類型，再決定執行路徑，節省成本又提升準確度。
「我今年完攀幾條」這種問題，RAG 語義搜尋永遠不如直接查資料庫。讓 LLM 識別意圖、提取參數，執行預定義 SQL 模板。
BM25、向量搜尋、HyDE、Multi-Query 各出一份結果，怎麼合理地合成一份？RRF 用名次而不用分數，規避了跨系統分數無法比較的根本問題。
向量搜尋的相似度分數不等於相關性，Cross-Encoder 用成對比較重新排序，把真正相關的文件推上來。
只看相關性會讓結果都是同一條路線的不同描述，MMR 在相關性和多樣性之間取平衡，再疊加熱門度讓結果更實用。
複雜多跳問題，RAG 一次搜尋不夠。Agentic RAG 讓 LLM 評估結果是否充分，不夠就改寫查詢再搜一次，形成 ReAct 迴圈。
對複雜問題，先讓 LLM 規劃出需要哪些資訊、分幾步取得，再按計畫執行，比邊搜邊想更系統化。
過濾條件太嚴格導致零結果？CRAG 自動放寬過濾條件重試，比讓 LLM 用通用知識瞎猜好多了。
用另一個 LLM 評估回答的準確度和品質，分數太低就重新生成，並自動加上適當的免責聲明。
向量搜尋找相似，圖搜尋走關係。當問題需要跨多個實體的推理（岩場→路線→完攀者→難度分布），GraphRAG 比標準 RAG 更有優勢。
傳統 RAG 把文件切成小 chunks 再檢索，但這造成資訊碎片化。LongRAG 利用 100K+ token 的長上下文模型，檢索更大的文件區段（整個章節甚至整份文件），減少碎片化同時保持檢索效率。
Speculative RAG 用小型專家模型從不同文件子集平行生成多個答案草稿，再由大型模型一次驗證選出最佳答案。論文在 PubHealth 上準確度提升 12.97 個百分點、延遲降低 50.83%——但這是最好的那一格，其他 benchmark 的幅度小很多。
單一 RAG Agent 處理所有查詢會遇到知識邊界和效能瓶頸。Multi-Agent RAG 把檢索任務分派給多個專業化 Agent，每個 Agent 有自己的知識庫和檢索策略，由中央 Orchestrator 協調合併結果。
搜尋找到了正確的文件，但 LLM 的回答還是不好——很多時候問題在 Prompt 設計。System prompt 結構、context 排版、指令語言都會影響輸出品質。
RAG 系統面對的攻擊不只是技術層面的，Prompt Injection 和 Jailbreak 是真實威脅。輸入輸出都需要獨立的防護層。
LLM 生成需要 3-5 秒，等全部生成完再顯示體驗很差。SSE 讓 token 一邊生成一邊推送，首個字元出現時間從 5 秒縮到 1 秒以內。
每次對話後，異步提取使用者可能的偏好和程度，下次查詢時自動個性化搜尋條件，不需要使用者手動設定。
RAG 系統出問題，90% 的情況是這 10 種之一。先識別是哪種失敗模式，再找對應的解法，比盲目優化有效很多。
攀岩 RAG 系統中「推薦下一條路線」（progression）和「推薦類似路線」（similarity）被同一個 hasSimilarRouteIntent() 函式混為一談，導致推薦品質崩壞。解法是 Regex Fast Path + LLM Fallback 的兩階段意圖分類。
RAG 系統的 extractRouteReference() 用 for...return 只抓第一個匹配，使用者給了五條完攀紀錄卻只用到一條。解法從 rule-based 多實體擷取、user profile aggregation 到 embedding centroid，分三層遞進實作。
查詢「美人照鏡 5.11b，推薦類似難度路線」，結果回來的全是名字像的路線而不是難度像的。根因是 dense embedding 把多個屬性壓進同一個向量，名稱的稀有性壓過了難度訊號。解法：metadata pre-filter + query rewriting + score fusion 三層防線。
RAG 評估沒有指定工具的業界標準；先把 retrieval、generation、operation 分開量，再依技術棧選 Promptfoo、RAGAS、DeepEval 或 TruLens。
「加了 Cross-Encoder 之後感覺好多了」不是科學的評估。A/B 測試讓你知道改動是否真的有效，效果多大，在哪類查詢上有效。
RAG 系統最難的不是建起來，是搞清楚為什麼這次回答不好。Pipeline Tracing 把每個步驟的決策和數據記下來，讓除錯有跡可循。
自己寫 trace 夠用，但開源工具讓你少做很多事。Langfuse、Phoenix、LangSmith 各有定位，選哪個取決於你對自架、開源、整合複雜度的取捨。
快取不只能比對完全一樣的查詢，語義相近的問題也能命中快取，省下整個 RAG pipeline 的執行。
RAG 系統的成本來自 LLM token、Embedding API、向量搜尋。每個環節都有可以壓成本的地方，但要確認優化沒有犧牲太多品質。
只限制請求次數不夠，一個超長的查詢可能消耗掉十個普通查詢的 token。雙重配額（請求數 + token 數）才能真正控制成本。
RAG 系統需要資料才能回答問題，但一開始就沒有資料。冷啟動策略決定了系統從空到可用的路徑。
用 Weaviate Query Agent + ColQwen 多向量模型，一個 prompt 在 36 小時內搭出生產等級的法律合約搜尋系統——這篇拆解它的架構邏輯、技術選擇，以及你真正需要注意的事。
2025 年的 RAG 不再是「檢一次、生成一次」。Search-R1 用 RL 讓模型在推理中自主多輪搜索，REX-RAG/AlignRAG 補上策略與對齊的分支，OpenAI Deep Research 把整條鏈產品化，MCP 則把檢索泛化為統一的工具調用。本文拆開設計哲學、與舊世代的取捨、以及何時該用這套新範式。
同樣是「知識圖譜 + 檢索」，Microsoft GraphRAG v3.1.2 用重索引換全局總結能力，LightRAG 用 dual-level 與增量把成本砍下來，HippoRAG 2 用 PPR 把 RAG 做成可持續增長的記憶；這篇按部件拆設計取捨，含四種查詢、索引流程與選型表。
Anthropic Contextual Retrieval 用 LLM 為每塊生成 50-100 token 前置上下文把失敗率從 5.7% 壓到 1.9%（含 rerank），成本約 $1.02/1M tokens；Late Chunking 先以 32K 長上下文模型全文件編碼再切塊 mean-pool，零額外 LLM 成本，取捨在窗口、延遲與文件結構。