RAG 技術深入：從 Naive RAG 到 Advanced RAG

RAG（Retrieval-Augmented Generation）已成為 LLM 落地的關鍵架構，解決了模型知識截止、幻覺與領域專業不足三大痛點。本文從 Naive RAG 出發，一路探討到 Advanced RAG 的核心技術。

Naive RAG 的架構與局限

Naive RAG 遵循經典的三段式流程：索引（Indexing）→ 檢索（Retrieval）→ 生成（Generation）。

索引階段：將文件分割成 chunk → 對每個 chunk 進行向量化（embedding）→ 存入向量資料庫

檢索階段：將用戶查詢向量化 → 在向量庫中進行相似度搜尋（Top-K）→ 取出最相關的 chunks

生成階段：將檢索到的 chunks 作為上下文，拼接原始查詢送入 LLM 生成回答

Naive RAG 的三大痛點：

檢索品質不穩：單純依賴向量相似度，語義理解深度不足，容易檢出不相關內容

上下文碎片化：chunk 邊界可能切斷關鍵資訊，導致語意不連貫

資訊冗餘與衝突：多個 chunk 之間可能重疊或矛盾，LLM 難以取捨

Chunking 策略：決定 RAG 品質的第一關

Chunking 策略直接影響檢索召回率與上下文品質。主流策略包括：

| 策略 | 方式 | 適合場景 | |------|------|---------| | 固定長度 | 按 token 數切割（256/512/1024） | 通用型，簡單快速 | | 遞迴式 | 依分隔符號遞迴分割（\n\n > \n > .） | 結構化文件 | | 語義式 | 根據主題轉換或語義邊界分割 | 學術論文、長報告 | | Agentic | 由 LLM 判斷最佳分割點 | 高品質場景，成本較高 |

實務建議：對一般企業文件，chunk 大小 512-1024 tokens 搭配 10-20% 重疊（overlap）是安全起手配置。對程式碼或技術文件，建議按函式/類別邊界進行語義 chunking。

Embedding 模型選擇

Embedding 模型的品質決定了「語義壓縮」的保真度。2025-2026 年主流選項：

OpenAI text-embedding-3-large：3072 維，支援縮小維度，通用性最強但成本較高

Cohere Embed v3：多語言表現佳，支援壓縮與檢索專用模式

BGE-M3 (BAAI)：開源最強，支援多語言、多粒度，適合自建

Jina Embeddings v3：長文本（8K tokens）支援優秀，適合長文件場景

E5-mistral-7b-instruct：基於 LLM 的 embedding，語義理解最強但速度慢

選擇原則：先測後選。在自有資料集上計算 retrieval hit rate 與 MRR（Mean Reciprocal Rank），而非只看 MTEB 排行榜。

Advanced RAG 的關鍵優化

1. 檢索前優化（Pre-Retrieval）

查詢重寫（Query Rewriting）：將模糊查詢轉換為更精確的檢索語句

HyDE（Hypothetical Document Embeddings）：先讓 LLM 生成假想答案，再用該答案做向量檢索

多查詢策略（Multi-Query）：將一個查詢擴展為多個相關查詢同時檢索

2. 檢索後優化（Post-Retrieval）

Reranking：向量檢索出 Top-50 後，用跨編碼器（Cross-Encoder）模型重新排序，取 Top-3 至 Top-5 送入 LLM。這是成本效益最高的單一優化手段

Context Compression：壓縮或過濾檢索結果中的冗餘資訊，減少 LLM 的 token 消耗

Snippet Fusion：將多個 chunk 的關鍵片段融合為精煉的上下文

3. 索引優化

階層式索引（Hierarchical Index）：summary 層 + chunk 層，先檢索摘要再定位細節

多路徑檢索（Multi-path Retrieval）：同時使用向量檢索 + 關鍵字檢索（BM25）+ 知識圖譜檢索，透過 fusion 機制合併結果

Graph RAG：先建立知識圖譜，再沿圖結構進行遍歷式檢索，特別適合多跳問答

實戰建議

對於企業導入 RAG，建議逐步演進：先以 Naive RAG + 好的 chunking + reranker 起步（80% 效益來自這三項），再視需求加入查詢重寫、HyDE、Graph RAG 等 advanced 技術。切記：無人在意的 RAG 架構，優化順序永遠是先修資料品質，再調檢索策略，最後才是模型選擇。