Blog

O problema: quando o SDK não é uma opção

Equipes de aprendizado de máquina (ML) usam o MLflow para gerenciar o ciclo de vida dos seus modelos de forma eficiente. O Amazon SageMaker MLflow oferece capacidades abrangentes de rastreamento de experimentos e gerenciamento de modelos. No entanto, muitas empresas possuem requisitos de infraestrutura que exigem integrações baseadas em HTTPS em vez do uso direto do SDK.

O desafio é comum: políticas de segurança corporativa, restrições de rede ou limitações de sistemas legados impedem que as equipes usem o SDK do MLflow diretamente. A AWS publicou uma solução que endereça exatamente esse cenário — um serviço proxy Flask que atua como intermediário seguro entre os sistemas existentes e o SageMaker MLflow.

Visão geral da solução

A arquitetura proposta é composta por três componentes principais que trabalham em conjunto para garantir integração segura e compatível com ambientes corporativos.

Componente 1: Application Load Balancer (ALB)

Um AWS Application Load Balancer atua como roteador de entrada, responsável por:

• Distribuir o tráfego entre requisições da interface do MLflow e chamadas REST API.
• Realizar o tratamento inicial das requisições e o roteamento.
• Suportar domínios customizados e encerramento SSL.

Vale destacar que o ALB é a opção utilizada nessa implementação, mas outras soluções de roteamento, como Nginx, também podem ser utilizadas conforme a necessidade.

Componente 2: Flask MLflow Proxy Service

No centro da arquitetura, uma aplicação Python baseada em Flask é responsável por:

• Interceptar e processar as requisições HTTPS recebidas.
• Gerenciar a autenticação AWS e a assinatura das requisições.
• Transformar URLs para acesso seguro aos endpoints do MLflow.
• Encaminhar as respostas de volta aos clientes.

Componente 3: Amazon SageMaker MLflow

O serviço gerenciado da AWS suporta dois modos de implantação do MLflow:

• MLflow Tracking Server — servidor de rastreamento gerenciado.
• MLflowApp — aplicação MLflow serverless.

Em ambos os casos, o serviço fornece o armazenamento de metadados de experimentos e os arquivos de modelos.

Fluxo de requisições na arquitetura

O fluxo de uma requisição nessa arquitetura segue uma sequência bem definida. Quando um cliente inicia uma chamada HTTPS, ela primeiro chega ao ALB, que a encaminha para o serviço proxy Flask. A partir daí, o proxy realiza uma série de operações críticas:

• Autenticação via integração com o Gerenciamento de Identidade e Acesso da AWS (IAM).
• Transformação e pré-assinatura de URLs para acesso seguro.
• Processamento dos endpoints REST do MLflow conforme necessário.

Após essas transformações, a requisição autenticada é enviada ao SageMaker MLflow, que a processa e retorna a resposta. O proxy então encaminha essa resposta de volta ao cliente original. Toda essa cadeia mantém a segurança sem exigir que o cliente conheça os detalhes internos da autenticação AWS.

Pré-requisitos para implantação

Antes de começar, é necessário ter os seguintes recursos disponíveis:

• Uma conta AWS.
• Interface de Linha de Comando AWS (AWS CLI) configurada com permissões para criar: Nuvem Privada Virtual (Amazon VPC), instâncias Amazon EC2, recursos Amazon SageMaker AI, buckets Amazon S3, funções e políticas IAM, stacks AWS CloudFormation e Application Load Balancers.
• Node.js versão 18.0.0 ou superior.
• NPM.
• Kit de Desenvolvimento em Nuvem AWS (AWS CDK) CLI versão 2.100.0 ou superior.
• Python 3.x com pip ou pip3.

Do ponto de vista de conhecimento, é esperado que o profissional tenha familiaridade básica com serviços AWS e permissões IAM, com aplicações Python e Flask, e com os conceitos e operações do MLflow.

Em relação aos custos, a solução cria recursos AWS que podem gerar cobranças, principalmente instâncias Amazon EC2, o Application Load Balancer, recursos Amazon SageMaker AI e armazenamento Amazon S3. Para estimar os valores, a AWS disponibiliza a Calculadora de Preços AWS.

Implantando a solução

O processo de implantação leva aproximadamente 40 minutos e está dividido em três etapas.

Etapa 1: Implantação da infraestrutura com AWS CDK

O primeiro passo é baixar o código da solução e instalar as dependências:

# Clone the repository
git clone https://github.com/aws-samples/sample-sagemaker-mlflow-rest-apis.git

# Navigate to project directory and install dependencies
cd sample-sagemaker-mlflow-rest-apis
npm ci

Em seguida, é necessário fazer o bootstrap do ambiente para o AWS CDK. Esse passo pode ser ignorado se a conta e a região AWS já estiverem configuradas para o CDK:

npx cdk bootstrap aws://<ACCOUNT_ID>/<REGION>

A solução é composta por quatro stacks CDK:

• Networking stack — cria a VPC e os componentes de rede.
• SageMaker AI domain stack — configura o domínio SageMaker.
• SageMaker MLflow stack — implanta o servidor de rastreamento ou o app serverless do MLflow.
• Flask application stack — implanta o serviço proxy MLflow.

Para implantar todas as stacks de uma vez, utilize um dos comandos abaixo conforme o modo desejado.

