YGG臻星科技

AI 问答库

企业做 RAG，向量数据库该怎么选？

一句话回答

按数据规模和现有技术栈选，别一上来就挑最「专业」的那个。百万级向量以内、团队本来就在用 PostgreSQL 的，pgvector 通常最优 —— 不新增一套要单独运维的系统。千万级以上、需要多副本和在线扩容，才值得上 Milvus 这类分布式向量库。要复杂元数据过滤又不想扛集群选 Qdrant；没有专职运维就用云托管。

关键要点

01向量库很少是 RAG 效果的瓶颈。切分策略、嵌入模型、元数据过滤和重排的影响，通常远大于换一个向量库。
02选型的第一个变量是规模量级，不是功能表。百万级、千万级、亿级是三个不同的世界，跨一档才需要换方案。
03第二个变量是你的运维能力。多一套分布式系统就是多一套监控、备份、升级和故障预案，这笔成本不体现在选型文档里。
04数据在同一个库里能省掉一致性问题。业务数据和向量放在同一个 PostgreSQL 事务里，就不会出现「文档删了向量还在」这类脏数据。
05迁移成本比想象中低。检索层做好抽象后，向量库是整条链路里最容易替换的一环，不值得为它拖延项目启动。

四种常见选择的横向对比

下表按「企业内部 RAG 知识库」这个场景对比，不覆盖推荐系统、图像检索等其他向量用途。规模一栏给的是「不需要额外架构工作就能舒服跑起来」的经验区间，不是硬上限 —— 每一档都能往上顶，代价是调优和运维投入上升。

选项	部署与运维复杂度	舒适规模区间	适合谁
pgvector（PostgreSQL 扩展）	最低。已有 PG 就装个扩展，备份、权限、监控全部复用现成体系	十万到百万级向量，单库即可	绝大多数企业内部知识库；业务数据本来就在 PG 里的团队
Qdrant	中低。单节点容器化即可起步，集群模式再另说	百万到千万级，元数据过滤条件复杂时优势明显	需要按部门、时间、文档类型做多条件过滤，又不想维护集群的团队
Milvus	高。分布式组件多，要独立的监控、扩容与故障预案	千万级以上，或需要多副本、在线扩容、多租户隔离	有平台工程团队、向量规模确实上量、多业务线共用检索平台
云托管向量服务	最低（对你而言），但数据出域，且要评估厂商锁定	弹性好，规模基本不用你操心	没有专职运维、数据不敏感、想尽快验证业务的团队

先别急着选库，先看这几件更重要的事

实践中「检索不准」的原因排序大致是：文档切分不合理（切断了上下文，或一段里塞了几个主题）、缺元数据过滤（把全公司文档混在一起检索）、嵌入模型与语料语言/领域不匹配、没有重排环节、最后才轮到向量库本身的召回算法差异。也就是说，如果你现在的知识库答不准，换一个向量库大概率不会改变结果。一个务实的顺序是：先用最省事的方案（多数情况下是 pgvector）把整条链路跑通，建好评测集，再用评测集去判断到底哪一环拖后腿。

什么时候该从 pgvector 迁走

有几个比较明确的信号。一是数据量持续增长到千万级以上，且索引重建时间已经影响到正常写入。二是检索延迟在业务可接受范围之外，且调整索引参数、加机器都压不下来。三是需要向量检索独立扩缩容 —— 业务库和检索负载互相影响，同一个实例上顾此失彼。四是出现分片、多副本、多租户物理隔离这类需求，用一个关系库硬撑代价太高。反过来，如果只是「听说 Milvus 更专业」，或者只是想要某个还没用上的功能，那不是迁移的理由。迁移本身要付出重建索引、双写校验、切流验证的成本，值得为真实瓶颈付，不值得为架构美学付。

适用边界

什么情况下本答案不成立

本文只讨论企业内部 RAG 知识库场景。推荐系统、以图搜图、实时特征检索的负载特征完全不同，结论不能直接套用。
文中的规模区间是「不做额外架构工作就能舒服运行」的经验判断，受向量维度、过滤条件复杂度、并发量和硬件影响很大，属于量级参考而非阈值。上线前应用你自己的数据做压测。
各向量库都在快速迭代，功能差距每年都在收窄。选型时应以当前版本的官方文档为准，不要依据一两年前的对比文章。
如果数据受合规约束不能出内网，云托管向量服务直接出局，这是前置条件而非权衡项。

同义问法

pgvector 和 Milvus 哪个好
做知识库一定要用专门的向量数据库吗
向量数据库怎么选型
几百万条向量用什么存
向量库要不要自己部署