Amazon Bedrock 知识库向量库选型对比：OpenSearch、Aurora pgvector、S3

当使用 Amazon Bedrock Knowledge Bases 构建检索增强生成（RAG）解决方案时，选择合适的向量存储会直接影响性能与成本。Amazon Bedrock Knowledge Bases 提供全托管方案和客户托管方案（在客户托管方案中你可以选择自己的向量存储）。本文聚焦于客户托管路径，对三种支持的后端进行对比：Amazon OpenSearch Service、带有 pgvector 的 Amazon Aurora PostgreSQL，以及 Amazon S3 Vectors（Amazon Simple Storage Service 的一项功能），并在不同的 RAG 使用场景中进行比较。

如需查看所有 AWS 向量解决方案的更全面指导，请参阅 AWS vector solutions: Build agentic AI where your data lives。如需了解向量数据库在生成式 AI 应用中的作用，请参阅 The role of vector datastores in generative AI applications。如需关于 RAG 向量数据库的规范指导，请参阅 Choosing an AWS vector database for RAG use cases。

向量数据库在 RAG 解决方案中的位置

RAG 架构将大语言模型（LLM）的能力与信息检索系统相结合，以生成更准确、更及时、更具上下文相关性的响应。其基于数学中的向量概念，文本被转换为与文本含义对齐的向量。对向量执行的搜索会找到与问题语义相似的结果，这比关键词匹配更能有效捕捉语义相似性。

当用户提交查询时，会使用嵌入模型将其转换为向量嵌入。向量数据库（在数据摄取阶段预先处理、分块并将文档内容存储为向量嵌入）执行相似性搜索，找到与查询嵌入最相似的块。通常，系统会检索前 n 个块（例如前五个最相似的块）来丰富原始查询。这些检索到的块作为额外上下文提供给 LLM，使其能够生成更知情、更准确的响应。

向量数据库是原始信息与上下文理解之间的关键桥梁。它将非结构化数据转换为可搜索的、语义有意义的知识空间，帮助大语言模型提供更精确、更相关的响应。向量数据库通过将嵌入向量存储在名为向量索引的高效数据结构中来实现这一点，该结构支持快速、高维度的语义搜索和近即时检索语义相似信息。

图 1：检索增强生成（RAG）架构，在摄取阶段文档被分块、嵌入并存储到向量数据库中，在查询时查询内容被嵌入，检索相似块，并作为上下文传递给 LLM 以生成响应

Amazon Bedrock Knowledge Bases 的向量存储后端

Amazon Bedrock Knowledge Bases 采用客户托管（非托管）配置时支持三种向量存储后端。关于涵盖六项服务的完整 AWS 向量组合，请参阅 AWS vector solutions: Build agentic AI where your data lives。

Amazon OpenSearch Service 从保存在内存中的数据中提供高速结果。它支持高维向量嵌入，同时提供托管集群和无服务器部署两种选项，并具备 k-NN 搜索以及结合词汇和向量方法的混合搜索等功能。Amazon Bedrock Knowledge Bases 支持 Amazon OpenSearch 托管集群和 Amazon OpenSearch 无服务器作为向量存储后端。

带有 pgvector 的 Amazon Aurora PostgreSQL 将 Amazon Aurora 的高性能关系数据库能力与 pgvector 的向量相似性搜索功能相结合。它支持多种索引方法（IVFFlat 和 HNSW）、多种距离度量（L2、余弦、内积），并可在单精度下处理高达 2000 维的向量。

Amazon S3 Vectors 是 AWS 云对象存储服务，原生支持向量，旨在以经济高效的方式存储和查询大规模向量嵌入。它为相似性搜索提供亚秒级查询性能，同时与传统向量数据库相比可将向量存储成本降低高达 90%。

为了理解这些选项在实践中的表现，我们来审视三个不同的 RAG 使用场景，每个场景都有不同的延迟、成本和搜索需求，并查看哪种向量数据库最适合每个场景。

使用场景 1：产品目录搜索

电子商务平台面临帮助客户在数千种产品中准确找到所需商品的挑战。一个有效的产品搜索工具必须理解自然语言查询，并且能够扩展以处理高峰购物期间数千个并发查询，同时保持低延迟。

为什么 Amazon OpenSearch 最适合此使用场景

