O problema de monitorar a web manualmente

Acompanhar dezenas de sites ao mesmo tempo é um trabalho que rapidamente se torna inviável quando feito de forma manual. Times de design precisam rastrear produtos de concorrentes, equipes de marketing querem monitorar tendências de conteúdo, e gerentes de produto precisam estar por dentro da inteligência de mercado. Mas fazer isso na mão significa visitar sites, copiar conteúdo e organizar informações antes mesmo de começar qualquer análise real.

Scrapers baseados em regras oferecem alguma automação, mas são fortemente acoplados à estrutura das páginas. Uma redesign do site ou uma migração para um frontend renderizado via JavaScript pode quebrar silenciosamente o pipeline por dias antes que alguém perceba.

Para resolver esse cenário, a AWS publicou uma solução de extração automatizada de insights utilizando o Amazon Bedrock AgentCore — uma plataforma para construir, conectar e otimizar agentes em escala, com qualquer framework ou modelo. O componente central da solução é o AgentCore Browser, um serviço de navegador totalmente gerenciado que renderiza páginas com muito JavaScript de forma confiável, tornando o pipeline mais resiliente às mudanças nos sites.

O que a solução entrega

A arquitetura combina quatro serviços principais: o Amazon Bedrock AgentCore Browser para automação do navegador, o Amazon Bedrock para análise com IA, o Amazon OpenSearch Serverless para busca semântica e o AWS Lambda para orquestração. O resultado é um sistema que monitora feeds RSS, recupera conteúdo da web usando o navegador gerenciado, extrai insights com IA e disponibiliza tudo em uma interface de busca.

Os casos de uso cobertos pela solução incluem:

• Inteligência competitiva: rastreamento de blogs de concorrentes, anúncios de produtos e comunicados à imprensa, com identificação de novos recursos, mudanças de preço ou movimentos estratégicos.
• Pesquisa de mercado: monitoramento de notícias do setor, relatórios de analistas e publicações especializadas para identificar tendências emergentes.
• Curadoria de conteúdo: agregação de conteúdo de múltiplas fontes com a IA identificando as peças mais relevantes para o público.
• Monitoramento de conformidade: acompanhamento de sites regulatórios e fontes de notícias para mudanças que possam afetar o negócio.

A implementação completa está disponível neste repositório no GitHub.

Como a arquitetura funciona

A arquitetura segue um padrão orientado a eventos que separa a coleta de conteúdo do processamento. O sistema é organizado em três camadas funcionais.

Coleta via feeds RSS

Um agendamento no Amazon EventBridge dispara uma função AWS Lambda a cada 15 minutos para verificar os feeds RSS configurados em busca de novos artigos, realizando deduplicação com base no Amazon Simple Storage Service (Amazon S3).

Recuperação de conteúdo via navegador gerenciado

Para cada novo artigo, a função Lambda abre uma sessão de navegador pelo Amazon Bedrock AgentCore e se conecta a ela usando o Playwright sobre o Protocolo Chrome DevTools (CDP). Diferente de requisições HTTP comuns, o navegador remoto renderiza a página completa — incluindo conteúdo JavaScript pesado —, aguarda o carregamento de elementos dinâmicos, tira um screenshot e faz o download de imagens. Esse é o passo que torna o restante do pipeline possível: sem renderização confiável de páginas, a extração por IA receberia conteúdo incompleto ou quebrado. Os artefatos são enviados ao Amazon S3 em um formato estruturado.

Vale destacar que esse não é um navegador headless rodando dentro do Lambda. É um serviço de navegador gerenciado: o AgentCore hospeda o navegador remoto, e o Playwright o controla por meio de uma conexão WebSocket.

Os arquivos são armazenados com a seguinte estrutura no S3:

s3://bucket/
└── example.com/
    └── abc123def456/  # hash da URL
        ├── article.html    # HTML completo
        ├── screenshot.png  # screenshot da página
        ├── metadata.json   # metadados do artigo
        └── images/         # imagens capturadas
            ├── image1.jpg
            └── image2.jpg

O arquivo metadata.json inclui a URL original, título, timestamp e referências para os assets baixados. Quando esse arquivo é enviado ao Amazon S3, ele dispara automaticamente o pipeline de processamento.

Processamento orientado a eventos

Eventos de upload no Amazon S3 publicam mensagens em uma fila do Amazon Simple Queue Service (Amazon SQS), e uma segunda função Lambda extrai o texto limpo do HTML bruto.

Extração de insights com IA

O Amazon Bedrock gera resumos, identifica temas e entidades, extrai insights acionáveis e cria embeddings vetoriais a partir do conteúdo limpo. Antes de enviar o conteúdo ao Bedrock, a função Lambda executa um pré-processamento do HTML para reduzir o consumo de tokens — um passo que melhora significativamente a consistência da saída gerada pela IA. Arquivos HTML grandes (acima de 1 MB) são simplificados com a biblioteca html-to-text para evitar limites de tokens. Arquivos menores usam a biblioteca Readability da Mozilla, que faz um trabalho melhor de extrair o conteúdo principal e identificar a imagem primária.

