什麼是向量資料庫?它和傳統資料庫差在哪、企業何時才真的需要
很多廠商會給你一個等式:要做 RAG,就得先買一套專用向量資料庫。這個等式在多數企業情境下根本不成立。這篇先用一句話說清楚向量資料庫是什麼、它和傳統資料庫差在哪,再拆穿「每個 RAG 都得先採購向量庫」的迷思——判斷只看兩個數字。
作者
Tenten AI 研究團隊
AI 基礎設施
發佈日期
2026年1月24日
閱讀時間
6 分鐘
向量資料庫(vector database)是一種把文字、圖片、語音等非結構化資料轉成高維數字向量(embedding)後儲存起來、並以「語意相似度」而非「關鍵字完全匹配」來檢索的資料庫。你問「員工出差住宿怎麼報帳」,它能找回一份標題叫「差旅費用核銷辦法」的文件——即使兩句話沒有一個字重疊。這是它和傳統資料庫最根本的分野。
傳統資料庫在找「相等」,向量資料庫在找「相近」
傳統的關聯式資料庫(MySQL、PostgreSQL 這類)擅長的是精確查詢。WHERE 客戶編號 = 'A123',要嘛命中,要嘛沒有,沒有中間地帶。它的世界觀是結構化的:欄位、型別、主鍵、外鍵,一切都得先定義好。這對交易系統、帳務、庫存是完美的——你不會希望銀行用「語意相近」來判斷你的餘額。
但企業內部有八成資料根本不是這個形狀。合約 PDF、會議記錄、Slack 對話、客服工單、產品手冊,這些是非結構化文字,塞不進整齊的欄位。你想問的也不是「等於某個值」,而是「跟這個意思有關的內容在哪」。這正是向量資料庫的主場。它把每段文字壓縮成一串幾百到幾千維的數字,語意越接近,向量在空間中的距離就越短,檢索時算的是距離,不是字串比對。
| 面向 | 傳統關聯式資料庫 | 向量資料庫 |
|---|---|---|
| 資料形狀 | 結構化(欄位、型別、schema) | 非結構化轉成的高維向量 |
| 查詢邏輯 | 精確匹配、範圍、JOIN | 語意相似度(最近鄰) |
| 典型問句 | 「客戶 A123 的訂單」 | 「跟退貨政策有關的段落」 |
| 命中標準 | 完全相等才算 | 意思相近就召回 |
| 最適場景 | 交易、帳務、報表 | RAG、語意搜尋、推薦 |
| 弱點 | 不懂同義、不懂語意 | 不適合做精確對帳 |
這也是為什麼 RAG(檢索增強生成)幾乎都跟向量資料庫綁在一起被提起:大型語言模型要回答企業專屬問題,得先「檢索」出相關的內部文件餵給它,而語意檢索正是向量資料庫的看家本領。
那個要破的迷思:不是每個 RAG 都得先買一套專用向量庫
這裡要講一句可能不太討喜的話。市面上很多人——包括一些急著賣你 license 的廠商——會給你一個等式:要做 RAG,就得先採購一套專用向量資料庫(Pinecone、Weaviate、Milvus 這類)。這個等式在很多情境下根本不成立。
我們自己踩過、也幫客戶擋下過這種過度採購。判斷其實很簡單,看兩個數字:資料量與查詢併發。
如果你的知識庫只有幾千到幾萬份文件,說白了,你不需要一套獨立的向量基礎設施。你現有的 PostgreSQL 裝上 pgvector 擴充,就能存向量、做相似度檢索,查詢延遲在這個量級完全夠用。好處是資料不用搬家、權限模型沿用舊的、維運團隊不用學新東西。對一家中型企業,這往往省下的不只是授權費,而是一整個季度的整合工。
更小的場景——比方一份幾百頁的手冊、一個部門的 FAQ——甚至連資料庫都不必動。把向量算好放進記憶體,用 FAISS 這類函式庫直接查,一台機器就跑得動。我們有客戶的第一版內部問答,後端就是一個檔案,好用得很。
那什麼時候才真的需要專用向量資料庫?當你要面對的是上千萬、上億筆向量,要求毫秒級回應、高併發、還要動態增刪與過濾,這時專用引擎的索引演算法(HNSW、IVF 這些)和水平擴展能力才會開始值回票價。換句話說,專用向量庫解決的是「規模」問題,不是「能不能做 RAG」的問題。先有規模的痛,再買治痛的藥,順序別反了。
選型之前,先問對問題
我們進場看一個 RAG 需求,通常不會先問「你要用哪套向量庫」,而是問:資料多大、更新多頻繁、誰會查、查得多快、精確度容忍度多少。這幾題答完,技術選型往往自己就浮出來了,而且答案常常比廠商建議的樸素得多。
向量資料庫是個好東西,但它是工具,不是門票。真正決定一套企業知識系統上不上得了線、有沒有人願意用的,從來不是後端選了哪個品牌,而是檢索品質、資料治理與嵌入現場工作流的程度。這也是我們在 Tenten 做 RAG 知識系統時的一貫立場:先把問題量對,再挑最小夠用的那把工具,把工程師的力氣留給真正難的地方——讓答案準、讓人愛用。
