Blog

Os desafios reais da análise de dados clínicos

Pesquisadores e epidemiologistas em saúde lidam com um paradoxo bem conhecido: possuem profundo conhecimento sobre padrões de doenças, cuidados ao paciente e resultados clínicos, mas enfrentam obstáculos técnicos enormes antes de responder uma única pergunta de pesquisa. A realidade é que essas profissionais gastam semanas navegando infraestruturas complexas de dados, escrevendo código repetitivo e resolvendo barreiras técnicas que pouco têm a ver com seu trabalho principal.

Este gargalo não é apenas uma inconveniência — ele atrasa decisões baseadas em evidências e pode impactar diretamente o cuidado ao paciente. Centros acadêmicos, laboratórios de pesquisa, instalações clínicas e organizações comerciais de saúde produzem volumes enormes de dados clínicos que deveriam ser explorados muito mais rapidamente.

Principais obstáculos na análise acelerada de dados em saúde

Dois desafios centrais travam a velocidade de pesquisa clínica:

Navegação em dados clínicos complexos: Os catálogos de dados em saúde usam terminologias médicas especializadas e sistemas de codificação que exigem expertise de domínio para serem compreendidos. Descobrir quais tabelas contêm coortes de pacientes específicas e entender como códigos de condições se mapeiam entre diferentes sistemas de classificação é uma barreira considerável antes que qualquer análise comece.

Preparação técnica para análise: Após localizar os dados, analistas de saúde passam tempo significativo escrevendo scripts Python ou PySpark para extrair coortes de pacientes, calcular métricas clínicas e executar análises estatísticas. Este ônus técnico é particularmente agudo porque pesquisadores clínicos são especialistas em epidemiologia ou bioestatística, não em engenharia de software.

A solução: SageMaker Data Agent com IA agnóstica

Em 21 de novembro de 2025, a AWS introduziu uma capacidade integrada no Amazon SageMaker que muda fundamentalmente essa equação. O SageMaker Data Agent funciona como um assistente de pesquisa inteligente dentro do Amazon SageMaker Unified Studio, com capacidade de compreender seu ambiente de dados específico e seus objetivos clínicos.

Quando um pesquisador faz uma pergunta como “Compare padrões de comorbidade entre coortes de pacientes diabéticos e hipertensos”, o agente de dados não apenas gera fragmentos de código. Ele pensa o problema de forma sistemática: cria um plano de análise com múltiplas etapas, identifica as tabelas clínicas relevantes, determina os métodos estatísticos apropriados, gera código validado na linguagem otimizada (SQL, Python ou PySpark) e executa cada passo com pontos de controle integrados para supervisão humana.

Como o Data Agent resolve os desafios

Navegação inteligente de dados clínicos: O SageMaker Data Agent está integrado ao AWS Glue Data Catalog e mapeia todo o seu panorama de dados de saúde. O agente compreende suas tabelas clínicas reais — demografias de pacientes, diagnósticos, encontros, condições, medicações, imunizações, procedimentos — pelos seus nomes verdadeiros e relacionamentos. Reconhece relacionamentos temporais entre encontros, entende como códigos de diagnóstico se estruturam e navega as hierarquias complexas de dados clínicos sem exigir memorização de esquemas de banco de dados.

Redução do esforço técnico: O agente transforma perguntas clínicas em linguagem natural em código analítico pronto para produção. Gera código otimizado em SQL para extração eficiente de coortes de pacientes, Python para análise estatística e PySpark para processamento de dados em larga escala — tudo sem exigir que o pesquisador dominie cada linguagem. Além disso, cria um plano de análise estruturado com múltiplas etapas que reflete como pesquisadores clínicos experientes abordam problemas: definição de coorte, depois características basais, depois comparação estatística e, por fim, visualização. Cada etapa inclui pontos de validação para o usuário revisar o processo do agente, assegurando validade clínica, tratamento apropriado de dados faltantes e uso de métodos estatisticamente apropriados.

Esta abordagem agnóstica desloca o tempo do pesquisador de preparação técnica para interpretação clínica — exatamente o inverso do que acontecia antes.

Segurança e governança integradas

O SageMaker Data Agent foi arquitetado para respeitar controles de segurança existentes. Ele opera de forma segura dentro de seu ambiente AWS, respeitando políticas de AWS Identity and Access Management (IAM) e limites de dados organizacionais. Isso ajuda sua organização a manter controles de segurança enquanto acelera análise clínica, assegurando conformidade com regulamentos de proteção de dados e governança.

Cenário de uso: análise de coorte clínica

Imagine uma epidemiologista em um centro médico acadêmico conduzindo análise detalhada de condições clínicas como sinusite, diabetes e hipertensão através de comparação de coortes e análise de sobrevida. Seu fluxo de trabalho tradicional envolve navegar múltiplos sistemas desconectados para localizar conjuntos de dados, aguardar aprovações de acesso, compreender esquemas de dados complexos e escrever código extenso em Python e PySpark — um processo de múltiplas semanas onde a maioria do tempo vai para preparação de dados em vez de análise clínica real.

Este gargalo limita pesquisadores a apenas 2-3 estudos abrangentes por trimestre, atrasando diretamente a geração de insights analíticos.

Dois modos de interação para flexibilidade

Painel do Agente para análise clínica abrangente: Ideal para projetos de pesquisa de ponta a ponta. Este modo divide perguntas complexas de saúde em etapas analíticas estruturadas com pontos de revisão intermediários, mantendo supervisão humana ao longo de todo o processo.

Assistência integrada para tarefas focadas: Ideal para pesquisadores experientes que desejam ajuda direcionada com desafios de codificação específicos, correção de erros ou melhorias de código, mantendo controle total de seu fluxo de trabalho.

Como começar: guia prático

Pré-requisitos e configuração

Para este exemplo, usa-se Synthea — uma ferramenta que gera dados sintéticos de pacientes em formato CSV, contendo informações sobre pacientes, condições, imunizações, alergias, encontros e procedimentos. A Synthea é um gerador sintético de pacientes de código aberto que modela o histórico médico de pacientes sintéticos. Nenhum dado humano real é usado neste processo.

Como parte da configuração do SageMaker, abra o console do SageMaker e escolha “Get started” para criar um domínio baseado em IAM e um projeto denominado ClinicalDataProject. Para instruções sobre como configurar um domínio baseado em IAM e criar um projeto, consulte a documentação sobre domínios e projetos baseados em IAM.