O prompt enviado ao Amazon Bedrock solicita a extração de:

• Um resumo conciso
• Temas e tópicos principais
• Entidades principais (pessoas, empresas, produtos)
• Categorias relevantes
• Insights acionáveis

Para verificar a disponibilidade de modelos por região da AWS, consulte a documentação de modelos suportados por região no Amazon Bedrock.

Indexação e busca semântica

Os resultados enriquecidos são indexados no Amazon OpenSearch Serverless, que suporta tanto busca por palavras-chave quanto busca vetorial. Uma consulta como “quais são as tendências emergentes de design” retorna resultados relevantes mesmo que essas palavras exatas não apareçam no conteúdo-fonte — é o embedding vetorial que torna a interface de busca genuinamente útil para inteligência competitiva ou pesquisa de mercado.

Acesso via interface web e API

Os usuários finais se autenticam pelo Amazon Cognito e acessam um frontend em React hospedado no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate. Para acesso programático, um servidor MCP (Protocolo de Contexto de Modelo) no Amazon ECS com Fargate expõe o sistema via Amazon CloudFront. O MCP é um padrão aberto que permite que assistentes de IA e ferramentas se conectem a fontes de dados externas por meio de uma interface unificada.

Controles de IA responsável

Como o pipeline envia conteúdo de terceiros a um modelo de fundação e publica a saída gerada pela IA para a equipe, implantações em produção devem incluir salvaguardas. O Amazon Bedrock Guardrails permite aplicar esses controles sem alterar o prompt de extração:

• Filtragem de conteúdo: bloqueia material prejudicial ou inapropriado que possa aparecer em páginas web antes de chegar ao índice pesquisável.
• Tópicos negados e filtros de palavras: mantêm os insights extraídos dentro do escopo esperado pelos times, o que importa quando os feeds de origem estão fora do controle da organização.
• Verificações de fundamentação contextual: validam que os resumos e insights gerados estão fundamentados no artigo-fonte, reduzindo o risco de afirmações alucinadas serem indexadas como fatos.

Como o pipeline ingere conteúdo de sites externos, o texto coletado deve ser tratado como entrada não confiável — os guardrails atuam como ponto de controle entre o conteúdo bruto da web e os insights que a organização consome.

Lições aprendidas na construção do pipeline

A AWS compartilhou algumas decisões arquiteturais que tiveram impacto desproporcional em custo, confiabilidade e qualidade de saída:

• Sessões do AgentCore Browser são poderosas, mas custosas. Cada renderização via Playwright pelo Amazon Bedrock AgentCore leva de 10 a 30 segundos e custa significativamente mais do que uma requisição HTTP simples. O uso de hash de URL para deduplicação — verificando o Amazon S3 antes de acionar uma nova sessão do AgentCore — é essencial para manter os custos gerenciáveis em escala.
• HTML bruto é uma entrada ruim para LLMs. Limpar o HTML antes de enviá-lo ao Amazon Bedrock reduz o consumo de tokens e melhora a consistência da saída. Esse pré-processamento não é uma otimização — é um pré-requisito para resultados confiáveis.
• A busca semântica amplia o que você consegue encontrar. Uma busca por palavras-chave retorna correspondências exatas, enquanto a busca vetorial traz conteúdo conceitualmente relacionado independentemente da terminologia usada.
• O desacoplamento via SQS é o que torna o pipeline confiável. Sem ele, uma falha de processamento significa que o artigo nunca é analisado. Uma fila de mensagens mortas (DLQ) entre o Amazon S3 e a Lambda de extração fornece retentativas automáticas — uma pequena mudança arquitetural com impacto significativo na confiabilidade.
• O Amazon OpenSearch Serverless tem um custo mínimo real. O serviço exige unidades de capacidade mínimas independentemente do uso, o que é adequado para cargas de trabalho de produção com volume consistente de consultas. Para implantações de menor volume, o Amazon Relational Database Service (Amazon RDS) com pgvector suporta as mesmas capacidades de busca vetorial com um custo base menor. Consulte os detalhes de preços do Amazon OpenSearch Serverless.

Conclusão

A solução apresentada pela AWS transforma o monitoramento manual da web em uma base de conhecimento pesquisável e enriquecida com IA. A arquitetura orientada a eventos desacopla a coleta de conteúdo do processamento, o Amazon Bedrock AgentCore lida com sites com JavaScript pesado, e o Amazon OpenSearch Serverless com embeddings vetoriais potencializa a busca semântica além da correspondência por palavras-chave.

O código-fonte completo, o guia de implantação e as instruções de configuração estão disponíveis no repositório no GitHub. Para quem quiser se aprofundar nos serviços envolvidos, a AWS também disponibiliza a documentação do Amazon Bedrock AgentCore Browser e o guia do desenvolvedor do Amazon OpenSearch Serverless.

Fonte

Automated web insight extraction with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/automated-web-insight-extraction-with-amazon-bedrock-agentcore/)

Busca na web direto no Amazon Bedrock, sem intermediários

