一句話定義

向量資料庫（Vector Database）是專門存放「向量」這種一長串數字、並且用相似度而不是精確比對來找資料的資料庫。

30 秒看重點

  • 是什麼：向量資料庫把文字、圖片、聲音先轉成一組數字座標，再用「誰離誰比較近」的方式搜尋。
  • 為什麼重要：它是 RAG 的檢索引擎，AI 能不能翻到正確的那份資料，成敗就在這一層。
  • 跟誰相關：想知道 AI 怎麼讀懂公司內部文件的一般使用者、做 RAG 的工程師、想做語意搜尋的電商團隊。
  • 最常見的誤解：很多人以為它會取代原本的資料庫，實際上 Postgres 裝一個 pgvector 擴充就有向量搜尋能力了。
  • 記住這件事就夠了：一般資料庫回答「一模一樣的在哪」，向量資料庫回答「最像的是哪幾筆」。

向量資料庫到底是什麼？

向量資料庫是一種專門存「向量」的資料庫。向量就是一長串數字，代表一段文字或一張圖在「語意空間」裡的座標，查詢的時候它不看字面有沒有一樣，只算哪幾筆資料離你的問題最近。

這裡的關鍵前提是 embedding（向量嵌入）。根據 Hugging Face 官方部落格的說明，embedding 是「一段資訊的數值表示」，可以是文字、文件、圖片或音訊，重點在於它捕捉的是語意，不是字面。同一篇文章的示範裡，all-MiniLM-L6-v2 這個模型把 13 個問句各自編成 384 維的向量，然後用餘弦相似度去找最接近的那幾筆。

順序其實是這樣：先有 embedding 模型把東西變成座標，才需要一個地方把幾百萬、幾億組座標存起來並且查得夠快。那個地方就是向量資料庫。

生活比喻：一般資料庫像是用地址找店，你得把「台北市 XX 路 12 號」一字不差打對，錯一個字就查無此店。向量資料庫像是打開 Google Maps 點「附近的拉麵店」，你根本不知道店名，你只知道「離我最近、賣的東西最像」的那三家在哪。這兩種找法的差別，就是精確比對跟相似度搜尋的差別。

為什麼會有向量資料庫？

它出現的理由很單純：AI 要查的資料大多是非結構化的，而傳統的關鍵字比對只認得字面。

問題一：字面不同、意思相同的東西查不到。 你在公司知識庫搜「請假規定」，那份文件標題寫的是「員工休假管理辦法」，關鍵字比對就這樣錯過了。人腦覺得是同一件事，字串比對覺得完全不同。

問題二：AI 要處理的東西根本沒有欄位可言。 Milvus 官方倉庫把自己定位成處理文字、圖片與多模態這類非結構化資料的向量資料庫，這句話反過來讀就是重點：這些東西塞不進「姓名、電話、金額」這種格式。

「那我把每份文件都下好標籤不就好了？」可以，但你得先想得到所有人會怎麼問。向量的做法是把「想得到」這件事外包給模型，剩下的交給距離計算。

這也是 RAG 為什麼非它不可。檢索增強生成（RAG） 的第一步是「先去翻資料」，翻得準不準，全看底下這層找不找得到對的段落。

向量資料庫是怎麼運作的？

簡單來講就三步：把東西變成座標、幫座標建一份地圖、查詢時沿著地圖找最近的鄰居。

  1. 轉成向量：把文件切段之後丟給 embedding 模型，每段變成一組固定長度的數字。以上面那個 384 維的模型為例，一段話就是 384 個數字。
  2. 建索引：幾百萬筆向量不可能每次都從頭比一遍，所以要建 ANN 索引。pgvector 官方文件把兩種主流做法講得很清楚：HNSW 會建出一張多層圖，查詢效能比 IVFFlat 好，但建索引比較慢、也比較吃記憶體；IVFFlat 是把向量分成很多群，查詢時只搜其中幾群，建得快、省記憶體，但查詢品質差一截。
  3. 算距離找最近的：pgvector 支援 L2 距離、內積、餘弦距離、L1 距離，以及給二元向量用的 Hamming 與 Jaccard 距離，總共六種運算子。挑哪一種，看你的 embedding 模型當初是用哪種訓練的。

