打造卓越软件
让我们一起创造非凡。
Lasting Dynamics 提供无与伦比的软件质量。
努恩齐奥·朱利亚诺
2026年7月16日 • 阅读时间14分钟
我们去年提供咨询的一支团队曾进行过一项RAG试点项目，该项目在演示中给出了非常出色的答案，但在生产环境中却给出了令人尴尬的答案。模型相同、提示词相同、文档也相同。 唯一的变化是数据规模：演示环境中是4,000份文档，生产环境中则是900,000份。他们使用的向量数据库（仅因它是教程中的默认选项，便在短短一个下午内选定）随着索引规模的扩大，召回率悄无声息地下降，而此前无人对此进行监测。解决之道并非改进模型，而是更换 RAG 的向量数据库 以及一种能够充分考虑其语料库实际行为特征的重新索引策略。.
这种故事司空见惯，甚至可以算作一种类型。向量存储是检索增强生成系统中最不起眼的组件，却也是决定该系统能否正常运行的两个或三个关键因素之一。 本指南并非基于供应商的功能对比表编写，而是源自一个工程团队的实践经验——该团队已在真实的客户系统中部署了 Pinecone、Weaviate、Qdrant、Milvus、Chroma 和 pgvector。它是我们 企业级 RAG 架构指南; 如果您想了解整个处理流程，请从那里开始。如果您已经决定构建 RAG，现在需要确定嵌入向量应存储在何处，请从这里开始。.
RAG 的向量数据库有一项任务是普通数据库无法很好地完成的：给定一个查询嵌入向量，在数百万或数十亿个存储的嵌入向量中快速找到最近邻，而无需逐一扫描所有嵌入向量。 它通过近似最近邻（ANN）索引来实现这一功能，通常采用HNSW算法，有时也使用IVF算法或基于磁盘的变体。"近似"一词至关重要。 每种向量数据库都会以牺牲少量召回率为代价来换取大幅提升的速度，而它们在该曲线上的具体位置，正是决定RAG系统能否找到正确片段，还是会自信地检索到错误片段的关键所在。.
这种故障模式非常隐蔽，因为在演示中无法察觉。当向量数量为 5,000 个时，几乎任何配置都能返回正确的邻居，因为候选项非常少，即使是一个粗糙的索引也能找到它们。当数量达到一千万时，索引参数（即 ef （搜索宽度、图连接数、量化设置等）开始影响召回率。一个"运行良好"了六个月的系统，通常在此期间性能一直在下降；只是团队从未针对检索质量建立评估框架，因此未能察觉这一问题。.
因此，选择的重点其实并非"哪个产品的 API 最友好"，而是：哪款引擎能在您可接受的查询延迟下，以流量所需的吞吐量，提供您所需的召回率，且当语料库规模扩大三倍时成本不会激增，同时也是您团队能够实际运维的。 这五项约束条件很少会指向同一种产品，这就是为什么对于"RAG 最适合的向量数据库是什么"这个问题，诚实的回答总是反问一句。.
不妨不再将它们视为六种相互竞争的产品，而是将其视为解决不同问题的五个类别。大多数错误决策都源于将一个层级的数据库与另一个层级的数据库进行比较，仿佛它们可以互换一样。.
"(《世界人权宣言》) 全托管无服务器 tier 是 Pinecone 的主场：你无需触碰任何索引参数，也无需运行任何节点，但为此需要付出每条查询的成本以及供应商锁定的代价。该 开源、可自主部署的引擎 tier（Qdrant、Weaviate、Milvus）让您能够掌控部署，并在大规模部署时获得最佳的性价比，但您需要自行负责运维工作。该 嵌入式 / 原型设计 该层级是 Chroma：非常适合在半天内让 RAG 循环在笔记本电脑上运行起来，但并非为服务百万用户而设计。.
"(《世界人权宣言》) 作为现有数据库的扩展 tier 是 pgvector，它能在您现有的 PostgreSQL 环境中添加向量搜索功能，当您的系统规模适中且运维需求较低时，这确实是一个很好的解决方案。而 十亿级分布式 该层是 Milvus 的真正用武之地，在这里，数据集规模足够大，分布式架构不再是“大材小用”，而是变得不可或缺。.
原因 色度向量数据库 该领域搜索量最高的关键词之一，并非因为Chroma是最好的生产环境存储库，而是因为它是大多数工程师接触到的第一个RAG向量数据库。这一点值得我们在后续发展中继续保持。.
| 数据库 | 型号 | 索引 | 混合搜索 | 切合实际的上限 | 最适合 |
|---|---|---|---|---|---|
| 松果 | 托管式无服务器 / Pods | 专有（HNSW家族） | 支持稀疏-稠密模式 | 非常高（受控） | 对基础设施建设不感兴趣的团队 |
| Qdrant | 开源 / 托管云 | HNSW + 有效载荷过滤 | 原生（密集型 + 稀疏型） | 高，数千万以上 | 性价比最高的自托管方案 |
| Weaviate | 开源 / 托管云 | HNSW | 原生 BM25 与载体融合 | 高 | 混合搜索 + 内置模块 |
| Milvus | 开源 / Zilliz 云 | IVF、HNSW、DiskANN、GPU | 已支持 | 数十亿级分布式 | 超大规模语料库，高QPS |
| Chroma | 嵌入式/轻量级服务器 | HNSW | 稀疏 + 密集（BM25、RRF） | 低至中等 | 原型开发、LangChain 教程 |
| pgvector | PostgreSQL 扩展 | HNSW + IVFFlat | 通过 SQL + 全文搜索 | 中等 | 已使用 PostgreSQL 的团队 |
松果 当你团队中最昂贵的资源是工程师的时间而非云服务支出时，这就是你的最佳选择。其无服务器层消除了过去那种"我该配置多少个 Pod"的猜测游戏，对于一个在没有平台团队支持的情况下发布首个生产级 RAG 功能的团队来说，这种运维上的无忧状态确实能带来实实在在的经济价值。 其取舍显而易见：你无法查看索引内部结构，无法为满足数据驻留要求而自行托管，而且在规模扩大后，按查询计费的经济效益将不再具有吸引力。Pinecone 作为首个投入生产的数据库是正确的选择，但对于许多团队而言，作为第十个数据库则并非明智之选。.
让我们一起创造非凡。
Lasting Dynamics 提供无与伦比的软件质量。
Qdrant 当客户能够自行运维基础设施，且关注大规模查询的成本时，这是我们最常选用的一款数据库。 该数据库采用Rust语言编写，将HNSW索引与真正的一流有效载荷过滤功能相结合，能够实现"最近邻搜索，但仅限于该用户有权查看的文档、特定司法管辖区以及指定日期范围内的文档"这一需求，同时不会牺牲召回率。 这种过滤搜索能力绝非可有可无；在企业级 RAG 应用中，这通常是一项硬性要求，而 Qdrant 在此方面的表现优于大多数同类产品。它原生支持稀疏向量和稠密向量，使得混合搜索成为一种配置选项，而非必须运行的第二套系统。.
Weaviate 在相邻领域占据一席之地，但侧重点有所不同。 其混合搜索（融合了 BM25 关键词评分与向量相似度）是一条成熟且文档完善的解决方案，而非需要自行组装的方案；其模块生态系统（内置向量化器、重新排序器、生成式步骤）则吸引了希望将更多处理流程整合到单一系统中的团队。 在 Qdrant 和 Weaviate 之间做出选择，很少是基于性能的考量；关键在于您是想要一个由自己组合的精简、快速的引擎（Qdrant），还是一个功能更全面的“开箱即用”平台（Weaviate）。 两者均为开源，均支持自主部署，且扩展能力都远超大多数企业语料库的实际规模。.
Milvus 这是大多数团队目前尚未找到的答案。它专为处理数十亿维向量、高QPS（每秒查询次数）的场景而设计，采用分布式架构，支持多种索引类型（包括基于GPU和磁盘的选项），并具备相应的运维管理范围。 如果您的语料库规模确实庞大，属于网络级、海量多租户场景，或是与基础模型相关的检索工作负载，那么 Milvus（或其托管版本 Zilliz）的复杂性便物有所值。 如果您的语料库只有 200 万份内部文档，那么 Milvus 就像是用数据中心级别的工具来处理工作坊级别的任务，您将把时间花在运维上，而不是改进检索效果。.
Pinecone、Weaviate、Qdrant 和 Milvus 之间有什么区别？ Pinecone 是唯一一款完全托管、无服务器式的解决方案——零运维开销，但在大规模部署时成本最高。Weaviate 和 Qdrant 均为开源且需自行部署，在支持混合搜索的同时，提供最佳的性价比。Milvus 通过分布式架构处理数十亿级数据集。 Chroma 虽然原型开发速度最快，但在大规模生产环境中尚不成熟。.
Chroma 矢量数据库 正因为它如此受欢迎，才值得专门开辟一个章节来详细介绍。这是从零开始构建一个可运行的检索循环的最快途径（pip install, （, 添加文档、查询、完成），这正是它在大多数 LangChain 教程中被设为默认选项的原因，也是为什么这么多人会直接按其名称进行搜索。这种易用性对于原型开发、教学以及小型内部工具而言，确实是一大优势。.
Chroma 还 弥合了混合搜索的差距：它现在支持通过逆秩融合，将一等稀疏向量（BM25 和 SPLADE）与稠密相似度进行融合——这正是本指南在 Weaviate 和 Qdrant 中所称赞的机制。 因此，企业不再使用 Chroma 的原因已不再是检索能力，而是运营规模——包括多租户支持、高并发服务，以及在生产流量下的访问控制。从 Chroma 起步是一个明智的决定；迁移问题如今关乎运营，而非搜索本身。.
pgvector 这是务实派的首选，却是一项真正被低估的技术。如果您的数据已经存储在 PostgreSQL 中，添加 pgvector 扩展后，您就可以在关系型数据旁进行相似度搜索，且该操作是在您已信任的事务范围内进行的，并具备您现有的备份和访问控制机制。 最新版本支持 HNSW 索引，这弥合了此前导致其被淘汰的大部分性能差距。.
对于规模在数百万左右的语料库，如果更重视操作简便性而非人工神经网络（ANN）的原始吞吐量，pgvector 通常是最佳选择，而"无需新增基础设施"这一优势，确实是架构设计上的合理优势。 当数据集规模扩大到数千万级别且需要高并发时，专用引擎将更具优势，但许多生产环境中的 RAG 系统根本不会达到这一规模。.
真正能影响决策的比较并非逐项功能对比，而是你能直观想象到的全生命周期总拥有成本。以一个现实的中等规模 RAG 工作负载为例：1000 万个 1024 维的嵌入片段，查询流量适中，且启用了混合搜索。.
在完全托管的无服务器数据库中，这种资源占用会产生可预测的月度存储和查询费用，该费用会随查询量增加而上升，且绝不包含工程师的薪资。 在同一云平台上自建的 Qdrant 或 Weaviate 集群中，同等容量的基础架构成本通常仅为托管服务价格的一小部分（在此规模下，每月费用往往便宜数倍），但您需要承担实际的、持续的运维成本： 资源配置、升级、监控、值班，以及任何严肃系统在更换嵌入式模型时所需的重新索引操作。.
从创意到发布，我们根据您的业务需求量身打造可扩展的软件。
与我们合作，加速您的成长。
盈亏平衡点本质上是一个人员配置问题，只是伪装成了基础设施问题。如果你已经运营着一个负责管理有状态服务的平台团队，那么为 RAG 自建开源向量数据库在总体上几乎总是更便宜，而且随着查询量的增加，节省的成本会进一步扩大。 如果你没有这样的团队，且搭建该系统意味着需要一名工程师利用晚间和周末的时间学习如何运维一个新的分布式数据库，那么一旦如实计算工程时间，托管方案通常会更划算。.
我们曾看到一些团队通过自建服务器来"节省成本"，结果却在运维上耗费了三个工程师月的工作量——而这笔费用本足以支付多年托管服务费用。对此进行合理规划的方法，与我们应用于 AI SaaS 开发成本: 关注的是人，而不仅仅是发票。.
纯向量搜索存在一个具体且可重复的缺陷：它不擅长处理精确的词素。零件编号、合同ID、药品名称、错误代码、ICD-10编码以及不常见的姓氏（这些正是企业用户实际搜索的、稀有且信号强度高的术语）会被高密度嵌入转化为语义上的糊状物。 当用户查询"AX-4471-C 保单"时，向量搜索会“热心地”返回关于保单的一般性文档。.
混合搜索通过在向量索引的基础上并行运行词汇索引（如BM25或类似算法），并融合搜索结果（通常采用互逆排名融合算法）来解决这一问题。关键词检索能精准命中罕见的精确术语；向量检索则能捕捉到关键词检索遗漏的语义匹配；而融合则使您同时获得这两方面的结果。 根据我们的经验，这是最常能将企业级 RAG 系统从"令人印象深刻但不可靠"转变为"值得信赖"的单一检索改进。 正因如此，像 Weaviate 和 Qdrant 所提供的原生混合搜索支持，才是一项真正的选择标准，而不仅仅是一个勾选框。如果数据库迫使您运行并同步一个独立的关键词系统，那么这个数据库最终会在凌晨 2 点出现数据不一致的情况。.
公开基准虽有其用，却经常被滥用。. ANN-基准测试 该研究仍是衡量各索引实现方案中“召回率与吞吐量”权衡关系的标准参考，其中包括以下厂商： Qdrant 发布他们自己的可复现测试套件。阅读这些套件后，请不要过分关注排行榜上的排名，因为已发布的基准测试是在经过精心筛选的数据集上运行的，且采用了经过调优的参数，这些参数可能与您的语料库、维度、过滤模式或延迟预算不符。.
真正重要的数字并不是"数据库X在某人的基准测试中达到了2,000 QPS"。而是recall@k在 您的 评估集，位于 您的 延迟上限，其中 您的 应用了元数据过滤器；因为带过滤的搜索与不带过滤的搜索行为差异很大，而大多数企业查询都是带过滤的。唯一应作为架构决策依据的基准测试，是你在自己数据的代表性样本上运行的测试。任何团队如果仅凭排行榜上的排名就为 RAG 选择向量数据库，却没有进行私有评估，那就等于在用别人的作业来做决定。.
不要借用他人的QPS数据来为决策辩护，而应衡量适用于你自己的数据。.
抛开供应商的宣传噱头，选择适用于 RAG 的矢量数据库其实只需回答几个简单直接的问题。.
先从运维入手。如果团队中无人愿意负责管理一个有状态的分布式服务，那就选择托管服务（如 Pinecone，或 Qdrant/Weaviate/Zilliz 的托管云），并停止为了节省成本而进行优化——这种节省最终会以故障的形式回馈给你。 如果你有已经负责运维数据库的平台团队，那么自主部署开源向量数据库是一个可行的选项，而且通常成本更低。.
我们设计并打造脱颖而出的高品质数字产品。
每一步都可靠、高效、创新。
接下来，请评估您现有的技术栈。如果您的数据存储在 PostgreSQL 中，且规模在数百万级别，建议先尝试 pgvector；最佳的新基础设施往往就是无需新建基础设施。只有在您实际测得性能瓶颈后，才需要考虑超越现有方案。.
接着考虑规模和搜索模式。如果需要处理数十亿维向量或极高的每秒查询数（QPS），那么Milvus是理想选择。如果需要进行大量过滤搜索且对成本敏感，那么Qdrant是理想选择。 若将混合搜索视为首要需求，且希望将更多处理流程整合到单一平台中，则应选择 Weaviate。若希望在无需基础设施团队的情况下推出首个生产级功能，则应选择 Pinecone。而若你计划用新系统取代当前的笔记本电脑原型，则应选择 Chroma——这是有意的选择，因为你知道未来会进行迁移。.
Pinecone 是不是最好的矢量数据库？ Pinecone 的部署最为简便，最适合缺乏基础设施专业知识的团队。不过，在企业级规模（数百万个嵌入向量、高 QPS）下，Qdrant 和 Weaviate 通常能提供更高的成本效益。Pinecone 的无服务器层适合原型开发；专用 Pod 则适合生产环境。.
请注意，该框架永远不会产生唯一的"全球优胜者"，因为根本不存在这样的优胜者。它生成的只是针对特定约束条件集的合适数据库，而这才是生产环境中唯一具有实际意义的“最佳”方案。.
这些错误在各个团队和业务领域中屡见不鲜，正因如此，才值得特别指出。.
第一点是根据演示进行选择。一个在5,000个向量下表现出色数据库，并不能说明它在1,000万个向量下的表现如何，而教程中的默认设置会意外地成为影响生产环境的决策依据。第二点是忽略了过滤搜索。 开发团队通常会对未过滤的最近邻查询进行基准测试，随后将系统投入生产，但随后发现，当添加法律要求的访问控制和管辖范围过滤器后，查询的召回率急剧下降——因为他们从未测试过实际运行的查询模式。.
第三点是将混合搜索视为可选项；但对于任何包含代码、ID 或专有名词的语料库而言，这绝非可选项。第四点是低估了重新索引所需的预算：嵌入式模型会不断升级，而一个没有计划对语料库进行重新嵌入的系统，终将悄然衰败。 第五点，也是代价最高昂的，是在缺乏评估框架的情况下做出选择，推出一个无人衡量检索质量的系统，以至于"它能用"的含义变成了"目前还没有人抱怨得足够大声"。"
这些情况都不算罕见。它们都是在尚未确定如何判断基础设施是否正常运行之前就选定基础设施所必然导致的后果。如果您正处于这一历程的早期阶段，仍在构建周边系统，请参考我们关于 构建原生AI应用程序 以及……的基础知识 如何构建人工智能 全面探讨这一决定背后的情况。.
2026年，RAG最适合使用的矢量数据库是哪一个？ 对于大多数生产环境的 RAG 团队而言，最佳选择取决于您的部署模式：若需完全托管的无服务器方案，可选择 Pinecone；若需自托管的开源方案，可选择 Qdrant 或 Weaviate；若您已使用 PostgreSQL 且无需处理数十亿级数据，则可选择 pgvector。 对于采用混合搜索的大规模企业级 RAG 应用，Weaviate 和 Qdrant 在性价比方面处于领先地位。.
还有一个人常被点名问起的问题，因此值得直截了当地回答一下。.
LangChain 使用的是哪种向量数据库？ LangChain 原生支持与所有主流向量数据库集成——包括 Pinecone、Weaviate、Qdrant、Milvus、Chroma、pgvector 和 FAISS。由于无需任何配置，Chroma 成为大多数 LangChain 教程中的默认选择。 对于生产环境中的 RAG，LangChain 与 Pinecone 和 Qdrant 的集成方案经过了最充分的实战检验。.
如果你从这篇向量数据库对比文章中只能记住一点，那就请记住这一点：向量数据库是一个约束满足问题，而不是一场人气竞赛，而你往往低估的那个约束因素，几乎总是操作性能。 选择与您团队的工作方式及语料库特性相匹配的引擎，在正式上线前为其搭建评估框架，并随着索引规模的扩大持续复核召回率。最契合这些实际情况的数据库，才是您 RAG 系统最理想的向量数据库——无论本季度基准测试中哪款产品名列前茅。.
正在构建或维修一个生产级RAG系统，并评估其底层基础设施？我们的 企业级 RAG 架构指南 涵盖了整个处理流程：数据摄取、分块、检索、重新排序和评估；该数据库的选择就包含在其中。.
这篇关于矢量数据库的比较文章由Nunzio Giugliano撰写于 Lasting Dynamics, ，一家总部位于欧盟的定制软件开发公司。我们刻意保持模型和供应商中立：在任何一个季度，我们都会在 Pinecone、Qdrant、Weaviate、Milvus 和 pgvector 等平台上交付生产级的 RAG 系统，选择时完全基于客户的实际规模、预算和运营限制，而非供应商的推销话术。 上述每一项权衡都源于实际项目实践，而非数据手册。.
向量数据库用于存储嵌入向量；当收到查询嵌入向量时，它能利用HNSW等近似最近邻（ANN）索引，在数百万或数十亿条记录中于几毫秒内找到最近邻。 RAG 需要这种索引，因为检索质量——即找到正确的片段来为模型提供依据——是区分可靠系统与那些自信地检索出错误上下文的系统的重要标准，而普通数据库无法在如此大规模下进行快速的相似度搜索。.
这取决于人员配置，而不仅仅是账单金额。像 Qdrant、Weaviate 或 Milvus 这样的自托管开源矢量数据库，在规模化部署时，其每月的基础设施成本通常要低几倍，但前提是你已经拥有一支负责运维的平台团队。 如果部署该系统意味着需要一名工程师利用晚间和周末的时间学习新的分布式数据库，那么一旦如实计算工程时间，托管方案（如 Pinecone，或托管的 Qdrant/Weaviate/Zilliz）往往更为经济。.
对于许多生产环境中的RAG系统而言，答案是肯定的。如果您的数据已经存储在PostgreSQL中，且语料库规模在几百万左右，pgvector可以在您的关系型数据旁提供相似度搜索功能，同时保留您现有的备份和访问控制机制；此外，近期对HNSW的支持已基本消除了以往的性能差距。 只有当您的数据量达到数千万级别、面临高并发需求，并且已测得实际性能瓶颈时，才应迁移到专用引擎。.
混合搜索会在向量索引的基础上同时运行词汇索引（BM25），并将搜索结果进行融合，通常采用互补排名融合算法。纯向量搜索在处理精确词素（如零件编号、ID、药物名称、错误代码）时表现较弱，因为密集嵌入会将这些词素平滑处理成语义上的模糊信息。 混合搜索解决了这一问题：关键词侧精准捕捉罕见的精确术语，而向量侧则捕捉语义匹配。这往往是使企业级RAG系统从不可靠转变为值得信赖的关键一环，这也是Weaviate和Qdrant原生支持该功能成为真正选择标准的原因。.
这通常与性能无关。两者都是开源的，都支持自主部署，且扩展能力都远超大多数企业级语料库。如果您想要一个精简、快速的 Rust 引擎，并具备可自行组合且能针对每次查询成本进行调优的一流有效负载过滤功能，那么请选择 Qdrant。 若您需要一个功能更全面的“开箱即用”平台，该平台在同一系统内集成了顶级混合搜索功能及内置模块（向量化器、重新排序器和生成式处理步骤），请选择 Weaviate。.
先从运维入手：如果没有人负责管理一个有状态的分布式服务，那就选择托管服务。接着是技术栈：如果你已经在PostgreSQL上运行，且数据量在数百万级别，不妨先尝试pgvector。 接着考虑扩展和搜索模式：涉及数十亿向量或极高 QPS 的场景适合 Milvus；需要大量过滤且对成本敏感的扩展场景适合 Qdrant；一流的混合搜索方案可选 Weaviate；Pinecone 提供了无需基础设施团队即可部署的首个生产级功能；Chroma 则仅需一台一次性笔记本电脑即可完成原型开发。 没有唯一的赢家，只有最适合你具体约束条件的 RAG 向量数据库。.
将大胆的想法转化为强大的应用。
让我们一起创造出具有影响力的软件。
努恩齐奥·朱利亚诺
Nunzio Giugliano 是 Lasting Dynamics 的市场营销专家，主要负责人工智能、企业软件和数字化转型领域的 SEO 策略、技术内容及 B2B 研究工作。他的工作重点在于将复杂的技术主题以清晰、实用且通俗易懂的方式呈现给首席技术官、创始人、决策者及技术团队。.