A AWS anunciou a disponibilidade geral do Web Search no Amazon Bedrock — uma ferramenta nativa do lado do servidor que realiza buscas na web inteiramente dentro do ambiente AWS. O recurso permite que modelos OpenAI (GPT-5.4, GPT-5.5 e GPT-5.6 Sol/Terra/Luna) fundamentem suas respostas com informações atuais da web, sem que nenhum dado saia do ambiente seguro da AWS.

O problema que o Web Search resolve

Até então, quem precisava que um modelo de linguagem respondesse com base em informações recentes da internet tinha um caminho trabalhoso pela frente: contratar um provedor de busca terceiro, gerenciar chaves de API e cobranças separadas, construir uma orquestração personalizada e passar por revisões de conformidade adicionais para cada fornecedor externo envolvido.

O Web Search elimina toda essa complexidade. Basta adicionar um único parâmetro à chamada de API já existente — sem onboarding de fornecedor, sem APIs externas para orquestrar e sem revisões de segurança adicionais.

Como o Web Search funciona por dentro

O recurso foi desenvolvido pela própria Amazon, com base em anos de experiência acumulada em produtos como Alexa+, Amazon Quick e Kiro. Ele combina dois componentes principais:

• Índice web próprio da Amazon: abrange dezenas de bilhões de documentos, atualizado continuamente.
• Grafo de conhecimento integrado: fornece fatos verificados, indo além da simples recuperação de páginas brutas.

Em vez de devolver páginas cruas ao modelo, o Web Search realiza extração semântica de trechos relevantes — entregando resultados otimizados para a janela de contexto do modelo, com baixa latência.

Integração simples via API padrão

O Web Search se integra por meio de uma interface padronizada de uso de ferramentas, compatível com a API de Respostas da OpenAI (OpenAI Responses API). O fluxo é direto: adiciona-se a ferramenta de busca na chamada de API e o Bedrock cuida de todo o ciclo de busca no lado do servidor. Uma única chamada retorna uma resposta fundamentada, já com as citações incluídas.

Disponibilidade e próximos passos

O Web Search no Amazon Bedrock já está disponível nas regiões US East (N. Virginia), US East (Ohio) e US West (Oregon).

Para se aprofundar no tema, a AWS disponibiliza os seguintes recursos:

• Post introdutório sobre o Web Search no Amazon Bedrock para fundamentação de modelos — com detalhes técnicos e casos de uso.
• Seção de Web Search no Guia do Usuário do Amazon Bedrock — para documentação técnica completa.
• Página de preços do Amazon Bedrock — para entender os custos envolvidos.

Fonte

Amazon Bedrock launches Web Search for OpenAI GPT models (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-web/)

O que foi anunciado

A AWS anunciou que os modelos OpenAI GPT-5.6 Sol, Terra e Luna passam a suportar janelas de contexto de 1 milhão de tokens no Amazon Bedrock. Isso significa que é possível processar bases de código completas, documentos extensos e históricos de conversas em agentes com múltiplas etapas — tudo em uma única requisição, sem precisar fragmentar o conteúdo.

Com uma janela de contexto tão ampla, os modelos conseguem raciocinar sobre um volume muito maior de informações de uma vez, retornando respostas mais precisas e coerentes. A principal vantagem prática é eliminar a necessidade de técnicas de chunking (divisão do conteúdo em pedaços menores) e reduzir a perda de informações que costuma ocorrer quando o contexto é truncado.

Casos de uso habilitados

A AWS destaca três cenários principais que se beneficiam diretamente dessa capacidade expandida:

• Revisão e migração de código: é possível analisar repositórios inteiros em uma única passagem, sem precisar dividir o projeto em partes menores.
• Documentos jurídicos e regulatórios: contratos longos, normas e regulamentações podem ser processados do início ao fim sem interrupções.
• Fluxos de trabalho agênticos com múltiplas etapas: o histórico completo de uma conversa ou de uma sequência de ações pode ser mantido durante toda a execução do agente.

Prompt caching e desconto de cobrança

Um detalhe importante para quem vai usar esses modelos em produção: o prompt caching com pontos de cache explícitos já se aplica às requisições de contexto longo. Na prática, contextos repetidos são cobrados com desconto de cache, o que pode representar uma economia relevante em aplicações que reutilizam grandes blocos de contexto com frequência.

Disponibilidade por região

A disponibilidade dos modelos varia conforme a região AWS:

• GPT-5.6 Sol: disponível em US East (N. Virginia) e US East (Ohio).
• GPT-5.6 Terra e Luna: disponíveis em US East (N. Virginia), US East (Ohio) e US West (Oregon).

Como começar a usar

Para experimentar os modelos Sol, Terra e Luna com suporte a 1 milhão de tokens, a AWS indica dois caminhos: pelo Console do Amazon Bedrock ou pela Responses API no endpoint bedrock-mantle. Para detalhes técnicos e configurações, a documentação do Amazon Bedrock traz as informações completas. Quem quiser entender o contexto mais amplo do lançamento pode conferir também o post de lançamento oficial.

Fonte

