Blog

O problema: levar um modelo à produção leva semanas

Organizações estão correndo para colocar modelos de IA generativa em produção — seja para assistentes inteligentes, ferramentas de geração de código, motores de conteúdo ou aplicações voltadas ao cliente. Mas o processo de implantação continua sendo um obstáculo real: encontrar a combinação certa de tipo de instância GPU, contêiner de serving, estratégia de paralelismo e técnicas de otimização pode consumir de duas a três semanas por modelo, exigindo expertise em infraestrutura de GPU que a maioria das equipes simplesmente não tem internamente.

O espaço de decisão é enorme. Uma única implantação envolve escolher entre mais de uma dúzia de tipos de instância GPU, múltiplos contêineres de serving, diferentes graus de paralelismo e um conjunto crescente de técnicas como o speculative decoding. Todas essas variáveis interagem entre si, e não havia orientação validada para estreitar a busca.

O resultado costuma ser o mesmo: equipes provisionam instâncias, implantam o modelo, rodam testes de carga, analisam resultados e repetem o ciclo. Sem clareza sobre se existe uma opção melhor e mais econômica, muitas acabam superprovisionando — escolhendo infraestrutura de GPU mais cara do que o necessário. O custo desperdiçado se acumula a cada modelo implantado e a cada mês que o endpoint fica ativo.

A solução: recomendações otimizadas de inferência no SageMaker AI

A AWS anunciou que o Amazon SageMaker AI agora suporta recomendações otimizadas de inferência para IA generativa. O recurso entrega configurações de implantação validadas com métricas de desempenho reais, permitindo que as equipes se concentrem em construir modelos precisos — e não em gerenciar infraestrutura.

Para o benchmarking, a AWS avaliou diversas ferramentas e optou pelo NVIDIA AIPerf, um componente modular do NVIDIA Dynamo, por expor métricas detalhadas e consistentes, suportar cargas de trabalho diversas e oferecer controles de concorrência e opções de dataset que facilitam iterações rápidas com configuração mínima.

Segundo Eliuth Triana, Gerente de Relações com Desenvolvedores da NVIDIA: “Com a integração de componentes modulares do framework de inferência distribuída open source NVIDIA Dynamo diretamente no Amazon SageMaker AI, a AWS está tornando mais fácil para empresas implantarem modelos de IA generativa com confiança. A integração do NVIDIA AIPerf demonstra como o benchmarking padronizado pode eliminar semanas de testes manuais e entregar configurações validadas e prontas para produção aos usuários finais.”

Como funciona o processo em três etapas

O fluxo é direto: você traz seu modelo de IA generativa, define os padrões de tráfego esperados e especifica um único objetivo de desempenho — otimizar custo, minimizar latência ou maximizar throughput. A partir daí, o SageMaker AI assume o controle em três estágios.

Etapa 1: Redução do espaço de configurações

O SageMaker AI analisa a arquitetura do modelo, seu tamanho e requisitos de memória para identificar os tipos de instância e estratégias de paralelismo que podem realisticamente atingir o objetivo definido. Em vez de testar todas as combinações possíveis, o serviço estreita a busca para as configurações que valem a pena avaliar — considerando até três tipos de instância selecionados pelo usuário.

Etapa 2: Aplicação de otimizações alinhadas ao objetivo

Com base no objetivo de desempenho escolhido, o SageMaker AI aplica automaticamente as técnicas de otimização mais adequadas a cada configuração candidata:

• Para objetivos de throughput: treina modelos de speculative decoding (como o EAGLE 3.0), que permitem ao modelo gerar múltiplos tokens por passagem de avanço, aumentando significativamente os tokens por segundo.
• Para objetivos de latência: ajusta kernels de computação para reduzir o tempo de processamento por token, diminuindo o tempo até o primeiro token (TTFT — Time to First Token).
• Paralelismo tensorial é aplicado com base no tamanho do modelo e na capacidade da instância, distribuindo o modelo entre as GPUs disponíveis para lidar com modelos que excedem a memória de uma única GPU.

Não é necessário saber qual técnica é a mais adequada para cada objetivo — o SageMaker AI seleciona e aplica as otimizações automaticamente.

Etapa 3: Benchmarking e retorno de recomendações ranqueadas

O SageMaker AI faz o benchmarking de cada configuração otimizada em infraestrutura GPU real usando o NVIDIA AIPerf, medindo TTFT, latência entre tokens (ITL — Inter-Token Latency), latência de requisição nos percentis P50/P90/P99, throughput e custo. O resultado é um conjunto de recomendações ranqueadas e prontas para implantação, com métricas validadas para cada configuração e tipo de instância.

O fluxo de trabalho na prática

Do ponto de vista do usuário, o processo via APIs do SageMaker AI segue estas etapas:

• Prepare seu modelo: traga o modelo generativo a partir do Amazon S3 (Serviço de Armazenamento Simples) ou do SageMaker Model Registry, incluindo checkpoints do Hugging Face com pesos SafeTensor, modelos base e modelos customizados ou ajustados com seus próprios dados.
• Defina sua carga de trabalho (opcional): descreva os padrões de tráfego esperados, incluindo distribuições de tokens de entrada e saída e níveis de concorrência. Você pode fornecer essas informações diretamente ou usar um dataset representativo do Amazon S3.
• Defina seu objetivo de otimização: escolha um único objetivo — otimizar custo, minimizar latência ou maximizar throughput — e selecione até três tipos de instância para comparar.
• Revise as recomendações ranqueadas: o SageMaker AI retorna configurações prontas para implantação com métricas validadas como TTFT, latência entre tokens, latência de requisição nos percentis P50/P90/P99, throughput e projeções de custo.
• Implante a configuração escolhida: implante a configuração selecionada em um endpoint de inferência do SageMaker de forma programática via API.

Adicionalmente, é possível fazer benchmarking de endpoints de produção existentes para validar o desempenho atual ou compará-los com novas configurações. O SageMaker AI pode utilizar Reservas de ML existentes (Flexible Training Plans) sem custo adicional de computação, ou provisionar instâncias sob demanda automaticamente.

Rigor no benchmarking com NVIDIA AIPerf

Cada recomendação gerada pelo SageMaker AI é baseada em medições reais — não em estimativas ou simulações. Internamente, o serviço usa o NVIDIA AIPerf, uma ferramenta open source de benchmarking que mede métricas-chave de inferência: TTFT, latência entre tokens, throughput e requisições por segundo.

A AWS contribuiu diretamente para o AIPerf com melhorias que fortalecem a base estatística dos resultados. Essas contribuições incluem:

• Relatório de confiança multi-execução: permite medir a variância entre execuções repetidas do benchmark e quantificar a qualidade dos resultados com intervalos de confiança estatisticamente fundamentados — indo além de números frágeis de execução única.
• Convergência adaptativa e parada antecipada: os benchmarks param assim que as métricas se estabilizam, em vez de sempre rodar um número fixo de tentativas. Isso reduz o custo de benchmarking e acelera o tempo até os resultados sem sacrificar o rigor.

