Category: Uncategorized

Do Processamento à Inteligência: O Próximo Passo na Análise de Documentos

Extrair informações estruturadas de dados não-estruturados é um passo fundamental para desbloquear valor empresarial. O Acelerador GenAI IDP (Processamento Inteligente de Documentos com IA Generativa) tem se posicionado na vanguarda dessa transformação, tendo já processado dezenas de milhões de documentos para centenas de clientes.

Porém, existe um desafio que muitas organizações enfrentam: após digitizar e estruturar seus documentos, como analisar esse volume de informações de forma eficiente e extrair insights acionáveis rapidamente? A AWS identificou essa lacuna e apresentou uma solução: o Analytics Agent, uma nova funcionalidade integrada nativamente ao Acelerador GenAI IDP.

Com esse recurso, usuários podem realizar buscas avançadas e análises complexas usando consultas em linguagem natural, sem necessidade de dominar SQL ou técnicas de análise de dados. O objetivo é democratizar o acesso a insights, permitindo que qualquer usuário de negócio possa explorar seus documentos processados em escala.

O Acelerador GenAI IDP: Fundação para a Análise Inteligente

O Acelerador GenAI IDP é uma solução de código aberto que ajuda organizações a automatizar a extração de informações de diversos tipos de documentos usando IA generativa. A solução integra Amazon Bedrock com outros serviços da AWS, como AWS Lambda, AWS Step Functions, Amazon SQS (Simple Queue Service) e Amazon DynamoDB, para criar um sistema serverless robusto.

O acelerador foi projetado para operar em larga escala, conseguindo processar milhares de documentos diariamente. Ele oferece três padrões de processamento que permitem aos usuários construir soluções customizadas para fluxos complexos de tratamento de documentos.

A implantação é simplificada através de templates do AWS CloudFormation, e usuários podem começar a processar documentos imediatamente via interface web ou carregando arquivos direto no Amazon S3 (Simple Storage Service). O acelerador inclui múltiplos módulos como classificação de documentos, extração de dados, avaliação, sumarização e análise de qualidade.

Para aprofundar-se no Acelerador GenAI IDP, consulte a documentação oficial sobre como acelerar processamento inteligente de documentos com IA generativa na AWS.

O Analytics Agent: Tornando Dados Acessíveis através de Linguagem Natural

Com a nova funcionalidade Analytics Agent, usuários podem realizar consultas através de linguagem natural na interface Agent Companion Chat, acessível na seção de navegação do acelerador (a partir da versão 0.4.7). Consultas relacionadas a análises são automaticamente roteadas para o Analytics Agent.

O agente funciona como uma interface inteligente entre usuários de negócio e seus dados de documentos processados. Ele consegue lidar com consultas complexas que normalmente exigiriam um cientista de dados experiente, tornando análises avançadas acessíveis ao usuário médio.

Alguns exemplos práticos:

• Um provedor de saúde poderia perguntar: “Qual percentual de reclamações de seguro foi negado no mês passado? Daquelas, quantas foram devido a documentação incompleta? Mostre-me uma tendência de motivos de negação nos últimos seis meses.”
• Um escritório de contabilidade fiscal poderia questionar: “Quais dos meus clientes estão pagando imposto estadual em mais de um estado nos formulários W2?”

Como o Analytics Agent Funciona: Arquitetura e Fluxo

O Analytics Agent é construído sobre Strands Agents, um SDK de código aberto que utiliza uma abordagem orientada por modelos para construir agentes de IA. O agente é projetado para tornar o trabalho com dados empresariais mais intuitivo, oferecendo conversão automática de linguagem natural para dados e visualizações.

O fluxo de trabalho do Analytics Agent segue estes passos:

1. Exploração do banco de dados: O agente usa uma ferramenta de exploração para entender as estruturas de dados armazenadas nas tabelas do Amazon Athena dentro da solução IDP. Isso é necessário porque as tabelas podem ter esquemas diferentes dependendo de como os usuários configuraram o pipeline de processamento.
2. Conversão para SQL: O agente converte consultas em linguagem natural em queries SQL otimizadas e compatíveis com os bancos e tabelas disponíveis, capazes de escalar para tabelas de tamanho arbitrário.
3. Execução de queries: O agente executa SQL contra o Athena e armazena os resultados no Amazon S3. Ele corrige e re-executa queries que falharam com base na mensagem de erro.
4. Transferência segura: Os resultados são transferidos com segurança do Amazon S3 para o sandbox do AWS Bedrock AgentCore Code Interpreter.
5. Geração de visualizações: O agente escreve código Python para analisar os resultados e gerar gráficos ou tabelas em formato estruturado compatível com a interface web.
6. Apresentação final: As visualizações finais são exibidas na interface web para interpretação direta pelo usuário.

Arquitetura da Solução: Design Orientado pela Segurança

O Analytics Agent é implantado principalmente dentro de funções Lambda. Quando uma consulta do usuário chega através da API AWS AppSync, uma função Lambda efêmera cria e armazena um ID único de trabalho no DynamoDB para rastrear o fluxo de processamento assíncrono, e inicializa uma função Lambda de longa duração que instancia um agente Strands.

A interface frontend consulta o status do trabalho e recupera os resultados finais (incluindo de trabalhos anteriores) do DynamoDB. A função processadora tem permissões do AWS IAM (Gerenciamento de Identidade e Acesso) para acessar as tabelas IDP no Athena e para executar um sandbox Code Interpreter com execução mais segura de código Python.

A arquitetura segue um design orientado pela segurança:

• Execução em sandbox: O código Python executa no AgentCore Code Interpreter, completamente isolado do resto do ambiente AWS e da internet.
• Transferência segura de dados: Os resultados são transferidos através do Amazon S3 e APIs do AgentCore, não através do contexto da janela de um modelo de linguagem.
• Gerenciamento de sessões: As sessões do AgentCore Code Interpreter são gerenciadas adequadamente e limpas após o uso.
• Permissões mínimas: Cada componente solicita apenas as permissões AWS necessárias.
• Auditoria: A solução oferece logging e monitoramento abrangentes para revisões de segurança.

Demonstração Prática: Análise de Memorandos Departamentais

Para demonstrar as capacidades do Analytics Agent, a AWS processou 10.000 documentos do conjunto de dados RVL-CDIP usando o Acelerador GenAI IDP. O conjunto contém diversos tipos de documentos como memorandos, cartas, formulários e relatórios, processados usando a configuração de Padrão 2 para extrair informações estruturadas como tipo de documento, remetente, destinatário e detalhes de departamento.

Um usuário fez uma pergunta simples em linguagem natural: “Quais departamentos geram o maior volume de memorandos?”

Traditicionalmente, essa consulta exigiria que um analista de dados completasse várias etapas: obter credenciais, conectar ao banco de dados interno, entender o esquema através de queries exploratórias ou documentação, escrever SQL complexo com sintaxe Athena correta, executar e validar a query, processar resultados e criar visualizações, e formatar os achados para apresentação.

O Analytics Agent completou todo esse fluxo de forma autônoma em menos de 60 segundos.

A análise revelou que Lorillard gerou o maior número de memorandos (11 documentos), seguido pelos departamentos INBIFO, Assuntos Corporativos e Philip Morris (10 documentos cada). A visualização mostrou a distribuição entre as unidades organizacionais principais, com departamentos de pesquisa de tabaco e corporativos dominando a geração de memorandos.

Usuários podem rapidamente alternar entre diferentes estilos de visualização como gráficos de pizza, linhas e barras, ou exibir os resultados como tabelas.

Capacidades Transformadoras do Agente

O exemplo acima ilustra três capacidades principais:

• Resolução autônoma de problemas: O agente descobriu independentemente o esquema do banco de dados, identificou as tabelas e colunas corretas, e tratou problemas de qualidade de dados (valores nulos) sem intervenção humana. Isso significa que o agente pode trabalhar com diferentes documentos analisados pela solução IDP, independentemente do tipo de documento ou configurações de processamento.
• Raciocínio adaptativo: Quando o agente detectou valores nulos na visualização inicial, corrigiu automaticamente o problema filtrando os dados e regenerando o gráfico, demonstrando capacidades de auto-correção.
• Interpretabilidade fim-a-fim: Todo o fluxo de trabalho, da consulta em linguagem natural até a visualização polida, executou em 90 segundos com transparência completa. Usuários podem revisar cada decisão que o agente tomou através do registro detalhado de raciocínio.

Casos de Uso Práticos para o Analytics Agent

O poder dessa funcionalidade reside em sua capacidade de democratizar análise de dados, transformando usuários de negócio em analistas através da conversa simples. Alguns casos de uso incluem:

Insights Empresariais Instantâneos

Fazer perguntas complexas em linguagem natural como “Qual percentual de faturas excedeu $50.000 no último trimestre?” ou “Como o valor médio de faturas tendenciou ao longo dos últimos 12 meses?” Tomar decisões orientadas por dados sem aguardar equipes de TI ou ciência de dados.

Monitoramento de Risco e Conformidade

Detectar anomalias em tempo real com queries como “Mostre-me todos os contratos com cláusulas obrigatórias ausentes”, rastrear taxas de conformidade entre tipos de documento e identificar documentos de alto risco que requerem atenção imediata.

Excelência Operacional

Monitorar gargalos de processamento com “Quais tipos de documento têm os tempos de processamento mais longos?”, rastrear taxas de precisão entre categorias de documento e otimizar alocação de recursos baseado em padrões de volume.

Aprimoramento da Experiência do Cliente

Analisar métricas de processamento específicas do cliente, identificar oportunidades para automação de processos e rastrear conformidade com SLA em tempo real.

Planejamento Estratégico

Prever volumes de processamento baseado em padrões históricos, identificar tendências sazonais e planejar de acordo, rastrear métricas de ROI para investimentos em processamento de documentos e tomar decisões informadas sobre escalabilidade do sistema.

Melhores Práticas para Usar o Analytics Agent

• Comece abrangente: Inicie com perguntas gerais antes de mergulhar em especificidades.
• Seja específico: Declare claramente que informação você está procurando. Não tenha medo de fornecer um parágrafo inteiro descrevendo suas necessidades se necessário.
• Use consultas de acompanhamento: Desenvolva o que aprendeu em perguntas anteriores para explorar tópicos em profundidade. As mensagens enviadas no Agent Companion Chat possuem estado, permitindo fazer perguntas de acompanhamento.
• Verifique os resultados: Valide se as visualizações fazem sentido para seus dados e leia através do processo de raciocínio do agente exibido para validar as decisões que ele tomou.

Integração com Sistemas Agênticos Externos

O Analytics Agent pode ser facilmente integrado em outros sistemas agênticos de IA, como o Amazon Quick Suite, através do novo Servidor MCP (Model Context Protocol) do Acelerador IDP. Organizações podem incorporar capacidades de análise de documentos em seus fluxos de trabalho de IA mais amplos e plataformas de automação usando essa integração. Para orientação de implementação e detalhes técnicos, consulte a documentação de integração MCP.

Limpeza e Manutenção

Após experimentar o Analytics Agent, existem duas opções de limpeza dependendo das suas necessidades:

• Remover queries individuais: Navegue para a seção de Análise do Agente na interface web e use o painel “carregar chat anterior” para deletar queries específicas.
• Deletar toda a implantação IDP: Use o console CloudFormation para deletar a pilha IDP. Para limpeza automatizada incluindo esvaziamento de buckets S3, use o CLI do IDP conforme documentado na documentação do IDP CLI.

Próximos Passos e Recursos

Visite o repositório GitHub do Acelerador GenAI IDP para guias detalhados e exemplos, e escolha “Watch” para se manter informado sobre novos lançamentos e recursos.

O time de AWS Professional Services e AWS Partners está disponível para auxiliar com implementação. Você também pode se juntar à comunidade GitHub para contribuir com melhorias e compartilhar suas experiências.

Conclusão

O Analytics Agent representa um passo significativo na democratização da análise de dados empresariais. Ao eliminar barreiras técnicas tradicionais—conhecimento de SQL, compreensão de estruturas de banco de dados, familiaridade com ferramentas de análise—a AWS coloca o poder da exploração de dados nas mãos de qualquer usuário de negócio.

Com a integração nativa no Acelerador GenAI IDP, organizações que já investiram no processamento inteligente de documentos agora ganham uma ferramenta poderosa para extrair valor máximo de seus dados. Essa combinação de processamento de documentos automatizado e análise conversacional abre novas possibilidades para casos de uso em saúde, contabilidade, conformidade, operações e muito além.

Fonte