Amazon OpenSearch 无服务器非常适合产品目录搜索，因为它支持通过混合搜索功能将语义理解与传统关键词匹配相结合。在处理大型产品目录时，性能至关重要。Amazon OpenSearch 无服务器处理向量搜索的查询延迟处于低毫秒级。

它对电子商务特别有价值的原因在于内置支持复杂过滤和聚合，可实现分面导航（想想按价格、品牌或颜色过滤）。你还可以选择多种距离度量（如余弦相似度或欧几里得距离），根据具体需求微调产品相似度的计算方式。

Amazon OpenSearch 无服务器经典版集合提供了多种优化选项，可在成本和搜索质量之间取得平衡，详见下一节。

注意：Amazon Bedrock Knowledge Bases 同时支持 Amazon OpenSearch 无服务器和托管集群。以下基准测试在无服务器经典版集合上运行。Amazon OpenSearch 无服务器新一代集合（2026 年 5 月全面可用）尚未与 Amazon Bedrock Knowledge Bases Retrieve API 兼容。新一代通过从索引映射中移除引擎和模式参数来简化索引创建，默认使用 32 倍压缩并配备 GPU 加速索引构建，支持缩放至零。本文中 的基准测试使用经典版集合，其中引擎、模式 和 HNSW 参数是显式配置的。托管集群提供额外的调优选项（自动优化、GPU 加速索引、可配置实例大小），可能产生不同结果。

Amazon OpenSearch 无服务器向量搜索的性能分析与优化

Amazon OpenSearch 具有高度可配置性，提供了多种配置选项。在选择这些选项时要小心，因为它们会显著影响向量索引的性能。我们来探讨其中一些针对优化成本和数据库大小的选项，并量化展示它们对向量索引性能的影响。

一些常见的优化选项包括：

向量嵌入的维度大小：较大的向量通常可以包含更多关于嵌入文本的语义信息。但这也导致更高的内存消耗，从而增加向量索引大小和成本。现代嵌入模型（如 Amazon Titan Text Embedding v2）支持以不同维度（Amazon Titan 为 1024、512 或 256）的向量嵌入文本。对不同维度的嵌入进行基准测试，有助于量化衡量性能和成本对特定使用场景的影响。关于各 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的 Supported models by AWS Region。

嵌入的数据类型：我们还可以通过以更低精度数据类型（如二进制嵌入）存储嵌入来减小向量索引大小（从而降低成本）。这可以显著减小向量索引的大小。

磁盘优化存储：Amazon OpenSearch 无服务器经典版集合提供基于磁盘的向量搜索（on_disk 模式），在内部应用 32 倍二进制量化，同时从磁盘重新评分针对全精度向量的结果。这在保持质量的同时减少了内存占用代价，但代价是更高的延迟。请注意，on_disk 需要 float 数据类型，不能与二进制嵌入结合使用。

根据所选的索引算法，用户还可以配置 HNSW 参数（ef_construction、m），以在索引构建时间、内存使用量和搜索准确性之间进行权衡调优（实践指导请参阅 A practical guide to selecting HNSW hyperparameters）。此外，Faiss 16 位标量量化在 Classic 集合上可用，以减少内存使用。选择嵌入维度和技术类型需要根据你自己的相关性数据进行评估，因为这些会改变嵌入空间本身。选择之后，自动优化功能可以在不到一小时内移除剩余的 HNSW 和量化调优工作，它通过对照召回率和延迟阈值评估索引配置（适用于 Amazon OpenSearch Serverless 和使用 Faiss 引擎的托管集群）。

我们使用"购物查询数据集"（ESCI），这是亚马逊提供的一个包含困难搜索查询的大型数据集。该数据集包含 1,215,851 个独特的美国产品（标题、描述、要点和品牌；中位字符数约 1,140 个）和 97,345 个已评判的查询。对于每个查询，数据集提供了分级相关性标签：Exact（3）、Substitute（2）、Complement（1）和 Irrelevant（0）。以下示例展示了一个查询及其相关和不相关的产品。

查询示例：

self-seal envelopes without window

相关产品标题：

BAZIC Security Self Seal Envelope 4 1/8" x 9 1/2" #10, No Window Tint Pattern Mailing Envelopes, Peel & Seal, Office Checks Invoices (30/Pack), 1-Pack

不相关产品标题：