Explorando dados clínicos com SQL

Após configurar o ambiente, você pode visualizar dados usando SQL simples. No console do SageMaker, escolha “Open” e depois o projeto que criou. Será redirecionado para a página de visão geral do SageMaker Unified Studio. Escolha “Data” no painel de navegação e expanda AwsDataCatalog para visualizar os dados catalogados aos quais você tem acesso em sua conta.

Para este caso de uso, crie cada uma das tabelas (pacientes, condições, imunizações, alergias, encontros e procedimentos) sob sagemaker_sample_db usando os arquivos CSV gerados anteriormente. Antes de realizar a análise clínica complexa, execute uma consulta básica na tabela de condições:

select * from "AwsDataCatalog"."sagemaker_sample_db"."conditions" limit 10

Criando um notebook para análise detalhada

Para análise aprofundada, crie um notebook. Escolha “Notebooks” no painel de navegação e selecione “Create notebook”. Depois de criar o notebook, você pode interagir com os dados de duas formas:

• Codificar diretamente dentro de células do notebook usando a interface de prompt integrado. Por exemplo, digite “Code to find patient records in conditions table who suffer from Sinusitis” (Código para encontrar registros de pacientes na tabela de condições que sofrem de Sinusite), escolha “Generate code” e execute a célula para exibir os resultados.
• Usar o painel Data Agent, que suporta tarefas analíticas abrangentes dividindo-as em etapas estruturadas, cada uma com código gerado que se baseia em resultados anteriores.

Análise detalhada de dados clínicos com Data Agent

No painel Data Agent, insira a consulta: “Find top 20 conditions and perform a detailed analysis of patients with immunizations suffering from those conditions” (Encontre as 20 principais condições e realize análise detalhada de pacientes com imunizações sofrendo dessas condições) e gere o código.

O SageMaker Data Agent verifica o estado atual do notebook para compreender com quais dados você está trabalhando. Identifica as tabelas de condições, imunizações e pacientes no banco de dados sagemaker_sample_db. Prepara um plano abrangente e o lista para que você revise. Você pode revisar o plano, fazer alterações necessárias se needed e depois escolher “Run step-by-step”.

O agente escreve o código nas células do notebook. Você pode revisar o código e depois escolher “Accept and run”. Se algumas etapas falharem na execução, escolha “Fix with AI” para prosseguir. Quando a consulta for concluída, os resultados serão exibidos com visualizações incluindo análise demográfica de pacientes imunizados com as 20 principais condições, análise de prevalência de condições e análise temporal do aparecimento de condições.

Comparação de coorte e análise de sobrevida

Com a sinusite viral identificada como a condição principal, você pode realizar comparação de coorte e análise de sobrevida. Insira a seguinte consulta no painel Data Agent:

“Build two cohorts 1/ Cohort for Male patients who are suffering from viral sinusitis 2/ Cohort for Female patients who are suffering from viral sinusitis. Run a detailed cohort comparison and survival analysis.” (Construa duas coortes 1/ Coorte para pacientes do sexo masculino sofrendo de sinusite viral 2/ Coorte para pacientes do sexo feminino sofrendo de sinusite viral. Execute comparação detalhada de coorte e análise de sobrevida.)

O SageMaker Data Agent prepara um plano abrangente para criação de coorte, análise de comparação de coorte e análise de sobrevida. Revise o plano e escolha “Run step-by-step”. O resultado inclui gráficos de comparação demográfica entre coortes, curvas de Kaplan-Meier e gráficos cumulativos de eventos.

Limpeza de recursos

Para remover recursos criados durante este processo: primeiro, delete o projeto SageMaker Unified Studio navegando até o console, selecionando seu projeto da lista e escolhendo “Delete”. Segundo, remova recursos do AWS Glue Data Catalog abrindo o console do AWS Glue, navegando até “Databases” e deletando o banco de dados de exemplo. Terceiro, delete buckets S3 e dados abrindo o console do Amazon S3, localizando o bucket onde dados de saúde estão armazenados, esvaziando o conteúdo e deletando o bucket.

Por que isso importa para pesquisa em saúde

Com o SageMaker Data Agent alimentado por IA agnóstica, você vê seus conjuntos de dados acessíveis ao fazer login, valida qualidade de dados com visualizações rápidas e realiza análise através de prompts em linguagem natural — reduzindo esforço de codificação manual. O agente acelera sua capacidade de pesquisa, ajudando padrões de tratamento a serem identificados mais cedo.

Ao deslocar a vasta maioria do seu tempo de preparação de dados para análise real, o SageMaker Data Agent entrega descobertas de pesquisa mais eficientemente enquanto reduz custos de infraestrutura. As análises são documentadas em notebooks reproduzíveis que podem ser validadas e auditadas por stakeholders clínicos, suportando transparência enquanto acelera o caminho de dados para análise impactante.

Fonte