Enhance document analytics with Strands AI Agents for the GenAI IDP Accelerator (https://aws.amazon.com/blogs/machine-learning/enhance-document-analytics-with-strands-ai-agents-for-the-genai-idp-accelerator/)

O Que É Voxtral: Capacidades Multimodais Integradas

Os modelos Voxtral da Mistral AI marcam um avanço significativo no processamento simultâneo de texto e áudio. Ao contrário de soluções convencionais que exigem etapas separadas para transcrever e processar dados, o Voxtral integra essas funcionalidades em um único framework coeso.

A família Voxtral apresenta dois modelos específicos, cada um otimizado para cenários distintos. O Voxtral-Mini-3B-2507 é uma versão compacta com 3 bilhões de parâmetros, direcionado a aplicações onde velocidade e economia de recursos computacionais são prioridades. O Voxtral-Small-24B-2507, com 24 bilhões de parâmetros baseados no Mistral Small 3, atende casos corporativos mais complexos, proporcionando recursos avançados de conversação, execução de funções diretamente por comando de voz e processamento sofisticado em múltiplos idiomas.

Ambos suportam contexto de áudio estendido (entre 30 e 40 minutos), identificação automática de idioma e mantêm uma janela de contexto de 32 mil tokens. Disponibilizados sob licença Apache 2.0, permitem tanto uso comercial quanto em pesquisa.

Processamento Multimodal Unificado

Um dos diferenciais do Voxtral é processar fala e texto em um único fluxo de trabalho. Isso elimina a necessidade de etapas separadas de transcrição, reduzindo latência e complexidade da arquitetura. O modelo extrai contexto e sentimento diretamente do áudio, e gerencia vários arquivos de áudio dentro da mesma conversa.

O Voxtral Small acrescenta capacidade de chamada de funções, permitindo que comandos falados se convertam em ações executáveis. Isso viabiliza assistentes de voz contextualizados, transcrição automática e extração de insights em reuniões, processamento inteligente de chamadas para suporte ao cliente, ferramentas acessíveis e sistemas de comunicação multilíngue para empresas globais.

Hospedagem no Amazon SageMaker Com Contêiner Personalizado

A solução combina Amazon SageMaker AI com vLLM usando a abordagem Bring Your Own Container (BYOC). O vLLM é uma biblioteca otimizada para servir grandes modelos de linguagem, oferecendo atenção paginada para melhor gestão de memória e paralelismo tensorial para distribuir modelos entre várias GPUs.

A capacidade BYOC do SageMaker permite implantação com imagens Docker personalizadas. Isso oferece controle de versão compatível com vLLM 0.10.0+, flexibilidade para otimizar requisitos específicos do Voxtral (incluindo bibliotecas de áudio e gerenciamento customizado de memória), além de suportar ambas as variantes através de ajustes simples de configuração.

Arquitetura da Solução

O notebook do SageMaker atua como ponto central de orquestração. Gerencia a construção e envio de imagens Docker personalizadas para o Registro de Contêineres (Amazon ECR), coordena fluxos de configuração e implementação, e oferece capacidades de teste e validação.

Um componente essencial é o contêiner Docker personalizado que estende o servidor vLLM oficial com bibliotecas especializadas para processar áudio (librosa, soundfile, pydub) e mistral_common para tokenização do Voxtral. O Amazon Elastic Container Registry (ECR) fornece armazenamento seguro e distribuição escalável dessa imagem, integrando-se aos mecanismos de implantação do SageMaker.

O endpoint de inferência do SageMaker funciona como ambiente de produção, oferecendo escalonamento automático e distribuição de carga. Para Voxtral-Mini, a recomendação é ml.g6.4xlarge; para Voxtral-Small, ml.g6.12xlarge. O Amazon Simple Storage Service (S3) armazena três arquivos críticos: o manipulador de inferência personalizado (model.py), configuração do modelo (serving.properties) e dependências (requirements.txt). Essa abordagem modular permite separar configuração de imagens de contêiner e facilita mudanças sem reconstrução completa.

Padrões de Uso Suportados

A solução atende múltiplos padrões de uso alinhados a necessidades organizacionais variadas. O processamento apenas de texto utiliza a API padrão de conclusão de chat para IA conversacional. O modo transcription-only oferece transcrição precisa de arquivos de áudio, ideal para anotações de reuniões. Aplicações sofisticadas combinam inteligência de áudio e texto, onde o áudio fornece contexto e texto entrega instruções específicas. O padrão avançado envolve chamada de funções a partir de áudio, onde comandos falados disparam ações automatizadas—por exemplo, “Calcule a raiz quadrada de 144” executa automaticamente a ferramenta de calculadora.

Este guia também demonstra integração do Voxtral implantado no SageMaker com Strands Agents para construir aplicações agentic com código mínimo.

Preparação Técnica Para Implantação

Antes de iniciar, certifique-se de possuir os seguintes pré-requisitos:

Requisitos de software:

• vLLM >= 0.10.0
• mistral_common >= 1.8.1

Configuração da AWS:

• Uma conta AWS ativa
• Notebook SageMaker com ml.m5.4xlarge e 100 GB de armazenamento
• AWS Identity and Access Management (IAM) adequadas. Adicione a política EC2InstanceProfileForImageBuilderECRContainerBuilds ao papel de execução do SageMaker
• Quotas de serviço: instâncias ml.g6.4xlarge (Voxtral-Mini) e ml.g6.12xlarge (Voxtral-Small) disponíveis em sua região. Se necessário, solicite um aumento de cota

Processo de Implantação

Para implantar os modelos Voxtral, siga estas etapas:

1. Baixe o código do repositório

git clone https://github.com/aws-samples/mistral-on-aws.git
cd mistral-on-aws/Mistral\ Voxtral/Voxtral-vllm-byoc

2. Construa seu contêiner

chmod +x build_and_push.sh
./build_and_push.sh

3. Configure o modelo em code/serving.properties

Para Voxtral-Mini:

option.model_id=mistralai/Voxtral-Mini-3B-2507
option.tensor_parallel_degree=1

Para Voxtral-Small:

option.model_id=mistralai/Voxtral-Small-24B-2507
option.tensor_parallel_degree=4

4. Execute a implantação

Abra e execute Voxtral-vLLM-BYOC-SageMaker.ipynb para implantar seu endpoint e testar com recursos de texto, áudio e chamada de funções.

Configuração do Contêiner Docker

O repositório GitHub contém o Dockerfile completo. Os componentes principais são:

# Custom vLLM Container for Voxtral Model Deployment on SageMaker
FROM --platform=linux/amd64 vllm/vllm-openai:latest

# Set environment variables for SageMaker
ENV MODEL_CACHE_DIR=/opt/ml/model
ENV TRANSFORMERS_CACHE=/tmp/transformers_cache
ENV HF_HOME=/tmp/hf_home
ENV VLLM_WORKER_MULTIPROC_METHOD=spawn

# Install audio processing dependencies
RUN pip install --no-cache-dir \
    "mistral_common>=1.8.1" \
    librosa>=0.10.2 \
    soundfile>=0.12.1 \
    pydub>=0.25.1

Este Dockerfile estende o servidor vLLM oficial com capacidades específicas do Voxtral. A abordagem separa infraestrutura de lógica de negócio: o contêiner permanece genérico enquanto o SageMaker injeta dinamicamente código específico do modelo a partir do S3 em tempo de execução.

Configurações do Modelo

As configurações estão no arquivo serving.properties. Os parâmetros principais incluem:

# Model configuration
option.model_id=mistralai/Voxtral-Small-24B-2507
option.tensor_parallel_degree=4
option.dtype=bfloat16

# Voxtral-specific settings (as per official documentation)
option.tokenizer_mode=mistral
option.config_format=mistral
option.load_format=mistral
option.trust_remote_code=true

# Audio processing (Voxtral specifications)
option.limit_mm_per_prompt=audio:8
option.mm_processor_kwargs={"audio_sampling_rate": 16000, "audio_max_length": 1800.0}

# Performance optimizations (vLLM v0.10.0+ features)
option.enable_chunked_prefill=true
option.enable_prefix_caching=true
option.use_v2_block_manager=true

Esta configuração implementa otimizações específicas do Voxtral, permitindo processamento de até oito arquivos de áudio por prompt com suporte a transcrição de 30 minutos, além de utilizar mecanismos avançados de cache para melhorar desempenho de inferência.

Manipulador de Inferência Personalizado

O arquivo model.py implementa um servidor compatível com SageMaker. Os componentes-chave são:

# FastAPI app for SageMaker compatibility
app = FastAPI(title="Voxtral vLLM Inference Server", version="1.1.0")
model_engine = None

# vLLM Server Initialization for Voxtral
def start_vllm_server():
    """Start vLLM server with Voxtral-specific configuration"""
    config = load_serving_properties()
    cmd = [
        "vllm",
        "serve",
        config.get("option.model_id"),
        "--tokenizer-mode", "mistral",
        "--config-format", "mistral",
        "--tensor-parallel-size", config.get("option.tensor_parallel_degree"),
        "--host", "127.0.0.1",
        "--port", "8000"
    ]
    vllm_server_process = subprocess.Popen(cmd, env=vllm_env)
    server_ready = wait_for_server()
    return server_ready

@app.post("/invocations")
async def invoke_model(request: Request):
    """Handle chat, transcription, and function calling"""
    # Transcription requests
    if "transcription" in request_data:
        audio_source = request_data["transcription"]["audio"]
        return transcribe_audio(audio_source)
    
    # Chat requests with multimodal support
    messages = format_messages_for_openai(request_data["messages"])
    tools = request_data.get("tools")
    
    # Generate via vLLM OpenAI client
    response = openai_client.chat.completions.create(
        model=model_config["model_id"],
        messages=messages,
        tools=tools if supports_function_calling() else None
    )
    return response

Este manipulador cria um servidor baseado em FastAPI que se integra ao servidor vLLM, processando conteúdo multimodal incluindo áudio codificado em base64 e URLs de áudio, além de suportar chamadas de funções.

Código de Implantação no SageMaker

O notebook Voxtral-vLLM-BYOC-SageMaker.ipynb orquestra todo o processo de implantação:

import boto3
import sagemaker
from sagemaker.model import Model

# Initialize SageMaker session
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
bucket = "your-s3-bucket"

# Upload model artifacts to S3
byoc_config_uri = sagemaker_session.upload_data(
    path="./code",
    bucket=bucket,
    key_prefix="voxtral-vllm-byoc/code"
)

# Configure custom container image
account_id = boto3.client('sts').get_caller_identity()['Account']
region = boto3.Session().region_name
image_uri = f"{account_id}.dkr.ecr.{region}.amazonaws.com/voxtral-vllm-byoc:latest"

# Create SageMaker model
voxtral_model = Model(
    image_uri=image_uri,
    model_data={
        "S3DataSource": {
            "S3Uri": f"{byoc_config_uri}/",
            "S3DataType": "S3Prefix",
            "CompressionType": "None"
        }
    },
    role=role,
    env={
        'MODEL_CACHE_DIR': '/opt/ml/model',
        'TRANSFORMERS_CACHE': '/tmp/transformers_cache',
        'SAGEMAKER_BIND_TO_PORT': '8080'
    }
)

# Deploy to endpoint
predictor = voxtral_model.deploy(
    initial_instance_count=1,
    instance_type="ml.g6.12xlarge",
    container_startup_health_check_timeout=1200,
    wait=True
)

Exemplos de Uso do Modelo

O repositório GitHub contém o código completo. Aqui apresentamos exemplos para diferentes cenários.

Apenas texto

Uma conversa básica onde o usuário envia uma consulta e recebe resposta estruturada:

payload = {
    "messages": [
        {
            "role": "user",
            "content": "Hello! Can you tell me about the advantages of using vLLM for model inference?"
        }
    ],
    "max_tokens": 200,
    "temperature": 0.2,
    "top_p": 0.95
}
response = predictor.predict(payload)

Apenas transcrição

Este exemplo foca em transcrição de fala em texto. O modelo processa URL de arquivo de áudio ou arquivo em base64, retornando apenas o texto transcrito:

payload = {
    "transcription": {
        "audio": "https://audiocdn.frenchtoday.com/file/ft-public-files/audiobook-samples/AMPFE/AMP%20FE%20Ch%2002%20Story%20Slower.mp3",
        "language": "fr",
        "temperature": 0.0
    }
}
response = predictor.predict(payload)

Entendimento de texto e áudio

Combinação de instruções em texto e entrada de áudio para processamento multimodal. O modelo segue comandos escritos enquanto analisa o arquivo de áudio em uma única passada de inferência:

payload = {
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Can you summarise this audio file"
                },
                {
                    "type": "audio",
                    "path": "https://huggingface.co/datasets/hf-internal-testing/dummy-audio-samples/resolve/main/obama.mp3"
                }
            ]
        }
    ],
    "max_tokens": 300,
    "temperature": 0.2,
    "top_p": 0.95
}
response = predictor.predict(payload)

Uso de ferramentas

Este exemplo demonstra chamada de funções, permitindo que o modelo interprete comandos de voz e execute ferramentas predefinidas:

WEATHER_TOOL = {
    "type": "function",
    "function": {
        "name": "get_current_weather",
        "description": "Get the current weather for a specific location",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "The city and state, e.g. San Francisco, CA"
                },
                "format": {
                    "type": "string",
                    "enum": ["celsius", "fahrenheit"],
                    "description": "The temperature unit to use."
                }
            },
            "required": ["location", "format"]
        }
    }
}

