RAG 之前你該知道的事：四種資料檢索方法完整比較
想導入 RAG 之前，先搞懂底層在做什麼。向量搜尋、BM25、Hybrid Search、知識圖譜 — 四種資料檢索方法的原理、適用場景和 trade-off 完整比較。結論：大部分企業場景用 Hybrid Search 就夠了。
為什麼要理解檢索原理？
RAG（Retrieval-Augmented Generation）這個詞現在到處都聽到，但大部分人對它的理解停留在「讓 AI 能查資料」。問題是，「查資料」這件事本身就有很多不同的做法，每種做法的效果差很大。
你不需要自己寫演算法，但你需要知道每種檢索方法的強項和弱點，才能在技術選型時做出正確判斷。這篇把四種主流方法的原理用白話講清楚。
向量搜尋（Vector Search）
核心概念：比對「意思」而不是比對「文字」
傳統搜尋是比對文字本身 — 查詢和文件有多少相同的字詞。但「伺服器過熱」跟「散熱模組需要維護」沒有任何共同字詞，傳統方法會認為它們毫不相關。
向量搜尋換了一個思路：不比對文字，比對意思。
做法是把文字轉成一組數字，這組數字叫做 embedding（嵌入向量）。一段文字經過 embedding model 處理後，會變成一個高維度的數字陣列，比如 768 個數字。這 768 個數字代表這段文字在「意義空間」裡的座標位置。
意思相近的文字，座標會靠近。「伺服器過熱」和「散熱模組維護」的向量座標很接近，而「今天午餐吃什麼」跟它們差很遠。搜尋時把問題也轉成向量，然後在資料庫裡找座標最近的幾段文字。「最近」用的是餘弦相似度（cosine similarity），本質上就是算兩個向量的夾角 — 夾角越小越相似。
Embedding Model 怎麼學會理解「意思」？
Embedding model 是一個神經網路，在大量文字上訓練過。訓練方式大致是：給它看大量「這兩句話意思相近」和「這兩句話意思不同」的例子，讓它學會把相近的句子映射到接近的座標。不同的 embedding model 訓練資料不同，所以對不同語言和領域的效果也不同。這就是為什麼選 embedding model 是一個有意義的決策，不是隨便選一個就好。
向量資料庫的角色
如果只有 100 段文字，每次搜尋逐一比對就好。但有 100 萬段時，逐一比對太慢。向量資料庫做的事是建立索引（index），讓搜尋可以跳過大部分不相關的向量，直接找到最近的幾個。常見的索引方法如 HNSW（Hierarchical Navigable Small World），讓搜尋速度從秒級變成毫秒級。
ChromaDB、Pinecone、FAISS 做的都是這件事，差別在部署模式：FAISS 是純 library（要自己管理儲存），ChromaDB 是輕量級資料庫（本地跑，幫你管儲存），Pinecone 是雲端託管（不用管基礎設施但需要付費）。
BM25 / 關鍵字搜尋
核心邏輯：字詞出現頻率 + 稀有度加權
BM25（Best Matching 25）是 1994 年發明的演算法，到現在仍在廣泛使用。它的邏輯是：一個字詞在一份文件裡出現越多次，這份文件越可能跟包含這個字詞的查詢相關。但有兩個關鍵修正：
第一，IDF（Inverse Document Frequency）。如果一個字詞在所有文件裡都很常見（像「的」、「是」、「一個」），它的區分度很低，權重要降低。越罕見的字詞越有區分價值。
第二，長度正規化。文件越長自然包含越多字詞，要做正規化，不讓長文件佔便宜。
BM25 vs 向量搜尋的核心差異
BM25 比對的是字詞本身。查詢裡有「部署」，它就找包含「部署」這兩個字的段落。如果文件寫的是「上線流程」而不是「部署」，BM25 找不到。
向量搜尋比對的是語義。「部署」和「上線流程」的 embedding 會很接近，所以能找到。
但反過來，如果查的是特定名詞，比如「ChromaDB」或「v1.0-pre-migration」，向量搜尋可能找到語義相近但不是這個東西的段落，而 BM25 的精確匹配反而更準。
簡單說：向量搜尋贏在「理解意思」，BM25 贏在「精確匹配」。兩者互補，這就是為什麼需要 Hybrid Search。
Hybrid Search：兩個互補的搜尋合在一起
合併邏輯：Reciprocal Rank Fusion（RRF）
向量搜尋找到了 top-10 段落，BM25 也找到了 top-10 段落。兩個清單有部分重疊、部分不同。怎麼合併成一個最終清單？
最常用的方法叫 RRF（Reciprocal Rank Fusion）。邏輯很直覺：一個段落在某個搜尋結果裡排名越前面，分數越高。如果同時在兩個搜尋結果裡都排很前面，分數就更高。
具體公式是 score = 1 / (k + rank)，k 是一個常數（通常設 60），rank 是排名。把兩個搜尋結果的分數加起來，重新排序，取 top-K。
這方法的好處是不需要校準兩個搜尋的分數。向量搜尋的餘弦相似度跟 BM25 的分數量級完全不同，直接比沒意義。RRF 只用排名來合併，繞過了這個問題。
知識圖譜（Knowledge Graph）
核心概念：三元組 + 關係推理
知識圖譜把資訊拆成三元組：主體 → 關係 → 客體。比如從一堆文件裡可以抽出：
- gwarket → 使用技術 → Next.js
- gwarket → 部署在 → Cloudflare Pages
- Blog-Writer → 拆分成 → 文章寫手
- 文章寫手 → 輸出格式 → WordPress HTML
這些三元組形成一個圖（graph），節點是實體，邊是關係。查詢時可以沿著邊遊走 — 比如問「gwarket 用了什麼技術？」就是從 gwarket 節點出發，找所有「使用技術」的邊。
知識圖譜 vs 向量搜尋
向量搜尋擅長「這段文字跟問題像不像」，但不擅長「A 跟 B 之間有什麼關係」。知識圖譜擅長關係推理和多跳推理 — 比如「gwarket 用了 Next.js → Next.js 部署在 Cloudflare Pages → 所以 gwarket 部署在 Cloudflare Pages」，這種跨多個節點的推理是向量搜尋做不到的。
但知識圖譜的代價是：你需要先從非結構化文字裡把三元組抽出來（extraction）。這個步驟用 LLM 抽取的品質不穩定，會有漏抽和錯抽。而且圖譜的查詢語言比向量搜尋複雜得多。
為什麼 GraphRAG 很紅但大部分團隊不用？
因為 ROI 不對。建圖譜的成本高（每份文件都要用 LLM 處理來提取實體和關係，這步驟本身就大量消耗 API token），維護成本也高（新文件進來要重新跑提取）。而對大多數企業的問答場景，向量搜尋 + BM25 已經能處理 80-90% 的問題。知識圖譜解決的是那最後 10-20% 需要多跳推理的場景。
四種方法的比較與選型建議
| 維度 | 向量搜尋 | BM25 關鍵字 | Hybrid Search | 知識圖譜 |
|---|---|---|---|---|
| 擅長 | 語義理解、同義詞 | 精確名詞、代碼搜尋 | 兼顧語義與精確 | 多跳推理、關係查詢 |
| 弱點 | 特定名詞可能失準 | 語義歧義致命 | 需維護兩套索引 | 建置維護成本極高 |
| 建置成本 | 中（需 embedding + 向量 DB） | 低（成熟工具多） | 中高 | 高（LLM 抽取 + 圖 DB） |
| 適用規模 | 中大型知識庫 | 任何規模 | 中大型知識庫 | 大型、關係密集型 |
| 典型場景 | 客服問答、文件搜尋 | 程式碼搜尋、日誌查詢 | 企業知識庫 RAG | 醫療、法律、供應鏈 |
我的觀點
對大部分企業場景，Hybrid Search 就是最務實的選擇。它用向量搜尋補 BM25 的語義盲點，用 BM25 補向量搜尋的精確匹配不足，RRF 合併邏輯簡單且不需要調參。
知識圖譜在概念上很吸引人，但現階段的建置成本和維護複雜度，讓它只適合特定場景 — 比如醫療診斷需要沿著症狀→疾病→藥物的路徑推理，或是法律條文需要追溯條文之間的引用關係。如果你的場景是「員工問問題、系統從文件庫裡找答案」，Hybrid Search 已經足夠。
技術選型最怕的不是選錯，而是過度設計。在你驗證 Hybrid Search 真的不夠用之前，不需要跳到知識圖譜。
常見問題 FAQ
Embedding Model 該怎麼選？
看你的語言和領域。如果知識庫是中英文混合，選多語言模型（如 Voyage AI 的多語言版或 OpenAI 的 text-embedding-3）。如果是特定領域（醫療、法律），優先選有該領域資料訓練過的模型。沒有絕對最好的模型，只有最適合你資料特性的模型。
向量資料庫該選哪個？
看你的部署需求。原型驗證用 ChromaDB（本地跑、設定簡單）。生產環境如果不想管基礎設施，用 Pinecone 或 Weaviate Cloud。如果團隊有 DevOps 能力且資料量大，自建 Qdrant 或 Milvus。小型專案用 FAISS 就夠了。
Hybrid Search 裡向量和 BM25 的權重怎麼調？
用 RRF 的好處就是不太需要調權重。如果真的要調，可以在 RRF 公式前加一個係數，比如 α * vector_score + (1-α) * bm25_score，α 設 0.5 開始，根據實際檢索效果微調。但多數情況下，預設的 RRF 就夠用了。