向量資料庫原理：RAG 背後的存儲與檢索機制深度解析

那個讓 RAG 從 2 秒降到 80ms 的索引

2026 年 3 月 28 日，晚上 11:43。小刺蝟在群組發了一條告警：「API 回應時間 P99 = 2.3s，超出閾值 10 倍。」

我查了日誌，問題出在 RAG 檢索環節。每次用戶提問，系統都要在 1200 篇筆記裡做向量相似度搜索，全量掃描需要 1.8 秒。

小獵鷹建議：「上 HNSW 索引。」

48 小時後，回應時間降到 80ms。用戶無感知，但服務器 CPU 使用率從 73% 降到 31%。

這背後是向量資料庫在幹活。今天拆解給你看。

向量資料庫到底存了什麼

先說一個反直覺的事實：向量資料庫不存「向量」，存的是「向量 + 元數據 + 索引結構」。

三種主流索引算法對比

1. HNSW（分層導航小世界）

原理：構建多層圖結構，上層是「高速公路」，下層是「本地街道」。

性能：O(log N) 查詢時間，高內存，95-99% 準確率。

SFD 實測：1200 篇筆記，P50=67ms，P99=143ms，2.3GB 內存。

2. IVF（倒排文件索引）

原理：先聚類，再搜索。K-Means 聚成 100 個簇，只搜索最近 3 個。

性能：O(N/K)，低內存，85-95% 準確率。

3. PQ（乘積量化）

原理：向量壓縮。768 維→8 字節。384:1 壓縮率。

性能：O(1)，70-85% 準確率。

為什麼 HNSW 贏了

1. 延遲是硬指標（200ms 上限）
2. 數據量不大（2.3GB 可接受）
3. 增量更新友好

實戰：用 Qdrant 搭建 RAG 檢索服務

docker run -d -p 6333:6333 qdrant/qdrant

創建集合（指定 HNSW 配置），插入向量，帶元數據過濾檢索。

踩坑記錄

坑 1：維度不匹配—刪除集合重新創建。
坑 2：距離度量選錯—從歐氏距離改成餘弦相似度。
坑 3：忘記持久化—掛載 Docker 卷。

SFD 編者註

向量資料庫是 RAG 系統的「心臟」，但大多數人只關注 LLM（大腦）。

我們花了 3 週時間調優 HNSW 參數，把 P99 延遲從 890ms 壓到 143ms。用戶無感知，但服務器成本每月省了 200 美元（可以降級實例規格）。

這件事教會我：基礎設施的優化，往往比模型升級帶來的收益更直接。

你不需要 GPT-5，你需要一個不卡頓的 RAG 檢索。