def mock_weather(location, format="celsius"):
    """Always returns sunny weather at 25°C/77°F"""
    temp = 77 if format.lower() == "fahrenheit" else 25
    unit = "°F" if format.lower() == "fahrenheit" else "°C"
    return f"It's sunny in {location} with {temp}{unit}"

payload = {
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "audio",
                    "path": "https://huggingface.co/datasets/patrickvonplaten/audio_samples/resolve/main/fn_calling.wav"
                }
            ]
        }
    ],
    "temperature": 0.2,
    "top_p": 0.95,
    "tools": [WEATHER_TOOL]
}
response = predictor.predict(payload)

Integrando Com Strands Agents

O exemplo a seguir mostra como integrar Voxtral com o framework Strands para criar agentes inteligentes capazes de utilizar múltiplas ferramentas. O agente seleciona e executa ferramentas apropriadas (calculadora, operações com arquivos ou comandos shell) com base em consultas de usuário:

# SageMaker integration with Strands agents
from strands import Agent
from strands.models.sagemaker import SageMakerAIModel
from strands_tools import calculator, current_time, file_read, shell

model = SageMakerAIModel(
    endpoint_config={
        "endpoint_name": endpoint_name,
        "region_name": "us-west-2",
    },
    payload_config={
        "max_tokens": 1000,
        "temperature": 0.7,
        "stream": False,
    }
)

agent = Agent(model=model, tools=[calculator, current_time, file_read, shell])
response = agent("What is the square root of 12?")

Limpeza de Recursos

Após concluir os experimentos, delete os endpoints do SageMaker criados para evitar custos desnecessários:

# Delete SageMaker endpoint
print(f" Deleting endpoint: {endpoint_name}")
predictor.delete_endpoint(delete_endpoint_config=True)
print(" Endpoint deleted successfully")

Considerações Finais

A abordagem apresentada demonstra como hospedar os modelos Voxtral da Mistral AI no SageMaker utilizando a estratégia BYOC. A solução é pronta para produção, aproveitando o framework vLLM mais recente e as otimizações do Voxtral para ambas as variantes Mini e Small.

A arquitetura suporta todo o espectro de capacidades do Voxtral: conversas apenas com texto, transcrição de áudio, entendimento multimodal sofisticado e chamada de funções a partir de entrada de voz. Por seu design flexível, é possível alternar entre Voxtral-Mini e Voxtral-Small através de simples atualizações de configuração, sem reconstruir contêineres.

Para aprofundar sua experiência, experimente o código completo disponível no repositório GitHub para hospedar o Voxtral no SageMaker e comece a construir suas próprias aplicações habilitadas para voz. Explore todo o potencial do Voxtral visitando o site oficial da Mistral para conhecer capacidades detalhadas, benchmarks de desempenho e especificações técnicas. Por fim, explore o framework Strands Agents para criar aplicações agentic que executem fluxos de trabalho complexos de forma integrada.

Fonte

Deploy Mistral AI’s Voxtral on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/deploy-mistral-ais-voxtral-on-amazon-sagemaker-ai/)

Entendendo Manutenção Preditiva com IA

A manutenção preditiva representa uma mudança estratégica significativa na forma como as indústrias gerenciam seus ativos. Em vez de esperar que equipamentos falhem ou realizar manutenção em intervalos fixos, essa abordagem utiliza dados contínuos de sensores e análise avançada para prever quando uma máquina provavelmente enfrentará problemas. Isso permite que as equipes intervenham proativamente, evitando paradas não planejadas, melhorando a eficiência operacional e prolongando a vida útil de equipamentos críticos como motores, ventiladores, caixas de engrenagens, rolamentos e transportadores.

A AWS apresentou uma solução prática que combina modelos de fundação com IA generativa para aprimorar significativamente o processo de diagnóstico. Usando Amazon Bedrock como base tecnológica, a empresa demonstrou como um assistente inteligente pode ajudar equipes de manutenção a identificar com precisão a causa raiz de problemas nos equipamentos.

Os Dois Pilares da Manutenção Preditiva

O processo de manutenção preditiva funciona em duas fases complementares que, juntas, criam uma abordagem completa para evitar falhas.

Fase 1: Geração de Alarmes a Partir de Sensores

Nesta primeira etapa, sensores monitoram continuamente parâmetros críticos do equipamento, como temperatura e vibração. A Amazon Monitron oferece uma solução integrada de monitoramento de equipamentos com capacidades de aprendizado de máquina. O processo segue uma sequência clara: os sensores capturam dados de vibração e temperatura, que são automaticamente transferidos para a nuvem AWS, onde algoritmos de aprendizado de máquina analisam esses dados em comparação com padrões ISO de vibração, disparando notificações quando condições anormais são detectadas.

Fase 2: Diagnóstico da Causa Raiz

A segunda fase enfrenta desafios significativos que o setor há muito tempo procura resolver. Após o disparo de um alarme, os técnicos recebem ordens de trabalho genéricas com pouca orientação específica e precisam consultar entre 40 ou mais manuais de reparo, cada um contendo centenas de páginas. Quando problemas surgem em estágios iniciais e não exibem sinais claros de mau funcionamento, torna-se extremamente difícil para os técnicos identificar a causa raiz, resultando em longos períodos de inatividade, redução de eficiência e custos elevados de manutenção.

Dados mostram que mais de 50% das ordens de trabalho geradas após um alarme permanecem classificadas como “Indeterminadas” quanto à causa raiz—um problema operacional substancial que impacta diretamente a produtividade.

A Solução: Um Assistente Inteligente Multimodal

Para resolver esse desafio, a AWS desenvolveu um assistente baseado em IA generativa que transforma o processo de diagnóstico. A solução oferece várias capacidades integradas que trabalham em conjunto para fornecer orientação precisa e contextualizada aos técnicos.

Análise de Séries Temporais e Diagnóstico Orientado

O assistente processa dados de sensores e identifica padrões anômalos em relação aos padrões normais de operação. Quando anormalidades são detectadas, o sistema inicia uma conversa orientada que retém o histórico de interações, permitindo diálogos multiturno e contextualmente conscientes. O sistema faz perguntas direcionadas para reunir informações essenciais, funcionando como um técnico virtual consultivo.

Capacidades Multimodais

Uma das características mais poderosas da solução é seu suporte a múltiplos tipos de entrada. Os técnicos podem enviar imagens de componentes desgastados, descrever problemas por áudio, ou até mesmo fazer upload de vídeos mostrando o funcionamento anormal do equipamento. Usando modelos multimodais como Claude 3 Haiku e Claude 3 Sonnet disponíveis através do Amazon Bedrock, o sistema analisa todos esses formatos e fornece interpretações precisas e recomendações contextualizadas.

Recuperação Aumentada Multimodal com Fusão de Ranking

O sistema integra informações tanto de manuais de reparo em texto quanto de diagrama visuais. Quando um técnico faz uma pergunta, o assistente utiliza técnicas avançadas de busca semântica para recuperar informações relevantes. A fusão de ranking recíproco garante que os resultados retornados sejam semanticamente alinhados com a consulta do usuário, combinando insights textuais com guias visuais para diagnóstico mais efetivo.

Guardrails para Segurança e Conformidade

O assistente emprega Amazon Bedrock Guardrails para manter segurança, precisão e conformidade durante todo o processo diagnóstico. Esses guardrails incluem filtros para informações sensíveis, bloqueio de conteúdo prejudicial e passos de validação para evitar recomendações errôneas.

Implementação Técnica: Como Funciona

Processamento de Dados de Sensores

O processo começa quando um técnico carrega um arquivo Excel contendo dados de vibração e temperatura em uma aplicação Streamlit. O sistema extrai esses dados, cria visualizações que destacam desvios de padrões normais com linhas verticais em vermelho, e classifica os níveis de vibração em comparação com padrões internacionais ISO 20816-1. As classificações resultam em zonas de avaliação: Muito Bom, Satisfatório, Alerta ou Crítico, dependendo da classe de máquina e dos valores medidos em VRMS (Velocidade Raiz Quadrática Média).

Entrada por Áudio

Os técnicos podem registrar notas de áudio descrevendo as condições do equipamento. O áudio é enviado para Amazon Transcribe para transcrição automática. Após revisão da transcrição, o texto é processado pelo assistente de IA, que integra essas observações verbais no fluxo diagnóstico, mantendo contexto através de múltiplas trocas.

O seguinte exemplo mostra como isso é implementado. Um arquivo de áudio é enviado para um bucket de Amazon Simple Storage Service (Amazon S3), uma transcrição é acionada através de um endpoint customizado do Amazon API Gateway, e o resultado é recuperado:

def transcribe_audio(audio_filename):
    file_size = os.path.getsize(audio_filename)
    bucket_name = read_key_value(config_filename, "S3_bucket_name")
    s3 = boto3.client('s3')
    s3.upload_file(audio_filename, bucket_name, audio_filename)
    s3_uri = f's3://{bucket_name}/{audio_filename}'
    url = 'https:' + read_key_value(config_filename, "api_endpoint_amazon_transcribe")
    response = requests.post(url, json={'audio_file_uri': s3_uri})
    result = response.json()
    return result.get('transcript_uri', 'No transcription found.')

Uma função AWS Lambda processa o trabalho de transcrição de forma assíncrona:

import boto3
import json
import time
transcribe = boto3.client('transcribe')
def lambda_handler(event, context):
    print("Received event: " + json.dumps(event, indent=2))
    try:
        body = json.loads(event.get('body', '{}'))
        audio_file_uri = body.get('audio_file_uri')
        if not audio_file_uri:
            return {
                'statusCode': 400,
                'body': json.dumps({'error': 'audio_file_uri is missing'})
            }
        s3_bucket = audio_file_uri.split('/')[2]
        s3_key = '/'.join(audio_file_uri.split('/')[3:])
        job_name = f"transcription-job-{int(time.time())}"
        response = transcribe.start_transcription_job(
            TranscriptionJobName=job_name,
            Media={'MediaFileUri': audio_file_uri},
            MediaFormat=s3_key.split('.')[-1],
            LanguageCode='en-US'
        )
        while True:
            status = transcribe.get_transcription_job(TranscriptionJobName=job_name)
            if status['TranscriptionJob']['TranscriptionJobStatus'] in ['COMPLETED', 'FAILED']:
                break
            time.sleep(5)
        if status['TranscriptionJob']['TranscriptionJobStatus'] == 'COMPLETED':
            transcript_uri = status['TranscriptionJob']['Transcript']['TranscriptFileUri']
            return {
                'statusCode': 200,
                'body': json.dumps({'transcript_uri': transcript_uri})
            }
        else:
            return {
                'statusCode': 500,
                'body': json.dumps({'error': 'Transcription job failed.'})
            }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': json.dumps({'error': str(e)})
        }

Processamento de Vídeo

Para vídeos, a solução extrai componentes de áudio e visual de forma separada. O áudio é transcrito usando o mesmo processo mencionado anteriormente. Frames individuais são extraídos em intervalos regulares, convertidos em formato base64, e processados por modelos multimodais para gerar descrições. Os timestamps dos frames são sincronizados com as transcrições de áudio para manter coerência entre informações visuais e auditivas.

A AWS nota que abordagens mais recentes, como as capacidades nativas de compreensão de vídeo do Amazon Nova, agora oferecem alternativas simplificadas e escaláveis para essa funcionalidade.

Recuperação de Informação de Manuais

O sistema extrai texto e imagens de manuais em PDF usando bibliotecas especializadas. O texto é convertido em embeddings usando o modelo Amazon Titan v2 e armazenado nas Amazon Bedrock Knowledge Bases. As imagens também são processadas: modelos multimodais geram descrições detalhadas que incluem contexto das páginas adjacentes, e essas descrições são também convertidas em embeddings.

Durante a busca, o sistema transforma a consulta do usuário em múltiplas consultas relacionadas usando um LLM (Modelo de Linguagem Grande). Cada consulta recupera resultados de uma base de dados vetorial, e um algoritmo de fusão de ranking recíproco reordena esses resultados para priorizar informações verdadeiramente relevantes e semanticamente alinhadas. Texto e imagens são processados em fluxos separados de busca, garantindo que o resultado final combine insights escritos com suporte visual.

Pré-requisitos para Implementação

Para implementar com sucesso essa solução, algumas fundações precisam estar em lugar:

• Identificar ativos críticos para manutenção preditiva—determinar quais equipamentos são mais essenciais e causariam maior impacto se falhassem
• Coletar e registrar dados acionáveis—configurar monitoramento contínuo de vibração e temperatura em intervalos de um minuto com transferência automática para a nuvem
• Reunir manuais de reparo—obter documentos dos fabricantes de equipamentos originais que detalhem requisitos de manutenção e procedimentos seguros
• Manter registros históricos de manutenção (opcional mas recomendado)—dados anteriores ajudam a refinar modelos e melhorar a precisão de previsões

