快速回答：Vector Database 是什麼？

Vector Database（向量資料庫）是一種專門設計來儲存、索引和搜尋高維向量的資料庫。它讓你可以用「語意相似度」來找資料，而不只是靠關鍵字完全比對。現在做 RAG、語意搜尋、推薦系統，背後幾乎都需要向量資料庫。

向量資料庫的正式定義

向量資料庫是針對向量嵌入（Vector Embedding）進行最佳化的資料庫管理系統。它支援高效率的相似度搜尋操作，能在數百萬甚至數十億筆向量資料中，快速找出與查詢向量最相近的結果。

傳統資料庫用 B-tree 或 Hash Index 做精確查詢，向量資料庫則使用近似最近鄰（Approximate Nearest Neighbor, ANN）演算法，在速度和精確度之間取得平衡。

白話解釋

想像你走進一間圖書館。

傳統資料庫就像用書的編號去找書。你要知道確切的編號、書名或作者名字，才能找到你要的書。搜尋「狗」就只會找到標題裡有「狗」這個字的書。

向量資料庫比較像跟一個很懂書的館員說：「我想找跟《老人與海》氣氛類似的小說。」館員不用你給出確切書名，他理解你要的是那種孤獨、與自然搏鬥的故事感，然後推薦你幾本類似的書。

這就是「語意搜尋」和「關鍵字搜尋」的差別。向量資料庫把文字、圖片、音訊都轉成數學向量（一串數字），然後用數學方式算出哪些東西在意義上彼此接近。

向量資料庫 vs 傳統資料庫

比較項目 傳統資料庫（如 PostgreSQL） 向量資料庫（如 Pinecone）
搜尋方式 精確比對（WHERE name = 'X'） 相似度搜尋（最像 X 的前 10 筆）
資料型態 結構化資料（數字、字串、日期） 高維向量（浮點數陣列）
查詢語言 SQL 向量 + 篩選條件
索引結構 B-tree、Hash HNSW、IVF、PQ
典型用途 交易系統、CRUD 操作 語意搜尋、RAG、推薦
回傳結果 精確匹配的資料 按相似度排序的近似結果

兩者不是互斥的。很多場景是傳統資料庫和向量資料庫搭配使用，各自處理適合的查詢類型。

向量資料庫怎麼運作

Embedding：把資料變成向量

向量資料庫本身不會把文字變成向量，這個工作是 Embedding 模型的責任。你先用 Embedding 模型（如 OpenAI 的 text-embedding-3-small 或開源的 BGE）把文字轉成一組浮點數陣列，然後存進向量資料庫。

例如「台灣的夏天很熱」這句話，經過 Embedding 模型後可能變成一個 1536 維的向量：[0.023, -0.041, 0.087, ...]。語意相近的句子，轉出來的向量在空間中會彼此靠近。

想深入了解 Embedding 的原理，可以參考〈Embedding 是什麼？〉。

相似度搜尋

當你丟一個查詢進來，向量資料庫會計算查詢向量和資料庫中每個向量之間的距離。常見的計算方式有兩種：

Cosine Similarity（餘弦相似度）：看兩個向量的方向有多接近，數值從 -1 到 1，1 代表完全相同方向。大多數文字搜尋場景用這個。

Euclidean Distance（歐幾里得距離）：看兩個向量在空間中的直線距離。距離越小越相似。

你不需要自己寫這些計算，向量資料庫會幫你處理。你只需要決定用哪種距離函數。

索引結構

如果資料庫裡有一千萬筆向量，每次查詢都跟全部比對一次（暴力搜尋），速度會慢到不能用。所以向量資料庫用 ANN 演算法建立索引，犧牲一點點精確度來換取大幅提升的速度。

HNSW（Hierarchical Navigable Small World）：目前最主流的索引演算法。想像一個多層的圖結構，上層是粗略的跳躍，下層是精細的搜尋。查詢時從最上層開始，逐層往下找到最接近的結果。查詢快，但建索引時需要較多記憶體。

IVF（Inverted File Index）：把向量空間切成很多區域（cluster），查詢時先找出最可能的幾個區域，再只在那些區域裡搜尋。建索引快，適合資料量特別大的場景。

主流產品比較

產品 類型 開源 部署方式 適合場景
Pinecone 專用向量 DB 否 全託管雲端 快速上手、不想管基礎設施
Weaviate 專用向量 DB 是 自架 / 雲端 需要混合搜尋（向量+關鍵字）
Milvus 專用向量 DB 是 自架 / Zilliz Cloud 大規模生產環境、十億級資料
Qdrant 專用向量 DB 是 自架 / 雲端 Rust 寫的，效能好，API 設計乾淨
ChromaDB 嵌入式向量 DB 是 嵌入應用程式 原型開發、小規模專案
pgvector PostgreSQL 擴充 是 跟著 PostgreSQL 已經用 PostgreSQL，資料量 < 百萬

如果你已經在用 PostgreSQL，可以先試 pgvector。資料量在幾百萬筆以下，pgvector 就夠用了，不需要額外維護一套系統。

資料量大、查詢頻率高、需要更細緻的索引策略時，再考慮專用的向量資料庫。

實際應用場景

RAG（檢索增強生成）

