[後端] 向量資料庫是什麼？跟一般資料庫差在哪

前言

這陣子，如果你有在關注 AI、尤其是大型語言模型（LLM）的應用，肯定會一直聽到一個名詞：「向量資料庫」（Vector Database）。什麼 RAG 要用向量資料庫、推薦系統要用向量資料庫、連圖片搜尋也跟向量資料庫有關……搞得好像它無所不能一樣。

欸，但是它到底是什麼？跟我們平常在用的 MySQL、PostgreSQL、MongoDB 這些傳統資料庫有什麼不同？難道這些老牌資料庫不能用嗎？為什麼突然間大家都跳出來說向量資料庫很屌？

今天，Hikari 我就來用最白話的方式，跟大家聊聊向量資料庫到底在幹嘛，還有它為什麼會在 AI 時代這麼重要。

所以，什麼是「向量」？

要搞懂向量資料庫，首先要理解什麼是「向量」（Vector）。在數學上，向量就是一個有方向、有大小的量，通常用一串數字來表示。你高中物理可能學過位移、速度是向量對吧？

但在 AI 的世界裡，它更像是一種「特徵的數位化表示」。

想像一下，你想描述一個人。你可以說他「身高 175 公分、體重 70 公斤、年齡 30 歲」。如果把這些數字排成一串 [175, 70, 30]，這就是一個很簡單的「向量」了。這個向量代表了這個人的某幾個特徵。

那 AI 怎麼用呢？

今天不管是文字、圖片、聲音，甚至是影片，AI 模型都能把它們「轉化」成一串數字，也就是「嵌入」（Embedding）。這個嵌入，就是一個高維度的向量。這個向量的神奇之處在於，如果兩個東西的意義或內容很「相似」，它們轉換出來的向量在數學空間上也會「靠得很近」。

舉個例子：

「貓」這個字的向量：[0.1, 0.5, -0.3, ...]
「貓咪」這個字的向量：[0.12, 0.48, -0.31, ...] (很接近)
「狗」這個字的向量：[0.6, -0.2, 0.8, ...] (也算動物，但比貓遠一點)
「電腦」這個字的向量：[-0.9, 0.05, 0.1, ...] (差很遠)

你看，傳統的電腦是認不出「貓」跟「貓咪」很像的，它們是兩個不同的字串。但透過向量，AI 就能理解它們在語意上是很接近的。

graph TD
    A[原始資料: 文字/圖片/聲音] --> B[AI 模型 (Encoder/Embedding Model)]
    B --> C{向量 (Embedding)}
    C --> D[由一串數字組成的多維度陣列]
    D -- 語意相似度 --> E[數學上距離相近]
    D -- 語意不相似度 --> F[數學上距離遙遠]

傳統資料庫為什麼不夠用？

好了，既然這些向量就是一串數字，我們不能直接存到傳統資料庫嗎？當然可以啊！你可以開一個 TEXT 或 BLOB 欄位存 JSON 格式的向量，或者開一堆 FLOAT 欄位來存每個維度。

問題來了，你存進去了，然後呢？

傳統資料庫最擅長的是「精確比對」（Exact Match）和「結構化查詢」（Structured Query）。例如：

SELECT * FROM users WHERE age > 30 AND gender = 'male'; (精確篩選)
SELECT * FROM products WHERE name LIKE '%手機%'; (字串比對)

但如果你想做的是：「找出所有跟『貓』這張圖片『很像』的圖片」，或者「找出所有跟這段文字『語意相關』的文件」，傳統資料庫就整個當機了！

為什麼？因為它沒有辦法理解「相似」的語意，它只認得精確的字串、數字、日期。你不可能用 LIKE '%貓%' 找到「貓咪」的圖片，更不可能找到「喵星人」的圖片。你需要的是「相似度搜尋」（Similarity Search），而不是精確比對。

這時候，你就需要向量資料庫了。

向量資料庫怎麼辦到的？核心原理拆解

向量資料庫厲害的地方，就是它專門為「相似度搜尋」而生。它的核心原理很簡單：

儲存向量： 它就是一個用來儲存大量高維度向量的資料庫。
快速搜尋「最近鄰」： 當你給它一個查詢向量（Query Vector），它能非常有效率地找出資料庫中「距離這個查詢向量最近」的那些向量。距離越近，就代表語意越相似。

那它是怎麼找到「最近鄰」的呢？如果每個向量都跟資料庫裡所有向量計算一次距離，那資料量一大，速度就會慢到哭爸。這就是傳統資料庫做不到的原因。

向量資料庫會用一些特別的索引技術（例如 HNSW, IVFFlat, Annoy 等）。這些索引技術有點像我們傳統資料庫的 Index，但它們是為高維度向量的相似度搜尋而設計的。它們不會真的把所有向量都比對一遍，而是透過一些巧妙的演算法，快速地排除掉大部分不可能相似的向量，只去比對那些「可能」相似的向量。雖然這樣可能犧牲一點點的精準度（變成「近似最近鄰搜尋」，Approximate Nearest Neighbor Search, ANN），但換來的是查詢速度的大幅提升，在實務上通常已經綽綽有餘。

graph TD
    A[應用程式收到查詢] --> B[查詢內容轉換成查詢向量 (Query Embedding)]
    B --> C{向量資料庫}
    C -- 查詢向量 --> D[向量資料庫的索引結構 (e.g., HNSW)]
    D -- 找出最接近的 K 個向量 --> E[回傳匹配的原始資料]
    E --> A

什麼時候會用到向量資料庫？

現在你應該大概知道向量資料庫在幹嘛了。那實務上什麼時候會用到它呢？

RAG (Retrieval-Augmented Generation)： 這是目前最火紅的應用。當 LLM 要回答問題時，我們不希望它憑空捏造，而是能參考我們提供的「知識庫」。所以我們會把知識庫的內容都轉換成向量存起來，當使用者問問題時，就把問題也轉成向量，去向量資料庫裡找出最相關的知識片段，然後餵給 LLM 讓它去總結或回答。這就是 RAG 的核心機制。
推薦系統： 你在電商網站看到「推薦商品」，背後很可能就有向量資料庫的影子。把每個商品、每個用戶的喜好都變成向量，透過相似度搜尋，就能找出用戶可能會喜歡的商品。
語意搜尋與問答系統： 不再只是關鍵字搜尋，而是理解你的問題「真正想問什麼」。例如，你搜尋「怎麼讓貓咪不抓沙發」，它能找到關於「貓行為訓練」、「防抓墊」等內容，而不是只找到「貓咪」或「沙發」。
圖片/影音搜尋： 透過圖片或影音的內容來搜尋相似的圖片或影音，而不是透過標籤。例如 Google Photos 的圖片搜尋功能，你可能搜尋「有狗在海邊的照片」，它就能找到。
重複資料偵測： 找出重複的產品描述、相似的新聞報導、或是抄襲的內容。