Impacto Operacional e Escalabilidade

A implementação dessa solução em centros de distribuição da Amazon demonstrou capacidade de reduzir significativamente o número de diagnósticos indeterminados. Ao fornecer aos técnicos orientação clara e acionável quando um alarme é disparado, o assistente não apenas acelera o processo de diagnóstico mas também melhora a confiabilidade geral das recomendações.

O design adaptável da solução a torna viável para diversos setores além da manufatura—indústrias de óleo e gás, logística e saúde podem todas se beneficiar dessa abordagem. Melhorias futuras poderiam incluir expansão de capacidades de busca para abranger vídeos, treinamento de agentes inteligentes para recomendar próximos passos com base em diagnósticos bem-sucedidos anteriores, e geração automática de ordens de trabalho que especifiquem recursos e tarefas com base nos resultados diagnósticos.

Fonte

Build a multimodal generative AI assistant for root cause diagnosis in predictive maintenance using Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-a-multimodal-generative-ai-assistant-for-root-cause-diagnosis-in-predictive-maintenance-using-amazon-bedrock/)

Entendendo o novo recurso SOCI indexing

A AWS anunciou a integração de indexação SOCI (Seekable Open Container Initiative) no SageMaker Studio. Essa novidade possibilita um carregamento seletivo de imagens de container, onde apenas as partes necessárias são baixadas inicialmente, em vez de todo o arquivo de container.

O SageMaker Studio funciona como um Ambiente Integrado de Desenvolvimento (IDE) web para desenvolvimento completo de aprendizado de máquina, permitindo que usuários construam, treinem, implantem e gerenciem tanto modelos de ML tradicionais quanto modelos de fundação para todo o fluxo de trabalho. Cada aplicação executada no SageMaker Studio roda dentro de um container que empacota as bibliotecas, frameworks e dependências necessárias, garantindo execução consistente entre diferentes cargas de trabalho e sessões de usuário.

Essa arquitetura containerizada permite ao SageMaker Studio oferecer suporte a uma ampla gama de frameworks de ML como TensorFlow, PyTorch, scikit-learn e outros, mantendo isolamento forte entre ambientes.

O desafio da customização em escala

Embora a AWS forneça containers para os ambientes de ML mais comuns, cientistas de dados frequentemente precisam personalizar esses ambientes para casos de uso específicos. Isso pode incluir adicionar ou remover pacotes, configurar variáveis de ambiente customizadas ou instalar dependências especializadas.

Para atender essa necessidade, o SageMaker Studio oferece suporte por meio de Configurações de Ciclo de Vida (LCCs), que permitem executar scripts bash durante a inicialização de um espaço IDE. No entanto, customizar repetidamente ambientes dessa forma pode se tornar demorado e difícil de manter em escala.

Como alternativa, a plataforma suporta construção e registro de imagens de container personalizadas com bibliotecas e frameworks pré-configurados. Essas imagens reutilizáveis reduzem o atrito na configuração e melhoram a reprodutibilidade para consistência entre projetos, permitindo que cientistas de dados se concentrem no desenvolvimento de modelos em vez de gerenciamento de ambiente.

O problema da inicialização lenta

Conforme as cargas de trabalho de ML se tornam mais complexas, as imagens de container que alimentam esses ambientes crescem em tamanho, levando a tempos de inicialização mais longos. Isso pode atrasar a produtividade e interromper fluxos de trabalho de desenvolvimento.

Cientistas de dados, engenheiros de ML e desenvolvedores enfrentam tempos de espera mais longos para seus ambientes iniciarem, particularmente ao alternar entre diferentes frameworks ou ao usar imagens com extensas bibliotecas e dependências pré-instaladas. Essa latência de inicialização se torna um gargalo significativo no desenvolvimento iterativo de ML, onde experimentação rápida e prototipagem ágil são essenciais.

Como SOCI resolve o problema

Em vez de baixar a imagem de container inteira antecipadamente, SOCI cria um índice que permite ao sistema buscar apenas os arquivos e camadas específicas necessários para iniciar a aplicação, com componentes adicionais carregados sob demanda conforme necessário. Isso reduz significativamente os tempos de inicialização de container de alguns minutos para segundos, permitindo que ambientes SageMaker Studio sejam iniciados muito mais rapidamente e os usuários comecem a trabalhar em projetos de ML logo em seguida, melhorando a produtividade de desenvolvedores e reduzindo o tempo para obter insights de experimentos de ML.

Pré-requisitos

Para usar indexação SOCI com SageMaker Studio, é necessário:

• Uma conta da AWS com uma função AWS Identity and Access Management (IAM) com permissões para gerenciar recursos SageMaker e ECR. Para detalhes, consulte Criar uma conta AWS.
• Se esta é sua primeira vez trabalhando com Amazon SageMaker Studio, primeiro é necessário criar um domínio SageMaker.
• Um repositório privado Amazon Elastic Container Registry (ECR) para armazenar suas imagens de container com índices SOCI.
• Verificar que você possui AWS CLI versão 2.0 ou superior instalado para interagir com esses serviços e gerenciar suas imagens indexadas com SOCI.

Visão geral do recurso SOCI indexing

O SOCI (Seekable Open Container Initiative), originalmente disponibilizado como código aberto pela AWS, aborda atrasos na inicialização de containers no SageMaker Studio por meio de carregamento seletivo de imagens. Essa tecnologia cria um índice especializado que mapeia a estrutura interna de imagens de container para acesso granular a arquivos individuais sem baixar todo o arquivo de container primeiro.

Imagens de container tradicionais são armazenadas como listas ordenadas de camadas em arquivos tar compactados com gzip, que tipicamente exigem download completo antes de acessar qualquer conteúdo. SOCI supera essa limitação gerando um índice separado armazenado como um Artefato OCI que se vincula à imagem original de container por meio de Tipos de Referência OCI. Esse design preserva todas as imagens originais de container, mantém digests de imagem consistentes e garante validade de assinatura — fatores críticos para ambientes de IA/ML com requisitos rigorosos de segurança.

Para usuários do SageMaker Studio, a implementação de indexação SOCI por meio de integração com Finch container runtime resulta em redução de 35-70% nos tempos de inicialização de container em todos os tipos de instância usando Trazer Sua Própria Imagem (BYOI). Essa implementação vai além das estratégias de otimização atuais limitadas a combinações específicas de imagens de primeiro partido e tipos de instância, fornecendo tempos de inicialização de aplicação mais rápidos em ambientes SageMaker AI Studio e SageMaker Unified Studio.

Criando um índice SOCI

Para criar e gerenciar índices SOCI, é possível usar várias ferramentas de gerenciamento de container, cada uma oferecendo vantagens diferentes dependendo do seu ambiente de desenvolvimento e preferências:

• Finch CLI é uma ferramenta de linha de comando compatível com Docker desenvolvida pela AWS que fornece suporte nativo para construção e envio de índices SOCI. Oferece uma interface familiar semelhante ao Docker enquanto inclui funcionalidade SOCI integrada, tornando direto criar imagens indexadas sem ferramental adicional.
• nerdctl funciona como uma CLI alternativa de container para containerd, o container runtime padrão da indústria. Fornece comandos compatíveis com Docker enquanto oferece integração direta com funcionalidades de containerd, incluindo suporte SOCI para capacidades de carregamento lazy.
• Docker + SOCI CLI combina o ferramental Docker amplamente utilizado com a interface de linha de comando dedicada a SOCI. Essa abordagem permite aproveitar fluxos de trabalho Docker existentes enquanto adiciona capacidades de indexação SOCI por meio de uma ferramenta CLI separada, oferecendo flexibilidade para equipes já investidas em processos de desenvolvimento baseados em Docker.

Fluxo de trabalho padrão versus otimizado com SOCI

No fluxo de trabalho padrão do SageMaker Studio, lançar um ambiente de aprendizado de máquina requer baixar a imagem de container completa antes que qualquer aplicação possa iniciar. Quando um usuário inicia uma nova sessão do SageMaker Studio, o sistema deve extrair a imagem inteira contendo frameworks como TensorFlow, PyTorch, scikit-learn, Jupyter e dependências associadas do registro de container. Esse processo é sequencial e demorado — o container runtime baixa cada camada compactada, extrai o sistema de arquivos completo para armazenamento local e apenas então a aplicação pode começar sua inicialização. Para imagens típicas de ML variando de 2-5 GB, isso resulta em tempos de inicialização de 3-5 minutos, criando atrito significativo em fluxos de trabalho de desenvolvimento iterativo onde cientistas de dados frequentemente alternam entre diferentes ambientes ou reiniciam sessões.

O fluxo de trabalho aprimorado com SOCI transforma a inicialização de container permitindo recuperação inteligente de arquivos sob demanda. Em vez de baixar imagens inteiras, SOCI cria um índice pesquisável que mapeia a localização precisa de cada arquivo dentro das camadas de container compactadas. Ao lançar uma aplicação SageMaker Studio, o sistema baixa apenas o índice SOCI (tipicamente 10-20 MB) e o conjunto mínimo de arquivos necessários para inicialização da aplicação — geralmente 5-10% do tamanho total da imagem. O container começa executando imediatamente enquanto um processo de background continua baixando arquivos restantes conforme a aplicação os solicita. Essa abordagem de carregamento lazy reduz tempos iniciais de inicialização de alguns minutos para segundos, permitindo que usuários comecem trabalho produtivo quase imediatamente enquanto o ambiente completa inicialização transparentemente em segundo plano.

Conversão de imagem para SOCI

É possível converter sua imagem existente em uma imagem SOCI e enviá-la para seu ECR privado usando os seguintes comandos:

#/bin/bash
# Download and install soci-snapshotter, containerd, and nerdctl
sudo yum install soci-snapshotter
sudo yum install containerd jq
sudo systemctl start soci-snapshotter
sudo systemctl restart containerd
sudo yum install nerdctl

# Set your registry variables
REGISTRY="123456789012.dkr.ecr.us-west-2.amazonaws.com"
REPOSITORY_NAME="my-sagemaker-image"

# Authenticate for image pull and push
AWS_REGION=us-west-2
REGISTRY_USER=AWS
REGISTRY_PASSWORD=$(/usr/local/bin/aws ecr get-login-password --region $AWS_REGION)
echo $REGISTRY_PASSWORD | sudo nerdctl login -u $REGISTRY_USER --password-stdin $REGISTRY

# Pull the original image
sudo nerdctl pull $REGISTRY/$REPOSITORY_NAME\:original-image

# Create SOCI index using the convert subcommand
sudo nerdctl image convert --soci $REGISTRY/$REPOSITORY_NAME\:original-image $REGISTRY/$REPOSITORY_NAME\:soci-image

# Push the SOCI v2 indexed image
sudo nerdctl push --platform linux/amd64 $REGISTRY/$REPOSITORY_NAME\:soci-image

Esse processo cria dois artefatos para a imagem de container original em seu repositório ECR: o índice SOCI (metadata que permite carregamento lazy) e o manifesto de índice de imagem (manifesto compatível com OCI que os vincula).

Para usar imagens indexadas com SOCI no SageMaker Studio, é necessário fazer referência à URI de índice de imagem em vez da URI original de imagem de container ao criar recursos SageMaker Image e SageMaker Image Version. A URI de índice de imagem corresponde à tag que você especificou durante o processo de conversão SOCI (por exemplo, soci-image no exemplo anterior).

#/bin/bash
# Use the SOCI v2 image index URI
IMAGE_INDEX_URI="123456789012.dkr.ecr.us-west-2.amazonaws.com/my-sagemaker-image:soci-image"

# Create SageMaker Image
aws sagemaker create-image \
  --image-name "my-sagemaker-image" \
  --role-arn "arn:aws:iam::123456789012:role/SageMakerExecutionRole"

# Create SageMaker Image Version with SOCI index
aws sagemaker create-image-version \
  --image-name "my-sagemaker-image" \
  --base-image "$IMAGE_INDEX_URI"

# Create App Image Config for JupyterLab
aws sagemaker create-app-image-config \
  --app-image-config-name "my-sagemaker-image-config" \
  --jupyter-lab-app-image-config '{
    "FileSystemConfig": {
      "MountPath": "/home/sagemaker-user",
      "DefaultUid": 1000,
      "DefaultGid": 100
    }
  }'

#Update domain to include the custom image (required step)
aws sagemaker update-domain \
  --domain-id "d-xxxxxxxxxxxx" \
  --default-user-settings '{
    "JupyterLabAppSettings": {
      "CustomImages": [{
        "ImageName": "my-sagemaker-image",
        "AppImageConfigName": "my-sagemaker-image-config"
      }]
    }
  }'