Otimizações em ação: exemplo real

Para ilustrar o impacto prático, considere um exemplo concreto. Um cliente implantando o GPT-OSS-20B em uma única instância ml.p5en.48xlarge (H100) seleciona “maximizar throughput” como objetivo de desempenho. O SageMaker AI identifica o speculative decoding como a otimização adequada para esse objetivo, treina um modelo rascunho EAGLE 3.0, aplica-o à configuração de serving e faz o benchmarking tanto da linha de base quanto da configuração otimizada em infraestrutura GPU real.

O resultado: após a otimização de throughput, a mesma instância entrega 2x mais tokens/s com 1.000ms de latência — o que significa servir o dobro de usuários no mesmo hardware, efetivamente reduzindo o custo de inferência por token pela metade. Essa é exatamente a otimização que o SageMaker AI aplica automaticamente quando o objetivo de throughput é selecionado, sem que o usuário precise saber qual técnica usar, como treinar um modelo rascunho ou como configurá-lo para o modelo e hardware específicos.

Casos de uso

• Validação pré-implantação: otimize e faça benchmarking de um novo modelo antes de comprometer com uma implantação em produção.
• Teste de regressão após atualizações: valide o desempenho após uma atualização de contêiner, upgrade de framework ou nova versão de biblioteca de serving.
• Redimensionamento quando as condições mudam: quando os padrões de tráfego mudam ou novos tipos de instância ficam disponíveis, reexecute as recomendações em horas em vez de reiniciar um processo manual de semanas.
• Comparação de modelos: compare desempenho e custo de diferentes variantes de modelo entre tipos de instância para fazer uma seleção informada antes da implantação em produção.
• Otimização de custos: faça benchmarking de endpoints de produção existentes para identificar infraestrutura superprovisionada e reduzir gastos recorrentes com inferência.

Implantando a partir das recomendações

Após a conclusão do job de recomendação, o resultado é um SageMaker Model Package — um recurso versionado que agrupa todas as configurações de implantação específicas por instância em um único artefato. Para implantar, é necessário converter o Model Package em um Deployable Model chamando CreateModel com o ModelPackageName e o InferenceSpecificationName para a instância desejada, depois criar uma configuração de endpoint e implantar como um endpoint de tempo real padrão do SageMaker ou como um Inference Component.

Um único Recommendation Job produz um Model Package com múltiplas InferenceSpecifications — uma por tipo de instância avaliado — permitindo escolher a configuração que melhor atende ao objetivo de latência, throughput ou custo e implantá-la diretamente sem reexecutar o job.

O código abaixo ilustra o fluxo completo, exatamente como documentado pela AWS:

# Selecionar a recomendação desejada
resp = client.describe_ai_recommendation_job(
    AIRecommendationJobName="my-recommendation-job"
)
rec = resp["Recommendations"][0]
model_package_arn = rec["ModelDetails"]["ModelPackageArn"]
inference_spec_name = rec["ModelDetails"]["InferenceSpecificationName"]
instance_type = rec["InstanceDetails"][0]["InstanceType"]

print(f"Model Package : {model_package_arn}")
print(f"Inference Spec: {inference_spec_name}")
print(f"Instance Type : {instance_type}")

# Converter Model Package → Deployable Model
sm.create_model(
    ModelName="oss20b-deployable-model",
    ModelPackageName=model_package_arn,
    InferenceSpecificationName=inference_spec_name,
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerExecutionRole",
)

# Criar configuração de endpoint
sm.create_endpoint_config(
    EndpointConfigName="oss20b-endpoint-config",
    ProductionVariants=[
        {
            "VariantName": "AllTraffic",
            "ModelName": "oss20b-deployable-model",
            "InstanceType": instance_type,
            "InitialInstanceCount": 1,
        }
    ],
)

# Implantar e aguardar
sm.create_endpoint(
    EndpointName="oss20b-endpoint",
    EndpointConfigName="oss20b-endpoint-config",
)

Saídas do benchmarking

Um job de benchmarking de IA executa testes de desempenho contra endpoints de inferência do SageMaker AI usando uma configuração de carga de trabalho predefinida. Ao concluir, os resultados são armazenados no caminho de saída do Amazon S3 especificado. Após extrair o arquivo zip de saída, a estrutura de arquivos gerada inclui:

• profile_export_aiperf.json e profile_export_aiperf.csv: métricas agregadas, incluindo percentis de latência (P50, P90, P99), throughput de tokens de saída, TTFT e ITL.
• profile_export.jsonl: dados brutos por requisição — cada requisição individual registrada com sua própria latência, contagem de tokens e timestamp, útil para análises próprias ou identificação de outliers.
• inputs.json: prompts enviados durante a execução.
• benchmark_summary.txt: resumo de conclusão.
• plots/: visualizações incluindo linha do tempo de TTFT por requisição e TTFT agregado ao longo da execução.
• logs/aiperf.log: log completo de execução do AIPerf.

A AWS disponibilizou um notebook de exemplo no GitHub que faz benchmarking do modelo openai/gpt-oss-20b implantado em uma instância ml.g6.12xlarge (4× GPUs NVIDIA L40S), servido via contêiner vLLM como Inference Component. O notebook simula uma carga de trabalho realista com prompts sintéticos: 300 requisições com 10 usuários concorrentes, aproximadamente 500 tokens de entrada e 150 de saída por requisição.

Preços e disponibilidade

Não há custo adicional para gerar as recomendações otimizadas de inferência para IA generativa. Os clientes incorrem nos custos padrão de computação para os jobs de otimização que geram as configurações otimizadas e para os endpoints provisionados durante o benchmarking. Clientes com Reservas de ML existentes (Flexible Training Plans) podem executar o benchmarking em sua capacidade reservada sem custo adicional — o único custo é o próprio job de otimização.

O recurso está disponível hoje em sete regiões AWS: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Leste dos EUA (Ohio), Ásia-Pacífico (Tóquio), Europa (Irlanda), Ásia-Pacífico (Cingapura) e Europa (Frankfurt). O acesso é feito pelas APIs do SageMaker AI. Para detalhes de implementação, walkthroughs de API e exemplos de código, consulte a documentação do SageMaker AI e os notebooks de exemplo no GitHub.

Fonte

Amazon SageMaker AI now supports optimized generative AI inference recommendations (https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-ai-now-supports-optimized-generative-ai-inference-recommendations/)

Novos modelos Qwen disponíveis no SageMaker JumpStart

A AWS anunciou a chegada de cinco novos modelos da família Qwen ao Amazon SageMaker JumpStart, expandindo o portfólio de modelos de fundação disponíveis na plataforma. Os modelos incorporados são: Qwen3-Coder-Next, Qwen3-30B-A3B, Qwen3-30B-A3B-Thinking-2507, Qwen3-Coder-30B-A3B-Instruct e Qwen3.5-4B.

