向量資料庫是什麼？和傳統資料庫的差別，一篇講清楚
向量資料庫儲存、索引、檢索的是高維向量（AI 模型把文字、圖片、音訊轉成的那串數字），讓你能按「意思」找資料，而不是按「字面」找。傳統資料庫回答的是「哪些列包含這個詞」，向量資料庫回答的是「什麼內容跟這個最像」。
多數科普文講到這一句對照就停了。這篇把剩下的路走完：向量資料庫裡到底存了什麼、同一個查詢在兩種資料庫裡各怎麼走、為什麼 MySQL 真做不了這件事、一張誠實的對照表、什麼時候團隊會後悔上了向量庫，以及真需要時有哪三條路可選。
存的是意思，不是字
一切都從 embedding 模型開始。餵給它一句話、一張圖、一段音訊，它吐出一長串數字，這就是向量。數字的個數叫維度。沒什麼玄的：顏色就是最直觀的向量，紅綠藍三個數就能定位螢幕上任何一種顏色，一個三維向量而已。embedding 模型做的只是同樣的事，把維度從三個換成幾百上千個。
妙處在模型把這些數字安排得讓「意思變成了幾何」。兩段話用不同的詞說了同一件事，它們對應的點在空間裡就挨得很近。IBM 文件裡有個經典對照：搜「智慧型手機」，關鍵字檢索只回傳含這個詞的內容；向量檢索連「cellphone」「行動裝置」也能召回，因為它們的向量落在查詢附近。IBM 引用的 2025 年研究還有個數字：向量資料庫的採用率一年漲了 377%，是所有大型語言模型相關技術裡最快的。這個數字值得停下來想一想：它不是某個小眾引擎的炒作，而是整個檢索式 AI 浪潮底下的儲存層在擴張。
同一個查詢，兩種走法
抽象定義容易越聽越糊，我們拿同一個需求在兩種系統裡各跑一遍。需求：查公司特休假制度的細節。
在傳統 SQL 資料庫裡，文件的元資料躺在資料表裡，你大概會寫 WHERE title = '特休假制度' 或者 WHERE body LIKE '%休假天數%'。快、精確，而且只要措辭對不上就靜默失敗。制度文件標題寫的是「員工請假與休假管理辦法」，裡面根本沒有「特休」兩個字，這筆資料永遠不會被查出來。做過關鍵字搜尋的開發者都熟悉這個坑：使用者輸入的是同義詞，索引裡存的是字面，兩邊永遠碰不上頭。
在向量資料庫裡，管線兩頭都不一樣。寫入時，每份文件已經過 embedding 模型轉成向量存進去了。查詢時，「查公司特休假制度的細節」這句話本身也被轉成向量。資料庫找出離這個查詢向量最近的那批儲存向量，「請假與休假管理辦法」那份文件就躺在近處，因為「特休」和「休假」意思幾乎一樣，模型把這層語意編進了數字裡。同一個需求，兩種失敗模式正好相反：精確比對漏掉換說法的內容，相似檢索接得住；反過來，相似檢索放棄的，恰是 SQL 引擎打磨了五十年的那些東西（交易、精確聚合、Join），對照表裡會寫清楚。
為什麼 MySQL 真做不了這件事
你可能會問：不就是一串數字嗎，普通資料庫存個浮點數陣列、算算距離不行嗎？技術上可以，而且所有 demo 都這麼起步：向量塞進陣列，查詢時 for 迴圈逐個算餘弦相似度，取前 K 個。幾千筆資料，跑得飛快。
然後語料漲到一百萬筆。每次查詢都要對一百萬個高維向量逐一算相似度。社群裡上過線的團隊把這條曲線描述得很清楚：單次查詢拉長到兩三秒，記憶體一路爬升，併發一來機器直接被壓死。數學上沒有僥倖，十億級語料乘上千維向量，暴力遍歷回不來。
標準答案是「加索引」。但 B-Tree 索引是為精確查找和有序範圍掃描組織的，「找意思最近的向量」既不是等值也不是範圍，768 維語意空間裡不存在一根能排序的軸。這才是向量資料庫真正補的缺口：不是存浮點數，而是為近鄰搜尋專門建的 ANN 索引（HNSW 圖、IVF 分群、PQ 壓縮）。它們天生就是近似的，Pinecone 的工程文件把這個權衡說得很直白：拿一點點精確度換數量級的速度，精確和快之間的旋鈕歸你調。這些 SQL 引擎裡都沒有。
向量資料庫和傳統資料庫的差別：一張誠實的表
| 維度 | 傳統資料庫（MySQL、PostgreSQL） | 向量資料庫 |
|---|---|---|
| 資料模型 | 列、欄、資料表，固定 Schema | 高維向量 + 元資料 |
| 查詢方式 | 精確：等值、範圍、Join、聚合 | 「給我最相似的 K 個」 |
| 索引 | B-Tree、Hash，為精確和範圍而生 | ANN（HNSW、IVF、PQ），為近鄰而生 |
| 交易 | 完整 ACID | 通常不支援 ACID，或只有弱一致性 |
| 擴充 | 主從複寫、分庫分表，要花力氣 | 天然分布式 |
| 主場 | 交易、ERP、帳戶、報表 | 語意搜尋、推薦、RAG |
表之外有兩句誠實的話。第一，ACID 那一列是真的，不是小字：有生產經驗的騰訊雲社群作者說得很直白，向量資料庫普遍用完整 ACID 換吞吐量，凡是要求銀行級一致性的資料，就該待在關聯式資料庫裡。第二，這兩類系統是搭檔不是對手。成熟的 AI 架構裡通常是 PostgreSQL 管帳戶和訂單，向量庫管檢索，可能再加一個圖資料庫管實體關係，各幹各的活。
什麼時候你其實不需要它
每篇科普都講用例，幾乎沒人講翻車的故事，這裡補一個。有個團隊被大模型的熱度帶著，做了套「純向量資料庫架構」的電商搜尋系統，所有資料全塞進 Milvus。上線第三週，營運提了個日常需求：拉一份「近 7 天購買過 A 商品且收藏過 B 商品的使用者」名單做促銷。多條件精確篩選，SQL 裡一句 WHERE 的事，恰恰是向量引擎做不了的。他們臨時寫 ETL 把資料倒回 MySQL，兩邊資料已經不同步，報表數字對不上，最後花了一週重修被刪掉的關聯式資料層。那篇社群複盤的標題下得很準：追架構時髦，把自己的資料層追沒了。
這個故事背後的規則很簡單：該用向量庫的理由是相似檢索這個需求，不是「AI 原生」這個標籤。IBM 自己的文件還補了一類更隱蔽的情況：主題總結、寬泛的主題分析這類任務，模型需要通讀全部上下文而不是抓取近鄰，向量庫幫不上忙。我說得更直接一點：如果你說不出一句以「幫我找最相似的……」開頭的需求，你就沒有向量問題。
三條落地路徑
真有向量問題，路徑有三檔，多數團隊應該從最底下那檔起步：
- 檢索庫，不是資料庫。FAISS（Meta 開源）是個相似度檢索程式庫：快、免費，而且故意不做成資料庫，沒有權限控制、沒有備份、沒有多租戶。原型驗證或單機批次處理，選它沒錯。
- 給現有資料庫裝外掛。PostgreSQL 加 pgvector 擴充，就能在你已經在維運的系統裡擁有向量欄位和 ANN 檢索。幾十萬筆向量、中等查詢壓力，這是新增基礎設施最少的路，也是我給已經在跑 Postgres 的團隊的預設建議。
- 專用向量資料庫。Milvus、Qdrant、Weaviate、Pinecone。什麼時候算「配得上」：幾千萬級向量、高併發查詢、需要調校旋鈕的團隊。一上來就跳到這檔，就是上面那家電商團隊重修資料層的來路。
產業的趨勢是兩邊在合攏：關聯式引擎吸收向量能力，向量引擎補資料庫功能。但今天在高併發大規模場景下效能差距仍然真實存在，選哪一檔應該跟著你的實際資料量走。
它在 AI 架構裡站在哪
讀過我們的 RAG 詳解的話你已經知道，檢索那一步負責給大模型餵有依據的上下文，而向量資料庫就是那個檢索底下的儲存引擎。這個依據之所以重要，是因為沒有外部知識的生成會漂向編造；一個向量化的知識庫是減少 AI 幻覺的實用手段之一，同一條檢索管線也是任何夠格的 AI 智慧代理人的核心工具。
Cloudflare 的學習中心把「AI 應用為什麼繞不開這層」講得最透：模型記不住訓練之外的東西，不存向量的話，每個問題都得把全量語料重新餵一遍：慢、貴，而且反正是塞進模型的上下文視窗，上限就擺在那裡。向量資料庫把這件事變成一次性的 embedding 成本加毫秒級查詢。377% 的年成長從這來：它不是 AI 架構的配件，它是記憶本身。
常見問題快答
什麼是向量資料庫？一句話： 存高維向量（embedding）、按相似度檢索的資料庫：「找最接近的」，而不是按精確比對查。
向量資料庫和傳統資料庫的差別是什麼？ 傳統資料庫在結構化的列上做精確比對（等值、範圍、Join、完整 ACID）；向量資料庫在向量上做近鄰檢索。是搭檔，各管一攤。
它能存一般業務資料嗎？ 存的是向量加元資料，多數產品支援按元資料過濾，但一旦需要多條件精確查詢、Join 或交易，你需要的是旁邊配一個關聯式資料庫，不是拿它替換。
用 AI 一定要自己裝一個嗎？ 不用。聊天產品和 RAG 服務已經替你做好檢索了。自己架向量庫的時機，是你要對自己的語料自建檢索、且資料量到了 for 迴圈不好使的那一天。
Milvus、Pinecone、pgvector 是什麼？ 三檔路徑的代表：Milvus 是開源的專用向量資料庫，Pinecone 是商業託管版，pgvector 是給你可能已經在跑的 PostgreSQL 加向量檢索的那個擴充套件。
下次有人拿「AI 原生資料庫」向你做推薦，你就問一句：我的查詢裡有哪句是以「找最相似的」開頭的？答得上來，再談選型；答不上來，你缺的不是新資料庫，是把 SQL 寫好。