Para implantação baseada em tracking server:

npx cdk deploy --all --require-approval=never -c mlflowType=tracking

Para implantação baseada em app serverless:

npx cdk deploy --all --require-approval=never -c mlflowType=serverless

Etapa 2: Instalação e configuração do Flask MLflow Proxy Service

Após a implantação da infraestrutura, é necessário conectar à instância EC2. O ID da instância pode ser obtido na saída do CDK ou na seção de outputs da stack sagemaker-infra-flaskapp-{mlflowType} no AWS CloudFormation. A conexão deve ser feita pelo AWS Systems Manager Session Manager, seguindo o guia de conexão do Session Manager.

Com a sessão aberta, instale o Python 3.13 e as dependências:

# Switch to root user
sudo su -
cd /root

# Install Python and dependencies
chmod +x install_python13.sh
./install_python13.sh

O script foi desenvolvido para sistemas baseados em Ubuntu. Para outras distribuições Linux, é necessário instalar manualmente o Python 3.12+, PIP3 e Virtualenv usando o gerenciador de pacotes do sistema.

Em seguida, instale e inicie o serviço proxy MLflow:

chmod +x setup_mlflow_proxy_app.sh
./setup_mlflow_proxy_app.sh

Para verificar o status do serviço:

systemctl status mlflowproxy

Caso o serviço não esteja em execução, os logs podem ser consultados com o seguinte comando:

journalctl -u mlflowproxy

Etapa 3: Validação do acesso à REST API do MLflow

Com a solução implantada, é possível interagir com as REST APIs do MLflow por meio do ALB. Os exemplos abaixo utilizam o protocolo HTTP (sem segurança). Para ambientes de produção, a AWS recomenda o uso de HTTPS. As chamadas podem ser feitas com curl ou qualquer outra ferramenta de preferência — os comandos funcionam da mesma forma tanto para o modo tracking server quanto para o modo serverless.

Primeiro, obtenha o nome DNS do ALB com o seguinte comando na sua estação de trabalho:

aws cloudformation describe-stacks --stack-name sagemaker-infra-flaskapp-{mlflowType} --query 'Stacks[0].Outputs[?OutputKey==`ALBUrl`].OutputValue' --output text

Com o DNS em mãos, substitua <ALB DNS>, <EXP ID>, <RUN ID> e <RUN NAME> pelos valores correspondentes nos comandos abaixo.

Criar um experimento:

curl -X POST http://<ALB DNS>/ajax-api/2.0/mlflow/experiments/create -H "Content-Type: application/json" -d '{"name": "mlflow-experiment"}'

Buscar experimentos:

curl -X POST http://<ALB DNS>/ajax-api/2.0/mlflow/experiments/search -H "Content-Type: application/json" -d '{"max_results": 5}'

Obter um experimento:

curl -X GET 'http://<ALB DNS>/ajax-api/2.0/mlflow/experiments/get?experiment_id=0'

Criar uma execução dentro de um experimento:

curl -X POST http://<ALB DNS>/ajax-api/2.0/mlflow/runs/create -H "Content-Type: application/json" -d '{"experiment_id": <EXP ID>, "run_name": "<RUN NAME>"}'

Listar artefatos de uma execução:

curl -X GET "http://<ALB DNS>/ajax-api/2.0/mlflow/artifacts/list?run_id=<RUN ID>"

Definir uma tag em uma execução:

curl -X POST "http://<ALB DNS>/ajax-api/2.0/mlflow/runs/set-tag" -H "Content-Type: application/json" -d '{"run_id": "<RUN ID>", "key": "model_type","value": "api-test"}'

Excluir uma execução:

curl -X POST http://<ALB DNS>/ajax-api/2.0/mlflow/runs/delete -H "Content-Type: application/json" -d '{"run_id": "<RUN ID>"}'

Também é possível abrir a interface do MLflow para visualizar as alterações realizadas pelos comandos acima. Para instruções sobre como acessar a interface, consulte como iniciar a interface do MLflow usando uma URL pré-assinada.

Limpeza dos recursos

Para evitar cobranças contínuas, os recursos criados pela solução devem ser removidos. Para destruir as stacks gerenciadas pelo CDK, execute o comando adequado ao modo de implantação utilizado.

Para tracking server:

npx cdk destroy --all -c mlflowType=tracking

Para app serverless:

npx cdk destroy --all -c mlflowType=serverless

As stacks de rede e do domínio SageMaker são compartilhadas entre os modos de implantação e só serão removidas quando o último par de stacks MLflow/Flask for excluído. Além disso, alguns recursos podem exigir exclusão manual por conta de políticas de retenção ou dependências:

• Buckets Amazon S3: acesse o console do S3, identifique os buckets criados pela solução, esvazie-os e exclua-os.
• Grupos de logs do Amazon CloudWatch: no console do CloudWatch, localize e exclua os grupos de logs associados à solução.

Considerações de segurança para produção

Ao levar essa solução para um ambiente produtivo, a AWS recomenda uma série de medidas adicionais de segurança:

