Como melhorar a precisão na busca de contratos com filtros automáticos no Amazon Bedrock

O desafio de buscar contratos com IA

Empresas de setores como entretenimento e mídia gerenciam milhares de contratos jurídicos ao mesmo tempo — acordos de licenciamento, restrições geográficas, cláusulas de renovação, obrigações de conformidade. Hoje, grande parte desse trabalho ainda é feito manualmente: lento, caro e difícil de escalar.

Para endereçar esse problema, a AWS publicou um estudo sobre a solução AIDA (AI-Driven Annotation), que transforma contratos não estruturados em inteligência pesquisável e acionável. A AIDA permite que usuários façam perguntas em linguagem natural sobre grandes repositórios de contratos — mas entregar respostas precisas exige muito mais do que uma busca semântica simples.

Documentos jurídicos são altamente contextuais. Sistemas baseados em RAG (Geração Aumentada por Recuperação) podem retornar mais conteúdo do que um modelo de linguagem consegue processar com eficiência. Sem controle cuidadoso sobre quais trechos são recuperados — e sem contexto suficiente no nível do documento — cláusulas importantes correm o risco de serem ignoradas ou interpretadas de forma errada.

Visão geral da arquitetura

A AIDA é construída sobre uma arquitetura RAG usando o Amazon Bedrock Knowledge Bases. Toda a transmissão de dados entre os componentes é criptografada em trânsito via HTTPS/TLS 1.2+, incluindo uploads de documentos, chamadas a modelos de embeddings, consultas ao banco vetorial e entrega de respostas. Para dados armazenados no Amazon Bedrock, aplica-se o modelo de responsabilidade compartilhada da AWS.

O fluxo de implementação segue nove etapas bem definidas, divididas em dois grandes blocos: ingestão de dados e interação do usuário.

Fluxo de ingestão de dados

Etapa 1 — Ingestão de documentos e configuração de metadados: Os contratos são sincronizados no Amazon Bedrock Knowledge Bases junto com arquivos de metadados estruturados. Esses metadados devem conter atributos-chave como partes envolvidas, data de vigência, data de encerramento, jurisdição e outros campos relevantes para habilitar filtragens poderosas nas etapas seguintes.

Etapa 2 — Implementação do mecanismo de chunking: A base de conhecimento é configurada com um mecanismo sofisticado de divisão de documentos em segmentos semanticamente significativos, otimizados para recuperação. Cada segmento precisa ter contexto suficiente para ser útil, mas ser conciso o bastante para processamento eficiente. Os metadados fornecidos na ingestão são essenciais para a filtragem implícita — o que diferencia essa arquitetura de implementações RAG padrão.

Etapa 3 — Armazenamento no banco vetorial: Os segmentos processados são convertidos em embeddings vetoriais e armazenados em um banco vetorial. As opções disponíveis incluem o Amazon OpenSearch Service ou o Amazon S3 Vectors — ambos devem ser configurados com criptografia em repouso habilitada. O acesso à base de conhecimento é governado por políticas do AWS Identity and Access Management (IAM), com logging habilitado no Amazon CloudWatch para manter trilhas de auditoria para fins de conformidade.

Fluxo de interação do usuário

Etapa 4 — Geração de embeddings da consulta: Quando um usuário envia uma pergunta, a AIDA usa o Amazon Bedrock Guardrails para proteger contra injeções de prompt e vazamento de dados. Em seguida, a consulta é convertida em embeddings usando os modelos de embedding do Amazon Bedrock, permitindo comparação semântica com os segmentos armazenados.

Etapa 5 — Filtragem implícita e explícita: Antes de executar a busca semântica, o sistema aplica dois mecanismos de filtragem — um ponto central desta arquitetura. A filtragem implícita aplica automaticamente condições baseadas em metadados (como faixas de data de vigência ou partes específicas) antes da busca vetorial. Essa abordagem em dois estágios primeiro restringe o espaço de busca por restrições de metadados, depois aplica correspondência semântica dentro desse subconjunto filtrado.

Etapa 6 — Busca semântica e recuperação de documentos: O banco vetorial recupera os segmentos mais relevantes com base em pontuações de similaridade semântica, tipicamente usando métricas de similaridade de cosseno para identificar as correspondências mais próximas à consulta do usuário.

Etapa 7 — Augmentação do prompt: Os segmentos recuperados são usados para enriquecer a consulta original em um prompt cuidadosamente formatado, combinando a pergunta do usuário com os trechos de contrato relevantes e o contexto de metadados.