Cada um deles foi desenvolvido para atender a desafios específicos de Inteligência Artificial (IA) empresarial, cobrindo casos de uso que vão de codificação agêntica a compreensão multimodal — tudo rodando sobre a infraestrutura da AWS.

O que cada modelo oferece

Os cinco modelos têm perfis bem distintos entre si. Entender as diferenças ajuda a escolher o mais adequado para cada projeto:

• Qwen3-Coder-Next: focado em raciocínio de longo horizonte, uso complexo de ferramentas e recuperação de falhas durante a execução. É indicado para alimentar agentes de codificação em plataformas de Interface de Linha de Comando (CLI) e ambientes de Desenvolvimento Integrado (IDE).
• Qwen3-30B-A3B: suporta alternância entre modos de raciocínio com e sem “thinking” (processamento reflexivo), tornando-o versátil para tarefas de assistência geral, como diálogo multilíngue, raciocínio matemático e chamadas de ferramentas.
• Qwen3-30B-A3B-Thinking-2507: entrega desempenho aprimorado em tarefas complexas de raciocínio nas áreas de matemática, ciências e codificação, com capacidade estendida de compreensão de contextos longos.
• Qwen3-Coder-30B-A3B-Instruct: projetado para fluxos de trabalho de codificação agêntica, com formato de chamada de função personalizado e compreensão de contexto em escala de repositório.
• Qwen3.5-4B: modelo leve com treinamento unificado de visão e linguagem, suportando 201 idiomas — ideal para implantações multimodais de baixo custo computacional.

Como fazer o deploy no SageMaker JumpStart

O SageMaker JumpStart simplifica bastante o processo de implantação: qualquer um desses modelos pode ser colocado em produção com poucos cliques, sem necessidade de configurações complexas de infraestrutura.

Para começar, basta acessar a seção Models dentro do SageMaker Studio ou utilizar o SageMaker Python SDK para realizar o deploy diretamente na conta AWS. A documentação oficial do Amazon SageMaker JumpStart traz os detalhes completos sobre como implantar e utilizar modelos de fundação na plataforma.

Por que isso importa para equipes brasileiras

A chegada desses modelos ao JumpStart é relevante porque reduz a barreira de entrada para times que querem experimentar modelos de ponta sem precisar gerenciar infraestrutura de ML do zero. A combinação de modelos especializados em código, raciocínio avançado e suporte multilíngue — incluindo os 201 idiomas do Qwen3.5-4B — abre espaço para aplicações de IA sofisticadas em contextos diversos, inclusive para o mercado brasileiro.

Fonte

Five new Qwen models for coding agents and efficient reasoning are now available in Amazon SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/04/qwen-models-on-sagemaker-jumpstart/)

O problema de rastreabilidade em ML de produção

Equipes de machine learning (ML) em produção frequentemente se deparam com uma pergunta simples que se transforma em uma investigação de dias: “quais dados treinaram o modelo que está em produção agora?” Sem uma cadeia de rastreabilidade bem definida, a resposta exige vasculhar logs espalhados, notebooks e buckets do Amazon Simple Storage Service (Amazon S3) — um processo lento e propenso a erros.

Esse problema é ainda mais crítico em setores regulados, como saúde, serviços financeiros e veículos autônomos. Nesses contextos, auditorias exigem que modelos em produção estejam vinculados aos dados exatos que os treinaram, e registros individuais podem precisar ser excluídos de treinamentos futuros mediante solicitação.

Para endereçar esse desafio, a AWS publicou um guia técnico mostrando como combinar três ferramentas em um único fluxo de trabalho rastreável:

• DVC (Controle de Versão de Dados) — para versionar datasets e vinculá-los a commits do Git
• Amazon SageMaker AI — para processamento, treinamento e implantação escaláveis
• Amazon SageMaker AI MLflow Apps — para rastreamento de experimentos, registro de modelos e linhagem

Como a arquitetura funciona

A solução integra as três ferramentas de forma que cada modelo possa ser rastreado até seus dados de treinamento exatos. Cada ferramenta tem um papel distinto:

• DVC: armazena metafiles .dvc leves no Git, enquanto os dados reais ficam no Amazon S3
• Amazon SageMaker AI: orquestra jobs de processamento, treinamento e hospedagem do modelo
• SageMaker AI MLflow App: registra parâmetros, métricas, artefatos e modelos versionados

O fluxo de dados percorre quatro estágios principais. Primeiro, um job de processamento do SageMaker AI pré-processa os dados brutos e versiona o dataset resultante com o DVC, enviando os dados para o S3 e os metadados para um repositório Git. Em seguida, um job de treinamento clona o repositório DVC em uma tag Git específica, executa dvc pull para recuperar o dataset versionado exato e treina o modelo. Cada execução de treinamento registra o data_git_commit_id — o hash do commit DVC que aponta para o dataset exato no S3. Por fim, o modelo treinado é registrado no MLflow Model Registry e pode ser implantado em um endpoint do SageMaker AI.

O resultado é uma cadeia de rastreabilidade completa: Modelo em Produção → Execução MLflow → Commit DVC → Dataset exato no Amazon S3.

Como DVC e MLflow se complementam

O ponto central dessa arquitetura é que o DVC e o MLflow resolvem metades diferentes do problema de linhagem — e juntos fecham o ciclo.

O DVC (Controle de Versão de Dados) é uma ferramenta gratuita e de código aberto que estende o Git para lidar com grandes datasets e artefatos de ML. O Git sozinho não consegue gerenciar arquivos binários grandes sem tornar os repositórios lentos e pesados. O DVC resolve isso rastreando metafiles .dvc leves no Git (ponteiros endereçáveis por conteúdo), enquanto os dados reais ficam em armazenamento remoto como o Amazon S3. Isso oferece semântica de versionamento similar ao Git — branches, tags, diffs — para datasets de gigabytes ou terabytes.

Em termos de eficiência de armazenamento, o DVC usa armazenamento endereçável por conteúdo com hashes MD5. Isso significa que apenas arquivos novos ou modificados são armazenados — se você adicionar mil imagens a um dataset existente, somente essas novas imagens são enviadas ao S3. Arquivos com conteúdo idêntico são armazenados uma única vez, mesmo que apareçam com nomes diferentes ou em versões distintas do dataset.

Além do versionamento de dados, o DVC também suporta pipelines de dados reproduzíveis, gerenciamento de experimentos e pode funcionar como um registro de dados para compartilhamento entre equipes. Nessa arquitetura, porém, o foco é exclusivamente no versionamento de dados.

O SageMaker AI MLflow App é um serviço totalmente gerenciado da AWS, disponível dentro do SageMaker AI Studio, para gerenciar o ciclo de vida completo de ML e IA generativa. Suas capacidades incluem rastreamento de experimentos, registro de modelos com versionamento e gerenciamento de ciclo de vida, avaliação de modelos e integrações de implantação.

A separação de responsabilidades é clara: o DVC cuida da linhagem dados→treinamento, o MLflow cuida da linhagem treinamento→implantação, e o hash do commit Git é o elo que os conecta.

