利用自动生成的过滤器提高 Amazon Bedrock 中的合同搜索准确率

企业依赖大量复杂的法律协议来做出关键业务决策——确定权利、续约选项、地域限制和合规义务。在娱乐和媒体等行业中，组织需要管理跨多个司法管辖区的数千份合同，这项工作在很大程度上仍依赖人工完成：耗时、成本高昂，且难以规模化扩展。

我们基于 AWS 构建的 AI-Driven Annotation（AIDA）解决方案通过将非结构化合同转化为可搜索、可操作的情报，帮助应对这一挑战。AIDA 使用户能够跨大型合同库提出自然语言问题——但要提供精确答案，仅靠语义搜索是不够的。法律文件具有高度上下文相关性，基于检索增强生成（RAG）的系统可能检索出超出语言模型有效处理能力的内容。如果不对检索到的片段进行精细控制，且缺乏足够的文档级上下文，重要条款就有可能被遗漏或误解。

在本文中，我们介绍 AIDA 的高层工作原理，以及它如何帮助应对这些挑战——让用户在正确的合同、正确的法律上下文和正确的访问边界内获得可靠依据。具体来说，我们探讨 AIDA 如何利用隐式和显式过滤，结合 Amazon Bedrock Knowledge Bases 中元数据增强的分块机制，大幅提升合同搜索的准确性。

解决方案概述


参考架构图展示了 AIDA 如何利用基于 Amazon Bedrock Knowledge Bases 构建的 RAG 架构，创建智能文档查询系统。组件之间的数据传输使用 HTTPS/TLS 1.2+ 进行传输加密，包括向 Amazon Bedrock Knowledge Bases 上传文档、调用嵌入模型的 API 请求、向量数据库查询以及向客户端应用传递响应。对于存储在 Amazon Bedrock 中的数据，适用 AWS 共享责任模型。该实现遵循系统化的工作流程：

数据摄取流程

该架构从文档摄取开始，合同与结构化元数据文件一起同步到 Amazon Bedrock Knowledge Bases。元数据应包含关键合同属性，如当事方、生效日期、终止日期、司法管辖区以及其他关键属性，这些属性可在下游实现强大的过滤能力。

知识库配置阶段实现了精细的分块机制，将合同拆分为语义上有意义的片段，并针对检索进行优化。这种分块策略有助于为每个片段提供足够的上下文，同时保持足够简洁以支持高效处理。摄取期间提供的元数据在系统实现智能过滤的能力中发挥着关键作用，尤其是通过隐式过滤机制——这正是该架构区别于标准 RAG 实现的关键所在。

第 3 步：向量数据库存储

文档完成摄取和处理后，系统将文档块转换为向量嵌入，并将其存储在 Amazon Bedrock Knowledge Bases 提供的多种向量数据库选项之一中，例如 Amazon OpenSearch Service 或 Amazon S3 Vectors（Amazon Simple Storage Service（Amazon S3）的一项功能），两者都应启用静态加密配置。该向量数据库作为语义搜索的基础，使系统能够查找概念上相似的内容，而非仅依赖关键词匹配。

对知识库和模型调用的访问通过 AWS Identity and Access Management（IAM）策略进行管控，并启用 Amazon CloudWatch 日志记录以维护合规审计追踪。

在安全方面，AIDA 使用基于角色的访问控制，通过 AIDA 应用层中的项目范围角色，利用 AWS IAM 策略强制执行，从而限制每个用户可执行的操作。

用户交互流程

第 4 步：查询嵌入生成

当用户提交查询时，AIDA 使用 Amazon Bedrock Guardrails 帮助防范提示注入和数据泄露，随后系统遵循增强的 RAG 工作流程，首先使用 Amazon Bedrock 的嵌入模型将查询转换为嵌入向量。这一转换使得用户问题与存储的文档块之间能够进行语义比较。

第 5 步：隐式和显式过滤

在执行语义搜索之前，系统会同时应用隐式和显式过滤机制——这是一项显著提升检索准确率的关键创新。隐式过滤会在执行向量搜索之前自动应用基于元数据的条件，例如按生效日期范围或特定签约方进行过滤。这种两阶段方法首先通过元数据约束缩小搜索空间，然后在该过滤后的子集内进行语义相似度匹配，从而确保检索到的文档既具有上下文相关性，又满足特定的业务标准。