• Configure o monitoramento com Amazon CloudWatch para acompanhar a saúde da aplicação proxy, detectar anomalias e configurar alertas para atividades suspeitas.
• Implemente limitação de taxa (rate limiting) no serviço proxy Flask para proteção contra ataques de negação de serviço (DoS). O AWS WAF (firewall de aplicação web) pode ser usado junto ao ALB para implementar regras baseadas em taxa.
• Implante um ALB interno (não voltado para a internet) para restringir o acesso ao proxy apenas à rede privada, permitindo tráfego somente de dentro da VPC ou de redes conectadas via VPC Peering ou AWS Transit Gateway.
• Habilite o encerramento HTTPS no nível do ALB para comunicação segura entre clientes e a aplicação. O AWS Certificate Manager (ACM) pode ser usado para provisionar e gerenciar certificados SSL/TLS. Para detalhes sobre a configuração, consulte a documentação de listeners HTTPS do Application Load Balancer.

Conclusão

A solução apresentada pela AWS oferece uma forma prática de integrar o Amazon SageMaker MLflow com sistemas corporativos existentes, sem abrir mão dos padrões de segurança e infraestrutura já estabelecidos. O serviço proxy Flask atua como uma ponte entre o mundo HTTPS das aplicações empresariais e as APIs autenticadas da AWS, reduzindo a complexidade de implementação e permitindo que as equipes de ML continuem operando com seus fluxos de trabalho atuais.

Os principais benefícios da abordagem incluem integração com controles de segurança corporativos já existentes, mínimas alterações nos fluxos de trabalho de ML, menor complexidade de implantação, integração via REST API e compatibilidade com serviços de proxy corporativos.

Para aprofundar o conhecimento sobre o tema, a AWS disponibiliza a documentação do Amazon SageMaker MLflow, além de materiais sobre servidores de rastreamento MLflow e MLflow apps.

Fonte

