AWS发文对比Amazon Bedrock知识库三种向量存储后端
AWS机器学习博客发布选型指南，对比Amazon OpenSearch Service、Aurora PostgreSQL with pgvector和S3 Vectors在三种RAG场景下的表现，并给出产品目录搜索的量化基准。
AI解读：Amazon Bedrock知识库支持自带向量存储，有OpenSearch、Aurora PostgreSQL with pgvector和S3 Vectors三种后端可选，本文关注后一种“客户管理”路径。选型影响的不是功能有无，而是同样做检索增强生成时，延迟、成本和搜索质量之间的实际取舍。
对电商产品目录搜索这类并发高、要求低延迟的场景，文章给出的基准数据比较有说服力：在约 122 万商品描述上，1024 维float和 512 维float的NDCG几乎相同，但 512 维索引只有 2.79 GiB，远小于 1024 维的 5.34 GiB，p50延迟也从 31 毫秒降到 25 毫秒。换句话说，减维度有时不牺牲质量，但降到 256 维就有了约 4.4% 的损失。
二进制嵌入能大幅压缩索引：1024 维二进制把索引从 5.34 GiB压到 0.40 GiB，代价是NDCG损失 5.2%。有意思的是，开启混合搜索后，1024 维二进制的NDCG反超仅语义搜索的 1024 维float，同时内存只有后者的约十三分之一。不过混合搜索会增加延迟，需要看具体负载能不能接受。
如果延迟不敏感，on_disk模式用约 3 倍延迟换来几乎无损的质量；如果面对的是深度研究这类动辄跑几分钟甚至几小时的任务，文章推荐S3 Vectors，因其存储成本可降最多 90%，更看重批量重索引和成本效率而非单次响应速度。
这些数字来自Shopping Queries数据集上的OpenSearch Serverless Classic集合，且使用FAISS HNSW参数，不代表所有模型和数据集上的必然结果；Classic和NextGen集合的兼容性也有明确说明。选型最终还得在自己的数据上验证。
AWS机器学习博客发布一篇选型指南，对比Amazon Bedrock知识库在客户自管配置下支持的三种向量存储后端：Amazon OpenSearch Service、Amazon Aurora PostgreSQL with pgvector和Amazon S3 Vectors，并给出三种检索增强生成（RAG）用例下的匹配建议。文章由Deepak Dalakoti撰写，聚焦客户自管路径，不涉及完全托管选项。
Amazon Bedrock知识库的客户自管配置支持这三个后端。OpenSearch提供内存高速查询，支持k-NN搜索和混合搜索，有托管集群与Serverless两种部署形式；Aurora PostgreSQL with pgvector结合关系数据库与向量相似度搜索，支持IVFFlat、HNSW索引和L2、余弦、内积等距离度量，单精度向量最高支持 2000 维；S3 Vectors为S3对象存储加入原生向量支持，面向大规模向量的低成本存储与查询，相似度搜索提供亚秒级查询性能，存储成本较传统向量数据库最多降低 90%。
产品目录搜索：在 122 万商品上测OpenSearch各配置
文章用第一个用例——电商产品目录搜索——量化不同OpenSearch Serverless配置的表现。数据集使用亚马逊的Shopping Queries Data Set（ESCI），包含 1,215,851 个美国商品（标题、描述、要点和品牌，文本中位数约 1,140 字符）和 97,345 条已标注查询，相关性分为Exact（3）、Substitute（2）、Complement（1）和Irrelevant（0）。基准抽取 5,000 条查询，每条约 19 个已标注商品（其中约 17 个相关），对所有 1,215,851 条商品描述建立索引，测量NDCG@10、延迟（并发 1 和 10 下的p50/p95/p99）和索引大小。
测试覆盖嵌入维度 1024、512、256 与数据类型float、binary的全部组合，共六种配置，外加 1024 维float的on_disk模式（默认 32 倍压缩），与 1024 维float内存基线共七种。所有索引使用FAISS和HNSW（ef_construction=128，m=24），float嵌入用L2距离，二进制用汉明距离。每个配置单独建索引、导入全部 122 万文档、预热至延迟稳定后测量，删除后冷却 15 分钟再测下一个。
结果显示，降低维度并不总牺牲质量：在数据集上，512 维float与 1024 维float基线统计上无差别（NDCG 0.3628对 0.3627，p=0.87），索引大小减半（2.79 GiB对 5.34 GiB），p50延迟更低（25 毫秒对 31 毫秒）。降到 256 维则出现可测量的 4.4% 质量损失（NDCG 0.3468）。
二值化能大幅压缩索引，但质量代价取决于维度数。1024 维二进制将索引缩小 13.4 倍（0.40 GiB对 5.34 GiB），NDCG损失 5.2%，延迟相当（p50 22毫秒对 31 毫秒）。256 维二进制质量损失升至 28.3%，而额外索引节省只有 5.0 倍。文章指出，在这个数据集上，二进制惩罚随维度下降而增大，建议降低精度而非同时降精度和维度。
磁盘模式（on_disk 32倍）以延迟换质量保留：1024 维下NDCG 0.3610（较基线损失 0.5%），索引大小与 1024 维二进制相同（0.40 GiB），但p50延迟约 3 倍（99 毫秒对 31 毫秒内存）。该 3 倍延迟比在p50、p95、p99上一致。文章提醒，小语料下索引可能完全驻留页面缓存，这个代价可能不出现，只有在生产规模才会显现。
- 测试使用Amazon OpenSearch Serverless Classic集合，原文注明NextGen集合（预计 2026 年 5 月一般可用）尚不兼容Amazon Bedrock知识库Retrieve API。NextGen简化索引创建，移除engine和mode参数，默认 32 倍压缩和GPU加速索引构建，并支持缩零。
- 嵌入大小和类型的变化会改变嵌入空间本身，文章建议用自身相关性数据评估后再选，并可用auto-optimize在一小时内自动移除剩余HNSW和量化调参，适用于Faiss引擎的Serverless和托管集群。
- on_disk模式要求float数据类型，不能与二进制嵌入组合；1024 维二进制on_disk并非有效配置。
混合搜索：1024 维二进制加混合可超过float仅语义
文章另做了 1024 维下的混合搜索对比，使用normalization-processor，语义权重 0.7、关键词权重 0.3。混合搜索对float和二进制都带来一致的质量提升：float从 0.3633 升到 0.3850（提升 6.0%），二进制从 0.3451 升到 0.3658（同样提升 6.0%）。
值得注意的组合是：1024 维二进制配合混合搜索NDCG达到 0.3658，超过 1024 维float仅语义搜索的 0.3633，而内存占用仅 0.40 GiB，约为后者的十三分之一。文章解读，开启混合搜索可以抵消二值化带来的质量损失。
但混合搜索会增加延迟。融合步骤大致让顺序延迟翻倍：float从 30 毫秒到 38 毫秒，二进制从 17 毫秒到 35 毫秒，并发下差距进一步扩大。文章提醒，这个产品搜索数据集本身偏向关键词匹配：BM25单独达到NDCG 0.314，仅落后语义搜索 13 个百分点。在自然语言RAG查询上，绝对混合提升可能不同，且 0.7/0.3 的融合权重是为演示设置，并非调优结果。
- 关键词BM25单独在float上NDCG 0.3141、延迟 11 毫秒，在二进制上 0.3177、17 毫秒。
- 语义k-NN在float上 0.3633、30 毫秒，在二进制上 0.3451、17 毫秒。
- 混合搜索在float上 0.3850、38 毫秒，在二进制上 0.3658、35 毫秒。
深度研究代理与其余用例的选型逻辑
第二个用例是深度研究代理，这类系统不再只做单轮检索生成，而是通过动态推理、自适应规划和迭代检索完成复杂多轮研究任务，可能运行数分钟到数小时。文章认为，这类工作流对延迟容忍度高，更看重成本效率和可扩展性，向量存储层需要以低成本高效处理数千万嵌入，支持周期性重建索引的批量操作、灵活的元数据过滤和弹性扩展。
文章由此推荐Amazon S3 Vectors作为深度研究代理的向量存储选项，理由是它显著降低存储和查询向量的成本，使处理由大量文档衍生的数十亿嵌入变得可行。该文摘要仅覆盖摘要中提及的三种用例对比，第三个用例的详细基准数据在提供的来源摘要中未完整展开。