向量数据库基于语义相似度分数检索最相关的文档片段，通常使用余弦相似度指标来识别与用户查询最接近的匹配项。这种语义搜索在过滤后的文档子集上运行，为结果提供了高精度和高相关性。

步骤7：提示词增强

检索到的片段随后被用于增强用户的原始查询，形成一个精心格式化的提示词，将用户的问题与相关的合同摘录和元数据上下文相结合。这个增强后的提示词为大型语言模型（LLM）提供了生成精确、有依据的回复所需的特定信息。

步骤8：LLM回复生成

增强后的提示词通过Amazon Bedrock传递给LLM，后者基于实际合同文档生成上下文精确的回复，而非仅依赖模型自身的训练数据。这种方法有助于提供反映组织合同具体内容的回复。

此外，AIDA使用Amazon Bedrock Guardrails应用内容过滤、敏感信息（PII）保护和提示词安全控制，以确保回复的安全性并符合企业及法律标准。

最终回复通过Retrieve API返回给用户，确保答案不仅相关，而且可以追溯到具体的源文档。这种可追溯性减少了幻觉——这是LLM常见的挑战——并提供了可验证的合同智能，用户可以在关键业务决策中信赖这些信息。

调优RAG

在为法律合同分析开发RAG系统时，核心挑战之一是管理潜在相关信息的数量。考虑以下问题：

“请识别任何已过期且受加州法律管辖的许可协议？这些协议如何续签？”

这样的查询可能会匹配多个文档中数百个相关的文本片段。在RAG术语中，这些摘录通常被称为候选片段。

当Amazon Bedrock执行语义搜索以查找相关文档摘录时，其设计目标是返回前k个（最多100个）相关候选片段。被过滤掉的其余候选片段可能包含关键上下文。因此，LLM的回复可能不完整、遗漏关键见解，甚至不准确。

法律文档高度结构化且深度依赖上下文。在我们的示例中，加州许可协议中的续签条款可能与其他司法管辖区管辖的许可协议中的续签条款运作方式不同。如果检索步骤未能正确过滤许可协议和加州管辖法律，系统可能会返回不相关的合同，如服务协议、保密协议或受其他州法律管辖的协议。即使这些文档包含到期或续签措辞，它们也无法回答原始问题。有效的元数据过滤变得至关重要，可以将候选池缩小到最相关的子集。这使得后续的LLM调用能够获得所需的上下文，从而提供更精确和完整的答案。

需要特别注意的是，尽管这些检索改进显著提升了准确性，但AI生成的合同解释在用于业务决策之前，始终应由合格的法律专业人士进行审查。AIDA被设计为一种决策支持工具，旨在增强法律专业知识而非取代它。

辅助调优RAG的两种方式是隐式过滤和显式过滤，我们接下来将分别讨论。

隐式过滤

隐式过滤是Amazon Bedrock知识库中的一项强大功能，它允许你基于元数据属性自动过滤搜索结果，而无需在每个查询中编写显式过滤表达式。这种方法使系统能够在执行语义搜索之前，基于文档元数据对向量存储进行预过滤，从而将搜索空间显著缩小到最相关的文档。

阶段1：元数据预过滤

在执行语义相似度搜索之前，系统会自动应用基于元数据的条件。您可以为知识库中的每个文档提供自定义元数据文件（每个文档最多 10 KB），其中包含生效日期、文档类型、相关方或与您的用例相关的自定义字段等属性。

第 2 阶段：语义搜索

通过元数据过滤器缩小文档集范围后，系统仅在此过滤后的子集内执行向量相似度搜索。这有助于减少噪声和不相关信息，同时提高检索准确性。

显式过滤

显式过滤在应用层一致地应用，独立于用户输入。这种方法有助于提供与业务策略、合规要求和组织约束保持一致的搜索结果，而不是完全交由检索引擎自行解读。因此，显式过滤器可以充当安全屏障，帮助确保每个查询都遵守关键边界。

• 应用层约束 – 根据预定义的系统规则限制检索结果，例如地理限制 – 旨在限制特定区域的用户只能访问符合当地法规的文档（例如，欧洲用户只能访问欧盟合同）。
• 时间约束 – 仅返回特定时间范围内的文档（例如，过去两年内有效的合同）。
• 分类和敏感性 – 将搜索结果限制为仅包含具有所需保密或分类级别标签的文档。