Streamline external access to Amazon SageMaker MLflow using a REST API proxy (https://aws.amazon.com/blogs/machine-learning/streamline-external-access-to-amazon-sagemaker-mlflow-using-a-rest-api-proxy/)

Por que datasets de teste importam para agentes de IA

Agentes de IA são, por natureza, não determinísticos. O mesmo input pode gerar respostas diferentes entre execuções, o que torna um único resultado de avaliação praticamente sem valor. Sem inputs estáveis como base, é impossível saber se uma pontuação melhorou porque o agente ficou melhor — ou simplesmente porque o modelo amostrou de forma diferente naquela rodada.

Mas estabilidade de inputs sozinha não resolve tudo. Um juiz baseado em Modelo de Linguagem Grande (LLM) consegue dizer se uma resposta parece útil. Ele não consegue dizer se o preço da ação está correto, se o fluxo de ferramentas rodou na ordem certa ou se Informações de Identificação Pessoal (PII) vazaram entre sessões. Para essas verificações, é preciso ter ground truth: a resposta esperada, a sequência de ferramentas necessária e as asserções que precisam ser verdadeiras independentemente de como a resposta foi formulada.

Sem ground truth, você está medindo a aparência de correção — não a correção em si. Datasets versionados resolvem os dois problemas ao mesmo tempo: mantêm os inputs estáveis para que as pontuações sejam comparáveis entre execuções, e carregam o ground truth que dá significado a essas pontuações.

Os dois laços de avaliação de agentes

A avaliação de agentes acontece em dois contextos distintos, e cada um tem necessidades específicas.

O laço interno é a mesa do desenvolvedor. Você invoca o agente, lê as pontuações, ajusta a descrição de uma ferramenta e invoca de novo. O ciclo dura minutos. O problema não é rodar avaliações — é que os casos de teste tendem a ser o que estava à mão: perguntas escritas semana passada ou uma sessão que você salvou por acaso. Quando uma pontuação melhora, você quer acreditar que o ajuste funcionou. Mas sem inputs estáveis por baixo, não há como saber se o agente melhorou ou se as perguntas ficaram mais fáceis.

O laço externo é o pipeline de Integração Contínua/Entrega Contínua (CI/CD). Antes de uma mudança ir para produção, algo precisa garantir que nada quebrou. A maioria das equipes tem esse portão. O que elas frequentemente não têm é um conjunto estável e versionado de inputs com asserções explícitas. Isso significa que o portão está testando o que alguém apontou por último — sem ground truth para checar. Um pipeline que aprova um build porque as perguntas mudaram não está capturando regressões, está deixando-as passar.

Um dataset versionado fecha essa lacuna. O desenvolvedor cuida das falhas no laço interno. No laço externo, uma versão publicada desse dataset vira o portão: imutável, com ground truth intacto, testando os mesmos cenários do sprint passado e do anterior.

Dois tipos de cenários de teste

Os Datasets no Amazon Bedrock AgentCore suportam dois tipos de schema que atendem a esses dois laços de forma diferente.

Cenários predefinidos

São retrospectivos. Você já sabe exatamente quais queries o usuário vai enviar e sabe como é uma resposta correta: a resposta esperada, a sequência de ferramentas e as asserções que precisam ser verdadeiras. Você os escreve, e o avaliador verifica se o agente os atendeu. Uma vez que uma falha é formalizada como cenário predefinido, ela aparece em todas as execuções de avaliação futuras. Eles pertencem ao portão do laço externo porque os critérios de aprovação e reprovação são explícitos, repetíveis e não dependem de como a conversa aconteceu.

Cenários de simulação de usuário

São prospectivos. Em vez de roteirizar turnos, você descreve uma persona: quem é o ator, o que ele quer alcançar e como ele se comunica. Um ator baseado em LLM conduz uma conversa real de múltiplos turnos com o agente até que o objetivo seja atingido ou o limite de turnos seja alcançado. Você não roteiriza o que o ator diz — a cobertura emerge da interação. Para mais detalhes, consulte a documentação de Simulação de Usuário no guia do AgentCore.

A diferença é fundamental: um cenário predefinido testa se o agente lida corretamente com um input específico. Um cenário simulado testa se o agente consegue satisfazer um tipo de usuário, qualquer que seja o caminho que esse usuário tome. A simulação é especialmente útil no laço interno, quando você ainda não sabe quais modos de falha ainda não foram descobertos. As falhas que surgem se tornam candidatas a cenários predefinidos na próxima versão do dataset.

O agente de exemplo: Market Trends Agent

Para ilustrar o fluxo completo, a AWS usa o Market Trends Agent, uma aplicação LangGraph implantada no AgentCore Runtime. O agente atende corretores de investimento em instituições financeiras. Um corretor envia algo como “Sou Sarah Chen da Morgan Stanley, focada em tech e energia limpa — o que está acontecendo com a NVDA hoje?” O agente identifica o corretor, armazena suas preferências na memória do AgentCore, recupera o preço atual da ação e busca notícias relevantes. Quando Sarah volta no dia seguinte, o agente lembra o perfil dela e personaliza a resposta.

As ferramentas disponíveis no agente são:

• get_stock_data — preço atual, variação diária e volume para um ticker.
• search_news — busca de notícias financeiras em múltiplas fontes (Bloomberg, Reuters, CNBC, WSJ, FT).
• identify_broker — extrai a identidade do corretor da mensagem para consulta na memória.
• get_broker_financial_profile — lê preferências armazenadas, tolerância a risco e foco setorial.
• update_broker_financial_interests — grava novas preferências na memória de longo prazo.

Três modos de falha recorrentes justificam casos de teste permanentes: preços defasados (o agente cita um número que derivou mais de 2% do valor ao vivo por reutilizar uma resposta de ferramenta em cache), verificação de identidade ignorada (o agente pula direto para get_broker_financial_profile sem chamar identify_broker primeiro, podendo entregar o perfil do corretor errado) e vazamento de PII (informações pessoais de um corretor aparecem na resposta de uma sessão diferente).

Exemplo de cenário predefinido

PreDefinedScenario{
    "scenario_id": "broker_profile_onboarding",
    "turns": [
        {
            "input": (
                "Hi, I'm Sarah Chen from Morgan Stanley. "
                "I focus on tech and clean energy. "
                "Risk tolerance: moderate-high. "
                "Client base: institutional and high-net-worth."
            )
        }
    ],
    "expected_trajectory": {"toolNames": ["identify_broker", "update_broker_financial_interests"]},
    "assertions": [
        "Agent identifies the broker by name and firm.",
        "Agent stores the broker's sector preferences and risk tolerance.",
        "Agent acknowledges receipt of the profile and offers to help.",
    ],
    "metadata": {"category": "onboarding", "priority": "high"},
}

Exemplo de cenário simulado

Um analista sênior de tecnologia simulado pode abrir com uma pergunta ampla sobre NVDA. Ele pressiona quando a resposta parece rasa, pede uma comparação com AMD e só sinaliza conclusão quando tem algo citável para uma ligação com cliente. Ninguém roteirizou esses turnos — o ator os gerou a partir do perfil.

SimulatedScenario(
    scenario_id="sim-tech-analyst-nvda-amd-deep-dive",
    scenario_description=(
        "A senior technology research analyst probes for a deep, citable NVDA vs AMD briefing ahead of a client call."
    ),
    actor_profile=ActorProfile(
        traits={
            "expertise": "senior",
            "focus": "semiconductors",
            "style": "skeptical and data-driven",
        },
        context=(
            "Senior sell-side technology analyst preparing talking points for a high-value client call. "
            "Expects multi-layered analysis, not surface-level summaries, and will push back when answers feel generic or thin."
        ),
        goal=(
            "Pressure-test the agent's semiconductor domain depth by asking about NVIDIA, then insisting on richer detail, "
            "requesting a structured comparison with AMD, and only concluding when she has citable points for a client conversation."
        ),
    ),
    input=(
        "I'm prepping for a client call and need a quick but solid briefing on NVIDIA. "
        "Start with NVDA's recent performance and positioning in semiconductors."
    ),
    max_turns=8,
    assertions=[
        "Agent provides an initial NVDA summary with recent performance and positioning",
        "Agent responds with deeper fundamentals, product/roadmap, or moat detail for NVDA",
        "Agent produces a structured NVDA vs AMD comparison (e.g., valuation, growth, segments)",
        "Agent includes specific, citable data points or metrics suitable for a client call"
    ],
)

Vale destacar como a simulação funciona internamente: o ator roda em um modelo do Bedrock especificado em SimulationConfig. A cada turno, o ator recebe a resposta do agente e produz três elementos — seu raciocínio interno sobre se o objetivo foi atingido, a próxima mensagem a enviar e um sinal de parada. A conversa termina quando o ator sinaliza conclusão, quando max_turns é atingido ou quando o ator não produz próxima mensagem. Como o caminho da conversa é dinâmico, cenários simulados não suportam expected_trajectory nem expected_response por turno — use asserções para o ground truth.

Como os datasets funcionam no AgentCore

Os datasets são recursos de primeira classe no AgentCore, com ARNs (Nomes de Recurso da Amazon), autorização via Gerenciamento de Identidade e Acesso (IAM) e tags. Não é necessário provisionar buckets no Amazon Simple Storage Service (Amazon S3) nem configurar serviços externos.

O fluxo de trabalho segue três princípios principais:

• Rascunho e publicação: cada dataset tem um rascunho mutável onde você adiciona e remove cenários livremente. Quando quiser um checkpoint estável, publique. O rascunho vira uma versão numerada imutável. Fixe uma execução de avaliação na Versão 3 e ela usará exatamente os cenários que estavam na Versão 3, independentemente do que você adicionou ao rascunho depois.
• Validação de schema na gravação: você declara o tipo de schema ao criar o dataset, e cada cenário é validado contra esse schema antes de ser aceito. Exemplos malformados são rejeitados na ingestão, e não no meio de uma execução de avaliação de 30 minutos.
• Um dataset, múltiplos executores: carregue um dataset com DatasetManagementServiceProvider e passe para o executor sob demanda (feedback rápido por cenário) ou para o executor em lote (pontuação agregada em muitas sessões). Os mesmos cenários, asserções e ID de dataset funcionam tanto na iteração local quanto no portão de deployment.

Passo a passo da implementação

O walkthrough completo leva cerca de 30 minutos. Os pré-requisitos são: uma conta AWS com permissões para AgentCore Runtime, Memory, Evaluations e Amazon CloudWatch; AWS Command Line Interface (AWS CLI) configurado; CloudWatch Transaction Search habilitado (opt-in único por conta); e o repositório de amostras clonado com o Market Trends Agent implantado via uv run python deploy.py. O código completo está disponível no repositório de amostras do AgentCore.

O fluxo de trabalho sugerido pela AWS segue estas etapas:

• Implantar o agente: execute uv run python deploy.py para provisionar o AgentCore Runtime, Memory, papel IAM e container ECR. O ARN do agente é gravado em .agent_arn.
• Criar e versionar os datasets: execute uv run python optimization/manage_dataset.py --no-cleanup para criar dois datasets e publicar uma versão imutável de cada. O dataset predefinido inclui cinco casos de teste roteirizados cobrindo os modos de falha principais. O dataset simulado inclui três cenários de persona de ator. O script também demonstra o fluxo de curadoria do dia a dia: adicionar novos exemplos, atualizar os existentes e excluir casos obsoletos antes de publicar.
• Executar a avaliação: execute uv run python optimization/user_simulated_dataset.py para carregar os cenários simulados, invocar o agente contra cada um e aguardar os spans chegarem no CloudWatch. O script então submete uma avaliação em lote com Correção, Utilidade e Taxa de Sucesso de Objetivo. Pontuações e explicações por cenário são impressas no console.
• Iterar — corrigir e reavaliar: atualize a descrição da ferramenta ou o prompt do sistema com base nas explicações da avaliação. Adicione o novo caso de borda ao rascunho com add_examples_and_wait(), publique uma nova versão com create_dataset_version_and_wait() e execute novamente. Como os cenários e asserções são idênticos entre execuções, a comparação antes/depois isola o efeito da sua mudança. Alternativamente, é possível usar as recomendações diretas do AgentCore via optimize_agent.py, que usa o avaliador como sinal e sugere melhorias no prompt do sistema e nas descrições de ferramentas.

Após concluir esses passos, o dataset persiste como recurso gerenciado na conta AWS. Jobs de avaliação futuros podem referenciar o mesmo ID de dataset e versão — seja disparados da máquina do desenvolvedor, de um pipeline CI/CD ou de uma verificação de regressão agendada.

Modos de uso: sob demanda vs. em lote

Use o executor sob demanda quando precisar de feedback imediato por cenário durante o desenvolvimento em datasets menores, gerenciando a concorrência você mesmo. Use o executor em lote para medir qualidade agregada em um dataset grande ou comparar duas versões do agente em escala.

Para portões de deployment, fixe a avaliação em uma versão publicada e reprove o build se qualquer avaliador cair abaixo do seu limiar. Como a versão é imutável, o portão testa os mesmos cenários em cada Pull Request, independentemente do que foi adicionado ao rascunho desde então.

O mesmo dataset versionado também alimenta a otimização do AgentCore. Quando você usa a API de Recomendações para gerar prompts de sistema ou descrições de ferramentas melhorados, as pontuações de avaliação que embasam essas decisões estão ancoradas no seu dataset. O mesmo vale para testes A/B que validam essas melhorias contra tráfego real. Inputs estáveis tornam o laço de otimização confiável, em vez de ser um efeito colateral de um conjunto de testes em constante mudança.

Boas práticas para adotar desde cedo

• Baseie a suíte em incidentes reais: os cenários que mais capturam problemas são os originados de falhas reais de produção. Perguntas inventadas testam falhas imaginárias.
• Use predefinidos para profundidade, simulados para amplitude: cenários predefinidos protegem os bugs já encontrados. Cenários simulados revelam os que ainda não foram. Um dataset saudável inclui os dois tipos.
• Publique uma versão antes de cada mudança: versões são imutáveis e não custam nada para manter. Quando você estiver depurando uma regressão de pontuação meses depois, vai querer saber exatamente quais cenários estavam em jogo em cada checkpoint.
• Um dataset, muitas versões: resista à tentação de criar um novo dataset a cada sprint. O valor está na continuidade. O mesmo ID de dataset acumula cada falha que o agente já teve, e cada avaliação futura herda esse histórico. Criar um novo dataset significa começar do zero.

Conclusão

Uma suíte de testes só é útil se permanecer estável. Quando os inputs mudam entre execuções, as pontuações medem a deriva do conjunto de testes — não a melhoria do agente. O gerenciamento de datasets no AgentCore entrega casos de teste versionados e validados por schema como recurso gerenciado. Falhas de produção viram cenários de regressão permanentes, personas simuladas geram cobertura que ninguém conseguiria roteirizar manualmente, e versões imutáveis permitem comparações honestas entre releases do agente.

O bug de preço que um corretor reportou no trimestre passado agora é um caso de teste. Cada mudança no prompt do sistema, cada atualização de descrição de ferramenta e cada troca de modelo é avaliada contra ele. A suíte acumula o conhecimento institucional sobre como o agente já falhou — e responsabiliza todas as versões futuras por essa história.

Para começar, consulte a documentação do Amazon Bedrock AgentCore e o exemplo do Market Trends Agent.

Fonte

Build a test suite that grows with your agent with dataset management in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-a-test-suite-that-grows-with-your-agent-with-dataset-management-in-amazon-bedrock-agentcore/)