OpenAI GPT-5.6 Sol, Terra, and Luna now support 1 million token context windows on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/08/gpt-sol-terra-luna-long-context-bedrock)

O problema que a AWS resolveu

Quem já trabalhou com políticas de Automated Reasoning checks (Verificações de Raciocínio Automatizado) no Amazon Bedrock Guardrails sabe que o maior atrito no processo não é criar a política — é afinar ela. O ciclo de diagnosticar falhas, editar regras manualmente, retestar e repetir consumia tempo considerável de especialistas. A AWS anunciou o refinamento automático de políticas, que automatiza justamente a parte de diagnóstico e correção desse ciclo.

Vale lembrar o que são os Automated Reasoning checks: eles traduzem linguagem natural para lógica formal e aplicam técnicas de verificação automatizada para produzir um resultado — VALID, INVALID, SATISFIABLE, IMPOSSIBLE ou TRANSLATION_AMBIGUOUS. Em traduções sem ambiguidade, o recurso entrega até 99% de precisão de verificação, conforme reportado no anúncio de disponibilidade geral.

O pipeline de dois passos que explica tudo

Para entender o refinamento, é preciso ter clareza sobre como uma política funciona internamente. O processo tem dois passos sequenciais:

• Passo de tradução: o texto em linguagem natural (entrada e saída) é mapeado para atribuições de variáveis, usando as descrições de variáveis definidas na política.
• Passo de validação: as regras formais da política são aplicadas sobre essas atribuições para chegar a um resultado final.

Quando um teste falha, o problema está em um desses dois passos. É exatamente por isso que o refinamento automático oferece dois modos distintos, cada um mirando uma etapa diferente do pipeline.

Os dois tipos de falha — e como identificá-los

Falha tipo 1: problema nas regras (a lógica está errada)

Nesse cenário, a tradução funcionou corretamente — as variáveis certas receberam os valores certos — mas o resultado da validação não corresponde ao esperado. O problema está nas regras: alguma está permissiva demais, restritiva demais ou simplesmente ausente. O modelo entendeu a pergunta perfeitamente, mas aplicou a lógica errada.

Falha tipo 2: tradução ambígua (a linguagem está errada)

Quando um teste retorna TRANSLATION_AMBIGUOUS, significa que o motor de validação chegou a resultados diferentes dependendo de qual interpretação seguiu. As causas mais comuns incluem variáveis com definições sobrepostas (por exemplo, “tempo de serviço” e “meses de emprego” descrevendo o mesmo conceito), descrições vagas, formatos de valor inconsistentes (5 versus 0,05 para representar “5%”) e nomes de variáveis que já embutem negações, o que confunde os modelos de tradução.

Modo 1: Refinamento Iterativo — corrigindo as regras

O Refinamento Iterativo (ITERATIVELY_REFINE_POLICY) é indicado quando a tradução está correta, mas o resultado da validação não bate com o esperado. Antes desse recurso, corrigir uma política com 10 a 30 regras exigia que um especialista rastreasse cada regra manualmente, formulasse hipóteses e editasse lógica formal SMT-LIB à mão. Esse trabalho agora se resume a uma etapa de revisão e aprovação.

Como funciona

O motor recebe três entradas: a definição atual da política (regras, variáveis e tipos), um documento-fonte com o texto autoritativo em linguagem natural, e — opcionalmente — um feedback em linguagem natural descrevendo explicitamente o que deve mudar. Por exemplo: “Atualize o requisito de tempo de serviço para licença parental de 12 para 6 meses, conforme a seção 3 do documento revisado.”

Internamente, o motor gera uma proposta de mudança, simula o efeito sobre os testes salvos, verifica se os testes que falhavam agora passam e ajusta caso necessário. Esse ciclo acontece de forma transparente — o que o usuário recebe é o resultado convergido: um diff mostrando exatamente quais regras e variáveis foram alteradas e como cada teste é afetado.

Fluxo via API (Boto3)

O refinamento é executado como um fluxo assíncrono. O processo tem quatro etapas: exportar a definição atual da política, iniciar o fluxo, aguardar a conclusão e recuperar as mudanças propostas.

import boto3
bedrock = boto3.client("bedrock")

# Export the current policy definition (required input to the workflow).
policy_definition = bedrock.export_automated_reasoning_policy_version(
    policyArn=policy_arn,
)["policyDefinition"]

with open("hr-leave-policy.pdf", "rb") as f:
    source_document = f.read()

response = bedrock.start_automated_reasoning_policy_build_workflow(
    policyArn=policy_arn,
    buildWorkflowType="ITERATIVELY_REFINE_POLICY",
    sourceContent={
        "policyDefinition": policy_definition,
        "workflowContent": {
            "iterativeRefinementContent": {
                "documents": [
                    {
                        "document": source_document,
                        "documentName": "hr-leave-policy.pdf",
                        "documentContentType": "pdf",
                    }
                ],
                "feedback": "Update the tenure requirement from 12 to 6 months per section 3.",
            }
        },
    },
)
build_workflow_id = response["buildWorkflowId"]

