构建 Agentic AI 应用时，向量搜索并不一定意味着新增一个独立的向量数据库。AWS 提供了一组直接集成到现有数据库和存储服务中的向量能力，团队可以继续使用已经承载业务数据的服务，减少数据迁移、同步链路和额外运维。
这类架构的关键问题不是“哪个向量数据库最强”，而是“向量搜索应该放在哪里，才能最贴近数据、权限和访问模式”。
向量搜索为什么应该靠近业务数据
传统 RAG 架构通常会把文档或业务记录复制到独立的向量数据库，再通过 embedding 完成语义检索。这个方案可以工作，但也会带来几项长期成本：
- 原始数据与向量索引需要持续同步。
- 权限、租户隔离和删除操作需要在两套系统中保持一致。
- 查询结果还要回到业务数据库中补齐字段。
- 团队需要额外学习和维护一套存储服务。
AWS 的向量方案将搜索能力放进已有的数据服务中。这样，Agent 可以在同一数据边界内完成语义检索、过滤和上下文组装。对于已经使用关系数据库、文档数据库、图数据库、键值存储、搜索引擎或对象存储的团队，这种方式尤其适合渐进式接入。
需要注意的是，“不迁移数据”并不代表不需要设计索引。embedding 模型、向量维度、距离度量、元数据过滤、更新策略和权限边界仍然需要明确。
六类服务，六种数据形态
可以把 AWS 的向量能力按数据模型和检索目标来理解，而不是只看向量查询接口。
关系数据：Aurora PostgreSQL 与 RDS for PostgreSQL
如果产品数据、权限关系和业务过滤条件已经位于 PostgreSQL 中，可以直接在关系数据库里保存 embedding，并使用 pgvector 完成相似度检索。
这种方式适合：
- 检索结果必须和事务数据保持一致。
- 查询同时包含结构化条件和语义相似度。
- 应用已经依赖 SQL、事务和 PostgreSQL 权限模型。
例如，客服 Agent 可以先按租户和产品线过滤，再从知识条目中找出语义最相近的内容。向量检索只是 SQL 查询的一部分，而不是单独的上下文服务。
搜索数据：Amazon OpenSearch Service
当应用需要全文搜索、向量搜索、过滤、聚合和搜索相关性调优时，OpenSearch 更适合承担检索层角色。它尤其适合文档搜索、日志分析、企业知识库和需要混合检索的场景。
可以把关键词匹配、语义匹配和业务过滤组合在同一个搜索流程中，再将结果交给 Agent 生成答案。代价是需要认真规划索引映射、分片、刷新策略和集群容量。
图数据：Amazon Neptune
如果问题的核心是实体之间的关系，例如“某个客户关联了哪些合同、产品、供应商和风险事件”，图数据库比单纯的近邻搜索更自然。向量可以帮助发现语义相似的实体或文本，但图遍历负责解释关系和路径。
适合将向量检索与关系推理结合起来的 Agent 场景包括知识图谱问答、供应链分析、身份关系分析和故障根因探索。
文档数据：Amazon DocumentDB
对已经以 JSON 文档形式存储产品目录、内容条目或用户资料的应用，DocumentDB 可以让向量字段和文档元数据留在相同的数据模型中。
这能减少从文档数据库导出数据、转换格式并同步到独立向量系统的工作，但仍需评估向量索引规模、写入频率和查询延迟是否符合业务目标。
低延迟键值数据：Amazon MemoryDB
对于需要极低访问延迟的个性化推荐、会话记忆和实时 Agent 上下文，MemoryDB 可以作为靠近在线请求路径的向量存储选择。
它更适合已经把热点状态放在内存型键值服务中的系统。团队需要关注内存成本、数据生命周期和持久化需求，避免把长期、低访问频率的大型知识库全部放进高成本的在线缓存层。
对象存储数据：Amazon S3 Vectors
如果数据规模很大、访问模式偏批处理或成本敏感，S3 Vectors 可以作为面向对象存储数据的向量检索方案。它适合文档归档、历史内容、海量素材和不需要每次请求都访问的知识集合。
这类方案通常更关注存储成本、索引更新周期和查询吞吐，而不是把所有数据都放在低延迟数据库中。在线 Agent 可以将高频数据与低频数据分层处理。
一个可改造的 PostgreSQL 示例
下面的示例假设你使用 Aurora PostgreSQL 或 RDS for PostgreSQL，并且实例已安装 pgvector 扩展。示例使用 3 维向量只是为了便于演示，生产环境应替换为实际 embedding 模型产生的维度。
先创建表和向量索引：
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE IF NOT EXISTS knowledge_items (
id BIGSERIAL PRIMARY KEY,
tenant_id TEXT NOT NULL,
title TEXT NOT NULL,
content TEXT NOT NULL,
embedding vector(3) NOT NULL,
metadata JSONB NOT NULL DEFAULT '{}'::jsonb,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX IF NOT EXISTS knowledge_items_tenant_idx
ON knowledge_items (tenant_id);
CREATE INDEX IF NOT EXISTS knowledge_items_embedding_idx
ON knowledge_items
USING hnsw (embedding vector_cosine_ops);
插入几条示例数据，并执行带租户过滤的相似度查询：
INSERT INTO knowledge_items
(tenant_id, title, content, embedding, metadata)
VALUES
('acme', '退款政策', '标准商品支持签收后七天内申请退款。', '[0.91, 0.12, 0.08]', '{"product":"support"}'),
('acme', '发票说明', '企业客户可以在订单完成后申请电子发票。', '[0.18, 0.88, 0.16]', '{"product":"billing"}'),
('other-tenant', '退款政策', '这是另一个租户的内容。', '[0.90, 0.11, 0.07]', '{"product":"support"}')
ON CONFLICT DO NOTHING;
SELECT id, title, content, metadata,
1 - (embedding <=> '[0.89, 0.15, 0.10]') AS similarity
FROM knowledge_items
WHERE tenant_id = 'acme'
ORDER BY embedding <=> '[0.89, 0.15, 0.10]'
LIMIT 5;
运行前需要将连接信息替换为实际数据库地址，并根据业务 embedding 模型调整 vector(3) 和查询向量的维度。生产系统还应在 SQL 层保留租户、地域、数据分类和权限过滤，不能只依赖 Agent 的提示词来限制数据范围。
如何选择合适的引擎
可以用下面四个问题快速缩小范围：
- 原始数据当前在哪里？ 如果主要数据已经在 PostgreSQL、文档数据库或对象存储中，优先评估同一服务内的向量能力。
- 查询是纯语义搜索，还是混合检索？ 需要全文搜索、聚合和相关性调优时，OpenSearch 更自然；需要事务和复杂 SQL 过滤时，关系数据库更直接。
- 数据之间的关系是否比相似度更重要？ 如果答案依赖实体关系和多跳路径，应评估 Neptune，而不是只增加向量维度。
- 请求延迟、数据规模和成本哪个最敏感？ 实时会话记忆偏向低延迟存储；海量历史数据则应考虑对象存储和分层架构。
此外，应该用真实查询集测试召回率、延迟、索引构建时间、更新延迟和每月成本。客户案例或服务证明点可以帮助验证方向，但不能替代针对自身数据分布和权限模型的压测。
落地时需要提前确认的边界
向量搜索解决的是“找到语义上相关的数据”，并不会自动解决答案可信度、权限控制和数据新鲜度问题。上线 Agent 前，至少确认以下事项：
- embedding 模型升级时如何重建索引。
- 原始数据删除后，向量和元数据多久失效。
- 检索结果如何执行租户和用户级权限过滤。
- 是否需要关键词搜索、结构化过滤或图遍历的组合。
- 低延迟和低成本之间如何分层。
- 生产查询是否包含足够的可观测信息，例如索引版本、过滤条件和召回结果。
AWS 这套思路的价值在于让向量能力贴近已有数据，而不是要求每个团队从零搭建另一套数据平台。最稳妥的采用路径通常是从一个已有数据边界清晰的 Agent 场景开始，使用真实业务查询验证效果，再决定是否需要混合多个引擎或建立专门的检索层。