RAG 架構深入解析：讓 LLM 不再胡說八道

為什麼需要 RAG？

大型語言模型雖然強大，但有一個致命缺陷：幻覺（Hallucination）——編造不存在的事實。

RAG（Retrieval-Augmented Generation）是當前的標準解法。它讓 LLM 在回答問題前，先從外部知識庫中檢索相關文件，再基於真實資料生成答案。

RAG 的核心流程

1. 索引階段：將文件庫切割成 chunk，透過 embedding model 轉成向量存入向量資料庫
2. 檢索階段：使用者提問 → embedding → 向量相似度搜尋 → 取回最相關的 Top-K 文件片段
3. 生成階段：將檢索到的文件作為 context 插入 prompt，交由 LLM 生成最終答案

實戰陷阱

• Chunk size 太大：單一 chunk 包含過多不相關資訊，影響檢索精確度
• Chunk size 太小：語意不完整，LLM 無法理解前後文
• 只做 naive retrieval：沒有 rerank 或 hybrid search，Top-K 品質不穩定

我的經驗

在實際專案中，chunk size 設在 512 tokens 左右，搭配 overlap 10%，再用 BM25 + 向量 hybrid search，效果最好。

你用的是哪一套 RAG 架構？LangChain、LlamaIndex 還是自己寫的？