Blog

Dominando o Desafio do Aprendizado por Reforço em Larga Escala

O rápido avanço da inteligência artificial criou uma demanda crescente por modelos especializados capazes de tarefas complexas de raciocínio. Na programação competitiva, esse desafio é particularmente agudo: os modelos precisam gerar código funcional através de raciocínio algorítmico genuíno, não simples memorização de padrões.

O aprendizado por reforço (RL) oferece uma abordagem promissora nesse contexto. Diferentemente do aprendizado supervisionado tradicional, RL permite que modelos aprendam através de tentativa e erro, recebendo recompensas baseadas na execução real do código. Isso possibilita desenvolver capacidades verdadeiras de resolução de problemas em domínios algorítmicos.

Porém, implementar treinamento distribuído de RL para geração de código apresenta desafios infraestruturais significativos: orquestração de múltiplos componentes heterogêneos, coordenação de compilação paralela de código entre nós e manutenção de tolerância a falhas em processos de longa duração.

A Solução: Ray e SageMaker Integrados

Ray é um framework destacado para cargas de trabalho distribuídas que aborda esses desafios através de uma arquitetura unificada que gerencia todo o pipeline de IA. Seu design centrado em GPU e integração perfeita com ferramentas como Hugging Face Transformers e PyTorch o tornam ideal para cenários complexos.

A AWS combinou essas capacidades de Ray com a infraestrutura gerenciada do SageMaker através da solução Ray on Amazon SageMaker Training jobs. Essa integração automatiza a inicialização do cluster Ray, coordenação entre múltiplos nós e gerenciamento de recursos distribuídos, permitindo que desenvolvedores se concentrem no desenvolvimento do modelo enquanto usufruem dos recursos corporativos do SageMaker.

CodeFu-7B: Um Modelo Especializado em Programação

CodeFu-7B-v0.1 é um modelo de linguagem com 7 bilhões de parâmetros especificamente treinado para resolver problemas de programação competitiva. Construído sobre o modelo base DeepSeek-R1-Distill-Qwen-7B, demonstra como o aprendizado por reforço desenvolve capacidades de raciocínio algorítmico e geração eficiente de código C++, superando abordagens tradicionais de ajuste fino supervisionado.

O modelo foi treinado usando enunciados de problemas do dataset CodeContest da DeepMind, sem acesso a soluções corretas durante o treinamento. Essa abordagem força o modelo a aprender através de tentativa e erro baseado em feedback de execução de código, desenvolvendo capacidades genuínas de resolução de problemas em vez de memorização de padrões.

CodeFu é disponível publicamente no HuggingFace sob a licença MIT, tornando-o acessível para pesquisadores e profissionais interessados em geração de código e raciocínio algorítmico.

Arquitetura e Fluxo de Treinamento

O pipeline de treinamento do CodeFu com veRL e Ray no SageMaker segue uma sequência bem definida. Inicialmente, o dataset preprocessado do CodeContest e as configurações de treinamento são carregados. Em seguida, um job de treinamento SageMaker é submetido através da classe ModelTrainer do SDK Python do SageMaker.

Durante a execução, o progresso é monitorado em tempo real através do Ray Dashboard, com coleta opcional de métricas Prometheus, visualização Grafana e rastreamento de experimentos. Quando o treinamento é concluído, o SageMaker salva automaticamente o modelo treinado no S3, carrega logs de treinamento no CloudWatch e descomissiona o cluster de computação.

Essa arquitetura simplificada entrega uma experiência de treinamento de aprendizado por reforço completamente gerenciada, permitindo que desenvolvedores foquem no desenvolvimento do modelo enquanto Ray e SageMaker lidam com a orquestração complexa da infraestrutura distribuída — tudo dentro de um modelo de precificação pay-as-you-go que cobra apenas pelo tempo de computação efetivamente utilizado.

Otimização da Avaliação de Recompensas

O sistema de avaliação de recompensas implementa execução de código paralela através de funções remotas Ray, manipulando compilação C++ e execução de casos de teste. O framework veRL orquestra a execução distribuída através do componente main_ppo.py, coordenando três tipos principais de workers: ActorRolloutRefWorker para inferência de políticas e rollouts, CriticWorker para estimação de função de valor, e RewardModelWorker para pontuação de soluções geradas.

O algoritmo Group Relative Policy Optimization (GRPO) aprimora a otimização de política por proximidade tradicional (PPO) computando vantagens usando baselines relativos ao grupo, o que ajuda a estabilizar o treinamento reduzindo variância nas estimativas de gradiente de política.

A avaliação de recompensas segue um sistema hierárquico. Código não executável recebe penalidade severa (-1), falhas de compilação recebem penalidade moderada (-0.5), e código que excede limite de tempo recebe recompensa zero. Para soluções C++ executadas com sucesso, a recompensa é calculada como função linear baseada na fração de casos de teste privados passados, incentivando o modelo a resolver o máximo de casos possível enquanto evita overfitting aos testes públicos.

Implementação Prática no SageMaker

Para treinar CodeFu-7B usando veRL e Ray em jobs de treinamento SageMaker, utiliza-se a classe ModelTrainer do SDK Python do SageMaker. O primeiro passo é configurar a carga de trabalho de treinamento distribuída selecionando o tipo de instância apropriado — para este caso de uso recomenda-se mínimo de 2 instâncias p4de.24xlarge (cada uma com 8 GPUs NVIDIA A100), com possibilidade de escalar conforme necessário.

O treinamento usa um container Docker customizado que inclui veRL, Ray e as dependências necessárias para treinamento distribuído de RL. A classe ModelTrainer encapsula a configuração do treinamento baseado em Ray, permitindo especificar um script de entrada (entry_script) ou usar parâmetro de comando customizado para integração com frameworks especializados.

O script launcher.py funciona como ponto de entrada universal, detectando o ambiente SageMaker (nó único ou multi-nó, homogêneo ou heterogêneo) e inicializando o cluster Ray com coordenação apropriada de nó head/worker. Suas funcionalidades principais incluem setup do cluster Ray, coordenação entre nós head e worker, execução do script de treinamento especificado e conectividade com servidores Prometheus e Grafana externos para monitoramento abrangente.

Monitoramento e Observabilidade

O pipeline de treinamento CodeFu integra-se perfeitamente com Managed MLflow on Amazon SageMaker AI assim como soluções de terceiros, para rastreamento abrangente de experimentos e visualização de métricas de aprendizado por reforço.

Métricas críticas a monitorar incluem critic/reward/min (recompensa mínima — detecta falhas catastróficas), critic/reward/mean (recompensa média — indicador primário de progresso), critic/reward/max (recompensa máxima — desempenho de melhor caso), actor/ppo_kl (divergência KL entre iterações de política — deve manter-se estável), e val/test_score/code_contests (desempenho em conjunto de validação — mais importante para medir real melhoria do modelo).

Durante treinamento bem-sucedido, espera-se que critic/reward/mean melhore gradualmente, actor/ppo_kl permaneça baixo após spike inicial, e val/test_score/code_contests mostre melhoria consistente, com ambas as curvas (treinamento e validação) acompanhando proximamente, indicando aprendizado efetivo sem overfitting.

O acesso ao Ray Dashboard e habilitação de visualização Grafana durante treinamento pode ser estabelecido através de encaminhamento de porta usando AWS Systems Manager (SSM). O Ray Dashboard (porta 8265) fornece insights detalhados sobre utilização de workers, status de execução de tarefas e consumo de recursos, enquanto dashboards Grafana integrados oferecem visualização abrangente de métricas de treinamento, desempenho do sistema e saúde do cluster em tempo real.

Preparação de Dados e Configuração