A chamada retorna imediatamente com um buildWorkflowId. O fluxo passa pelos estados SCHEDULED → BUILDING até atingir COMPLETED, FAILED ou CANCELLED. A convergência leva tipicamente de um a alguns minutos, dependendo do tamanho da política.

import time

while True:
    workflow = bedrock.get_automated_reasoning_policy_build_workflow(
        policyArn=policy_arn,
        buildWorkflowId=build_workflow_id,
    )
    status = workflow["status"]
    if status in ("COMPLETED", "FAILED", "CANCELLED"):
        break
    time.sleep(10)

if status == "COMPLETED":
    assets = bedrock.get_automated_reasoning_policy_build_workflow_result_assets(
        policyArn=policy_arn,
        buildWorkflowId=build_workflow_id,
        assetType="POLICY_DEFINITION",
    )
    proposed_definition = assets["buildWorkflowAssets"]["policyDefinition"]

A definição retornada é o DRAFT proposto. Para confirmar as mudanças, basta chamar update_automated_reasoning_policy com essa definição. Para ver o que mudou, compare com a definição exportada antes de iniciar o fluxo.

Modo 2: Refinamento de Variáveis Ambíguas — corrigindo a linguagem

Quando os testes retornam TRANSLATION_AMBIGUOUS, nenhuma quantidade de edição de regras vai resolver o problema — a raiz está na linguagem usada para descrever as variáveis. O Refinamento de Variáveis Ambíguas (RESOLVE_POLICY_AMBIGUITIES) identifica quais descrições de variáveis causam interpretações conflitantes e propõe definições mais precisas.

O que ele corrige

O modo detecta padrões como variáveis sobrepostas (duas variáveis descrevendo o mesmo conceito), descrições incompletas ou vagas, formatos de valor inconsistentes e nomes de variáveis que embutem negações. Quando variáveis sobrepostas são detectadas, pode ser proposta uma fusão: uma variável é eliminada e as regras que a referenciavam são atualizadas para usar a variável sobrevivente.

Um exemplo típico de proposta antes/depois:

• Antes: tenureMonths: “How long the employee has worked in months.”
• Depois (proposto): tenureMonths: “The number of complete months the employee has been continuously employed. When users mention years of service, convert to months (for example, 2 years = 24 months). This variable captures references to employment duration, length of service, time at the company, or seniority.”

Fluxo via API

O padrão assíncrono é o mesmo do Refinamento Iterativo. A diferença é que esse modo analisa as variáveis da política diretamente e não exige documento-fonte nem testes anexados — apenas a definição atual da política em sourceContent.

response = bedrock.start_automated_reasoning_policy_build_workflow(
    policyArn=policy_arn,
    buildWorkflowType="RESOLVE_POLICY_AMBIGUITIES",
    sourceContent={
        "policyDefinition": policy_definition,
    },
)
build_workflow_id = response["buildWorkflowId"]

O polling e a recuperação dos resultados seguem exatamente o mesmo padrão mostrado para o Refinamento Iterativo, usando assetType="POLICY_DEFINITION".

O princípio inegociável: aprovação humana em todas as mudanças

Os dois modos compartilham uma propriedade fundamental: nenhuma alteração entra em vigor sem aprovação explícita. O motor de refinamento tem autoridade para sugerir. O usuário tem autoridade para confirmar. Nenhuma mudança chega à política DRAFT — muito menos à produção — sem que o responsável aceite a proposta.

A tela de revisão mostra simultaneamente o diff das mudanças propostas (regras adicionadas, editadas ou removidas; variáveis alteradas; tipos de variáveis customizados modificados) e o impacto de cada mudança sobre todos os testes salvos. Se os testes que falhavam agora passam e os que passavam continuam passando, a proposta pode ser aceita com confiança.

Walkthrough A: corrigindo um problema de regra

Considere uma política de elegibilidade de licença parental de RH com um teste falhando. O assistente informa que um funcionário em regime de meio período com 8 meses de tempo de serviço é elegível para licença parental. O teste espera INVALID, mas a política retorna VALID.

Ao inspecionar o resultado do teste, as variáveis estão corretamente capturadas: monthsOfContinuousService = 8 e employmentStatus = PART_TIME. O resultado é VALID porque a única regra de suporte concede elegibilidade após 6 meses de serviço contínuo, sem nenhuma regra que exclua funcionários de meio período. A tradução está correta — o problema é de lógica.

Ao acionar o Refinamento Iterativo com o documento-fonte e o feedback “Add a rule that explicitly makes part-time employees ineligible for parental leave”, o motor propõe duas mudanças: remove a regra que concedia elegibilidade apenas por tempo de serviço e adiciona uma regra que exclui funcionários de meio período. O teste que falhava passa a ser aprovado, sem regressões nos demais.

Walkthrough B: corrigindo um problema de linguagem

Na mesma política de RH, um teste retorna TRANSLATION_AMBIGUOUS. O resultado mostra duas interpretações: uma mapeou “2 anos de serviço” para tenureMonths = 24 e outra para monthsOfService = 24. Duas variáveis descrevem o mesmo conceito — essa sobreposição é a raiz da ambiguidade.

