AWS 发布向量检索全景：在数据原地为 Agentic AI 搭建检索层

AWS 近日在其机器学习博客上发布了一篇系统性介绍，阐述如何在企业现有数据存储中为 Agentic AI 构建向量检索层。其核心观点是：向量能力应当「跟着数据走」，而不是把数据搬到新数据库里。AWS 同时给出了针对新工作负载的六大向量方案选型决策树。

为什么向量检索对 Agentic AI 至关重要

智能体（agent）需要规划、推理并执行多步工作流，离不开对企业内部知识的快速、相关访问。向量作为 AI 的通用语言，能够把文本、图像、音频、视频等不同模态的数据映射到同一高维数学空间，从而支撑跨模态的语义检索。

向量检索与前沿大模型结合后，可支撑以下典型场景：

• RAG 与知识库：在推理时检索可信数据，减少幻觉并使回答与组织知识对齐。
• 语义搜索：基于含义和意图而非关键词匹配来检索信息。
• 混合搜索：将关键词检索与语义搜索结合，覆盖结构化与非结构化数据。
• GraphRAG：将语义搜索与知识图谱结合，提供可追溯的多步推理能力。
• 知识图谱：通过显式关系连接人、产品、文档等实体。

在应用层面，向量检索还广泛用于实时推荐、异常与欺诈检测、多模态内容发现等场景。

第一原则：在数据原地添加向量能力

AWS 把「不引入新数据库」作为整个方案的指导原则。只要数据已经存在于某个 AWS 数据存储中，就在该存储内添加向量检索能力。其好处包括：

• 沿用既有的扩展性、可用性与性能保障；
• 无需学习新的编程接口与 SDK；
• 避免跨服务数据同步与迁移；
• 应用运行更快，且可复用既有投资。

目前已在以下服务中原生支持向量能力：

• Amazon OpenSearch Service
• Amazon S3
• Amazon Aurora PostgreSQL
• Amazon DynamoDB
• Amazon ElastiCache for Valkey
• Amazon Neptune

对于新工作负载，AWS 建议先识别主要诉求（延迟、成本还是访问模式），再选择对应引擎；在需要兼顾搜索、规模与智能体集成的场景中，默认推荐 Amazon OpenSearch Service，因为它在一个系统内同时支持词法、向量、混合与智能体搜索，并具备高吞吐、低延迟与可扩展的相关性排序能力。

Amazon OpenSearch Service：新工作负载的默认选项

OpenSearch Service 作为托管检索引擎，支持多种索引策略、向量量化与元数据过滤，可覆盖从简单 RAG 到多信号检索的各类需求。其内置的机器学习自动优化能力可自动选择配置，减少人工调参成本。

选型思路小结

• 现有数据存储：直接在 Aurora PostgreSQL、DynamoDB、OpenSearch、Neptune、ElastiCache 或 S3 中启用向量能力，无需迁移。
• 新工作负载：根据延迟、成本与访问模式在六个专用方案间选择，OpenSearch 是综合场景的默认推荐。

整体来看，这篇博客更偏向 AWS 对其向量能力全景的官方梳理与选型指南，而非新产品发布。对正在评估向量数据库或构建智能体应用的开发者，可作为 AWS 生态内的参考地图。