O pipeline de preparação de dados transforma o dataset bruto do CodeContest em formato apropriado para treinamento de aprendizado por reforço. Filtros sistemáticos identificam problemas adequados, removendo aqueles com ratings Codeforces abaixo de 800 e implementando verificações de qualidade para casos de teste faltantes, descrições malformadas e restrições inválidas.

Problemas são categorizados em três níveis de dificuldade: Fácil (800-1000 pontos), Difícil (1100-2200 pontos) e Especialista (2300-3500 pontos). Cada problema é formatado com dois componentes: um prompt do usuário contendo o enunciado do problema, e especificação reward_model com casos de teste, limites de tempo e restrições de memória. Crucialmente, o campo ground_truth contém apenas casos de teste, sem código de solução, forçando o modelo a aprender através de sinais de recompensa em vez de memorizar soluções.

Pré-requisitos e Configuração Inicial

Antes de executar o treinamento, alguns requisitos devem ser atendidos. É necessário solicitar aumento de quota para instâncias p4de.24xlarge no console Service Quotas (mínimo de 2 para este caso de uso). Também é preciso criar uma função AWS Identity and Access Management (IAM) com políticas gerenciadas AmazonSageMakerFullAccess, AmazonS3FullAccess e AmazonSSMFullAccess.

Opcionalmente, pode-se criar um domínio Amazon SageMaker Studio para acessar Jupyter notebooks e executar o código de treinamento. Alternativamente, JupyterLab pode ser usado em setup local ou outro ambiente de desenvolvimento Python.

O código completo pode ser encontrado nos repositórios mencionados, que incluem definição completa do container Docker, scripts de entrada e configurações de treinamento.

Conclusão

A solução demonstra como treinar modelos especializados de raciocínio para programação competitiva usando veRL (Volcano Engine Reinforcement Learning) combinado com a infraestrutura gerenciada do SageMaker. Essa abordagem integrada simplifica a complexidade de orquestração de cargas de trabalho distribuídas de aprendizado por reforço, automatizando inicialização de cluster Ray, coordenação entre múltiplos nós e gerenciamento de recursos em ambientes heterogêneos.

A integração permite organizações aproveitarem capacidades avançadas de computação distribuída do Ray — incluindo suporte para arquiteturas multi-componentes complexas, alocação dinâmica de recursos e execução tolerante a falhas — enquanto usufruem da infraestrutura completamente gerenciada do SageMaker, segurança corporativa e modelo de precificação pay-as-you-go.

Para começar a implementar treinamento de aprendizado por reforço distribuído com Ray no SageMaker, visite o repositório do GitHub com a solução fundacional. A implementação completa do treinamento CodeFu-7B, incluindo integração veRL e exemplos de configuração, está disponível no repositório de exemplos da AWS.

Fonte