O Refinamento de Variáveis Ambíguas não exige documento-fonte. Ao ser acionado, ele propõe eliminar monthsOfService, atualizar as regras que a referenciavam para usar tenureMonths e expandir a descrição dessa variável para incluir instruções explícitas de conversão e sinônimos. Após aceitar a proposta, o teste que retornava TRANSLATION_AMBIGUOUS passa a produzir um resultado definitivo.

Validando com o Relatório de Fidelidade

Após aplicar qualquer refinamento, a AWS recomenda gerar um Relatório de Fidelidade (GENERATE_FIDELITY_REPORT) para verificar se a política atualizada ainda representa fielmente o documento-fonte. O relatório fornece três métricas: pontuação de cobertura (0,0–1,0), pontuação de precisão (0,0–1,0) e ancoragem por regra, que vincula cada regra às declarações específicas do documento que a sustentam. Comparar os relatórios antes e depois do refinamento é a forma mais confiável de detectar se uma correção fez a política se desviar da intenção original.

Boas práticas

• Inspecione a tradução antes de escolher o modo. Abra o resultado do teste falhando e verifique as atribuições de variáveis. Se as variáveis certas têm os valores certos mas o resultado está errado, use Refinamento Iterativo. Se as atribuições estão erradas ou o resultado é TRANSLATION_AMBIGUOUS, use Refinamento de Variáveis Ambíguas.
• Delimite os inputs para limitar o escopo da mudança. Um documento-fonte focado em uma parte específica da política, combinado com feedback objetivo em formato “se-então”, produz propostas mais precisas e revisáveis do que apontar o motor para um manual de 40 páginas com instruções vagas.
• Confie no painel de resultados de testes, não apenas no diff. Um diff aparentemente limpo que causa regressão em testes que passavam não é uma correção válida.
• Compare Relatórios de Fidelidade antes de versionar. O refinamento otimiza para fazer testes passarem — essa otimização pode distanciar uma regra do que o documento-fonte realmente diz.

Casos de uso em setores regulados

A AWS destaca aplicações práticas em múltiplos setores: em RH, manuais de benefícios atualizados anualmente podem ser ingeridos pelo Refinamento Iterativo para propor atualizações de regras sem que o time precise tocar em lógica formal. Em serviços financeiros, variáveis sobrepostas como debtToIncomeRatio e DTI são consolidadas pelo Refinamento de Variáveis Ambíguas para suportar validação determinística. Em saúde e manufatura, equipes de conformidade podem refinar políticas iterativamente mantendo trilha de auditoria completa por meio de snapshots versionados e Relatórios de Fidelidade.

Recursos adicionais

• Documentação: documentação de Automated Reasoning checks
• Guia prático: Como minimizar alucinações de IA generativa com Automated Reasoning checks
• Chatbot com reescrita iterativa: implementação de referência do chatbot com Automated Reasoning checks e código de exemplo no GitHub
• Agente de formalização de políticas: exemplo open-source de agente que guia especialistas pelo processo em linguagem natural
• Exemplos de código: exemplos de Automated Reasoning checks no GitHub
• Resultados de clientes: caso Amazon Logistics | caso PitCrew | caso PwC Responsible AI in Education | recursos de IA Responsável da AWS
• Funcionalidades relacionadas: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore
• Orientações de IA responsável: AWS Well-Architected Responsible AI Lens

Fonte

Automated Reasoning policy refinement in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/automated-reasoning-policy-refinement-in-amazon-bedrock/)

Da prototipagem à produção: o desafio muda de forma

Quando um agente de Inteligência Artificial (IA) sai do ambiente de prototipagem e vai para produção, o tipo de problema que surge muda completamente. No início, o esforço é fazer o agente funcionar. Em produção, o desafio passa a ser mantê-lo rápido, estável e econômico.

A AWS publicou a segunda parte de sua série sobre depuração e otimização de agentes com o AgentCore Observability, recurso do Amazon Bedrock AgentCore. Enquanto a Parte 1 tratou de agentes quebrados — com loops infinitos e erros de invocação de ferramentas —, esta edição foca em agentes que funcionam corretamente, mas que apresentam problemas de performance: respostas lentas e crescimento descontrolado de memória em sessões longas.

Esses problemas são insidiosos: não disparam alertas de erro, mas corroem a confiança do usuário e aumentam custos ao longo do tempo. O artigo da AWS demonstra como usar o AgentCore Observability em conjunto com o Amazon CloudWatch para diagnosticar e corrigir esses cenários de forma sistemática.

Cenário 3: Gargalos de desempenho

Um agente com gargalo de desempenho é aquele que completa suas tarefas corretamente, mas demora demais para responder. O que é “demais” depende do contexto: 5 segundos podem ser aceitáveis para um processo em lote, mas inviáveis para um chatbot de atendimento ao cliente.