ValBox 200 Count #8 Double Window Envelopes 3 5/8" x 8 11/16" Flip and Seal Double Window Security Check Envelopes- Security Tint Pattern Designed for Home Office Secure Mailing

我们采样了 5,000 个查询（每个查询约 19 个已评判产品，约 17 个相关产品）并为基准测试索引了所有 1,215,851 个产品描述。我们测量了检索质量（NDCG@10）、延迟（并发为 1 和 10 时的 p50/p95/p99）以及索引大小（ANN 内存占用）。

向量索引构建

我们测试了嵌入维度（1024、512、256）和数据类型（float、binary）的所有组合，共六种配置，外加 1024-float 在默认压缩级别 32× 下的 on_disk 模式，与 1024-float 内存基准进行比较（共七种配置）。所有索引都使用 FAISS 和 HNSW（ef_construction=128，m=24），float 嵌入使用 l2 距离，binary 嵌入使用 hamming 距离。请注意，on_disk 模式需要数据类型为 float，并在内部应用自己的二进制量化（32×），对从磁盘读取的全精度向量进行重新评分。因此"1024-dim binary on_disk"不是有效的索引配置。每个索引在集合中单独创建，摄入所有 1.22M 文档，等待延迟稳定后测量，然后删除，并在下一个配置之前冷却 15 分钟。

评估方法

对于每种配置，我们在 Amazon OpenSearch Serverless（Classic 集合）中创建向量索引，摄入所有 1,215,851 个产品，等待合并完成后运行自适应预热直到延迟稳定，然后进行测量。我们在并发为 1 和并发为 10 的条件下测量 1,000 个查询 × 3 次重复。配置顺序采用交叉设计，使数据类型和维度与时间不相关。主基准测试（表 1）使用语义搜索（仅 k-NN）。我们在表 2 中单独评估混合搜索（语义 + 关键词与 BM25）。我们评估：

检索延迟：延迟测量为从 Amazon OpenSearch 结果中报告的向量索引中检索相关匹配项所需的时间。这不包括将文本转换为嵌入的时间。

检索性能：我们使用标准化折扣累积增益（NDCG）指标对每个查询的检索结果进行评分。该指标通过考虑检索文档的相关性及其在排名中的位置来评估排序检索结果的质量。排名较高的相关文档比排名较低的文档对总体分数的贡献更大。分数相对于理想排名进行标准化，落在 0-1 之间，这在产品搜索中尤为重要，因为用户更有可能查看顶部结果。

索引大小：我们报告 ANN（近似最近邻）索引大小，这是驱动搜索计算成本并决定容量需求的内存结构。这与总存储大小不同，总存储大小包括每个文档的 _source JSON 副本，并随文档文本量而变化。

表 1：语义搜索（仅 k-NN）在七种 Amazon OpenSearch Serverless 配置下的性能（1,215,851 个索引向量，5,000 个查询，k=10）。延迟为并发为 1 时的服务端延迟。Delta 相对于 1024-float 内存基准进行配对 bootstrap。混合搜索结果见表 2。

降低维度并不总是减少质量。在这个数据集上，512-float 在统计上与 1024-float 基准无法区分（NDCG 0.3628 vs 0.3627，p = 0.87），但索引大小减半（2.79 vs 5.34 GiB）且延迟更低（25 vs 31 ms p50）。降到 256 维度显示出可测量的 4.4% 质量损失。"无损"和"有损"维度缩减之间的差距取决于嵌入模型和数据集。

二值化提供了大幅索引大小缩减，但质量成本取决于维度数量。在 1024 维度时，二值嵌入将索引大小缩减了 13.4 倍（0.40 vs 5.34 GiB），NDCG 损失 5.2%，延迟相当（22 vs 31 ms p50）。在 256 维度时，质量成本上升到 28.3%，而增量大小节省要小得多（5.0 倍）。在这个数据集上，趋势很明显：二进制惩罚随着维度缩小而增加，这表明在更高维度上降低精度比同时降低精度和维度更有效。