Train CodeFu-7B with veRL and Ray on Amazon SageMaker Training jobs (https://aws.amazon.com/blogs/machine-learning/train-codefu-7b-with-verl-and-ray-on-amazon-sagemaker-training-jobs/)

Acesso aos Modelos Anthropic Claude através da AWS no Sudeste Asiático

A AWS expandiu a disponibilidade de seus modelos de inteligência artificial generativa para países do Sudeste Asiático. Organizações na Tailândia, Malásia, Singapura, Indonésia e Taiwan conseguem agora acessar os modelos Claude Opus 4.6, Sonnet 4.6 e Haiku 4.5 da Anthropic através de uma arquitetura de inferência distribuída globalmente chamada Inferência Global entre Regiões (CRIS) no Amazon Bedrock.

Essa capacidade oferece três vantagens principais para organizações que trabalham com IA generativa: maiores limites de uso, redução de custos e roteamento inteligente de requisições entre mais de 20 regiões comerciais da AWS globalmente, permitindo casos de uso como chatbots, agentes autônomos de programação e sistemas de análise financeira.

Como Funciona a Arquitetura de Inferência Global

A CRIS é um recurso poderoso do Amazon Bedrock que permite distribuir o processamento de inferência entre múltiplas regiões da AWS sem necessidade de alterações complexas na aplicação. A tecnologia opera através dos conceitos de Região de Origem e Região de Destino. A Região de Origem é aquela a partir da qual você faz a requisição da API, enquanto a Região de Destino é para onde a AWS pode rotear a requisição para processamento.

Quando você submete uma requisição de inferência a partir de uma região de origem, o CRIS roteia inteligentemente a requisição para uma das regiões de destino configuradas no perfil de inferência através da rede gerenciada pelo Bedrock. O tráfego viaja pela rede global da AWS, e as respostas retornam à sua aplicação na região de origem.

Um ponto importante é que enquanto o processamento da inferência ocorre em outra região, os dados em repouso — incluindo logs, bases de conhecimento e configurações armazenadas — permanecem exclusivamente na sua região de origem. A AWS oferece dois tipos de perfis de inferência entre regiões: o CRIS Geográfico (que roteia dentro de uma geografia específica como EUA, Europa ou Ásia-Pacífico) e o CRIS Global (que roteia para regiões comerciais suportadas em todo o mundo).

Toda a comunicação utiliza a rede segura da AWS com criptografia de ponta a ponta para dados em trânsito e em repouso.

Regiões Disponíveis e Configuração Inicial

Clientes na Tailândia, Malásia, Singapura, Indonésia e Taiwan podem invocar os perfis de inferência global a partir das seguintes regiões de origem:

• Ásia-Pacífico (Singapura) — ap-southeast-1
• Ásia-Pacífico (Jacarta) — ap-southeast-3
• Ásia-Pacífico (Taipei) — ap-east-2
• Ásia-Pacífico (Tailândia) — ap-southeast-7
• Ásia-Pacífico (Malásia) — ap-southeast-5

Cada uma dessas regiões pode rotear requisições para mais de 20 regiões comerciais da AWS globalmente. O roteamento é gerenciado automaticamente pelo CRIS, sem intervenção manual necessária.

Configuração de Permissões com IAM

Antes de utilizar o CRIS, é necessário configurar permissões de Identidade e Acesso (IAM) que habilitem o roteamento entre regiões. A configuração requer três declarações de política porque o CRIS roteia requisições entre regiões: você chama o perfil de inferência na sua região de origem, que então invoca o modelo de base em qualquer região de destino que o CRIS selecionar.

A terceira declaração utiliza "aws:RequestedRegion": "unspecified" para conceder as permissões necessárias ao CRIS rotear suas requisições entre regiões.

Um detalhe importante: se as políticas de controle de serviço (SCPs) da sua organização negarem acesso a regiões não especificadas, o CRIS não funcionará. Recomenda-se validar sua configuração de SCP antes de implantar workloads em produção que dependam de roteamento global.

Utilizando os Perfis de Inferência entre Regiões

Os perfis de inferência global são identificados pelo prefixo global. no identificador do modelo — uma convenção de nomenclatura que você pode usar para distinguir perfis de roteamento global de IDs de modelo regionais ou de uma única região.

Use estes identificadores de perfil de inferência ao fazer chamadas de API, em vez dos IDs de modelo padrão:

• global.anthropic.claude-opus-4-6-v1 (Claude Opus 4.6)
• global.anthropic.claude-sonnet-4-5-20250929-v1:0 (Claude Sonnet 4.5)
• global.anthropic.claude-haiku-4-5-20251001-v1:0 (Claude Haiku 4.5)

Tanto a API InvokeModel quanto a API Converse suportam perfis de inferência entre regiões. A recomendação é usar a API Converse, pois oferece uma interface simplificada e formato consistente de requisição/resposta entre diferentes modelos de base.

Primeiro Teste com a API

Começar com o CRIS requer apenas poucas alterações no código existente da aplicação. Aqui está um exemplo de como invocar o Claude Opus 4.6 usando CRIS em Python com o SDK boto3:

import logging
import os
import boto3
from botocore.exceptions import ClientError

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Load configuration from environment variables with defaults
REGION = os.getenv(
    "AWS_REGION", "ap-southeast-1"
)  # Singapore or Jakarta (ap-southeast-3)
MODEL_ID = os.getenv("MODEL_ID", "global.anthropic.claude-opus-4-6-v1")
MAX_TOKENS = int(os.getenv("MAX_TOKENS", "8000"))
TEMPERATURE = float(os.getenv("TEMPERATURE", "1"))
THINKING_TYPE = os.getenv("THINKING_TYPE", "adaptive")
EFFORT_LEVEL = os.getenv("EFFORT_LEVEL", "medium")

# Initialize Bedrock Runtime client for your Region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Example: Architecture trade-offs analysis
user_query = "Analyze the trade-offs between microservices and monolithic architectures for a mid-size SaaS company."

# Make inference request using Converse API with adaptive thinking
try:
    response = bedrock_runtime.converse(
        modelId=MODEL_ID,
        messages=[{"role": "user", "content": [{"text": user_query}]}],
        inferenceConfig={"maxTokens": MAX_TOKENS, "temperature": TEMPERATURE},
        additionalModelRequestFields={
            "thinking": {"type": THINKING_TYPE},
            "output_config": {"effort": EFFORT_LEVEL},
        },
    )
except ClientError as e:
    logger.error("Failed to invoke model %s: %s", MODEL_ID, e)
    raise

# Extract response content
output_message = response["output"]["message"]
has_thinking = any(block.get("type") == "thinking" for block in output_message["content"])
logger.info("Effort level: %s", EFFORT_LEVEL)
logger.info("Claude decided to think: %s", has_thinking)
for block in output_message["content"]:
    if block.get("type") == "thinking":
        thinking_tokens = len(block["thinking"].split())
        logger.info("[Thinking]: ~%d words", thinking_tokens)
    elif block.get("text"):
        logger.info("[Response]: %s", block["text"])

Um aspecto importante é que o monitoramento continua funcionando normalmente. Suas métricas do CloudWatch, logs e registros de auditoria do CloudTrail permanecem em sua região de origem, mesmo quando as requisições de inferência são processadas em outro lugar. Seus dashboards e alarmes existentes continuam funcionando exatamente como antes.

Gerenciamento de Cotas de Uso

À medida que sua aplicação escala de protótipo para produção, compreender e gerenciar cotas de serviço torna-se crítico. O Amazon Bedrock aplica cotas de serviço para garantir alocação justa de recursos e estabilidade do sistema.

Para o CRIS, as cotas são medidas em duas dimensões. Tokens por Minuto (TPM) é o número máximo de tokens (entrada + saída) que podem ser processados por minuto. Requisições por Minuto (RPM) é o número máximo de requisições de inferência que podem ser feitas por minuto.

Um detalhe técnico importante: a AWS utiliza uma taxa de consumo de tokens que pondera tokens de saída mais pesadamente que tokens de entrada. A taxa é de 5:1 — tokens de saída consomem cinco vezes mais quota que tokens de entrada, porque gerar tokens requer mais computação que processar entrada.

A fórmula é: Consumo de quota = Tokens de entrada + (Tokens de saída × 5)

Por exemplo, se sua requisição usa 10 mil tokens de entrada e gera 5 mil tokens de saída, o consumo total seria 35 mil tokens (10.000 + 5.000 × 5). Se sua aplicação processa requisições com esse padrão a 100 requisições por minuto, o consumo total de quota seria 3,5 milhões de TPM.

Ao trabalhar com seu gerenciador de conta da AWS em solicitações de aumento de quota, forneça seu volume de requisições esperado, tokens de entrada médios por requisição e tokens de saída médios para que calculem a alocação apropriada.

A recomendação é configurar alarmes do CloudWatch em 70-80% de utilização de quota para solicitar aumentos antes de atingir limites de throttling. As métricas InputTokenCount e OutputTokenCount rastreiam seu consumo em tempo real.

Para workloads não sensíveis ao tempo, o Claude Haiku 4.5 suporta inferência em lote com economia de custo de 50%. Requisições em lote são processadas de forma assíncrona dentro de 24 horas e não contam contra sua quota de TPM em tempo real.

Solicitando Aumentos de Cotas

Você pode visualizar suas cotas atuais no Console de Cotas de Serviço da AWS navegando até as cotas de serviço do Amazon Bedrock em sua região de origem.

Se seu workload requer cotas além dos limites padrão, você pode solicitar aumentos através do console. Para solicitações de grande escala ou lançamentos sensíveis ao tempo, recomenda-se trabalhar com sua equipe de contas da AWS para garantir planejamento apropriado de capacidade.

Escolhendo entre os Modelos Claude

Considere complexidade da tarefa, requisitos de latência, restrições de custo e necessidades de acurácia ao escolher entre os modelos. O Claude Opus 4.6 é recomendado para tarefas mais complexas que requerem inteligência de fronteira, como raciocínio multi-passos complexo, agentes autônomos sofisticados e análise crítica de precisão.

O Claude Sonnet 4.6 é adequado para problemas complexos que requerem planejamento e execução de agentes. O Claude Haiku 4.5 oferece desempenho próximo à fronteira com custo mais baixo, tornando-o ideal para operações de alto volume e experiências sensíveis a latência.

Para arquiteturas multi-agente, considere usar Opus 4.6 ou Sonnet 4.6 como orquestrador e Haiku 4.5 para execução paralela de workers.

Otimizações Avançadas

Cache de Prompts para Contexto Repetido

O cache de prompts oferece até 90% de redução de custos em tokens em cache e até 85% de melhoria de latência para workloads que reutilizam o mesmo contexto. Você deve cachear prompts de sistema que excedem 500 tokens, conteúdo de documentação, exemplos com poucos disparadores e definições de ferramentas. Estruture prompts com conteúdo estático primeiro, seguido por consultas dinâmicas. Consulte a documentação de cache de prompts para inferência mais rápida para detalhes de implementação.

Raciocínio Adaptativo e Estendido

O Claude Opus 4.6 suporta raciocínio adaptativo, uma evolução do raciocínio estendido que dá ao Claude liberdade para pensar se e quando determina que raciocínio é necessário. Você pode orientar quanto de raciocínio o Claude aloca usando o parâmetro de esforço, otimizando desempenho e velocidade.

Sonnet 4.6 e Haiku 4.5 suportam raciocínio estendido, onde o modelo gera etapas de raciocínio intermediárias através de decomposição de problemas, auto-correção e exploração de múltiplos caminhos de solução. Esses recursos de raciocínio oferecem melhorias de acurácia em tarefas de raciocínio complexo.

Testes de Carga para Validação de Cotas

Execute testes de carga antes do lançamento em produção para medir o consumo real de cotas sob tráfego máximo. Configure seu cliente de teste com modo de retry adaptativo, use ferramentas como Locust ou boto3 com threading para simular requisições concorrentes, e monitore as métricas do CloudWatch durante seu teste para observar padrões de consumo de TPM e RPM.

Próximos Passos

A inferência global entre regiões no Amazon Bedrock entrega os modelos Claude para organizações no Sudeste Asiático com duas vantagens principais: economia de custos comparada a perfis regionais e roteamento inteligente entre mais de 20 regiões da AWS para máxima disponibilidade e escala.

Essa infraestrutura habilita aplicações de IA generativa em produção em toda a região Sudeste Asiática, desde atendimento ao cliente em tempo real até análise financeira e assistentes autônomos de programação.

Para começar com a inferência global entre regiões, siga estes passos:

• Acesse o console do Amazon Bedrock em qualquer uma das regiões de origem listadas acima
• Configure permissões de IAM usando o modelo de política fornecido
• Faça sua primeira chamada de API usando o ID de perfil de inferência global
• Implemente cache de prompts para economia de custos em contexto repetido

Para mais informações, consulte:

• Documentação do Amazon Bedrock
• Guia do Usuário de Inferência entre Regiões
• Preços do Amazon Bedrock
• Documentação do Anthropic Claude
• Comece com Amazon Bedrock

Fonte

Global cross-Region inference for latest Anthropic Claude Opus, Sonnet and Haiku models on Amazon Bedrock in Thailand, Malaysia, Singapore, Indonesia, and Taiwan (https://aws.amazon.com/blogs/machine-learning/global-cross-region-inference-for-latest-anthropic-claude-opus-sonnet-and-haiku-models-on-amazon-bedrock-in-thailand-malaysia-singapore-indonesia-and-taiwan/)

Novos modelos Claude disponíveis no Oriente Médio

A AWS anunciou a disponibilidade de cinco modelos Claude da Anthropic através do Amazon Bedrock com suporte à inferência distribuída entre regiões para clientes operando no Oriente Médio. Os modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 e Claude Haiku 4.5 agora estão acessíveis nas regiões me-central-1 (Emirados Árabes Unidos) e me-south-1 (Bahrein), beneficiando-se do roteamento inteligente de inferência através da infraestrutura global da AWS.

Com essa expansão, organizações no Oriente Médio podem escalar suas cargas de trabalho de IA de forma contínua, melhorar a resiliência de suas aplicações e reduzir a complexidade operacional de gerenciar múltiplas regiões manualmente.

Entendendo a inferência distribuída entre regiões

O conceito de inferência distribuída entre regiões no Amazon Bedrock funciona através de um mecanismo de roteamento automático e inteligente. Quando uma solicitação é feita através de um perfil de inferência entre regiões, a requisição originária de sua região-fonte é automaticamente direcionada para uma das regiões de destino pré-configuradas no perfil.

Um aspecto importante dessa abordagem é a segurança dos dados. A transmissão ocorre através da rede global gerenciada pela AWS com criptografia de ponta a ponta. Diferentemente do que alguns poderiam supor, a inferência entre regiões não altera o local onde os dados são armazenados—os dados do cliente não residem na região de destino. Os registros gerenciados pelo cliente (como logs de invocação de modelos), bases de conhecimento e configurações armazenadas permanecem exclusivamente na região-fonte. A resposta criptografada retorna à sua aplicação na região original.

Capacidades dos modelos Claude disponibilizados

Cada variante de modelo Claude oferece características distintas para diferentes necessidades:

Claude Opus 4.6

Traz capacidades avançadas para tarefas de agentic, projetos complexos de codificação e fluxos de trabalho de nível empresarial que exigem raciocínio profundo e confiabilidade. É a opção mais potente quando se prioriza desempenho e capacidade de análise.

Claude Sonnet 4.6

Equilibra inteligência, velocidade e custo-efetividade, sendo ideal para aplicações em produção e tarefas multi-etapas onde é necessário encontrar um bom ponto de equilíbrio entre performance e recursos.

Claude Haiku 4.5

Otimizado para respostas de baixa latência, adequado para casos de uso em tempo real como assistentes de IA e geração de conteúdo em alto volume, priorizando velocidade de resposta.

Ao combinar esses modelos com a inferência distribuída entre regiões, as organizações podem dinamicamente escalar cargas de trabalho de IA entre regiões mantendo desempenho ótimo, selecionando o modelo certo conforme seus requisitos específicos.

Benefícios da inferência distribuída entre regiões

Melhor desempenho durante picos de demanda

Para organizações no Oriente Médio, a inferência distribuída fornece resiliência crítica durante períodos de pico regional—como durante o Ramadã, eventos de compras importantes ou horários comerciais de alto tráfego. O sistema automaticamente roteia requisições para regiões com capacidade disponível na infraestrutura global, garantindo que suas aplicações mantenham performance mesmo durante picos inesperados de tráfego. Esse roteamento acontece de forma transparente e é completamente gerenciado pelo Amazon Bedrock. Para aplicações críticas do negócio que servem clientes pela região do Golfo e mais amplamente na região MENAT, isso significa evitar tempo de inatividade custoso ou degradação de performance que poderia impactar receita e confiança do cliente.

Transmissão segura de dados

Os dados transmitidos durante operações entre regiões são gerenciados pelo Amazon Bedrock com criptografia em trânsito entre regiões, ajudando a atender aos requisitos rigorosos de segurança e proteção de dados importantes para organizações no Oriente Médio.

Estratégia multi-região simplificada

As organizações não precisam mais arquitetar manualmente implantações complexas em múltiplas regiões. A inferência distribuída entre regiões fornece resiliência de nível empresarial sem a sobrecarga operacional de gerenciar múltiplos endpoints regionais.

Suporte à transformação digital acelerada

À medida que organizações do Oriente Médio aceleram iniciativas de transformação digital alinhadas com visões nacionais (como Saudi Vision 2030 e a Estratégia de IA dos Emirados), a inferência distribuída entre regiões proporciona a escalabilidade necessária para apoiar projetos ambiciosos de IA sem limitações de capacidade.

Monitoramento simplificado

O Amazon CloudWatch e AWS CloudTrail continuam registrando entradas de log em sua região-fonte do Oriente Médio, fornecendo uma visão centralizada do desempenho de sua aplicação. Essa observabilidade simplificada significa que suas equipes podem monitorar e gerenciar aplicações de IA generativa usando ferramentas AWS familiares, independentemente de onde as requisições são processadas globalmente, tornando conformidade e gerenciamento operacional mais diretos.

Flexibilidade de cota sob demanda

A inferência distribuída entre regiões ajuda a remover as limitações impostas pelas cotas de capacidade de regiões individuais. Suas cargas de trabalho podem dinamicamente acessar recursos através da infraestrutura global da AWS, tornando simples manipular aplicações de alto volume e picos súbitos de tráfego comuns na economia digital em rápido crescimento da região.

Casos de uso práticos

A disponibilidade dos modelos Claude através de inferência distribuída entre regiões desbloqueia uma ampla gama de aplicações para clientes no Oriente Médio:

• Copilots corporativos e assistentes de IA que exigem alta disponibilidade e performance consistente
• Fluxos de trabalho agentic que orquestram raciocínio complexo e uso de ferramentas
• Ferramentas de produtividade para desenvolvedores focadas em geração, revisão e transformação de código
• Aplicações de engajamento com clientes que requerem escala elástica
• Análise avançada de dados e processamento de documentos

Gerenciamento de cotas

Para ver as cotas padrão de throughput entre regiões ao usar perfis de inferência global, consulte os valores de requisições de inferência de modelo entre regiões por minuto e tokens de inferência de modelo entre regiões por minuto nas cotas de serviço do Amazon Bedrock. Você pode solicitar, visualizar e gerenciar cotas para o perfil de inferência distribuída através do console de Cotas de Serviço ou usando comandos da Interface de Linha de Comando da AWS (CLI) em sua região-fonte.

Primeiros passos na prática

Para começar a usar os modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 ou Claude Haiku 4.5 com inferência distribuída entre regiões (por exemplo, na região me-central-1), execute os seguintes passos:

Verificar permissões de acesso

Confirme que seu usuário ou função Gerenciamento de Identidade e Acesso da AWS (IAM) possui as permissões necessárias para invocar modelos do Amazon Bedrock usando um perfil de inferência entre regiões.

Invocar o modelo através de APIs

Use as APIs do Amazon Bedrock ou SDKs (Software Development Kits) da AWS:

import boto3
import json

bedrock = boto3.client('bedrock-runtime', region_name='me-central-1')
model_id = "global.anthropic.claude-sonnet-4-6"

response = bedrock.converse(
    messages=[{"role": "user", "content": [{"text": "Explain cloud computing in 2 sentences."}]}],
    modelId=model_id,
)

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

Monitorar uso e desempenho

Você pode monitorar uso, performance e custos através do CloudWatch e AWS Cost Explorer para escalar suas aplicações conforme a demanda cresce.

Considerações finais

Com o lançamento dos modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 e Claude Haiku 4.5 usando inferência distribuída entre regiões do Amazon Bedrock, clientes no Oriente Médio podem agora construir aplicações de IA generativa altamente escaláveis e resilientes sem a sobrecarga operacional de gerenciar manualmente capacidade de inferência regional. Essa funcionalidade oferece a base infraestrutural para que organizações acelerem inovação e entreguem experiências impactantes potencializadas por IA em toda a região.

Para aprender mais detalhes técnicos, consulte o guia Primeiros passos com inferência entre regiões no Amazon Bedrock.

Fonte

Introducing Amazon Bedrock global cross-Region inference for Anthropic’s Claude models in the Middle East Regions (UAE and Bahrain) (https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-global-cross-region-inference-for-anthropics-claude-models-in-the-middle-east-regions/)

Uma nova abordagem para observabilidade em nuvem

A AWS anunciou recentemente a integração de sua solução de observabilidade como Kiro Power, ampliando as capacidades oferecidas através da plataforma Kiro. Essa integração representa um avanço significativo para profissionais que trabalham com infraestrutura e aplicações em nuvem, permitindo acelerar investigações de problemas com o apoio de agentes de IA integrados ao ambiente de desenvolvimento.

Para contextualizar: Kiro Powers é um repositório curado e pré-configurado que reúne servidores de Protocolo de Contexto do Modelo (MCP), arquivos de direcionamento e hooks validados por parceiros Kiro, facilitando o desenvolvimento e implantação de soluções especializadas.

Estrutura técnica da solução

Os componentes do AWS Observability Power

O AWS Observability Power agrupa quatro servidores MCP especializados, cada um projetado para um aspecto diferente da observabilidade:

• CloudWatch MCP server — responsável por acessar dados de observabilidade
• Application Signals MCP server — fornece monitoramento de performance de aplicações
• CloudTrail MCP server — suporta análise de segurança e conformidade
• AWS Documentation MCP server — oferece acesso a referências contextuais

Essa arquitetura integrada oferece aos agentes Kiro um contexto abrangente para executar fluxos de trabalho especializados, incluindo resposta a alarmes, detecção de anomalias, rastreamento distribuído, monitoramento de SLO (Acordos de Nível de Serviço) e investigações de segurança.

Análise automatizada de lacunas de instrumentação

Além das capacidades principais, o poder inclui um mecanismo de análise automatizada de lacunas que identifica padrões ausentes na instrumentação do código. Isso abrange situações como erros não registrados, identificadores de correlação faltantes ou rastreamento distribuído ausente, fornecendo recomendações acionáveis para melhorias.

Benefícios práticos para operações

Redução do tempo de resolução de incidentes

A solução atende a dois objetivos críticos em operações de TI. Primeiro, ao investigar um alarme ativo, o poder carrega dinamicamente a orientação relevante e sinais operacionais, assegurando que os agentes de IA recebam apenas o contexto necessário para a tarefa de troubleshooting específica. Isso reduz significativamente o tempo de resolução médio (MTTR).

Melhoria proativa da pilha de observabilidade

Segundo, a análise automatizada de lacunas permite que equipes identifiquem e resolvam proativamente problemas de instrumentação antes que eles afetem a detecção de incidentes. O poder acompanha oito guias de direcionamento abrangentes cobrindo resposta a incidentes, alertas, monitoramento de performance, auditoria de segurança e análise de lacunas.

Disponibilidade e instalação

O AWS Observability Power está disponível para instalação com um clique dentro do Kiro IDE e na página de Kiro Powers, funcional em todas as regiões AWS. Cada servidor MCP subjacente opera conforme o suporte regional do serviço AWS correspondente.

Desenvolvedores podem agora acelerar o troubleshooting de aplicações distribuídas e infraestrutura diretamente em seu ambiente de desenvolvimento integrado (IDE), transformando minutos que seriam gastos em investigação manual em processos assistidos e guiados.

Para explorar mais detalhes sobre os servidores MCP de observabilidade da AWS, a documentação técnica está disponível para consulta.

Fonte

AWS Observability now available as a Kiro power (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-observability-kiro-power/)

O que é o AWS Elemental Inference

A AWS anunciou a disponibilidade geral do Elemental Inference, um serviço totalmente gerenciado de Inteligência Artificial que oferece aos broadcasters e streamers a capacidade de gerar automaticamente conteúdo otimizado para dispositivos móveis e plataformas sociais em tempo real. O diferencial está em sua arquitetura paralela: o processamento de vídeo acontece simultaneamente com a codificação, permitindo que empresas e criadores de conteúdo alcancem audiências em diversos formatos sem necessitar de conhecimento especializado em IA ou equipes dedicadas exclusivamente à produção.

Processamento de Vídeo Único, Distribuição Múltipla

Um dos pontos-chave do Elemental Inference é seu modelo de processamento: processa-se o vídeo uma única vez e o otimiza para todos os destinos. Enquanto transmissão principal é codificada, o serviço gera simultaneamente versões verticais para plataformas como TikTok, Instagram Reels, YouTube Shorts e Snapchat. Essa abordagem paralela elimina a necessidade de pipelines separados de produção.

Para exemplificar: uma emissora de esportes pode gerar automaticamente clips de destaque em formato vertical durante transmissões ao vivo e distribuí-los para redes sociais em tempo real, capturando momentos virais conforme ocorrem, em vez de horas depois.

Recursos de IA Disponíveis

O serviço foi lançado com dois recursos principais impulsionados por IA:

• Recorte de vídeo vertical: transforma automaticamente transmissões em landscape (ao vivo ou sob demanda) em formatos otimizados para dispositivos móveis
• Análise avançada de metadados: identifica momentos-chave em conteúdo ao vivo para gerar automaticamente clips de destaque

Ambos os recursos funcionam através de uma aplicação de IA que não requer prompts ou intervenção manual. O sistema adapta o conteúdo automaticamente para cada plataforma, permitindo que broadcasters escalem produção sem adicionar fluxos de trabalho manuais ou contratar mais staff.

Eficiência Operacional Comprovada

Durante a fase de testes em beta, grandes empresas de mídia relataram economia de 34% ou superior em fluxos de trabalho de vídeo ao vivo com IA, comparado ao uso de múltiplas soluções pontuais. Esse resultado reforça o valor da integração centralizada versus abordagens fragmentadas.

Disponibilidade Regional

O AWS Elemental Inference está disponível nas seguintes regiões da AWS: US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai) e Europe (Ireland).

Próximas Etapas

Para conhecer mais detalhes, a AWS recomenda consultar o AWS News Blog ou explorar a documentação do AWS Elemental Inference.

Fonte

Announcing AWS Elemental Inference (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-elemental-inference-generally-avail/)

Exportação de Snapshots RDS para S3 no AWS GovCloud

A AWS anunciou a disponibilidade do recurso de Exportação de Snapshots do RDS para S3 nas regiões do AWS GovCloud (US). Essa funcionalidade permite que organizações exportem dados de snapshots em formato Apache Parquet, viabilizando cenários de análise de dados, retenção de informações e aplicações de machine learning.

Capacidades e Características Técnicas

O recurso funciona de forma abrangente e flexível. Ele suporta todos os tipos de snapshots de banco de dados: snapshots manuais, snapshots de sistema automatizados e snapshots criados via AWS Backup. Uma característica importante é que a exportação ocorre diretamente sobre o snapshot, sem impacto no desempenho da base de dados em operação.

Formato e Interoperabilidade

Os dados exportados no formato Apache Parquet podem ser analisados utilizando diversos serviços e ferramentas. Na plataforma AWS, é possível integrar com Amazon Athena, Amazon SageMaker e Amazon Redshift Spectrum. Além disso, a solução é compatível com frameworks de processamento de big data como Apache Spark, oferecendo flexibilidade para diferentes arquiteturas de análise.

Simplicidade de Uso

A criação de uma exportação de snapshot é realizada com facilidade através do Console de Gerenciamento do Amazon RDS, ou alternativamente, usando AWS SDK ou AWS CLI para automação e integração em pipelines.

Mecanismos de Banco de Dados Suportados

O recurso de exportação para S3 está disponível para os seguintes tipos de bancos de dados:

• Amazon Aurora PostgreSQL – Compatible Edition
• Amazon Aurora MySQL
• Amazon RDS para PostgreSQL
• Amazon RDS para MySQL
• Amazon RDS para MariaDB

Próximos Passos

Para implementar essa solução em seu ambiente, consulte a documentação do Aurora ou a documentação do Amazon RDS, onde você encontrará instruções detalhadas para começar a utilizar o recurso.

Fonte

Amazon RDS Snapshot Export to S3 now available in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/02/rds-exports-s3-available-gov-cloud/)