Agentic AI for healthcare data analysis with Amazon SageMaker Data Agent (https://aws.amazon.com/blogs/machine-learning/agentic-ai-for-healthcare-data-analysis-with-amazon-sagemaker-data-agent/)

Novos modelos de IA para casos de uso empresariais

A AWS anunciou recentemente a disponibilidade de três novos modelos de fundação no Amazon SageMaker JumpStart, expandindo significativamente o portfólio de soluções de inteligência artificial disponíveis aos clientes da plataforma. O anúncio traz o DeepSeek OCR, MiniMax M2.1 e Qwen3-VL-8B-Instruct, modelos especializados que abrangem capacidades em inteligência de documentos, codificação multilíngue, raciocínio multimodal avançado e compreensão visão-linguagem.

Esses três modelos foram desenvolvidos para resolver diferentes desafios de inteligência artificial em ambientes corporativos, oferecendo capacidades especializadas que permitem aos clientes construir aplicações sofisticadas sobre a infraestrutura da AWS.

Capacidades técnicas de cada modelo

DeepSeek OCR: Processamento inteligente de documentos

O modelo DeepSeek OCR explora a compressão de elementos visuais e textuais, direcionado especialmente para processamento de documentos. Sua funcionalidade permite extrair informações estruturadas de formulários, faturas, diagramas e documentos complexos com layouts de texto denso, facilitando a automação de processos documentais em escala.

MiniMax M2.1: Desenvolvimento de software e automação

O MiniMax M2.1 foi otimizado para codificação, uso de ferramentas, seguimento de instruções e planejamento em múltiplos passos. O modelo automatiza desenvolvimento de software multilíngue e executa fluxos de trabalho de escritório complexos e com múltiplas etapas, permitindo que desenvolvedores criem aplicações autônomas mais sofisticadas.

Qwen3-VL-8B-Instruct: Compreensão avançada multimodal

O Qwen3-VL-8B-Instruct oferece compreensão e geração superior de texto, percepção visual mais profunda e capacidade de raciocínio, comprimento de contexto estendido, e compreensão aprimorada de dinâmicas espaciais e de vídeo, além de capacidades mais fortes de interação com agentes.

Como começar

O SageMaker JumpStart permite que clientes da AWS implantem qualquer um desses modelos com apenas alguns cliques, endereçando casos de uso específicos de inteligência artificial. Para começar a usar esses modelos, basta acessar o catálogo de modelos do SageMaker JumpStart no console do SageMaker ou utilizar o SDK em Python do SageMaker para implantar os modelos na sua conta AWS.

Para obter mais informações sobre como implantar e usar modelos de fundação no SageMaker JumpStart, consulte a documentação do Amazon SageMaker JumpStart.

Fonte

DeepSeek OCR, MiniMax M2.1, and Qwen3-VL-8B-Instruct models are now available on SageMaker JumpStart (https://aws.amazon.com/about-aws/whats-new/2026/01/new-models-on-sagemaker-jumpstart)

Resolvendo desafios de escalabilidade em aplicações de IA

Construir aplicações de inteligência artificial com o Amazon Bedrock frequentemente apresenta desafios significativos relacionados ao throughput, impactando diretamente a capacidade de escala dos seus sistemas. A inferência global cross-region na região af-south-1 da AWS modifica esse cenário.

Agora é possível invocar modelos a partir da região de Cape Town enquanto o Amazon Bedrock automaticamente roteia requisições para regiões que possuem capacidade disponível. O resultado é que suas aplicações mantêm tempos de resposta consistentes, seus usuários experimentam confiabilidade, e seus logs centralizados no Amazon CloudWatch e AWS CloudTrail permanecem organizados em um único local.

Acesso aos modelos Claude 4.5 com maior throughput

A inferência cross-region global com os modelos Anthropic Claude Sonnet 4.5, Haiku 4.5 e Opus 4.5 no Amazon Bedrock agora está disponível na região de Cape Town. Clientes sul-africanos podem utilizar perfis de inferência global para acessar esses modelos com throughput melhorado e maior resiliência.

A inferência cross-region global roteia requisições para regiões comerciais suportadas em todo o mundo, otimizando recursos e possibilitando maior throughput — particularmente valioso durante períodos de pico. O recurso é compatível com cache de prompts do Amazon Bedrock, inferência em lote, Guardrails do Amazon Bedrock, Bases de Conhecimento do Amazon Bedrock e muito mais.

Compreendendo a inferência cross-region

A inferência cross-region é um recurso poderoso que organizações podem utilizar para distribuir processamento de inferência perfeitamente entre múltiplas regiões. Essa capacidade permite alcançar maior throughput ao construir em escala, permitindo que aplicações de IA generativa permaneçam responsivas e confiáveis mesmo sob carga pesada.

Um perfil de inferência no Amazon Bedrock define um modelo de fundação (FM) e uma ou mais regiões para as quais pode rotear requisições de invocação. Os perfis de inferência funcionam em torno de dois conceitos principais:

• Região de Origem: A região de onde a requisição de API é feita
• Região de Destino: Uma região para a qual o Amazon Bedrock pode rotear a requisição para inferência

A inferência cross-region opera através da rede segura da AWS com criptografia de ponta a ponta tanto para dados em trânsito quanto em repouso. Quando um cliente submete uma requisição de inferência a partir de uma região de origem, a inferência cross-region roteia inteligentemente a requisição para uma das regiões de destino configuradas no perfil de inferência através da rede gerenciada pelo Bedrock.

Uma distinção importante: enquanto o processamento de inferência (o cálculo transitório) pode ocorrer em outra região, dados em repouso — incluindo logs, bases de conhecimento e configurações armazenadas — foram projetados para permanecer em sua região de origem. As requisições viajam pela Rede Global da AWS gerenciada pelo Bedrock. Os dados transmitidos durante a inferência cross-region são criptografados e permanecem dentro da rede segura da AWS.

Dois modelos de inferência cross-region

A AWS oferece dois tipos de perfis de inferência cross-region:

• Inferência cross-region geográfica: O Amazon Bedrock seleciona automaticamente a região comercial ótima dentro de uma geografia definida (Estados Unidos, Europa, Austrália e Japão) para processar sua requisição de inferência. Recomendado para casos de uso com requisitos de residência de dados.
• Inferência cross-region global: A inferência cross-region global aprimoura ainda mais esse recurso ao permitir o roteamento de requisições de inferência para regiões comerciais suportadas em todo o mundo, otimizando recursos disponíveis e possibilitando maior throughput de modelo. Recomendado para casos de uso sem requisitos rígidos de residência de dados.

Monitoramento e registro centralizado

Com a inferência cross-region global a partir de af-south-1, suas requisições podem ser processadas em qualquer lugar na infraestrutura global da AWS. No entanto, seus logs do Amazon CloudWatch e AWS CloudTrail são registrados em af-south-1, simplificando o monitoramento ao manter seus registros em um único local.

Segurança de dados e conformidade regulatória

Segurança e conformidade representam uma responsabilidade compartilhada entre a AWS e cada cliente. A inferência cross-region global foi projetada para manter a segurança de dados. Dados transmitidos durante a inferência cross-region são criptografados pelo Amazon Bedrock e permanecem dentro da rede segura da AWS.

Informações sensíveis permanecem protegidas durante todo o processo de inferência, independentemente da região que processa a requisição. Os clientes são responsáveis por configurar suas aplicações e políticas de Gerenciamento de Identidade e Acesso da AWS (IAM) apropriadamente e por avaliar se a inferência cross-region global atende seus requisitos específicos de segurança e conformidade.

Como a inferência cross-region global roteia requisições para regiões comerciais suportadas mundialmente, você deve avaliar se essa abordagem está alinhada com suas obrigações regulatórias, incluindo a Lei de Proteção de Informações Pessoais (POPIA) e outros requisitos específicos do setor. Recomenda-se consultar suas equipes de compliance e jurídica para determinar a abordagem apropriada para seus casos de uso específicos.

Implementando a inferência cross-region global

Para utilizar a inferência cross-region global com modelos Claude 4.5, desenvolvedores devem completar os seguintes passos principais:

• Usar o ID do perfil de inferência global — Ao fazer chamadas de API para o Amazon Bedrock, especifique o ID do perfil de inferência do modelo Claude 4.5 global (por exemplo, global.anthropic.claude-opus-4-5-20251101-v1:0). Funciona com as APIs InvokeModel e Converse.
• Configurar permissões IAM — Conceda permissões IAM para acessar o perfil de inferência e FMs nas regiões de destino potenciais. Na próxima seção, fornecemos mais detalhes. Você também pode consultar mais informações sobre pré-requisitos para perfis de inferência.

Implementar a inferência cross-region global com modelos Claude 4.5 é simples, exigindo apenas algumas alterações no código de sua aplicação existente. O seguinte é um exemplo de como atualizar seu código em Python:

import boto3
import json

# Connect to Bedrock from your deployed region
bedrock = boto3.client('bedrock-runtime', region_name='af-south-1')

# Use global cross-Region inference inference profile for Opus 4.5 model
model_id = "global.anthropic.claude-opus-4-5-20251101-v1:0"

# Make request - Global CRIS automatically routes to optimal AWS Region globally
response = bedrock.converse(
    messages=[
        {
            "role": "user",
            "content": [{"text": "Explain cloud computing in 2 sentences."}]
        }
    ],
    modelId=model_id,
)

print("Response:", response['output']['message']['content'][0]['text'])
print("Token usage:", response['usage'])
print("Total tokens:", response['usage']['totalTokens'])

Se estiver utilizando a API InvokeModel do Amazon Bedrock, você pode rapidamente alternar entre diferentes modelos mudando o ID do modelo, como mostrado em exemplos de código para invocar modelos.

Requisitos de política IAM para inferência cross-region global

A inferência cross-region global requer três permissões específicas porque o mecanismo de roteamento se estende por múltiplos escopos: seu perfil de inferência regional, a definição de FM em sua região de origem e a definição de FM em nível global. Sem essas três, o serviço não consegue resolver o modelo, validar seu acesso e rotear requisições entre regiões.

O acesso a modelos Anthropic requer uma submissão de caso de uso antes de invocar um modelo. Essa submissão pode ser completada no nível da conta individual ou centralmente através da conta de gerenciamento da organização. Para submeter seu caso de uso, use a API PutUseCaseForModelAccess ou selecione um modelo Anthropic no catálogo de modelos no Console de Gerenciamento da AWS para Amazon Bedrock.

Permissões do AWS Marketplace são necessárias para ativar modelos e podem ser limitadas a IDs de produto específicos quando suportado. A seguinte política IAM fornece controle granular:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "GrantGlobalCrisInferenceProfileRegionAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:af-south-1::inference-profile/global."
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "af-south-1"
      }
    }
  }, {
    "Sid": "GrantGlobalCrisInferenceProfileInRegionModelAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:af-south-1::foundation-model/"
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "af-south-1",
        "bedrock:InferenceProfileArn": "arn:aws:bedrock:af-south-1::inference-profile/global."
      }
    }
  }, {
    "Sid": "GrantGlobalCrisInferenceProfileGlobalModelAccess",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
      "arn:aws:bedrock:::foundation-model/ "
    ],
    "Condition": {
      "StringEquals": {
        "aws:RequestedRegion": "unspecified",
        "bedrock:InferenceProfileArn": "arn:aws:bedrock:af-south-1::inference-profile/global."
      }
    }
  } ]
}

