Blog

Novos controles de precisão para a Busca Web no Bedrock

A AWS anunciou duas novas funcionalidades para a Busca Web no AWS Bedrock, ampliando o controle que os desenvolvedores têm sobre os resultados que fundamentam as respostas dos modelos de linguagem: a filtragem de domínios e o controle de localização do usuário. Ambas as configurações são aplicadas diretamente na ferramenta web_search, dentro das requisições existentes à API de Respostas do OpenAI.

Filtragem de domínios

Com a filtragem de domínios, é possível restringir os resultados da Busca Web a um conjunto específico de domínios escolhidos pelo desenvolvedor. Por meio do parâmetro filters, a configuração aceita até 100 domínios permitidos (allowed_domains), limitando os resultados apenas a fontes confiáveis, ou até 100 domínios bloqueados (blocked_domains), excluindo fontes indesejadas.

Esse recurso é especialmente útil em cenários onde o objetivo é garantir que as respostas do modelo sejam embasadas apenas em sites específicos — ou, ao contrário, quando há necessidade de impedir que determinados domínios apareçam nos resultados.

Controle de localização do usuário

A segunda novidade permite que os desenvolvedores informem, de forma opcional, parâmetros de localização geográfica para que a Busca Web retorne resultados relevantes para aquela região. Isso é particularmente útil em perguntas que dependem de contexto geográfico, como disponibilidade regional de serviços ou informações sobre negócios locais.

Disponibilidade

A filtragem de domínios e o controle de localização do usuário estão disponíveis em todas as regiões da AWS onde a Busca Web é suportada:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• AWS GovCloud (US-West)

Para começar a usar, a AWS indica a seção de Busca Web na documentação oficial do AWS Bedrock. Informações sobre preços estão disponíveis na página de preços do AWS Bedrock.

Fonte

Web Search on AWS Bedrock now supports domain filtering and user location controls (https://aws.amazon.com/about-aws/whats-new/2026/10/bedrock-web-search-domain-user-location/)

O problema: por que atualizar endpoints com auto scaling falha

Quem trabalha com endpoints de inferência em tempo real no Amazon SageMaker AI já deve ter se deparado com uma situação frustrante: ao tentar atualizar a configuração do endpoint — seja mudando o tipo de instância, a quantidade de instâncias ou variáveis de ambiente — o deploy via AWS CloudFormation ou Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) simplesmente falha.

O motivo é uma exigência do próprio SageMaker AI: antes de atualizar o endpoint, é necessário desregistrar o scalable target do Auto Scaling de Aplicações da AWS (Application Auto Scaling). O problema é que, ao fazer isso, o CloudFormation perde o rastreamento desse recurso — e aí começa uma série de falhas em cascata.

A AWS documentou em detalhes os três modos de falha mais comuns nesse cenário:

• Atualizar a configuração com o auto scaling ainda registrado: o CloudFormation tenta atualizar o endpoint enquanto o scalable target ainda está ativo. O SageMaker AI rejeita a operação com o erro: The variant(s) "[AllTraffic]" must be deregistered as scalable targets with Application Auto Scaling before they can be removed or have their instance type updated.
• Desregistrar manualmente e atualizar apenas a configuração do endpoint: o deploy funciona, mas o CloudFormation não reregistra o auto scaling — porque os parâmetros de auto scaling no template não mudaram. O endpoint fica rodando sem auto scaling, sem qualquer erro visível. Um problema silencioso e perigoso.
• Desregistrar manualmente e alterar também os parâmetros de auto scaling: o CloudFormation tenta atualizar um recurso AWS::ApplicationAutoScaling::ScalableTarget que não existe mais, gerando falha. O pior: o rollback também falha (UPDATE_ROLLBACK_FAILED), deixando a stack em estado corrompido que exige intervenção manual no console do CloudFormation.

A solução: um construct CDK com recursos personalizados do CloudFormation

Para resolver esse problema de forma robusta e reutilizável, a AWS propõe substituir os recursos nativos AWS::ApplicationAutoScaling::ScalableTarget e AWS::ApplicationAutoScaling::ScalingPolicy por três recursos personalizados do CloudFormation (CloudFormation custom resources), orquestrados por um construct do CDK.

Esses recursos personalizados gerenciam o ciclo completo de deregistro e reregistro do auto scaling em torno da atualização do endpoint, com ordenação explícita de dependências via chamadas node.add_dependency no CDK. A sequência completa de execução é:

• Deregistro (custom resource): remove o scalable target antes de qualquer atualização do endpoint. No primeiro deploy, como ainda não existe nenhum scalable target, o handler trata o erro graciosamente e continua.
• Atualização do endpoint (gerenciada pelo CDK): o CDK atualiza o recurso de endpoint normalmente, aplicando a nova configuração.
• Registro do Scalable Target (custom resource): aguarda o endpoint atingir o status InService e então registra o scalable target.
• Aplicação da Scaling Policy (custom resource): aguarda o scalable target estar disponível para consulta e então aplica a política de rastreamento de alvo (target tracking policy).

Os dois últimos recursos utilizam o padrão de conclusão assíncrona do provedor CDK: cada um tem um handler on_event que retorna imediatamente e um handler is_complete que é reinvocado em intervalos de 30 segundos até que a verificação de prontidão seja aprovada. O timeout total é de 1 hora para o registro do scalable target e 15 minutos para a aplicação da política — limites que não dependem do timeout de nenhuma invocação individual do AWS Lambda.

Uma propriedade chamada ConfigHash em cada recurso personalizado força o CloudFormation a reinvocar as funções Lambda sempre que qualquer valor de configuração muda. Por isso, a configuração do endpoint e os parâmetros de auto scaling são definidos juntos: um único ConfigHash dispara toda a orquestração.

O que é implantado na stack

Embora o construct defina três recursos personalizados, a stack implantada contém mais recursos do que isso. Cada recurso personalizado é suportado por um cr.Provider do CDK, e o framework do provedor gera suas próprias funções auxiliares Lambda. No total, a stack implantada contém:

• Três recursos personalizados
• Duas máquinas de estado do AWS Step Functions
• Doze funções Lambda (cinco com código próprio do construct, sete geradas pelo framework do provedor)

As funções geradas pelo framework não precisam ser escritas nem mantidas manualmente, mas é importante contabilizá-las ao revisar os recursos implantados.

Passo a passo: implantando e testando a solução

O código-fonte completo está disponível no repositório GitHub de exemplo. O walkthrough cobre quatro etapas principais.

Pré-requisitos

Para seguir o passo a passo, são necessários:

• Uma conta AWS com permissões para Amazon SageMaker AI, AWS Lambda, Gerenciamento de Identidade e Acesso (IAM), Application Auto Scaling e Amazon CloudWatch
• AWS CDK v2 instalado
• Python 3.12 ou superior
• uv para gerenciamento de dependências Python
• Um artefato de modelo SageMaker AI no Amazon S3 e uma imagem de container no Amazon ECR, ou um container de algoritmo nativo do SageMaker AI

Clonando o repositório e instalando dependências

git clone https://github.com/aws-samples/sample-sagemaker-endpoint-autoscaling.git
cd sample-sagemaker-endpoint-autoscaling

uv sync

Configurando o endpoint e os parâmetros de auto scaling

As configurações do endpoint e do auto scaling são definidas juntas no arquivo config/config.yaml, pois um único config_hash controla toda a orquestração. Qualquer alteração em qualquer uma das seções dispara a sequência completa.

endpoint:
  endpoint_name: "my-model-endpoint"
  image: "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-model:latest"
  model_data_url: "s3://my-bucket/models/model.tar.gz"
  instance_type: "ml.m5.large"
  initial_instance_count: 1
  environment: {}

autoscaling:
  min_capacity: 1
  max_capacity: 10
  target_value: 100
  scale_in_cooldown: 600
  scale_out_cooldown: 120

