AWS 在 Amazon Bedrock 推出合同智能搜索方案 AIDA

AWS 在官方机器学习博客中介绍了一套名为 AIDA（AI-Driven Annotation）的合同智能检索方案，该方案构建于 Amazon Bedrock Knowledge Bases 之上，面向娱乐、媒体等需要管理大量跨区域合同的企业，旨在将非结构化的法律协议转化为可搜索、可执行的知识资产。

方案背景与核心思路

企业在处理合同条款时，长期依赖人工检索权利、续约、地理限制与合规义务等关键信息，效率低且难以规模化。AIDA 通过自然语言问答覆盖大型合同库，但仅靠语义搜索并不能保证准确率——法律文本高度依赖上下文，RAG 系统往往返回过多片段，超出大模型的有效处理范围，容易遗漏或误读关键条款。

为此，AIDA 在标准 RAG 流程中引入两项关键机制：隐式过滤（基于元数据自动收缩检索范围）与显式过滤（用户或业务规则指定条件），并通过元数据增强的分块策略，为每个片段保留足够的合同上下文。

数据接入与存储架构

AIDA 的数据接入流程可拆解为三个步骤：

• 文档摄取与元数据配置：合同同步至 Amazon Bedrock Knowledge Bases 时，需附带结构化元数据文件，包含合同方、生效日、终止日、司法管辖区等关键属性，供下游过滤使用。
• 分块机制实现：分块策略将合同拆分为语义完整的段落，既保证上下文充分，又控制单段长度以利于检索。元数据在此阶段决定了系统能否执行隐式过滤。
• 向量数据库存储：分块经嵌入模型转换为向量后，存入 Amazon OpenSearch Service 或 Amazon S3 Vectors，两者均启用静态加密。访问与模型调用受 IAM 策略约束，并由 CloudWatch 记录审计日志，满足合规要求。

用户查询与过滤机制

用户提交查询后，AIDA 先经 Bedrock Guardrails 防护潜在提示注入与数据泄露，再将查询转为向量嵌入，进入增强的 RAG 流程：

• 隐式与显式过滤：在执行向量检索之前，系统先根据元数据条件（如生效日期范围、合同方）自动收缩候选集，再在过滤后的子集内进行语义相似度匹配。这种「先过滤、再检索」的两阶段方式兼顾了上下文相关性与业务精确性。
• 语义检索与文档获取：向量数据库通常使用余弦相似度在过滤子集内召回最相关的合同片段。
• 提示增强与生成：检索片段与原始问题、元数据上下文被组合为增强提示，输入大模型生成有据可查的回答。

安全与权限

AIDA 在应用层通过 IAM 角色实现项目级的访问控制，限制不同用户对知识库与模型调用的权限。配合 Guardrails 与 CloudWatch 审计，可在合同这一敏感场景下兼顾检索效率与数据安全。

整体来看，AIDA 并非新模型发布，而是 AWS 在 Bedrock 平台上对法律合同场景的一次解决方案级整合，其核心价值在于把元数据过滤、分块策略与 RAG 检索串联成可落地的参考架构，供企业客户在自有合同库中复用。