這是目前向量資料庫最常見的用途。流程是：把企業文件切成小段（chunk），用 Embedding 模型轉成向量存入資料庫。使用者提問時，先用向量搜尋找出最相關的文件段落，再把這些段落餵給 LLM 作為上下文來回答問題。

這解決了 LLM 知識過時和幻覺的問題，讓 AI 能根據你的私有資料回答問題。

語意搜尋

傳統搜尋引擎靠關鍵字比對，使用者搜「頭痛怎麼辦」可能找不到寫著「偏頭痛的緩解方法」的文章。語意搜尋用向量來理解意思，就算措辭不同，只要語意相近就能找到。

推薦系統

把商品、文章、影片都轉成向量。使用者瀏覽過的內容也轉成向量。找出在向量空間中離使用者偏好最近的商品，就是推薦結果。

異常偵測

正常的系統日誌、網路封包轉成向量後，會集中在某個區域。如果有一筆資料的向量離群太遠，很可能是異常行為。這在資安監控和工業物聯網中很實用。

什麼時候需要向量資料庫

你可能需要向量資料庫的情境：

  • 關鍵字搜尋已經不夠用，使用者用不同措辭描述同一件事
  • 正在建 RAG pipeline，需要語意檢索企業知識庫
  • 想做「找相似」的功能（相似圖片、相似文章、相似產品）
  • 資料是非結構化的（文字、圖片、音訊），傳統 SQL 查詢派不上用場

你可能還不需要的情境：

  • 資料量很小（幾千筆），暴力搜尋就夠快
  • 查詢都是精確比對（查訂單編號、查使用者 ID）
  • 只需要全文搜尋，Elasticsearch 就能解決

安全與風險

使用向量資料庫時需要注意幾個安全面向。

Embedding 洩漏：向量看起來只是一串數字，但研究已經證明，可以從 Embedding 向量反推出原始文字的大致內容。如果向量資料庫被攻破，裡面的資料等於間接曝光。

存取控制：誰可以查詢哪些向量？RAG 系統如果沒有做好權限區隔，一般員工可能透過語意搜尋取得主管才能看到的機密文件。

資料投毒：攻擊者如果能在你的知識庫中插入惡意內容，這些內容會被切 chunk、做 embedding、存進向量資料庫。之後使用者提問時，被污染的內容就會被檢索出來，影響 LLM 的回答。

供應商綁定：不同向量資料庫的 Embedding 格式和索引結構不完全相容。如果未來要換產品，遷移成本不低。建議從一開始就把 Embedding 生成邏輯和向量資料庫存取邏輯分開，降低耦合度。

台灣使用情境

台灣企業在選擇向量資料庫時，有幾個特殊考量。

資料落地（Data Residency）：金融業和醫療業的資料通常不能出境。全託管的雲端向量資料庫（如 Pinecone）目前沒有台灣區域。需要資料落地的企業，通常選擇 Milvus 或 Qdrant 自架在台灣的雲端或地端。

中文支援：中文的 Embedding 品質很依賴模型的選擇。目前 OpenAI 的 text-embedding-3 系列對繁體中文支援不錯，開源的 BGE-M3 也是熱門選擇。不過在測試時建議用繁體中文語料評估，別只看英文的 benchmark 分數。

企業導入現況：根據 2026 年的觀察，台灣中大型企業建 RAG 系統時，pgvector 和 Milvus 是最常見的選擇。小型團隊或新創則偏好 ChromaDB 做原型，確認可行後再遷移到正式環境。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題 FAQ

向量資料庫和 Elasticsearch 有什麼不同？

Elasticsearch 主要做全文搜尋（BM25 演算法），以關鍵字頻率和位置來排序結果。向量資料庫做語意搜尋，用向量距離來排序。Elasticsearch 在 8.x 版後也加入了向量搜尋功能，但專用的向量資料庫在大規模向量查詢的效能上通常更好。

pgvector 夠用嗎？

看你的資料規模。百萬筆以下，pgvector 的效能足夠，而且你可以同時享受 PostgreSQL 的 ACID 事務保證和關聯查詢能力。超過千萬筆或需要極低延遲（< 10ms），建議評估專用向量資料庫。

Embedding 維度越高越好嗎？

不一定。維度高代表能捕捉更多語意細節，但也意味著更大的儲存空間和更慢的搜尋速度。1536 維（OpenAI 預設）對大多數應用已經夠用。有些場景用 256 或 384 維的 Embedding 就能達到不錯的效果，而且搜尋速度快很多。

向量資料庫需要 GPU 嗎？

查詢階段通常不需要 GPU，CPU 就能高效執行 ANN 搜尋。但如果你要自己跑 Embedding 模型來生成向量，那個步驟會需要 GPU 加速。

能不能把向量資料庫當唯一的資料庫？

不建議。向量資料庫擅長相似度搜尋，但不適合做精確查詢、交易處理或複雜的關聯查詢。實務上是和傳統資料庫搭配，各司其職。

怎麼評估向量搜尋的品質？

用 Recall@K 指標。準備一組測試查詢和已知的正確答案，看向量搜尋回傳的前 K 筆結果中，命中了幾個正確答案。一般希望 Recall@10 達到 90% 以上。

向量資料庫的資料會過期嗎？

向量本身不會過期，但如果你換了 Embedding 模型（例如從舊版升級到新版），舊向量和新向量之間的相似度計算會不準確。換模型時，通常需要把所有資料重新做 Embedding。

參考資料