如何为本地部署 RAG 选择向量数据库：ChromaDB vs Qdrant vs Milvus vs FAISS

如果你正在构建一个完全在自有基础设施上运行的 RAG 管道，你面临的首要决策之一就是使用哪个向量数据库。向量存储位于检索层的核心——它保存你的文档嵌入，并提供为 LLM 提供上下文的最近邻查询。

在生产 RAG 部署中，有五个自托管向量数据库持续出现：ChromaDB、Qdrant、Milvus、Weaviate 和 FAISS。每个在设置复杂度、可扩展性、元数据过滤和运维开销方面做出了不同的权衡。本指南梳理这些权衡，帮助你为本地部署 RAG 选择最佳向量数据库，既不过度设计也不欠缺构建。

为什么向量存储的选择很重要

你的向量数据库不仅仅是一个存储层。它直接影响：

• 检索延迟。 缓慢的最近邻搜索意味着缓慢的响应。在规模化场景下，暴力扫描和优化索引之间的差异就是 20ms 和 2 秒的差异。
• 过滤精度。 大多数 RAG 系统需要元数据过滤——按文档类型、日期范围、部门或访问级别。并非所有向量存储都能同样出色地处理这一点。
• 运维负担。 有些存储只需一个 pip install。其他则需要 Kubernetes、etcd 和分布式存储后端。正确的选择取决于你的团队愿意管理多少基础设施。
• 可扩展性上限。 一个拥有 50,000 个向量的原型与一个拥有 5000 万个向量的生产系统有着不同的需求。在项目中途迁移向量存储是痛苦的。

五种选项的对比

以下是针对本地部署 RAG 最重要维度的实用对比。

ChromaDB

ChromaDB 是从零到可用 RAG 检索的最快路径。它嵌入运行在你的 Python 进程中，或作为轻量级服务器运行。你用 pip 安装它，指向一个目录，然后开始插入向量。无需配置基础设施。

权衡在于规模。ChromaDB 在单节点上可以很好地处理几百万个向量，但不提供分布式模式进行水平扩展。元数据过滤覆盖基本的等值和范围查询，但缺乏 Qdrant 或 Weaviate 的表达力。

何时选择 ChromaDB： 你是一个小团队，正在构建文档少于 500 万的 RAG 系统，你重视简单性胜过原始性能。你想让检索本周就能工作，而不是下个季度。

Qdrant

Qdrant 是一个用 Rust 编写的专用向量搜索引擎。它作为单个 Docker 容器运行用于独立部署，或在多个节点间以分布式模式运行。性能强劲——Rust 的内存模型使 Qdrant 具有持续的低查询延迟，无垃圾回收停顿。

Qdrant 的突出之处在于过滤。其 payload 索引系统支持嵌套字段、地理查询和复杂的布尔条件。对于需要将检索范围限定到特定部门、日期范围或文档类别的 RAG 管道，Qdrant 原生处理这些需求，无需应用端后过滤。

何时选择 Qdrant： 你需要具有丰富元数据过滤的生产级检索，并且想要单容器部署。你的语料库在低百万到数千万向量范围。你想要强性能而不需要分布式数据库的运维复杂度。

Milvus

Milvus 是重量级选项。它专为十亿级向量搜索设计，作为分布式系统运行，具有独立的查询节点、数据节点、索引节点和协调服务。最小的 Milvus 部署需要 etcd 用于元数据、MinIO 用于对象存储，以及 Milvus 服务本身。

这种复杂性在规模化时是合理的。Milvus 支持多种索引类型（IVF、HNSW、DiskANN），处理自动数据压缩，并可通过添加节点水平扩展。如果你正在索引大型企业的整个文档语料库——数千万份文档、数亿个分块——Milvus 就是为这种工作负载构建的。

何时选择 Milvus： 你有专门的基础设施团队，你的向量数量将超过 5000 万，你需要水平可扩展性。你愿意在运维复杂度上投入，以换取无需架构变更即可扩展的能力。

Weaviate

Weaviate 将自己定位为不仅仅是向量数据库——它是一个搜索平台，内置向量化模块、混合搜索（将稠密向量与 BM25 关键词搜索结合）和类 GraphQL 查询 API。它作为单个二进制文件或 Docker 容器运行，集群可用于水平扩展。

混合搜索能力是 Weaviate 的显著特征。许多 RAG 用例受益于将语义搜索（这是什么意思）与关键词搜索（这个确切术语是否出现）结合。Weaviate 在单次查询中处理两者，简化了你的检索管道。

权衡在于配置面。Weaviate 有很多参数——模式定义、模块选择、向量化器配置——学习曲线比 ChromaDB 或 Qdrant 更陡峭。

何时选择 Weaviate： 你在 RAG 管道中需要混合搜索（语义加关键词），并且想要一个系统同时处理两者。你的团队能够接受更大的配置面以换取更多内置功能。

FAISS

FAISS（Facebook AI Similarity Search）不是数据库——它是一个库。它提供高度优化的最近邻搜索算法，运行在 CPU 或 GPU 上，但没有服务器、没有 API、没有持久化层、没有元数据过滤。你将向量加载到内存中，构建索引，然后从应用代码中查询。

FAISS 提供的是原始速度。对于批量检索工作负载——对固定索引处理数千个查询——配合 GPU 加速的 FAISS 难以超越。它支持近似最近邻索引（IVF、PQ、HNSW），在单机上可扩展到百万级向量。

权衡在于相似性搜索之外的一切都是你的责任。持久化意味着手动保存和加载索引文件。过滤意味着在你的应用中实现。更新意味着自己重建或部分更新索引。

何时选择 FAISS： 你有很强的工程能力，需要最大检索吞吐量，你的用例涉及批处理或相对静态的索引。你能够自行构建周围的基础设施（持久化、过滤、更新）。

Ertas 如何融入决策

Ertas 不替代你的向量数据库——它处理上游的一切。Ertas 管道导入原始文档，清洗和标准化，将文本分割成检索优化的片段，生成嵌入，然后将生成的向量写入你的团队选择的任何存储中。

Ertas 中的 Vector Store Writer 节点连接到 ChromaDB、Qdrant、Milvus、Weaviate 和 FAISS。五种都在本地运行，将你的数据保留在你的基础设施上。当你的团队决定切换向量存储——从 ChromaDB 原型开发转到 Qdrant 或 Milvus 用于生产——上游管道保持不变。你改变的是目的地，而非过程。

这种分离很重要，因为 RAG 管道中最难的部分很少是向量存储本身。而是将干净、分块良好、正确嵌入的数据放入存储中。自托管向量数据库对比通常关注查询性能，但检索质量更多取决于你放入了什么，而非你如何搜索。

做出决策

对于大多数开始本地部署 RAG 的团队，实用路径是：

1. 从 ChromaDB 或 Qdrant 开始。 先用真实数据让检索运行起来，再优化基础设施。
2. 升级到 Qdrant 或 Weaviate，当你需要更丰富的过滤、混合搜索，或你的语料库超出了轻量级存储能够舒适处理的范围。
3. 升级到 Milvus，仅当你有专门的基础设施团队，且你的规模确实需要分布式向量搜索时。
4. 使用 FAISS，当你需要最大批处理吞吐量，且你的工程团队能够承担基础设施层的所有权。

最适合本地部署 RAG 的向量数据库是与你团队的运维能力和数据实际规模相匹配的那个——而不是对比表上功能最多的那个。