Etapa 8 — Geração de resposta pelo LLM: O prompt enriquecido é enviado a um LLM (Modelo de Linguagem de Grande Escala) via Amazon Bedrock, que gera uma resposta contextualmente precisa, fundamentada nos documentos reais — e não apenas no conhecimento de treinamento do modelo. O Amazon Bedrock Guardrails também é aplicado para filtragem de conteúdo, proteção de informações sensíveis (PII) e controles de segurança de prompt.

Etapa 9 — Entrega da resposta com atribuição de fonte: A resposta final é retornada ao usuário pela Retrieve API, garantindo que as respostas sejam rastreáveis até os documentos-fonte específicos. Essa rastreabilidade reduz alucinações — um desafio comum em LLMs — e fornece inteligência contratual verificável.

O problema do volume de informação no RAG jurídico

Um dos principais desafios ao desenvolver um sistema RAG para análise de contratos é gerenciar o volume de informação potencialmente relevante. Considere a seguinte pergunta:

“Por favor, identifique quaisquer acordos de licenciamento expirados regidos pela lei da Califórnia. Como esses acordos se renovam?”

Essa consulta pode corresponder a centenas de trechos relevantes em múltiplos documentos. O Amazon Bedrock retorna os top-k (máximo 100) segmentos mais relevantes — mas os demais podem conter contexto crítico que ficará de fora. Como resultado, as respostas do LLM podem ser incompletas ou imprecisas.

Documentos jurídicos são altamente estruturados e dependentes de contexto. Uma cláusula de renovação em um acordo de licenciamento regido pela lei da Califórnia pode funcionar de forma completamente diferente de uma cláusula similar em outra jurisdição. Se a etapa de recuperação não filtrar corretamente por tipo de contrato e lei aplicável, o sistema pode retornar contratos irrelevantes — como NDAs ou acordos de serviço — que até contêm linguagem de expiração ou renovação, mas não respondem à pergunta original.

É importante destacar que, mesmo com todas essas melhorias de recuperação, interpretações de contratos geradas por IA devem sempre ser revisadas por profissionais jurídicos qualificados antes de serem usadas em decisões de negócio. A AIDA é projetada como uma ferramenta de suporte à decisão, não como substituta da expertise jurídica.

Filtragem implícita

A filtragem implícita é uma capacidade do Amazon Bedrock Knowledge Bases que permite filtrar automaticamente os resultados de busca com base em atributos de metadados, sem exigir expressões de filtro explícitas em cada consulta. O mecanismo opera em dois estágios:

• Estágio 1 — Pré-filtragem por metadados: Antes de executar a busca por similaridade semântica, o sistema aplica condições baseadas em metadados automaticamente. É possível fornecer um arquivo de metadados customizado (até 10 KB por documento) para cada documento na base de conhecimento, contendo atributos como datas de vigência, tipos de documento, partes envolvidas ou campos personalizados relevantes para o caso de uso.
• Estágio 2 — Busca semântica no subconjunto filtrado: Após restringir o conjunto de documentos pelos filtros de metadados, o sistema executa a busca por similaridade vetorial apenas dentro desse subconjunto. Isso reduz ruído e informações irrelevantes, melhorando a precisão da recuperação.

Filtragem explícita

A filtragem explícita é aplicada de forma consistente na camada de aplicação, independentemente da entrada do usuário. Essa abordagem garante que os resultados de busca permaneçam alinhados com políticas de negócio, requisitos de conformidade e restrições organizacionais. Casos de uso comuns incluem:

• Restrições no nível da aplicação: Limitar resultados com base em regras predefinidas do sistema.
• Restrições geográficas: Garantir que usuários em determinadas regiões acessem apenas documentos alinhados com regulamentações locais (ex: usuários europeus restritos a contratos da UE).
• Restrições temporais: Retornar apenas documentos dentro de um período específico (ex: contratos ativos nos últimos dois anos).
• Classificação e sensibilidade: Restringir resultados a documentos marcados com um nível de confidencialidade exigido.

Exemplo de filtro explícito utilizado na solução:

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

Além da filtragem: enriquecimento de segmentos com metadados

Embora a filtragem implícita e explícita restrinja o conjunto de segmentos candidatos, ela não fornece automaticamente ao LLM o contexto estruturado no nível do documento. Sem esses valores de metadados, o modelo pode gerar respostas incompletas ou menos precisas — especialmente em cenários com alto volume de contratos similares e complexos.