A política compreende três partes. A primeira declaração concede acesso ao perfil de inferência regional em af-south-1, para que usuários possam invocar o perfil de inferência cross-region global especificado a partir da África do Sul. A segunda declaração fornece acesso ao recurso regional de FM, que o serviço precisa para compreender qual modelo está sendo solicitado no contexto regional. A terceira declaração concede acesso ao recurso de FM global, que permite que o roteamento cross-region funcione.

Ao implementar essas políticas, verifique que os três ARNs estejam inclusos:

• O ARN do perfil de inferência regional segue o padrão arn:aws:bedrock:af-south-1::inference-profile/global.. Isso concede acesso ao perfil de inferência global em sua região de origem.
• O FM regional usa arn:aws:bedrock:af-south-1::foundation-model/. Isso concede acesso à definição de modelo em af-south-1.
• O FM global requer arn:aws:bedrock:::foundation-model/. Isso concede acesso ao modelo entre regiões — observe que esse ARN intencionalmente omite os segmentos de região e conta para permitir roteamento cross-region.

Nota importante sobre Políticas de Controle de Serviço (SCPs): Se sua organização usa SCPs específicas por região, verifique que "aws:RequestedRegion": "unspecified" não está incluída na lista de regiões negadas, porque requisições de inferência cross-region global utilizam esse valor de região. Organizações que utilizam SCPs restritivas que negam múltiplas regiões exceto aquelas especificamente aprovadas precisarão permitir explicitamente esse valor para habilitar a funcionalidade de inferência cross-region global.

Se sua organização determinar que a inferência cross-region global não é apropriada para certos cargas de trabalho por requisitos de residência de dados ou conformidade, você pode desabilitá-la de duas maneiras:

• Remover permissões IAM: Remova uma ou mais das três declarações de política IAM necessárias. Como a inferência cross-region global requer as três declarações para funcionar, remover uma delas causa requisições ao perfil de inferência global retornem um erro de acesso negado.
• Implementar uma política de negação explícita: Crie uma política de negação que segmente especificamente perfis de inferência cross-region global usando a condição "aws:RequestedRegion": "unspecified". Essa abordagem documenta claramente sua intenção de segurança, e a negação explícita tem precedência mesmo se políticas de permissão forem acidentalmente adicionadas depois.

Solicitando aumento de limites para inferência cross-region global