O que muda no Amazon Bedrock

A AWS anunciou um aprimoramento significativo no Amazon Bedrock, seu serviço de modelos de IA em larga escala. Agora, o serviço suporta execução de ferramentas no servidor por meio da integração do Amazon Bedrock AgentCore Gateway com a API Responses. Essa novidade permite que os clientes conectem suas ferramentas do AgentCore Gateway diretamente aos modelos do Amazon Bedrock, possibilitando execução de ferramentas no servidor sem a necessidade de orquestração no lado do cliente.

Como funciona a integração

O funcionamento é direto e eficiente. Ao fazer requisições pela API Responses, os clientes podem especificar um ARN (Amazon Resource Name) do AgentCore Gateway como um conector de ferramentas. A partir daí, o Amazon Bedrock realiza automaticamente a descoberta das ferramentas disponíveis no gateway, as apresenta ao modelo durante a inferência e executa as chamadas de ferramentas no servidor quando o modelo as seleciona. Tudo isso acontece dentro de uma única chamada da API.

Esse fluxo integrado oferece uma vantagem clara: elimina a necessidade de os clientes construírem e manterem loops de orquestração no lado do cliente. O resultado é uma redução significativa na complexidade das aplicações e na latência dos fluxos de trabalho com agentes de IA.

Segurança e controle