Os parâmetros de endpoint mapeiam para as APIs CreateModel e CreateEndpointConfig do SageMaker AI. Os parâmetros de auto scaling mapeiam para as APIs RegisterScalableTarget e PutScalingPolicy do Application Auto Scaling.

Implantando e verificando

uv run cdk bootstrap
uv run cdk deploy InferenceStack

Após o deploy, é possível verificar se o scalable target foi registrado corretamente:

aws application-autoscaling describe-scalable-targets \
  --service-namespace sagemaker \
  --resource-ids endpoint/my-model-endpoint/variant/AllTraffic

E verificar se a política de escalonamento foi aplicada:

aws application-autoscaling describe-scaling-policies \
  --service-namespace sagemaker \
  --resource-id endpoint/my-model-endpoint/variant/AllTraffic

Testando uma atualização

Para testar, basta alterar um valor no config.yaml — por exemplo, mudar o tipo de instância de ml.m5.large para ml.m5.xlarge — e reimplantar:

uv run cdk deploy InferenceStack

Após o deploy, a verificação com o comando describe-scalable-targets deve confirmar que o auto scaling continua registrado e com os valores atualizados.

Integrando com uma stack existente

Quem já possui uma stack CDK com recursos SageMaker AI pode integrar o construct diretamente, sem precisar usar o exemplo completo. Basta copiar o diretório sagemaker_autoscaling/constructs/ para o projeto e adicionar o construct junto aos recursos de endpoint existentes:

import json
from sagemaker_autoscaling.constructs.sagemaker_autoscaling_construct import (
    AutoscalingConfig,
    SagemakerAutoscalingConstruct,
    SagemakerAutoscalingProps,
)

# Both endpoint and auto scaling values must be in config_hash so that
# a change to either triggers the auto scaling orchestration.
config_hash = json.dumps({
    "endpoint": {
        "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-model:latest",
        "modelDataUrl": "s3://my-bucket/models/model.tar.gz",
        "instanceType": "ml.m5.large",
        "initialInstanceCount": 1,
    },
    "autoscaling": {
        "minCapacity": 1,
        "maxCapacity": 10,
        "targetValue": 100,
        "scaleInCooldown": 600,
        "scaleOutCooldown": 120,
    },
})

SagemakerAutoscalingConstruct(
    self,
    "Autoscaling",
    props=SagemakerAutoscalingProps(
        endpoint=your_endpoint,  # your CfnEndpoint
        autoscaling=AutoscalingConfig(
            min_capacity=1,
            max_capacity=10,
            target_value=100,
            scale_in_cooldown=600,
            scale_out_cooldown=120,
        ),
        config_hash=config_hash,
    ),
)

Como o construct funciona internamente

Deregistro

O recurso personalizado de deregistro chama deregister_scalable_target antes da atualização do endpoint. Ele trata a exceção ObjectNotFoundException para o caso de primeiro deploy, onde nenhum scalable target existe ainda:

def handler(event, context):
    resource_id = event["ResourceProperties"]["ResourceId"]
    if event["RequestType"] in ("Create", "Update"):
        try:
            client.deregister_scalable_target(
                ServiceNamespace="sagemaker",
                ResourceId=resource_id,
                ScalableDimension="sagemaker:variant:DesiredInstanceCount",
            )
        except client.exceptions.ObjectNotFoundException:
            pass  # No scalable target on first deploy
    return {"PhysicalResourceId": f"deregister-{resource_id}"}

Registro do Scalable Target

Mesmo que o CloudFormation considere o recurso de endpoint como completo assim que a atualização é aceita, o scalable target só pode ser registrado depois que o endpoint atinge o status InService. O handler on_event retorna imediatamente, e o waiter do provedor reinvoca o is_complete em intervalos até que o endpoint esteja pronto:

def handler(event, context):
    props = event["ResourceProperties"]
    resource_id = props["ResourceId"]
    endpoint_name = resource_id.split("/")[1]

    if event["RequestType"] == "Delete":
        return {"IsComplete": True}

    status = sm_client.describe_endpoint(EndpointName=endpoint_name)["EndpointStatus"]
    if status == "Failed":
        raise Exception("Endpoint in Failed state")
    if status != "InService":
        return {"IsComplete": False}

    as_client.register_scalable_target(
        ServiceNamespace="sagemaker",
        ResourceId=resource_id,
        ScalableDimension="sagemaker:variant:DesiredInstanceCount",
        MinCapacity=int(props["MinCapacity"]),
        MaxCapacity=int(props["MaxCapacity"]),
    )
    return {"IsComplete": True}

Na exclusão da stack, o handler on_event desregistra o scalable target para limpeza dos recursos.

Aplicação da Scaling Policy

Existe uma janela breve após o retorno de RegisterScalableTarget em que o target ainda não está disponível para consulta. O mesmo padrão assíncrono é usado: o handler on_event retorna imediatamente, e o is_complete reporta conclusão apenas quando o scalable target está consultável, aplicando então a política:

def handler(event, context):
    props = event["ResourceProperties"]
    resource_id = props["ResourceId"]

    if event["RequestType"] == "Delete":
        return {"IsComplete": True}

    resp = client.describe_scalable_targets(
        ServiceNamespace="sagemaker",
        ResourceIds=[resource_id],
        ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    )
    if not resp.get("ScalableTargets"):
        return {"IsComplete": False}

    client.put_scaling_policy(
        PolicyName=props["PolicyName"],
        ServiceNamespace="sagemaker",
        ResourceId=resource_id,
        ScalableDimension="sagemaker:variant:DesiredInstanceCount",
        PolicyType="TargetTrackingScaling",
        TargetTrackingScalingPolicyConfiguration=json.loads(props["ScalingPolicyConfig"]),
    )
    return {"IsComplete": True}

Limpeza dos recursos

Para evitar cobranças desnecessárias após os testes, basta destruir a stack:

uv run cdk destroy InferenceStack

Esse comando remove o endpoint do SageMaker AI, a configuração de endpoint, o modelo, as funções Lambda, as roles do IAM, os alarmes do Amazon CloudWatch criados pela política de rastreamento de alvo e desregistra o scalable target.

Conclusão

A solução apresentada pela AWS resolve de forma elegante um problema real e recorrente: manter o auto scaling funcionando corretamente em endpoints SageMaker AI durante atualizações de configuração, sem exigir intervenção manual. O construct CDK reutilizável encapsula toda a orquestração com três recursos personalizados, ordenação explícita de dependências e um mecanismo de ConfigHash que garante que qualquer mudança — seja no endpoint ou nos parâmetros de escalonamento — dispare o fluxo completo.

Para mais informações sobre o Application Auto Scaling para SageMaker AI, consulte a documentação Escalonamento automático de modelos Amazon SageMaker AI. Para mais detalhes sobre recursos personalizados do CloudFormation, consulte o Guia do Usuário do AWS CloudFormation.

Fonte