O que foi anunciado

A AWS anunciou a expansão do suporte a resumos pós-atendimento com Inteligência Artificial (IA) generativa no Amazon Connect para oito novos grupos de idiomas: português, francês, italiano, alemão, espanhol, chinês, japonês e coreano. Além disso, o recurso passou a contemplar variações regionais do inglês além do americano — incluindo o inglês britânico, o australiano e outros dialetos locais — garantindo que os resumos reflitam a ortografia e a terminologia adequadas para cada região.

Como funcionam os resumos pós-atendimento

Os resumos pós-atendimento com IA generativa do Amazon Connect entregam visões gerais concisas e estruturadas das conversas com clientes, abrangendo os canais de voz, chat e e-mail. O objetivo é eliminar a necessidade de leitura integral das transcrições — tanto para os agentes que precisam registrar o atendimento quanto para os gestores que acompanham a qualidade do serviço.

Com a expansão para novos idiomas, as organizações passam a gerar automaticamente os resumos no idioma em que a conversa foi conduzida. Isso agiliza o trabalho pós-atendimento dos agentes e facilita a revisão de contatos em múltiplos idiomas por parte dos supervisores.

Exemplo prático de uso

Uma organização de suporte global, por exemplo, pode agora gerar resumos pós-atendimento para chamadas realizadas em francês, alemão ou japonês — dando aos supervisores visibilidade sobre a qualidade do serviço em todas as regiões atendidas, sem depender de tradução manual ou leitura de transcrições extensas.