Padrão 1: Linhagem em nível de dataset

O primeiro padrão demonstra o fluxo central usando o dataset de classificação de imagens CIFAR-10, simulando um cenário comum de expansão progressiva de dados rotulados:

• v1.0: processamento e treinamento com 5% dos dados (~2.250 imagens de treino)
• v2.0: processamento e treinamento com 10% dos dados (~4.500 imagens de treino)

Para cada versão, o pipeline executa dois passos. No Passo 1, um job de processamento do SageMaker AI baixa o CIFAR-10, faz a amostragem configurada, divide em conjuntos de treino/validação/teste e versiona o resultado com DVC. O job recebe a URL do repositório DVC e o URI de rastreamento do MLflow como variáveis de ambiente:

processor_v1 = FrameworkProcessor(
    image_uri=processing_image,
    role=role,
    instance_type="ml.m5.xlarge",
    instance_count=1,
    env={
        "DVC_REPO_URL": dvc_repo_url,
        "DVC_REPO_NAME": dvc_repo_name,
        "MLFLOW_TRACKING_URI": mlflow_app_arn,
        "MLFLOW_EXPERIMENT_NAME": experiment_name,
        "PIPELINE_RUN_ID": pipeline_run_id_v1,
    }
)
processor_v1.run(
    code="preprocessing_foundational.py",
    source_dir="../source_dir",
    arguments=[
        "--data-fraction", str(data_fraction_v1),
        "--data-version", data_version_v1,
        "--val-split", "0.1"
    ],
    wait=True
)

Dentro do script de processamento, o dataset é versionado com DVC e o hash do commit é registrado no MLflow:

def version_with_dvc(repo_path, version_tag, pipeline_run_id):
    """Add data to DVC and push to remote."""
    subprocess.check_call(["dvc", "add", "dataset"], cwd=repo_path)
    subprocess.check_call(["git", "add", "dataset.dvc", ".gitignore"], cwd=repo_path)
    subprocess.check_call(
        ["git", "commit", "-m", f"Add dataset version {version_tag}"],
        cwd=repo_path
    )
    subprocess.check_call(["git", "tag", pipeline_run_id], cwd=repo_path)
    subprocess.check_call(["dvc", "push"], cwd=repo_path)
    subprocess.check_call(["git", "push", "origin", "main"], cwd=repo_path)
    subprocess.check_call(["git", "push", "origin", pipeline_run_id], cwd=repo_path)
    commit_id = subprocess.check_output(
        ["git", "rev-parse", "HEAD"], cwd=repo_path
    ).decode().strip()
    return commit_id

No Passo 2, um job de treinamento clona o repositório DVC na tag exata do Passo 1, executa dvc pull para baixar o dataset versionado e faz o fine-tuning de um modelo MobileNetV3-Small pré-treinado. A ponte de linhagem — o registro do hash do commit DVC no MLflow — acontece no script de treinamento:

# Fetch data: clone DVC repo at the exact tag, then dvc pull
data_git_commit_id = fetch_data_from_dvc()

with mlflow.start_run(run_name=run_name) as run:
    mlflow.log_params({
        "data_version": data_version,
        "data_git_commit_id": data_git_commit_id,  # <-- the lineage bridge
        "dvc_repo_url": dvc_repo_url,
        "model_architecture": "mobilenet_v3_small",
        "epochs": args.epochs,
        "learning_rate": args.learning_rate,
        # ...
    })

Com esse padrão, é possível responder perguntas como: “qual versão do dataset treinou este modelo?”, “consigo reproduzir os dados de treinamento?” e “por que a performance do modelo mudou entre versões?”. Os modelos treinados são automaticamente registrados no MLflow Model Registry com histórico de versões e links para a execução de treinamento que os gerou. Com a integração entre o SageMaker AI MLflow App e o SageMaker AI Model Registry, o MLflow também registra automaticamente o modelo no Model Registry do SageMaker AI.

O notebook também demonstra a implantação do modelo recomendado (v2.0, treinado com mais dados) do MLflow Model Registry para um endpoint de inferência em tempo real do SageMaker AI usando o ModelBuilder. Após a implantação, é possível invocar o endpoint com bytes de imagem bruta e obter predições de classe.

Padrão 2: Linhagem em nível de registro (conformidade em saúde)

O segundo padrão estende o padrão fundacional para ambientes regulados, adicionando rastreabilidade em nível de registro individual por meio de manifestos e registros de consentimento.

A adição do manifesto

A diferença central é um manifesto: um arquivo CSV estruturado que lista cada registro individual em cada versão do dataset:

patient_id,scan_id,file_path,split,label
PAT-00001,PAT-00001-SCAN-0001,train/normal/00042.png,train,normal
PAT-00023,PAT-00023-SCAN-0015,train/tubercolosis/00015.png,train,tubercolosis
...

Esse manifesto é salvo dentro do diretório do dataset versionado pelo DVC e registrado como artefato do MLflow em cada execução de treinamento. Isso torna os registros individuais consultáveis diretamente no MLflow, sem precisar baixar o dataset completo do DVC.

O registro de consentimento e o fluxo de opt-out

O fluxo é orientado por um registro de consentimento — um arquivo CSV listando cada paciente e seu status de consentimento. Em produção, isso seria um banco de dados com commits transacionais e trilha de auditoria própria. O job de processamento lê esse registro e inclui apenas registros com consent_status == "active". O código de processamento é idempotente: um opt-out é simplesmente uma mudança de entrada que produz um dataset novo e limpo quando o mesmo pipeline é executado novamente.

O notebook demonstra um ciclo completo de opt-out:

• v1.0 — Baseline: processamento e treinamento com todos os pacientes com consentimento ativo. O manifesto lista todos os exames. O modelo é registrado no MLflow com o manifesto como artefato.
• Evento de opt-out: o paciente PAT-00023 solicita exclusão. O status de consentimento é atualizado para revoked no registro, e o registro atualizado é enviado ao S3.
• v2.0 — Dataset limpo: o mesmo job de processamento roda com o registro atualizado. As imagens de PAT-00023 são automaticamente excluídas. O DVC versiona o novo dataset. O modelo é retreinado e registrado como nova versão no MLflow.
• Verificação de auditoria: consultas ao MLflow confirmam que PAT-00023 aparece apenas no modelo v1.0 e está ausente dos modelos treinados após a data de opt-out.

Consultas de auditoria

O módulo utils/audit_queries.py do repositório fornece três funções de consulta que operam baixando artefatos de manifesto do MLflow:

• find_models_with_patient("PAT-00023") — busca execuções de treinamento que incluem um paciente. Retorna apenas a execução v1.0.
• verify_patient_excluded_after_date("PAT-00023", "2025-06-01") — verifica modelos treinados após uma data e confirma a ausência do paciente. Retorna PASSED ou FAILED com detalhes.
• get_patients_in_model(run_id) — lista os IDs de pacientes nos dados de treinamento de um modelo específico.

from utils.audit_queries import find_models_with_patient

