Vector Databases for RAG: Pinecone, pgvector, Chroma, and How to Choose
标题：用于 RAG 的向量数据库：Pinecone、pgvector、Chroma 以及如何选择
原文：
用于 RAG 的向量数据库：Pinecone、pgvector、Chroma 以及如何选择
一份关于为检索增强生成系统选择合适嵌入索引的技术指南。
向量数据库是一种专门构建的系统，用于大规模存储、索引和查询高维嵌入。在检索增强生成（RAG）流水线中，它承担一个关键功能：给定一个编码为向量的用户查询，在毫秒内从你的语料库中返回最近的相关文档。这个基础设施位于你的嵌入模型和语言模型之间，选择合适的数据库决定了你的 RAG 系统是生产就绪，还是在负载下崩溃的原型。
为什么现在这很重要
到 2026 年，RAG 已不再是实验性技术。团队正在将检索系统推向生产环境，而延迟、成本和可靠性至关重要。向量数据库市场已经集中在少数经过验证的供应商上，每个都有不同的权衡。Pinecone 在易用性和托管基础设施方面占主导地位。pgvector（PostgreSQL 扩展）对于已经在运行 Postgres 并希望避免新基础设施的团队来说变得可行。Chroma 和 Weaviate 主导了开源部署。问题不再是“我是否应该使用向量数据库”，而是“哪一个适合我的约束条件并且不会超出我的预算”。
实际现实：2026 年，大多数构建 RAG 系统的团队在托管服务（Pinecone、使用 pgvector 的 Supabase）和自托管开源（Qdrant、Weaviate、Milvus）之间进行选择。决策取决于三个很少冲突的变量。首先，数据集大小（向量数量和元数据的基数）。其次，查询延迟要求（100 毫秒是否可以接受，还是需要低于 20 毫秒？）。第三，数据驻留和成本限制。正确获取这三个输入，选择就会变得明显。
向量数据库如何解决索引问题
Photo by Brett Sayles on Pexels.
如果没有索引，向量搜索意味着计算从查询嵌入到语料库中每个文档嵌入的距离。对于 100 万个向量，每次查询需要 100 万次距离计算。在合理的嵌入维度（现代模型为 768 或 1536）和商用硬件下，朴素搜索大约需要 300 到 500 毫秒。这对于生产 RAG 来说是不可接受的。
向量数据库通过索引算法来解决这个问题，这些算法将向量空间划分为区域，使搜索能够跳过大多数候选者。两种主要方法是 HNSW（分层可导航小世界）和 IVF（倒排文件）。HNSW 构建了一个邻近图，其中每个向量在多个层级连接到其最近邻，从而实现对数级遍历。IVF 将向量划分为簇，只搜索附近的簇，然后在这些簇内计算精确距离。Pinecone 和 Chroma 默认使用 HNSW，它为大多数 RAG 工作负载提供了高召回率和一致的性能。Milvus 和 Weaviate 两者都支持，在内存、速度和召回率之间具有可调的权衡。
实际影响：一个调优良好的 HNSW 索引可以在 5 到 15 毫秒内从 1000 万个向量中返回最相似的 10 个文档。相同的操作使用 IVF 可能达到 8 到 12 毫秒，且内存开销更低。两种方法没有固有优劣。HNSW 适用于静态或缓慢变化的语料库，其中召回率至关重要。IVF 适用于内存受限、可以接受少量召回率权衡以换取更快新文档摄取的大型数据集。
比较主要参与者
Pinecone 是最完整的托管产品，专为 RAG 构建。它开箱即用地处理 HNSW 索引、自动扩展、多区域复制和命名空间隔离。Pinecone 还原生支持混合搜索（将向量相似性与 BM25 词法搜索相结合），这对于许多 RAG 系统至关重要，因为精确术语与语义相关性同等重要。成本高于自托管替代方案：存储每 100 万个向量每月约 0.10 美元，加上查询成本，根据层级每千次查询在 0.001 到 0.01 美元不等。对于一个拥有 500 万个向量和每月 1000 万次查询的生产系统，预计基本成本为 100 到 300 美元，外加超额费用。
pgvector 是 PostgreSQL 扩展，将向量搜索带到了已经在数百万台服务器上运行的数据库生态系统中。如果你有一个 Postgres 实例，设置很简单：创建一个向量列，添加 GiST 或 IVF 索引，然后编写 SQL。对于中小型语料库（低于 500 万个向量），召回率是可以接受的，并且你可以继承 Postgres 的所有事务语义、备份基础设施和监控。但缺点是：pgvector 在查询时对 GiST 索引使用精确距离计算（以延迟换取保证正确性），并且对最复杂的索引技巧支持有限。对于超过 1000 万个向量的数据集，即使在强大的硬件上，查询延迟也会超过 500 毫秒。pgvector 非常适合已经在管理 Postgres 的团队，对他们来说，向量搜索的边际成本几乎为零。
Chroma 轻量级，易于嵌入 Python 应用程序。它可以运行在内存中，也可以持久化到 SQLite 或 DuckDB，非常适合原型、本地开发和小型部署（少于 10 万个向量）。Chroma 底层使用 HNSW，运营开销极小。限制在于规模：没有集群、没有多副本故障转移，也没有托管选项。Chroma 不是生产系统的替代品，而是通向它们的垫脚石。
Qdrant 针对高吞吐量场景进行了优化。它支持稀疏向量（对于无需外部 BM25 的混合搜索很有用）、量化（缩小向量维度以节省内存并提高速度）以及极快的索引（每秒数百万个向量）。如果你的瓶颈是摄取速度，或者你正在运行内存效率不可妥协的大规模数据集，那么 Qdrant 就是选择。
混合搜索和元数据过滤的实际应用
Photo by Rafael Minguet Delgado on Pexels.
纯向量搜索有一个盲点：它完全依赖于嵌入模型的质量以及查询与文档之间的语义相似性。像“什么是 GDPR 第 5 条？”这样的查询，如果文档使用缩写“GDPR”而没有展开，则会失败。一个只优化余弦相似度的向量数据库会将关于隐私原则的文档排名高于包含确切缩写的文档，即使后者才是用户想要的。
混合搜索通过将语义搜索与关键词（BM25）分数相结合来解决这个问题。查询被编码为向量，同时进行标记化以进行词法匹配。结果按两个信号的加权混合进行排名。Pinecone 的混合搜索实现为向量和词法分量分配可调整的权重。实际效果：添加混合搜索可将面向命名实体的领域（法律、医疗、金融）的召回率提高 15% 到 30%，代价是轻微的延迟（每次查询增加 5 到 10 毫秒）。
元数据过滤同样重要。在 RAG 系统中，文档通常带有相关元数据：创建日期、作者、来源 URL、主题标签。用户查询可能包含一个过滤条件：“显示过去 30 天内的结果”或“限制为标记为‘紧急’的文档”。高效的元数据过滤将过滤条件下推到索引本身，使得距离计算只在候选向量上进行，而不是整个语料库。Pinecone 和 Weaviate 原生处理这点。使用 pgvector，你可以将向量搜索与 SQL 谓词结合使用，这可以工作，但如果过滤条件在低基数字段上是选择性的，可能会很慢。
工程决策：从一开始就投资于元数据过滤。确定字段