Enter your search text in the box above

Select a result to preview

向量資料庫 (Vector Database)

#search-and-ai #vector-database #system-design
一句話定位

傳統資料庫擅長精確查詢（user_id = 123）；向量資料庫擅長相似度搜尋（「找出和這篇文章語意最接近的 10 篇」）。
本質：它是一種索引，不是真理來源。核心技術是 ANN（Approximate Nearest Neighbor）。

什麼是 Embedding（向量）

把任意東西（字、句、圖、用戶、商品）丟進 ML 模型 → 轉成一組數字陣列。

"The cat sat on the mat"   → [0.12, -0.34, 0.78, ...]  (1536 維)
"A feline rested on a rug" → [0.11, -0.32, 0.79, ...]  幾何上非常接近 → 語意相似
"The stock market crashed" → [-0.89, 0.12, -0.45, ...] 差很遠

相似度怎麼算

度量 機制 備註
Euclidean (L2) 高維畢氏定理，距離越小越相似 考慮方向與大小
Cosine Similarity 看夾角（同向 1 / 垂直 0 / 反向 -1） 多數 embedding 已 normalize，最常用
Dot Product 類 cosine 但不 normalize 計算稍快
Hamming binary 向量 XOR 後數 bit 差異 非常快
面試話術

infra 型題目只要說「我們用 cosine similarity 或適合該模型的 metric」通常就夠了。

KNN → ANN：核心取捨

KNN（K-Nearest Neighbors）暴力解：對每個向量算相似度、排序、取前 K → O(n)。

1M 向量 × 1536 維，每次 query 約 60 億次浮點運算，即使 SIMD/GPU 也不夠。

ANN：容忍「不是完全準確」，找到 95%+ 就夠。向量資料庫本質就是讓你在三者間平滑調整：

        Recall（準確率）
           ▲
           │      三者互相拉扯，
   Latency │      向量 DB = 在這個三角形裡找平衡點
（延遲）────┴──── Memory（索引記憶體）

索引演算法

演算法 概念 優點 缺點
HNSW 高維 skip list；多層 graph，稀疏層當高速通道 O(log n)、95%+ recall、低延遲 記憶體大（≈原始 ×2）、建索引慢、插入貴
IVF k-means 分群，查詢只搜最近的幾個 cluster 建索引快、插入簡單、記憶體小 recall 通常比 HNSW 低
LSH 隨機 hyperplane 讓相似向量落同 bucket 建索引快、適合 streaming 實務 recall 不如 HNSW
HNSW 是預設答案

「使用 HNSW，多層 graph，從稀疏層往密集層 greedy search。」除非有特定限制（寫入極頻繁、規模極大、記憶體受限），HNSW 通常是正解。IVF 的 nprobe 越高 → recall 越高但越慢。

實務查詢很少是「找最相似的 10 個」，通常加條件：「而且 in stock、價格 < $100、今年發布」。

策略 做法 問題
Post-filter 先找 top-N 再過濾 過濾後可能不足 K 個
Pre-filter 先過濾再向量搜尋 索引可能無法有效套用

各系統做法：pgvector 走 query planner（可能 brute force）；Elasticsearch 在 HNSW traversal 中整合 filter，支援 BM25 + vector hybrid search；Pinecone 把 metadata 當 first-class，索引內同時處理。

實務選型：先簡單

原則：不要一開始就用專門向量資料庫

很多人低估了多維運一套新系統的複雜度。

規模 / 需求 選擇
已有 Postgres pgvector（支援 HNSW/IVF、可 JOIN、ACID）
需要 hybrid search Elasticsearch kNN
低延遲 Redis Vector Search
專門（> 100M 向量） Pinecone（managed）/ Weaviate / Milvus（billions）/ Qdrant（過濾強）/ Chroma（prototype/RAG）

面試常見場景（幾乎必用向量 DB）

三種架構模式

模式 做法
獨立服務 應用送 embedding → 向量服務回 ID → 再去主 DB 查完整資料（關注點分離，最常見）
Hybrid search 同時送關鍵字索引 + 向量索引，用排序函數合併
Two-stage 第一階段向量搜回 top-1000 候選，第二階段用較慢的 reranker 重排

關鍵設計決策

Numbers to Know

指標 數字
維度 常見 128–1536（OpenAI 1536，開源常 384/768）
單向量記憶體 float32 每維 4 bytes → 1536 維 ≈ 6KB（比直覺大）
100 萬向量 原始 ≈ 6GB，HNSW 索引再 ×2
查詢延遲 調校良好 < 10ms，常見 1–5ms
Recall 目標 95%+ 通常可接受（99%+ 要犧牲延遲/記憶體）
吞吐 索引常駐記憶體時，每節點每秒數萬次查詢合理

常見陷阱

向量資料庫不是交易型資料庫

不要當系統唯一 source of truth。權威資料放主 DB，向量 DB 只是索引。

  • Embedding drift：換 embedding 模型 → 舊向量全失效不相容，要全部重產（成本高）或維護多套索引。API 要帶「哪個模型產生此 embedding」。
  • Cold start：用行為產生 embedding 的推薦，新用戶無資料 → 需 fallback。
  • 索引建構慢：1000 萬筆 HNSW 可能要一小時+，影響部署/災難復原速度。
  • 不是精確匹配：要用 ID 找文件就用一般 DB；向量搜的是「相似」不是「相同」。