什麼是 vector database（向量資料庫）？RAG 的鄰居

如果說 RAG 是「讓 LLM 回答前先去翻資料」，那 vector database 就是它常用的那間資料室。

但這個詞很容易被講成 AI 基礎建設神物：只要把文件丟進向量資料庫，AI 就會懂你公司。這不對。向量資料庫做的事其實很窄，也很重要：把資料變成向量後，快速找出「最相似」的幾筆。

它不是魔法記憶，也不是知識庫本身。它比較像一個會用語意距離排序的檔案櫃。

一句話定義

Vector database（向量資料庫）是用來儲存、索引、查詢 embedding 向量的資料庫或資料庫能力。它的核心查詢不是「完全符合哪個關鍵字」，而是「哪些向量離這個 query vector 最近」。

Embedding 會把文字、圖片、音訊或其他物件轉成一串數字，也就是向量。語意或特徵相近的物件，在向量空間裡通常距離也比較近。

所以當使用者問「怎麼申請退費？」時，系統可以先把這句話轉成向量，再去找文件庫裡距離最近的段落。就算原文件寫的是「退款流程」、「取消訂單後的款項處理」、「退貨金流」，向量搜尋仍有機會找回來。

這就是 vector database 的基本價值：讓搜尋從字面比對，升級成相似度比對。

它跟傳統資料庫差在哪

傳統 relational database 很擅長回答這種問題：

問題	適合工具
customer_id = 123 的訂單有哪些？	relational database
上個月台北門市營收多少？	SQL / analytics database
標題包含「退費」的文章有哪些？	keyword search
跟「客戶不想續約的原因」語意最接近的 10 段內部紀錄？	vector search

向量資料庫不是要取代 SQL。它補的是另一種查詢方式：相似性。

SQL 的世界裡，資料通常有明確欄位、型別和條件。Vector search 的世界裡，你常處理的是非結構化資料：文件、客服對話、產品描述、圖片、音訊、程式碼片段。你不知道使用者會用什麼字問，只知道要找「意思接近」的內容。

所以更精準的說法是：vector database 不是「新一代資料庫」，而是 AI 應用需要的檢索能力。

它怎麼運作

一個典型流程分成兩段。

索引階段：

1. 把文件切成 chunks
2. 用 embedding model 把每個 chunk 轉成向量
3. 把原文、metadata 和向量一起存進資料庫
4. 建立 vector index，讓相似度搜尋可以跑得快

查詢階段：

1. 使用者提出問題
2. 系統把問題也轉成 query embedding
3. 資料庫用 cosine distance、dot product 或 Euclidean distance 等方式找最近的向量
4. 回傳 top-K 結果，也就是最相似的幾段資料
5. 如果是 RAG，這些片段會被塞進 prompt，交給 LLM 生成答案

小資料量時，系統可以暴力比對每一筆向量。但資料一多，這會太慢。因此向量資料庫通常會用 HNSW、IVF 或其他近似最近鄰（approximate nearest neighbor）索引，在速度和召回率之間做取捨。

這裡的關鍵 trade-off 是：你不一定每次都拿到數學上絕對最近的那幾筆，但你換到足夠快、足夠穩的查詢速度。

它跟 RAG 的關係

Vector database 最常被提到，是因為 RAG。

RAG 的標準流程是：

文件 → chunk → embedding → vector database
問題 → embedding → 找相似 chunks → 塞進 prompt → LLM 回答

在這條鏈裡，vector database 負責 retrieval，不負責「理解全文」、不負責「判斷答案正不正確」，也不負責「產生文字」。

這個分工很重要。當 RAG 答錯時，問題可能出在不同層：

問題	可能壞掉的地方
沒找到正確資料	chunking、embedding、vector index、metadata filter
找到資料但排序不好	distance metric、hybrid search、reranker
找到正確資料但 LLM 答錯	prompt、模型能力、指令衝突
答案引用了不該看的資料	permission filter、tenant isolation、資料治理

所以不要把「我們有 vector database」等同於「我們有可靠 RAG」。向量資料庫只是其中一層，而且通常不是最難治理的那一層。

Vector search 不等於 keyword search

Keyword search 找的是字面重疊。Vector search 找的是語意接近。

兩者各有強項：