Ao utilizar perfis de inferência cross-region global a partir de af-south-1, você pode solicitar aumentos de cota através do Console de Cotas de Serviço da AWS. Como esse é um limite global, requisições devem ser feitas em sua região de origem (af-south-1).

Antes de solicitar um aumento, calcule sua cota necessária utilizando a taxa de redução para seu modelo. Para Sonnet 4.5 e Haiku 4.5, tokens de saída têm uma taxa de redução de cinco vezes — cada token de saída consome 5 tokens de sua cota — enquanto tokens de entrada mantêm uma proporção de 1:1. Seu consumo total de tokens por requisição é:

Contagem de tokens de entrada + Tokens de entrada de escrita em cache + (Contagem de tokens de saída x Taxa de redução)

Para solicitar um aumento de limite:

• Faça login no Console de Cotas de Serviço da AWS em af-south-1
• No painel de navegação, escolha Serviços da AWS
• Localize e escolha Amazon Bedrock
• Pesquise pelas cotas específicas de inferência cross-region global (por exemplo, Tokens de inferência de modelo cross-region global por minuto para Claude Sonnet 4.5 V1)
• Selecione a cota e escolha Solicitar aumento no nível da conta
• Digite seu valor de cota desejado e envie a solicitação

Próximos passos

A inferência cross-region global também traz a família de modelos Claude 4.5 para a região de Cape Town, oferecendo acesso às mesmas capacidades disponíveis em outras regiões. Você pode construir com Sonnet 4.5, Haiku 4.5 e Opus 4.5 a partir de sua região local enquanto a infraestrutura de roteamento gerencia a distribuição transparentemente.

Para começar, atualize suas aplicações para utilizar o ID do perfil de inferência global, configure permissões IAM apropriadas, e monitore o desempenho conforme suas aplicações utilizam a infraestrutura global da AWS. Visite o console do Amazon Bedrock e explore como a inferência cross-region global pode aprimorar suas aplicações de IA.

Para mais informações, consulte os seguintes recursos:

• Aumentar throughput com inferência cross-region
• Regiões e modelos suportados para perfis de inferência
• Usar um perfil de inferência em invocação de modelo

Fonte