名詞小教室：ANN 是 Approximate Nearest Neighbor（近似最近鄰）。注意那個「近似」，它是刻意不找標準答案來換速度的（對，是刻意的）。pgvector 講得很老實：近似索引是「拿一部分的召回率去換速度」，而且加了索引之後，同一句查詢跑出來的結果就會跟以前不一樣。HNSW 那張多層圖你可以想成搭車跨縣市，先搭高鐵跳到大概的位置，再轉捷運縮小範圍，最後用走的抵達 — 不是每條巷子都走過一遍，但通常會走到對的地方。

向量資料庫跟一般資料庫差在哪？

一般資料庫回答的是「符合條件的有哪些」，向量資料庫回答的是「最像的前幾名是誰」，一個給你對錯，一個給你排名。

比較項目向量資料庫一般關聯式資料庫
存什麼高維向量，外加一包附屬資料有欄位定義的表格資料
怎麼查算距離，找最接近的前 K 筆條件比對，符合就回傳
查不到會怎樣沒有「查不到」，一定回傳最接近的不符合就回傳空的
最擅長什麼語意搜尋、以圖搜圖、推薦交易、對帳、精確查詢
我會在什麼情況選它使用者用自己的話問問題使用者知道自己要哪一筆

從這張表可以看出來，「查不到會怎樣」那一列才是真正的陷阱。向量搜尋永遠會給你答案，就算你的資料庫裡根本沒有相關內容，它還是會挑出距離最近的幾筆交出去 交白卷不是它的選項。這也是為什麼 RAG 系統實務上一定要加相似度門檻，太遠的就當作沒找到。

你會在哪些 AI 工具看到向量資料庫？

它幾乎藏在所有「你用自己的話問、系統要去找東西」的功能背後。

  • 企業內部知識庫問答：把公司文件切段、轉向量、存起來，員工用白話問，系統撈出最相關的段落再交給 AI 回答。Milvus 官方倉庫直接點名 RAG 應用與推薦系統是它最主要的使用情境。
  • 電商的語意搜尋與商品分類：Qdrant 官方倉庫列出的使用情境就包含電商商品分類、圖片搜尋與推薦系統，做法是用正例與負例去找相似商品。
  • 以圖搜圖：你上傳一張沙發照片，系統找出長得像的商品。圖片一樣先變成向量，比的還是距離。
  • 推薦系統：「看過這部的人也看了」那一排，本質上就是在向量空間裡找鄰居。

如果你是工程師，老實講最快的入門不是去申請一套新服務。pgvector 的定位寫得很直白，它讓你「把向量跟其他資料一起存在 Postgres 裡」，等於在原本的資料庫加一個欄位型別就開工了（真的就這麼簡單）。想要更專門的選擇，Milvus 由 LF AI & Data 基金會託管、以 Apache 2.0 授權釋出，宣稱能在數十億級向量上處理數萬筆查詢；Qdrant 用 Rust 寫成，主打條件過濾（關鍵字、全文、數值範圍、地理位置）與量化壓縮，README 宣稱內建量化最多可省下 97% 的記憶體用量。

再往底層走還有 Faiss，那是 Meta FAIR 團隊開發的相似度搜尋函式庫，支援 L2 與內積、內含 HNSW 與 NSG 等圖索引，用壓縮表示法時可以在單台伺服器的主記憶體裡塞進數十億筆向量。

學向量資料庫最常見的 3 個誤解

  1. 誤解一：它會取代 MySQL、Postgres 這些資料庫 — 真相是兩者處理的問題根本不同，而且很多情況你連換都不用換。pgvector 就是直接長在 Postgres 上的擴充，帳務資料跟向量放同一套系統裡，省掉兩邊資料同步的麻煩，這件事在小團隊身上省下來的力氣超有感。
  2. 誤解二：向量搜尋找回來的一定是最正確的答案 — 真相是主流索引都是「近似」的。pgvector 官方文件明講近似索引是用召回率換速度，會漏掉理論上的最佳解。追求百分之百正確就得全部掃一遍，那個成本通常沒人想付。
  3. 誤解三：用了向量資料庫，AI 就不會亂講話了 — 真相是它只負責把資料找出來，找錯了模型照樣掰得很順。這題請看 AI 幻覺（Hallucination） 那一篇，檢索品質差的 RAG 反而會讓幻覺講得更有自信。

想多了解向量資料庫，從哪開始？

沒有技術背景的話：你只要抓住「AI 是靠找相似、不是靠找一樣」這個直覺就夠了。下次某個 AI 工具回你一段看起來相關、其實答非所問的內容，很可能不是模型笨，是底下那層撈錯段落。

