一、PGVector为什么推荐 PGVector 作为 RAG 的入门首选理由很直接——你的项目大概率已经在用 PostgreSQL。直接加一个扩展不需要引入新的数据库组件运维成本最低。DBA 会用 PG就会维护 PGVector。这种“复用已有基础设施”的价值在实际项目里非常实在。1.1 PGVector 能做什么本质PGVector 给 PostgreSQL 加了一个新的数据类型VECTOR你可以在普通的表里加一列向量然后对这列向量做相似度搜索。查询时用“向量相似度排序”替代普通 SQL 的ORDER BY。三种距离算法运算符距离类型适用场景-欧氏距离L2坐标空间对向量幅度敏感余弦距离文本语义搜索首选只看方向不看幅度#内积负数向量已归一化时等效于余弦距离文本 RAG 场景几乎都用余弦距离。因为不同长度的文本Embedding 向量的幅度可能不同但语义方向是相似的。余弦距离只看方向不受幅度影响更适合语义搜索。1.2索引类型HNSW vs IVFFlat这是 PGVector最重要的选择之一直接影响搜索速度和精度。什么是向量索引没有索引时向量搜索要把查询向量和库里每一条记录都算一次距离全量扫描。100 万条数据就要算 100 万次距离O(n) 复杂度数据量大了根本跑不动。向量索引通过构建特殊的数据结构让搜索时只计算一小部分候选向量的距离。代价是不保证找到“最精确”的结果只保证找到“足够好”的近似结果——即ANN近似最近邻搜索。1.2.1 HNSW层级小世界网络HNSW 构建了一个多层的图结构HNSW 索引结构简化示意 层 2稀疏 A ←————→ F ←——→ K ↑ 层 1中等 A ←——→ D ←——→ F ←——→ H ←——→ K ↑ 层 0密集 A-B-C-D-E-F-G-H-I-J-K所有节点查询时从高层稀疏图开始找大方向逐层往下精化最终在底层找到精确候选——就像在地图上先定位到城市再找街道再找门牌号高效且准确。HNSW 的优点查询速度快延迟低召回率高精度好支持增量插入随时插入新数据不需要重建索引HNSW 的缺点建索引较慢但通常是一次性操作内存占用较大索引结构要常驻内存大多数 RAG 场景推荐 HNSW。1.2.2 IVFFlat倒排文件 扁平量化IVFFlat 的思路先把向量空间划分成若干个“桶”Cluster每次查询只搜最近的几个桶不搜全部。IVFFlat 索引结构简化示意 向量空间 ┌──────────────────────────────────┐ │ 桶1 桶2 桶3 桶4 桶5 │ │ ··· ··· ··· ··· ··· │ └──────────────────────────────────┘ ↑ 查询向量先判断属于哪个桶附近只在附近桶里搜IVFFlat 的优点建索引快内存占用小IVFFlat 的缺点查询速度相对较慢召回率略低向量被错分到错误桶的情况不可避免需要先有足够量的数据才能建索引通常要求 1000 条聚类才有意义适合 IVFFlat 的场景数据量百万级以上、批量入库非实时插入、对内存比较敏感。1.2.3两者对比维度HNSWIVFFlat查询速度快较慢查询精度召回率高中等建索引速度慢快内存占用大小增量插入友好较麻烦需定期重建数据量要求无特殊要求 1000 条才有意义推荐场景大多数 RAG 场景大规模批量场景1.3 HNSW 的关键参数m 和 ef_constructionHNSW 有两个建索引时的关键参数影响精度和资源消耗的权衡。参数 m每个节点的最大连接数m决定了 HNSW 图的“密度”——每个节点最多连接几个邻居。m越大图越密搜索越准但内存占用越大、建索引越慢m越小内存省但精度降低通用推荐值m 16调大 m如 32~64对召回率要求极高如法律文档检索代价是内存翻倍调小 m如 8内存极度紧张时精度会下降但速度更快参数 ef_construction建索引时的搜索宽度ef_construction控制建索引时的精度——在往图里插入每个节点时搜索多少候选邻居来决定最终连接。ef_construction越大索引越精确但建索引越慢ef_construction越小建索引快但索引质量略低通用推荐值ef_construction 64建议这两个参数入门时不要纠结16/64就是很好的默认值。等到真正遇到性能瓶颈再基于实际测量调整。1.4查询时的 ef_search精度和速度的旋钮建好索引后查询时还有一个参数ef_search控制查询时搜索的候选数量。ef_search越大查询越准召回率高但耗时越长ef_search越小查询越快但可能漏掉一些相关结果默认值通常是40。这个参数的意义是你可以在不重建索引的情况下灵活地在查询精度和速度之间调整。场景推荐 ef_search精度优先如法律条文检索100–200速度精度平衡大多数场景40–100默认附近速度优先高并发低延迟20–401.5距离算法和相似度分数的关系这里有个容易混淆的地方鸡哥单独说清楚。余弦距离的范围是[0, 2]0→ 完全相同2→ 完全相反但 RAG 框架里通常展示的是相似度分数它是对余弦距离的转换相似度 1 - 余弦距离完全相同 → 余弦距离 0 → 相似度 1.0不相关 → 余弦距离 ≈ 1 → 相似度 ≈ 0.0完全相反 → 余弦距离 2 → 相似度 -1.0所以设置“相似度阈值”时例如similarityThreshold 0.6表示“只要余弦相似度 ≥ 0.6 的结果”。阈值怎么设没有通用答案要根据数据和模型实测。鸡哥的经验中文业务文档通义千问 Embedding0.5–0.7比较合理英文技术文档OpenAI Embedding0.6–0.8第一次调试先设0.3看能不能搜到东西再逐步调高阈值设太高比如 0.9会过滤掉大量相关结果知识库形同虚设。阈值设太低会引入大量噪音浪费 LLM 的上下文窗口。1.6 Metadata 过滤向量搜索 结构化过滤组合PGVector 支持在向量搜索的同时按 Metadata 过滤。这个功能看起来简单但设计得好可以大幅提升检索精度。1.6.1场景举例知识库里有产品手册categorymanual、FAQcategoryfaq、政策文档categorypolicy。用户提问“退款要多久”普通向量搜索可能找到来自产品手册的内容里面也提到了退款加 Metadata 过滤只在categoryfaq里搜精准命中 FAQ 里的退款条款1.6.2Metadata 设计建议建议入库时至少标注{ source: 文件名或 URL, category: 文档类别, version: 版本号, upload_date: 入库时间 }注意Metadata 过滤和向量搜索是“先过滤后搜索”——先通过 Metadata 缩小候选集再在候选集内搜向量。过滤条件越严格候选集越小TopK 能找到的结果就越少甚至可能不足 K 个。合理设计 Metadata 粒度很重要。1.7性能基准PGVector 在不同规模下的表现测试环境HNSW 索引m16, ef_construction641536 维向量普通 4 核 8G 服务器。数据量查询延迟TopK5内存占用向量索引推荐场景1 万条 10ms~100MBDemo、小型工具10 万条10–30ms~1GB企业知识库100 万条30–100ms~10GB平台级中型产品1000 万条100ms内存可能撑不住考虑换专业向量库对于中小型企业知识库文档数百到数千个分块后数万条向量PGVector 性能完全够用查询延迟可以控制在 30ms 以内。PGVector 的实际瓶颈通常不在向量搜索而在写入速度。大规模批量入库时Embedding 模型的调用速度每条都要调用一次 API才是真正的瓶颈。1.8什么时候 PGVector 开始显现局限见过一些开始觉得 PGVector 不够用的情况数据量超过几百万条查询延迟开始超出要求HNSW 索引的内存占用可能超出单机可用内存。多租户向量隔离需求比如 SaaS 产品每个客户的知识库要完全隔离。PGVector 只能靠 Metadata 过滤实现“逻辑隔离”没有真正的物理隔离。专业向量库的 Collection 概念更适合这个场景。向量 复杂结构化条件的混合查询例如“在最近 7 天上传的、来自技术部门的、内容和问题相关的文档块”。这类复杂混合查询PGVector 的过滤性能不如专业向量库。极高并发PGVector 依赖 PostgreSQL 的连接池高并发场景下会遇到连接数上限和锁竞争问题。1.9生产部署的几个要点1. 不要用initialize-schema: true管理生产 DDL让框架自动建表只适合开发和 Demo。生产环境的表结构变更要纳入版本管理Flyway、Liquibase 或手动维护 SQL 文件方便追踪和回滚。2. 向量表要定期做 VACUUM大量删除和更新向量后PG 的 MVCC 机制会留下“死元组”占用磁盘空间并影响查询性能。定期执行VACUUM ANALYZE vector_store;3. 监控向量表大小和索引状态特别是 HNSW 索引在内存里的占用。如果机器内存不足索引会被频繁换入换出查询延迟会大幅上升。4. 数据备份和恢复策略向量库里存的是 Embedding 结果。如果 Embedding 模型没变数据丢失可以通过重新入库恢复只是费时间。但建议还是纳入常规备份。二、Qdrant——高性能、现代感强的专业向量库Qdrant 是用Rust写的这一点非常重要——Rust 的内存安全特性和零成本抽象让 Qdrant 在性能和稳定性上有天然优势单机可以支撑千万级向量内存占用还比同等 Java/Go 实现低。2.1Qdrant 相比 PGVector 的核心优势多 Collection 原生支持每个 Collection 是独立的向量空间有独立的维度和索引。鸡哥见过的一个场景一个平台有“产品手册”、“FAQ”、“政策文档”三个知识库用 Qdrant 就是三个 Collection天然隔离用 PGVector 只能靠 Metadata 字段区分查询时加过滤条件不够干净。Payload 过滤性能优秀Qdrant 的过滤机制是专门为“向量过滤”组合查询设计的支持在过滤之前或之后做向量搜索有复杂优化器。在同样的数据量下复杂过滤条件的性能比 PGVector 好很多。Rust 实现的性能和稳定性高并发场景下Qdrant 的延迟抖动很小。PGVector 在高并发下可能因为 PG 锁机制出现延迟毛刺。自带图形化界面启动后就有 Dashboard可以直接在界面里看 Collection、查数据、测搜索调试很方便。鸡哥每次接触新知识库先在 Qdrant 的界面里搜几个测试问题看看效果。2.2 Qdrant 的适用场景场景 A中大型企业知识库数百万条向量→ 单机 Qdrant 就够比 PGVector 有明显性能优势场景 BSaaS 平台的多租户知识库→ 每个租户一个 Collection物理隔离简洁清晰场景 C从 PGVector 升级的首选→ 部署简单单 DockerSpring AI 支持好代码层不用改场景 D对运维复杂度有约束的团队→ Qdrant 单进程就能跑不像 Milvus 需要多个组件2.3 Qdrant 的局限Qdrant 不适合“数据量亿级以上 需要水平扩展”的场景——它的分布式模式Qdrant Cloud 或自建集群相对复杂不如 Milvus 在分布式层面成熟。三、Milvus——分布式大规模场景的重炮Milvus 是由 Zilliz 开源的分布式向量数据库支持十亿级向量内置分布式能力是向量数据库领域的“大规模场景专家”。3.1Milvus 的架构特点Milvus 是真正的分布式系统组件分离┌─────────────────────────────────────────────────────────────┐ │ Milvus 分布式架构 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Query │ │ Data │ │ Index │ ← 计算节点 │ │ │ Node │ │ Node │ │ Node │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ↓ ↓ ↓ │ │ ┌─────────────────────────────────────┐ │ │ │ 消息队列Pulsar/Kafka │ ← 数据流 │ │ └─────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────┐ │ │ │ 对象存储MinIO/S3 │ ← 持久化 │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘这个架构的好处每一层可以独立扩展计算和存储分离扛得住真正的大规模。代价部署复杂度很高。一个完整的 Milvus 集群需要协调节点Coordinator、查询节点、数据节点、索引节点、消息队列Pulsar 或 Kafka、对象存储MinIO 或 S3。对一个没有专职运维的中小团队来说光是搭起来就要花不少时间。3.2Milvus 的适用场景场景 A数据量亿级以上的大规模系统→ 电商推荐系统商品 Embedding 用户行为 Embedding→ 大型内容平台的语义搜索文章、视频描述→ 超大规模企业文档库集团级、跨公司的知识管理平台场景 B需要水平扩展能力→ 业务增长快向量量每月翻倍→ 需要在线扩容不停服场景 C有专职运维团队→ 公司有 DBA/SRE能维护多组件分布式系统对大多数企业知识库项目Milvus 是过度设计。如何判断如果你的知识库文档不超过几十万团队没有专职运维用 Milvus 是给自己找麻烦。四、三个向量库的全面对比维度PGVectorQdrantMilvus数据量级上限百万条以内舒适千万级单机十亿级分布式部署复杂度极低已有 PG 直接用低单 Docker高多组件Payload/Metadata 过滤一般优秀专门优化优秀多租户隔离靠 Metadata 过滤逻辑隔离Collection 原生隔离Collection 原生隔离写入吞吐中高极高查询延迟中10万条 30ms低Rust 实现低分布式优化内存占用中随 PG 共享低Rust 高效利用高多节点运维成本低复用 DBA 技能中需要学习 Qdrant高分布式运维Spring AI 支持完整完整完整图形化界面需要额外工具pgAdmin内置 Dashboard需要 Attu 等工具云托管RDS for PG各云厂商Qdrant CloudZilliz Cloud开源协议Apache 2.0Apache 2.0Apache 2.0适用场景中小项目已有 PG中大型项目性能有要求超大规模分布式五、选型决策树你的 RAG 系统数据量是多少 │ ├── 50 万条且已有 PostgreSQL │ → PGVector复用已有基础设施最省事 │ ├── 50 万 - 1000 万条或有多租户需求 │ → Qdrant高性能运维简单Collection 隔离 │ → 也可以 PGVector 垂直扩容先撑一段时间 │ └── 1000 万条或需要水平扩展 │ ├── 有专职运维团队数据量亿级 │ → Milvus真分布式扛得住 │ └── 没有专职运维但数据量大 → Qdrant Cloud 或 Zilliz Cloud云托管省运维 其他约束条件 │ ├── 数据不能上云必须私有化部署 │ → Qdrant 单机运维最简单 │ → Milvus 单机版比集群版简单但组件还是多 │ ├── 团队熟悉 SQL不想学新查询语言 │ → PGVectorSQL 查向量 │ └── 需要最快速的 Demo / 验证 → PGVectordocker 一行最快