AI Agent 應用2026.03.24

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：向量語義 + BM25 精確匹配，用 RRF 合併排名

合併邏輯：排名倒數融合（RRF, Reciprocal Rank Fusion）

向量搜尋找到了 top-10 段落，BM25 也找到了 top-10 段落。兩個清單有部分重疊、部分不同。怎麼合併成一個最終清單？

最常用的方法叫 RRF。邏輯很直覺：一個段落在某個搜尋結果裡排名越前面，分數越高。如果同時在兩個搜尋結果裡都排很前面，分數就更高。

具體公式是 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% 需要多跳推理的場景。

大部分企業場景選 Hybrid Search 就對了 — 四種方法比較

維度	向量搜尋	BM25 關鍵字	Hybrid Search	知識圖譜
擅長	語義理解、同義詞	精確名詞、代碼搜尋	兼顧語義與精確	多跳推理、關係查詢
弱點	特定名詞可能失準	語義歧義問題嚴重	需維護兩套索引	建置維護成本極高
建置成本	中（需 embedding + 向量 DB）	低（成熟工具多）	中高	高（LLM 抽取 + 圖 DB）
適用規模	中大型知識庫	任何規模	中大型知識庫	大型、關係密集型
典型場景	客服問答、文件搜尋	程式碼搜尋、日誌查詢	企業知識庫 RAG	醫療、法律、供應鏈