A URI de índice de imagem contém referências tanto à imagem de container quanto ao seu índice SOCI associado através do manifesto Image Index compatível com OCI. Quando SageMaker Studio inicia aplicações usando essa URI, detecta automaticamente o índice SOCI e habilita capacidades de carregamento lazy. A indexação SOCI é suportada para todos os ambientes de ML (JupyterLab, CodeEditor, etc.) tanto para SageMaker Unified Studio quanto para SageMaker AI. Para informações adicionais sobre configuração de sua imagem personalizada, consulte a documentação SageMaker Bring Your Own Image.

Impacto mensurável de SOCI no SageMaker Studio

O objetivo principal dessa novidade no SageMaker Studio é simplificar a experiência do usuário final reduzindo tempos de inicialização para aplicações SageMaker Studio lançadas com imagens personalizadas. Para medir a efetividade do carregamento lazy de imagens de container personalizadas usando SOCI, foi realizada análise empírica comparando durações de inicialização de determinada imagem personalizada com e sem SOCI. Testes foram conduzidos para variedade de imagens personalizadas representando diversos conjuntos de dependências, arquivos e dados, avaliando como a efetividade pode variar para usuários finais com diferentes necessidades de imagem personalizada.

Para quantificar empiricamente durações de inicialização para launches de aplicação em imagem personalizada, foi usado programaticamente lançamento de JupyterLab e CodeEditor Apps com a API CreateApp do SageMaker, especificando o sageMakerImageArn candidato e sageMakerImageVersionAlias com um instanceType apropriado, registrando o eventTime para análise. Posteriormente, a API ListApps do SageMaker foi consultada a cada segundo para monitorar inicialização da aplicação, registrando o eventTime da primeira resposta onde Status foi reportado como InService. O delta entre esses dois tempos para determinada aplicação é a duração de inicialização.

Para essa análise, foram criados dois conjuntos de repositórios ECR privados, cada um com as mesmas imagens de container SageMaker personalizado, mas apenas um conjunto implementando índices SOCI. Ao comparar imagens equivalentes em ECR, era possível ver artefatos SOCI presentes apenas em um repositório. As aplicações foram implantadas em um único domínio SageMaker AI. Todas as imagens personalizadas foram anexadas a esse domínio para que usuários SageMaker Studio pudessem escolher essas imagens personalizadas ao invocar inicialização de um espaço JupyterLab.

Para executar testes, para cada imagem personalizada, foi invocada série de dez chamadas API CreateApp com especificações detalhadas de domínio, espaço, tipo de aplicação e especificações de recurso.

Os testes revelaram aceleração de inicialização com índice SOCI habilitado para distribuição de imagens Amazon SageMaker. Os dados mostram que executar imagens personalizadas SageMaker Studio com índices SOCI permite usuários lançar suas aplicações significativamente mais rápido comparado sem SOCI. Especificamente, foram observados tempos de inicialização de container aproximadamente 35-70% mais rápidos, com variações dependendo do tipo de instância e aplicação específica (JupyterLab versus CodeEditor).

Conclusão

A integração de indexação SOCI no SageMaker Studio representa um avanço importante na experiência de desenvolvedor para profissionais de aprendizado de máquina. Ao otimizar tempos de inicialização de container por meio de carregamento lazy — reduzindo tempos de espera de vários minutos para perto de um minuto — a solução contribui para que cientistas de dados, engenheiros de ML e desenvolvedores gastem menos tempo esperando e mais tempo inovando. Essa melhoria aborda um dos pontos de fricção mais comuns em desenvolvimento de ML iterativo, onde alternâncias frequentes de ambiente e reinicializações impactam produtividade. Com SOCI, equipes podem manter sua velocidade de desenvolvimento, experimentar diferentes frameworks e configurações, e acelerar seu caminho de experimentação para implantação em produção.

Fonte

Introducing SOCI indexing for Amazon SageMaker Studio: Faster container startup times for AI/ML workloads (https://aws.amazon.com/blogs/machine-learning/introducing-soci-indexing-for-amazon-sagemaker-studio-faster-container-startup-times-for-ai-ml-workloads/)

Expansão do suporte a OCSP em novas regiões

A AWS anunciou a disponibilidade do protocolo OCSP (Protocolo de Status de Certificado Online) para o AWS Private Certificate Authority (AWS Private CA) nas regiões da China e AWS GovCloud (US). Trata-se de uma expansão importante que amplia as capacidades de validação de certificados em regiões geograficamente estratégicas para empresas que operam nessas áreas.

O que é AWS Private CA

O AWS Private CA é um serviço gerenciado de autoridade certificadora que simplifica a criação e gestão de certificados privados para organizações. Diferentemente de manter uma infraestrutura própria de CA, o serviço elimina a complexidade operacional, permitindo que as equipes foquem no negócio em vez de gerenciar a infraestrutura de certificados.

Entendendo OCSP e suas vantagens

O OCSP é um protocolo que permite validação de certificados em tempo real. Em vez de as aplicações baixarem listas de revogação de certificados (CRL), que podem ter centenas de quilobytes, o OCSP possibilita consultas sob demanda sobre o status de um certificado específico. Cada consulta requer apenas alguns centenas de bytes, tornando o processo muito mais eficiente em termos de consumo de banda.

Com o suporte a OCSP agora disponível, clientes nessas regiões podem implementar validação de certificados mais eficiente com uso mínimo de largura de banda, comparado ao download de listas CRL tradicionais que podem ser significativamente maiores.

Casos de uso práticos

O OCSP é particularmente útil para:

• Validação de comunicação entre microsserviços internos
• Implementação de arquiteturas de segurança zero trust
• Autenticação de dispositivos IoT que precisam verificar status de certificados em tempo real

Gestão totalmente automatizada

Uma característica diferencial é que a AWS gerencia completamente a infraestrutura do respondente OCSP, garantindo alta disponibilidade sem que o cliente precise implantar ou manter servidores OCSP próprios. Isso reduz ainda mais a complexidade operacional.

Regiões disponíveis

O OCSP está agora disponível nas seguintes regiões:

• China (Beijing)
• China (Ningxia)
• AWS GovCloud (US-East)
• AWS GovCloud (US-West)

Como habilitar OCSP

Para ativar OCSP nas autoridades certificadoras existentes, é possível usar o console do AWS Private CA, a interface de linha de comando (AWS CLI) ou a API.

Próximos passos

Organizações que operam nessas regiões e necessitam de validação de certificados mais eficiente podem explorar essa funcionalidade. Para informações detalhadas sobre revogação de certificados, consulte a documentação de revogação de certificados no guia do usuário do AWS Private CA. Detalhes de precificação estão disponíveis na página de preços do AWS Private CA.

Fonte

AWS Private CA OCSP now available in China and AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-private-ca-ocsp-china-govcloud-us-regions)

Conversas naturais em IA: o desafio da engenharia em tempo real

Construir conversas de voz naturais com agentes de IA exige infraestrutura complexa e uma quantidade considerável de código das equipes de engenharia. As interações baseadas em texto entre usuários e agentes seguem um padrão tradicional de turnos: o usuário envia uma solicitação completa, aguarda o agente processar a informação e recebe uma resposta integral antes de prosseguir. Este modelo funciona bem para muitos cenários, mas não replica a fluidez das conversas humanas.

O streaming bidirecional muda essa dinâmica ao estabelecer uma conexão persistente que transmite dados simultânea e continuamente em ambas as direções. A Plataforma AgentCore Runtime do Amazon Bedrock agora oferece suporte nativo para esse tipo de comunicação em tempo real entre usuários e agentes de IA, permitindo que os agentes escutem a entrada do usuário enquanto geram respostas simultaneamente. Isso cria um fluxo conversacional muito mais natural, especialmente adequado para interações multimodais, como conversas com visão e voz.

Capacidades habilitadas pelo streaming bidirecional

Com o streaming bidirecional, os agentes de IA ganham habilidades que se aproximam da conversação humana. Um agente de voz bidirecional consegue conduzir diálogos falados com a fluidez natural de uma conversa entre pessoas, permitindo que os usuários interrompam, esclareçam dúvidas ou mudem de assunto sem pausas incômodas.

Esses agentes processam entrada e saída de áudio em streaming simultaneamente mantendo o estado da conversa. A capacidade de começar a responder enquanto ainda recebe entrada do usuário, lidar com interrupções no meio da conversa e ajustar respostas com base em feedback em tempo real representa um avanço significativo em relação aos sistemas baseados em turnos.

Implementar essa infraestrutura do zero exigiria gerenciar conexões persistentes de baixa latência, lidar com múltiplos fluxos de áudio concorrentes, preservar contexto entre trocas de mensagens e escalar várias conversas simultaneamente. Estimativas indicam que desenvolver essas capacidades exigir meses de esforço de engenharia e expertise especializada em sistemas em tempo real.

O papel do AgentCore Runtime

A Plataforma AgentCore Runtime do Amazon Bedrock resolve esses desafios ao oferecer um ambiente de hospedagem seguro, sem servidores (serverless) e propositalmente construído para implantar e executar agentes de IA. Developers não precisam mais construir e manter infraestrutura complexa de streaming por conta própria — a plataforma gerencia toda a complexidade subjacente das conexões, ordenação de mensagens e manutenção do estado conversacional.

Fundamentos técnicos do streaming bidirecional

O protocolo WebSocket

O streaming bidirecional utiliza o protocolo WebSocket, que oferece comunicação full-duplex (bidireção completa) sobre uma única conexão TCP. Quando estabelecida, a conexão cria um canal persistente onde dados fluem continuamente em ambas as direções. Este protocolo possui amplo suporte em clientes diversos — navegadores, aplicações móveis e ambientes de servidor — tornando-o acessível para cenários variados de implementação.

Uma vez que a conexão é estabelecida, o agente consegue receber a entrada do usuário como um fluxo enquanto simultaneamente envia fragmentos de resposta de volta. O AgentCore Runtime gerencia a infraestrutura subjacente que trata de conexão, ordenação de mensagens e manutenção do estado conversacional através da troca bidirecional, eliminando a necessidade de desenvolvedores construírem infraestrutura de streaming customizada ou gerenciarem as complexidades de fluxos de dados concorrentes.

Conversa de voz versus interações de texto

Conversas de voz diferem fundamentalmente de interações baseadas em texto em relação às expectativas de fluidez natural. Quando conversam com um agente de voz, os usuários esperam a mesma dinâmica de conversa que experimentam com humanos: a capacidade de interromper para se corrigir, interjeccionar esclarecimentos no meio de uma resposta, ou redirecionar a conversa sem pausas constrangedoras.

O streaming bidirecional possibilita que agentes de voz processem áudio recebido enquanto geram respostas, detectem interrupções e ajustem comportamento em tempo real. O agente mantém contexto conversacional ao longo dessas interações, preservando o fio do diálogo mesmo conforme a conversa muda de direção. Essa capacidade transforma agentes de voz de sistemas baseados em turnos para um parceiro conversacional verdadeiramente responsivo.

Além de conversas de voz

O streaming bidirecional viabiliza diversos padrões de interação além de vozes. Sessões interativas de depuração permitem que desenvolvedores guiem agentes através de resolução de problemas em tempo real, fornecendo feedback conforme o agente explora soluções. Agentes colaborativos podem trabalhar ao lado de usuários em tarefas compartilhadas, recebendo entrada contínua enquanto o trabalho avança em vez de aguardar instruções completas. Agentes multimodais conseguem processar vídeo em streaming ou dados de sensores enquanto simultaneamente fornecedm análise e recomendações. Operações assíncronas de longa duração podem processar tarefas ao longo de minutos ou horas enquanto transmitem resultados incrementais aos clientes.

Implementação de WebSocket

Configuração básica

Para criar uma implementação de WebSocket no AgentCore Runtime, alguns padrões devem ser seguidos. Primeiramente, seus contêineres devem implementar endpoints de WebSocket na porta 8080 no caminho /ws, alinhado com práticas padrão de servidores WebSocket. Esse endpoint de WebSocket habilitará um único contêiner de agente a servir tanto a API tradicional InvokeAgentRuntime quanto a nova API InvokeAgentRuntimeWithWebsocketStream. Além disso, clientes precisam fornecer um endpoint /ping para verificações de integridade.

O streaming bidirecional usando WebSockets no AgentCore Runtime suporta aplicações que utilizem bibliotecas de linguagem de WebSocket. O cliente deve conectar ao endpoint de serviço com uma conexão de protocolo WebSocket:

wss://bedrock-agentcore.<region>.amazonaws.com/runtimes/<agentRuntimeArn>/ws

É necessário também utilizar um dos métodos de autenticação suportados (cabeçalhos SigV4, URL pré-assinada SigV4, ou OAuth 2.0) e garantir que a aplicação do agente implemente o contrato de serviço de WebSocket conforme especificado no contrato do protocolo HTTP.

Implementação prática com Strands e Amazon Nova Sonic

Modelos de implementação

A AWS oferece múltiplas abordagens para implementar agentes de voz bidirecional. Uma implementação direta exige gerenciar manualmente conexões de WebSocket, fazer parsing de eventos de protocolo, lidar com fragmentos de áudio e orquestrar tarefas assíncronas — uma abordagem que oferece controle total mas demanda conhecimento especializado. Alternativamente, a implementação usando Strands abstrai essa complexidade, tratando internamente dessas etapas.