A implementação mantém o controle total nas mãos dos clientes. O acesso às ferramentas é governado pelas configurações existentes do AgentCore Gateway e pelas permissões do AWS IAM (Gerenciamento de Identidade e Acesso), garantindo que apenas as ferramentas autorizadas possam ser acessadas e executadas.

Compatibilidade e recursos

A execução de ferramentas no servidor com AgentCore Gateway está disponível para todos os modelos suportados pela API Responses do Amazon Bedrock. Os clientes definem as ferramentas usando o tipo de conector do servidor MCP com o ARN do gateway, e o Amazon Bedrock gerencia automaticamente a descoberta de ferramentas, a seleção orientada pelo modelo, a execução e a injeção de resultados.

Um destaque importante: o serviço suporta múltiplas chamadas de ferramentas em um único turno de conversa, e os resultados das ferramentas são transmitidos de volta ao cliente em tempo real.

Disponibilidade e próximos passos

Essa capacidade está disponível em caráter geral (GA) em todas as regiões da AWS onde tanto a API Responses do Amazon Bedrock quanto o Amazon Bedrock AgentCore Gateway estão disponíveis. Para começar, recomenda-se consultar a documentação do Amazon Bedrock ou acessar o console do Amazon Bedrock. Informações adicionais sobre o Amazon Bedrock AgentCore Gateway podem ser encontradas na documentação do AgentCore.

