AI技术 2026-08-08

向量数据库选型指南：Milvus vs Qdrant vs pgvector深度对比

向量数据库是RAG系统的核心。本文深度对比Milvus、Qdrant、pgvector、Chroma五大方案，涵盖索引算法、选型指南、成本分析和混合检索实战。杭州深圳AI团队技术分享。

为什么向量数据库选型这么重要

2025年RAG（检索增强生成）已经成了企业AI应用的标配。但很多团队在落地时发现：同样的文档、同样的分块策略，换个向量数据库，检索效果差了30%。根本原因是没有选对向量数据库。我们在上海、杭州、深圳的RAG项目中，向量数据库选型往往是项目成败的关键因素。

向量数据库不是存储引擎，是检索引擎。选错了，Embedding再好也白搭。

向量数据库到底在干什么

向量数据库存储的是文本经过Embedding模型转换后的高维向量。每段文本变成一个768维或1536维的浮点数数组，语义相近的文本在向量空间中距离很近。检索时，把用户问题也向量化，然后找到距离最近的K个向量——这就是语义检索。

核心流程

用户问题 → Embedding模型 → query向量(768维)
                                ↓
文档集合 → Embedding模型 → doc向量(768维) → 存入向量数据库
                                ↓
                    向量数据库计算query与所有doc的距离
                                ↓
                        返回距离最近的top-K文档

关键指标是ANN（近似最近邻）搜索的速度和召回率。完美的暴力搜索是O(N)，但100万条文档时太慢。所以向量数据库用ANN算法在速度和精度间做权衡。

五大主流向量数据库深度对比

数据库	类型	索引算法	最大向量数	查询延迟	适合场景
Milvus	专用分布式	HNSW/IVF/DiskANN	10亿+	1-10ms	大规模生产环境
Qdrant	专用Rust	HNSW	1亿+	1-5ms	中小型RAG
pgvector	PostgreSQL扩展	HNSW/IVFFlat	1000万	2-20ms	已有PG的项目
Chroma	轻量嵌入式	HNSW	100万	1-5ms	原型开发/小型应用
Elasticsearch	搜索引擎	HNSW	1亿+	5-30ms	混合检索(全文+向量)

索引算法：选型的核心技术门槛

HNSW（分层导航小世界图）

当前最主流的ANN算法。构建多层图结构，上层稀疏下层稠密。查询时从最上层快速定位到目标区域，逐层下降精确定位。

优点：查询速度快，召回率高（>95%）
缺点：内存占用大（图结构需要常驻内存），构建速度慢
适合：数据量<1亿，对延迟要求高的场景

IVF（倒排文件索引）

把向量空间聚类成N个桶，查询时只搜索最近的几个桶。以Qdrant为例，深圳团队用IVF在1亿向量上实现了5ms查询延迟。

优点：内存占用小，构建速度快
缺点：召回率略低（90-93%），需要调参（nlist、nprobe）
适合：数据量大、精度要求不极端的场景

DiskANN

微软提出的磁盘索引算法。向量数据存在SSD上，内存只放压缩后的索引。

优点：内存占用极低，10亿向量只需8GB内存
缺点：查询延迟略高（10-50ms）
适合：超大规模数据（>1亿），成本敏感场景

实战选型指南

场景一：创业团队/MVP验证（数据量<50万）

推荐：Chroma

import chromadb

client = chromadb.PersistentClient(path="./vectordb")
collection = client.create_collection("docs")

# 存入向量
collection.add(
    documents=["文档内容1", "文档内容2"],
    metadatas=[{"source": "api"}, {"source": "faq"}],
    ids=["1", "2"]
)

# 查询
results = collection.query(
    query_texts=["如何退款"],
    n_results=5
)

Chroma零配置，pip install即用。杭州的初创团队用它1天搭好RAG原型。但数据超过100万时性能急剧下降。

场景二：中型企业RAG系统（数据量50万-1000万）

推荐：Qdrant

from qdrant_client import QdrantClient

client = QdrantClient(host="localhost", port=6333)

# 创建collection，HNSW索引
client.create_collection(
    collection_name="company_docs",
    vectors_config={"size": 768, "distance": "Cosine"},
    hnsw_config={"m": 16, "ef_construct": 100}
)

