Vector Database 是什麼？它不是把資料變成向量的地方

假設你有五萬段文件，現在問系統：「退款超過七天還能處理嗎？」如果只靠關鍵字搜尋，文件裡寫的是「逾期退貨」而不是「超過七天」，可能就不容易被找到。另一種做法，是先用 embedding model 把每段文字轉成向量，再把問題也轉成同一個向量空間中的表示，接著找出距離最近的文件。

Vector Database 可以先理解成：特別擅長保存向量，並依照向量相似度快速搜尋資料的資料系統。 它本身通常不負責「理解文字」或「產生 embedding」。真正把內容轉成向量的是 embedding model；Vector Database 接手的是儲存、索引、查詢，以及把找到的向量重新對回原本的文件、圖片或其他資料。

一般資料庫問的是「哪筆資料符合條件」

傳統關聯式資料庫很擅長精確條件。你可以找出 user_id = 42 的使用者、價格小於 500 的商品，或日期落在某個區間的訂單。這些條件通常有明確的欄位與比較規則：等於、不等於、大於、小於，或文字完全匹配。

向量搜尋處理的問題不同。它更常問：「哪幾筆資料和這個查詢最接近？」這裡的「接近」不是看字串長得像不像，而是看兩個向量在某種距離或相似度度量下有多靠近。常見做法包括 cosine similarity、dot product 與 Euclidean distance。實際用哪一種，要看 embedding 模型與系統設計。

真正困難的地方，是在很多向量裡找鄰居

如果資料只有一百筆，最直接的方式是拿查詢向量和每一筆向量都算一次距離，再排序找出最近的幾個。這叫 exact nearest neighbor search，概念很單純；但資料變成幾百萬、幾千萬筆之後，每次都全部比較，成本就會快速上升。

因此很多向量系統會建立專門的 index，使用 approximate nearest neighbor（ANN）演算法，加速「找最接近向量」這件事。名字裡的 approximate 很重要：它通常用一點點精確度交換更高的搜尋速度與更低的成本。不同系統可能採用 HNSW、IVF 或其他索引策略，而參數選擇也會影響速度、記憶體使用量與 recall。

pgvector 就是一個很好的例子。它不是獨立的新資料庫，而是 PostgreSQL 的 extension，讓 Postgres 可以儲存 vector 型別並進行向量相似度搜尋，也支援 exact 與 approximate nearest-neighbor search。這也說明了一件事：需要 vector search，不代表你一定得再部署一套獨立的「Vector Database」產品。

向量旁邊通常還要存 Metadata

只有相似度往往不夠。假設知識庫同時放了台灣、日本與美國三個市場的退款規則，使用者問台灣政策時，你不希望系統因為文字很像，把日本版本一起撈回來。因此向量旁邊通常會帶 metadata，例如文件 ID、語言、日期、產品、權限範圍或資料來源。

搜尋時就可以先限制條件，再做 vector similarity search，例如「只搜尋 zh-TW、產品 A、目前有效版本」。這是實務上很重要的一層，因為語意上相近的資料不一定在業務規則上適用。相似度只是搜尋訊號，不是真實性、權限或有效性的保證。

它為什麼常和 RAG 一起出現？

RAG 的核心，是模型回答以前先去外部資料來源找相關內容。當文件很多，而且希望依照語意而不是只靠關鍵字找資料時，常見流程就是先把文件切成 chunks，產生 embeddings，存進支援向量搜尋的資料庫；收到問題後，再把問題轉成向量，找出最相關的幾個 chunks，最後放進 context window 讓語言模型回答。

這也是為什麼 Vector Database 和 LLM 其實是兩個不同角色。資料庫不負責生成答案；LLM 也通常不會自己掃完整個向量索引。中間還需要應用程式決定怎麼切資料、用哪個 embedding model、取回幾筆、是否加 metadata filter，以及最後怎麼把內容塞進 prompt。

Vector Database 不是 RAG 的必要條件

「做 RAG 就一定要 Vector Database」也是常見誤解。如果資料量很小，直接搜尋、全文索引甚至手動選文件都可能夠用；有些資料庫本身已經能加上向量欄位與索引，也不需要另外維護一套服務。真正該問的不是「我要不要上 Vector Database」，而是「我的資料量、更新方式、查詢需求與延遲要求，需要什麼搜尋方法」。

反過來說，Vector Database 也不只用在 RAG。任何需要「找相似項目」的場景都有可能使用向量搜尋，例如相似圖片、商品推薦、重複內容偵測、語意搜尋與異常資料探索。LLM 只是讓這個概念在近年的應用裡變得特別常見。

Vector Database 和 Embedding 最容易搞反

Embedding 是資料的向量表示；Vector Database 是管理和搜尋這些表示的系統。換 embedding model 時，同一段文字產生的向量空間可能完全不同，因此舊向量通常不能直接和新模型產生的向量混著比較。這也是為什麼實務上需要記錄 embedding model、版本與維度，而不是只把一串浮點數丟進資料庫就結束。

所以如果只記住最後一句：Vector Database 不負責讓資料「有意義」；它負責讓已經被表示成向量的資料，可以被有效保存、篩選與搜尋。 Embedding 決定資料怎麼被表示，Vector Database 決定這些表示之後怎麼被找到，而 RAG 則決定找到的內容怎麼進入模型回答。