大部分人第一次做 RAG 失敗,不是因為技術難,而是每一層都挑了當下最熱門的 5 個工具,結果搞出個 Frankenstein。先做最簡單能 work 的版本,之後再隨時換掉某一塊。
五層,照順序
基本 RAG 系統有五個元件,跳過或簡化某些是可以的(有時甚至更好),但你要知道它們存在:
- 文件載入 / 切塊(loader / chunker) — 把原始素材切成可以 embed 的小塊
- embedding 模型 — 把每個 chunk 變成向量
- 向量資料庫(vector store) — 存向量、文字、metadata
- 檢索(retriever) — 拿到使用者 query 時,找最相關的 chunk
- 生成(generator,LLM) — 拿著 chunk + query,寫出答案
80/20 法則:切塊跟檢索比 embedding 模型跟 vector DB 重要。大部分團隊在錯的層級上鑽牛角尖。
第一層:切塊
預設:切成大概 500 token 的 chunk、重疊 50 token、以自然邊界切(段落,然後句子)。LangChain 的 RecursiveCharacterTextSplitter 或 LlamaIndex 的 SentenceSplitter 是標準工具,直接用。
預設不夠時:文件有強結構(法律合約、程式碼、有章節的學術論文)。這類用 semantic chunking 或 section-aware chunking — 按文件本身的自然單位切。Unstructured.io 跟 Docling 處理 PDF、HTML、DOCX 而且保留結構。
新手最常掉的坑:chunk 切太大(「每塊 context 多 = 檢索更好,對吧?」)。錯。大 chunk 會稀釋檢索訊號 — 真正相關的那一句話會被旁邊兩段不相關的文字平均掉。chunk 要小。如果需要更多 context,就多撈幾個 chunk 讓 LLM 自己整合。
第二層:embedding 模型
純英文:OpenAI text-embedding-3-small(每百萬 token $0.02)是預設。快、便宜、幾乎所有場景都夠好。text-embedding-3-large 微幅好一點,但價格 4 倍,通常不值得。
多語言或中文為主的內容:BGE M3(開源,自架或透過 Together / Replicate)跟 Cohere Embed v4 是兩個強選擇。BGE M3 自架免費;Cohere 是 hosted 也穩定。OpenAI 的 embedding 中文還行但不如專門模型。
專業領域(醫療、法律、程式碼):有評估資料證明能 help 的話再考慮 domain fine-tune embedding。大部分團隊應該跳過。
第一步不要 fine-tune embedding。幾乎永遠是改善 chunking 或加 reranker 的提升更大。
第三層:vector store
第一個專案:已經用 Postgres 就 pgvector;沒用就 Qdrant。兩個都免費、兩個都能 scale 到百萬 chunk、兩個 DX 都好。
什麼時候用 Pinecone 之類的 hosted:ops 能力是瓶頸而不是錢的時候。Pinecone 比較貴,但你不用想 DB 的事。對只有一個工程師的新創,這通常是對的取捨。
什麼時候用 Weaviate、Milvus、Chroma、LanceDB:第一版很少需要。各有有趣的特色(Weaviate 的 hybrid search、LanceDB 的 S3-native 架構)但第一版通常用不到。有具體理由再選。
不要根據 benchmark scaling 圖選 vector DB。你第一個專案有 1 萬個 chunk,不是 1 億。任何選項處理 1 萬 chunk 都是瞬間。
第四層:檢索
預設:top-k 語義搜尋(k=5 到 10)。把 query embed 後,用 cosine similarity 找最近的 k 個 chunk。所有 tutorial 都這樣示範。
升級 #1:hybrid search — 語義搜尋 + 關鍵字搜尋(BM25)。很多 query(「Q3 合約價格是多少」)需要關鍵字匹配才能撈到對的 chunk。Hybrid 幾乎永遠比純語義好。Qdrant、Weaviate、pgvector + tsvector 都支援。
升級 #2:reranker — 先用 vector search 撈 20-30 個候選,再用 cross-encoder 模型重排。Cohere Rerank v3 是黃金標準(每 query $0.001)。自架選項像 BGE reranker 也有競爭力。Reranker 帶來的提升常常大過換 embedding 模型。
升級 #3:query expansion / HyDE — 讓 LLM 在搜尋前重寫 query。對模糊 query 有合理提升。等檢索明確是瓶頸再加。
第五層:生成
Claude 4.5 Sonnet 是 2026 年 RAG 生成的預設。它比 GPT-5 跟 Gemini 2.5 Pro 更會「只用提供的 context」,context 缺漏時較少幻覺,citation 比較乾淨。
GPT-5 在簡單 Q&A 上速度更快、價格相似品質下更便宜。高量、面對客戶、延遲 dominate 的 RAG 用它。
Gemini 2.5 Pro 在 context 巨大(1M+ token)時最強 — 那種場景有時候可以完全跳過檢索把整個 corpus 直接丟進去。中型文件集(10-50 個 PDF)可行,但不能 scale 到企業級知識庫。
DeepSeek 跟開源模型是成本受限或要自架時的選擇。品質好,但「不要幻覺、要引用 chunk」這類指令服從度比較弱。
什麼時候不適合做 RAG
如果你的整個知識庫總共不到 10 萬 token,直接全部貼進 LLM context 跳過檢索就好。現代長 context 模型處理沒問題、延遲可接受、整類檢索失敗的問題消失。
如果資料每幾秒就變(交易、即時分析),RAG 是錯的 pattern。用 SQL 或你既有的 query 層,給 LLM tool use 去查。
如果你沒有評估資料,你做的不是 RAG,是「帶檢索的願望思考」。先花一天做 50-100 個問題/期望答案的 pair 再調任何東西。
最小可行 stack
真的第一個專案的話:
- Loader:LlamaIndex
SimpleDirectoryReader或 LangChain document loader - Chunker:
RecursiveCharacterTextSplitter,500 token、50 重疊 - Embedder:OpenAI
text-embedding-3-small - Vector DB:pgvector 或 Qdrant
- Retriever:top-10 語義搜尋 + Cohere Rerank v3 → top-5
- Generator:Claude 4.5 Sonnet,系統 prompt 嚴格要求「只從 context 回答」
這個 stack 跑起來幾乎不花錢、一天能架好,在大部分場景上跟更複雜的解決方案有競爭力。
下一步
- 看一下 RAG 評估:怎麼量化你的 RAG 真的有用
- 關鍵字 query 多的話研究 hybrid search
- 探索 agentic RAG:讓 LLM 自己迭代檢索
- 看 chunk size 實驗 — 你的資料大概有個特定的最佳數字