大型語言模型（LLM）、多模態模型與語意搜尋需求快速成長，使文字、影像、語音及視訊等異質資料，必須轉換為可計算、可比較的統一表示形式。資料向量化（Data Vectorization）因此逐漸成為現代 AI 應用的底層能力，讓系統得以根據資料間的語意或特徵相似度進行檢索、排序與回應生成。
隨著向量資料規模持續擴大，傳統資料庫在高維度資料索引與相似度查詢上的限制更加明顯。產業因而發展專門的向量搜尋引擎與向量資料庫，近期也出現結合物件儲存的分層架構，試圖在查詢效能、資料規模與基礎設施成本之間取得平衡。
RAG 帶動向量嵌入成為 AI 應用基礎
資料向量化及相關搜尋、索引技術在 2010 年代中後期已逐漸成熟，但早期應用範圍相對有限。2020 年代大型語言模型普及後，向量化技術的採用加速，其中最具代表性的使用情境之一為增強檢索生成（Retrieval-Augmented Generation，RAG）。
大型語言模型可依訓練階段預先學得的知識，回答多數領域問題；不過，面對企業內部文件、專業領域知識或需要即時更新的資訊時，模型既有知識可能不足。RAG 架構會先依使用者問題，從外部資料庫檢索相關內容，再將檢索結果提供給模型作為生成回答的脈絡，以改善回應與特定資料來源之間的關聯性。
在這類架構中，原始資料需先經由嵌入模型（Embedding Model）編碼為向量，這個過程稱為向量嵌入（Vector Embedding）。系統再根據查詢向量與資料向量間的相似度，找出語意上接近的文件片段或其他資料實體。
從關鍵字比對走向語意與特徵搜尋
向量嵌入並不僅用於 RAG。非關鍵字搜尋、語意搜尋、影音內容推薦、社群貼文排序與審核、企業客服與 FAQ 系統、電商商品推薦、影像與語音辨識，以及跨模態搜尋，皆可使用向量作為資料表示方式。
企業內部知識庫、金融風險控管、履歷與人才媒合，以及 AI Agent 的長期記憶機制，也常依賴向量資料進行相關內容的檢索。相較於只尋找字詞完全吻合的傳統查詢模式，向量搜尋可處理詞彙不同但語意相近的內容，讓系統更接近以語意層次理解使用者需求。
高維度向量的設計與效能取捨
向量嵌入會將資料映射至高維度數值空間。每一個向量由多個數值維度組成，這些維度代表模型在訓練過程中所學得的抽象特徵。文字向量可能反映主題或語境特性，影像向量則可能與色彩、形狀或物體特徵有關，但個別維度通常不是人工定義，也未必具有可直接解讀的語意。
資料在向量空間中的相對距離或方向，可用來衡量其語意或特徵的相近程度。一般而言，較高維度能承載更多特徵資訊，實務上的向量維度可達數百甚至數千維；但維度增加同時也會提高運算、儲存與搜尋成本，並可能影響查詢效率。因此，系統設計需依資料類型、查詢量、延遲需求與結果品質，在特徵表現與基礎設施成本間進行取捨。
傳統資料庫與向量資料庫的角色差異
傳統資料庫主要以表格、欄位及明確資料型態管理資訊，適合依數字、字串、日期或其他條件執行精確查詢。其索引設計與交易機制，適用於金流、庫存、訂單及其他對一致性與正確性要求嚴格的結構化工作負載。
向量資料庫則以高維度向量作為核心資料型態，查詢重點不是判斷資料是否完全符合條件，而是依向量距離或相似度排序。這類系統通常採用近似最近鄰搜尋（Approximate Nearest Neighbor，ANN），在可接受誤差範圍內找出最接近的多筆結果。
| 比較項目 | 傳統資料庫 | 向量資料庫 |
|---|---|---|
| 主要資料型態 | 數字、字串、日期等結構化欄位 | 高維度數值向量與相關 metadata |
| 查詢方式 | 條件篩選與精確比對 | 距離計算與相似度排序 |
| 核心優勢 | 一致性、交易保障與精確查詢 | 語意搜尋、推薦與非結構化資料檢索 |
| 典型情境 | 金流、庫存、交易系統 | RAG、文件搜尋、推薦系統 |
傳統資料庫並非不能保存向量資料，但既有的 B-tree 或 Hash Index 等索引架構，並未針對高維度向量的距離排序設計。當資料量升高時，系統可能需要掃描大量資料或計算多筆向量距離，導致運算成本顯著增加。因此，專門的向量資料庫通常更適合處理大規模相似度搜尋；但它們並不適合取代對交易一致性有嚴格需求的主資料庫。
向量資料庫以 ANN 索引支撐大規模搜尋
完整的向量資料庫通常以向量搜尋引擎為核心，並結合資料持久化、索引管理、查詢介面、metadata 管理、安全控管、分散式處理、複製及高可用性等能力。
常見的 ANN 演算法包括 HNSW（Hierarchical Navigable Small World）、IVF（Inverted File Index）、IVF-PQ（Inverted File Index with Product Quantization），以及適合較小規模資料或基準測試的 Flat 演算法。這些技術的目的，是避免對每一筆向量進行完整比較，並在查詢速度、資源使用與結果召回品質之間取得平衡。
早期向量化應用多採取「向量搜尋引擎加上第三方資料庫」的組合。約自 2019 年起，隨著向量資料需求增加，市場開始出現以完整向量資料庫為定位的產品，例如 Zilliz、Weaviate 等。這些產品將向量檢索能力與資料庫層級的管理功能整合，降低開發者自行組裝搜尋、儲存與營運元件的需求。
開源、商用與雲端原生產品並存
目前的向量搜尋與資料庫產品涵蓋開源、商用託管與雲端平臺原生服務。開源產品包括 Meta 的 FAISS、Milvus、Qdrant、Weaviate、Apache Lucene、OpenSearch 與 Elasticsearch，但各自定位並不相同。
- FAISS 屬於向量搜尋引擎。
- Apache Lucene 是提供向量搜尋能力的搜尋引擎核心函式庫。
- OpenSearch 與 Elasticsearch 為具分散式搜尋能力、並提供部分資料庫功能的系統。
- Milvus、Qdrant 與 Weaviate 則屬於較完整的向量資料庫。
Milvus 是廣泛採用的開源向量資料庫之一，並提供 Zilliz Cloud 商用服務。Qdrant 常見於 RAG 應用；Weaviate 則以原生整合嵌入模型為特色，兩者亦分別提供 Qdrant Cloud 與 Weaviate Cloud Service。
商用服務方面，市場常見產品包括 Pinecone Systems 的 Pinecone、DataStax 的 Astra DB Vector，以及上述雲端版本服務。相較於自行部署的開源方案，商用服務通常提供更完整的存取控制、監控、日誌、資料複製、高可用性與託管擴展能力；部分產品也支援更多索引類型、複雜篩選條件或 GPU 加速。相應地，企業需依資料規模、營運能力與成本模型評估採用方式。
主要雲端供應商也陸續將向量搜尋納入既有產品生態系，包括 AWS 的 OpenSearch Vector Engine、加入向量功能的 DynamoDB、Microsoft Azure AI Search，以及 Google Cloud Vertex AI Vector Search。這類服務的主要優勢，在於與既有雲端身分管理、資料服務及 AI 工具深度整合，可讓原本已使用該平臺的企業較快導入，並減少額外搬移資料或建立獨立系統的需求。
物件儲存加入架構以降低成本
向量資料庫的成本通常與節點數量、CPU、記憶體及 SSD 等硬體資源有關，部分服務也會依查詢或掃描次數計費。當向量數量增加、向量維度提高，且應用同時要求低延遲與高精度索引時，所需資源將明顯增加。
近年出現「向量資料庫結合物件儲存」的架構，核心是將資料依存取頻率分層。向量資料庫主要作為搜尋加速層，保存活躍向量與索引；容量較大、查詢頻率較低的向量、原始文件或大型資料集，則置於可大規模擴展且成本較低的物件儲存系統。
這種分層設計可降低高效能儲存層的容量壓力，也讓原始資料保留在相對獨立的儲存位置。當企業需要重新進行向量嵌入、重建索引或改用其他向量資料庫時，可減少與單一資料庫實作綁定的程度。
不過，分層架構的限制同樣明確：若查詢結果對應的內容位於外部物件儲存，系統還需進行額外讀取，可能增加數十毫秒或更多延遲。因此，這類設計未必適合對延遲極度敏感，或檢索頻率極高的即時推薦等工作負載。
市場上已有相關實作，例如 Cloudian 透過 HyperStore 物件儲存平臺整合 Milvus，鎖定可延伸至 PB 與 EB 規模的 AI 資料平臺；AWS 則在 S3 服務中新增具向量資料處理能力的 S3 Vector，並強調可與 OpenSearch、Bedrock 知識庫及 SageMaker 等既有 AI 服務整合。
向量基礎設施將持續隨 AI 工作負載調整
資料向量化與相似度搜尋的理論基礎，可追溯至 2000 年代前後的資訊檢索、機器學習、資料探勘與電腦視覺特徵比對。2010 年代向量搜尋引擎逐步成熟，主要應用於推薦系統及部分自然語言處理任務；2019 年後，第一批向量資料庫產品開始出現。
真正推動這一領域快速擴大的轉折點在 2022 年以後。隨著大型語言模型與生成式 AI 加速普及，企業開始需要讓模型存取內部知識、即時資料與各式非結構化內容，向量嵌入、向量搜尋及向量資料庫遂成為常見的技術組合。
從單一向量搜尋引擎，到具備資料庫管理能力的平台，再到整合物件儲存的分層架構，向量基礎設施的演進反映 AI 語意分析應用正面臨更大規模、更複雜資料與更嚴格成本要求。未來系統選型仍須視實際工作負載而定，特別是資料更新頻率、可接受延遲、結果品質、治理要求與既有雲端環境，將共同決定最合適的部署方式。