# 查询（支持过滤）
results = client.search(
    collection_name="company_docs",
    query_vector=embedding,
    query_filter={"must": [{"key": "dept", "match": {"value": "sales"}}]},
    limit=5
)

Qdrant用Rust编写，性能和内存效率优秀。支持payload过滤（先按metadata过滤再向量检索），这个功能在企业场景中非常实用——比如只检索销售部门的文档。

场景三：大型企业/平台级（数据量>1000万）

推荐：Milvus

Milvus是分布式架构，支持水平扩展。我们在上海为某银行搭建的RAG系统，2亿文档向量，4节点Milvus集群，平均查询延迟8ms。

# Milvus连接配置
connections.connect(
    alias="default",
    host="milvus-host",
    port="19530"
)

# 创建分区（按业务线分）
collection.create_partition("retail")
collection.create_partition("corporate")
collection.create_partition("investment")

# 混合检索：向量+标量过滤
results = collection.search(
    data=[query_vector],
    anns_field="embeddings",
    param={"metric_type": "IP", "params": {"ef": 64}},
    limit=10,
    expr='department == "investment" and date > "2026-01-01"',
    output_fields=["title", "content", "source"]
)

场景四：已有PostgreSQL技术栈

推荐：pgvector

-- 安装扩展
CREATE EXTENSION vector;

-- 创建表
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(768),
    department VARCHAR(50)
);

-- 创建HNSW索引
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- 查询：向量+SQL过滤
SELECT content, embedding  '[0.1, 0.2, ...]'::vector AS distance
FROM documents
WHERE department = 'engineering'
ORDER BY embedding  '[0.1, 0.2, ...]'::vector
LIMIT 5;

pgvector的优势是事务一致性：向量数据和业务数据在同一个数据库中，不用维护数据同步。北京很多企业在已有PG的基础上直接加pgvector，运维成本几乎为零。

混合检索：向量数据库的进阶用法

纯向量检索有局限：它擅长语义匹配但不擅长精确匹配。用户搜”SQL注入漏洞CVE-2024-1234″，向量检索可能返回一堆SQL安全文章，但找不到精确的CVE编号。解决方案是混合检索：

检索方式	擅长	不擅长	权重
向量检索	语义相似（”退款”≈”退货”）	精确匹配（编号、代码）	0.6
BM25全文检索	精确关键词匹配	语义相似	0.3
元数据过滤	结构化条件筛选	文本相关性	0.1

三路结果用RRF（Reciprocal Rank Fusion）融合，取最终top-5。深圳团队用这个方案将RAG准确率从72%提升到89%。

成本对比：你该花多少钱

方案	100万向量	1000万向量	1亿向量
Chroma（本地）	2GB内存	不推荐	不支持
Qdrant（本地）	4GB内存	20GB内存+SSD	需集群
Milvus（3节点集群）	6GB内存/节点	16GB内存/节点	32GB内存/节点
pgvector	4GB内存	32GB内存	不推荐
Elasticsearch	8GB内存	32GB内存/节点	集群+SSD

对于中小团队，杭州团队推荐的方案是：Qdrant本地部署 + 1536维text-embedding-3-small，100万文档的月成本不到100元服务器费。

常见问题

向量维度越高越好吗？

不是。1536维的OpenAI Embedding效果确实好，但存储和计算成本是768维的2倍。杭州团队的实验数据：768维的BGE-M3在中文场景下效果接近1536维，成本省一半。建议先用768维做基线，效果不够再升级。

Embedding模型换了，向量数据库要重建吗？

是的。不同Embedding模型的向量空间不兼容，换了模型必须重新Embedding全部文档。这也是为什么Embedding模型选型要慎重——一旦上线，迁移成本极高。

Milvus和Qdrant怎么选？

数据量1000万或有水平扩展需求选Milvus。如果你已经有PostgreSQL且数据量<500万，pgvector是最省心的选择。

向量数据库需要定期维护吗？

需要。主要维护项：索引重建（频繁增删后HNSW图碎片化）、数据压缩、监控查询延迟和召回率。建议每周跑一次召回率回归测试，确保检索质量没有退化。

#Chroma #Embedding #HNSW #Milvus #pgvector #Qdrant #RAG #向量数据库