小編精選 - 技術文章翻譯 · 03月25日

AI 中的四種向量資料庫

=============

前言

在 AI 技術爆發的這兩年，我發現了一個有趣的現象。

當大家都在討論大模型有多強大時，真正落地的 AI 應用卻往往卡在一個看似不起眼的環節：資料的檢索與記憶。

你有沒有想過，為什麼智慧客服能記住你之前的對話？

為什麼電商推薦能精準找到「風格相似」的商品？

為什麼企業知識庫能瞬間從海量文件中找出你想要的答案？

這些能力的背後，都有一個共同的技術核心——向量資料庫。

今天這篇文章就專門跟大家聊聊，AI 中最常用的四種向量資料庫，希望對你有所幫助。

更多專案實戰在專案實戰網：java突擊隊

一、為什麼 AI 離不開向量資料庫？

有些朋友可能會問：傳統的關聯式資料庫難道不能存這些向量嗎？

答案是：能，但沒辦法高效檢索。

向量資料庫的核心原理

在深入具體產品之前，我們先花三分鐘理解向量資料庫的核心概念：

萬物皆可向量化

想像一下，你要用一組數字來描述一個朋友。你可以用 [身高、體重、外向程度、幽默感…] 這類數字向量來定義他。

AI 模型做得更細緻，它能把一段文字、一張圖轉成由數百甚至數千個維度組成的「特徵向量」，就像給內容設定了一個超精密的數學座標。

相似度計算 = 找「鄰近點」

向量資料庫把所有內容的座標點都存起來。

當你查詢時，它把你的問題也轉成座標點，然後快速計算空間中距離最近的那些點。

空間中兩點距離越近，內容就越相似。這就像在一個巨大的星空地圖中，快速找到離你位置最近的那些星球。

索引：快速查找的「秘訣」

如果逐一計算距離，資料量一大就慢如蝸牛。

所以需要「索引」——一種高級的目錄或地圖。

常見的像 HNSW（分層導航小世界）演算法，它就像建立了一個多層次的「社交網路」，讓你可以透過少數幾個「朋友」快速聯絡到目標，極大提升搜尋速度。

理解了這三個核心，你就掌握了向量資料庫 90% 的原理。

向量資料庫的完整架構

二、Milvus：開源領域的「效能怪物」

2.1 專案概況

一句話定位：專為海量向量搜尋設計的分散式資料庫

Milvus 是 LF AI & Data 基金會的畢業專案，由 Zilliz 主導開發。經過多年迭代，它已成為開源向量資料庫領域的標竿產品。

2.2 底層架構深度解析

Milvus 採用「存算分離」的雲原生架構，這是它與眾不同的核心設計：

核心創新：三層儲存架構

Milvus 2.6 引入的三層儲存架構是其最大的技術亮點：

內存層：承載熱資料，支援毫秒級查詢回應
本地 SSD 快取：溫資料快取，加速重複訪問請求
物件儲存（如 S3）：存放全量資料，保障低成本

系統基於 LRU（最近最少使用）演算法智能預測，動態調整冷熱資料邊界，自動降級不常用資料塊。

生產環境測試顯示，其快取命中率超過 90%，能降低約 87% 儲存成本與 25% 計算支出。

例如一個 10 TB 的資料集，月均成本可由約 3000 美元降至 400 美元。

2.3 混合搜尋能力

Milvus 最新版本內建了優化版 BM25 全文引擎，支援向量語意檢索與關鍵字精確匹配的雙重能力：

import io.milvus.client.MilvusClient;
import io.milvus.param.*;
import io.milvus.param.collection.SearchParam;
import io.milvus.grpc.SearchResults;
import io.milvus.grpc.SearchResultData;
import java.util.Collections;
import java.util.List;

// 初始化用戶端
MilvusClient client = new MilvusClient(ConnectParam.newBuilder()
        .withHost("localhost")
        .withPort(19530)
        .build());