Para análise de contratos jurídicos, campos de metadados comuns incluem: tipo de contrato, lei aplicável, data de vigência, data de expiração, partes envolvidas, unidade de negócio e nível de confidencialidade.

Voltando ao exemplo da pergunta sobre acordos de licenciamento expirados regidos pela lei da Califórnia: suponha que um segmento recuperado contenha a seguinte cláusula:

“Este Acordo será renovado automaticamente por períodos sucessivos de um ano, a menos que qualquer uma das partes forneça aviso por escrito de não renovação com pelo menos 60 dias de antecedência da data de expiração.”

Se essa cláusula for fornecida ao LLM sem os metadados associados ao documento, o modelo não consegue determinar: se o acordo é um contrato de licenciamento; se é regido pela lei da Califórnia; se já expirou; ou qual é a data real de expiração. Sem esses valores, o modelo pode gerar respostas incompletas ou imprecisas.

Para resolver essa limitação, a AIDA enriquece os segmentos candidatos com metadados no nível do documento. Em vez de duplicar metadados para cada segmento — o que desperdiçaria tokens de entrada — os segmentos são agrupados por documento e os metadados relevantes são anexados uma única vez. Isso dá a cada segmento um contexto mais rico e ajuda o LLM a raciocinar com mais eficácia.

Avaliando o impacto da filtragem e do enriquecimento

Para avaliar o impacto dessas técnicas, a AWS testou a pergunta-guia sobre acordos de licenciamento expirados usando o Contract Understanding Atticus Dataset (CUAD) (acordos de licenciamento e co-branding). Em cada teste, a profundidade de recuperação foi definida como top-k = 15. Quatro configurações progressivamente aprimoradas foram comparadas:

• RAG base (sem filtros, sem metadados): O sistema recuperou 55 segmentos candidatos potenciais, mas apenas uma fração do contexto relevante chegou aos 15 resultados passados ao modelo. O modelo identificou corretamente um acordo expirado, mas as condições de renovação foram descritas de forma parcial e a resposta careceu de confiança e fundamentação contextual completa.
• Apenas filtragem explícita: Reduziu o conjunto candidato, mas a precisão não melhorou de forma consistente. Um acordo foi incorretamente classificado como expirado e cláusulas de renovação foram mal interpretadas. A filtragem sozinha restringiu o espaço de busca, mas não forneceu contexto estruturado suficiente para raciocínio preciso.
• Filtragem implícita e explícita combinadas: Reduziu o número de documentos concorrentes para 20 e melhorou o foco contextual. O modelo identificou o acordo correto, mas hesitou em classificá-lo definitivamente como expirado. Os mecanismos de renovação foram descritos, mas com ressalvas.
• Filtragem com enriquecimento de metadados: Com os segmentos enriquecidos com metadados como lei aplicável, data de expiração e tipo de contrato, o sistema identificou corretamente apenas o acordo Snap/United como expirado, explicou claramente os termos de renovação e produziu a resposta mais precisa e confiável de todas as configurações.

A qualidade das melhorias depende diretamente da relevância e adequação dos metadados escolhidos. A filtragem e o enriquecimento funcionam melhor quando as consultas estão alinhadas com os metadados disponíveis. Consultas não relacionadas a esses metadados podem não apresentar os mesmos benefícios — por isso, o design cuidadoso e a seleção criteriosa dos campos de metadados são essenciais.

Conclusão

A abordagem descrita pela AWS demonstra como a combinação de filtragem explícita, filtragem implícita e enriquecimento de segmentos com metadados no Amazon Bedrock Knowledge Bases pode melhorar significativamente a precisão de sistemas RAG aplicados à análise de contratos jurídicos. Ao incorporar esses controles diretamente no pipeline de recuperação, a AIDA consegue fornecer aos usuários insights derivados dos contratos que estão autorizados a acessar, preservando o contexto jurídico e de negócio necessário para tomadas de decisão confiantes.

O resultado é uma abordagem prática e pronta para uso empresarial que reduz o esforço de revisão manual, melhora a qualidade das respostas e ajuda organizações a extrair valor real de seus dados contratuais.

Para começar, a AWS recomenda consultar a documentação do Amazon Bedrock Knowledge Bases e explorar o Amazon Bedrock no Console de Gerenciamento da AWS.

Fonte

Improve contract search accuracy with auto-generated filters in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/improve-contract-search-accuracy-with-auto-generated-filters-in-amazon-bedrock/)