{
  "andAll": [
    { "listContains": { "key": "region", "value": "Germany" } },
    { "stringEquals": { "key": "confidentiality_level", "value": "Public" } }
  ]
}

超越过滤：用元数据值丰富分块内容

虽然隐式和显式过滤缩小了候选分块的范围，但它们并不会自动为 LLM 提供文档元数据所描述的、结构化的文档级上下文。

元数据是指描述文档的、超越其原始文本的结构化属性。这些属性在文档摄取和索引之后生成。如果没有这些元数据值和上下文，模型可能会生成不完整或不精确的答案，尤其是在涉及大量相似且性质复杂的合同场景中。

• 合同类型（例如，许可协议）
• 管辖法律（例如，加利福尼亚州）
• 生效日期
• 到期日期
• 相关方
• 业务部门
• 保密级别

这个结构化层支持过滤、策略执行和更丰富的推理。

“本协议应自动续约，每次续约一年，除非任何一方在到期日期前至少 60 天提供书面不续约通知。”

• 该协议是否为许可协议。
• 是否受加利福尼亚州法律管辖。
• 是否已到期。
• 实际到期日期。

如果没有这些元数据值，模型可能会生成不完整或不够准确的响应。

为了解决这一限制，我们用文档级元数据值来丰富候选分块。为了避免为每个分块重复元数据（这会浪费输入令牌），我们首先按文档对分块进行分组，并一次性附加相关元数据。这为每个分块提供了更丰富的上下文，帮助 LLM 更有效地推理，从而产生更准确、一致和可靠的输出。

最后，重要的是要认识到，改进的质量取决于我们选择的元数据的相关性和适当性。当查询与可用元数据对齐时，过滤和丰富化效果最佳。相反，与这些元数据值无关的查询可能不会显示出同样的益处。因此，精心设计和审慎选择元数据字段对于最大化这种方法的影响至关重要。

评估过滤和丰富化的影响

实验在 Contract Understanding Atticus Dataset (CUAD)（许可和联合品牌协议）上进行。对于每个测试，检索深度设置为 top-k = 15。我们比较了四种逐步增强的配置。

基线RAG（无过滤器，无元数据）。在基线设置中，检索完全依赖语义相似性。系统在文档中检索到55个潜在候选条款。然而，只有一小部分相关上下文进入了传递给模型的前15个结果。观察结果：模型正确识别出一份已过期协议（Snap/United）。续约条款被部分描述。回答缺乏信心和完整的上下文支撑。

仅显式过滤。接下来，我们应用了显式过滤器（例如，将结果限制为美国合同）。这缩小了候选池，但准确率并未持续提升。观察结果：一份协议被错误分类为已过期。续约条款被误解。仅靠过滤缩小了搜索空间，但未提供足够的结构化上下文供精确推理。

隐式与显式过滤结合。随后，我们结合了查询派生的过滤器（加州法律）和应用级约束（美国合同）。这减少了竞争文档的数量，并改善了上下文聚焦。观察结果：模型识别出了正确的协议。然而，它在明确将其分类为已过期时有所犹豫。续约机制被描述出来，但措辞谨慎。过滤提高了检索精度，但不确定性仍然存在。

过滤与元数据增强。最后，我们用文档级元数据（如适用法律、到期日期和合同类型）对检索到的分块进行了增强。观察结果：系统正确识别出仅Snap/United为已过期。续约条款被清晰准确地解释。回答同时基于条款文本和结构化属性。该配置产生了最准确、最自信的输出。

结论

在本文中，我们展示了AIDA如何通过AI帮助客户评估法律文档。具体来说，我们描述了AIDA如何利用显式和隐式过滤，以及用元数据值增强分块，来改进RAG的结果并提高准确性。

通过将这些控制直接嵌入检索流程，AIDA可以为用户提供来自其有权访问的合同的洞察，同时保留做出自信决策所需的法律和业务上下文。其结果是提供了一种实用且适合企业级的合同智能方法，减少了人工审查工作量，提高了回答质量，并帮助组织释放其合同数据的整体价值。

要开始使用，请参阅Amazon Bedrock Knowledge Bases文档，并在AWS管理控制台中探索Amazon Bedrock。

关于作者