Scale AI in South Africa using Amazon Bedrock global cross-Region inference with Anthropic Claude 4.5 models (https://aws.amazon.com/blogs/machine-learning/scale-ai-in-south-africa-using-amazon-bedrock-global-cross-region-inference-with-anthropic-claude-4-5-models/)

O desafio das operações de modelo em escala

Gerenciar fluxos de trabalho de ModelOps (operações de modelos de machine learning) sempre foi uma tarefa complexa e demorada. Equipes que tentaram configurar templates de projeto para seus times de ciência de dados enfrentaram um cenário desafiador: a abordagem anterior exigia o uso do AWS Service Catalog, que demandava configuração de portfolios, produtos e permissões complexas—adicionando sobrecarga administrativa significativa antes do time conseguir construir seus primeiros pipelines de ML.

Esse gargalo administrativo afastava cientistas de dados de suas atividades principais, enquanto que arquitetos e administradores gastavam horas configurando infraestrutura em vez de resolver problemas de negócio.

O caminho simplificado: templates baseados em Amazon S3

A AWS agora oferece uma alternativa mais direta: o Amazon SageMaker AI Projects suporta templates baseados em Amazon S3. Com essa nova capacidade, administradores podem armazenar templates AWS CloudFormation diretamente no Amazon Simple Storage Service (Amazon S3) e gerenciar todo o ciclo de vida usando recursos familiares do S3: versionamento, políticas de ciclo de vida e replicação entre regiões do S3.

Isso significa fornecer ao time de ciência de dados templates de projeto automatizados, com controle de versão e seguros—com uma sobrecarga administrativa significativamente menor.

O que é Amazon SageMaker AI Projects?

O Amazon SageMaker AI Projects permite que times criem, compartilhem e gerenciem projetos de ModelOps completamente configurados. Dentro desse ambiente estruturado, você organiza código, dados e experimentos—facilitando colaboração e reprodutibilidade. Cada projeto pode incluir pipelines de integração e entrega contínua (CI/CD), registros de modelo, configurações de deployment e outros componentes de ModelOps, todos gerenciados dentro do SageMaker AI.

Templates reutilizáveis padronizam práticas de ModelOps ao codificar as melhores práticas para processamento de dados, desenvolvimento de modelos, treinamento, deployment e monitoramento.

Casos de uso principais

Você pode orquestrar diversos cenários usando SageMaker AI Projects:

• Automatizar fluxos de ML: Configure pipelines CI/CD que compilam, testam e deployam modelos automaticamente
• Impor governança e conformidade: Garanta que seus projetos sigam padrões organizacionais para segurança, rede e marcação de recursos
• Acelerar time-to-value: Forneça ambientes pré-configurados para que cientistas de dados se concentrem em problemas de ML, não em infraestrutura
• Melhorar colaboração: Estabeleça estruturas de projeto consistentes para compartilhamento e reutilização de código

Nova funcionalidade: templates de projeto em Amazon S3

A atualização mais recente do SageMaker AI Projects permite que administradores armazenem e gerenciem templates de projeto de ML diretamente no Amazon S3. Esses templates baseados em S3 são uma alternativa menos complicada e mais flexível em relação ao Service Catalog anterior.

Com esse aprimoramento, templates de AWS CloudFormation podem ser versionados, protegidos e compartilhados eficientemente entre times usando os controles de acesso ricos, gerenciamento de ciclo de vida e recursos de replicação fornecidos pelo S3.

Disponibilidade regional e acesso entre contas

Quando você armazena templates no Amazon S3, eles ficam disponíveis em todas as regiões AWS onde SageMaker AI Projects é suportado. Para compartilhar templates entre contas AWS, você pode usar políticas de bucket S3 e controles de acesso entre contas.

Versionamento e auditoria completa

A possibilidade de ativar versionamento no S3 fornece um histórico completo de alterações de template, facilitando auditorias e reversões, além de registrar a evolução do template do projeto de forma imutável.

Migração do Service Catalog

Se seus times atualmente usam templates baseados em Service Catalog, a abordagem baseada em S3 oferece um caminho de migração direto. Ao migrar, as considerações principais envolvem: provisionar novas funções SageMaker para substituir funções específicas do Service Catalog, atualizar referências de template, enviar templates para S3 com marcação adequada e configurar tags no nível do domínio apontando para o bucket de templates.

Para organizações com repositórios de templates centralizados, você deve estabelecer políticas de bucket S3 entre contas para permitir descoberta de templates a partir de contas consumidoras, com cada domínio SageMaker de cada conta consumidora marcado para referenciar o bucket central.

Tanto templates baseados em S3 quanto baseados em Service Catalog aparecem em abas separadas na interface de criação do SageMaker AI Projects, permitindo que organizações introduzam templates em S3 gradualmente sem interromper fluxos de trabalho existentes durante a migração.

Requisitos técnicos para configuração

SageMaker AI Projects com templates em S3 suporta templates CloudFormation personalizados que você cria para o seu caso de uso de ML organizacional. Os templates fornecidos pela AWS (como os templates de projeto ModelOps integrados) continuam disponíveis exclusivamente através do Service Catalog.

Seus templates personalizados devem ser arquivos CloudFormation válidos em formato YAML.

Para começar a usar templates baseados em S3 com SageMaker AI Projects, seu domínio SageMaker deve incluir a tag sagemaker:projectS3TemplatesLocation com o valor s3://<bucket-name>/<prefix>/.

Cada arquivo de template enviado para S3 deve ser marcado com sagemaker:studio-visibility=true para aparecer no console SageMaker AI Studio Projects.

Você precisará conceder acesso de leitura a funções de execução SageMaker na política de bucket S3 e ativar configuração CORS no bucket S3 para permitir ao SageMaker AI Projects acessar os templates S3.

Como integração de templates em S3 funciona na prática

A configuração opera em dois fluxos de trabalho separados: configuração única por administradores e lançamento de projeto por engenheiros de ML e cientistas de dados.

Quando engenheiros de ML e cientistas de dados lançam um novo projeto de ModelOps no SageMaker AI, o SageMaker lança uma pilha (stack) AWS CloudFormation para provisionar os recursos definidos no template. Assim que o processo é concluído, você acessa todos os recursos especificados e os pipelines CI/CD configurados em seu projeto.

Gerenciamento do ciclo de vida de projetos

O gerenciamento do ciclo de vida de projetos lançados pode ser realizado através do console SageMaker Studio, onde usuários navegam para S3 Templates, selecionam um projeto e usam o menu Actions para atualizar ou deletar projetos.

Atualizações de projeto podem ser usadas para modificar parâmetros de template existentes ou a própria URL do template, acionando atualizações de stack CloudFormation que são validadas antes da execução. A exclusão de projeto remove todos os recursos e configurações associadas do CloudFormation.

Essas operações de ciclo de vida também podem ser executadas programaticamente usando as APIs do SageMaker.

Caso de uso: template MLOps integrado com GitHub para times corporativos

Muitas organizações usam GitHub como seu sistema principal de controle de versão e desejam usar GitHub Actions para CI/CD enquanto usam SageMaker para cargas de trabalho de ML. No entanto, configurar essa integração requer a configuração de múltiplos serviços AWS, estabelecer conexões seguras e implementar fluxos de aprovação apropriados—uma tarefa complexa que consome tempo se feita manualmente.

Solução com template baseado em S3

O template baseado em S3 resolve esse desafio ao provisionar um pipeline de ModelOps completo que inclui orquestração CI/CD, componentes de SageMaker Pipelines e automação acionada por eventos.

Esse exemplo de projeto ModelOps com templates baseados em S3 habilita fluxos de trabalho de ModelOps totalmente automatizados e governados. Cada projeto de ModelOps inclui um repositório GitHub pré-configurado com fluxos de Actions e AWS CodeConnections seguras para integração perfeita.

Após commits de código, uma pipeline SageMaker é acionada para orquestrar um processo padronizado envolvendo pré-processamento de dados, treinamento de modelo, avaliação e registro. Para deployment, o sistema suporta staging automatizado na aprovação do modelo, com verificações robustas de validação, uma porta de aprovação manual para promover modelos à produção, e uma arquitetura segura e orientada por eventos usando AWS Lambda e Amazon EventBridge.

Governança e conformidade no fluxo

Em todo o fluxo de trabalho, a governança é suportada pelo SageMaker Model Registry para rastreamento de versões de modelo e linhagem, etapas de aprovação bem-definidas, gerenciamento seguro de credenciais usando AWS Secrets Manager, e padrões consistentes de marcação e nomenclatura para todos os recursos.

Quando cientistas de dados selecionam esse template no SageMaker Studio, eles provisionam um ambiente de ModelOps totalmente funcional através de um processo simplificado. Eles enviam seu código de ML para GitHub usando funcionalidade Git integrada no IDE do Studio, e o pipeline automaticamente lida com treinamento de modelo, avaliação e deployment progressivo através de staging até produção—tudo mantendo requisitos de segurança e conformidade corporativos.

Começando com o template

Instruções de configuração completas e código para esse template de ModelOps estão disponíveis em um repositório GitHub. Após seguir as instruções no repositório, você encontra o template mlops-github-actions na seção SageMaker AI Projects no console SageMaker AI Studio escolhendo Projects no painel de navegação e selecionando a aba Organization templates, depois clicando em Next.

Para lançar o projeto ModelOps, você deve inserir detalhes específicos do projeto, incluindo o campo Role ARN, que deve conter o ARN da função AmazonSageMakerProjectsLaunchRole criada durante a configuração.

Segurança com Launch Roles

Como prática recomendada de segurança, use o Amazon Resource Name (ARN) da função AmazonSageMakerProjectsLaunchRole, não sua função de execução SageMaker. A AmazonSageMakerProjectsLaunchRole é uma função de provisionamento que atua como intermediária durante a criação de projeto ModelOps. Essa função contém todas as permissões necessárias para criar infraestrutura do seu projeto, incluindo funções AWS Identity and Access Management (IAM), buckets S3, AWS CodePipeline e outros recursos AWS.

Ao usar essa launch role dedicada, engenheiros de ML e cientistas de dados podem criar projetos de ModelOps sem exigir permissões mais amplas em suas contas. Sua função de execução SageMaker pessoal permanece limitada em escopo—eles precisam apenas de permissão para assumir a launch role. Essa separação de responsabilidades é importante para manter segurança.

Sem launch roles, cada profissional de ML precisaria de permissões IAM extensas para criar pipelines de código, projetos AWS CodeBuild, buckets S3 e outros recursos AWS diretamente. Com launch roles, precisam apenas de permissão para assumir uma função pré-configurada que lida com o provisionamento em seu nome, mantendo suas permissões pessoais mínimas e seguras.

Após inserir seus detalhes desejados de configuração de projeto e clicar em Next, o template cria dois fluxos de trabalho automatizados de ModelOps—um para construção de modelo e outro para deployment de modelo—que trabalham juntos para fornecer CI/CD para seus modelos de ML. O exemplo completo de ModelOps pode ser encontrado no repositório mlops-github-actions.

Limpeza de recursos

Após deployment, você incorrerá em custos pelos recursos deployados. Se não tenciona continuar usando a configuração, delete os recursos do projeto ModelOps para evitar cobranças desnecessárias.

Para destruir o projeto, abra o SageMaker Studio, clique em More no painel de navegação e selecione Projects. Escolha o projeto que deseja deletar, clique nas reticências acima do canto superior direito da lista de projetos e escolha Delete. Revise as informações na caixa de diálogo Delete project e selecione Yes, delete the project para confirmar. Após a exclusão, verifique que seu projeto não aparece mais na lista.

Além de deletar um projeto, que remove e desprovisiona o SageMaker AI Project, você também precisa deletar manualmente os seguintes componentes se não forem mais necessários: repositórios Git, pipelines, grupos de modelo e endpoints.

Impacto estratégico e conclusão

O provisionamento de templates baseado em Amazon S3 para Amazon SageMaker AI Projects transforma como organizações padronizam operações de ML. Conforme demonstrado neste artigo, um único template AWS CloudFormation pode provisionar um fluxo de trabalho CI/CD completo integrando seu repositório Git (GitHub, Bitbucket ou GitLab), SageMaker Pipelines e SageMaker Model Registry—fornecendo times de ciência de dados com fluxos de trabalho automatizados enquanto mantém controles de governança e segurança corporativos.

Para mais informações sobre SageMaker AI Projects e templates baseados em S3, consulte ModelOps Automation With SageMaker Projects.

Ao usar templates baseados em S3 no SageMaker AI Projects, administradores podem definir e governar a infraestrutura de ML, enquanto engenheiros de ML e cientistas de dados ganham acesso a ambientes de ML pré-configurados através de provisionamento em autoatendimento. Explore o repositório de exemplos GitHub para templates populares de ModelOps e comece hoje seguindo as instruções fornecidas. Você também pode criar templates personalizados adaptados aos requisitos específicos da sua organização, políticas de segurança e frameworks de ML preferidos.

Fonte

Simplify ModelOps with Amazon SageMaker AI Projects using Amazon S3-based templates (https://aws.amazon.com/blogs/machine-learning/simplify-modelops-with-amazon-sagemaker-ai-projects-using-amazon-s3-based-templates/)

Além das Métricas Tradicionais

Avaliar o desempenho de modelos de linguagem grandes vai além de simples métricas estatísticas como perplexidade ou scores BLEU (Bilingual Evaluation Understudy). Na maioria dos cenários reais de IA generativa, o que realmente importa é entender se um modelo produz resultados melhores que uma versão anterior ou uma linha de base. Isso é particularmente crítico em aplicações como sumarização, geração de conteúdo ou agentes inteligentes, onde julgamentos subjetivos e correção contextual são essenciais.

As organizações que aprofundam a implantação desses modelos em produção enfrentam um desafio crescente: como avaliar sistematicamente a qualidade além dos métodos tradicionais? Abordagens convencionais como medidas de acurácia e avaliações baseadas em regras, embora úteis, não conseguem capturar completamente as necessidades de avaliação nuanceadas, especialmente quando as tarefas exigem julgamentos subjetivos, compreensão contextual ou alinhamento com requisitos comerciais específicos.

A Abordagem LLM-as-a-Judge

Para preencher essa lacuna, emergiu a abordagem conhecida como LLM-as-a-Judge (Modelo de Linguagem como Juiz), que aproveita as capacidades de raciocínio de modelos de linguagem para avaliar outros modelos de forma mais flexível e em larga escala.

A Amazon Nova agora oferece o recurso LLM-as-a-Judge integrado ao Amazon SageMaker AI, um serviço gerenciado da Amazon Web Services (AWS) para construir, treinar e implantar modelos de aprendizado de máquina em escala. O Amazon Nova LLM-as-a-Judge foi projetado para entregar avaliações robustas e imparciais dos resultados de IA generativa em diferentes famílias de modelos.

O recurso está disponível como workflows otimizados no SageMaker AI, permitindo começar a avaliar o desempenho de modelos contra seus casos de uso específicos em minutos. Ao contrário de muitos avaliadores que apresentam vieses arquiteturais, o Amazon Nova LLM-as-a-Judge foi rigorosamente validado para manter imparcialidade e alcançou desempenho líder em benchmarks importantes de juízes, refletindo de perto as preferências humanas.

Treinamento e Validação do Nova LLM-as-a-Judge

O Amazon Nova LLM-as-a-Judge foi construído através de um processo de treinamento em múltiplas etapas, combinando treinamento supervisionado e estágios de aprendizado por reforço que utilizaram datasets públicos anotados com preferências humanas.

Para o componente proprietário, múltiplos anotadores avaliaram independentemente milhares de exemplos, comparando pares de respostas de diferentes modelos de linguagem para o mesmo prompt. Todas as anotações passaram por verificações rigorosas de qualidade, com julgamentos finais calibrados para refletir consenso amplo de humanos, em vez de um ponto de vista individual. Os dados de treinamento foram projetados para serem diversos e representativos, abrangendo categorias que incluem conhecimento do mundo real, criatividade, codificação, matemática, domínios especializados e toxicidade. Os dados incluem informações de mais de 90 idiomas, sendo principalmente compostos por inglês, russo, chinês, alemão, japonês e italiano.

Um estudo interno de viés, avaliando mais de 10 mil julgamentos de preferência humana contra 75 modelos de terceiros, confirmou que o Amazon Nova LLM-as-a-Judge apresenta apenas 3% de viés agregado em relação às anotações humanas — um resultado significativo na redução de viés sistemático. Mesmo com esse desempenho, a AWS recomenda verificações ocasionais para validar comparações críticas.

O Amazon Nova LLM-as-a-Judge alcança desempenho avançado entre modelos de avaliação, demonstrando forte alinhamento com julgamentos humanos em uma gama de tarefas. Por exemplo, atinge 45% de acurácia no JudgeBench (comparado a 42% do Meta J1 8B) e 68% no PPE (versus 60% do Meta J1 8B). Esses resultados destacam a força do Amazon Nova LLM-as-a-Judge em avaliações relacionadas a chatbots.

Fluxo de Trabalho de Avaliação

O processo de avaliação começa preparando um dataset no qual cada exemplo inclui um prompt e duas respostas alternativas de modelos. O formato JSONL segue este padrão:

{ "prompt":"Explain photosynthesis.", "response_A":"Answer A...", "response_B":"Answer B..." }
{ "prompt":"Summarize the article.", "response_A":"Answer A...", "response_B":"Answer B..." }

Após preparar esse dataset, utiliza-se uma receita de avaliação do SageMaker que configura a estratégia de avaliação, especifica qual modelo será usado como juiz e define as configurações de inferência, como temperatura e top_p. A avaliação é executada dentro de um job de treinamento do SageMaker usando contêineres pré-construídos do Amazon Nova. O SageMaker AI provisiona recursos de computação, orquestra a avaliação e escreve as métricas de saída e visualizações no Amazon Simple Storage Service (S3). Quando concluído, é possível baixar e analisar os resultados, que incluem distribuições de preferência, taxas de vitória e intervalos de confiança.

Método de Avaliação Binária

O Amazon Nova LLM-as-a-Judge utiliza um método de avaliação chamado binary overall preference judge (juiz de preferência geral binária). Esse método compara dois resultados lado a lado e escolhe o melhor ou declara um empate. Para cada exemplo, produz uma preferência clara. Quando essas avaliações são agregadas em muitas amostras, geram métricas como taxa de vitória e intervalos de confiança.

Esta abordagem usa o raciocínio do próprio modelo para avaliar qualidades como relevância e clareza de forma direta e consistente. O modelo de juiz fornece preferências gerais de baixa latência em situações onde feedback granular não é necessário. A saída é uma de [[A>B]] ou [[B>A]].

Interpretando as Métricas de Avaliação

Ao usar o framework do Amazon Nova LLM-as-a-Judge para comparar resultados de dois modelos de linguagem, o SageMaker AI produz um conjunto abrangente de métricas quantitativas. Os resultados se dividem em três categorias principais: métricas de preferência central, métricas de confiança estatística e métricas de erro padrão.

Métricas de preferência central: O a_scores conta quantos exemplos favoreceram o Modelo A, enquanto b_scores conta casos em que o Modelo B foi escolhido como melhor. O campo ties captura instâncias onde o modelo juiz classificou ambas as respostas igualmente ou não conseguiu identificar uma preferência clara. O inference_error conta casos em que o juiz não conseguiu gerar um julgamento válido.

Métricas de confiança estatística: O winrate reporta a proporção de todas as comparações válidas em que o Modelo B foi preferido. Os campos lower_rate e upper_rate definem os limites inferior e superior do intervalo de confiança de 95% para essa taxa de vitória. Por exemplo, um winrate de 0,75 com intervalo de confiança entre 0,60 e 0,85 sugere que, mesmo contabilizando incerteza, o Modelo B é consistentemente favorecido.

Métricas de erro padrão: Incluem a_scores_stderr, b_scores_stderr, ties_stderr, inference_error_stderr e score_stderr. Valores menores indicam resultados mais confiáveis; valores maiores podem apontar para a necessidade de dados de avaliação adicionais.

Interpretar essas métricas requer atenção tanto às preferências observadas quanto aos intervalos de confiança: se o winrate está substancialmente acima de 0,5 e o intervalo de confiança não inclui 0,5, o Modelo B é estatisticamente favorecido. Inversamente, se o winrate está abaixo de 0,5 e o intervalo está completamente abaixo de 0,5, o Modelo A é preferido. Quando o intervalo de confiança sobrepõe 0,5, os resultados são inconclusivos.

Implementação Prática

Para demonstrar a implementação, a AWS oferece um notebook que guia pelo fluxo completo de trabalho. O código primeiro prepara um dataset amostrando questões do SQuAD (Stanford Question Answering Dataset) e gerando respostas candidatas. Os resultados são salvos em um arquivo JSONL contendo o prompt e ambas as respostas.

Um estimador PyTorch lança um job de avaliação usando uma receita do Amazon Nova LLM-as-a-Judge, executando em instâncias GPU como ml.g5.12xlarge e produzindo métricas de avaliação, incluindo taxas de vitória, intervalos de confiança e contagens de preferência. Os resultados são salvos no S3 para análise.

Uma função de visualização renderiza gráficos e tabelas, resumindo qual modelo foi preferido, quão forte foi a preferência e quão confiáveis são as estimativas. Através dessa abordagem de ponta a ponta, é possível avaliar melhorias, rastrear regressões e tomar decisões baseadas em dados sobre qual modelo generativo implantar — tudo sem anotação manual.

Casos de Uso

O framework do Amazon Nova LLM-as-a-Judge oferece uma forma confiável e repetível de comparar dois modelos de linguagem com seus próprios dados. Pode ser integrado em pipelines de seleção de modelo para decidir qual versão apresenta melhor desempenho, ou agendado como parte de uma avaliação contínua para detectar regressões ao longo do tempo. Para equipes construindo sistemas específicos de domínio ou baseados em agentes, essa abordagem fornece insights mais ricos do que métricas automatizadas isoladamente. Como todo o processo é executado em jobs de treinamento do SageMaker, escala rapidamente e produz relatórios visuais claros que podem ser compartilhados com stakeholders.

Próximos Passos

Para começar a jornada de avaliação de modelos de linguagem, recomenda-se explorar a documentação oficial do Amazon Nova e exemplos práticos. A comunidade AWS de IA/ML oferece recursos extensos, incluindo workshops e orientação técnica, para apoiar sua jornada de implementação.

Fonte

Evaluating generative AI models with Amazon Nova LLM-as-a-Judge on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/evaluating-generative-ai-models-with-amazon-nova-llm-as-a-judge-on-amazon-sagemaker-ai/)