Disponibilidade

Os idiomas recém-suportados estão disponíveis em todas as Regiões da AWS onde os resumos pós-atendimento do Amazon Connect já estavam habilitados. Não há restrição de região específica para acessar a novidade — basta estar em uma região que já suportava o recurso anteriormente.

Saiba mais

Para se aprofundar na configuração e no uso do recurso, a AWS disponibiliza documentação oficial. Você pode consultar o guia Visualizar resumos pós-atendimento com IA generativa no Guia do Administrador do Amazon Connect. Para uma visão geral completa do serviço, acesse o site oficial do Amazon Connect.

Fonte

Amazon Connect Customer expands generative AI-powered post-contact summaries to eight new languages (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-connect-summary-languages/)

O desafio de processar documentos financeiros em escala

Instituições financeiras lidam diariamente com milhares de documentos: extratos bancários, declarações de imposto de renda, ordens de compra, contratos de fornecedores. Cada um tem formato, estrutura e nomenclatura de campos próprios — o que torna extremamente difícil criar fluxos de automação usando apenas ferramentas tradicionais de Reconhecimento Óptico de Caracteres (OCR).

Para endereçar esse problema, a AWS disponibilizou o Amazon Bedrock Data Automation (BDA), um serviço que automatiza a extração, validação e análise de dados a partir de documentos. A diferença em relação ao OCR convencional está no uso de modelos de fundação, que conseguem:

• Compreender o contexto do documento como um todo
• Reconhecer relações entre diferentes seções
• Extrair dados estruturados e acionáveis
• Validar informações cruzando múltiplas fontes

Embora modelos de fundação como o Anthropic Claude já consigam extrair conteúdo de PDFs, o Amazon Bedrock Data Automation oferece extrações personalizadas com alta precisão e custo reduzido, além de recursos como ancoragem visual com pontuações de confiança para explicabilidade e mitigação integrada de alucinações.

Como o BDA funciona: blueprints como ponto central