// 建立搜尋請求
SearchParam searchParam = SearchParam.newBuilder()
        .withCollectionName("docs")
        .withVectorFieldName("embedding")
        .withVectors(Collections.singletonList(queryVector))
        .withMetricType(MetricType.COSINE)
        .withTopK(10)
        .withExpr("category == 'AI'")  // 標量過濾
        .build();

SearchResults results = client.search(searchParam);
List<SearchResultData> resultData = results.getResults().getFieldsDataList();

實測顯示，Milvus 的 BM25 檢索速度比 Elasticsearch 快 4–7 倍，索引體積僅為原始文本的約 1/3。

2.4 優缺點分析

優點：

分散式架構，可水平擴展至千億級向量
豐富的索引類型：HNSW、IVF、DiskANN、GPU 加速（如 CAGRA）
完善的混合搜尋能力：向量 + 全文 + 標量過濾
開源免費，社群活躍

缺點：

部署與運維較複雜，依賴 etcd、物件儲存、訊息隊列等多個元件
學習曲線陡峭，需要理解其儲存與索引概念
對中小型應用來說可能「太重」

適用場景：

超大規模圖片/影片檢索
基因序列分析
大型網路平台的推薦系統
企業級 RAG（Retrieval-Augmented Generation）應用

三、Qdrant：以 Rust 打造的「可組合」搜尋引擎

3.1 專案概況

一句話定位：讓工程師可以完全掌控檢索流程的現代化向量引擎

2026 年 3 月，Qdrant 宣布完成 5000 萬美元 B 輪融資，由 AVP 領投，Bosch 投資、Unusual Ventures 等參投。這標誌著市場對「可組合向量搜尋」理念的高度認可。

3.2 核心設計理念

Qdrant 的核心理念是「可組合性」。很多向量資料庫只能做「儲存嵌入、回傳最近鄰」的基礎操作，但 Qdrant 認為，生產級 AI 系統需要更細緻的控制：

「生產級 AI 系統需要一個搜尋引擎，其中檢索的每個面向——如何建立索引、如何打分、如何過濾、如何在延遲與精度間取捨——都是可組合的決策。」—— André Zayarni，Qdrant 執行長

3.3 架構解析

技術亮點：

Rust 語言開發：記憶體安全、零成本抽象，效能卓越
精確控制：工程師可以明確選擇檢索元件，精準控制相關性、延遲與成本之間的影響
多向量支援：同時支援密集向量與稀疏向量的混合使用

3.4 程式碼範例

import io.qdrant.client.QdrantClient;
import io.qdrant.client.grpc.Points;
import io.qdrant.client.grpc.Collections;
import java.util.Collections;

// 初始化用戶端
QdrantClient client = new QdrantClient(
    QdrantGrpcClient.newBuilder("localhost", 6334, false).build()
);

// 建立集合（Collection）
Collections.VectorParams vectorParams = Collections.VectorParams.newBuilder()
    .setSize(768)
    .setDistance(Collections.Distance.Cosine)
    .build();

client.createCollectionAsync("products",
    Collections.CreateCollection.newBuilder()
        .setVectorsConfig(Collections.VectorsConfig.newBuilder()
            .setParams(vectorParams).build())
        .build()
).get();

// 插入資料時支援豐富的 metadata（payload）
Points.PointStruct point = Points.PointStruct.newBuilder()
    .setId(Points.PointId.newBuilder().setNum(1).build())
    .addAllVector(FloatVector.asList(0.1f, 0.2f /* ... */))
    .putPayload("category", Points.Value.newBuilder()
        .setStringValue("electronics").build())
    .putPayload("price", Points.Value.newBuilder()
        .setDoubleValue(299.99).build())
    .putPayload("in_stock", Points.Value.newBuilder()
        .setBoolValue(true).build())
    .build();

client.upsertAsync("products", Collections.singletonList(point)).get();