Orchestrating SageMaker AI endpoint auto scaling with AWS CDK (https://aws.amazon.com/blogs/machine-learning/orchestrating-sagemaker-ai-endpoint-auto-scaling-with-aws-cdk/)

O que mudou no Amazon Polly Generative

A AWS acaba de lançar uma atualização significativa no motor Generative do Amazon Polly, seu serviço de conversão de texto em fala. A nova versão entrega vozes mais expressivas, pronúncia mais precisa e baixa latência. Além disso, chegam 14 novas vozes em 9 localidades, incluindo a disponibilidade geral de vozes generativas em hindi e finlandês pela primeira vez.

Um ponto importante para quem já usa o serviço: trata-se de uma atualização transparente. Os nomes das vozes e as chamadas de API permanecem iguais, ou seja, aplicações existentes continuam funcionando sem nenhuma alteração de código.

O Amazon Polly é um serviço totalmente gerenciado da AWS que converte texto em fala com som natural. Ele atende cenários como contact centers, aplicações baseadas em Modelos de Linguagem de Grande Escala (LLM), mídia e entretenimento, e-learning, acessibilidade e outras aplicações que exigem saída de voz confiável em escala.

Ouça a diferença

A AWS disponibiliza amostras de áudio para que os usuários avaliem diretamente as melhorias. Veja alguns exemplos do que a atualização entrega:

Vozes mais naturais e expressivas

A voz Tiffany demonstra um tom acolhedor e agradável ao se apresentar: “Hi there! I’m Tiffany, one of Polly’s generative voices. I was built to sound natural, expressive, and a little bit delightful. What should we talk about?”

Pronúncia precisa de números, moedas e endereços

A voz Kenneth lê uma confirmação de pedido com número de rastreamento, data, horário, valor monetário e endereço de forma precisa: “Thanks for calling. Your order, number 4471 9902 ships today to 85 Harbor View Drive, Apartment 4B, Portland, Oregon 97209. It should arrive on Thursday, October 22nd, between 9 AM and 1 PM. Your total was $1,284.50 and your confirmation code is K-7-Q-2-X-9.”

Novos idiomas: hindi e finlandês

As vozes Arjun e Kiara para hindi, e Suvi para finlandês, estão disponíveis pela primeira vez no motor Generative do Amazon Polly. São vozes que demonstram naturalidade em seus respectivos idiomas, com entonação e ritmo adequados para cada contexto.

Estilos de fala baseados no contexto textual

Um dos avanços mais interessantes é que as vozes do novo motor Generative conseguem refletir emoção e prosódia com base no texto de entrada, sem necessidade de configuração manual. O mesmo texto pode soar neutro, incerto ou surpreso dependendo de como é escrito:

• Neutro: “Your package arrived early.”
• Incerteza: “So, um… your package arrived early. I think?”
• Surpresa: “Wait, what? Your package arrived early?”

Novas vozes, idiomas e disponibilidade regional

Com esta atualização, o catálogo do motor Generative do Amazon Polly passa a contar com:

• 57 vozes generativas em 11 idiomas e 25 localidades
• 14 novas vozes em 9 localidades: inglês americano (Kenneth, Nate), inglês australiano (Russell, Curtis), inglês indiano (Kiara, Arjun), alemão (Tina), espanhol americano (Carlos), português brasileiro (Leo, Carolina), coreano (Hyunduk), hindi (Kiara, Arjun) e finlandês (Suvi)
• Novos idiomas no motor Generative: hindi e finlandês com disponibilidade geral
• Expansão regional para AWS GovCloud (US-West), totalizando 11 regiões AWS

Vale destacar para o público brasileiro: as vozes Leo e Carolina em português brasileiro estão entre as novidades dessa atualização.

Pronto para produção em ambientes corporativos

O motor Generative atualizado utiliza a chamada de API padrão do Amazon Polly. Isso significa que equipes podem continuar construindo com os padrões familiares da AWS: mesma API do Amazon Polly, controle de acesso via Gerenciamento de Identidade e Acesso (IAM), integração com aplicações e fluxos de contact center existentes, e monitoramento das cargas de trabalho que sintetizam fala.

Para aplicações que já utilizam vozes generativas do Amazon Polly, a atualização acontece automaticamente — sem necessidade de alteração de código. Para novas aplicações, a mesma API SynthesizeSpeech dá acesso ao catálogo expandido de vozes generativas.

Com a API de streaming bidirecional StartSpeechSynthesisStream, é possível enviar texto para o Amazon Polly e receber áudio sintetizado simultaneamente. Isso é especialmente adequado para aplicações em tempo real, como agentes de voz e personagens em jogos.

Preço-performance competitivo

O motor Generative do Amazon Polly opera em modelo de pagamento por uso. Com esta atualização do modelo, a qualidade e a precisão das vozes melhoram pelo mesmo preço — sem aumento de custo, sem novo SKU e sem alterações na integração existente. Além disso, é possível armazenar em cache e reproduzir prompts estáticos sintetizados sem custo adicional. Consulte a página de preços do Amazon Polly para informações completas.

O motor Generative agora combina fala mais natural e expressiva com streaming de baixa latência para aplicações em tempo real, suporte a Linguagem de Marcação para Síntese de Fala (SSML) para controle refinado, e a confiabilidade operacional de um serviço totalmente gerenciado da AWS.

O que é possível construir

Contact centers

Em conversas de atendimento ao cliente, a precisão é fundamental. Quando um cliente consulta um pedido, uma voz que lê corretamente o número de rastreamento, endereço e código de confirmação ajuda a resolver a chamada em autoatendimento, sem escalar para um agente humano. A pronúncia precisa de entidades e a geração de baixa latência tornam as interações automatizadas de Resposta de Voz Interativa (IVR) mais naturais.

Agentes de voz em cascata

Usando o Amazon Polly em um framework de agente de voz, é possível converter o texto de resposta de um LLM em fala clara e natural, transmitindo de volta para os usuários em tempo quase real via WebSockets ou canais de telefonia. Os principais benefícios são reprodução de baixa latência, alta escalabilidade e eficiência de custo.

Mídia, localização e dublagem

O serviço permite converter roteiros em áudio finalizado para vídeo, publicidade, podcasts, apresentações de produtos e audiolivros — sem necessidade de estúdio de gravação. A entonação mais natural reduz o trabalho de pós-produção. A cobertura expandida de localidades, incluindo hindi e finlandês generativos pela primeira vez, possibilita localizar um mesmo conteúdo para mais mercados a partir do mesmo pipeline.

E-learning e treinamento

Permite narrar cursos, onboarding e artigos de base de conhecimento em escala, atualizando a narração assim que o texto fonte muda — sem necessidade de regravar. A entrega mais expressiva favorece o engajamento em materiais de longa duração.

Acessibilidade

Oferece uma versão falada clara e natural de artigos, documentos e aplicações, para que mais pessoas possam consumir conteúdo ouvindo: leitura em voz alta, em movimento ou com leitor de tela.

Experiências interativas e transacionais

É possível habilitar voz em jogos, quiosques, menus IVR e dispositivos de Internet das Coisas (IoT) com respostas geradas sob demanda. O Amazon Polly é indicado quando a voz precisa soar natural e ler nomes, números, detalhes de produtos, endereços e confirmações de forma confiável.

Caso de uso real: Sanoma Media Finland

A Sanoma Media Finland compartilhou sua experiência com o serviço: “Na Sanoma Media Finland, usamos o Amazon Polly para transformar nossos artigos de notícias em tempo real em áudio, dando ao ouvinte a opção de ouvir quando for mais conveniente. Hoje publicamos mais de 10.000 artigos por mês usando a voz neural finlandesa do Polly. Com base em nossos testes, a nova voz generativa Suvi é uma melhoria clara em relação à voz neural anterior — soa notavelmente mais natural e proporciona uma experiência mais agradável para o ouvinte.” — Justus Reinikainen, Product Manager, Sanoma Media Finland.

Como começar

As novas vozes podem ser acessadas pelo Console de Gerenciamento da AWS, pela Interface de Linha de Comando da AWS (AWS CLI) ou pelos SDKs da AWS.

Pré-requisitos:

• Conta AWS ativa com acesso ao Amazon Polly
• AWS CLI instalada e configurada
• Python 3.10+
• Boto3 instalado: pip install boto3
• Permissões IAM: polly:SynthesizeSpeech

Veja um exemplo usando o SDK da AWS para Python (Boto3) com a API SynthesizeSpeech e uma voz generativa:

import boto3

polly = boto3.client("polly", region_name="us-east-1")

response = polly.synthesize_speech(
    Text="Hello! This is Amazon Polly's next-generation generative voice.",
    VoiceId="Kenneth",       # any generative voice in the catalogue
    Engine="generative",
    OutputFormat="mp3",
)

with open("speech.mp3", "wb") as f:
    f.write(response["AudioStream"].read())

Também é possível fazer a mesma requisição via AWS CLI:

aws polly synthesize-speech \
  --region us-east-1 \
  --voice-id Kenneth \
  --engine generative \
  --output-format mp3 \
  --text "Hello! This is Amazon Polly's next-generation generative voice." \
  speech.mp3

Para recuperar a lista completa e atualizada de vozes programaticamente, utilize a chamada DescribeVoices. Isso pode ser usado em verificações de deploy para confirmar que uma voz generativa selecionada está disponível na região onde a aplicação roda.

Disponibilidade

O motor Generative de nova geração e as novas vozes já estão disponíveis. As 14 novas vozes generativas estão disponíveis nas seguintes regiões AWS: US East (N. Virginia), US West (Oregon), Europe (Frankfurt), Europe (Zurich), Europe (London), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Tokyo), Canada (Central) e AWS GovCloud (US-West).

