向量資料庫Vector Database

它在做什麼

一般資料庫用「等於」「大於」這類條件查資料，向量資料庫查的是「哪些內容在意義上最接近」。

1. 1

   文件先轉成向量

   透過 embedding 模型，把每一段文字轉成一組數字（向量）。意思相近的文字，向量在空間中的位置也相近。

2. 2

   向量存進資料庫並建立索引

   為了能在大量資料中快速搜尋，向量資料庫會建立特殊的索引結構，而不是逐筆比對。

3. 3

   查詢時把問題也轉成向量

   使用者的問題同樣經過 embedding 模型，變成一組向量。

4. 4

   找出距離最近的幾筆

   資料庫計算問題向量和所有已存向量之間的距離，回傳最接近的幾筆結果。

為什麼需要專門的資料庫

理論上，把向量存進一般資料庫、寫程式逐筆算距離也能做到同樣的事，資料量小的時候確實可行。但資料量一大就會遇到問題：

• 暴力比對太慢。 幾百萬筆向量，逐一計算距離的成本會直線上升，回應時間變得無法接受。
• 需要專門的索引結構。 向量資料庫用近似最近鄰演算法，用極小的精確度損失換取大幅提升的搜尋速度，這是一般資料庫的索引機制做不到的。
• 需要搭配結構化條件過濾。 實務上常需要「語意相近，而且分類是 A、日期在某範圍內」這種複合查詢，向量資料庫通常內建支援。

實際會怎麼用

最常見的場景是 RAG：把公司內部文件全部轉成向量存進向量資料庫，使用者提問時先用向量資料庫找出最相關的幾段，再把這些段落連同問題一起交給語言模型生成答案。

其他常見用途：

• 語意搜尋：搜尋「意思相近」而不只是「關鍵字相同」的內容，例如客服知識庫。
• 推薦系統：找出和使用者過去偏好向量相近的商品或內容。
• 重複內容偵測：找出語意高度相似的文件或訊息。

常見的坑

只看向量距離，不看時效與權重。 語意最相近的內容不一定是最該優先呈現的內容，實務上常需要額外加上時間、來源可信度等權重調整排序。

切分方式沒調好，檢索品質就先輸了。 向量資料庫本身再快，如果前端把文件切得七零八落、破壞語意完整性，搜尋結果照樣不準。

忽略混合搜尋。 純向量搜尋在處理專有名詞、型號、代碼這類需要精確比對的內容時表現不佳，混合關鍵字搜尋與向量搜尋通常比單用其中一種穩定。

延伸閱讀：Embedding 是什麼、RAG 完整說明、Inference 是什麼。