舉個例子。一家做精密零件的公司想讓業務用 AI 查產品規格和過去的報價，找了兩家廠商估價。第一份報價單有一行「向量資料庫授權，年費另計」；第二份沒有這一行，只寫「使用雲端平台內建的檔案檢索」。老闆把兩份丟給 IT 窗口：「這個向量資料庫到底是什麼？一定要買嗎？少了它，第二家做出來的東西會比較差嗎？」
這三個問題都有答案，但要先弄懂兩件事：embedding 把文字變成了什麼，以及向量資料庫拿這些東西做什麼。弄懂之後你會發現，要不要另外買，取決於你的資料量和手上已經有什麼系統，跟 AI 做得好不好沒有直接關係。
向量資料庫是什麼：依「意思」找資料的資料庫
Google Cloud 的定義是：向量資料庫是可以儲存、建立索引並查詢向量嵌入（vector embedding）的資料庫。向量嵌入就是文字、圖片或音訊這類非結構化資料轉成的一串數字。
一般資料庫擅長的是「完全符合」：訂單編號等於多少、日期落在哪個區間、客戶名稱包含哪幾個字。向量資料庫擅長的是「意思相近」：問題和文件用了不同的字，只要講的是同一件事，也能被找出來。
OpenAI 的說明文件舉過一個很好懂的例子。問題是「我們什麼時候登上月球？」，三段候選文字的比對結果如下：
| 候選文字 | 關鍵字相似度 | 語意相似度 |
|---|---|---|
| 人類第一次登陸月球是在 1969 年 7 月。 | 0% | 65% |
| 第一位登上月球的人是阿姆斯壯。 | 27% | 43% |
| 我吃了月餅，很好吃。 | 40% | 28% |
（原文是英文，這裡翻成中文；關鍵字相似度用字詞重疊計算，語意相似度用 embedding 計算。）
只看字詞重疊，最相關的反而是月餅那一句，因為它和問題共用最多字。用 embedding 比，真正回答問題的第一句排在最前面，雖然它和問題一個共同的字都沒有。向量搜尋補上的，就是「用詞不同、意思相同」這一塊。
Embedding 是什麼：把一段文字變成一串數字
embedding 是由一個專門的模型，把一段文字轉成一長串浮點數。以 OpenAI 的模型為例，text-embedding-3-small 輸出的長度預設是 1,536 個數字，text-embedding-3-large 是 3,072 個。每一個數字單獨看沒有意義，整串數字代表這段文字在「意思空間」裡的位置。
你可以把它想成把一大堆石頭按顏色排在桌上：顏色越接近的放得越近，不需要誰先替每顆石頭取名字。Google Cloud 的說法是，嵌入把資料對應到向量空間，相似的項目彼此靠近，不相似的相距較遠。查詢的時候，問題也用同一個模型轉成一串數字，再找出距離最近的幾段文件。
距離怎麼算，有餘弦相似度、點積、歐幾里得距離幾種。OpenAI 建議用餘弦相似度，也說選哪一種通常影響不大；它的 embedding 長度都正規化成 1，所以用點積算會快一點，排名結果和餘弦相同。
回到零件公司的例子。業務問「上次那批鋁件的表面處理怎麼做的？」，報價單上寫的是「6061 陽極處理，黑色」。問題裡沒有「陽極」兩個字，關鍵字搜尋可能找不到；embedding 會把「表面處理」和「陽極處理」放在很近的位置，這段就有機會被找出來。
embedding 的費用通常不高。OpenAI 的說明頁以每頁約 800 個 token 估算，text-embedding-3-small 每 1 美元大約可以處理 62,500 頁文字。對多數中小企業來說，把整個文件庫轉成向量一次的費用很少會是決策的重點，要算的是後面的儲存、維運和重算。
向量資料庫比一般資料庫多做了什麼
把文字轉成數字只是第一步。數字存下來之後，每次提問都要從幾萬、幾十萬段裡找出最近的幾段，這才是向量資料庫要處理的事。它通常多做了三件事：
| 功能 | 在做什麼 | 在零件公司的例子裡 |
|---|---|---|
| 近似最近鄰搜尋（ANN） | 不和每一段逐一比對，用索引快速找到「大概最近」的幾段 | 十萬段文件裡，毫秒內找出和問題最接近的二十段 |
| 向量索引（HNSW、IVFFlat 等） | 事先把相近的向量整理成圖或分群，查詢時只看一小部分 | 索引建好之後，新增報價單要跟著更新索引 |
| 中繼資料篩選 | 在比意思的同時，加上一般條件 | 只找 2025 年以後、業務部有權限看的報價單 |
第一項有一個取捨要知道。PostgreSQL 的向量擴充套件 pgvector 在說明文件裡寫得很清楚：預設是精確搜尋，召回率完整；加上近似索引之後速度變快，但會犧牲一些召回率，同一個查詢的結果也可能和加索引前不同。Google Cloud 也用同樣的方式描述 ANN：犧牲少量準確率，換取大幅的速度提升。文件量不大的時候，精確搜尋就夠快，不急著建近似索引。
第三項在企業裡最常被低估。只比意思，會找出一堆相關但不該給這個人看、或已經過期的段落。Google Cloud 舉的例子是找「關於魚的溫馨故事」的書，同時限制價格在 20 美元以下；換到公司裡，就是限制版本、日期、部門和權限。權限要在檢索這一層處理的理由，我在 RAG 是什麼 寫過，這裡只提醒一件事：選向量資料庫時，先確認它能不能在同一次查詢裡同時做語意比對和條件篩選。
我們自己的例子：站內重疊檢查為什麼抓不到同義句
這個網站有兩支程式，負責在發文前檢查文章之間會不會搶同一個搜尋意圖。一支在每次檢查時比對全站的標題與常見問題，另一支產生站內競爭風險報告。兩支用的方法相同：把句子切成兩個字一組（雙字詞），依每組字在全站出現的頻率加權，再算兩個句子的餘弦相似度。全站常見的「AI」「GEO」權重低，罕見的詞撞在一起才會拉高分數。
這種做法便宜、可以離線跑、結果每次都一樣，缺點就是前面月餅例子的缺點：只認得字，不認得意思。2026 年 9 月寫這篇時，我們拿同一支程式實際算了三個句子：
| 句子 A | 句子 B | 分數 |
|---|---|---|
| 第一個 agent 先做哪個流程 | 哪些流程適合先交給 agent | 0.14 |
| 第一個 agent 先做哪個流程 | AI agent 第一個流程要選哪個 | 0.48 |
第一組講的是同一件事，只是換了說法，分數只有 0.14，遠低於我們設的提醒門檻 0.45。第二組共用了「第一個」「流程」這些字，分數就衝過門檻。換句話說，字詞比對抓得到換字，抓不到換句話說。
所以我們的產文流程另外規定：每一篇新文都要人工寫下讀者會打的那一句問題，並讀過最接近的兩、三頁再判斷，程式只負責把明顯的撞題挑出來。
如果改用 embedding，做法會是把每一句標題轉成向量，改用 embedding 的距離算相似度。第一組那種換句話說的撞題會比較容易被抓到，但也會多出幾件事要處理：
- 每次檢查都要呼叫 embedding 模型。目前全站約 550 句，費用很低，但檢查會多一個依賴外部服務的步驟，離線時就跑不了。
- 門檻要重新校準。字詞比對的 0.45 不能直接搬到 embedding 分數上，要拿已知撞題和已知不撞題的組合重新試。
- 會多出新的誤報。embedding 認為意思相近，不代表讀者要做的決定相同。例如「RAG 是什麼」和「向量資料庫是什麼」的向量可能很接近，但一個是在問整套做法，一個是在問其中一個元件，這兩頁本來就該分開寫。
- 換模型就要全部重算。不同模型產出的向量長度和空間都不一樣，舊分數和新分數不能直接比較。
以這個網站目前的規模，人工讀最接近的幾頁還負擔得起，所以我們沒有換。這個取捨也適用在你的公司：向量搜尋解決的是「換句話說」的問題，這個問題夠痛，才值得付後面的維運成本。
一定要另外買一套嗎：三種做法
回到老闆的問題。Microsoft 在 Azure Cosmos DB 的說明裡把向量資料庫分成兩種：一種是獨立的純向量資料庫，和原本存資料的系統分開；另一種是整合在既有 NoSQL 或關聯式資料庫裡的向量功能，向量和原始資料存在一起。再加上雲端平台把整套檢索包好的做法，企業大致有三條路：
| 做法 | 例子 | 適合的情況 | 要注意的地方 |
|---|---|---|---|
| 平台內建的檔案檢索 | OpenAI 的檔案搜尋（vector store）、各家 AI 平台的知識庫功能 | 文件幾百份以內，想先把第一個流程做起來 | 切段與檢索方式能調的空間有限；檔案要放到平台上 |
| 現有資料庫加向量功能 | PostgreSQL 加 pgvector（AWS RDS、Google Cloud SQL 與 AlloyDB 都支援）、Azure Cosmos DB | 公司已經在用這些資料庫，向量要和訂單、客戶資料一起查 | 維度與索引有上限；資料量很大時要調效能 |
| 專門的向量資料庫 | Milvus、Weaviate、Pinecone 等 | 向量數量很大、查詢量很高，或要做細部的檢索調整 | 多一套系統要同步資料、管權限、付費與維運 |
第一條路最省事。OpenAI 的檔案搜尋工具會同時用語意和關鍵字搜尋，檔案放進 vector store 時自動切段、轉向量、建索引，儲存空間 1 GB 以內免費，超過按容量逐日計費。零件公司的第二家廠商走的就是這條路，它做出來的東西不會因為少了「向量資料庫」這一行而比較差，只是檢索的調整空間比較小。
第二條路常被忽略。pgvector 的說明寫的是「把向量和其他資料存在一起」，同時保有 PostgreSQL 的交易一致性、時間點還原和 JOIN。如果你的報價單和客戶資料本來就在 PostgreSQL 裡，加一個向量欄位，就能在同一個查詢裡比意思、篩客戶、篩日期，不必把資料複製到另一套系統。Google Cloud 的說明頁甚至寫道，他們認為未來每個資料庫都會成為向量資料庫；這是廠商的看法，但方向和各家資料庫陸續加上向量功能的現況一致。
第三條路適合規模真的大的時候。網路上不少文章會比較 FAISS、Weaviate、Pinecone、Milvus，那些比較對工程師選型有幫助；對多數中小企業的第一個知識庫問答來說，通常還用不到這一步。
我的建議順序是：先用平台內建的檢索把流程做起來，已經有 PostgreSQL 這類資料庫就直接加向量功能，真的遇到規模或效能瓶頸，再評估專門的向量資料庫。
文件量更少的時候，連檢索都可以先不建，整份文件直接放進提示就好，RAG 是什麼 的「長上下文」段落有比較完整的說明。
選之前先問的五個問題
不管走哪一條路，估價或選型前，我會先問這五個問題：
- 資料有多少、多久更新一次？ 幾十份文件和幾萬份文件是完全不同的規模。更新頻繁時，要確認新增、修改、刪除文件後，索引多久會跟上。
- 向量要不要和既有資料一起查？ 要依客戶、日期、權限篩選，就優先考慮能和原始資料放在一起的做法，或確認向量資料庫支援中繼資料篩選。
- 會不會查料號、編號這類精確字串？ 會的話要用混合搜尋。Microsoft 的 Azure AI Search 說明寫到，產品編號、專業術語、日期和人名這類查詢，關鍵字搜尋因為能精確比對，表現比較好；混合搜尋會同時跑關鍵字和向量查詢，再用一種叫 RRF（倒數排名融合）的方法合併結果。pgvector 也建議搭配 PostgreSQL 的全文檢索做混合搜尋。
- 用哪個 embedding 模型、幾個維度？ 維度會碰到資料庫的上限。pgvector 的 HNSW 索引，一般向量型別最多支援 2,000 個維度，
text-embedding-3-large預設是 3,072 個。OpenAI 允許在產生 embedding 時用參數縮短長度，說明文件就舉了「資料庫只支援 1,024 維，就把長度指定成 1,024」的例子，代價是犧牲一點準確度。 - 換模型時誰負責重算？ 模型升級或換供應商，整個文件庫的向量都要重算一次，索引也要重建。這件事要寫進維護範圍，不然第一次換模型時才會發現沒有人負責。
向量搜尋找不到的東西
向量搜尋擅長找意思相近的段落，有幾類問題交給它反而會出錯：
- 精確的料號、訂單編號：語意比對容易把相似的編號當成同一個，要靠混合搜尋的關鍵字那一半。
- 數量、金額、庫存：「A 客戶上個月下了幾件？」答案在資料庫的欄位裡，直接查系統比從文件段落裡找準確。
- 最新版本：新舊兩版規格表的向量幾乎一樣，檢索分不出哪一版是現行版本，要靠文件整理和版本欄位。這部分可以看企業知識庫要整理到什麼程度，AI agent 才用得上。
- 不該看的內容：向量本身不帶權限，權限要在檢索時用條件篩選。
這四類問題的共通點，是答案取決於「精確的值」而不是「相近的意思」。遇到這類需求，先把資料放在能精確查詢的地方，再讓 AI 去查它。模型本身怎麼處理這些查回來的內容，可以看 LLM 是什麼。
我們能協助的部分
我們的企業 AI 營運方案從需求診斷開始：工程團隊會先梳理資料現況，挑一個關鍵流程切入，只整理這個流程會用到的資料，不必等全公司資料整頓完畢。系統會串接你既有的軟體、資料庫與 API，模型可以依任務接入 OpenAI、Claude 與 Gemini；資料的保存位置與期限，會在需求診斷時寫進交付文件。要不要另外建向量資料庫，也是在這個階段依資料量和既有系統一起決定。
常見問題
向量資料庫和 RAG 是同一件事嗎？
兩者是整體和元件的關係。RAG 是一整套做法：先找資料，再把資料交給模型回答。向量資料庫是其中「找資料」那一步常用的元件。RAG 也可以只用關鍵字搜尋，或在文件很少時整份放進提示；反過來，向量資料庫也用在推薦商品、找相似圖片這類和 AI 問答無關的地方。
換了 embedding 模型，已經存好的向量還能用嗎？
要全部重新處理。不同模型產出的向量長度和空間都不同，例如 OpenAI 的兩個模型預設就分別是 1,536 和 3,072 個數字。換模型時，要用新模型把全部文件重新轉一次、重建索引，查詢端也要改用同一個模型。建議先用固定的測試題比較新舊模型的檢索結果，再決定要不要換；測試題怎麼設計，可以參考 AI agent 專案怎麼驗收。
文件轉成向量之後，就等於匿名化了嗎？
向量還是可能被還原成原文。2023 年一篇研究（Morris 等人，EMNLP 2023）用反推方法，能從 embedding 還原出 92% 的 32 個 token 長度的原文，也從臨床紀錄的向量裡還原出病患全名。存向量的資料庫，要用和原始文件同一個等級的權限與加密來保護。
向量資料庫大概要花多少錢？
要分三塊算。第一塊是把文件轉成向量的費用，通常很低；第二塊是儲存與查詢，平台內建的檢索多半按容量或用量計費，自架的要算主機與維運人力；第三塊是之後的重算與維護，最常被漏掉。估價時請廠商把三塊分開列，比較容易看出差異在哪裡。
參考來源
以下依官方文件整理，embedding 模型的維度、儲存計費方式與各資料庫支援的版本以各官方頁面當下為準。
- Google Cloud：什麼是向量資料庫？運作方式為何？
- OpenAI：Vector embeddings
- OpenAI：Retrieval（語意搜尋範例）
- OpenAI：File search
- OpenAI：API Pricing
- pgvector（GitHub）
- Amazon RDS for PostgreSQL：支援的擴充套件版本
- Microsoft Learn：整合向量資料庫（Azure Cosmos DB）
- Microsoft Learn：Hybrid search overview（Azure AI Search）
- Morris et al.：Text Embeddings Reveal (Almost) As Much As Text（arXiv）