利用DynamoDB和Bedrock构建统一AI代理架构
内容提要
本文介绍如何利用DynamoDB原生向量搜索与Bedrock构建统一AI代理架构。该方案将操作数据与向量嵌入存储在同一DynamoDB表中，通过Lambda调用SearchVectors实现语义搜索，并利用DynamoDB Streams自动生成嵌入，避免单独向量数据库，降低基础设施成本与同步复杂性，适用于频繁更新且需实时搜索的文档管理场景。
延伸解读
架构选择考量
该方案并非适用于所有场景。文章明确指出，当数据存储在S3、需要托管分块或高级搜索功能（如范围过滤、聚合）时，应选择Bedrock Knowledge Bases或OpenSearch。此架构最适合已使用DynamoDB且需要实时语义搜索的频繁更新文档场景，可避免引入额外数据库带来的运维负担。
关键限制与注意事项
DynamoDB向量搜索存在若干限制：仅支持按需容量模式，每个表最多5个向量索引，SearchVectors响应限制16MB且不支持分页，TopK上限100。此外，搜索条件仅支持等值过滤，且缺少细粒度访问控制。多租户场景需通过分区键隔离或使用独立表，设计时需评估这些约束是否满足业务需求。
避免无限循环的关键
自动生成嵌入的管道依赖DynamoDB Streams，但必须启用NEW_AND_OLD_IMAGES视图并实现内容变更检查，否则Lambda写回嵌入会再次触发流，导致无限循环。生产环境还应配置批量失败报告和死信队列，以处理失败记录并保证管道可靠性。
Q&A
如何利用DynamoDB和Bedrock构建统一的AI代理架构？
该架构将操作数据和向量嵌入存储在同一DynamoDB表中，通过Bedrock代理调用Lambda动作组，使用SearchVectors API进行语义搜索，并通过DynamoDB Streams自动生成嵌入，从而避免单独向量数据库，降低基础设施成本和同步复杂性。
DynamoDB原生向量搜索相比单独向量数据库有什么优势？
优势包括：减少基础设施成本（无需单独向量数据库）、降低同步复杂性（数据存储在同一表中）、减少陈旧检索结果的风险，并简化代理请求路由。
如何创建DynamoDB表的向量索引？
使用AWS CLI命令update-table，指定向量索引名称、向量属性（如embedding）、维度（如1024）、距离函数（如COSINE）和搜索模式（如category作为HASH键）。创建后需等待索引状态变为ACTIVE且Backfilling为false。
DynamoDB向量搜索有哪些限制？
限制包括：仅支持按需容量模式；每表最多5个向量索引，每个索引最多4096维；SearchSchema的HASH属性在搜索条件中必填；仅支持等值过滤；SearchVectors响应限制为16MB且不支持分页；缺少HASH属性的项目会被静默排除在索引外。
如何防止DynamoDB Streams触发无限循环？
在嵌入生成Lambda中，检查旧镜像和新镜像的content字段是否相同，如果相同则跳过处理。这需要启用StreamViewType为NEW_AND_OLD_IMAGES，以便Lambda能访问旧镜像。
在什么情况下应该使用Amazon Bedrock Knowledge Bases而不是这个模式？
当源数据存储在Amazon S3中，需要托管的分块和摄取，或者不需要与操作写入实时同步的索引更新时，应使用Bedrock Knowledge Bases。
如何确保SearchVectors API的访问安全？
使用最小权限IAM策略，将dynamodb:SearchVectors权限限定到特定索引ARN；对于多租户工作负载，使用SearchSchema HASH分区键按租户隔离；加密静态数据和传输数据；限制Bedrock模型访问权限；为代理到Lambda的调用添加资源策略。