Fonte

Amazon Bedrock now supports server-side tool execution with AgentCore Gateway (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-server-side-tool-execution-agentcore-gateway/)

O Desafio de Organizar Grandes Coleções de Fotos

Gerenciar acervos fotográficos expressivos apresenta desafios significativos para organizações e indivíduos. As abordagens tradicionais baseiam-se em etiquetagem manual, metadados simples e organização por pastas, estratégias que se tornam impraticáveis quando se lida com milhares de imagens contendo múltiplas pessoas e relacionamentos complexos. A rotulação manual consome tempo considerável, as buscas por metadata simples oferecem resultado limitado, e a estrutura de pastas frequentemente não reflete a forma como as pessoas realmente buscam suas memórias.

Sistemas de busca fotográfica inteligente resolvem esse problema combinando visão computacional, bancos de dados em grafo e processamento de linguagem natural. Essas soluções capturam não apenas quem e o que aparece nas fotos, mas os relacionamentos e contextos complexos que as tornam significativas, viabilizando consultas em linguagem natural e descoberta semântica genuína.

Uma Arquitetura Serverless Integrada

A AWS demonstrou como construir um sistema completo de busca fotográfica utilizando o AWS Cloud Development Kit (AWS CDK), integrando três serviços principais: Amazon Rekognition para detecção de rostos e objetos, Amazon Neptune para mapeamento de relacionamentos, e Amazon Bedrock para legendagem orientada por IA.

A solução demonstra que integrando as capacidades de banco de dados em grafo do Amazon Neptune com os serviços de IA da AWS, é possível criar uma busca fotográfica em linguagem natural que compreende contexto e relacionamentos. Em vez de simples metadados, a arquitetura oferece descoberta fotográfica verdadeiramente inteligente.

Componentes Principais da Solução

A arquitetura serverless articula diversos serviços AWS para criar um sistema contextualmente consciente:

• Amazon API Gateway — para endpoints REST e integração com interface web
• Amazon Bedrock com Claude 3.5 Sonnet da Anthropic — para legendagem contextual de imagens orientada por IA
• Amazon DynamoDB — para armazenamento rápido e recuperação de metadados
• AWS Lambda — para orquestração serverless de computação entre componentes
• Amazon Neptune — para armazenar relacionamentos complexos como banco de dados em grafo
• Amazon Rekognition — para detecção facial, reconhecimento e etiquetagem de objetos
• Amazon Simple Storage Service (Amazon S3) — para armazenamento escalável de fotos e disparo de fluxos de processamento

Fluxo de Processamento

O sistema segue um fluxo de trabalho racionalizado: imagens são enviadas para buckets S3 com acionadores Lambda automáticos. Fotos de referência na pasta faces/ são processadas para construir modelos de reconhecimento. Novas fotos acionam Amazon Rekognition para detecção facial e etiquetagem de objetos. O Neptune armazena conexões entre pessoas, objetos e contextos. O Amazon Bedrock gera descrições contextuais usando rostos detectados e relacionamentos. O DynamoDB armazena metadados pesquisáveis com recuperação rápida. Consultas em linguagem natural atravessam o grafo Neptune para resultados inteligentes.

Casos de Uso e Escalabilidade

A arquitetura serverless escala eficientemente para múltiplos casos de uso: em contextos corporativos para reconhecimento de funcionários e documentação de eventos; no setor de saúde para gestão de fotos compatível com HIPAA com rastreamento de relacionamentos; na educação para organização de fotos de estudantes e corpo docente entre departamentos; em eventos para fotografia profissional com etiquetagem automática e entrega ao cliente.