O modelo Amazon Nova Sonic unifica compreensão e geração de fala em um único modelo, fornecendo IA conversacional similar à humana com baixa latência, precisão líder e excelente relação preço-desempenho. Sua arquitetura integrada oferece geração de fala expressiva e transcrição em tempo real em um único modelo, adaptando dinamicamente respostas com base na prosódia, ritmo e timbre da fala de entrada.

Exemplo de implementação com Strands

Para desenvolver agentes de voz com a abordagem Strands, há um repositório com dois modelos de implementação: uma usando a implementação nativa de Python do Amazon Nova Sonic implantada diretamente no AgentCore Runtime, e outra usando uma implementação de framework de alto nível com o agente bidirecional Strands para conversas de áudio em tempo real simplificadas.

O código a seguir exemplifica a simplificação oferecida pelo Strands:

from strands.experimental.bidi.agent import BidiAgent
from strands.experimental.bidi.models.nova_sonic import BidiNovaSonicModel
from strands_tools import calculator

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket, model_name: str):
    # Define a Nova Sonic BidiModel
    model = BidiNovaSonicModel(
        region="us-east-1",
        model_id="amazon.nova-sonic-v1:0",
        provider_config={
            "audio": {
                "input_sample_rate": 16000,
                "output_sample_rate": 24000,
                "voice": "matthew",
            }
        }
    )

    # Create a Strands Agent with tools and system prompt
    agent = BidiAgent(
        model=model,
        tools=[calculator],
        system_prompt="You are a helpful assistant with access to a calculator tool.",
    )

    # Start streaming conversation
    await agent.run(inputs=[receive_and_convert], outputs=[websocket.send_json])

Essa implementação demonstra a simplicidade do Strands: instanciar um modelo, criar um agente com ferramentas e um prompt de sistema, e executá-lo com fluxos de entrada e saída. O framework trata a complexidade do protocolo internamente.

Orquestração de ferramentas

Na seção de declaração do agente, as ferramentas são passadas diretamente ao construtor:

agent = BidiAgent(
    model=model,
    tools=[calculator, weather_api, database_query],
    system_prompt="You are a helpful assistant..."
)

O Strands orquestra automaticamente a chamada de funções, eliminando a necessidade de código manual para essa complexidade. Uma implementação nativa de WebSocket da mesma funcionalidade exigiria aproximadamente 150 linhas de código, enquanto a implementação Strands reduz isto para aproximadamente 20 linhas focadas na lógica de negócio.

Developers conseguem focar em definir o comportamento do agente, integrar ferramentas e elaborar prompts de sistema em vez de gerenciar conexões de WebSocket, fazer parsing de eventos, lidar com fragmentos de áudio ou orquestrar tarefas assíncronas. Isso torna o streaming bidirecional acessível para desenvolvedores sem expertise especializada em sistemas em tempo real, mantendo acesso total às capacidades de conversa de áudio do Nova Sonic.

Flexibilidade de implementação

O recurso bidirecional do Strands atualmente é suportado apenas para o Python SDK. Para quem busca flexibilidade na implementação de seu agente de voz, a implementação nativa do Amazon Nova Sonic pode ser útil, especialmente importante para casos onde há múltiplos padrões diferentes de comunicação entre agente e modelo.

Com a implementação do Amazon Nova Sonic há controle total sobre cada passo do processo. A abordagem de framework oferece melhor controle de dependências, pois isso é feito pelo SDK, e fornece consistência entre sistemas. A mesma estrutura de código do agente bidirecional Strands funciona com Nova Sonic, OpenAI Realtime API e Google Gemini Live — desenvolvedores simplesmente trocam a implementação do modelo mantendo o restante do código inalterado.

Referências práticas

Para explorar essas capacidades, há exemplos de código disponíveis. O repositório contém implementação bidirecional do Amazon Bedrock AgentCore, que demonstra comunicação bidirecional com o AgentCore. Estão disponíveis a implementação nativa de Python do Amazon Nova Sonic implantada diretamente no AgentCore Runtime, assim como a implementação de framework de alto nível usando o agente bidirecional Strands para conversas de áudio em tempo real simplificadas.

Impacto para desenvolvimento de IA conversacional

A capacidade de streaming bidirecional do AgentCore Runtime transforma como desenvolvedores conseguem criar agentes de IA conversacionais. Ao fornecer infraestrutura de comunicação em tempo real baseada em WebSocket, o AgentCore elimina meses de esforço de engenharia necessários para implementar sistemas de streaming do zero.

O runtime do framework viabiliza implantação de múltiplos tipos de agentes de voz — desde implementações de protocolo nativo usando Amazon Nova Sonic até frameworks de alto nível como o agente bidirecional Strands — dentro do mesmo ambiente seguro e sem servidores. Isso democratiza o acesso a capacidades de conversação em tempo real para equipes com diferentes níveis de expertise em sistemas em tempo real.

Fonte