O padrão típico de degradação é gradual: o agente começa com 2 segundos de resposta, mas à medida que novas ferramentas são integradas e mais memória é acumulada, a latência sobe para 5, depois 10 segundos, até se tornar inutilizável. A taxa de erros permanece baixa — o que dificulta a detecção por alertas tradicionais.

Como identificar o gargalo

O primeiro passo é identificar as requisições com alta latência. Para isso, o artigo sugere consultar o CloudWatch buscando invocações do agente que ultrapassem o orçamento de desempenho definido para o seu caso de uso:

fields @timestamp, RequestId, Latency
| filter Operation like /InvokeAgent/
| filter Latency > 3000
| sort Latency desc
| limit 50

Essa consulta retorna as invocações que levaram mais de 3 segundos, ordenadas por latência. A partir de um RequestId representativo, é possível analisar a linha do tempo da requisição para entender onde o tempo está sendo gasto:

fields @timestamp, Operation, Duration, SpanName
| filter RequestId = "<RequestId>"
| sort @timestamp asc

Operações que consomem tempo de forma desproporcional são os principais suspeitos: recuperação de memória, invocação de ferramentas, geração de tokens e operações sequenciais que poderiam rodar em paralelo.

Para verificar especificamente a latência de recuperação de memória:

fields @timestamp, MemoryRetrievalLatency, MemoryNamespace
| filter RequestId = "<RequestId>"
| stats avg(MemoryRetrievalLatency), max(MemoryRetrievalLatency) by MemoryNamespace

A recuperação de memória deve ser concluída em menos de 200 milissegundos. Valores acima disso indicam organização ineficiente da memória. Para identificar ferramentas lentas:

fields @timestamp, ToolName, ToolLatency
| filter RequestId = "<RequestId>"
| sort ToolLatency desc

Causas raiz e como corrigir

O artigo da AWS aponta três causas principais de gargalos de desempenho:

• Execução lenta de ferramentas: ferramentas externas que demoram segundos para responder por conta de falta de otimização, sobrecarga ou latência de rede. O efeito se amplifica com chamadas sequenciais — uma ferramenta de 2 segundos chamada três vezes resulta em 6 segundos de espera.
• Geração excessiva de tokens: Modelos de Fundação (FM — Foundation Models) geram tokens de forma sequencial. Uma resposta de 500 tokens demora 5 vezes mais do que uma de 100 tokens, impactando latência e custo.
• Processamento sequencial: executar operações independentes uma após a outra, em vez de em paralelo, aumenta desnecessariamente o tempo total de resposta.

As correções recomendadas incluem: implementar cache, connection pooling e indexação adequada de banco de dados para ferramentas lentas; substituir grandes namespaces únicos por partições temáticas (preferências, histórico, conhecimento de domínio) para reduzir o espaço de busca na memória; otimizar prompts para respostas mais diretas e concisas; e paralelizar chamadas de ferramentas independentes. Chamadas sequenciais que somam 4,5 segundos (2s + 1,5s + 1s) caem para apenas 2 segundos quando paralelizadas — uma redução de 50% ou mais com esforço mínimo.

A imagem acima ilustra uma linha do tempo de rastreamento OpenTelemetry com 17 spans distribuídos em três operações sequenciais de execute_event_loop_cycle. As ferramentas customer_lookup e order_history são executadas uma após a outra, com cada ciclo aguardando o anterior terminar — padrão que compõe a latência a cada invocação de ferramenta.

Cenário 4: Problemas de memória em sessões longas

Agentes que mantêm sessões prolongadas — como assistentes de atendimento ao cliente, pesquisa ou monitoramento — acumulam contexto ao longo do tempo. Sem uma estratégia de gerenciamento de memória adequada, esse crescimento se torna ilimitado: o agente atinge limites de tokens, perde contexto importante ou esgota a memória disponível, resultando em falhas inesperadas de sessão.

Sintomas a observar

Os sinais de alerta incluem: sessões anormalmente longas, uso de tokens crescendo linearmente com a duração da sessão, latência de recuperação de memória aumentando progressivamente e sessões encerrando com erros de memória esgotada ou janela de contexto excedida.

O exemplo acima mostra os detalhes de sessão do agente memorygrowth_Agent: 6 traces, 15,7 mil tokens consumidos e latência média de 3.757 ms por trace em uma única sessão. O uso de tokens cresce a cada invocação sucessiva, demonstrando acumulação ilimitada de contexto — padrão que em sessões de horas leva ao esgotamento da janela de contexto e falhas inesperadas.

Como diagnosticar

Para identificar sessões longas com alto uso de memória, o artigo sugere a seguinte consulta no CloudWatch:

fields @timestamp, SessionId, SessionDuration, MemorySize, TokenUsage
| filter SessionDuration > 3600
| sort MemorySize desc
| limit 20

Essa consulta retorna sessões com mais de uma hora de duração, ordenadas pelo tamanho da memória. A partir de um SessionId com uso anormalmente alto, é possível examinar os padrões de extração de memória para verificar se a consolidação está ocorrendo:

fields @timestamp, MemoryExtractionStatus, MemoryExtractionLatency, MemoriesExtracted
| filter SessionId = "<SessionId>"
| sort @timestamp asc