O conceito principal do Amazon Bedrock Data Automation é o blueprint — um modelo de configuração que define como os dados devem ser extraídos de um determinado tipo de documento. Pense nele como um mapa que instrui o BDA sobre quais informações buscar e como organizá-las na saída.

Um blueprint especifica:

• O tipo de documento sendo processado
• Os campos de dados a serem extraídos
• As regras de validação dos dados extraídos
• A estrutura e o formato da saída

O serviço oferece dois tipos de blueprints: os de catálogo (pré-configurados pela AWS para tipos comuns de documentos) e os blueprints personalizados, que permitem às organizações criar padrões de extração adaptados às suas necessidades específicas. A saída pode ser exportada nos formatos JSON, CSV e dados brutos.

Pré-requisitos para começar

Para reproduzir os exemplos apresentados pela AWS, são necessários:

• Uma conta AWS ativa com as permissões de Gerenciamento de Identidade e Acesso (IAM) adequadas — há uma política de exemplo disponível no workshop do BDA
• Acesso aos modelos de fundação habilitado no console da AWS
• Configuração do Amazon Bedrock Data Automation seguindo o guia de introdução ao Amazon Bedrock
• Documentos financeiros de exemplo para testes

Para quem não está familiarizado com a criação de blueprints personalizados, a AWS disponibiliza instruções detalhadas na documentação do Amazon Bedrock.

Quatro tipos de documentos financeiros na prática

A AWS demonstrou a aplicação do BDA em quatro categorias de documentos financeiros, usando blueprints personalizados em cada caso. Vale destacar que, para extratos bancários e formulários W-2, o BDA já conta com blueprints de catálogo prontos para uso — os blueprints personalizados foram utilizados aqui para ilustrar como as organizações podem adaptar a extração às suas necessidades específicas de fluxo de trabalho.

1. Extratos bancários

Extratos bancários apresentam um desafio considerável: contêm dezenas de transações mensais, frequentemente distribuídas em várias páginas, com formatos e detalhes variados. Em muitos fluxos de trabalho, o que importa é capturar com precisão os dados de cada transação — data, valor, descrição e número de referência — para alimentar sistemas de contabilidade automatizados, como a categorização de transações em um razão contábil.

Para esse tipo de documento, o blueprint personalizado foi estruturado com um campo principal chamado Transactions, composto por um tipo customizado TRANSACTION_DETAILS contendo os campos: Date, Description, Debit (número) e Credit (número). O resultado da extração confirmou que o sistema capturou todas as transações com precisão, gerando um arquivo table.csv pronto para integração downstream.

2. Formulário W-2

O formulário W-2 é um documento fiscal norte-americano que reporta renda e impostos retidos para pessoas físicas ou jurídicas. Apesar de ter uma estrutura padronizada, ele apresenta complexidades específicas de extração que foram especialmente verificadas no experimento da AWS:

• Não há agrupamento explícito entre informações de imposto federal e estadual no formulário, mas elas precisam ser processadas em conjunto — o blueprint resolve isso estruturando os dados de forma lógica na saída.
• O campo Box 12 pode conter até 26 códigos para reportar diferentes tipos de remuneração e benefícios. É fundamental extrair código e valor como um par.
• O campo Box 14 é de uso livre pelos empregadores, servindo para itens sem campo dedicado no W-2 — esses dados devem ser agrupados separadamente.

O blueprint customizado criado para o W-2 organizou os dados em sete tipos personalizados: EmployerInfo, EmployeeInfo, FederalWageInfo, FederalTaxInfo, StateTaxInfo, CodeAmount e FilingInfo. O resultado foi exportado em result.json, com todos os campos extraídos corretamente.

3. Formulário IRS 1099-B

O formulário 1099-B é um documento fiscal norte-americano que registra transações de valores mobiliários, operações intermediadas por corretoras e participações em bolsas de permuta. Por não ter um blueprint de catálogo disponível no BDA, ele é um exemplo claro de caso de uso para blueprints personalizados.

O blueprint criado para o 1099-B utilizou um tipo customizado TRANSACTION_DETAILS com os campos: security_description, quantity_sold, date_acquired, date_sold_or_disposed, proceeds, cost_or_other_basis, gainloss_amount e additional_information.

Um resultado relevante destacado pela AWS foi a capacidade do BDA de manter precisão contextual ao longo do documento: o sistema identificou e extraiu corretamente o ticker TSLA como descritor comum para um grupo de transações de ações, mesmo quando esse identificador aparecia como um descritor compartilhado entre múltiplas linhas — demonstrando a compreensão contextual do modelo, além da simples leitura de campos.

4. Contratos de fornecedores

Contratos de fornecedores são documentos altamente variáveis — cada empresa tem seus próprios requisitos operacionais e campos relevantes. Por isso, o blueprint precisa ser adaptado caso a caso.

No experimento da AWS, o blueprint criado para contratos de consultoria estruturou os dados em três tipos personalizados principais:

• PARTICIPANT_DETAILS: nome do participante e representante autorizado
• PARTICIPANT_REQUIREMENTS: recursos alocados, obrigações e restrições do participante
• TERM_AND_TERMINATION: prazo do contrato e condições de rescisão

Além desses, o blueprint incluiu campos para data de vigência, período de duração e obrigações de confidencialidade. O sistema identificou e extraiu corretamente todos os elementos especificados no blueprint a partir do contrato de teste.