查詢型態	Keyword search	Vector search
精確型號、法條、料號	很強	可能不穩
同義詞、改寫、語意接近	容易漏	很強
需要可解釋排序	較容易	較難
多模態相似搜尋	不適合	適合
權限、日期、分類過濾	成熟	需要搭配 metadata filter

實務上，production RAG 很少只靠純 vector search。更常見的是 hybrid search：keyword search 先保住精確詞，vector search 補語意相似，再用 reranker 重排。

例如使用者問「合約裡的 force majeure 怎麼寫？」如果文件真的出現 force majeure，keyword search 很重要；如果文件寫的是「不可抗力條款」，vector search 又會比較有機會抓到。兩者不是互斥，而是互補。

專用向量資料庫，還是既有資料庫加 vector index

這是企業最容易花錯錢的地方。

你不一定需要一個獨立的向量資料庫產品。你需要的是「你的應用是否需要把向量搜尋當核心能力」。

情境	較務實的選擇
幾萬到幾十萬筆文件 chunks，主要是內部知識庫	既有 Postgres + pgvector 或雲端搜尋服務可能夠用
需要和大量 metadata、權限、交易資料一起查	先評估既有資料庫或搜尋平台的 vector 支援
上億級向量、低延遲、多租戶、向量搜尋是產品核心	專用 vector database 或專門 vector search 服務更合理
團隊還在驗證產品需求	先用簡單方案跑 eval，不要先買一套重 infra

pgvector 的存在說明了一件事：vector search 已經不只存在於「專用向量資料庫」。Postgres 可以透過 extension 支援向量欄位、距離運算和 HNSW / IVFFlat 索引。Azure AI Search、Google Cloud 的資料庫與搜尋服務，也都把 vector search 納入既有平台能力。

這不代表專用向量資料庫沒價值。當你的產品核心就是相似度搜尋、推薦或大規模 RAG，專用系統在效能、索引策略、水平擴展、multi-tenancy 和 operational tooling 上可能更合適。

判斷點不是「哪個比較 AI」。判斷點是：vector search 是你的主菜，還是配菜。

評估時看什麼

如果你真的要選 vector database 或 vector search 平台，至少看六件事。

第一，查詢品質。 用真實 query 測 recall@k，不要只看 demo。你的目標不是「能不能搜」，而是「前 5 筆有沒有包含人類認為正確的資料」。

第二，metadata filter。 企業場景通常要照部門、客戶、日期、權限、版本過濾。不能只找相似，還要先排除不該看的資料。

第三，hybrid search。 純 vector search 對精確詞不一定穩。能不能混合 BM25、filter、reranker，會直接影響 RAG 品質。

第四，索引更新成本。 文件每天變動時，新增、刪除、重建索引的成本是多少？換 embedding model 時，是否要整庫 re-embed？

第五，延遲與召回率取捨。 HNSW、IVF、量化等策略會影響速度、記憶體和準確率。不要只問 QPS，也要問 recall。

第六，治理。 向量不是無害的數字。它可能代表內部文件、客戶對話、醫療紀錄或商業機密。權限、刪除、稽核、資料 residency 都要一起設計。

對台灣團隊的實務判斷

台灣企業導入 AI 時，常會把 vector database 當成第一個採購項目。我的建議相反：先把問題定義清楚。

如果你只是要做內部 FAQ、客服知識庫、產品文件問答，先用最簡單的 RAG stack 跑起來：chunking、embedding、vector index、reranker、人工標註 eval set。等你證明 retrieval 真的能改善工作，再決定要不要換更重的資料庫。

如果你是軟體產品公司，向量搜尋會變成產品體驗的一部分，才值得早點認真選型。因為一旦資料量、權限模型和延遲要求上來，搬家成本會很高。

如果你是受監管產業，別只問「哪個 vector database 最準」。你更該問：資料能不能刪乾淨、誰看過什麼能不能稽核、embedding 供應商能不能符合資料政策。

收尾

Vector database 的核心不是「資料庫」，而是「相似度檢索」。

它讓 AI 系統能從一堆非結構化資料裡，找出語意最接近的幾段內容。這是 RAG、語意搜尋、推薦和多模態搜尋的重要基礎。

但它不是萬用解法。你仍然要處理資料品質、權限、chunking、embedding model、reranking 和評估。

一句話收斂：向量資料庫是 RAG 的隔壁，不是 RAG 本人。它負責找資料；答案能不能可信，還要看整條系統鏈。