A solução beneficia-se diretamente da natureza serverless: você paga apenas pelo que usa, tornando-a economicamente viável tanto para pequenos acervos familiares quanto para arquivos corporativos massivos. O processamento de 1.000 imagens tipicamente custa aproximadamente $15–25 (incluindo detecção facial do Amazon Rekognition, geração de legendas com Amazon Bedrock e execução de funções Lambda), com custos de cluster Neptune na faixa de $100–150 mensais independentemente do volume. Custos de armazenamento permanecem mínimos, inferior a $1 por 1.000 imagens no Amazon S3.

Capacidades Principais

Reconhecimento Facial e Etiquetagem Automática

Com o Amazon Rekognition, é possível identificar automaticamente indivíduos a partir de fotos de referência, sem necessidade de etiquetagem manual. Enviando algumas imagens claras por pessoa, o sistema as reconhece em toda a coleção, independentemente de iluminação ou ângulos. Essa automação reduz o tempo de etiquetagem de semanas para horas, suportando diretórios corporativos, arquivos de conformidade e fluxos de gestão de eventos.

Busca Consciente de Relacionamentos

Utilizando Neptune, a solução compreende quem aparece nas fotos e como estão conectados. Consultas em linguagem natural como “gerente da Sarah” ou “Mãe com seus filhos” permitem que o sistema atravesse relacionamentos de múltiplos saltos para retornar imagens relevantes. Essa busca semântica substitui a organização manual por pastas com descoberta intuitiva e contextualmente consciente.

Compreensão Automática de Objetos e Contexto

O Amazon Rekognition detecta objetos, cenas e atividades, e o Neptune os conecta a pessoas e relacionamentos. Isso viabiliza consultas complexas como “executivos com veículos corporativos” ou “professores em salas de aula”. A hierarquia de etiquetas é gerada dinamicamente e se adapta a domínios diferentes — como saúde ou educação — sem configuração manual.

Legendagem Contextual com Amazon Bedrock

Usando Amazon Bedrock, o sistema cria legendas significativas, conscientes de relacionamentos, como “Sarah e seu gerente discutindo resultados trimestrais” em vez de legendas genéricas. Legendas podem ser ajustadas quanto ao tom (objetivo para conformidade, narrativo para marketing, conciso para resumos executivos), aprimorando tanto a capacidade de busca quanto a comunicação.

Experiência Web Intuitiva

A interface web permite que usuários busquem fotos usando linguagem natural, visualizem legendas geradas por IA e ajustem o tom dinamicamente. Consultas como “mãe com crianças” ou “atividades ao ar livre” retornam resultados relevantes e legendados instantaneamente. Essa experiência unificada suporta tanto fluxos de trabalho corporativos quanto coleções pessoais.

Gerenciamento de Relacionamentos e Hierarquias

Escalando Relacionamentos em Grafos com Hierarquias de Etiquetas

O Neptune escala para modelar milhares de relacionamentos e hierarquias de etiquetas em organizações ou conjuntos de dados. Relacionamentos são gerados automaticamente durante o processamento de imagens, viabilizando descoberta semântica rápida enquanto mantém performance e flexibilidade conforme os dados crescem.

Abordagem Orientada por Configuração

O grafo de relacionamentos utiliza uma abordagem flexível orientada por configuração através da função initialize_relationship_data(). Esse modelo mitiga a necessidade de codificação fixa e suporta casos de uso ilimitados — você simplesmente define suas pessoas e relacionamentos em um objeto de configuração.

Um exemplo de estrutura genérica de configuração:

config = {
    "people": [
        {"name": "alice", "gender": "woman", "role": "mother"},
        {"name": "jane", "gender": "girl", "role": "daughter"}
    ],
    "relationships": [
        {"from": "alice", "to": "jane", "type": "parent_of", "subtype": "mother_of"},
        {"from": "jane", "to": "david", "type": "sibling_of", "bidirectional": True}
    ]
}

# Generic relationship creation
for rel in relationships_data:
    g.V().has('name', rel["from"]).addE(rel["type"]).to(
        __.V().has('name', rel["to"])
    ).property('type', rel["subtype"]).next()

# Business example - just change the configuration
business_config = {
    "people": [{"name": "sarah", "role": "manager"}],
    "relationships": [{"from": "sarah", "to": "john", "type": "manages", "subtype": "manager_of"}]
}

Criação Automática de Hierarquias de Etiquetas

O banco de dados de relacionamentos de etiquetas é criado automaticamente durante o processamento de imagens através da função store_labels_in_neptune():

# Rekognition provides labels with categories
response = rekognition.detect_labels(
    Image={'Bytes': image_bytes},
    MaxLabels=20,
    MinConfidence=70
)

# Extract labels and categories
for label in response.get('Labels', []):
    label_data = {
        'name': label['Name'],  # e.g., "Car"
        'categories': [cat['Name'] for cat in label.get('Categories', [])]  # e.g., ["Vehicle", "Transportation"]
    }

# Automatic hierarchy creation in Neptune
for category in categories:
    # Create belongs_to relationship (Car -> Vehicle -> Transportation)
    g.V().has('name', label_name).addE('belongs_to').to(
        __.V().has('name', category_name)
    ).property('type', 'hierarchy').next()
    
    # Create appears_with relationship (Person -> Car)
    g.V().has('name', person_name).addE('appears_with').to(
        __.V().has('name', label_name)
    ).property('confidence', confidence).next()

Com essas funções, é possível gerenciar coleções fotográficas grandes com consultas de relacionamento complexas, descobrir fotos por contexto semântico e localizar coleções temáticas através de padrões de co-ocorrência de etiquetas.

Implantação e Pré-requisitos

Requisitos Técnicos

Antes de implementar essa solução, certifique-se de ter:

• Uma conta AWS com permissões apropriadas para Amazon S3, Lambda, Amazon Rekognition, Neptune, Amazon Bedrock e DynamoDB
• AWS Command Line Interface (AWS CLI) v2.15.0 ou posterior configurada com acesso programático
• AWS CDK v2.92.0 ou posterior instalado (npm install -g aws-cdk)
• Python 3.11 ou posterior com gerenciador pip
• Node.js 18.x ou posterior para operações AWS CDK
• Conhecimento básico de arquiteturas serverless e bancos de dados em grafo
• Acesso ao Claude 3.5 Sonnet da Anthropic no Amazon Bedrock em sua região AWS

Estrutura do Projeto

O código-fonte completo está disponível em repositório GitHub, com instruções detalhadas de setup e implantação no README. O projeto está organizado em diretórios-chave que separam responsabilidades e viabilizam desenvolvimento modular:

smart-photo-caption-and-search/
├── lambda/
│   ├── face_indexer.py # Indexes reference faces in Rekognition
│   ├── faces_handler.py # Lists indexed faces via API
│   ├── image_processor.py # Main processing pipeline
│   ├── search_handler.py # Handles search queries
│   ├── style_caption.py # Generates styled captions
│   ├── relationships_handler_neptune.py # Manages Neptune relationships
│   ├── label_relationships.py # Queries label hierarchies
│   └── neptune_search.py # Neptune relationship parsing
├── lambda_layer/ # Pillow image processing layer
├── neptune_layer/ # Gremlin Python Neptune layer
├── ui/
│   └── demo.html # Web interface with Cognito authentication
├── app.py # CDK application entry point
├── image_name_cap_stack_neptune.py # Neptune-enabled CDK stack
└── requirements_neptune.txt # Python dependencies

Funções Lambda Principais

A solução utiliza as seguintes funções Lambda-chave:

• image_processor.py — Processamento central com reconhecimento facial, detecção de etiquetas e geração de legendas enriquecidas por relacionamentos
• search_handler.py — Processamento de consultas em linguagem natural com travessia de relacionamentos de múltiplos saltos
• relationships_handler_neptune.py — Gerenciamento de relacionamentos orientado por configuração e conexões em grafo
• label_relationships.py — Consultas hierárquicas de etiquetas, associações objeto-pessoa e descoberta semântica

