向量数据库选型：从 Chroma 到 Milvus 的取舍

做 RAG 的第一个技术决策，往往就是「用哪个向量库」。网上的对比文章很多，但大多数只比延迟和召回率，忽略了一个更关键的问题：你的团队能否长期运维它。

这篇文章按项目阶段来选型，而不是按 benchmark 排名。

一、先问三个问题

• 数据量有多大：是几万条文档，还是上亿条 chunk？
• 更新有多频繁：一次性导入，还是每天增量、实时删除？
• 团队能运维什么：有没有人愿意维护分布式集群和备份恢复？

再加上两条业务约束：是否需要按租户、时间、权限做强过滤；是否必须和现有 PostgreSQL 事务保持一致。答案会直接排除掉一半选项。

二、原型期：Chroma / FAISS / pgvector

原型阶段的目标是尽快验证检索质量，不是搭建生产基础设施。

Chroma 适合单机、嵌入式场景，几行代码就能建集合、写入、查询，自带元数据过滤，做 demo 和内部工具非常顺手。

FAISS 是向量检索库，不是数据库。它快、索引丰富，但持久化、元数据、增删改都要自己实现。适合对性能有明确要求、且愿意写一层封装的团队。

pgvector 的优势是「你已经有 PostgreSQL」。数据不离开熟悉的数据库，事务、备份、权限都能复用，中小数据量下完全够用。

三、增长期：Qdrant / Weaviate / pgvector

数据量到百万级、查询并发开始上升时，关注点会从「能不能查」变成「过滤是否高效、增量是否稳定、监控是否完整」。

Qdrant 的过滤性能和工程体验都不错，API 清晰，单机部署简单，也支持分布式。适合中小团队作为生产环境的默认选择。

Weaviate 的模块生态更丰富，内置向量化模块和混合检索，适合希望少写胶水代码的团队，但概念和配置也更多。

如果数据量仍在千万级以内、团队又熟悉 PostgreSQL，继续用 pgvector 往往是性价比最高的方案。加索引、分区、读写分离，通常比换一个数据库更省事。

四、规模化：Milvus / Vespa

当数据量进入亿级、需要多副本和高吞吐写入时，专用分布式系统才有意义。Milvus 的索引类型和生态最完整，适合有专职基础设施团队的公司；代价是组件多、运维复杂、资源占用高。

Vespa 更偏向大型搜索场景，排序、聚合、机器学习推理可以放在一起，但学习曲线陡峭，不适合作为第一个向量库。

在这个阶段，选型的关键已经不是功能，而是故障恢复、容量规划和成本。能不能在凌晨三点把集群拉起来，比多 5% 的召回率重要得多。

五、一张选型对照表

阶段	数据量（经验值）	推荐	理由
原型	十万级以内	Chroma / FAISS / pgvector	零运维或低运维，快速验证
增长	百万到千万级	pgvector / Qdrant	过滤、增量、监控更成熟
规模	亿级以上	Milvus / Vespa	分布式、多副本、高吞吐

表中的数字只是经验值，实际边界取决于维度、索引、过滤复杂度和硬件。用真实数据压测，比看任何对照表都可靠。

六、迁移时要注意什么

如果已经用 pgvector 起步，几行 SQL 就能完成建表和检索：

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  doc_id text NOT NULL,
  content text NOT NULL,
  embedding vector(1024) NOT NULL
);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

SELECT id, content, 1 - (embedding <=> $1) AS score
FROM chunks
WHERE doc_id = $2
ORDER BY embedding <=> $1
LIMIT 8;

迁移到专用向量库时，容易忽略四件事：

1. 嵌入模型版本：换库不换模型，向量才能复用；换模型必须全量重建。
2. ID 与元数据映射：业务主键、权限字段、更新时间都要一起迁过去。
3. 双写与灰度：新库先影子写入，对比召回结果，再切流量。
4. 评测基线：用同一套问答集比较 Recall@k，而不是凭感觉判断。

选型的本质，是在「当前阶段的简单」和「下一阶段的扩展」之间找平衡。能让你今天顺利上线、明天不必推倒重来的方案，就是好方案。