Considerações para uso em produção

Um ponto importante destacado pela AWS: um único blueprint geralmente é suficiente para um tipo específico de documento quando os campos extraídos são consistentes. No entanto, se os requisitos do fluxo de trabalho variarem ou os formatos dos documentos mudarem significativamente, pode ser necessário criar múltiplos blueprints para cobrir essas diferenças.

Como a saída do BDA é sempre JSON estruturado, é direto criar regras para processamento downstream — por exemplo, descartar totais quando o fluxo de trabalho precisa apenas categorizar transações individuais de débito e crédito para fins contábeis.

Para fluxos de trabalho em produção que envolvam informações sensíveis, a AWS recomenda seguir as diretrizes de cibersegurança e jurídicas da organização, verificando a conformidade com todas as regulamentações aplicáveis — incluindo o Regulamento Geral sobre a Proteção de Dados (RGPD/GDPR) na Europa e outras normas regionais ou setoriais relevantes.

Conclusão

O Amazon Bedrock Data Automation representa uma evolução significativa em relação ao OCR tradicional para o processamento de documentos financeiros. Ao combinar modelos de fundação com blueprints configuráveis, o serviço consegue extrair dados estruturados de documentos complexos — como extratos bancários, formulários fiscais e contratos — com precisão e de forma adaptável aos diferentes fluxos de trabalho de cada organização.

Para quem quiser se aprofundar, a AWS disponibiliza a documentação completa do Amazon Bedrock Data Automation com detalhes sobre implementação em ambientes produtivos.

Fonte

Process financial documents using Amazon Bedrock Data Automation (https://aws.amazon.com/blogs/machine-learning/process-financial-documents-using-amazon-bedrock-data-automation/)

O que mudou no Amazon Bedrock

A AWS anunciou uma expansão no suporte do Amazon Bedrock ao AWS Service Quotas, o serviço centralizado de gerenciamento de cotas da plataforma. A partir de agora, os clientes conseguem visualizar as cotas de inferência do endpoint bedrock-mantle diretamente pelo console de Service Quotas — da mesma forma que já faziam com o endpoint bedrock-runtime e outros serviços da AWS.

Na prática, isso significa que equipes de engenharia e arquitetura ganham uma visão clara e padronizada dos limites que se aplicam às suas cargas de trabalho no Bedrock, sem precisar consultar documentação separada ou abrir chamados para descobrir qual é o teto de requisições disponível.

O que é o endpoint bedrock-mantle

O bedrock-mantle é o endpoint do Amazon Bedrock que oferece compatibilidade com três APIs amplamente utilizadas no mercado de Inteligência Artificial (IA) generativa:

• OpenAI Responses API
• OpenAI Chat Completions API
• Anthropic Messages API

Essa compatibilidade permite que times que já possuem aplicações construídas sobre OpenAI ou Anthropic migrem para o Amazon Bedrock com mudanças mínimas no código. É uma porta de entrada direta para quem quer aproveitar a infraestrutura gerenciada da AWS sem reescrever integrações do zero.

O que ficou visível com esta atualização

Com a expansão do suporte a Service Quotas, o endpoint bedrock-mantle passa a expor, por modelo, as seguintes cotas:

• Tokens de entrada por minuto (input-tokens-per-minute)
• Tokens de saída por minuto (output-tokens-per-minute)

Essa granularidade por modelo é especialmente útil para equipes que trabalham com múltiplos modelos de fundação simultaneamente e precisam planejar a capacidade de cada um de forma independente.

Como acessar as cotas no console

O acesso é simples e segue o fluxo padrão do AWS Service Quotas:

• Abra o console do AWS Service Quotas
• Selecione Amazon Bedrock
• Pesquise por “Bedrock Mantle” para visualizar as cotas disponíveis

Para solicitar aumento de qualquer uma dessas cotas, basta seguir o processo padrão de aumento de limites do Amazon Bedrock.

Disponibilidade por região

O suporte a Service Quotas para o endpoint bedrock-mantle está disponível em todas as regiões da AWS onde o endpoint é oferecido:

• EUA Leste: Norte da Virgínia, Ohio
• EUA Oeste: Oregon
• Ásia-Pacífico: Mumbai, Tóquio, Sydney, Jacarta
• Europa: Frankfurt, Irlanda, Londres, Milão, Estocolmo
• América do Sul: São Paulo

Para o público brasileiro, vale destacar a presença da região de São Paulo, o que garante baixa latência para aplicações hospedadas localmente.

Por que isso importa

Ter visibilidade de cotas de forma proativa é fundamental para quem opera em escala de produção. Sem esse tipo de informação, equipes costumam descobrir os limites apenas quando os erros começam a aparecer — o que pode significar interrupções inesperadas em aplicações críticas. Com essa atualização, o Amazon Bedrock se alinha ao padrão já consolidado de outros serviços da AWS, tornando o planejamento de capacidade mais previsível e menos reativo.

Para mais detalhes técnicos sobre os limites disponíveis, consulte a documentação de cotas do Amazon Bedrock.

Fonte

Amazon Bedrock expands support for Service Quotas (https://aws.amazon.com/about-aws/whats-new/2026/5/amazon-bedrock-service-quotas/)