// 帶過濾條件的檢索
Points.SearchPoints searchPoints = Points.SearchPoints.newBuilder()
    .setCollectionName("products")
    .addAllVector(FloatVector.asList(queryVec))
    .setLimit(10)
    .setFilter(Points.Filter.newBuilder()
        .addMust(Points.Condition.newBuilder()
            .setField("category")
            .setMatch(Points.Match.newBuilder()
                .setKeyword("electronics").build()).build())
        .addMust(Points.Condition.newBuilder()
            .setField("price")
            .setRange(Points.Range.newBuilder()
                .setLte(500.0).build()).build())
        .build())
    .build();

Points.SearchResponse response = client.searchAsync(searchPoints).get();

3.5 優缺點分析

優點：

Rust 開發，記憶體佔用低，效能卓越
可組合的設計，能精確控制檢索的每個環節
支援密集與稀疏向量混合使用
部署輕量，資源消耗小

缺點：

生態系相對 Milvus 較小
分散式功能不如 Milvus 成熟
中文資源較少

適用場景：

對延遲要求極高的即時推薦
邊緣 AI 裝置部署
需要精細控制檢索邏輯的生產系統
中小規模高精度檢索場景

更多專案實戰在專案實戰網：java突擊隊

四、Weaviate：混合搜尋的「多面手」

4.1 專案概況

一句話定位：既能做向量搜尋，也能做關鍵字搜尋的「全能選手」

Weaviate 是一個開源向量資料庫，以其獨特的混合搜尋能力和 GraphQL 介面著稱。它內建多種 AI 模型，可以自動完成向量化流程。

4.2 核心架構

4.3 混合搜尋實戰

Weaviate 的殺手級功能是「混合搜尋」——同時進行向量搜尋（找語意相近）與傳統關鍵字搜尋（找字面匹配），結果更精準：

# GraphQL 混合搜尋查詢
{
  Get {
    Product(
      hybrid: {
        query: "wireless headphones with noise cancellation"
        alpha: 0.5  # 向量搜尋與關鍵字搜尋的平衡權重
        vector: [0.1, 0.2, ...]  # 可選：直接提供向量
      }
      limit: 10
    ) {
      name
      description
      price
      _additional {
        score
        explainScore
      }
    }
  }
}

Alpha 參數是關鍵：alpha=1 表示純向量搜尋，alpha=0 表示純關鍵字搜尋，中間值則混合兩者。

4.4 模組化設計

Weaviate 的模組系統允許使用者輕鬆切換不同的 AI 模型：

# docker-compose.yml
version: '3.4'
services:
  weaviate:
    image: semitechnologies/weaviate:1.36.0
    environment:
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'
      PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
      DEFAULT_VECTORIZER_MODULE: 'text2vec-openai'
      ENABLE_MODULES: 'text2vec-openai,text2vec-cohere,qna-openai'
      OPENAI_APIKEY: ${OPENAI_APIKEY}

Weaviate 1.36（2026 年 3 月）引入了 HFresh 向量索引（預覽）、Server-side Batching、Object TTL 等新特性。

4.5 優缺點分析

優點：

GraphQL 介面，對前端開發者友好
內建多種 AI 模型，開箱即用
混合搜尋能力業界領先
模組化設計，可插拔

缺點：

超大規模（十億級以上）需精細調校效能
社群規模小於 Milvus
中文資源相對較少

適用場景：

需要結合關鍵字與語意搜尋的企業知識庫
內部智慧搜尋引擎
快速構建 AI 應用原型
多模態搜尋場景

五、pgvector：PostgreSQL 的「AI 擴充套件」

5.1 專案概況

一句話定位：給老朋友 PostgreSQL 戴上 AI 眼鏡

pgvector 是 PostgreSQL 的一個開源擴充套件，將向量搜尋能力無縫整合到全球最流行的關聯式資料庫中。

5.2 為什麼選 pgvector？

有些朋友可能會問：為什麼要在 PostgreSQL 裡做向量搜尋？

