向量数据库深度对比：pgvector、Milvus、Weaviate架构选型与工程实践

一、为什么数据库进入了向量时代

在大语言模型(LLM)和生成式AI浪潮下，检索增强生成(RAG)架构成为解决模型幻觉、提升领域知识准确性的关键方案。而向量数据库作为RAG的核心基础设施，承担着海量Embedding向量的高效存储与最近邻(ANN)检索任务。本文从架构设计、索引实现、运维成熟度三个维度，对目前最主流的三个开源向量数据库——pgvector、Milvus、Weaviate——进行深度技术剖析。

二、pgvector：以Postgres为基石的极简方案

2.1 架构原理

pgvector是PostgreSQL的一个扩展(Extension)，核心思路是将向量作为原生数据类型存储在Postgres表列中。其Approximate Nearest Neighbor(ANN)检索依赖HNSW(Hierarchical Navigable Small World)索引与可选的IVFFlat索引。

2.2 HNSW索引内部机制

HNSW采用多层跳表思想：底层包含所有向量点，逐层向上形成越来越稀疏的导航图。查询时从顶层贪心跳转到最接近目标点的位置，逐层向下精细化搜索。它的核心优势是高召回率(ms级查询延迟)与动态增量插入能力——新向量的加入无需重建索引，只需在HNSW图中定位合适邻居并添加边。其缺点是内存占用高(V×维度×4字节 + 邻接边索引)。

2.3 IVFFlat索引选择

IVFFlat预先通过K-means聚类将空间划分为若干倒排列表(cluster)，查询时只在最近的几个cluster中做暴力扫描(Flat)。优点是构建速度快、内存占用极低(无需图结构)，缺点是召回率依赖聚类数(probes参数)，无法增量更新——新向量涌入后必须重建聚类中心。

三、Milvus：专为向量搜索设计的分布式系统

3.1 三层解耦架构

Milvus采用接入层-协调层-存储层的经典分布式设计。Proxy节点处理协议转换和结果聚合；Coordinator(根/数据/查询/索引协调器)管理元数据、调度任务与负载均衡；Worker节点(数据节点/查询节点/索引节点)分别负责WAL日志追加、ANN检索与离线索引构建；底层存储依赖对象存储(MinIO/S3)和消息队列(Pulsar/Kafka)。

3.2 性能优化要点

• 分片(Partition)：按哈希或范围将集合(Collection)切分到不同查询节点，实现水平扩展
• 索引自动降级：Milvus 2.4引入的DiskANN允许将大图结构存储在NVMe SSD上，内存仅缓存热点节点，牺牲约10~15%延迟换取10倍以上容量
• 混合检索：支持向量+标量过滤的Bitset优化——在ANN搜索前先过滤不满足条件的向量，减少无效搜索
• Delta Channel：吸收实时写入并构建增量索引，避免频繁全量Index-Build带来的I/O抖动

四、Weaviate：原生图结构的语言学导向方案

4.1 HNSW+倒排混合引擎

Weaviate独创性地将HNSW图索引与倒排索引(Inverted Index)结合在同一引擎中。对于有过滤条件的查询，先通过倒排索引筛选满足条件的对象ID集合，再子集上做HNSW近邻检索。这种"过滤优先"策略使得带条件的ANN查询性能远优于先过滤再逐个计算的传统方案。

4.2 内置向量化模块

Weaviate的突出优势是生态集成——内置了transformers、OpenAI、Cohere、voyageAI等主流嵌入模型的本地调用能力。数据入库时可自动调用指定模型生成向量并实时索引，用户无需维护外部向量pipeline。

五、选型决策框架

六、总结

向量数据库的选型没有银弹。pgvector最大化复用现有Postgres基础设施；Milvus为horizontally可扩展的大规模检索场景而生；Weaviate则在Linguistic-centric的RAG工程中提供开箱即用的AI集成。未来趋势看，向量数据库将继续向"向量+标量+图"的多模混合引擎演进，向量搜索与ANN算法的标准化(如Alibaba's Annoy/ Google's SCANN)也将推动性能进一步优化。