Passos de Implantação

Para implantar a solução, execute os seguintes passos:

1. Instale as dependências com: pip install -r requirements_neptune.txt
2. Para configuração de primeira vez, execute o bootstrap do AWS CDK: cdk bootstrap
3. Provisione recursos AWS com: cdk deploy
4. Configure credenciais do pool de usuários Amazon Cognito na interface web
5. Carregue fotos de referência para estabelecer a linha de base de reconhecimento
6. Crie relacionamentos familiares de amostra utilizando a API ou interface web

O sistema gerencia automaticamente reconhecimento facial, detecção de etiquetas, resolução de relacionamentos e geração de legendas orientada por IA através do pipeline serverless, viabilizando consultas em linguagem natural como “mãe da pessoa com carro” alimentadas por travessias em grafo Neptune.

Segurança e Privacidade

A solução implementa medidas abrangentes de segurança para proteger dados sensíveis de imagem e reconhecimento facial. O sistema criptografa dados em repouso utilizando criptografia AES-256 com chaves gerenciadas pelo AWS Key Management Service (AWS KMS) e assegura dados em trânsito com TLS 1.2 ou posterior. Funções Neptune e Lambda operam dentro de sub-redes de nuvem privada virtual (VPC), isoladas do acesso direto à internet, e o API Gateway fornece o único endpoint público com políticas CORS e limite de taxa.

O controle de acesso segue princípios de menor privilégio com políticas do AWS Identity and Access Management (IAM) que concedem apenas permissões mínimas necessárias: funções Lambda podem acessar apenas buckets S3 e tabelas DynamoDB específicas, e o acesso Neptune é restrito a operações autorizadas de banco de dados. Dados de imagem e reconhecimento facial permanecem dentro de sua conta AWS e nunca são compartilhados fora dos serviços AWS.

Você pode configurar políticas de ciclo de vida do Amazon S3 para gerenciamento automático de retenção de dados, e o AWS CloudTrail fornece logs de auditoria completos de acesso a dados e chamadas de API para monitoramento de conformidade, suportando requisitos GDPR e HIPAA com monitoramento adicional do Amazon GuardDuty para detecção de ameaças.

Limpeza de Recursos

Para evitar incorrer em cobranças futuras, execute os seguintes passos para deletar recursos que você criou:

• Delete imagens do bucket S3: aws s3 rm s3://YOUR_BUCKET_NAME –recursive
• Delete o cluster Neptune (esse comando também deleta automaticamente as funções Lambda): cdk destroy
• Remova a coleção de rostos do Amazon Rekognition: aws rekognition delete-collection --collection-id face-collection

Perspectiva para Profissionais de Nuvem Brasileiros

Essa arquitetura representa uma abordagem moderna para um problema clássico de gestão de dados visuais. Para times brasileiras de engenharia, o projeto oferece várias lições técnicas: a integração entre serviços especializados (visão, grafos, IA) demonstra como orquestrar capacidades distintas em uma solução coesa; a arquitetura serverless elimina gerenciamento de infraestrutura, permitindo que equipes se concentrem em lógica de negócio; a abordagem orientada por configuração do Neptune facilita adaptação a diferentes domínios sem alterações de código.

A relevância para o contexto brasileiro inclui casos de uso em áreas como documentação de eventos, gestão de acervos fotográficos institucionais, compliance corporativo com rastreabilidade, e até aplicações de segurança com reconhecimento facial contextualizado. O modelo de precificação serverless torna a solução economicamente acessível para startups e empresas de médio porte que historicamente enfrentavam barreiras de investimento em infraestrutura de ML e grafos.

Referência de Recursos

Para aprofundamento técnico, consulte:

• Documentação do AWS CDK
• Guia do Desenvolvedor Amazon Rekognition
• Guia do Usuário Amazon Neptune
• Guia do Usuário Amazon Bedrock

Conclusão

A demonstração da AWS ilustra como Amazon Rekognition, Amazon Neptune e Amazon Bedrock trabalham em conjunto para viabilizar busca fotográfica inteligente que compreende conteúdo visual e contexto. Construída sobre uma arquitetura totalmente serverless, a solução combina visão computacional, modelagem em grafo e compreensão em linguagem natural para entregar experiências de descoberta escaláveis e humanizadas.

Ao transformar coleções fotográficas em um grafo de conhecimento de pessoas, objetos e momentos, a arquitetura redefine como usuários interagem com dados visuais — tornando a busca mais semântica, relacional e significativa. Essa abordagem reflete a confiabilidade e robustez de tecnologias de IA e grafos da AWS na viabilização de compreensão fotográfica segura e contextualmente consciente.

Fonte

Build an intelligent photo search using Amazon Rekognition, Amazon Neptune, and Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-an-intelligent-photo-search-using-amazon-rekognition-amazon-neptune-and-amazon-bedrock/)

Novidade no Amazon Q Developer: visualização inteligente de recursos e custos

A AWS anunciou em fevereiro de 2026 a disponibilidade geral dos artefatos do Amazon Q Developer no Console de Gerenciamento da AWS. Essa funcionalidade representa um passo importante na forma como os clientes interagem com seus ambientes em nuvem, oferecendo uma experiência baseada em inteligência artificial generativa para visualizar dados de forma organizada e intuitiva.

Os artefatos do Amazon Q permitem que os usuários visualizem dados de recursos em formato tabular e informações de custos em gráficos, tudo através de uma interface conversacional. O lançamento também trouxe melhorias na acessibilidade do serviço, com o ícone do Amazon Q agora posicionado na barra de navegação e o painel de chat movido para o lado esquerdo do console, facilitando o acesso a partir de qualquer ponto do Console de Gerenciamento da AWS.

Como usar os artefatos do Amazon Q

Consultando recursos com exemplos práticos

Os clientes podem acessar os artefatos selecionando o ícone do Amazon Q e fazendo perguntas sobre seus recursos da AWS. Por exemplo, ao questionar “List S3 buckets with tag value production”, o Amazon Q exibe os buckets do S3 que possuem a tag de produção em formato tabular. A partir daí, é possível clicar nos nomes dos buckets para visualizar detalhes completos diretamente no console do S3.

Analisando custos com visualizações gráficas

Além de recursos, os usuários podem visualizar informações de custos e faturamento através de gráficos. Quando o usuário digita uma consulta como “Show me RDS costs by instance type over the last 6 months”, o Amazon Q renderiza a resposta utilizando gráficos adequados — como gráficos de barras, linhas, pizzas ou áreas — permitindo uma análise rápida e visual dos gastos com banco de dados.

Recursos de acessibilidade e produtividade

O Amazon Q Developer oferece uma biblioteca de prompts de exemplo no painel de chat, permitindo que novos usuários comecem rapidamente sem necessidade de memorizar comandos específicos. Os artefatos são exibidos em um painel dedicado à direita do painel de chat do Amazon Q, mantendo a conversa visível e facilitando o acompanhamento das consultas.

Para usuários que desejam uma experiência focada, há a opção de expandir o Amazon Q para tela cheia, oferecendo um modo dedicado sem distrações.

Disponibilidade e próximos passos

Os artefatos do Amazon Q Developer estão disponíveis em todas as regiões da AWS onde o Amazon Q Developer está presente. Para começar a usar a funcionalidade, é recomendável consultar a documentação do Amazon Q Developer, que contém guias detalhados e exemplos adicionais de uso.

Fonte

Amazon announces generative AI-based artifacts in Amazon Q Developer for visualizing resource and cost data (https://aws.amazon.com/about-aws/whats-new/2026/02/generative-ai-based-Amazon-Q-artifacts/)