向量数据库选型记：Milvus vs. Chroma 的一周对比实验

LLM 项目落地到检索增强（RAG）时，向量数据库是关键决策。八月我们做了一次为期一周的“真数据”对比实验，结论写在前面：如果你要支撑 >1000 QPS 的检索，Milvus + GPU 索引值得投入；如果是中小团队 + 快速迭代，Chroma 足够但要注意运维策略。

---

1. 实验设计

• 数据集：13 万条中文 FAQ（平均 120 token），使用 bge-large-zh 向量化；
• 查询集：500 条真实搜索日志 + 200 条人工构造的长尾问题；
• 硬件：
  • Milvus：2 × c8i.2xlarge（32G 内存）+ GPU 索引（1 × g6.xlarge）
  • Chroma：1 × c8i.2xlarge（Docker Compose 部署）
• 指标：Recall@5、P95 延迟、资源成本、运维复杂度。

---

2. 索引与配置

Milvus

• 存储引擎：HNSW（M=32, efConstruction=200）
• GPU 索引：IVF_PQ，PQ=64，使用 index_type: GPU_IVF_PQ
• 写入策略：批量 5000 条，启用 async flush
• DataNode/QueryNode 分离，配合 Pulsar 做消息队列

配置片段：

index:
	type: IVF_PQ
	metric_type: IP
	params:
		nlist: 2048
		m: 64
		nprobe: 32

Chroma

• 存储模式：duckdb + persist_directory
• 索引：hnswlib（space=’cosine’, M=48, ef_construction=200）
• 写入策略：增量 1000 条，写入后 persist()
• 并发访问通过 gunicorn + uvicorn 组合暴露 HTTP API。

---

3. 测试结果

指标	Milvus	Chroma	说明
Recall@5	0.93	0.91	数据量大时差距不大
P95 Latency	68ms	145ms	Milvus GPU 索引优势明显
QPS 峰值	1500	350	Chroma 受限于单节点 CPU
写入速度	2.4 万条/分钟	8000 条/分钟	Milvus 批量写入效率高
成本 (月)	￥6.3k	￥2.1k	以上硬件配置估算

额外观察：

• Chroma 的持久化目录增长较快，需要定期 vacuum；
• Milvus 引入了更多组件（etcd、pulsar、minio），运维门槛高，建议托管服务或基础设施团队支持；
• 在 50 万数据量下，Chroma 的内存占用达到 18GB，restart 需要 90s 恢复，期间无法服务。

---

4. 开发体验与 API 生态

• Milvus：有完善的 Python SDK + ORM（pymilvus），但模型需要先定义 schema；
• Chroma：API 简洁，适合作为嵌入式数据库，与 LangChain 集成紧密；
• 在我们的链路中，Milvus 需要额外的服务来做元数据管理（Document Store），而 Chroma 可以直接存 metadata。

---

5. 决策清单

选择 Milvus 的理由：

1. 查询 QPS > 500，且有增长预期；
2. 数据量 > 100 万，需要分片/冷热分层；
3. 团队有 DevOps 能力或预算使用云托管版。

选择 Chroma 的理由：

1. 团队规模小，对自运维接受度高；
2. 需要快速迭代、频繁重建索引；
3. 希望与 Python 生态深度集成（如直接在 notebook 调试）。

我们最终方案：

• 线上主库使用 Milvus，部署在 K8s，配备独立监控；
• 研发沙箱保持 Chroma，方便研究员做算法实验；
• 通过统一的 Repository 层屏蔽差异，向上游暴露一致的接口。

---

6. 下一步

• 计划引入 Delta Lake + Milvus 的冷数据归档策略；
• 使用 Towhee / Jina 做自动向量化流水线；
• 建立“双写 + 校验”机制，确保多集群数据一致。

在 LLM 时代，向量库不是谁火用谁，而是把“数据规模、预算、团队能力”三个维度拉在一起做决策。指标、压测和回滚一样都不能少。