有技術背景的話：先在既有的 Postgres 上裝 pgvector，用 IVFFlat 跟 HNSW 各建一次索引，親眼比較建索引時間與查詢結果的差異，感受會比看十篇文章深。想理解 HNSW 的參數怎麼調，可以看 hnswlib 的說明，M 控制圖上每個點的連線數量並直接影響記憶體、ef_construction 管建索引時的時間與精度取捨、ef 管查詢當下的速度與品質取捨。這套演算法出自 Malkov 與 Yashunin 2018 年發表在 IEEE TPAMI 的論文。

常見問題 FAQ

向量資料庫跟 AI 有什麼關係？

向量資料庫是 AI 應用的記憶與檢索層。AI 模型本身不記得你的公司文件，是向量資料庫把這些文件轉成向量存起來，在你提問時撈出最相關的幾段交給模型參考。RAG、企業知識庫問答、語意搜尋這類功能，底下幾乎都有一套向量檢索在跑。

為什麼向量資料庫突然這麼紅？

因為 RAG 變成企業導入 AI 的標準做法。要讓模型讀得到公司內部最新的資料，就得先有地方存這些資料的向量並且查得夠快。Milvus 官方倉庫把 RAG 應用與推薦系統列為主要使用情境，Qdrant 則主打語意搜尋與電商應用，這兩個定位剛好說明了需求是從哪裡長出來的。

我不是工程師也需要懂向量資料庫嗎？

不需要懂技術細節，但知道它的運作邏輯會讓你更會用 AI 工具。理解「系統是靠相似度撈資料」之後，你就會明白為什麼問法換一種說法，AI 給的答案可能完全不同。問句裡多放幾個關鍵名詞，等於把座標指得更準。

向量資料庫的中文翻譯有沒有統一？

台灣繁體中文圈相當一致，幾乎都寫「向量資料庫」。中國簡體中文則常見「向量数据库」與「矢量数据库」兩種寫法，用的是「數據庫」而不是「資料庫」。本站統一採用「向量資料庫」，實務上工程師之間也很常直接講 Vector DB。

學會向量資料庫之後，下一個該學什麼？

建議先補 Embedding（向量嵌入），那是決定向量品質的上游，向量轉得爛，資料庫再快也撈不對。接著回頭把 RAG 的完整流程走一遍，理解檢索與生成怎麼接。行有餘力再看多模態，因為圖片與音訊要進同一個向量空間，靠的也是同一套邏輯。

延伸閱讀

參考來源

  1. pgvector 官方倉庫 — HNSW 與 IVFFlat 的差異、六種距離運算子、近似索引以召回率換速度、向量與其他資料一起存在 Postgres 的定位。
  2. Milvus 官方倉庫 — 非結構化資料定位、LF AI & Data 基金會與 Apache 2.0 授權、數十億向量上處理數萬筆查詢、RAG 與推薦系統的使用情境。
  3. Qdrant 官方倉庫 — Rust 實作、關鍵字與全文與數值範圍與地理位置的過濾條件、內建量化最多省 97% 記憶體、電商分類與圖片搜尋等使用情境。
  4. Faiss 官方倉庫 — Meta FAIR 團隊開發、L2 與內積、HNSW 與 NSG 圖索引、單台伺服器主記憶體容納數十億向量。
  5. hnswlib 官方倉庫 — HNSW 演算法出自 Malkov 與 Yashunin 發表於 IEEE TPAMI 的 2018 年論文、M 與 ef_construction 與 ef 三個參數各自控制什麼。
  6. Hugging Face 官方部落格《Getting Started With Embeddings》 — embedding 是捕捉語意的數值表示、all-MiniLM-L6-v2 輸出 384 維向量、以餘弦相似度做語意搜尋。

整理一下重點：向量資料庫真的不是一種更快的資料庫，它是一種問法完全不同的資料庫 — 你問的不是「哪一筆對」，而是「哪幾筆最像」。

希望這一篇有讓你對向量資料庫有比較具體的理解哩～如果發現事實錯誤、定義不準、或翻譯卡卡的，歡迎透過聯絡頁指正，看到我們會盡快修。

我們下篇文章見囉～

本條目由 Array 報報 AI 編輯部根據上方「參考來源」整理，文末已揭露 AI 生成 + 公開資料引用。