磁盘模式（on_disk 32×）以延迟为代价保持质量。在 1024 维度时，磁盘模式实现了 NDCG 0.3610（相对于基准下降 0.5%），索引大小与 1024-binary 相同（0.40 GiB），但延迟约为内存模式的 3 倍（99 ms p50 vs 31 ms 内存）。1024-binary 和 on_disk 都将索引缩减了 13.4 倍，但磁盘模式保留了明显更多的质量（-0.5% vs -5.2%）。约 3 倍的延迟比率在 p50、p95 和 p99 上保持一致。在小规模语料库上这个惩罚可能不会出现，因为索引适合页面缓存。它在生产规模时才会显现。

混合搜索结果

表 2：1024 维度下的混合搜索对比（1,215,851 个向量，5,000 个查询，k=10）。混合使用归一化处理器，语义/词法权重为 0.7/0.3。

混合搜索比纯语义搜索提供了一致的质量提升。在这个数据集上，混合搜索使 float（NDCG 0.3633 → 0.3850）和 binary（NDCG 0.3451 → 0.3658）的 NDCG 都提升了 +6.0%。特别是，1024-binary 混合搜索（0.3658）超过了 1024-float 纯语义搜索（0.3633），而内存占用仅为 1/13（0.40 vs 5.34 GiB）。这表明开启混合搜索可以抵消二值化的质量成本。

混合搜索会增加延迟。融合步骤大约使顺序延迟翻倍（float 从 30 到 38 ms，binary 从 17 到 35 ms），差距在并发下扩大。

注意：该数据集（产品搜索）有利于关键词匹配：BM25 单独达到了 NDCG 0.314，仅落后语义搜索 13%。在自然语言 RAG 查询上，绝对混合提升可能不同。融合权重（0.7/0.3）是为演示而设置，未经过调优。

用例 2：深度研究智能体

深度研究智能体代表了传统 RAG 系统的重大进化。与标准 RAG 执行单个检索-生成周期不同，深度研究智能体通过动态推理、自适应规划和迭代信息检索来处理复杂的多轮研究任务。这些智能体可以搜索信息、分析发现、根据中间结果调整方法，并在较长时间内综合全面的报告。

深度研究智能体的一个关键特征是它们以更高延迟换取详尽性的容忍度。与用户期望亚秒级响应的实时搜索应用不同，深度研究工作流可能运行数分钟或数小时，使得成本效率和可扩展性比原始查询速度重要得多。

该用例的向量存储层必须能够以最低成本高效处理数千万个嵌入，同时支持定期重新索引的批处理操作、灵活的元数据过滤，以及扩展到数百万向量的弹性扩缩容。

为什么 S3 Vectors 最适合此用例

对于在超大规模 embedding 集合上运行的深度研究智能体，Amazon S3 Vectors 是一个实用且高效的向量存储选项。与传统向量数据库相比，它显著降低了向量存储和查询的成本，使得从大型文档集合中生成的数十亿个 embedding 成为可能。Amazon S3 Vectors 无需基础设施配置即可弹性扩展，支持每个索引数千万个向量和每个存储桶数千个索引，非常适合数据集不断增长的长时运行研究系统。它支持广泛的 embedding 维度，并针对批量摄取和检索进行了优化，能够高效地后台处理大型集合。它与其他 AWS 服务集成，例如 Amazon Bedrock Knowledge Bases（完全托管的 RAG 能力）和 Amazon OpenSearch，使团队能够在需要时将低成本存储与更专业的检索或 RAG 工作流程相结合。其按需付费的定价模式进一步支持具有可变或不可预测使用模式的研究工作负载。

我们使用了英文维基百科的一个子集，包含超过 600 万篇文章。在基准测试中，我们创建了多个规模的向量索引，以评估 Amazon S3 Vectors 在数据集增长时的表现：

每篇维基百科文章使用基于 token 的分块器分割成 300 个 token 的段落。

向量索引构建

我们使用 Amazon Titan Text Embedding v2 构建向量索引，该模型生成 1024 维 float32 embedding。我们的摄取管道使用以下配置：

我们使用从维基百科内容生成的 100 个研究风格问题测量了四个索引规模的查询延迟。每次查询检索前 50 个最相似的向量。延迟测量不包括 embedding 生成时间，以隔离 Amazon S3 Vectors 的性能。

哪些因素会影响政府官员和政策制定者的职业轨迹？

主要发现如下：

亚线性扩展：查询延迟的增长速度远慢于索引规模。从 5K 到 1M 向量（200 倍增长）仅使 p50 延迟增加约 3.5 倍（82ms → 294ms）。这展示了 Amazon S3 Vectors 高效的索引结构。