# "Which models were trained on this patient's data?"
find_models_with_patient("PAT-00023", experiment_name="demo-cxr-mlflow-dvc")

Essas consultas não exigem um checkout do DVC — elas operam inteiramente sobre artefatos do MLflow, sendo rápidas o suficiente para respostas interativas de auditoria. Para produção em escala, a recomendação é escrever tuplas (record_id, run_id, data_version) no Amazon DynamoDB no momento do treinamento, apontar o Amazon Athena para o prefixo de artefatos do MLflow no S3, ou usar um AWS Lambda pós-treinamento para popular um índice.

Embora o exemplo use terminologia de saúde, o padrão se aplica a outros domínios que exigem rastreabilidade em nível de registro: serviços financeiros, moderação de conteúdo com conteúdo enviado por usuários, ou qualquer sistema de ML sujeito a solicitações de exclusão de dados.

Boas práticas e considerações de segurança

O fluxo integrado cria rastreabilidade em três camadas:

• Camada Git + DVC: cada versão do dataset é uma tag Git apontando para um commit DVC. Executar git checkout <tag> && dvc pull restaura os dados processados exatos.
• Camada MLflow: cada execução de treinamento registra o data_git_commit_id, vinculando o modelo à versão de dados DVC. O manifesto de nível de registro (quando usado) torna registros individuais consultáveis.
• Camada Model Registry: cada versão de modelo registrada está vinculada à sua execução de treinamento, que está vinculada à sua versão de dados.

Para implantações em ambientes regulados (HIPAA, FDA 21 CFR Part 11, GDPR), a AWS recomenda adicionar controles em nível de infraestrutura:

• S3 Object Lock (modo de conformidade) nos remotes DVC e nos armazenamentos de artefatos do MLflow
• AWS CloudTrail para registro independente e append-only de acessos
• Políticas de Gerenciamento de Identidade e Acesso (IAM) com privilégio mínimo para buckets de produção, servidores de rastreamento MLflow e repositórios Git
• Criptografia em repouso usando o AWS Key Management Service (AWS KMS)

Otimizando a iteração

Para acelerar experimentos repetidos, dois recursos do SageMaker AI são recomendados:

• SageMaker Managed Warm Pools — mantém instâncias de treinamento aquecidas entre jobs, reutilizando infraestrutura já provisionada. Basta adicionar keep_alive_period_in_seconds à configuração de Compute. Esse recurso se aplica apenas a jobs de treinamento, não de processamento.
• SageMaker AI Pipelines — orquestra o fluxo processamento → treinamento → registro como um pipeline único e repetível. Os pipelines gerenciam dependências entre etapas, passam artefatos automaticamente e podem ser disparados programaticamente — por exemplo, quando um paciente faz opt-out e o manifesto é atualizado.

Pré-requisitos e limpeza

Para seguir o guia, são necessários: uma conta AWS com permissões para Amazon SageMaker (Processing, Training, MLflow Apps, Endpoints), Amazon S3, AWS CodeCommit e Gerenciamento de Identidade e Acesso (IAM); Python 3.11 ou 3.12; e o SageMaker Python SDK v3.4.0 ou posterior. O repositório de acompanhamento inclui um requirements.txt com todas as dependências.

Os notebooks usam o AWS CodeCommit como backend Git para metadados do DVC, mas o DVC funciona com outros provedores Git (GitHub, GitLab, Bitbucket). Basta substituir a URL do git remote add origin e configurar as credenciais adequadas — por exemplo, armazenando tokens no AWS Secrets Manager e buscando-os em tempo de execução, ou usando o AWS CodeConnections.

Para evitar cobranças contínuas, é importante excluir os recursos criados ao final dos testes: o endpoint do SageMaker AI, o MLflow App (opcional), o repositório do AWS CodeCommit e os dados no S3. O principal gerador de custos é o endpoint de inferência em tempo real do SageMaker AI — ele deve ser excluído imediatamente após os testes.

Conclusão

A abordagem demonstrada pela AWS combina DVC para versionamento de dados, Amazon SageMaker AI para treinamento e orquestração escaláveis, e SageMaker AI MLflow Apps para rastreamento de experimentos e registro de modelos. Os resultados principais são:

• Reprodutibilidade completa: modelos podem ser rastreados até seus dados de treinamento exatos via hashes de commit DVC armazenados no MLflow.
• Linhagem em nível de registro: o padrão de manifesto permite consultar quais registros individuais treinaram um determinado modelo — essencial para conformidade com opt-out e respostas a auditorias.
• Alinhamento de conformidade sem estado: o padrão de registro de consentimento trata exclusões de registros como mudanças de entrada, sem alterar o código de processamento.
• Comparação de experimentos: o MLflow oferece comparação lado a lado de modelos treinados em versões diferentes de dados, com rastreamento completo de parâmetros e métricas.

Os dois notebooks disponíveis no repositório GitHub de acompanhamento são implantáveis diretamente. O padrão fundacional atende equipes que precisam de rastreabilidade em nível de dataset. O padrão de conformidade em saúde o estende para ambientes regulados que exigem trilhas de auditoria em nível de registro. Ambos compartilham o mesmo código de treinamento e arquitetura do SageMaker AI. Para aprofundar no versionamento com DVC, o guia Versionando Dados e Modelos é o ponto de partida recomendado.

Fonte