A extração de memória deve ocorrer regularmente ao longo da sessão. Lacunas prolongadas sem extração indicam que o agente não está consolidando memórias adequadamente. Para verificar falhas de extração:

fields @timestamp, ErrorMessage, MemoryExtractionStatus
| filter SessionId = "<SessionId>"
| filter MemoryExtractionStatus = "Failed"

Falhas na extração de memória impedem o agente de consolidar contexto, causando crescimento ilimitado. As causas mais comuns incluem: limite de tokens excedido durante a sumarização, formatos de memória inválidos, timeouts de rede ao gravar no armazenamento de memória e erros de permissão que bloqueiam atualizações.

Para analisar a organização dos namespaces de memória:

fields @timestamp, MemoryNamespace, MemoryCount, MemorySize
| filter SessionId = "<SessionId>"
| stats sum(MemoryCount) as TotalMemories, sum(MemorySize) as TotalSize by MemoryNamespace
| sort TotalSize desc

Um único namespace com milhares de memórias é um sinal claro de que o agente precisa de melhor organização de memória.

Como corrigir

Para resolver problemas de memória, a AWS recomenda verificar se as estratégias de memória incluem uma configuração de consolidação, para que o AgentCore Memory mescle e sumarize registros ao longo do tempo em vez de acumulá-los indefinidamente. Também é importante organizar registros usando templates de namespace nas definições de estratégia, garantindo que a recuperação fique restrita ao contexto relevante. O parâmetro eventExpiryDuration controla por quanto tempo os eventos brutos persistem (entre 7 e 365 dias). Para mais detalhes, a AWS disponibiliza documentação sobre como o AgentCore Memory funciona e sobre a implementação do AgentCore Memory.

Boas práticas para produção

Além dos cenários de diagnóstico, o artigo da AWS apresenta um conjunto de boas práticas para evitar esses problemas antes que ocorram.

Instrumentação abrangente

Ative a instrumentação completa para agentes em produção, sistemas de memória e gateways. Configure logs do CloudWatch, métricas do CloudWatch e rastreamentos OpenTelemetry. Não espere que usuários reportem problemas — configure alarmes para métricas críticas com os seguintes limites sugeridos: taxa de erros acima de 5%, latência no percentil 95 (P95) acima de 3 segundos e uso de tokens por sessão.

Dashboards operacionais

A AWS recomenda criar um dashboard principal com: total de invocações nas últimas 24 horas, taxa de erros atual comparada ao baseline, latências P50/P95/P99, tendências de uso de tokens e contagem de sessões ativas. Dashboards por agente devem mostrar padrões de invocação específicos, distribuição de uso de ferramentas, tendências de consumo de memória, distribuição de tipos de erro e custo por sessão. Revisar esses dashboards diariamente ajuda a identificar tendências antes que se tornem problemas.

Avaliação contínua com AgentCore Evaluators e Insights

Para monitorar a precisão das ferramentas em escala, a AWS oferece o AgentCore Evaluators, que inspeciona sessões de agentes em tempo real e as pontua com base em critérios de qualidade predefinidos — sem necessidade de revisão manual de traces após falhas. O AgentCore Insights (preview) complementa os Evaluators com análise de triagem, extração de intenção do usuário e resumo de execução.

Limpeza de recursos

Após testar as técnicas de otimização, a AWS orienta remover os recursos criados para evitar cobranças desnecessárias. Para recursos do CloudWatch, exclua dashboards de teste, remova alarmes criados para fins de teste e considere arquivar ou excluir grupos de logs antigos. Para recursos do AgentCore, exclua agentes de teste pelo console do AgentCore, remova namespaces de memória de teste e delete integrações de ferramentas temporárias.

Para excluir grupos de logs do CloudWatch via CLI:

aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/your-agent-name

Para remover alarmes do CloudWatch:

aws cloudwatch delete-alarms --alarm-names your-alarm-name

Também vale revisar as configurações de retenção de logs do CloudWatch e considerar o uso do CloudWatch Logs Data Protection para reduzir custos de armazenamento de logs mais antigos.

Próximos passos

O artigo da AWS recomenda ativar o AgentCore Observability para agentes em produção como primeiro passo — essa configuração única fornece a base para todo o diagnóstico descrito. Em seguida, configurar alarmes no CloudWatch para métricas críticas, criar runbooks de troubleshooting documentando as consultas utilizadas, os limites que indicam problemas e as correções aplicadas.

A prática deliberada em ambientes não produtivos também é sugerida: introduzir falhas intencionalmente e praticar o diagnóstico usando os fluxos de trabalho apresentados, construindo familiaridade com as ferramentas antes de precisar delas em produção. Para mais informações, a documentação do AgentCore está disponível na documentação oficial do AgentCore e o Guia do Usuário do CloudWatch traz boas práticas adicionais de monitoramento.

Fonte

Optimizing production agents with Amazon Bedrock AgentCore Observability (https://aws.amazon.com/blogs/machine-learning/optimizing-production-agents-with-amazon-bedrock-agentcore-observability/)