规模化后尾延迟趋于稳定：p50 → p95 的差距从 5K 向量时的约 100ms 扩大到 250K 时的约 210ms，但随后在 500K 到 1M 之间收窄并稳定在约 100-120ms。这表明一旦索引达到中等规模，最坏情况下的性能变得可预测，添加更多向量不会按比例增加尾延迟。

规模化下亚秒级查询：即使在 100 万个向量时，p99 延迟也保持在 510ms 以下。对于深度研究智能体而言，其在检索到的上下文上花费数秒进行推理，这种检索开销是可以接受的。

图 2：Amazon S3 Vectors 查询延迟（p50、p95、p99）与索引规模（从 5K 到 1M 向量）的关系，展示了亚线性扩展，即使在 1M 向量时中位数查询也在 300ms 以下

与 Amazon OpenSearch 集成以实现混合搜索工作流程

对于需要超越纯向量相似性的高级搜索能力的研究工作负载，Amazon S3 Vectors 通过两种互补模式与 Amazon OpenSearch Service 集成。

第一种模式是将 Amazon S3 Vectors 用作 Amazon OpenSearch 托管集群内的成本高效存储引擎，允许团队在使用 Amazon S3 Vectors 的低存储成本的同时，利用 Amazon OpenSearch 的混合搜索、聚合和复杂过滤能力。

第二种模式支持将 S3 向量索引一次性导出到 Amazon OpenSearch Serverless 集合，当数据的特定子集需要高查询吞吐量或实时应用的亚 100ms 延迟时。通过这种分层方法，研究团队可以在 Amazon S3 Vectors 中以低成本存储完整语料库，同时将有高优先级的向量选择性提升到 Amazon OpenSearch 以处理性能关键型查询。两种集成都保留向量维度和元数据，支持随着研究需求的发展在存储层之间平滑过渡。

用例 3：面向客户的 RAG 聊天机器人

面向客户的聊天机器人已成为企业为用户提供即时、个性化支持的重要工具。当由 RAG 驱动时，这些聊天机器人可以通过基于可信知识来源的答案来提供准确、上下文相关的响应。然而，源数据类型的多样性以及用户表述问题方式的差异意味着，能够调整 RAG 查询以找到符合客户期望的结果非常重要。

面向客户聊天机器人的一个典型用例是根据内部知识库的内容回答客户问题。知识库会随着时间和客户查询以及构建或更改内部系统的项目而积累。它们可能包含客户问题的答案，但并不总是包含与问题中术语相匹配的关键词或直接引用。知识库检索系统的需求包括：

能够从间接问题中找到源材料。

快速提供答案。

可扩展以包含大型知识库。

为什么 Aurora 最适合此大型知识库用例

对于具有大型知识库的面向客户 RAG 聊天机器人，Amazon Aurora PostgreSQL 与 pgvector 平衡了 S3 和 Amazon OpenSearch 的容量和性能，并提供了更改索引方法以针对任何给定数据集优化检索的能力。

Amazon Aurora Serverless 也可用于开发环境等用例，在这些场景中自动数据库扩展具有成本或性能优势。

Aurora PostgreSQL 的性能分析和优化

PostgreSQL 为向量搜索提供多种索引算法，包括 HNSW 和 IVFFlat。HNSW（层次可导航小世界）构建多层图以实现快速近似最近邻搜索，以更高的内存使用和更慢的索引构建为代价提供更快的查询时间。IVFFlat（带 Flat 压缩的倒排文件）将向量分区为聚类以进行高效搜索，使用更少的内存但需要随着数据变化定期重建索引。有关这些算法的详细比较，请参阅使用 pgvector 索引优化生成式 AI 应用：IVFFlat 和 HNSW 技术深入探讨。在相同数据集上 A/B 测试不同索引的能力帮助团队针对其特定用例优化检索性能。关键优化因素包括：

数据库配置：实例大小和预热考虑。

索引选择：不同查询模式下 HNSW 与 IVFFlat 的权衡。

索引参数：每种算法类型的配置选项。

Amazon Relational Database Service（RDS）提供各种实例大小和部署选项，例如多可用区和无服务器操作。这有助于使用云开发和运营团队熟悉的技能来调整数据库的成本和性能。快速调整的能力