End-to-end lineage with DVC and Amazon SageMaker AI MLflow apps (https://aws.amazon.com/blogs/machine-learning/end-to-end-lineage-with-dvc-and-amazon-sagemaker-ai-mlflow-apps/)

Claude Cowork chega ao Amazon Bedrock

A AWS anunciou a disponibilidade do Claude Cowork no Amazon Bedrock. A partir de agora, é possível executar o Cowork e o Claude Code Desktop diretamente pelo Amazon Bedrock — seja de forma direta ou por meio de um gateway de Modelo de Linguagem de Grande Escala (LLM). A proposta é clara: expandir o uso de Inteligência Artificial (IA) para além das equipes de desenvolvimento e alcançar todos os trabalhadores do conhecimento dentro de uma organização.

Startups e grandes empresas de diferentes setores já utilizam o Claude Code no Amazon Bedrock para aumentar a produtividade de desenvolvedores e acelerar entregas. Com essa nova integração, a AWS amplia esse alcance para funções como produto, operações, finanças e pesquisa.

O que é o Claude Cowork

O Claude Cowork é uma aplicação desktop que permite delegar tarefas como pesquisa, análise de documentos, processamento de dados e geração de relatórios diretamente ao Claude. Os usuários têm acesso às funcionalidades centrais do Claude Desktop, incluindo projetos, artefatos, memória, upload e exportação de arquivos, conectores remotos, skills, plugins e servidores MCP.

É importante destacar que funcionalidades que dependem da infraestrutura hospedada pela Anthropic — como a aba de Chat, o Computer Use e o Skills Marketplace — não estão disponíveis nessa modalidade. Isso ocorre porque o Claude Cowork direciona toda a inferência de modelos exclusivamente pelo Amazon Bedrock, dentro da conta AWS da organização. Para uma comparação completa de funcionalidades com o Claude Enterprise, a AWS disponibiliza a matriz de funcionalidades para terceiros.

O modelo de cobrança é baseado em consumo, integrado ao contrato e faturamento AWS já existente — sem licenciamento por assento cobrado pela Anthropic.

Como o Claude Cowork se integra ao Amazon Bedrock

O Amazon Bedrock atua como o backend de inferência dentro da conta AWS da organização, nas regiões AWS suportadas. A configuração do Claude Cowork no Amazon Bedrock envolve dois passos principais.

Primeiro, os usuários fazem o download do aplicativo Claude Desktop em seus computadores. Em seguida, o sistema de gerenciamento de dispositivos da organização — como Jamf, Microsoft Intune ou Group Policy — envia uma configuração ao Claude Desktop que ativa o modo de inferência, especificando o ID do modelo e o Perfil de Inferência do Amazon Bedrock, o método de autenticação e as políticas organizacionais.

Se a organização centraliza o acesso a modelos por meio de um gateway de LLM, basta apontar o Claude Desktop para a URL do gateway usando a mesma configuração gerenciada. Organizações que já utilizam o Claude Code no Amazon Bedrock podem aproveitar a mesma infraestrutura existente.

O aplicativo possui três caminhos de saída, todos sob controle da organização:

• A inferência de modelos vai para o Amazon Bedrock nas regiões AWS configuradas.
• As conexões com servidores MCP, quando configuradas, vão para endpoints aprovados pela organização.
• A Anthropic recebe apenas telemetria agregada (contagem de tokens, ID do modelo, códigos de erro e identificador anônimo do dispositivo) — o que pode ser desativado por configuração.

O Amazon Bedrock oferece perfis de inferência dentro da região, geo entre regiões e global entre regiões, permitindo que cada organização escolha o nível adequado de residência de dados.

Integração com serviços AWS

O Claude Cowork funciona com os serviços AWS que as organizações já utilizam:

• Autenticação via AWS Gerenciamento de Identidade e Acesso (IAM) ou chaves de API do Amazon Bedrock
• Isolamento de rede via endpoints de Nuvem Privada Virtual (VPC)
• Observabilidade, opcionalmente via exportação OpenTelemetry para o Amazon CloudWatch
• Auditoria via AWS CloudTrail
• Faturamento consolidado AWS, com atribuição granular de custos

Para detalhes sobre configuração de MDM (Gerenciamento de Dispositivos Móveis), credenciais, servidores MCP e plugins, a AWS disponibiliza a referência de configuração do Claude Cowork.

Claude Cowork na prática

Com a integração configurada, os usuários abrem o Claude Desktop e começam a delegar trabalho. O Claude Cowork pode se conectar a fontes de dados externas por meio de servidores MCP, dando ao Claude acesso a documentação em tempo real, busca na web e outras ferramentas.

Um exemplo prático ilustra bem o potencial: imagine um gerente de produto planejando uma nova funcionalidade de notificações para um aplicativo de atletismo universitário hospedado na AWS. Ele tem anotações de reuniões com clientes que apontam em direções diferentes, um conjunto de requisitos de projeto e pouco tempo para reconciliar tudo. Ao fazer o upload desses materiais no Cowork, o Claude compara os insumos, sintetiza tudo em um único briefing de produto, avalia a abordagem proposta, pesquisa alternativas, aponta desafios técnicos e embasa recomendações com evidências.

Conectado ao servidor MCP de documentação AWS e a um servidor MCP de busca na web, o Claude ancora o briefing em documentação atualizada dos serviços, contexto de mercado e posicionamento competitivo. Em minutos, o gerente de produto tem um documento estruturado, fundamentado em fontes atuais e pronto para revisão.

O mesmo padrão se aplica a outros perfis: um gerente de operações pode consolidar documentação dispersa em um Procedimento Operacional Padrão (POP). Um analista financeiro pode transformar dados brutos em uma revisão mensal formatada. Uma equipe de pesquisa pode compilar descobertas de múltiplas fontes em um único relatório.

Disponibilidade

O Claude Cowork está disponível para macOS e Windows nas regiões AWS onde os modelos Claude estão disponíveis no Amazon Bedrock. Para começar, basta fazer o download do Claude Desktop em claude.com/download e consultar o Guia de Configuração do Claude Cowork.

Fonte

From developer desks to the whole organization: Running Claude Cowork in Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/from-developer-desks-to-the-whole-organization-running-claude-cowork-in-amazon-bedrock/)

O que mudou no AWS Lambda

A AWS anunciou suporte ao Amazon S3 Files no Lambda, uma integração que permite às funções montar buckets do Amazon S3 diretamente como sistemas de arquivos — e executar operações de arquivo convencionais sem a necessidade de baixar os dados antes de processá-los.

Construído sobre o Amazon EFS (Elastic File System), o S3 Files combina a simplicidade e a experiência de uso de um sistema de arquivos tradicional com a escalabilidade, durabilidade e o custo-benefício já conhecidos do S3.

Compartilhamento de dados entre funções

Um dos pontos mais relevantes dessa novidade é a possibilidade de múltiplas funções Lambda se conectarem ao mesmo sistema de arquivos S3 Files simultaneamente. Isso significa que diferentes funções podem compartilhar dados por meio de um espaço de trabalho comum, sem que o time precise desenvolver lógica customizada de sincronização.

Na prática, a integração simplifica workloads com estado no Lambda ao eliminar o overhead de baixar objetos, fazer upload de resultados e gerenciar os limites do armazenamento efêmero — um alívio considerável para quem já enfrentou essas restrições.

Valor especial para workloads de IA e machine learning

Esse recurso é especialmente valioso para workloads de Inteligência Artificial (IA) e machine learning, onde agentes precisam persistir memória e compartilhar estado entre as etapas de um pipeline. As funções duráveis do Lambda tornam esses fluxos de trabalho de IA em múltiplas etapas possíveis ao orquestrar a execução paralela com checkpointing automático.

Um exemplo prático: uma função orquestradora pode clonar um repositório para um espaço de trabalho compartilhado enquanto múltiplas funções de agente analisam o código em paralelo. A função durável cuida do checkpointing do estado de execução, enquanto o S3 Files garante o compartilhamento fluido de dados em todas as etapas.

Como configurar

Para usar o S3 Files com o Lambda, basta configurar a função para montar um bucket do S3. Essa configuração pode ser feita pelo console do Lambda, pela AWS CLI (Interface de Linha de Comando), pelos AWS SDKs (Kits de Desenvolvimento de Software), pelo AWS CloudFormation ou pelo AWS SAM (Serverless Application Model). Para mais detalhes sobre como utilizar o recurso, a AWS disponibiliza o guia do desenvolvedor do Lambda.

Disponibilidade e preços