答案很簡單——如果你已經在用 PostgreSQL，pgvector 是零成本上手的選擇。

-- 安裝擴充套件
CREATE EXTENSION vector;

-- 建立帶向量欄位的表
CREATE TABLE items (
    id bigserial PRIMARY KEY,
    content text,
    embedding vector(768)  -- 768 維向量
);

-- 建立 HNSW 索引加速查詢
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);

-- 向量相似度查詢（示意）
SELECT *
FROM items
ORDER BY embedding <-> '[0.1, 0.2, ...]'  -- 距離運算子（示意）
LIMIT 10;

5.3 資料型別與索引

pgvector 支援多種向量資料型別，以滿足不同場景需求。以下示意常見型別與適用情境：

資料型別	精度	最大維度	典型場景
vector	單精度浮點 (4 bytes)	≤ 16,000	傳統 Embedding
halfvec	半精度浮點 (2 bytes)	≤ 16,000	高維 Embedding、記憶體敏感場景
bit	二進位位元	≤ 64,000	二進位哈希、圖像特徵
sparsevec	稀疏向量	≤ 16,000	非零 TF-IDF 特徵、超高維稀疏表示

5.4 距離函數

pgvector 提供多種距離度量，常見範例如下：

-- 歐式距離（L2）
SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 10;

-- 內積（可用於相似度，值越大越相似）
SELECT * FROM items ORDER BY embedding #> '[3,1,2]' LIMIT 10;

-- 余弦距離（示意）
SELECT * FROM items ORDER BY embedding <=> '[3,1,2]' LIMIT 10;

-- 曼哈頓距離（L1）
SELECT * FROM items ORDER BY embedding <+> '[3,1,2]' LIMIT 10;

-- 二進位漢明距離（示意，對 bit 類型）
SELECT * FROM items ORDER BY bit_vec ~> '101010' LIMIT 10;

-- Jaccard 距離（示意）
SELECT * FROM items ORDER BY bit_vec %> '101010' LIMIT 10;

（注意：實際運算子名稱請依 pgvector 版本文件確認，以上為示意用法）

5.5 索引類型

pgvector 支援主要兩種索引：

索引類型	建構速度	查詢速度	記憶體占用	適用場景
IVFFlat	快	中等	低	中到大規模資料集
HNSW	慢	非常快	高	低延遲要求場景

5.6 優缺點分析

優點：

無需引入新資料庫，復用 PostgreSQL 的運維經驗
完整支援 ACID 交易，這是專用向量資料庫不一定具備的
使用 SQL 語法，學習成本低
可以與關聯式資料無縫關聯查詢

缺點：

處理海量或超高維向量時，效能不如專用向量資料庫
索引類型較少（主要 IVFFlat、HNSW）
不適合純向量搜尋且規模極大的場景

適用場景：

已有 PostgreSQL 的中小型 AI 應用
需要嚴格交易保證的 AI 業務
希望用 SQL 統一管理關聯資料與向量資料
在現有系統上快速增加 AI 能力

六、四大向量資料庫比較

6.1 功能特性對比（摘要）

維度	Milvus	Qdrant	Weaviate	pgvector
定位	分散式向量資料庫	可組合搜尋引擎	混合搜尋資料庫	PostgreSQL 擴充
開發語言	Go / C++	Rust	Go	C
架構模式	存算分離	一體化（可組合）	模組化	嵌入式（在 PG 內）
索引類型	HNSW / IVF / DiskANN / CAGRA	HNSW	HNSW	IVFFlat / HNSW
混合搜尋	✅（BM25 + 向量）	✅（稀疏 + 密集）	✅（關鍵字 + 向量）	❌（需由應用層實現）
分散式能力	✅ 原生分散式	⚠️ 分散式能力正在發展	✅ 支援	❌ 依賴 PostgreSQL
ACID 支援	❌	❌	❌	✅（完美支援）
易用性	中等	高	高（GraphQL）	非常高（SQL）
社群活躍度	極高	高	高	極高