Por público-alvo:

• Desenvolvedores: basta chamar synthesize_speech com Engine="generative" na aplicação existente. Nenhuma outra mudança é necessária.
• Equipes de contact center: as melhorias chegam automaticamente aos fluxos do Amazon Connect e Genesys.
• Todos: é possível acessar qualquer voz no console do Amazon Polly.

Pontos importantes:

• Vozes standard e neural não são afetadas pela atualização.
• Marcações de fala (speech marks) não estão disponíveis em vozes generativas. Caso a aplicação precise delas, as vozes standard e neural continuam com suporte.
• O motor Generative continua suportando tags SSML compatíveis.
• Verifique a disponibilidade de vozes em tempo de execução usando DescribeVoices ou o console ao fazer deploy em diferentes regiões.

Conclusão

O motor Generative de nova geração do Amazon Polly já está disponível, entregando vozes mais naturais e precisas, com 14 novas vozes — incluindo hindi e finlandês generativos pela primeira vez — e sem necessidade de alteração de código para quem já usa o serviço. Consulte a página de preços do Amazon Polly para informações de custo. Para começar, acesse o console do Amazon Polly para testar as vozes e consulte a documentação do Amazon Polly para construir com elas.

Fonte

Amazon Polly delivers a major upgrade to its Generative engine (https://aws.amazon.com/blogs/machine-learning/amazon-polly-delivers-a-major-upgrade-to-its-generative-engine/)

Controle total sobre o loop de treinamento, sem gerenciar infraestrutura

A AWS anunciou que o Amazon SageMaker AI agora oferece suporte a APIs de sessão de treinamento para customização serverless de modelos. A novidade dá às equipes controle completo sobre o algoritmo de pós-treinamento, sem a necessidade de provisionar ou gerenciar infraestrutura de GPU.

Como funciona

Até então, o SageMaker AI já disponibilizava técnicas gerenciadas — como Ajuste Fino Supervisionado (SFT), Otimização de Preferência Direta (DPO) e outros métodos de aprendizado por reforço — onde o cliente simplesmente escolhia a técnica e o modelo, e o serviço cuidava de todo o treinamento.

Com as novas APIs de sessão de treinamento, o cenário muda: as equipes passam a escrever o próprio loop de treinamento. Isso abre espaço para reproduzir SFT ou DPO com lógica própria, implementar uma função de perda customizada, criar um novo sinal de recompensa para aprendizado por reforço, definir um currículo de dados ou aplicar um algoritmo diretamente da literatura científica mais recente.

Operações como forward_backward(), optim_step() e sample() tornam-se chamadas de API contra uma sessão ativa e stateful. Com isso, o time compõe o procedimento de treinamento que precisar, enquanto o SageMaker AI cuida de:

• Alocação de GPU
• Carregamento do modelo e do LoRA
• Execução distribuída
• Recuperação de falhas
• Armazenamento de checkpoints
• Segurança

Modelo de cobrança e cookbook de receitas

A cobrança é feita por token processado, o que significa que computações locais — como o cálculo de pontuação de recompensa — não são tarifadas como tempo de GPU. Isso representa um modelo mais justo para fluxos de trabalho que combinam processamento local com execução remota.

Junto com as APIs, a AWS também está lançando o SageMaker Training Sessions Cookbook, um conjunto de receitas prontas para execução de SFT e aprendizado por reforço que podem ser usadas como ponto de partida para loops de treinamento personalizados.

Disponibilidade e como começar

As APIs de sessão de treinamento estão disponíveis para uso geral nas seguintes regiões:

• US East (N. Virginia)
• US West (Oregon)
• Asia Pacific (Mumbai)

Para começar, basta instalar o SDK Python do SageMaker e clonar o cookbook, ou abrir um notebook no SageMaker Studio e conectar um agente de codificação. Mais detalhes estão disponíveis na documentação oficial e na página do Amazon SageMaker AI.

Fonte

Amazon SageMaker AI announces training session APIs for serverless model customization (https://aws.amazon.com/about-aws/whats-new/2026/10/training-session-apis-on-sagemaker-ai)

O dilema entre controle algorítmico e simplicidade operacional

Fazer o ajuste fino de um Modelo de Linguagem de Grande Escala (LLM) costuma impor uma escolha difícil: ou você usa um serviço totalmente gerenciado — onde basta selecionar o modelo base, fornecer dados e hiperparâmetros — ou parte para uma abordagem menos gerenciada, ganhando controle sobre o algoritmo, mas herdando toda a complexidade de infraestrutura e frameworks de treinamento.

O problema aparece quando uma receita padrão não resolve: quando é preciso implementar uma função de perda customizada, um currículo de dados para Ajuste Fino Supervisionado (SFT), uma otimização de preferência própria, uma função de recompensa para Aprendizado por Reforço (RL) ou um algoritmo de alinhamento recém-publicado. Nesse momento, para ganhar liberdade algorítmica, a equipe acaba assumindo toda a gestão de infraestrutura GPU.

A AWS acaba de expandir o Serverless Model Customization do Amazon SageMaker AI com as Training Session APIs, que eliminam esse dilema ao mover a fronteira de abstração um nível abaixo. Em vez de abstrair o algoritmo, essas APIs abstraem o compute. Operações como forward_backward(), optim_step() e sample() tornam-se chamadas de API do SageMaker que podem ser compostas em qualquer procedimento que a técnica exigir: SFT, otimização de preferência, RL ou algo completamente novo.

As chamadas são direcionadas a uma sessão ativa e com estado (stateful), de modo que o modelo permanece carregado nas GPUs entre os passos. O serviço cuida de toda a configuração de runtime, execução distribuída, sincronização de gradientes, recuperação de falhas, isolamento de tenants e operação das GPUs em escala. Quem desenvolve escreve o loop de treinamento; o SageMaker AI roda a infraestrutura.

Junto com o serviço, a AWS também publicou o SageMaker training sessions cookbook, um conjunto de receitas prontas de SFT e RL que podem servir de ponto de partida para loops de treinamento personalizados.

O que são as Training Session APIs do SageMaker AI?

Com as Training Session APIs, é possível conduzir uma sessão ativa, respaldada por GPUs, a partir do seu próprio processo Python na máquina local. Você faz as chamadas de operação, e o SageMaker AI as executa em aceleradores gerenciados, já carregados com o modelo base escolhido e o adaptador de Adaptação de Baixa Classificação (LoRA). Não há arquivo de configuração descrevendo todo o job antecipadamente nem etapa de criação de cluster. Você controla o que acontece em cada passo, de forma interativa, direto do código — o que permite iterar e depurar rapidamente.

A divisão de responsabilidades fica assim:

• Você cuida de: seus dados, ambientes de RL, agentes e algoritmo. Você escreve um loop de treinamento em Python que chama operações como forward_backward(), optim_step() e sample() para os passos que precisam de GPUs.
• O SageMaker AI cuida de: alocação de GPU, carregamento do modelo e LoRA, execução distribuída, recuperação de falhas, armazenamento de checkpoints e segurança.

Os três clientes do SDK

A API é organizada em três clientes no SageMaker Python SDK, criados em sequência:

• ServiceClient — armazena configurações de plataforma (role de execução, grupo de pacotes de modelo, localização de saída no Amazon S3 e, opcionalmente, chave AWS KMS e configuração de VPC) e inicia a sessão.
• TrainingClient — instanciado pelo ServiceClient, concentra operações de treinamento e checkpointing como forward, forward_backward, optim_step e save_weights_for_sampler.
• SamplingClient — instanciado pelo TrainingClient, oferece sample e compute_logprobs para geração e scoring durante rollouts e avaliação.

Uma sessão ativa também expõe um endpoint de chat completions compatível com a API da OpenAI, permitindo que código existente que use o cliente OpenAI faça sampling diretamente.

O formato de um passo de treinamento com RL

Para Aprendizado por Reforço, o loop tem um formato característico com quatro estágios. As operações que rodam nas GPUs gerenciadas (sampling, gradiente e checkpoint) ficam no serviço, enquanto o controle do loop e a lógica de recompensa rodam na sua máquina:

• (1) Sample — gera respostas a partir do modelo atual nas GPUs.
• (2) Score — seu código Python pontua as saídas localmente (verificador, modelo de recompensa, harness de testes, etc.).
• (3) forward_backward + optim_step — transforma as pontuações em uma atualização de gradiente nas GPUs.
• (4) save_weights_and_get_sampling_client() — atualiza o sampler para que o próximo passo use o modelo atualizado.

As mesmas primitivas cobrem SFT e outras técnicas de treinamento de LLMs. Para SFT, basta remover os passos de sampling e recompensa e chamar forward_backward com uma perda cross_entropy sobre exemplos rotulados.

Para quem é e onde se encaixa no Amazon SageMaker AI?

As Training Session APIs são o ponto de partida certo quando a equipe precisa de ciclos rápidos de iteração e liberdade algorítmica — como uma perda customizada, um novo sinal de recompensa de RL ou um pipeline multi-estágio — mas não quer provisionar ou operar infraestrutura GPU.

A cobrança é feita por token processado, de modo que só se paga pelo compute que o loop efetivamente consome. Se a função de recompensa leva 10 segundos para pontuar um lote na máquina local, nenhum tempo de GPU é cobrado durante essa execução. Isso traz duas vantagens práticas em relação à cobrança por hora de GPU:

• Sem custo de GPU ociosa: computação de recompensa, carregamento de dados, logging e debugging acontecem fora do relógio de cobrança.
• Custo escala com o dataset e volume de geração, não com tempo de parede ou tamanho do cluster, o que facilita a previsão de gastos e a comparação de experimentos.

Os perfis de uso incluem:

• Pesquisadores de pós-treinamento e alinhamento implementando métodos de RL (GRPO, PPO, variantes de importance-sampling), estimadores de vantagem customizados ou novos objetivos.
• Equipes fazendo SFT ou otimização de preferência que precisam de uma perda não-padrão, currículo de dados ou pipeline multi-estágio.
• Construtores de RL agêntico e multi-turno que precisam de lógica de rollout customizada, reward shaping e currículos.
• Engenheiros de Aprendizado de Máquina (ML) que superaram o fine-tuning baseado em configuração, mas não querem o ônus operacional de clusters GPU.
• Pesquisadores portando código de loops de treinamento existentes, já que o modelo de programação baseado em operações mapeia diretamente para loops escritos com APIs de baixo nível.

Os modelos base suportados e as Regiões AWS disponíveis estão listados na documentação das Training Session APIs.

Posicionamento entre as opções de customização do SageMaker AI

As Training Session APIs ocupam um ponto distinto entre as opções de customização de modelos do SageMaker AI: oferecem substancialmente mais controle sobre o algoritmo de treinamento do que o Serverless Model Customization totalmente gerenciado, e muito menos responsabilidade operacional do que treinar com Amazon SageMaker Training Jobs ou Amazon SageMaker HyperPod.

Em resumo: o Serverless Model Customization com APIs gerenciadas oferece baixo controle (escolha modelo, configure hiperparâmetros, forneça dados) e infraestrutura serverless. As Training Session APIs oferecem alto controle (você escreve o loop e chama primitivas) e também são serverless. Já o SageMaker Training Jobs e o HyperPod oferecem controle total, mas exigem seleção de instâncias ou gerenciamento de clusters persistentes.

Anatomia de um loop de treinamento: GRPO em problemas de matemática

Para ilustrar como as operações se encaixam, o artigo original detalha um loop mínimo de RL sobre o GSM8K, um benchmark com aproximadamente 8.500 problemas de matemática de nível escolar, cada um com uma resposta numérica única. Exemplo:

Natalia sold clips to 48 of her friends in April, and then she sold half as many clips in May. How many clips did Natalia sell altogether in April and May? → 72

O treinamento usa um adaptador LoRA para o GPT-OSS 20B da OpenAI com Otimização de Política Relativa de Grupo (GRPO): para cada pergunta, o modelo gera várias respostas, cada uma é pontuada por correção, e respostas que superam a média do grupo são reforçadas. O exemplo completo e executável está no repositório de exemplos do Amazon SageMaker.

Abrindo a sessão

Antes de abrir uma sessão, é necessário completar os pré-requisitos na documentação. Em seguida, cria-se a sessão, obtém-se o tokenizer e um SamplingClient:

from sagemaker.train.training_session import ServiceClient, SamplingParams, AdamParams

svc = ServiceClient(role_arn=role, region=REGION)
training_client = svc.create_lora_training_client(
    "openai/gpt-oss-20b",                    # a name from svc.list_base_models()
    training_session_name=SESSION_NAME,
    rank=32, alpha=64,                        # LoRA rank and scaling factor
    model_package_group_arn=MODEL_PACKAGE_GROUP_ARN,
    s3_output_path=OUTPUT_S3_PATH,
)
tokenizer = training_client.get_tokenizer()
sampling_client = training_client.create_sampling_client()

Definindo recompensa e vantagem

A lógica específica da tarefa são duas funções curtas que rodam na máquina local:

def compute_reward(response_text, ground_truth):
    predicted = extract_answer(response_text)          # parse the number after "#### "
    return 1.0 if predicted == ground_truth else 0.0

def compute_advantages(rewards):
    rewards = np.array(rewards)
    advantages = rewards - rewards.mean()              # center within the group (the GRPO baseline)
    return advantages / (rewards.std() + 1e-8)         # normalize

O loop principal

Cada passo segue os quatro estágios descritos anteriormente:

for step in range(NUM_STEPS):
    datums, pending = [], []

    # (1) sample K responses per question in one request each (GPU); returns a future right away
    for question, ground_truth in draw(PROMPTS_PER_STEP):      # data loading is local
        prompt = tokenizer.encode(build_prompt(question), add_special_tokens=False)
        pending.append((prompt, ground_truth,
            sampling_client.sample(
                prompt, num_samples=K,
                sampling_params=SamplingParams(max_tokens=512, temperature=0.7, top_p=0.9))))

    for prompt, ground_truth, future in pending:
        result = future.result()                               # wait once the batch is in flight

        # (2) score each response, then center the rewards within the group (local)
        rewards    = [compute_reward(tokenizer.decode(s.tokens), ground_truth)
                      for s in result.sequences]
        advantages = compute_advantages(rewards)
        datums    += [build_training_datum(prompt, s, a)
                      for s, a in zip(result.sequences, advantages)]

    # (3) one gradient step over the batch (GPU); the optimizer step is sequenced behind it
    fwd_bwd_op = training_client.forward_backward(datums, loss_fn="ppo")
    optim_op   = training_client.optim_step(AdamParams(learning_rate=1e-5))
    fwd_bwd_op.result(), optim_op.result()

    # (4) refresh the sampler so the next step's rollouts come from the updated policy (GPU)
    sampling_client = training_client.save_weights_and_get_sampling_client()

training_client.stop()

Detalhes importantes do loop

Três detalhes fazem esse loop funcionar:

• Operações retornam futures. Toda chamada GPU retorna um APIFuture imediatamente: a requisição é enfileirada e enviada por um submitter em background, e .result() aguarda o valor. O loop submete todas as requisições de sampling de um passo antes de esperar qualquer uma, de modo que todo o lote gera concorrentemente. Operações de treinamento rodam na ordem em que são chamadas, então optim_step pode ser submetido antes de forward_backward ter terminado.
• O datum carrega tudo que a perda precisa. build_training_datum empacota os tokens do prompt e da resposta, os logprobs por token do sample(), a vantagem e uma máscara de pesos que mantém o prompt fora da perda.
• Checkpoints são pacotes de modelo. Cada save registra uma versão no grupo de pacotes de modelo. Após o treinamento, dois saves adicionais criam um modelo mesclado para deploy e um estado resumível com pesos e otimizador.

training_client.save_weights_for_sampler(merge_weights=True).result()  # merged, deployable model
training_client.save_state().result()                                  # resumable state (weights + optimizer)

Para retomar, basta iniciar uma nova sessão a partir do último checkpoint com create_training_client_from_state_with_optimizer. Uma sessão ativa conta contra a cota de sessões concorrentes até que stop() seja chamado ou ela expire. O checkpoint mesclado pode ser implantado em um endpoint de tempo real. Para servir checkpoints como adaptadores LoRA, consulte o notebook de deploy do cookbook.

No teste do exemplo, 10 passos de treinamento sobre 40 problemas elevaram a acurácia em dados de validação de 56% para 75%.

Caso de uso real: RL em programação competitiva

O GSM8K mantém a mecânica visível, mas um workload de RL em produção adiciona mais complexidade: gerações mais longas, interação multi-turno, um avaliador externo e throughput suficiente para manter as GPUs ocupadas. O SageMaker training sessions cookbook empacota essa engenharia em loops de treinamento reutilizáveis construídos sobre as mesmas operações.

Para uma nova tarefa de RL, basta escrever um environment: o que o modelo vê, como a resposta é pontuada e se há outro turno. O cookbook cuida de batching, templates de chat, estimativa de vantagem, overlap entre sampling e treinamento, validação, checkpointing com resume e métricas por passo.

A receita code_rl usa essa estrutura para treinar um modelo em problemas de programação competitiva:

• A tarefa: os problemas vêm do dataset DeepCoder (PrimeIntellect, TACO e LiveCodeBench para treinamento; Codeforces e LiveCodeBench para teste). O modelo escreve uma solução em Python, que é executada contra os testes unitários do problema em um contêiner SandboxFusion na máquina local. A recompensa é 1 quando todos os testes passam e 0 caso contrário, com penalidade de 0.1 quando a resposta não contém bloco de código.
• Uso de ferramentas multi-turno: com dois turnos, o modelo pode chamar uma ferramenta check_solution, ler os resultados dos testes e revisar a resposta antes da nota final. As chamadas de ferramenta e resultados são renderizados no formato de chat nativo do modelo.

O que a receita adiciona ao loop mínimo:

• Overlap entre sampling e treinamento: workers de rollout continuam gerando enquanto o trainer executa um passo. Um grupo de respostas amostrado de uma política mais antiga é usado se tiver no máximo k passos de defasagem (caso contrário é reenfileirado), e a perda cispo corrige a diferença de política.
• Computação de gradiente em stream: forward_backward é submetido em sub-lotes à medida que os grupos terminam, em vez de uma única vez por passo.
• Validação em hold-out, resume de checkpoint e métricas por passo, opcionalmente publicadas no SageMaker managed MLflow.

No treinamento descrito, um adaptador LoRA (rank 32) para GPT-OSS 20B foi treinado por 50 passos, cada um com 128 problemas e 8 respostas por problema, usando dois turnos e limite de defasagem de k=3. A recompensa de treinamento subiu de 0.46 para 0.60, e a acurácia em 200 problemas de teste reservados subiu de 40% para 50.5%.

Para executar, basta iniciar o sandbox e lançar a receita:

bash tools/sandbox_up.sh
python -m training_sessions_cookbook.recipes.code_rl.train \
  --config training_sessions_cookbook/recipes/code_rl/configs/coderl_oss20b_service.json \
  --max_steps_off_policy 3 --stale_policy requeue --num_rollout_workers 80 --max_steps 50 \
  --base_model_arn "$BASE_MODEL_ARN" \
  --model_package_group_arn "$MODEL_PACKAGE_GROUP_ARN" \
  --role_arn "$ROLE_ARN" \
  --output_s3_path "$OUTPUT_S3_PATH"

O cookbook traz mais receitas na mesma estrutura, incluindo SFT em datasets de chat (Tulu 3, UltraChat), RL no GSM8K em escala completa e alinhamento de preferência KTO a partir de feedback binário. O README de cada receita lista os comandos, hiperparâmetros e métricas esperadas.

Conclusão

As Training Session APIs do SageMaker AI movem a fronteira de abstração para o nível da operação de treinamento: você escreve o loop em Python na sua máquina, e o serviço o executa em GPUs gerenciadas, cuidando do carregamento de modelo e LoRA, execução distribuída, recuperação de falhas e checkpointing.

Um loop GRPO completo se resume a quatro operações — sample, forward_backward, optim_step e save_weights_and_get_sampling_client — com a lógica de recompensa e vantagem no seu próprio código. As mesmas operações escalam para RL multi-turno com uso de ferramentas e avaliação em sandbox, como demonstra a receita Code RL.

Recompensas customizadas, rollouts agênticos, debugging passo a passo e novas técnicas publicadas — tudo usa o mesmo modelo de programação: o algoritmo fica no seu loop, e o SageMaker AI roda as GPUs.

Para começar:

• Escolha uma receita do SageMaker training sessions cookbook, como a Code RL.
• Execute o exemplo GSM8K do repositório de exemplos do Amazon SageMaker e substitua pela sua própria função de recompensa.
• Leia a documentação das Training Session APIs para pré-requisitos, cotas, Regiões, modelos suportados e referência da API.

Fonte

Write your own training loop — without managing GPUs — with Amazon SageMaker training session APIs (https://aws.amazon.com/blogs/machine-learning/write-your-own-training-loop-without-managing-gpus-with-amazon-sagemaker-training-sessions/)

Personalização de dados no atendimento ao cliente

A AWS anunciou uma atualização relevante para o Amazon Connect Customer Profiles: administradores agora podem personalizar quais informações de clientes são exibidas para cada agente no espaço de trabalho, além de controlar como esses dados são organizados visualmente. Essa configuração é feita por meio de layouts criados no Profile Explorer.

O Customer Profiles já oferecia aos agentes uma visão unificada e em tempo real de cada cliente durante as interações, combinando histórico de contatos com dados vindos de múltiplas fontes. A novidade é a capacidade de adaptar essa visão conforme o perfil de atuação de cada agente.

Por que isso importa na prática

Agentes que lidam com tipos diferentes de solicitações precisam de informações diferentes em mãos. Um agente de reclamações de bagagem em uma companhia aérea, por exemplo, precisa ver o histórico de contatos, voos ativos e dados do ticket de bagagem. Já um agente de fidelidade precisa enxergar o status de fidelidade do cliente, suas preferências e os próximos voos. Exibir informações irrelevantes para o contexto do atendimento prejudica a agilidade e a qualidade do serviço.

Com essa atualização, cada layout pode ser configurado com diferentes widgets do Customer Profiles — como histórico de contatos, informações de contato e atributos calculados de valor ao longo da vida do cliente — e atribuído diretamente aos agentes, substituindo a visualização legada do Customer Profiles.

Resumo de Perfil com Inteligência Artificial

Os layouts também podem incluir um Resumo de Perfil com Inteligência Artificial (IA), recurso que direciona a atenção do agente para os principais insights do cliente, resumindo automaticamente o perfil antes ou durante o atendimento. Isso contribui para que o agente chegue à conversa mais bem preparado, sem precisar navegar manualmente por múltiplos campos de dados.

Regiões disponíveis

O Profile Explorer está disponível nas seguintes regiões da AWS:

• Leste dos EUA (Norte da Virgínia)
• Oeste dos EUA (Oregon)
• África (Cidade do Cabo)
• Ásia-Pacífico (Seul)
• Ásia-Pacífico (Singapura)
• Ásia-Pacífico (Sydney)
• Canadá (Central)
• Europa (Frankfurt)
• Europa (Londres)

Para saber mais sobre como configurar e utilizar o recurso, a AWS disponibiliza a documentação oficial no guia do administrador do Amazon Connect Customer.

Fonte

Amazon Connect Customer now supports customizing the Customer Profiles app on the agent workspace (https://aws.amazon.com/about-aws/whats-new/2026/10/connect-customer-customize-cp)

Dados recém-ingeridos ficam disponíveis para busca mais rapidamente

A AWS anunciou uma melhoria importante no Amazon OpenSearch Serverless: o intervalo de atualização padrão foi reduzido de 10 segundos para 5 segundos, tanto para coleções de busca quanto para coleções vetoriais. A mudança já está em vigor e não exige nenhuma alteração de configuração por parte dos times que utilizam o serviço.

O que é o intervalo de atualização e por que ele importa?

O intervalo de atualização (refresh interval) determina com que frequência documentos recém-ingeridos tornam-se disponíveis para consulta. Em termos práticos, quanto menor esse intervalo, mais rápido uma aplicação consegue ler dados que acabaram de ser escritos — o que é especialmente relevante para sistemas que trabalham com ingestão contínua de dados.

Com a redução de 10 para 5 segundos, a visibilidade de leitura após escrita (read-after-write visibility) melhorou automaticamente para todos os usuários da próxima geração do Amazon OpenSearch Serverless, sem custo adicional de configuração.

Quais cargas de trabalho se beneficiam?

A AWS destaca que essa melhoria é especialmente valiosa para workloads que ingerem dados de forma contínua e precisam de recuperação em tempo quase real. Entre os casos de uso mencionados estão:

• Busca em texto completo sobre conteúdos atualizados com frequência
• Geração Aumentada por Recuperação (RAG) — técnica usada em aplicações de IA generativa
• Busca semântica, que depende de vetores atualizados para retornar resultados relevantes
• Sistemas de recomendação e personalização, que se beneficiam de dados mais frescos

Para aplicações e agentes de IA, isso significa que os dados mais recentes ficam disponíveis para recuperação e processamento com mais agilidade, o que impacta diretamente a relevância e a precisão das respostas — especialmente em pipelines de RAG que trabalham com bases de conhecimento em constante atualização.

Disponibilidade

O novo intervalo padrão de 5 segundos está disponível em todas as 24 regiões onde o Amazon OpenSearch Serverless está presente. Para saber mais sobre o serviço e suas configurações, consulte a documentação oficial do Amazon OpenSearch Serverless.

Fonte

Amazon OpenSearch Serverless now supports a 5-second default refresh interval (https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-opensearch-serverless-supports-5-second-refresh-interval/)

O problema do modelo único para tudo

Quem já construiu agentes de Inteligência Artificial (IA) conhece bem o dilema: toda requisição — seja uma simples consulta de status ou uma análise complexa — acaba sendo enviada para o mesmo modelo grande e caro hospedado na nuvem. Essa abordagem de tamanho único eleva os custos de API, introduz latência imprevisível e torna o sistema completamente dependente de conectividade.

Para endereçar esse problema, a AWS publicou um artigo técnico apresentando o Adaptive Agentic Intelligence Framework (AAIF), construído sobre o Strands Agents. A ideia central é simples: usar Modelos de Linguagem Pequenos (SLMs) para resolver tarefas rotineiras localmente, e acionar modelos de nuvem via Amazon Bedrock apenas quando a complexidade realmente exigir. Essa lógica tem respaldo acadêmico: pesquisadores Belcak et al. da NVIDIA argumentam que SLMs são “suficientemente poderosos, inerentemente mais adequados e necessariamente mais econômicos para muitas invocações em sistemas agênticos”.

Arquitetura em três camadas

O AAIF organiza o processamento de IA em três camadas, cada uma otimizada para um tipo diferente de tarefa:

• Orquestração inteligente: um SLM leve (llama3.2:1b) atua como camada de decisão. Ele classifica cada requisição recebida e a direciona para a camada adequada, sem regras fixas codificadas manualmente.
• Processamento local: tarefas rotineiras como recuperação de telemetria de dispositivos e análise de imagens são tratadas por SLMs rodando no próprio hardware, via Ollama. Essas tarefas completam com baixa latência e sem dependência de nuvem.
• Processamento em nuvem: análises de padrões complexos e recomendações estratégicas são enviadas para modelos de fronteira no Amazon Bedrock, que oferecem raciocínio de múltiplos passos e contexto mais amplo.

No centro da arquitetura está o agente Strands, que se conecta a um runtime Ollama hospedando tanto o modelo orquestrador de 1 bilhão de parâmetros quanto o modelo de visão. O agente expõe três ferramentas: get_device_telemetry para recuperação local de dados de sensores, analyze_camera_feed para processamento de visão no dispositivo via llama3.2-vision, e get_expert_insights que aciona o Amazon Bedrock via boto3 para análises complexas.

O framework se adapta às restrições do ambiente de implantação sem exigir reestruturação de infraestrutura. Ele roda em dispositivos de borda como um Raspberry Pi com 8 GB de memória, em implantações totalmente em nuvem onde toda inferência passa pelo Amazon Bedrock, ou em configurações híbridas que combinam velocidade local com raciocínio em nuvem.

Pré-requisitos para o walkthrough

Para seguir o passo a passo técnico descrito no artigo original, os seguintes componentes são necessários:

• Uma conta AWS com acesso ao Amazon Bedrock configurado na região desejada.
• Python 3.10+ instalado.
• Ollama instalado com os modelos llama3.2:1b (orquestrador) e llama3.2-vision (análise visual) disponíveis.
• Strands Agents instalado: pip install strands-agents strands-agents-tools.
• Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais apropriadas.
• Boto3 instalado: pip install boto3.

Configurando o ambiente

O primeiro passo é criar o diretório do projeto e iniciar o servidor Ollama:

mkdir aaif-demo && cd aaif-demo
ollama serve

Em seguida, baixar os modelos necessários:

ollama pull llama3.2:1b
ollama pull llama3.2-vision

Implementando as ferramentas de processamento local

O Strands Agents utiliza o decorador @tool para definir as capacidades que os agentes podem invocar. A primeira ferramenta recupera dados de telemetria de dispositivos. Em produção, ela se conectaria a sensores reais de Internet das Coisas (IoT); no walkthrough, usa dados simulados:

from strands import Agent, tool
import random

DEVICE_TELEMETRY = {
    "sensor-001": {
        "device_type": "Temperature Sensor",
        "location": "Building A - Floor 2",
        "temperature": 72.5,
        "humidity": 45.2,
        "status": "normal"
    },
    "camera-001": {
        "device_type": "Security Camera",
        "location": "Main Entrance",
        "fps": 30,
        "resolution": "1080p",
        "status": "recording"
    },
    "hvac-001": {
        "device_type": "HVAC Controller",
        "location": "Building A - Central",
        "set_temp": 71.0,
        "current_temp": 72.5,
        "mode": "cooling",
        "status": "active"
    }
}

@tool
def get_device_telemetry() -> str:
    """Retrieve current telemetry data from connected IoT devices."""
    device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
    device_data = DEVICE_TELEMETRY[device_id]
    report = f"Device: {device_id} ({device_data['device_type']})\n"
    report += f"Location: {device_data['location']}\n"
    report += f"Status: {device_data['status']}\n"
    for key, value in device_data.items():
        if key not in ['device_type', 'location', 'status']:
            report += f"{key}: {value}\n"
    return report

A segunda ferramenta realiza análise visual usando um SLM local. O modelo llama3.2-vision roda inteiramente no hardware local, o que significa que feeds sensíveis de câmera não saem do dispositivo:

import ollama

@tool
def analyze_camera_feed(image_path: str) -> str:
    """Analyze visual data from cameras using local vision model."""
    stream = ollama.chat(
        model='llama3.2-vision',
        messages=[{
            'role': 'user',
            'content': 'Describe this image in one sentence. '
                       'What are the 3 most important things you see?',
            'images': [image_path]
        }],
        stream=True,
    )
    full_response = ""
    for chunk in stream:
        chunk_content = chunk['message']['content']
        print(chunk_content, end='', flush=True)
        full_response += chunk_content
    return f"Object Detection Report:\n{full_response}"

Implementando o processamento em nuvem

Para análises que requerem raciocínio mais amplo, uma terceira ferramenta aciona o Amazon Bedrock. Ela é invocada apenas quando o orquestrador determina que os modelos locais não conseguem resolver a requisição:

import boto3

@tool
def get_expert_insights(context_data: str, question: str) -> str:
    """Get advanced analysis and expert recommendations for complex questions via Amazon Bedrock."""
    client = boto3.client("bedrock-runtime", region_name="us-east-1")
    conversation = [
        {
            "role": "user",
            "content": [
                {"text": f"Context: {context_data}\n\nQuestion: {question}"}
            ],
        }
    ]
    response = client.converse(
        modelId="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
        messages=conversation,
        inferenceConfig={
            "maxTokens": 512,
            "temperature": 0.5,
            "topP": 0.9
        }
    )
    response_text = response["output"]["message"]["content"][0]["text"]
    return f"Expert Analysis:\n{response_text}"

Configurando o agente com orquestração inteligente

O núcleo do AAIF é a configuração do agente Strands. Ele utiliza um SLM local (llama3.2:1b) como orquestrador, via provedor Ollama:

from strands.models.ollama import OllamaModel

model = OllamaModel(
    model_id="llama3.2:1b",
    host="http://localhost:11434",
    params={
        "max_tokens": 300,
        "temperature": 0.3,
    },
)

system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities, and expert insights to help monitor operations effectively.

When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights

Always return the complete tool results directly to the user."""

agent = Agent(
    model=model,
    system_prompt=system_prompt,
    tools=[
        get_device_telemetry,
        analyze_camera_feed,
        get_expert_insights,
    ],
)

O orquestrador baseado em SLM analisa cada requisição e a encaminha para a ferramenta adequada sem correspondência de palavras-chave codificada. O roteamento acontece pelo entendimento contextual do modelo. A tabela abaixo resume o comportamento esperado:

• “Verificar status do dispositivo” → SLM local, baixa latência
• “Analisar esta imagem” → IA de visão local, baixa latência
• “Quais estratégias de otimização você recomenda?” → Nuvem (Amazon Bedrock), latência maior por round-trip de rede

Com o agente configurado, a interação é direta:

# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)

# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)

# Cloud processing - complex analysis
response = agent(
    "Based on current telemetry patterns, "
    "what optimization strategies do you recommend?"
)
print(response)

Adaptando para diferentes cenários de implantação

A arquitetura AAIF suporta três configurações principais, ajustáveis apenas trocando a configuração do modelo:

Totalmente em nuvem

Quando não há hardware de borda disponível, toda inferência passa pelo Amazon Bedrock com escalonamento automático:

from strands.models import BedrockModel

model = BedrockModel(
    model_id="<", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
    region_name="us-east-1"
)

Híbrido (configuração padrão do AAIF)

Mantém o orquestrador SLM local e aciona modelos de nuvem apenas para requisições que excedem a capacidade local. Cerca de 80% do tráfego não atinge um endpoint de API pago, o que representa economia significativa de custos.

Totalmente local (air-gapped)

Para ambientes com requisitos estritos de soberania de dados ou sem conectividade, um modelo local maior substitui a ferramenta de nuvem. Um modelo de 3 bilhões de parâmetros consegue lidar com tarefas moderadamente complexas que o orquestrador de 1B escalaria para a nuvem. A contrapartida é menor profundidade de raciocínio nas consultas mais difíceis:

model = OllamaModel(
    model_id="llama3.2:3b",  # Larger local model for complex tasks
    host="http://localhost:11434",
)

Próximos passos: servidores MCP para chamadas centralizadas de ferramentas

A implementação descrita usa chamadas de ferramentas locais definidas diretamente no código do agente. Para implantações em produção com múltiplos agentes compartilhando ferramentas entre serviços, o artigo recomenda expor essas ferramentas como servidores do Protocolo de Contexto de Modelo (MCP). O MCP fornece uma interface padronizada para descoberta e invocação de ferramentas, permitindo centralizar o gerenciamento e reutilizar ferramentas em diferentes agentes.

Na configuração distribuída, o Dispositivo 1 atua como hub orquestrador, rodando o agente Strands com o roteador SLM e uma ferramenta de telemetria local. Ele se conecta via protocolo MCP ao Dispositivo 2, que roda um servidor de processamento de visão de borda com llama3.2-vision, e ao Dispositivo 3, que serve como gateway de análise em nuvem conectado ao Amazon Bedrock. Do ponto de vista do orquestrador, todas as ferramentas remotas aparecem como chamadas de função locais, pois a camada de transporte MCP cuida da serialização e comunicação de rede de forma transparente.

Limpeza do ambiente

Para evitar cobranças futuras, o artigo recomenda os seguintes passos de limpeza:

• Desabilitar o acesso ao modelo no Amazon Bedrock: abrir o console do Amazon Bedrock, acessar “Model access” e revogar o acesso ao Amazon Nova Lite. Consulte Gerenciar acesso a modelos no Guia do Usuário do Amazon Bedrock para detalhes.
• Parar o servidor Ollama e remover os modelos para liberar espaço em disco (aproximadamente 2 GB):

  ollama stop
  ollama rm llama3.2:1b
  ollama rm llama3.2-vision

• Deletar o diretório do projeto se o código de exemplo não for mais necessário:

  rm -rf aaif-demo

IA responsável no caminho de inferência em nuvem

Antes de executar esse padrão em produção, o artigo recomenda adicionar controles de IA responsável ao caminho de inferência em nuvem, já que essas requisições carregam saídas de ferramentas, dados recuperados e entradas do usuário. É possível anexar Amazon Bedrock Guardrails ao BedrockModel do Strands com um ID e versão de guardrail. Ele então aplica filtros de conteúdo para categorias prejudiciais, filtros de injeção de prompt e verificações de fundamentação contextual que bloqueiam respostas não suportadas pelos dados de origem. Para aplicar as mesmas políticas à camada de SLM local, basta chamar a API ApplyGuardrail standalone nas entradas e saídas — garantindo que toda requisição siga um único padrão de segurança, independentemente de qual modelo a processa.

Aplicações além do monitoramento de IoT

O padrão arquitetural descrito vai muito além do cenário de monitoramento de IoT usado como referência. Uma organização de saúde poderia rodar monitoramento de pacientes localmente enquanto roteia suporte a diagnósticos para modelos em nuvem. Uma empresa de serviços financeiros poderia processar transações on-premises e reservar capacidade de nuvem para análise de risco. Uma equipe de manufatura poderia rodar modelos de visão para controle de qualidade na borda enquanto envia requisições de otimização para a nuvem.

Para saber mais sobre como construir agentes com Strands Agents, consulte a documentação do Strands Agents. Para informações sobre os modelos de fundação disponíveis, acesse o Amazon Bedrock.

Fonte

Adaptive agentic intelligence framework using Strands Agents (https://aws.amazon.com/blogs/machine-learning/adaptive-agentic-intelligence-framework-using-strands-agents/)