O S3 Files é suportado para funções Lambda que não estejam configuradas com um provedor de capacidade, e está disponível em todas as regiões da AWS onde tanto o Lambda quanto o S3 Files estiverem disponíveis. Não há cobrança adicional pelo uso da integração — os custos seguem os preços padrão do Lambda e do S3.

Fonte

AWS Lambda functions can now mount Amazon S3 buckets as file systems with S3 Files (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-lambda-amazon-s3/)

O problema de testar agentes de IA que chamam ferramentas externas

Agentes de IA modernos não se limitam a raciocinar: eles chamam APIs, consultam bancos de dados, acionam serviços MCP (Protocolo de Contexto de Modelo) e interagem com sistemas externos para concluir tarefas. O comportamento do agente depende não só do seu raciocínio, mas também do que essas ferramentas retornam — e é exatamente aí que o teste se complica.

Testar contra APIs reais cria três obstáculos sérios. Primeiro, dependências externas atrasam tudo: limites de taxa, instabilidades e necessidade de conectividade tornam impraticável rodar centenas de casos de teste. Segundo, chamadas reais geram efeitos colaterais reais — enviar e-mails de verdade, alterar bancos de produção ou confirmar reservas indesejadas. Terceiro, muitas ferramentas lidam com dados sensíveis, como registros de usuários e informações financeiras, criando riscos de conformidade desnecessários.

A alternativa clássica são os mocks estáticos, mas eles também têm um limite importante: funcionam bem para cenários simples e previsíveis, porém quebram em fluxos multi-etapas com estado. Imagine um agente de reserva de voos que primeiro busca opções e depois verifica o status de uma reserva — a segunda resposta precisa depender do que aconteceu na primeira chamada. Um mock com resposta fixa não consegue capturar essa dinâmica.

O que é o ToolSimulator

A AWS apresentou o ToolSimulator como parte do Kit de Desenvolvimento de Software (SDK) do Strands Evals. Trata-se de um framework de simulação de ferramentas baseado em Modelo de Linguagem de Grande Escala (LLM) que intercepta chamadas às ferramentas registradas e as redireciona para um gerador de respostas inteligente — sem nunca acionar a implementação real.

O gerador usa o esquema da ferramenta, a entrada do agente e o estado atual da simulação para produzir uma resposta realista e contextualmente adequada. Não são necessários fixtures escritos à mão.

Três capacidades centrais sustentam essa proposta:

• Geração adaptativa de respostas: as saídas refletem o que o agente realmente solicitou, não um template fixo. Uma busca por voos de Seattle para Nova York retorna opções plausíveis com preços e horários realistas.
• Suporte a fluxos com estado: o ToolSimulator mantém um estado compartilhado consistente entre chamadas, permitindo testar interações de banco de dados, fluxos de reserva e processos multi-etapas sem tocar em sistemas de produção.
• Validação de esquema: respostas são validadas contra modelos Pydantic definidos pelo desenvolvedor, capturando respostas malformadas antes que cheguem ao agente e quebrem a camada de pós-processamento.

Como o ToolSimulator funciona

O fluxo de trabalho segue três etapas: decorar e registrar as ferramentas, opcionalmente configurar o contexto da simulação e, por fim, deixar o ToolSimulator interceptar as chamadas durante a execução do agente.

Etapa 1: Decorar e registrar

Cria-se uma instância do ToolSimulator e envolve-se a função da ferramenta com o decorator @simulator.tool(). O corpo real da função pode ficar vazio — o ToolSimulator intercepta as chamadas antes de chegarem à implementação:

from strands_evals.simulation.tool_simulator import ToolSimulator

tool_simulator = ToolSimulator()

@tool_simulator.tool()
def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search for available flights between two airports on a given date."""
    pass  # The real implementation is never called during simulation

Etapa 2: Configurar o contexto (opcional)

Por padrão, o ToolSimulator infere o comportamento de cada ferramenta a partir do seu esquema e docstring — nenhuma configuração adicional é necessária para começar. Quando se quer mais controle, três parâmetros opcionais estão disponíveis:

• share_state_id: vincula ferramentas que compartilham o mesmo backend sob uma chave de estado comum. Alterações feitas por uma ferramenta ficam visíveis para chamadas subsequentes de outras ferramentas ligadas ao mesmo ID.
• initial_state_description: inicializa a simulação com uma descrição em linguagem natural do estado pré-existente. Quanto mais contexto, mais realistas e consistentes serão as respostas geradas.
• output_schema: um modelo Pydantic que define a estrutura esperada da resposta. O ToolSimulator gera respostas que obedecem estritamente a esse esquema.

Etapa 3: Simulação em execução

Quando o agente chama uma ferramenta registrada, o wrapper do ToolSimulator intercepta a chamada, valida os parâmetros do agente contra o esquema da ferramenta, produz uma resposta compatível com o output_schema e atualiza o registro de estado para que chamadas subsequentes vejam um ambiente consistente.

O exemplo abaixo mostra uma simulação completa de um assistente de busca de voos:

from strands import Agent
from strands_evals.simulation.tool_simulator import ToolSimulator

# 1. Create a simulator instance
tool_simulator = ToolSimulator()

# 2. Register a tool for simulation with initial state context
@tool_simulator.tool(
    initial_state_description="Flight database: SEA->JFK flights available at 8am, 12pm, and 6pm. Prices range from $180 to $420.",
)
def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search for available flights between two airports on a given date."""
    pass

# 3. Create an agent with the simulated tool and run it
flight_tool = tool_simulator.get_tool("search_flights")
agent = Agent(
    system_prompt="You are a flight search assistant.",
    tools=[flight_tool],
)
response = agent("Find me flights from Seattle to New York on March 15.")
print(response)
# Expected output: A structured list of simulated SEA->JFK flights with times
# and prices consistent with the initial_state_description you provided.

Recursos avançados do ToolSimulator

Instâncias independentes para testes paralelos

É possível criar múltiplas instâncias do ToolSimulator lado a lado. Cada instância mantém seu próprio registro de ferramentas e estado, permitindo executar configurações de experimento em paralelo no mesmo código:

simulator_a = ToolSimulator()
simulator_b = ToolSimulator()

# Each instance has an independent tool registry and state --
# ideal for comparing agent behavior across different tool setups.

Estado compartilhado para fluxos multi-etapas

Para ferramentas com estado — como getters e setters de banco de dados — o ToolSimulator mantém consistência entre chamadas. Usa-se share_state_id para vincular ferramentas que operam no mesmo backend e initial_state_description para inicializar o contexto:

