什麼是向量資料庫？ AI 語意搜尋背後的核心技術

一張圖片、一段商品描述或一個搜尋問題，都可以透過 embedding 模型轉成一串數字。這串向量不是內容本身，而是模型依訓練結果建立的數學表示；向量之間的距離，則可用來估計它們在特定模型下的相似程度。

本文重點 一、什麼是向量嵌入？二、向量資料庫做什麼？三、KNN 與 ANN 有何差異？四、電商與企業如何應用？五、一定需要專用向量資料庫嗎？

一、從內容到向量：讓機器可以比較相似性

Embedding 模型會把文字、圖片或其他資料映射到多維空間。若模型認為兩筆資料在語意或特徵上接近，它們的向量通常也會較靠近。這使系統能處理「意思相近但用字不同」的查詢，例如把「適合戶外派對的喇叭」與防水、續航和便攜等商品特徵連結起來。

同樣概念也能套用到圖片與使用行為：兩張外觀相近的椅子照片可能在視覺向量空間中靠近；一組長期瀏覽與購買紀錄也能形成推薦用的特徵表示。不過，不同 embedding 模型學到的「相似」並不相同，文字模型、圖片模型與多模態模型也不能隨意混用，導入前必須先用真實資料驗證。

重要限制：向量相近不等於系統真正理解世界，也不保證答案正確。結果會受到模型、資料品質、距離函數與評估方法影響。

向量資料庫或具向量能力的資料庫，會儲存向量、原始資料識別碼與 metadata，並提供相似度搜尋、索引與條件過濾。查詢流程通常是：

Metadata filter 很關鍵。只看語意相似，可能推薦缺貨、價格不符或無權限查看的內容；將向量搜尋與結構化條件結合，才是可落地的商業搜尋。

方法	做法	適合情境
精確 KNN	比較查詢向量與符合條件的全部向量，找出真正最近的結果。	資料量較小、需要高召回，或可先用 metadata 大幅縮小範圍。
ANN	透過索引快速尋找「近似」最近鄰，降低延遲但可能漏掉少量真正最近的結果。	向量量大、查詢頻繁且需要低延遲的線上服務。

常見 ANN 索引包含 HNSW、IVF 與 ScaNN 等。選擇時不能只看速度，還要同時測試 recall、延遲、索引大小、更新成本與過濾條件。Google Cloud 的索引指南也建議依資料量、延遲與 recall 需求選擇精確或近似搜尋，而不是假設 ANN 永遠比較好。

HNSW 會建立多層圖結構，查詢時先從較稀疏的上層快速靠近目標區域，再到下層細找；IVF 則先把向量空間分群，查詢時只搜尋最接近的幾個群。前者常有不錯的低延遲與召回率，後者在大規模資料上較容易控制查詢範圍，但兩者都需要依資料分布與更新方式調整參數。

語意商品搜尋 讓「婚禮送長輩的低糖禮盒」對應情境、對象與商品屬性。

圖片相似搜尋 用上傳照片找風格或視覺特徵接近的商品。

推薦與分群 以商品或行為向量找相近內容，再加入庫存與商業規則。

企業知識檢索 從授權文件中找相關段落，提供 RAG 系統的檢索來源。

一個穩定的系統還需要商品同步、版本管理、離線評估集、權限控制與監測。只把資料「向量化」並不會自動得到好的搜尋體驗。

不一定。原稿把傳統 SQL 資料庫描述成無法進行向量搜尋，這已不符合目前工具現況。以 PostgreSQL 為例，pgvector 可儲存 embedding，支援距離運算與 HNSW 等索引；若資料量、查詢量與團隊架構適合，既有關聯式資料庫就可能足夠。

專用向量資料庫通常更適合需要大規模向量、分散式查詢、多種索引策略或獨立擴展的場景。評估時可先回答四個問題：向量數量有多少、每秒查詢量多大、更新頻率多高，以及 metadata 過濾與權限有多複雜。

向量資料庫讓「依意義或特徵找相似內容」變得可行，但搜尋品質仍取決於 embedding 模型、商品資料、索引參數、排序邏輯與持續評估。選對基礎設施很重要，更重要的是先定義顧客問題與可衡量的好結果。