Bi-directional streaming for real-time agent interactions now available in Amazon Bedrock AgentCore Runtime (https://aws.amazon.com/blogs/machine-learning/bi-directional-streaming-for-real-time-agent-interactions-now-available-in-amazon-bedrock-agentcore-runtime/)

Além dos Assistentes de Chat: A Era dos Agentes Autônomos

A próxima fronteira da inteligência artificial não reside apenas em assistentes conversacionais mais sofisticados. O verdadeiro avanço está em agentes autônomos capazes de raciocinar, planejar e executar tarefas complexas em sistemas completos. No entanto, transformar protótipos em agentes prontos para produção que escalam de forma segura representa um desafio significativo para desenvolvedoras e desenvolvedores empresariais.

Conforme os problemas corporativos se tornam mais complexos, surge a necessidade de arquiteturas sofisticadas onde múltiplos agentes especializados colaboram para realizar tarefas refinadas. Existe um abismo considerável entre desenvolver um agente em ambiente controlado e implantá-lo em escala, envolto em questões de otimização de desempenho, escalabilidade de recursos, implementação de segurança e monitoramento operacional.

O Desafio de Levar Agentes do Desenvolvimento à Produção

Abordagens convencionais frequentemente deixam equipes malabarando múltiplas ferramentas desconectadas e frameworks distintos. Essa fragmentação torna difícil manter consistência desde o desenvolvimento até a implantação, sem comprometer o desempenho.

É neste contexto que emerge uma combinação poderosa: Strands Agents, Amazon Bedrock AgentCore e NVIDIA NeMo Agent Toolkit. Estas ferramentas trabalham em conjunto para permitir o design de sistemas sofisticados com múltiplos agentes, sua orquestração e implantação segura em produção, tudo isso com observabilidade integrada, avaliação de agentes, perfilagem e otimização de desempenho.

Fundação para Agentes Prontos para Empresas

O Framework Strands Agents

O Strands Agents é um framework de código aberto que simplifica o desenvolvimento de agentes por meio de uma abordagem orientada por modelos. Desenvolvedoras e desenvolvedores criam agentes utilizando três componentes principais:

• Modelos base (foundation models), como Amazon Nova, Claude da Anthropic e Llama da Meta
• Ferramentas (mais de 20 integradas, além de ferramentas personalizadas usando decoradores Python)
• Prompts que orientam o comportamento do agente

O framework inclui integrações nativas com serviços da AWS como Amazon Bedrock e Amazon Simple Storage Service (Amazon S3), suporte a testes locais, fluxos de integração e entrega contínua (CI/CD), múltiplas opções de implantação e observabilidade via OpenTelemetry.

Amazon Bedrock AgentCore: Plataforma de Agentes Gerenciada

O Amazon Bedrock AgentCore funciona como plataforma agentic completa para construir, implantar e operar agentes eficazes em escala, com segurança de nível empresarial. Seus componentes modulares e totalmente gerenciados incluem:

• Runtime: Execução segura e sem servidor de agentes
• Memory: Retenção de contexto de curto e longo prazo
• Gateway: Acesso seguro a ferramentas, transformando APIs e funções AWS Lambda em ferramentas compatíveis com agentes, e conectando a servidores Model Context Protocol (MCP) existentes
• Identity: Gerenciamento seguro de identidade e controle de acesso
• Code Interpreter: Execução segura de código em ambientes isolados
• Browser: Interações web rápidas e seguras
• Observability: Rastreamento e monitoramento abrangente do desempenho
• Evaluations: Inspeção contínua da qualidade do agente
• Policy: Mantém agentes dentro de limites definidos

Estes serviços funcionam independentemente ou em conjunto, abstraindo a complexidade de construir e operar agentes sofisticados enquanto mantêm segurança e confiabilidade de nível empresarial.

Avaliação, Perfilagem e Otimização com NeMo Agent Toolkit

O NVIDIA NeMo Agent Toolkit é um framework de código aberto desenhado para ajudar desenvolvedoras e desenvolvedores a construir, perfilar e otimizar agentes de IA, independentemente do framework subjacente. Sua abordagem agnóstica funciona perfeitamente com Strands Agents, LangChain, LlamaIndex, CrewAI e frameworks customizados, permitindo interoperabilidade entre diferentes plataformas.

Capacidades de Profiling e Avaliação

O profiler fornecido pelo toolkit oferece análise completa do fluxo de trabalho do agente, rastreando uso de tokens, timing, latência específica do workflow, throughput e tempos de execução para agentes e ferramentas individuais. Isso permite identificar e atacar gargalos específicos.

O harness de avaliação do toolkit inclui avaliadores específicos para Retrieval Augmented Generation (RAG), como precisão de resposta, relevância de contexto, fundamentação de resposta e trajetória do agente, além de suportar avaliadores customizados para casos especializados.

Otimização Automática e Right-Sizing

O otimizador automático de hiperparâmetros perfila e descobre sistematicamente configurações ideais para parâmetros como temperatura, top_p e max_tokens, enquanto maximiza acurácia e fundamentação, minimiza uso de tokens e latência. Esta abordagem identifica combinações ótimas que a sintonia manual poderia perder.

A calculadora inteligente de dimensionamento de GPU alivia a adivinhação simulando cenários de latência e concorrência de agentes, predizendo os requisitos precisos de infraestrutura GPU necessários para implantação em produção.

A integração de observabilidade do toolkit conecta-se com serviços populares de monitoramento incluindo Arize Phoenix, Weights & Biases Weave, Langfuse e sistemas compatíveis com OpenTelemetry, como Amazon Bedrock AgentCore Observability, criando um loop de feedback contínuo para otimização e manutenção permanentes.

Exemplo Prático: Agente Baseado em Conhecimento

Um exemplo ilustrativo envolve um agente capaz de recuperar e sintetizar informações de URLs para responder consultas do usuário. Construído com Strands Agents e NeMo Agent Toolkit integrado, a solução é containerizada para implantação rápida no Amazon Bedrock AgentCore Runtime, aproveitando serviços como Observability do AgentCore.

Desenvolvedoras e desenvolvedores têm flexibilidade para integrar modelos totalmente gerenciados no Amazon Bedrock, modelos hospedados em Amazon SageMaker AI, modelos containerizados em Amazon Elastic Kubernetes Service (Amazon EKS) ou outros endpoints de API de modelo.

Desenvolvimento e Avaliação do Agente

O processo começa definindo o agente e seus workflows em Strands Agents, depois encapsulando-o com NeMo Agent Toolkit para configurar componentes como um modelo de linguagem grande (LLM) para inferência e ferramentas. Existe um exemplo de integração Strands Agents e NeMo Agent Toolkit disponível com guia de configuração detalhado.

Após validar a lógica do agente executando um workflow individual via linha de comando, o próximo passo envolve estabelecer um servidor de API de longa duração capaz de lidar com requisições concorrentes, simulando o ambiente de produção onde o AgentCore executará o agente como serviço containerizado.

Profiling e Monitoramento de Desempenho

Usando um Llama 3.3 70B Instruct NIM auto-gerenciado em uma instância Amazon EC2 P4de.24xlarge com GPUs NVIDIA A100 Tensor Core (8x A100 80GB), o profiling revela insights profundos sobre o comportamento do agente. Os dados coletados incluem:

• Latência, throughput e runtime do workflow em intervalos de confiança de 90%, 95% e 99%
• Gráficos de Gantt do fluxo do agente e análise de stack aninhada para identificar exatamente onde estão os gargalos
• Picos de concorrência e eficiência de tokens
• Métricas de qualidade (acurácia, fundamentação, relevância)

Em um cenário típico, a latência p90 fica em torno de 58,9 segundos, com a geração de resposta identificada como principal gargalo (~61,4 segundos de processamento LLM), enquanto overhead não-LLM permanece mínimo (requisições HTTP em 0,7–1,2 segundos).

Otimização de Desempenho

Após profiling, refina-se os parâmetros do agente para equilibrar qualidade, desempenho e custo. A sintonia manual de configurações LLM como temperatura e top_p é frequentemente um jogo de adivinhação. O NeMo Agent Toolkit transforma isso em ciência orientada por dados.

Um sweep automático através do espaço de busca de parâmetros executa 20 testes com três repetições cada, usando métricas de avaliação ponderadas para descobrir automaticamente configurações ideais. O toolkit gera artefatos de desempenho e tabelas de resumo para identificação rápida da configuração ótima.

Em um exemplo realístico, a otimização identificou temperatura ≈ 0,7, top_p ≈ 1,0 e max_tokens ≈ 6.144 como configuração ótima, resultando em melhoria de 35% em acurácia em relação à baseline, enquanto simultaneamente alcançava 20% de ganho em eficiência de tokens comparado à configuração de 8.192 max_tokens.

Calibração de Infraestrutura GPU para Produção

Após otimizar e finalizar o agente, o foco se desloca para avaliar infraestrutura de implantação. Para equipes que autogerenciam implantação de modelos em frotas de instâncias EC2 com GPU, prever com precisão quais recursos computacionais são necessários representa um dos maiores desafios ao levar agentes para produção.

A calculadora de dimensionamento de GPU do NeMo Agent Toolkit aborda este desafio utilizando o perfil de desempenho real do agente para determinar o tamanho de cluster ideal para objetivos de nível de serviço (SLOs) específicos. Executar a calculadora em faixas de concorrência (por exemplo, 1–32 usuários simultâneos) em uma instância de referência produz análise de capacidade detalhada.

Os dados demonstram que concorrência escala quase linearmente com latência e runtime fim-a-fim, com latência LLM e runtime de workflow apresentando ajustes de tendência próximos ao perfeito (R² ≈ 0,977/0,983). Cada requisição concorrente adicional introduz penalidade de latência previsível.

Por exemplo, para suportar 25 usuários simultâneos com runtime de workflow alvo de 50 segundos, a ferramenta calcula que aproximadamente 30 GPUs são necessárias.

Implantação em Produção no Amazon Bedrock AgentCore

Após avaliar, perfilar e otimizar o agente, chega o momento da implantação em produção. Enquanto executar localmente é adequado para testes, implantação empresarial exige um runtime de agente que fornecça segurança, escalabilidade e gerenciamento robusto de memória sem overhead de gerenciar infraestrutura.

O Amazon Bedrock AgentCore Runtime brilha precisamente aqui, oferecendo runtime de agente sem servidor de nível empresarial. Um guia passo-a-passo de implantação está disponível no repositório NeMo Agent Toolkit.

Ao empacotar o agente otimizado em um container e implantá-lo no Bedrock AgentCore Runtime sem servidor, a equipe transforma o agente prototipado em aplicação resiliente para tarefas de longa duração e requisições de usuários concorrentes.

Observabilidade em Produção

Após implantação, visibilidade torna-se crítica. A integração cria experiência unificada de observabilidade, transformando execução opaca de caixa-preta em visibilidade profunda. Obtém-se traces exatos, spans e breakdowns de latência para cada interação em produção, integrado com Amazon Bedrock AgentCore Observability usando OpenTelemetry.

Os serviços do Bedrock AgentCore estendem-se além de gerenciamento de runtime e observabilidade. Agentes implantados podem utilizar perfeitamente serviços adicionais como Amazon Bedrock AgentCore Identity para autenticação e autorização, Amazon Bedrock AgentCore Gateway para acesso a ferramentas, Amazon Bedrock AgentCore Memory para consciência de contexto, Amazon Bedrock AgentCore Code Interpreter para execução segura de código e Amazon Bedrock AgentCore Browser para interações web, criando agentes prontos para empresas.

Síntese: Uma Solução Integrada de Ponta a Ponta

Agentes de IA em produção exigem visibilidade de desempenho, otimização e infraestrutura confiável. Para o caso de uso ilustrado, esta integração entregou em todas as frentes: ganhos de 20% em eficiência de tokens, melhorias de 35% em acurácia para o exemplo prático e infraestrutura GPU ajustada ao desempenho para concorrência alvo.

A combinação do Strands Agents para desenvolvimento e orquestração de agentes, NVIDIA NeMo Agent Toolkit para perfilagem profunda de agentes, otimização e calibração de infraestrutura GPU, e Amazon Bedrock AgentCore para infraestrutura agentic segura e escalável, fornece uma solução integrada fim-a-fim que permite que desenvolvedoras e desenvolvedores construam, avaliem, otimizem e implantem agentes em escala na AWS com resultados previsíveis.

Para começar, consulte o exemplo de integração Strands Agents e NeMo Agent Toolkit e o guia de implantação de Strands Agents e NeMo Agent Toolkit no Amazon Bedrock AgentCore Runtime.

Fonte

Build and deploy scalable AI agents with NVIDIA NeMo, Amazon Bedrock AgentCore, and Strands Agents (https://aws.amazon.com/blogs/machine-learning/build-and-deploy-scalable-ai-agents-with-nvidia-nemo-amazon-bedrock-agentcore-and-strands-agents/)

Contexto: Uma Nova Geração do Security Hub

A AWS Security Hub acaba de receber uma renovação significativa. A plataforma agora oferece capacidades expandidas para agregar, correlacionar e contextualizar alertas de segurança em múltiplas contas da Amazon Web Services (AWS). Enquanto isso, a versão anterior recebeu uma nova denominação: AWS Security Hub CSPM, que continua disponível como um serviço especializado focado em gerenciamento de postura de segurança em nuvem e agregação de descobertas.

Ambas as versões compartilham uma funcionalidade importante: as regras de automação. Esse recurso permite atualizar automaticamente campos de descobertas quando critérios específicos são atendidos. Porém, existe um desafio: as regras criadas em uma versão não sincronizam com a outra. Isso significa que usuários migrando do Security Hub CSPM para a nova plataforma precisam recriar suas automações manualmente — ou encontrar uma forma mais eficiente de fazer essa transição.

O Problema de Compatibilidade de Esquemas

Diferenças Fundamentais Entre os Esquemas

O Security Hub CSPM utiliza o AWS Security Finding Format (ASFF) como esquema para suas descobertas. Esse formato é central para como as regras de automação funcionam — elas analisam campos ASFF específicos usando operadores (como igualdade ou contém) para determinar quando ativar ações que modificam outros campos ASFF.

A nova versão do Security Hub, por sua vez, adota o Open Cybersecurity Schema Framework (OCSF), um padrão aberto amplamente adotado no setor de cibersegurança. Essa mudança traz melhorias em interoperabilidade e integração, mas cria um obstáculo para usuários existentes: as regras ASFF não são diretamente compatíveis com OCSF.

Desafios Específicos da Migração

Nem todas as regras podem ser migradas automaticamente. Alguns campos ASFF não possuem correspondentes diretos em OCSF. Por exemplo, campos como Criticality, GeneratorId e RelatedFindingsId não têm mapeamento na nova estrutura. Além disso, algumas ações suportadas no ASFF — como aquelas que modificam Confidence, VerificationState ou UserDefinedFields — também não estão disponíveis no OCSF.

Isso significa que regras existentes podem ser migradas de forma parcial, preservando apenas as ações que têm equivalente no novo esquema, ou podem exigir redesenho completo.

A Solução: Automatizando a Migração

Como Funciona a Ferramenta

A AWS oferece uma solução pronta baseada em scripts Python que automatiza o processo de migração. O fluxo funciona em etapas bem definidas:

Descoberta: A solução escaneia seu ambiente Security Hub CSPM para identificar todas as regras de automação existentes em múltiplas regiões.

Análise: Cada regra é avaliada para determinar se pode ser totalmente migrada, parcialmente migrada ou se exige intervenção manual, baseado na compatibilidade entre campos ASFF e OCSF.

Transformação: Regras compatíveis são convertidas automaticamente de ASFF para OCSF usando mapeamentos pré-definidos.

Geração de Template: A solução cria um template do AWS CloudFormation contendo as regras transformadas, preservando sua ordem original e contexto regional.

Implantação e Validação: O template é revisado e implantado, criando as regras migradas em estado desabilitado por padrão, permitindo testes antes da ativação.

Componentes da Solução

A ferramenta é composta por quatro scripts Python que trabalham de forma coordenada:

Orquestrador: Coordena descoberta, transformação e geração, além de gerenciar relatórios e logs.

Descoberta de Regras: Identifica e extrai regras de automação existentes do Security Hub CSPM em regiões especificadas.

Transformação de Esquema: Converte regras de ASFF para OCSF utilizando o mapeamento de campos.

Geração de Template: Cria templates CloudFormation prontos para implantação.

Mapeamento de Campos: ASFF para OCSF

Para entender o escopo da migração, é importante conhecer como os campos se relacionam. Campos ASFF usados como critérios em regras mapeiam para seus equivalentes OCSF da seguinte forma:

Campos como AwsAccountId, ComplianceStatus, Confidence, CreatedAt, Description, SeverityLabel e Title possuem correspondentes diretos. Porém, Criticality, GeneratorId, NoteText, ResourceApplicationArn, UserDefinedFields e VerificationState são marcados como indisponíveis (N/A) e não podem ser migrados automaticamente.

Regras que dependem desses campos precisam ser redesenhadas manualmente na nova plataforma.

Da mesma forma, ações suportadas como modificação de Severity e atualização de Status são totalmente compatíveis. Porém, ações que envolvem Confidence, Criticality, RelatedFindings e VerificationState não possuem equivalente e precisarão ser recriadas ou removidas.

Conceitos-Chave Para a Migração

Estado Padrão das Regras Migradas

Por segurança, todas as regras migradas são criadas em estado desabilitado. Isso permite que você as revise, valide o comportamento e só então as ative. A solução pode opcionalmente criar regras já habilitadas, mas essa abordagem não é recomendada.

Ordem e Prioridade de Regras

Tanto no Security Hub CSPM quanto no novo Security Hub, a ordem de execução das regras importa — especialmente quando múltiplas regras podem afetar os mesmos campos. A solução preserva a ordem original de suas regras. Se você já possui regras no Security Hub novo, as regras migradas começam sua numeração após as existentes.

Quando múltiplas regiões estão envolvidas em um cenário de Região Base (home region), a ordem é preservada por região e agrupada na sequência final. Por exemplo: primeiramente todas as regras da Região 1, depois da Região 2, e assim por diante.

Regiões: Base vs. Individual

O Security Hub CSPM opera com regras baseadas em regiões — uma regra criada em uma região afeta apenas as descobertas geradas naquela região, mesmo se você usa uma região base para agregação central.

O novo Security Hub funciona de forma diferente: regras definidas na região base são aplicadas a todas as regiões vinculadas. Regras não podem ser criadas em regiões vinculadas, apenas em regiões não vinculadas, onde afetarão apenas suas descobertas locais.

A solução oferece dois modos de implantação para lidar com essas diferenças:

Modo Região Base: Usa regiões especificadas e recria as regras na região base, adicionando um critério extra que preserva o contexto regional original. Um único template CloudFormation é gerado.

Modo Região-por-Região: Gera um template separado para cada região, preservando o comportamento regional das regras originais. Templates são implantados individualmente.

Se você usa uma região base com algumas regiões vinculadas e outras não, execute o Modo Região Base para a região base e regiões vinculadas, depois o Modo Região-por-Região para regiões não vinculadas.

Pré-Requisitos e Configuração

Softwares Necessários

Antes de iniciar, você precisa de:

• AWS Command Line Interface (AWS CLI) na versão mais recente
• Python 3.12 ou posterior
• Pacotes Python: boto3 (versão mais recente) e pyyaml (versão mais recente)

Permissões Necessárias

Sua conta AWS precisa ter permissões para:

Descoberta e transformação: securityhub:ListAutomationRules, securityhub:BatchGetAutomationRules, securityhub:GetFindingAggregator, securityhub:DescribeHub, securityhub:ListAutomationRulesV2.

Implantação de template: cloudformation:CreateStack, cloudformation:UpdateStack, cloudformation:DescribeStacks, cloudformation:CreateChangeSet, cloudformation:DescribeChangeSet, cloudformation:ExecuteChangeSet, cloudformation:GetTemplateSummary, securityhub:CreateAutomationRuleV2, securityhub:UpdateAutomationRuleV2, securityhub:DeleteAutomationRuleV2, securityhub:GetAutomationRuleV2, securityhub:TagResource, securityhub:ListTagsForResource.

Configuração da Conta AWS

O Security Hub suporta um modelo de administrador delegado quando usado com AWS Organizations. Nesse modelo, um administrador delegado centraliza a gestão de descobertas e configuração de segurança em toda a organização.

Regras de automação devem ser criadas na conta do administrador delegado, na região base e em regiões não vinculadas. Contas membro não podem criar suas próprias regras.

A recomendação é usar a mesma conta como administrador delegado tanto para Security Hub CSPM quanto para o novo Security Hub, garantindo consistência. Configure sua AWS CLI com credenciais dessa conta antes de executar a migração.

Embora a solução seja principalmente para deployments com administrador delegado, também funciona com implementações de Security Hub em conta única.

Passo a Passo: Executando a Migração

Preparação e Execução

Para iniciar o processo de migração:

Primeiro, clone o repositório da ferramenta de migração. Acesse o repositório de amostras da AWS no GitHub e execute:

git clone https://github.com/aws-samples/sample-SecurityHub-Automation-Rule-Migration.git

Em seguida, consulte o arquivo README do repositório para obter as instruções de implementação mais atualizadas. Siga os passos especificados para executar os scripts. O processo gerará um template CloudFormation com suas regras de automação transformadas.

Implante o template usando a AWS CLI ou o console. Veja como criar uma stack no console do CloudFormation para detalhes completos.

Validação e Ativação das Regras

Após a implantação, acesse o console do Security Hub para revisar suas regras migradas. Lembre-se: elas começam desabilitadas por padrão.

Para cada regra migrada:

• Acesse a seção de Automações no Security Hub
• Selecione a regra e escolha Editar
• Revise seus critérios e ações com cuidado
• Use a opção de visualizar descobertas correspondentes para validar o comportamento esperado
• Se tudo estiver correto, ative a regra

Preste atenção especial às regras marcadas como “parcialmente migradas” em sua descrição. Isso significa que uma ou mais ações da regra original não têm equivalente no novo Security Hub. Essas regras podem se comportar diferentemente do que você espera e precisarão de revisão.

A solução também gera um relatório detalhando quais regras foram parcialmente migradas e especificando quais ações não puderam ser replicadas. Revise esse relatório cuidadosamente antes de habilitar essas regras.

Conclusão

A nova geração do AWS Security Hub oferece capacidades significativamente melhoradas para agregar, correlacionar e contextualizar descobertas de segurança. Embora a mudança de esquema de ASFF para OCSF traga benefícios em termos de interoperabilidade e integrações com parceiros, ela também exige que regras de automação existentes sejam transformadas.

A solução de migração automatizada simplifica esse processo, executando a descoberta, transformação e geração de templates de forma coordenada. Ao seguir as melhores práticas recomendadas — revisar o relatório de migração, testar regras em estado desabilitado, validar correspondências e ativar gradualmente — você consegue manter seus fluxos de trabalho de automação de segurança funcionando sem interrupções.

Para mais informações sobre o Security Hub e suas capacidades ampliadas, consulte a documentação oficial do Security Hub.

Fonte

Security Hub CSPM automation rule migration to Security Hub (https://aws.amazon.com/blogs/security/security-hub-cspm-automation-rule-migration-to-security-hub/)

Integração Estratégica: Bancos de Dados AWS na Vercel

Desde dezembro de 2025, a AWS disponibilizou seus bancos de dados no Marketplace da Vercel, marcando um passo importante na simplificação da infraestrutura para desenvolvedores. Agora é possível criar e conectar instâncias de Amazon Aurora PostgreSQL, Amazon Aurora DSQL e Amazon DynamoDB diretamente do dashboard da Vercel, sem necessidade de configurações complexas.

Como Começar

Para iniciar, desenvolvedores podem criar uma nova conta AWS diretamente pela Vercel, que já inclui acesso aos três serviços de banco de dados mencionados. A promoção oferece $100 USD em créditos que podem ser utilizados em qualquer uma das opções de banco de dados por até seis meses, reduzindo significativamente as barreiras de entrada para prototipagem e desenvolvimento.

Configuração Rápida e Produção Imediata

Uma vez que a conta está configurada, é possível ter um banco de dados Aurora pronto para produção ou uma tabela DynamoDB alimentando seus projetos Vercel em questão de segundos. Todo o gerenciamento — desde o plano escolhido até a adição de informações de pagamento e visualização de uso — pode ser feito no portal de configurações AWS acessível diretamente do dashboard da Vercel.

Capacidades e Vantagens Técnicas

A integração oferece opções serverless para Aurora PostgreSQL, Aurora DSQL e DynamoDB, simplificando as necessidades das aplicações e reduzindo custos através do dimensionamento automático para zero quando não há uso. Essa abordagem elimina a cobrança por recursos ociosos, tornando a solução especialmente atrativa para aplicações com padrões de consumo variáveis.

Cobertura Geográfica e Escalabilidade

Os bancos de dados podem ser criados em Regiões AWS estratégicas: US East (Virgínia do Norte), US East (Ohio), US West (Oregon), Europe (Irlanda), Europe (Frankfurt), Ásia Pacífico (Tóquio) e Ásia Pacífico (Mumbai). Novos locais estão previstos para o futuro, ampliando a disponibilidade para diferentes contextos geográficos.

Segurança e Confiabilidade

Os bancos de dados AWS entregam segurança, confiabilidade e eficiência de custo sem a sobrecarga operacional associada ao gerenciamento manual de infraestrutura. A abordagem é adequada tanto para desenvolvedores prototipando suas próximas ideias quanto para equipes mantendo aplicações de produção críticas e orientadas por dados ou inteligência artificial.

Próximos Passos

Para explorar melhor essas capacidades, a AWS fornece documentação completa na página AWS no Marketplace da Vercel. Além disso, o site de bancos de dados da AWS oferece informações técnicas detalhadas sobre cada serviço e suas possibilidades de integração.

Fonte

AWS Databases are now available on the Vercel Marketplace (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-databases-are-available-on-the-vercel/)

O Desafio do Rastreamento de Experimentos em Ambientes Distribuídos

Cientistas de dados frequentemente conduzem experimentos de machine learning em ambientes de dados diversos, como o Snowflake, utilizando a biblioteca Snowpark. No entanto, rastrear esses experimentos de forma centralizada apresenta desafios significativos. Manter um repositório único que monitore metadados de experimentos, parâmetros, hiperparâmetros, modelos, resultados e outras informações relevantes torna-se complexo quando esses processos ocorrem em plataformas distintas.

A AWS apresenta uma solução: integrar o MLflow gerenciado do SageMaker como repositório central para registro desses experimentos, estabelecendo um sistema unificado de monitoramento de progresso.

Capacidades do MLflow Gerenciado no SageMaker

O MLflow gerenciado da AWS oferece serviços totalmente gerenciados para rastreamento de experimentos, empacotamento de modelos e registro de modelos. O Registro de Modelos do SageMaker simplifica o versionamento e a implantação de modelos, facilitando transições suaves do desenvolvimento para produção.

A integração com Amazon S3, AWS Glue e Repositório de Características do SageMaker potencializa o gerenciamento de dados e a rastreabilidade de modelos. Os principais benefícios dessa arquitetura incluem:

• Padronização de fluxos de trabalho de machine learning em toda a organização
• Melhoria na colaboração entre equipes de ciência de dados
• Aceleração da adoção de IA/ML com infraestrutura mais segura e escalável

Arquitetura da Solução: Snowpark Integrado ao MLflow

A integração entre Snowflake e SageMaker permite um fluxo de trabalho coeso. O Snowpark para Python funciona como biblioteca do lado cliente, permitindo que código Python interaja com o Snowflake a partir de kernels Python, como os notebooks Jupyter do SageMaker.

Um fluxo de trabalho típico inclui preparação de dados no Snowflake, juntamente com engenharia de características e treinamento de modelos dentro do Snowpark. Posteriormente, o MLflow gerenciado do SageMaker é utilizado para rastreamento de experimentos e registro de modelos, integrados às capacidades do SageMaker. Essa abordagem permite que cientistas de dados executem transformações e engenharia de características no Snowflake e aproveitem a infraestrutura gerenciada do SageMaker para treinamento e implantação, facilitando orquestração de fluxos de trabalho mais suave e tratamento seguro dos dados.

Rastreamento Centralizado com MLflow

O rastreamento MLflow é fundamental nessa integração entre SageMaker, Snowpark e Snowflake, pois fornece um ambiente centralizado para registro e gerenciamento de todo o ciclo de vida do machine learning. Enquanto o Snowpark processa dados do Snowflake e treina modelos, o Rastreamento MLflow captura detalhes essenciais:

• Parâmetros e hiperparâmetros do modelo
• Métricas de desempenho
• Artefatos gerados durante o treinamento

Isso permite que cientistas de dados monitorem experimentos, comparem diferentes versões de modelos e verifiquem reprodutibilidade. Com as capacidades de versionamento e registro do MLflow, equipes podem rastrear resultados até o conjunto de dados específico e as transformações utilizadas, tornando mais simples monitorar o desempenho de modelos ao longo do tempo e manter um fluxo de trabalho de machine learning transparente e eficiente.

Essa abordagem oferece diversos benefícios práticos: fornece um rastreador MLflow escalável e gerenciado no SageMaker, enquanto aproveita as capacidades de processamento do Snowpark para inferência de modelo dentro do ambiente Snowflake, criando um sistema unificado de dados. O fluxo de trabalho permanece dentro do ambiente Snowflake, o que aprimora segurança e governança dos dados. Adicionalmente, reduz custos ao utilizar a potência de computação elástica do Snowflake para inferência sem necessidade de manter infraestrutura separada para servir modelos.

Pré-requisitos para Implementação

Antes de estabelecer o MLflow do SageMaker, é necessário criar e configurar os seguintes recursos:

• Uma conta Snowflake
• Um bucket S3 para rastrear experimentos no MLflow
• Uma conta Amazon SageMaker Studio
• Uma função (role) de Gerenciamento de Identidade e Acesso da AWS que seja Função de Execução de Domínio do SageMaker
• Um novo usuário com permissão para acessar o bucket S3 criado
• Confirmação de acesso à conta AWS através do Console de Gerenciamento AWS e da Interface de Linha de Comando AWS

O usuário do Gerenciamento de Identidade e Acesso deve possuir permissões para fazer as chamadas de serviço AWS necessárias. Ao conceder essas permissões, é importante seguir o princípio do menor privilégio.

Conectando Snowflake ao Servidor de Rastreamento MLflow

Para conectar o ambiente Snowflake ao Servidor de Rastreamento MLflow gerenciado do SageMaker, siga estas etapas:

Configuração Inicial no Snowflake

• Faça login no Snowflake como usuário administrador
• Crie um novo Notebook em Snowflake: Projects > Notebooks > +Notebook
• Altere a função para uma função não-administrador
• Atribua um nome, selecione banco de dados, schema, warehouse, e selecione ‘Run on container’
• Nas configurações do Notebook, ative a opção de acesso externo para permitir todas as integrações

Instalação de Dependências

Instale a biblioteca necessária executando:

!pip install sagemaker-mlflow

Configuração do MLflow e Execução de Experimentos

Execute o código do MLflow, substituindo o valor de ARN pelo seu:

import mlflow
import boto3
import logging

sts = boto3.client("sts")
assumed = sts.assume_role(
    RoleArn="",
    RoleSessionName="sf-session"
)
creds = assumed["Credentials"]
arn = ""

try:
    mlflow.set_tracking_uri(arn)
    mlflow.set_experiment("Default")
    with mlflow.start_run():
        mlflow.log_param("test_size", 0.2)
        mlflow.log_param("random_state", 42)
        mlflow.log_param("model_type", "LinearRegression")
except Exception as e:
    logging.error("Failed to set tracking URI: {e}")

Após uma execução bem-sucedida, os experimentos podem ser rastreados no MLflow do SageMaker. Clicando no nome da execução (“Run name”), é possível acessar insights detalhados sobre cada experimento.

Limpeza de Recursos

Para evitar custos contínuos, execute estas etapas para remover os recursos configurados:

• Delete a conta SageMaker Studio (isso também deleta o servidor de rastreamento MLflow)
• Delete o bucket S3 com seu conteúdo
• Remova o notebook do Snowflake
• Verifique que a conta SageMaker foi deletada

Considerações Finais

A integração entre o MLflow gerenciado do SageMaker e o Snowflake oferece uma solução abrangente para gerenciar o ciclo de vida completo do machine learning. Ao aproveitar o Snowpark, a solução aprimora ainda mais esse conjunto de capacidades, permitindo fluxos de trabalho mais suaves de processamento de dados e implantação de modelos.

Para começar, siga as instruções passo a passo fornecidas acima para configurar o Servidor de Rastreamento MLflow no SageMaker Studio e integrá-lo com o Snowflake. Lembre-se de implementar as práticas recomendadas de segurança da AWS, incluindo funções e permissões apropriadas de Gerenciamento de Identidade e Acesso, e garantindo que todas as credenciais sejam protegidas adequadamente. Os exemplos de código e instruções neste artigo servem como ponto de partida — podem ser adaptados para casos de uso e requisitos específicos enquanto se mantêm as práticas recomendadas de segurança e escalabilidade.

Fonte

Track machine learning experiments with MLflow on Amazon SageMaker using Snowflake integration (https://aws.amazon.com/blogs/machine-learning/track-machine-learning-experiments-with-mlflow-on-amazon-sagemaker-using-snowflake-integration/)