@tool_simulator.tool(
    share_state_id="flight_booking",
    initial_state_description="Flight booking system: SEA->JFK flights available at 8am, 12pm, and 6pm. No bookings currently active.",
)
def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search for available flights between two airports on a given date."""
    pass

@tool_simulator.tool(
    share_state_id="flight_booking",
)
def get_booking_status(booking_id: str) -> dict:
    """Retrieve the current status of a flight booking by booking ID."""
    pass

# Both tools share "flight_booking" state.
# When search_flights is called, get_booking_status sees the same
# flight availability data in subsequent calls.

Também é possível inspecionar o estado antes e depois da execução do agente para validar que as interações com as ferramentas produziram as mudanças esperadas:

initial_state = tool_simulator.get_state("flight_booking")
# ... run the agent ...
final_state = tool_simulator.get_state("flight_booking")
# Verify not just the final output, but the full sequence of tool interactions.

Dica: como o initial_state_description aceita linguagem natural, é possível usar um DataFrame.describe() para gerar resumos estatísticos de dados tabulares e passá-los diretamente como descrição de estado — sem nunca acessar os dados reais.

Validação de esquema de resposta com Pydantic

Para ferramentas que seguem especificações rígidas — como OpenAPI ou MCP — define-se a resposta esperada como um modelo Pydantic e passa-se via output_schema:

from pydantic import BaseModel, Field

class FlightSearchResponse(BaseModel):
    flights: list[dict] = Field(
        ..., description="List of available flights with flight number, departure time, and price"
    )
    origin: str = Field(..., description="Origin airport code")
    destination: str = Field(..., description="Destination airport code")
    status: str = Field(default="success", description="Search operation status")
    message: str = Field(default="", description="Additional status message")

@tool_simulator.tool(output_schema=FlightSearchResponse)
def search_flights(origin: str, destination: str, date: str) -> dict:
    """Search for available flights between two airports on a given date."""
    pass

# ToolSimulator validates parameters strictly and returns only valid JSON
# responses that conform to the FlightSearchResponse schema.

Integração com pipelines de avaliação do Strands Evals

O ToolSimulator se encaixa naturalmente no framework de avaliação do Strands Evals. O exemplo abaixo mostra um pipeline completo — da configuração da simulação ao relatório do experimento — usando o GoalSuccessRateEvaluator para pontuar o desempenho do agente em tarefas de chamada de ferramentas:

from typing import Any
from pydantic import BaseModel, Field
from strands import Agent
from strands_evals import Case, Experiment
from strands_evals.evaluators import GoalSuccessRateEvaluator
from strands_evals.simulation.tool_simulator import ToolSimulator
from strands_evals.mappers import StrandsInMemorySessionMapper
from strands_evals.telemetry import StrandsEvalsTelemetry

# Set up telemetry and tool simulator
telemetry = StrandsEvalsTelemetry().setup_in_memory_exporter()
memory_exporter = telemetry.in_memory_exporter
tool_simulator = ToolSimulator()

# Define the response schema
class FlightSearchResponse(BaseModel):
    flights: list[dict] = Field(
        ..., description="Available flights with number, departure time, and price"
    )
    origin: str = Field(..., description="Origin airport code")
    destination: str = Field(..., description="Destination airport code")
    status: str = Field(default="success", description="Search operation status")
    message: str = Field(default="", description="Additional status message")

# Register tools for simulation
@tool_simulator.tool(
    share_state_id="flight_booking",
    initial_state_description="Flight booking system: SEA->JFK flights at 8am, 12pm, and 6pm. No bookings currently active.",
    output_schema=FlightSearchResponse,
)
def search_flights(origin: str, destination: str, date: str) -> dict[str, Any]:
    """Search for available flights between two airports on a given date."""
    pass

@tool_simulator.tool(share_state_id="flight_booking")
def get_booking_status(booking_id: str) -> dict[str, Any]:
    """Retrieve the current status of a flight booking by booking ID."""
    pass

# Define the evaluation task
def user_task_function(case: Case) -> dict:
    initial_state = tool_simulator.get_state("flight_booking")
    print(f"[State before]: {initial_state.get('initial_state')}")
    search_tool = tool_simulator.get_tool("search_flights")
    status_tool = tool_simulator.get_tool("get_booking_status")
    agent = Agent(
        trace_attributes={
            "gen_ai.conversation.id": case.session_id,
            "session.id": case.session_id
        },
        system_prompt="You are a flight booking assistant.",
        tools=[search_tool, status_tool],
        callback_handler=None,
    )
    agent_response = agent(case.input)
    print(f"[User]: {case.input}")
    print(f"[Agent]: {agent_response}")
    final_state = tool_simulator.get_state("flight_booking")
    print(f"[State after]: {final_state.get('previous_calls', [])}")
    finished_spans = memory_exporter.get_finished_spans()
    mapper = StrandsInMemorySessionMapper()
    session = mapper.map_to_session(finished_spans, session_id=case.session_id)
    return {"output": str(agent_response), "trajectory": session}

# Define test cases, run the experiment, and display the report
test_cases = [
    Case(
        name="flight_search",
        input="Find me flights from Seattle to New York on March 15.",
        metadata={"category": "flight_booking"},
    ),
]

experiment = Experiment[str, str](
    cases=test_cases,
    evaluators=[GoalSuccessRateEvaluator()]
)
reports = experiment.run_evaluations(user_task_function)
reports[0].run_display()

A função de tarefa recupera as ferramentas simuladas, cria um agente, executa a interação e retorna tanto a saída do agente quanto a trajetória completa de telemetria. Essa trajetória dá aos avaliadores como o GoalSuccessRateEvaluator acesso à sequência completa de chamadas de ferramentas e invocações do modelo — não apenas à resposta final.

Boas práticas para avaliação baseada em simulação

• Comece com a configuração padrão para cobertura ampla. Adicione overrides apenas para os ambientes de ferramentas que você precisa controlar com precisão.
• Forneça valores ricos em initial_state_description para ferramentas com estado: inclua faixas de dados, contagens de entidades e contexto de relacionamentos.
• Use share_state_id para ferramentas que interagem com o mesmo backend, garantindo que operações de escrita sejam visíveis para leituras subsequentes.
• Aplique output_schema para ferramentas que seguem especificações rígidas, como OpenAPI ou MCP.
• Valide sequências de interação com ferramentas, não apenas saídas finais — inspecione mudanças de estado antes e depois da execução do agente.
• Comece pelos cenários de interação mais comuns e expanda para casos extremos conforme sua prática de avaliação amadurece.
• Complemente os testes baseados em simulação com testes pontuais contra APIs reais para caminhos críticos de produção.

Como começar

A instalação é feita com um único comando:

pip install strands-evals

Para continuar explorando o ToolSimulator e o Strands Evals, a AWS recomenda consultar a documentação do Strands Evals para ver todas as opções de configuração, incluindo gerenciamento avançado de estado e avaliadores personalizados. Também é possível experimentar o exemplo oficial para ver o ToolSimulator em ação e estendê-lo com mais ferramentas e fluxos multi-etapas.

Para o backend de LLM que alimenta a geração de respostas do ToolSimulator, a AWS indica o Amazon Bedrock. Para estratégias de implantação serverless de agentes que funcionam bem com testes baseados em ToolSimulator, vale explorar o AWS Lambda.

Fonte

ToolSimulator: scalable tool testing for AI agents (https://aws.amazon.com/blogs/machine-learning/toolsimulator-scalable-tool-testing-for-ai-agents/)