AWS outlines a filtered RAG design for legal contracts
AWS has described a contract-search architecture called AIDA that uses Amazon Bedrock Knowledge Bases to make legal document retrieval more precise. The design combines implicit metadata filters, explicit application rules and metadata-enriched chunks before an LLM generates an answer. In AWS's evaluation on CUAD licensing and co-branding agreements, the most complete configuration produced the strongest answer for a California-law licensing query. The post frames the system as decision support for legal teams, not a substitute for qualified legal review.Legal RAG needs narrower retrieval than semantic search alone
AIDA addresses a common weakness in retrieval-augmented generation for contracts: semantic search can return plausible but legally irrelevant excerpts. AWS says large contract repositories contain agreements across different parties, jurisdictions, dates and document types, so a query about one legal context may match many clauses that use similar language but do not answer the question.The example used in the AWS post asks for expired licensing agreements governed by California law and how those agreements renew. A renewal clause from another jurisdiction, a service agreement or an NDA may look semantically close, but it can mislead the model if it enters the prompt. The implication is practical: legal AI systems need retrieval controls that understand document attributes, not only the wording of clauses.
AIDA filters before the vector search runs
The architecture uses Amazon Bedrock Knowledge Bases to ingest contracts, convert chunks into embeddings and store them in supported vector database options such as Amazon OpenSearch Service or Amazon S3 Vectors. AWS describes this as a RAG design in which document metadata is added during ingestion, including attributes such as parties, effective date, termination date and jurisdiction.The key change is the order of retrieval. Before semantic similarity search, AIDA can apply metadata constraints that narrow the candidate set. In AWS's description, implicit filtering automatically applies conditions derived from metadata, while explicit filtering applies application-layer constraints such as geography, time frame or classification level. Search then runs inside the filtered subset, which should reduce noise and leave the LLM with excerpts more closely tied to the question.
Metadata enrichment gives the model contract-level context
Filtering narrows the pool, but AWS argues that it does not by itself give the model enough structured context. A clause may say that an agreement renews for successive one-year terms unless notice is given 60 days before expiration, yet that text alone may not tell the model whether the agreement is a licensing agreement, whether California law applies or whether the expiration date has already passed.AIDA addresses that gap by enriching retrieved chunks with document-level metadata values. AWS says the system groups chunks by document and attaches relevant metadata once, rather than duplicating metadata for every chunk and wasting prompt tokens. The result is a prompt that combines clause text with structured attributes such as governing law, expiration date and contract type. For contract analysis, that distinction matters because an answer often depends on the legal status of the whole agreement, not a single paragraph in isolation.
Security controls are part of the retrieval boundary
AWS presents AIDA as an enterprise contract-intelligence design with several access and security layers. The post says data transmission between components uses encryption in transit through HTTPS and TLS 1.2 or later, while vector database options should be configured with encryption at rest. It also says access to the knowledge base and model invocations is governed through AWS Identity and Access Management policies, with Amazon CloudWatch logging used for audit trails.At the application layer, AIDA uses role-based access enforced through IAM policies and project-scoped roles. During interaction, Amazon Bedrock Guardrails are used to help protect against prompt injections, data leaks, sensitive information exposure and unsafe content. These controls are not just compliance features; they shape what the retrieval system is allowed to see and return, which is central when contract repositories contain confidential or access-restricted agreements.
CUAD tests favored filtering plus enrichment
AWS evaluated four configurations using the Contract Understanding Atticus Dataset, specifically licensing and co-branding agreements, with retrieval depth set to top-k equals 15. In the baseline RAG setup without filters or metadata, AWS says the system found 55 potential candidate clauses, but only part of the relevant context reached the top 15 results. The model identified one expired agreement, Snap/United, but renewal terms were only partially described and the answer lacked full grounding.With explicit filtering only, AWS says the candidate pool was reduced but accuracy did not improve consistently. One agreement was incorrectly classified as expired, and renewal clauses were misinterpreted. When implicit and explicit filtering were combined, the model identified the correct agreement, but hesitated to classify it definitively as expired. The strongest result came from filtering plus metadata enrichment: AWS says the system correctly identified only Snap/United as expired, explained renewal terms clearly and grounded the response in both clause text and structured attributes.
Conclusion
The AWS post is less a product launch than a reference pattern for legal RAG systems built on Amazon Bedrock. Its main argument is that contract search accuracy depends on retrieval discipline: metadata must narrow the candidate set, application rules must enforce business boundaries and chunks must carry enough document-level context for the LLM to reason about legal status.The limitations are also clear from the source. AWS says improvements depend on choosing relevant metadata fields, and queries unrelated to those fields may not show the same benefits. It also states that AI-generated contract interpretations should be reviewed by qualified legal professionals before business use. For enterprises, the takeaway is that legal AI accuracy is not only a model question; it is an architecture, metadata and governance question.
Sources
- Improve contract search accuracy with auto-generated filters in Amazon Bedrock | Amazon Web Services
Editorial Team - CoinBotLab