RAG 是一套「先找資料、再讓模型回答」的系統工程——不只是把文件塞進提示詞，而是涵蓋切塊、嵌入、檢索、生成、評估與治理的完整管線。本指南以原始論文與官方文件為權威骨幹，系統化梳理概念、管線與架構。
LLM 訓練完成後知識就被「凍結」在參數裡，帶來三個根本問題：知識截止、幻覺、私有知識盲區。RAG 的解法很直覺——在模型生成答案之前，先去「查資料」，讓 LLM 從「閉卷考」變成「開卷考」。
RAG 並非單一步驟，而是一條多階段管線：知識庫建立（離線）→ 查詢處理（線上）→ 生成 → 持續評估。本指南的 Stage 1–5 對應下圖五個核心環節。
把文件切成可檢索、可理解、可放入上下文的單位。
把文字轉成高維向量，讓語意相似者距離接近。
找到「能回答問題的證據」，而不只是「最像的片段」。
讓模型只在證據範圍內回答，並附引用、不足時拒答。
分層測量檢索與生成品質，是品質保障的基礎設施。
CRAG / Self-RAG / GraphRAG / Agentic 自主決策迴圈。
把大型文件切割成小單元（chunks），各自向量化並建立索引。即使模型支援長上下文，過長內容仍會提高成本、延遲並稀釋信號。
實驗結果：Vectara 在 NAACL 2025 跨 25 種 chunking 配置 × 48 個 embedding 模型的研究發現，chunking 配置對檢索品質的影響不亞於 embedding 模型本身的選擇。
| 策略 | 方法 | 適用 / 風險 |
|---|---|---|
| ① 固定大小 | 按固定 token 數切，前後重疊（overlap） | 最快；可能切斷句子破壞語意 |
| ② 遞迴字元 | 段落 → 句子 → 字元優先序遞迴切（LangChain 預設） | 通用 first-choice，兼顧自然邊界 |
| ③ 結構感知 | 用 Markdown 標題 / HTML 標籤 / 頁碼作邊界 | 技術文件、法務、規格書；依賴解析器品質 |
| ④ 語意切割 | 相鄰句子 embedding 距離 > 閾值處切 | 結構不清晰時；計算成本高，效益不一定穩定 |
| ⑤ Parent-Child | 小 chunk 做精準檢索、大 chunk 提供完整上下文 | 解決「精準 vs. 上下文完整」矛盾 |
| ⑥ 情境化 / Contextual | 每個 chunk 前加文件標題、章節路徑等 metadata 再嵌入 | 每個 chunk「知道自己在哪裡」，低成本高回報 |
Contextual Chunking 數據（Microsoft Azure 2025）：在每個 chunk 前補上文件層級定位後，QA 準確率可從 ~55% 提升到 ~73%（+15–25 個百分點），且無需改動任何檢索架構。
| 類型 | 代表 | 優勢 / 劣勢 |
|---|---|---|
| Dense 稠密 | text-embedding-3, BGE, voyage | 語意理解強、同義詞佳／可能忽略精確詞、數字、稀有名詞 |
| Sparse 稀疏 | BM25, TF-IDF, SPLADE | 精確詞彙匹配、可解釋、穩健基線／語意理解弱 |
| Late interaction | ColBERT 類 | 排序品質常更好／成本高、索引大 |
| Hybrid 混合 | Dense + BM25 融合 | 兼顧語意與精確匹配／需調融合比例 |
| 模型 | 提供方 · 維度 | 特色 |
|---|---|---|
text-embedding-3-large / small | OpenAI · 3072 / 1536 | 高品質通用 / 低成本，API 方便 |
voyage-3 | Voyage AI · 1024 | RAG 特化，MTEB 表現優異 |
jina-embeddings-v3 | Jina AI · 1024 | 多語言強（含中文），開源 |
bge-m3 | BAAI · 1024 | 中文最強開源選項之一 |
MTEB 分數不能預測特定領域的實際表現。DPR 論文顯示 dense 可勝過強 BM25 基線，但 BEIR 也指出 BM25 是穩健基線——不要預設「向量搜尋必然優於 BM25」。永遠要在你自己的資料上 benchmark 再決定。查詢與文件務必用同一模型，並做版本管理。
向量相似度高 ≠ 證據充分。檢索目標是找到能支援回答的定義、規則、例外條款、數字、表格欄位與跨文件關聯。
研究數據（arXiv 2604.01733, 2026）：兩階段 Hybrid RRF + 神經 reranker 達 Recall@5 = 0.816，對比純 Dense（0.587，+39%）、純 BM25（0.644，+27%）。Hybrid + Reranking 是 2025 年後的生產系統 baseline，純向量只適合 demo。
階段一高召回初步檢索（撈 Top-50）→ 階段二高精度 cross-encoder 對每個候選單獨評分重排（取 Top-5）。Bi-encoder 把 query 與文件分開編碼算距離；cross-encoder 把 [query, document] 一起輸入做深度交互，更準但更慢（不能預計算）。主流：Cohere Rerank v4、ms-marco-MiniLM、BGE Reranker v2。
| 技術 | 做法 |
|---|---|
| 查詢改寫 | 把口語、代詞、省略語轉成完整查詢（多輪對話必備） |
| HyDE | 先用 LLM 生成「假設答案文件」，用其 embedding 檢索真實文件——更貼近文件語言風格；精確數字場景效果有限 |
| Multi-Query | 生成 3–5 個同義不同表述的問題，分別檢索後去重合併，提高召回 |
| Query Decomposition | 複雜問題拆成子問題分別檢索再彙整，適合 multi-hop 推理 |
| Routing | 判斷該查向量庫 / SQL / API / 網路，或直接回答 |
Metadata Filtering 常比換 embedding 模型更有效。在檢索前後用 date ≥ 2025-01-01、department = HR、version = latest、permission_group 等過濾，可排除過期、無權限、錯版本或不適用地區的資料。沒有 metadata 的 RAG 很容易把錯誤資料送進 LLM。
「Lost in the Middle」效應（TACL 2023）：LLM 對上下文的記憶呈 U 形曲線——開頭與結尾最易記住，中間最易被忽略。對策：最相關的 chunk 放 context 最前或最後，並減少 Top-K 數量。
Context Rot（Chroma 2025）：測試 18 個模型（GPT-4.1、Claude 4、Gemini 2.5）發現，即便支援超長 context，隨長度增加檢索效能仍持續下降。對策：用 reranking 只保留少量最相關 chunk，不要塞入大量冗餘。
RAG 降低幻覺，但不消除幻覺。常見殘留原因：檢索結果錯誤/矛盾、模型忽略 context、過度推論、引用看似存在但不支援對應句子、未要求「資料不足時拒答」。
RAG 可能「答案對但檢索錯」，也可能「檢索對但生成錯」。必須拆成 Retriever 鏈 + Generator 鏈 + 端到端任務分別評估。核心是「RAG 三元組」：Context Relevance、Faithfulness、Answer Relevancy。
| 指標 | 意義 |
|---|---|
| Context Precision | 撈回 Top-K 中真正相關的比例。低 = 噪音污染 LLM |
| Context Recall | 回答所需資訊是否都被撈到。低 = 資訊遺漏，模型只能猜 |
| MRR / nDCG / Hit@k | 排名相關性；nDCG 與端到端 RAG 品質相關性最強 |
| 指標 | 意義 |
|---|---|
| Faithfulness 忠實度 | 回答陳述是否都能在 context 找到根據。核心抗幻覺指標，< 0.8 即有問題 |
| Answer Relevancy | 是否真的回答了問題，有無答非所問 |
| Citation Accuracy | 引用是否真的支援對應句子 |
| Refusal Accuracy | 資料不足或越權時是否正確拒答 |
生產就緒標準（RAGAS Docs 2025）：Faithfulness > 0.8、Context Precision > 0.8。框架選擇：RAGAS（reference-free 快速探索）、ARES（context/faithfulness/answer 三維）、DeepEval（CI/CD 品質 Gate）、TruLens（實驗 Dashboard）、Arize Phoenix / LangSmith（生產監控與 tracing）。
評估陷阱：① RAGAS 在複雜場景失效率高——Cleanlab 發現其 Faithfulness 在 FinanceBench 有 83.5% 案例無法生成分數。② Retriever-Generator 對齊問題：研究顯示 47.4–66.7% 查詢中 Generator 忽略了 Retriever 排名第一的文件，故必須評估「兩者對齊程度」，不能只看單邊。
評估集務必涵蓋：單文件 / 多文件 / 多跳 / 表格數字 / 時效性 / 權限 / 無答案 / 錯誤前提 / 同義改寫 / 長文件定位問題。每個主要任務至少 50–200 題，並標註 gold evidence。
RAG 綜述論文常將發展劃分為 Naive / Advanced / Modular 三類；2026 年主流再往 Agentic 推進。Modular RAG 把每個元件（Retriever、Reranker、Generator、Memory）都做成可獨立替換的模組。
| 面向 | Naive RAG | Advanced RAG | Modular RAG |
|---|---|---|---|
| 核心流程 | 索引 → 檢索 → 生成 | 預檢索優化 → 檢索 → 後檢索優化 | 可插拔模組 + 動態路由迴圈 |
| 主要解決 | 知識過時、幻覺 | 檢索噪音、Lost in the Middle | 多步推理、跨源知識調度 |
| 核心技術 | 單純向量相似度 | 查詢改寫、Hybrid、Reranking、壓縮 | 智能路由、反思、動態迭代檢索 |
| 查詢理解 | 弱 | 中 | 強 |
| 適用 | PoC、小型 FAQ（< 1000 件） | 企業知識庫、客服、法務、金融 | 大型系統、生產環境、多資料源 |
生產 baseline：不做 Hybrid Search + Reranking 就等於沒做 Advanced RAG。Advanced RAG 在 Naive 基礎上加入：查詢改寫（HyDE / Multi-Query）→ Hybrid Retrieval → Cross-encoder Reranking → Context Compression → 帶引用的生成。
撈回文件後先評估相關性：相關度 OK → 直接生成；不足 → 觸發重新檢索（如 Web Search）+ 知識精煉。MDPI 2025（250 臨床病例）：CRAG Precision@5 = 0.69、幻覺率 10.5%、延遲 240ms——進入進階架構成本最低的第一步。
引入反思 token：[Retrieve]（要不要檢索）、[ISREL]（文件相關嗎）、[ISSUP]（生成有文件支撐嗎）、[ISUSE]（對回答有幫助嗎）。同批臨床實驗：Self-RAG 幻覺率 5.8%，為 12 種變體中最低。
向量搜索只能說「這些 chunk 語意相似」，無法回答「實體間是什麼因果關係」或「整個資料集有哪些主要主題」。Microsoft GraphRAG 透過建立實體知識圖譜 + 社群摘要改善 query-focused summarization。兩種模式：Local Search（特定實體圖遍歷，精確問題）、Global Search（全圖摘要，全域性問題）。
性能躍升（arXiv 2506.10408）：HotpotQA 多跳推理——靜態 RAG 34% vs Agentic RAG 89%（+55 個百分點）；2WikiMultiHop 89.7%。這不是邊際改善，而是能力等級的跨越。實作工具：LangGraph（帶 checkpointing）、LlamaIndex Workflows、AutoGen。
RAG 的失敗分三層：索引層（Indexing）、檢索層（Retrieval）、生成層（Generation）。以下整合學術界與工業界公認的失敗模式。
| 失敗類型 | 現象 / 根因 | 對策 |
|---|---|---|
| 資料缺失 | 知識庫根本沒有答案，卻勉強生成 | 數據治理；強制「找不到請說不知道」 |
| Retrieval Miss | 答案存在但相似度誤差未進 Top-K | HyDE / Multi-Query；Hybrid + 強制 Reranking |
| Lost in the Middle | 答案在 Top-K 但排序居中被忽略 | 減少注入數量；關鍵 chunk 置於首尾 |
| Not Extracted | 答案在 Prompt 中但噪音過多未被抽出 | Prompt Compression；升級 in-context 能力更強的模型 |
| 格式錯誤 | 過度關注檢索文本而忽略 JSON/表格指令 | 結構化輸出工具（Pydantic）、Schema 強制約束 |
| 粒度不匹配 | 要全局概述卻撈回碎片細節（或反之） | Parent-Child 檢索：匹配子塊、提供父塊 |
| 合成不完整 | 答案散在多個分塊，只取其一導致片面 | Query Decomposition（multi-hop）依序檢索再彙整 |
| 上下文矛盾 | 新舊版法規並存，模型無法判斷 | 時序 metadata 標記 + 檢索階段過濾過期資料 |
| Context Leak | 模型用訓練知識覆蓋 context | 強化 grounding instruction、加 citation 要求 |
| Generation Drift | context 正確但改寫扭曲原意 | Faithfulness 監控、要求逐句 quote |
| 指代消解失敗 | 「那它的價格呢？」丟失第一輪主體 | History-aware 對話歷史重寫 |
| Stale Knowledge | 回答基於過時資訊 | 定期 re-index、日期 filter、CRAG + Web fallback |
OWASP 2025 LLM Top 10 將 prompt injection 與 vector / embedding weaknesses 列為重要風險，並指出 RAG 與 fine-tuning 都不能完全緩解 prompt injection。NIST 生成式 AI 風險框架強調需要治理、測量與管理控制。
| 風險 | 說明 | 防護 |
|---|---|---|
| 間接 Prompt Injection | 惡意指令藏在被檢索的文件中 | 文件清洗、指令/資料隔離、輸出限制 |
| Retrieval Poisoning | 攻擊者放入高相似度的惡意文件 | 來源信任分級、索引審核 |
| Data Leakage | 檢索到無權限內容 | 檢索階段 ACL filter、tenant isolation |
| Vector Inversion | embedding / 索引暴露敏感資料 | 加密、存取控管、資料最小化 |
| Hallucinated Citation | 看似引用但無支援 | 引用驗證、逐句支持檢查 |
| Tool Overreach | RAG agent 誤呼叫高權限工具 | 工具權限最小化、人審閘門 |
權限必須在「檢索階段」執行——不能只靠 prompt 指示。私有資料系統需要 retrieval-time ACL 過濾、租戶隔離與審計日誌。對醫療、法律、金融等高風險領域，RAG 必須搭配人審、引用驗證、拒答策略與資料治理。
2025 後 GPT-4.1、Claude 4、Gemini 2.5 的 context window 已超過 100 萬 token，有人質疑 RAG 是否還需要。多項研究（arXiv 2501.01880、2407.16833、LaRA 2025）的共同結論：沒有萬用解——取決於任務、資料特性與成本。
| 維度 | RAG 勝出 | Long Context 勝出 |
|---|---|---|
| 成本 | ✓ 低得多（只傳相關 chunks） | 1M token 約 1250× 費用 |
| 延遲 | ✓ 秒級 | 1M token 慢 30–60 倍 |
| 動態資料 | ✓ 即時更新索引 | 需重組整個上下文 |
| 精確事實 + 引用 | ✓ 可追溯來源 | 多事實 recall 約 60% |
| 全文件 / 多跳推理 | chunk 可能遺漏脈絡 | ✓ 一次讀完更自然 |
| 權限 / 治理 | ✓ 檢索階段過濾 | 難做細粒度控管 |
Self-Route（EMNLP 2024）：讓模型自行判斷——簡單事實查找路由到 RAG，需全域理解的複雜問題路由到 Long Context。在維持高準確率的同時顯著降低整體計算成本。長上下文不會完全取代 RAG：成本、權限、更新、引用與可治理性仍讓 RAG 有價值。
RecursiveCharacterTextSplitter 512 tokens → text-embedding-3-small → pgvector/Chroma/Qdrant → Cosine Top-5 → 帶「不知道請說不知道」的 Prompt → 跑 5–10 題人工評分。
加 BM25 + RRF Hybrid → Cross-encoder Reranking → chunk metadata + filter → 整合 RAGAS（Faithfulness/Precision/Recall）→ 設 > 0.8 門檻 → 最相關 chunk 放首尾。
權限檢索（ACL）→ 資料同步與索引監控 → 評估儀表板 → prompt injection 防護 → 失敗案例回流 → 成本/延遲監控 → 週期性 re-index 與合規審計。
本指南以原始論文與官方文件為權威骨幹彙整，內容反映截至 2026 年 5 月。