Author: Make.com Service User

Transformando Áudio em Conhecimento Buscável

Se você trabalha com gerenciamento de conteúdo em áudio — podcasts, gravações de atendimento, arquivos musicais ou material de treinamento — enfrenta um desafio técnico real: como encontrar informações específicas em bibliotecas grandes? Os métodos tradicionais como transcrição manual, etiquetagem de metadados e conversão de fala em texto funcionam bem para capturar palavras faladas, mas deixam de lado propriedades acústicas importantes como tom, emoção, características musicais e sons ambientes.

Os embeddings de áudio resolvem exatamente este problema. Em vez de representar áudio como ondas brutas ou apenas como texto, eles o transformam em vetores numéricos densos que capturam tanto propriedades semânticas quanto acústicas. Isso permite buscas semânticas usando linguagem natural, correspondência de áudio com som similar e categorização automática com base no que o áudio parece ser, não apenas em tags de metadados.

A AWS anunciou no dia 28 de outubro de 2025 o Amazon Nova Multimodal Embeddings, um modelo de embeddings multimodal disponível no Amazon Bedrock. Trata-se de um modelo único que suporta texto, documentos, imagens, vídeo e áudio através de um só modelo para recuperação cross-modal com precisão. Este artigo explora como implementar essa solução e construir um sistema prático de busca para sua biblioteca de conteúdo em áudio.

Compreendendo Embeddings de Áudio: Conceitos Fundamentais

Representações Vetoriais do Conteúdo Sonoro

Pense em embeddings de áudio como um sistema de coordenadas para o som. Assim como coordenadas GPS localizam pontos na Terra, embeddings mapeiam conteúdo de áudio para pontos específicos em um espaço de alta dimensionalidade. O Amazon Nova oferece quatro opções: 3.072 (padrão), 1.024, 384 ou 256 dimensões, sendo cada embedding um array de ponto flutuante 32 bits.

Cada dimensão codifica características acústicas e semânticas — ritmo, frequência, timbre, tom emocional e significado semântico — tudo aprendido através da arquitetura de rede neural do modelo durante o treinamento. A AWS usa Aprendizado de Representação Matrioshka (Matryoshka Representation Learning – MRL), uma técnica que estrutura embeddings hierarquicamente, como bonecas russas aninhadas. Um embedding de 3.072 dimensões contém todas as informações, mas você pode extrair apenas as primeiras 256 dimensões e ainda obter resultados precisos. Gera-se embeddings uma única vez, depois escolhe-se o tamanho que equilibra precisão com custos de armazenamento.

Medindo Similaridade Entre Áudios

Quando você quer encontrar áudio similar, calcula a similaridade do cosseno entre dois embeddings. A métrica produz valores de -1 a 1, onde valores mais próximos de 1 indicam similaridade semântica mais forte. Quando você armazena embeddings em um banco de dados vetorial, o serviço usa métricas de distância (distância = 1 – similaridade) para realizar buscas de k-vizinhos mais próximos (k-NN), recuperando os top-k embeddings mais similares para sua consulta.

Um exemplo real: imagine dois clipes de áudio — “um violino tocando uma melodia” e “um violoncelo tocando uma melodia similar” — que geram embeddings com similaridade do cosseno de 0,87. Eles se agrupam próximos no espaço vetorial, indicando relação acústica e semântica forte. Um terceiro clipe como “música rock com bateria” teria similaridade de 0,23 com o primeiro, ficando distante no espaço de embeddings.

Arquitetura de Processamento e Modalidades de Áudio

Fluxo de Trabalho Completo

O processamento de áudio segue dois fluxos principais: ingestão e indexação acontecem uma única vez, enquanto buscas em tempo de execução ocorrem continuamente.

Fase de ingestão e indexação: você processa sua biblioteca de áudio em lote. Carrega arquivos no Amazon S3, depois usa a API assíncrona para gerar embeddings. Para áudios longos (acima de 30 segundos), o modelo os segmenta automaticamente em pedaços menores com metadados temporais. Você armazena esses embeddings em um banco de dados vetorial junto com metadados como nome do arquivo, duração e gênero. Isso acontece uma única vez para toda a biblioteca.

Fase de busca em tempo de execução: quando um usuário busca, você gera um embedding para sua consulta — seja texto como “jazz piano animado” ou outro clipe de áudio — usando a API síncrona. Como consultas são curtas e usuários esperam resultados rápidos, a API síncrona fornece respostas de baixa latência. O banco de dados vetorial realiza busca de k-NN encontrando os embeddings de áudio mais similares, retornando resultados com metadados associados, tudo em milissegundos.

Processamento de Sinais Acústicos

Quando você submete apenas áudio, redes convolucionais temporais ou arquiteturas baseadas em transformers analisam seus sinais acústicos para padrões espectro-temporais. Em vez de trabalhar com ondas brutas, o Amazon Nova opera em representações de áudio como espectrogramas mel ou características aprendidas, permitindo processamento eficiente de áudio com alta taxa de amostragem.

Áudio é dado sequencial que exige contexto temporal. Seus segmentos de áudio (até 30 segundos) passam através de arquiteturas com campos receptivos temporais que capturam padrões acústicos ao longo do tempo. Essa abordagem captura ritmo, cadência, prosódia e dependências acústicas de longo alcance spanning múltiplos segundos — preservando toda a riqueza do conteúdo de áudio.

Operações de API e Estruturas de Requisição

Quando Usar Geração Síncrona de Embeddings

Use a API invoke_model para buscas em tempo de execução quando você precisa de embeddings para aplicações em tempo real onde latência é importante. Por exemplo, quando um usuário submete uma consulta de busca, o texto é curto e você quer fornecer uma experiência rápida — a API síncrona é ideal.

Aqui está um exemplo:

import boto3
import json

# Cria o cliente Bedrock Runtime
bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")

# Define o corpo da requisição para uma consulta de busca
request_body = {
    "taskType": "SINGLE_EMBEDDING",
    "singleEmbeddingParams": {
        "embeddingPurpose": "GENERIC_RETRIEVAL",
        "embeddingDimension": 1024,
        "text": {
            "truncationMode": "END",
            "value": "jazz piano music"
        }
    }
}

# Invoca o modelo Nova Embeddings
response = bedrock_runtime.invoke_model(
    body=json.dumps(request_body),
    modelId="amazon.nova-2-multimodal-embeddings-v1:0",
    contentType="application/json"
)

# Extrai o embedding da resposta
response_body = json.loads(response["body"].read())
embedding = response_body["embeddings"][0]["embedding"]

Compreendendo Parâmetros de Requisição

taskType: escolha SINGLE_EMBEDDING para itens individuais ou SEGMENTED_EMBEDDING para processamento em chunks. embeddingPurpose: otimiza embeddings para seu caso de uso — GENERIC_INDEX para indexar seu conteúdo, GENERIC_RETRIEVAL para consultas, DOCUMENT_RETRIEVAL para busca em documentos. embeddingDimension: sua escolha de dimensão de saída (3.072, 1.024, 384, 256). truncationMode: como lidar com entradas que excedem o comprimento de contexto — END trunca no final, START no início.

A API retorna um objeto JSON contendo seu embedding como um array de ponto flutuante 32 bits com informações sobre seu tamanho.

Quando Usar Processamento Assíncrono

O Amazon Nova suporta duas abordagens para processar grandes volumes de conteúdo: a API assíncrona e a API de lote. Entender quando usar cada uma ajuda a otimizar seu fluxo de trabalho.

API Assíncrona: use quando precisar processar arquivos de áudio ou vídeo grandes individuais que excedem os limites da API síncrona. Ideal para arquivos únicos e grandes (gravações de múltiplas horas, vídeos de comprimento total), arquivos que requerem segmentação (acima de 30 segundos) e quando você precisa de resultados dentro de horas, mas não imediatamente.

API de Lote: use quando precisar processar milhares de arquivos de áudio em um único trabalho. Oferece melhor eficiência de custo para operações em larga escala e trata o gerenciamento de trabalhos automaticamente. Você submete um arquivo de manifesto com todos seus arquivos de entrada, e o serviço os processa em paralelo, escrevendo resultados para S3.

Escolhendo entre assíncrono e lote: arquivo grande único ou necessidades de segmentação em tempo real? Use API assíncrona. Milhares de arquivos para processar em lote? Use API de lote. Precisa de resultados dentro de horas? Use API assíncrona. Pode esperar 24-48 horas por economia de custos? Use API de lote. Saiba mais consultando a documentação de inferência em lote do Amazon Bedrock.

Segmentação e Metadados Temporais

Por Que Segmentação é Importante

Se seus arquivos de áudio excedem 30 segundos, você precisa segmentá-los. Imagine que você tenha um podcast de 2 horas e queira encontrar o segmento específico de 30 segundos onde o apresentador discute inteligência artificial — segmentação torna isso possível. Você controla o chunking com o parâmetro segmentationConfig:

"segmentationConfig": {
    "durationSeconds": 15
}

Essa configuração processa um arquivo de áudio de 5 minutos (300 segundos) em 20 segmentos (300 ÷ 15 = 20), gerando 20 embeddings. Cada segmento recebe metadados temporais marcando sua posição no arquivo original.

Entendendo Saída Segmentada

A API assíncrona escreve seus embeddings segmentados para JSON Lines (JSONL) com metadados temporais. Cada linha contém o tempo de início, tempo de fim e o embedding correspondente. Você pode processar essa saída lendo o arquivo JSONL do S3 e extraindo informações de cada segmento, incluindo seu intervalo temporal e vetor de embedding.

Esse é um caso de uso real valioso: você armazena embeddings segmentados com seus metadados temporais em um banco de dados vetorial. Quando alguém busca por “reclamação de cliente sobre cobrança”, você recupera os segmentos específicos de 15 segundos com timestamps, dando navegação precisa para momentos relevantes dentro de gravações de chamadas de múltiplas horas. Não há necessidade de ouvir a gravação inteira.

Armazenamento Vetorial e Estratégias de Indexação

Compreendendo Seus Requisitos de Armazenamento

Embeddings são arrays de ponto flutuante 32 bits, requerendo 4 bytes por dimensão. Para 1 milhão de clipes de áudio com embeddings de 1.024 dimensões, você precisa de 4 GB de armazenamento vetorial (excluindo estruturas de metadados e índices).

Ao escolher tamanho de dimensão, considere que dimensões maiores fornecem representações mais detalhadas mas requerem mais armazenamento e computação. Dimensões menores oferecem equilíbrio prático entre desempenho de recuperação e eficiência de recursos. Comece com 1.024 dimensões — fornece excelente precisão para a maioria das aplicações mantendo custos gerenciáveis.

Usando Amazon S3 Vectors

Você pode armazenar e consultar seus embeddings usando Amazon S3 Vectors. Crie um índice vetorial, armazene embeddings com metadados, e realize buscas de k-NN para recuperar os resultados mais similares.

Metadados trabalham ao lado de embeddings para fornecer resultados de busca mais ricos. Quando você recupera resultados do banco de dados vetorial, metadados ajudam a filtrar, ordenar e exibir informações para usuários. Por exemplo, um campo de gênero deixa você filtrar apenas gravações de jazz, duração ajuda a encontrar faixas dentro de um intervalo específico de comprimento, e nome do arquivo fornece o caminho para o arquivo de áudio para reprodução.

Usando Amazon OpenSearch Service

OpenSearch fornece busca k-NN nativa com índices HNSW (Hierarchical Navigable Small World) para complexidade de tempo de consulta sub-linear. Isso significa que suas buscas permanecem rápidas mesmo conforme sua biblioteca de áudio cresce para milhões de arquivos. Você configura o índice especificando as propriedades de mapeamento, incluindo o tipo de vetor k-NN, dimensionalidade, espaço de similaridade (cosseno) e parâmetros do mecanismo de indexação.

Otimização em Lote e Padrões de Produção

Por Que Processamento em Lote é Importante

Quando você processa múltiplos arquivos de áudio, inferência em lote melhora throughput reduzindo overhead de latência de rede. Em vez de fazer chamadas de API separadas para cada arquivo, você pode processá-los mais eficientemente.

Suporte Multilíngue

O modelo suporta entradas de texto em 200+ idiomas. Isso habilita cenários poderosos de busca cross-modal: seus clientes podem buscar em espanhol por conteúdo de áudio indexado em inglês, ou vice-versa. Os embeddings capturam significado semântico através de idiomas.

Amazon Nova: Especificações Técnicas Profundas

Arquitetura e Capacidades do Modelo

O Amazon Nova Multimodal Embeddings é construído em um modelo de fundação treinado para entender relacionamentos entre diferentes modalidades — texto, imagens, documentos, vídeo e áudio — dentro de um espaço de embedding unificado. Oferece flexibilidade com quatro opções de dimensão de saída (3.072, 1.024, 384, 256) e capacidades de processamento de mídia para segmentos de até 30 segundos com segmentação automática para arquivos mais longos.

A API oferece flexibilidade com APIs síncronas e assíncronas — use síncronas para consultas onde latência importa e assíncronas para ingestão de dados e indexação onde você pode tolerar tempos de processamento mais longos. Você pode passar conteúdo especificando uma URI S3 ou inline como codificação base64.

Fluxo de Trabalho Completo

Você usa o Amazon Nova para gerar embeddings para seus clipes de vídeo ou áudio. Armazena os embeddings em um banco de dados vetorial. Quando seu usuário final busca conteúdo, você usa Nova para gerar um embedding para sua consulta de busca. Sua aplicação compara como similar é o embedding da consulta com seus embeddings de conteúdo indexado. Sua aplicação recupera o conteúdo que melhor corresponde à consulta de busca. Você mostra o conteúdo correspondente a seu usuário.

Entradas Suportadas

Entradas para gerar embeddings podem ser em formato de texto, imagem, imagem de documento, vídeo ou áudio. As entradas referem-se tanto aos itens que você usa para criar o índice quanto às consultas de busca de usuário final. O modelo produz embeddings que você usa para recuperar ativos que melhor correspondem à consulta para exibir a seu usuário. Atualmente, o Amazon Nova suporta mp3, wav e ogg como formatos de entrada de áudio.

Capacidades Principais

Busca áudio-para-áudio: encontre conteúdo acusticamente similar em sua biblioteca. Por exemplo, encontre todas as gravações com características musicais ou estilos de fala similares.

Busca texto-para-áudio: use consultas em linguagem natural para recuperar segmentos de áudio relevantes. Busque por “piano de jazz animado” ou “cliente expressando frustração” e obtenha clipes de áudio correspondentes.

Recuperação cross-modal: busque simultaneamente em imagens, áudio, vídeo e texto. Essa abordagem unificada significa que você pode usar uma consulta para buscar em toda sua biblioteca de conteúdo independente do formato.

Compreensão temporal: o modelo reconhece ações e eventos dentro de áudio ao longo do tempo. Isso permite buscar por momentos específicos dentro de gravações longas.

Quando Escolher Amazon Nova

O Amazon Nova Multimodal Embeddings é projetado para aplicações de produção requerendo desempenho escalável, deploy rápido e overhead operacional mínimo. A solução oferece velocidade para colocar em mercado (deploy em horas ou dias, não meses), gerenciamento simplificado como serviço (sem infraestrutura para manter ou modelos para treinar), capacidades cross-modais (um modelo para todos seus tipos de conteúdo com suporte a deployment de nível empresarial) e melhorias contínuas (beneficie-se de atualizações de modelo sem trabalho de migração).

Domínios de Aplicação Principal

O Amazon Nova Multimodal Embeddings atende a uma ampla gama de aplicações otimizadas para Geração Aumentada por Recuperação multimodal (RAG), busca semântica e agrupamento.

Geração Aumentada por Recuperação (RAG) com Agentes: você pode usar Amazon Nova Multimodal Embeddings para aplicações baseadas em RAG onde o modelo serve como embedding para a tarefa de recuperação. Sua entrada pode ser texto de documentos, imagens ou imagens de documentos que intercalam texto com infográficos, vídeo e áudio. O embedding deixa você recuperar informações mais relevantes de sua base de conhecimento que você pode fornecer a um sistema de modelo de linguagem para respostas aprimoradas.

Busca Semântica: você pode gerar embeddings a partir de texto, imagens, imagens de documentos, vídeo e áudio para alimentar aplicações de busca armazenadas em um índice vetorial. Como o modelo captura as nuances da consulta do seu usuário dentro do embedding, suporta consultas de busca avançadas que não dependem de correspondência de palavras-chave. Seus usuários podem buscar por conceitos, não apenas palavras exatas.

Agrupamento: você pode usar Amazon Nova Multimodal Embeddings para gerar embeddings a partir de texto, imagens, imagens de documentos, vídeo e áudio. Algoritmos de agrupamento podem agrupar itens que estão próximos uns aos outros com base em distância ou similaridade. Por exemplo, se você trabalha em gerenciamento de mídia e quer categorizar seus ativos de mídia entre temas similares, você pode usar os embeddings para agrupar ativos similares sem precisar de metadados para cada ativo. O modelo compreende similaridade de conteúdo automaticamente.

Conclusão

O Amazon Nova Multimodal Embeddings representa um avanço significativo no entendimento semântico de áudio, indo além das abordagens tradicionais baseadas apenas em texto. Ao representar áudio como vetores de alta dimensionalidade que capturam tanto propriedades acústicas quanto semânticas, é possível construir sistemas de busca que entendem tom, emoção e contexto — não apenas palavras faladas.

O fluxo de trabalho completo inclui: geração de embeddings usando APIs síncronas e assíncronas, segmentação de arquivos de áudio longos com metadados temporais, armazenamento de embeddings em um banco de dados vetorial e execução de busca de k-NN para recuperar segmentos de áudio relevantes. Essa abordagem transforma grandes bibliotecas de áudio em conjuntos de dados inteligentes e buscáveis que suportam casos de uso como análise de centrais de atendimento, busca de mídia e descoberta de conteúdo.

Fonte

Building intelligent audio search with Amazon Nova Embeddings: A deep dive into semantic audio understanding (https://aws.amazon.com/blogs/machine-learning/building-intelligent-audio-search-with-amazon-nova-embeddings-a-deep-dive-into-semantic-audio-understanding/)

Ajuste fino com reforço: uma abordagem diferente para customização de modelos

O Ajuste Fino com Reforço (RFT) oferecido no Amazon Bedrock representa uma alternativa promissora aos métodos tradicionais de customização de modelos de fundação. Diferentemente de abordagens convencionais que requerem grandes conjuntos de dados rotulados, o RFT permite refinar modelos como Amazon Nova e modelos de código aberto suportados definindo o que significa uma resposta de qualidade através de sinais de recompensa.

Essa metodologia tem mostrado ganhos de precisão de até 66% em comparação com modelos base, mantendo custos e complexidade reduzidos. O grande diferencial é que o modelo aprende não através de exemplos estáticos memorizados, mas através de um processo iterativo de tentativa, avaliação e ajuste de pesos — similar ao aprendizado por reforço.

Onde o ajuste com reforço se destaca

O RFT é particularmente valioso em cenários onde o comportamento desejado é fácil de verificar, mas difícil de demonstrar através de exemplos manualmente anotados. A AWS identifica dois contextos principais de aplicação:

Tarefas com critérios verificáveis automaticamente

Nesta categoria estão problemas como geração de código que deve passar em testes, raciocínio matemático com respostas verificáveis, extração de dados estruturados que deve respeitar esquemas rigorosos, e chamadas de APIs que precisam ser executadas corretamente. Como o sucesso é traduzível em sinais de recompensa diretos, o modelo descobre estratégias mais robustas do que um pequeno conjunto de exemplos anotados poderia ensinar. Esse padrão é conhecido como Aprendizado por Reforço com Recompensas Verificáveis (RLVR).

Tarefas subjetivas com avaliação por modelo

Categorias como moderação de conteúdo, assistentes conversacionais, criação criativa ou sumarização carecem de correção facilmente quantificável. Nesses casos, um modelo-juiz orientado por uma rubrica detalhada pode servir como função de recompensa, avaliando saídas contra critérios que seriam impraticáveis de codificar como pares de treinamento estáticos. Essa abordagem chama-se Aprendizado por Reforço com Feedback de IA (RLAIF).

No Amazon Bedrock, tanto abordagens baseadas em regras quanto baseadas em modelos podem ser implementadas através de uma função personalizada de AWS Lambda, que é acionada pelo Bedrock durante o loop de treinamento.

Exemplos práticos de aplicação incluem: geração de código para serviços em produção (com taxas de pass em testes unitários e verificações de linting), orquestração de ferramentas e APIs (medindo conclusão bem-sucedida de tarefas como fluxos de reserva), raciocínio matemático complexo (verificando respostas finais corretas ou etapas intermediárias), extração e transformação de dados estruturados (validação contra esquemas), síntese de queries SQL (comparando resultados esperados), e workflows de agentes (combinando RLVR e RLAIF).

Exemplo prático: melhorando raciocínio matemático com GSM8K

Para ilustrar como o ajuste com reforço funciona na prática, considere um exemplo concreto: melhorar a capacidade de um modelo resolver problemas de raciocínio matemático. O RFT é útil neste contexto porque soluções podem frequentemente ser verificadas objetivamente, permitindo desenhar sinais de recompensa claros que guiem o modelo para raciocínio correto e saídas estruturadas.

O dataset GSM8K (Grade School Math 8K) fornece problemas como: “Tina ganha $18,00 por hora. Se trabalha mais de 8 horas por turno, recebe hora extra (salário hora + 1/2 do salário). Se trabalha 10 horas todos os dias durante 5 dias, quanto ela ganha?”

Uma resposta ideal mostraria raciocínio claro estruturado: separar horas regulares de hora extra para cada dia, calcular a taxa de hora extra (1,5x), multiplicar pelos 5 dias, chegando à resposta $990. A resposta ideal não apenas forneceria o resultado final, mas demonstraria cada etapa do pensamento.

Métodos tradicionais de ajuste fino têm dificuldade com raciocínio matemático porque aprendem principalmente a fazer correspondência de padrões nos dados de treinamento. Modelos podem memorizar templates de solução, mas frequentemente falham quando apresentados com variações novas de um problema. Com RFT, respostas exatas como $990 podem ser avaliadas objetivamente, enquanto se atribui crédito parcial por etapas intermediárias de raciocínio correto. Isso permite ao modelo descobrir abordagens de solução válidas enquanto aprende a seguir formatos estruturados, frequentemente alcançando forte desempenho com datasets relativamente pequenos — entre 100 e 1.000 exemplos.

Preparando dados de treinamento eficazes

O RFT exige datasets cuidadosamente preparados. No Amazon Bedrock, dados de treinamento RFT são fornecidos em arquivo JSONL, com cada registro seguindo o formato de conclusão de chat OpenAI.

Diretrizes de tamanho de dataset

O RFT suporta datasets entre 100 e 10.000 amostras de treinamento, embora requisitos variem conforme complexidade da tarefa e design da função de recompensa. Tarefas envolvendo raciocínio complexo, domínios especializados ou escopos amplos de aplicação geralmente se beneficiam de datasets maiores e funções de recompensa sofisticadas.

Para experimentação inicial, comece com datasets pequenos (100-200 exemplos) para validar que seus prompts e função de recompensa produzem sinais de aprendizado significativos e que o modelo base consegue melhorias mensuráveis de recompensa. Implementações típicas usando 200 a 5.000 exemplos oferecem generalização mais forte e desempenho consistente através de variações de prompts. Para tarefas de raciocínio mais complexas, domínios especializados ou funções de recompensa sofisticadas, 5.000 a 10.000 exemplos aprimoram robustez através de entradas diversas.

Princípios de qualidade de dados

A qualidade dos dados de treinamento determina fundamentalmente os resultados do RFT. Ao preparar seu dataset, considere:

Distribuição de prompts: certifique-se de que o dataset reflete a gama completa de prompts que o modelo encontrará em produção. Um dataset enviesado leva a generalização pobre ou comportamento de treinamento instável.

Capacidade do modelo base: o RFT pressupõe que o modelo base demonstra compreensão básica da tarefa. Se o modelo não consegue alcançar recompensa não-nula em seus prompts, o sinal de aprendizado será fraco. Uma validação simples é gerar várias respostas do modelo base (temperatura ≈ 0,6) e confirmar que os outputs produzem sinais de recompensa significativos.

Design claro de prompts: prompts devem comunicar claramente expectativas e restrições. Instruções ambíguas levam a sinais de recompensa inconsistentes e aprendizado degradado. A estrutura do prompt também deve alinhar com o parsing da função de recompensa — por exemplo, exigindo respostas finais após um marcador específico ou fazendo uso de blocos de código para tarefas de programação.

Respostas de referência confiáveis: quando possível, inclua uma resposta de referência que represente o padrão desejado de saída, formatação e critérios de correção. Respostas de referência ancoram o cálculo de recompensa e reduzem ruído no sinal de aprendizado. Por exemplo, tarefas matemáticas podem incluir a resposta numérica correta, enquanto tarefas de codificação podem incluir testes unitários ou pares entrada-saída.

Sinais de recompensa consistentes: como o RFT depende inteiramente de sinais de recompensa para guiar o aprendizado, a qualidade desses sinais é crítica. Seu dataset e função de recompensa devem funcionar juntos produzindo pontuações consistentes e bem-diferenciadas. Respostas fortes devem pontuar consistentemente mais alto que respostas fracas em entradas similares.

Projetando funções de recompensa eficazes

Funções de recompensa são centrais ao RFT porque avaliam e pontuam respostas do modelo, atribuindo recompensas mais altas a saídas preferidas e recompensas menores a menos desejáveis. Esse feedback guia o modelo para comportamento melhorado durante o treinamento.

Recompensas para tarefas verificáveis

Para tarefas que podem ser verificadas deterministicamente, como raciocínio matemático ou codificação, a abordagem mais simples é verificar correção programaticamente. Funções de recompensa eficazes típicas avaliam tanto restrições de formato quanto objetivos de desempenho. Verificações de formato garantem que respostas possam ser confiável analisadas. Métricas de desempenho determinam se o resultado está correto. Recompensas podem ser implementadas usando sinais binários (correto versus incorreto) ou pontuação contínua conforme a tarefa.

Para tarefas de raciocínio matemático estilo GSM8K, funções de recompensa também devem considerar como modelos expressam respostas numéricas. Modelos podem formatar números com vírgulas, símbolos de moeda, percentuais ou embutir respostas em texto explicativo. Para abordar isso, respostas devem ser normalizadas removendo caracteres de formatação e aplicando extração flexível que prioriza formatos estruturados antes de cair de volta em correspondência de padrões. Essa abordagem garante que modelos sejam recompensados por raciocínio correto em vez de penalizados por escolhas estilísticas.

A implementação completa da função de recompensa para GSM8K está disponível no repositório amazon-bedrock-samples no GitHub.

Recompensas baseadas em feedback de IA

Tarefas como sumarização, criação criativa ou alinhamento semântico requerem um modelo de linguagem atuando como juiz para aproximar preferências subjetivas. Nesse cenário, o prompt do juiz efetivamente atua como a função de recompensa, definindo quais comportamentos são recompensados e como respostas são pontuadas. Um prompt de juiz prático deve claramente definir o objetivo de avaliação e incluir uma rubrica de pontuação concisa com escalas numéricas refletindo qualidades que o modelo deve melhorar. Prompts de juiz também devem retornar saídas estruturadas — por exemplo JSON ou formatos com tags — contendo a pontuação final e raciocínio opcional, para que valores de recompensa possam ser confiável extraídos durante o treinamento enquanto se mantém observabilidade em como cada resposta foi avaliada.

Um exemplo de função de recompensa que utiliza feedback de IA pode ser visto no script PandaLM de função de recompensa no GitHub.

Refinando design de funções de recompensa

Funções de recompensa frequentemente requerem iteração. Versões iniciais podem produzir sinais ruidosos ou durante o loop de treinamento o modelo pode aprender a explorar a função de recompensa para gerar alta pontuação sem aprender o comportamento desejado. Refinar a lógica de recompensa baseado em comportamento observado durante treinamento é essencial. Antes de lançar jobs de treinamento completos, é boa prática testar funções de recompensa independentemente usando prompts de amostra e saídas conhecidas para garantir que a lógica de pontuação produza sinais estáveis e significativos.

Monitorando progresso de treinamento

Após seu dataset e função de recompensa estarem prontos, você pode iniciar treinamento RFT usando a API Amazon Bedrock ou através do console. O workflow exato depende de seu ambiente de desenvolvimento preferido. A documentação Criar e gerenciar jobs de ajuste fino para modelos Amazon Nova no Guia do Usuário Amazon Bedrock fornece instruções passo-a-passo para ambas as abordagens.

Após o treinamento começar, monitorar métricas de treinamento é crítico. Esses sinais indicam se a função de recompensa é significativa e se o modelo está aprendendo comportamentos úteis em vez de fazer overfitting ou desabando em estratégias triviais.

Recompensas de treinamento registram a pontuação média de recompensa em cada passo. Variância é esperada porque prompts de entrada em um batch são amostrados aleatoriamente e dificuldade varia entre batches. O que importa é a tendência geral: recompensas devem aumentar de forma consistente, indicando que o modelo está convergindo para recompensas mais altas.

Recompensas de validação fornecem sinal mais claro porque são computadas em um dataset mantido separado. Uma melhora acentuada nos passos iniciais seguida de platô em torno de 0,88 sugere que o modelo está generalizando em vez de memorizando exemplos. Recompensas de validação que rastreiam proximamente recompensas de treinamento tipicamente indicam que overfitting não está ocorrendo.

Comprimento de episódio de treinamento mede o comprimento médio de resposta. Uma queda de aproximadamente 625 para ~400 tokens sugere que o modelo está aprendendo a alcançar respostas corretas mais eficientemente, produzindo menos raciocínio redundante conforme o treinamento progride. Em tarefas de raciocínio como cadeia-de-pensamento, um aumento gradual é saudável (aprendendo a pensar), mas um pico abrupto normalmente indica um loop ou falha.

Entropia de política mede o quanto o modelo está explorando diferentes estratégias de resposta. Valores entre 0,8 e 1,1 indicam exploração saudável. Se entropia desabasse para zero, sugeriria que o modelo tinha convergido prematuramente; entropia sustentada implica que o modelo ainda está explorando e melhorando.

Ajuste de hiperparâmetros: diretrizes práticas

As recomendações abaixo baseiam-se em experimentos internos executados através de múltiplos modelos e casos de uso. Enquanto valores eficazes variem conforme a tarefa, os padrões observados fornecem pontos de partida úteis ao configurar jobs RFT. Para mais informação sobre hiperparâmetros que podem ser configurados, consulte a documentação oficial boto3.

Contagem de épocas

Duração de treinamento e epochCount requerem ajuste baseado em tamanho de dataset e comportamento do modelo. Datasets menores frequentemente mostram melhoria contínua através de 6-12 épocas, enquanto datasets maiores podem alcançar desempenho ótimo em 3-6 épocas. Essa relação não é linear e monitoramento cuidadoso de métricas de validação permanece essencial para prevenir overfitting enquanto se garante adaptação suficiente do modelo.

Tamanho de batch

Este parâmetro controla quantos prompts são processados antes do modelo atualizado gerar uma nova rodada de respostas candidatas. Por exemplo, com batchSize de 128, o modelo processa, atualiza e gera novas saídas para 128 prompts por vez até ter trabalhado através do dataset completo. O número total de rodadas de saída iguala (dataset filtrado) dividido por batchSize.

Um batchSize de 128 funciona bem para a maioria de casos e modelos. Aumente se perda for errática ou recompensa não estiver melhorando. Diminua se iterações durarem muito.

Taxa de aprendizado

No Amazon Bedrock RFT, o ajuste é realizado usando Low Rank Adaptation (LoRA) com rank 32. Através de uma gama de casos de uso, uma taxa de aprendizado de 1e-4 produziu consistentemente resultados fortes.

Na prática, RFT baseado em LoRA tende a ser mais tolerante e desempenha bem através de uma gama mais ampla de taxas de aprendizado que ajuste completo, embora ambas abordagens possam desabar fora de seus intervalos ótimos. Recomenda-se monitorar curvas de recompensa proximamente e diminuir a taxa de aprendizado se começarem a oscilar ou desabar.

Comprimento de prompt e comprimento de resposta

O maxPromptLength define o comprimento máximo permitido para prompt de entrada no dataset. Prompts excedendo esse limite são filtrados durante treinamento. Se seu dataset contém prompts inusitadamente longos ou outros outliers, defina um valor apropriado que exclua outliers mantendo a maioria das amostras. Caso contrário, você pode defini-lo para o comprimento do prompt mais longo.

Por outro lado, inferenceMaxTokens define o comprimento máximo de resposta para qualquer saída gerada durante treinamento RL. Você pode usar esse argumento para controlar se o modelo resultante gera saídas detalhadas ou respostas concisas. Recomenda-se escolher um valor baseado em requisitos da tarefa. Um valor excessivamente grande pode aumentar tempo de treinamento enquanto um valor muito pequeno poderia degradar desempenho do modelo. Para tarefas que não requerem raciocínio complexo, definir comprimento máximo de resposta para 1.024 é tipicamente suficiente. Em contraste, para tarefas desafiadoras como codificação ou geração de forma longa, usar um limite superior maior (mais que 4.096) é preferível.

Parada antecipada e intervalo de avaliação

O serviço RFT fornece dois recursos que otimizam eficiência de treinamento e qualidade do modelo. EarlyStopping (habilitado por padrão) automaticamente para treinamento quando melhorias de desempenho platô, prevenindo overfitting e reduzindo custos computacionais desnecessários. O sistema continuamente monitora métricas de validação e termina treinamento após detectar que iterações futuras são improváveis de render melhorias significativas. Enquanto isso, evalInterval determina quantas vezes o modelo avalia desempenho no dataset de validação durante treinamento, automaticamente calculado como min(10, tamanho_dados/tamanho_batch), mantendo pelo menos uma avaliação por época enquanto se mantém frequência razoável.

Armadilhas comuns e como evitá-las

Exploração de recompensa: isso ocorre quando a política aprende a explorar fraquezas na função de recompensa para maximizar pontuações sem melhorar qualidade real. Você verá recompensas de treinamento subindo enquanto avaliações humanas degradam ou platô. Para mitigar, garanta que a função de recompensa captura todos aspectos do comportamento que você quer codificar através do ajuste. Se não, observe as gerações do modelo e itere na função de recompensa. Use penalidades rigorosas de comprimento se necessário.

Variância e instabilidade de recompensa: mesmo com boa recompensa média, flutuação alta em pontuações para entradas similares cria sinal ruidoso que desestabiliza treinamento. Isso se manifesta como curvas de recompensa agitadas e métricas de perda oscilando descontroladamente. A primeira linha de defesa é normalização rigorosa: padronize recompensas (média zero, variância unitária) dentro de cada batch, recorte outliers extremos, e garanta que sua inferência de recompensa é determinística (sem dropout), para que o otimizador receba sinal de aprendizado consistente e estável.

Próximos passos

Pronto para começar a customizar com RFT no Amazon Bedrock? Acesse o console Amazon Bedrock ou revise a documentação oficial de API e crie seu primeiro job de treinamento RFT.

Para começar:

• Explore a documentação visitando guias e tutoriais abrangentes: Criar um job de ajuste fino com reforço
• Experimente notebooks de exemplo acessando exemplos prontos para executar no repositório AWS Samples no GitHub
• Aplique as práticas de preparação de dados, design de recompensa e ajuste de hiperparâmetros cobertas neste artigo a seus próprios casos de uso

Fonte

Reinforcement fine-tuning on Amazon Bedrock: Best practices (https://aws.amazon.com/blogs/machine-learning/reinforcement-fine-tuning-on-amazon-bedrock-best-practices/)

Um novo assistente inteligente para desktops virtuais

A AWS apresentou o Amazon WorkSpaces Advisor, uma solução inovadora que coloca inteligência artificial a serviço da administração de infraestruturas de desktop virtual. Trata-se de uma ferramenta projetada especificamente para ajudar administradores a investigar, diagnosticar e resolver problemas no Amazon WorkSpaces Personal de forma muito mais rápida e eficiente do que os processos manuais tradicionais.

Como funciona o WorkSpaces Advisor

O diferencial do Amazon WorkSpaces Advisor reside na sua capacidade de processar informações usando inteligência artificial generativa. A ferramenta não apenas detecta os problemas — ela realiza uma análise profunda das configurações do WorkSpace, identifica a raiz das falhas e fornece recomendações acionáveis para que os administradores possam agir imediatamente.

Análise inteligente e recomendações práticas

Ao invés de exigir que o administrador investigue manualmente cada aspecto da infraestrutura, o WorkSpaces Advisor oferece insights orientados por IA. Esse tipo de abordagem reduz significativamente o tempo gasto em troubleshooting — aquele tempo valioso perdido investigando logs, configurações e dependências.

Benefícios para administradores e usuários finais

Manutenção proativa da infraestrutura

A disponibilidade de um assistente inteligente permite que os administradores adotem uma postura mais proativa. Em vez de apenas reagir a problemas quando eles ocorrem, é possível analisar continuamente a saúde dos WorkSpaces e aplicar otimizações antes que os problemas afetem os usuários finais.

Minimização de tempo de inatividade

Reduzir o tempo para identificar e resolver problemas significa minimizar o downtime — ou tempo em que a infraestrutura está indisponível. Para empresas que dependem de desktops virtuais para manter a produtividade, cada minuto de indisponibilidade representa uma perda potencial.

Experiência melhorada para o usuário final

Quando os problemas são resolvidos rapidamente e a infraestrutura é otimizada continuamente, o resultado direto é uma experiência mais consistente e estável para o usuário final. Isso se reflete em menos interrupções, melhor desempenho e maior confiabilidade na plataforma de desktop virtual.

Disponibilidade e acesso

O Amazon WorkSpaces Advisor está disponível em todas as regiões comerciais da AWS onde o Amazon WorkSpaces é oferecido. Os administradores podem acessar a ferramenta diretamente através do console do Amazon WorkSpaces e começar a utilizá-la para diagnosticar e otimizar seus ambientes imediatamente.

Para quem deseja conhecer mais detalhes sobre como usar o recurso, a AWS disponibiliza documentação oficial incluindo um artigo técnico sobre como resolver problemas mais rapidamente com o WorkSpaces Advisor e um guia completo de administração.

Fonte

Amazon WorkSpaces Advisor now available for AI-powered troubleshooting (https://aws.amazon.com/about-aws/whats-new/2026/04/workspaces-advisor-ai-troubleshooting/)

Uma evolução importante para automação em navegadores

A AWS expandiu as capacidades do Amazon Bedrock AgentCore Browser para incluir interações no nível do sistema operacional. Essa adição representa um passo significativo para desenvolvedores que trabalham com agentes de IA e engenheiros de teste automatizado, pois resolve limitações que existiam anteriormente ao usar exclusivamente o Protocolo de Ferramentas de Desenvolvedor do Chrome (CDP).

O protocolo CDP, embora poderoso, não consegue lidar com certos cenários de automação — como operações com caixas de diálogo do sistema, atalhos de teclado específicos ou interações com elementos fora da área visível do navegador. A AWS identificou essas lacunas e as preencheu com suporte direto ao sistema operacional.

Que capacidades foram adicionadas?

O novo recurso traz três categorias principais de funcionalidades:

• Operações de mouse: cliques, movimento, arraste e rolagem — todos coordenados pelas posições do sistema operacional
• Operações de teclado: digitação, pressão de teclas e atalhos como Ctrl+A e Ctrl+P
• Captura de tela completa: screenshots em resolução de desktop que vão além da viewport do navegador

Essas capacidades funcionam em coordenadas do nível do SO, ampliando a visibilidade e o controle muito além do que o navegador sozinho consegue oferecer.

Casos de uso práticos

A adição desses recursos abre caminho para automatizar cenários que eram difíceis ou impossíveis antes:

• Testes automatizados que precisam lidar com caixas de diálogo de sistema nativo
• Fluxos de trabalho de gerenciamento de documentos que envolvem impressão e diálogos de salvamento
• Interações complexas de interface que incluem menus de clique direito
• Agentes de IA baseados em visão que necessitam ter visibilidade completa do ambiente do navegador

Esses usos cases cobrem um espectro amplo: desde a automação de testes até a construção de ferramentas de interação web alimentadas por modelos de linguagem grande.

Disponibilidade global

O recurso está disponível por padrão em todas as instâncias de navegador do Amazon Bedrock AgentCore Browser em todos os 14 regiões da AWS onde o serviço está presente: US East (N. Virginia), US East (Ohio), US West (Oregon), Europa (Frankfurt), Europa (Irlanda), Europa (Londres), Europa (Paris), Europa (Estocolmo), Ásia Pacífico (Mumbai), Ásia Pacífico (Singapura), Ásia Pacífico (Sydney), Ásia Pacífico (Tóquio), Ásia Pacífico (Seul) e Canadá (Central).

Essa cobertura global garante que organizações em diferentes regiões possam aproveitar os novos recursos de automação sem restrições geográficas.

Próximos passos

Para aprender mais sobre como integrar essas capacidades em seus agentes e ferramentas de automação, consulte a documentação do AgentCore Browser.

Fonte

Amazon Bedrock AgentCore Browser adds OS-level interaction capabilities (https://aws.amazon.com/about-aws/whats-new/2026/04/agentcore-browser-os-actions/)

Entendendo a Personalização de Modelos com Fine-Tuning

Conforme as organizações expandem suas implementações de IA, surge uma necessidade crítica: contar com modelos que reflitam conhecimento proprietário e fluxos de trabalho específicos. Seja mantendo uma voz de marca consistente na comunicação com clientes, processando workflows complexos específicos de indústrias ou classificando intenções em sistemas de reserva com alto volume de transações, o desafio é o mesmo.

Técnicas tradicionais como engenharia de prompts e Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation) fornecem contexto adicional ao modelo, melhorando o desempenho em tarefas, mas não incorporam compreensão nativa ao modelo. A diferença é fundamental: essas abordagens “leem” as instruções a cada execução, em vez de internalizarem o conhecimento.

O Amazon Bedrock oferece três abordagens de personalização para modelos Nova:

• Supervisioned Fine-Tuning (SFT): treina o modelo em exemplos de entrada-saída rotulados
• Reinforcement Fine-Tuning (RFT): utiliza funções de recompensa para guiar o aprendizado em direção a comportamentos alvo
• Model Distillation: transfere conhecimento de um modelo professor maior para um modelo aluno menor e mais rápido

Diferentemente das técnicas de contexto, essas abordagens embutem novo conhecimento diretamente nos pesos do modelo. O resultado prático é triplo: inferência mais rápida, custos menores de tokens e maior precisão nas tarefas relevantes ao negócio.

Quando Aplicar Fine-Tuning e Quando Não Aplicar

Cenários Ideais para Fine-Tuning

Fine-tuning é recomendado quando você possui tarefas de alto volume bem definidas e consegue reunir exemplos rotulados de qualidade ou uma função de recompensa estruturada. Casos de uso típicos incluem renderizar corretamente o logo da empresa no modelo, incorporar tom de marca e políticas corporativas, ou substituir um classificador tradicional de machine learning por um pequeno LLM.

A indústria de atendimento ao cliente demonstra resultados práticos: ao personalizar modelos Nova Micro para suporte especializado, é possível melhorar a precisão em 5,4% em problemas específicos do domínio e 7,3% em questões gerais, reduzindo latência simultaneamente. Pequenos LLMs ajustados como o Nova Micro estão gradualmente substituindo classificadores tradicionais em tarefas de detecção de intenção, combinando a flexibilidade e conhecimento de mundo dos LLMs com a velocidade e eficiência de modelos leves.

Quando Evitar Fine-Tuning

Fine-tuning exige investimento inicial: montagem de dados rotulados, execução de job de treinamento, tempo e custos computacionais. Porém, esse investimento inicial costuma compensar em aplicações de alto volume ao reduzir custos de inferência por requisição e latência.

Capacidades dos Modelos Amazon Nova no Bedrock

O Amazon Bedrock automatiza completamente o provisionamento de infraestrutura, gerenciamento de compute e orquestração de treinamento. Você faz upload dos dados para o Amazon Simple Storage Service (Amazon S3) e inicia o treinamento com uma única chamada de API, sem gerenciar clusters, GPUs ou pipelines de treinamento distribuído.

Os modelos Amazon Nova suportam fine-tuning em diferentes variações. Vários deles possibilitam tanto SFT quanto RFT, conforme documentação específica. Para informações sobre disponibilidade e suporte, consulte a documentação atualizada e o Guia do Usuário Nova.

O Nova 2 Lite, por exemplo, é um modelo multimodal processando texto, imagens e vídeo em uma janela de contexto de 1 milhão de tokens. Oferece desempenho em processamento de documentos, compreensão de vídeo, geração de código e workflows de agentes.

O Nova Micro, o menor da família, destaca-se pela combinação de latência muito baixa com custo reduzido, sendo ideal para processamento em pipeline dentro de sistemas maiores — como correção de endereços ou extração de campos de dados de texto.

Caso de Uso Prático: Classificação de Intenções

Substituindo Modelos Tradicionais de Machine Learning

A detecção de intenção categoriza a intenção do usuário a partir da entrada fornecida. Em um sistema de assistência de viagens aéreas, por exemplo, o usuário pode estar solicitando informações sobre um voo previamente reservado ou perguntando sobre políticas da companhia. Esses sistemas precisam operar rápida e economicamente em alto volume.

Historicamente, a solução era treinar um modelo de machine learning tradicional. Hoje, desenvolvedores migram cada vez mais para pequenos LLMs. LLMs oferecem flexibilidade maior, compreendem gírias de texting, contexto e variações de linguagem natural — proporcionando melhor experiência ao usuário.

Para demonstração, o modelo Nova Micro foi personalizado sobre o dataset aberto Airline Travel Information System (ATIS), um benchmark padrão industrial para sistemas baseados em intenção. Sem personalização, Nova Micro alcança 41,4% de precisão. Com fine-tuning simples, essa precisão sobe para 97%.

Implementação Técnica do Fine-Tuning

Preparação de Dados

O Amazon Bedrock exige formato JSONL (JavaScript Object Notation Lines) para streaming eficiente de grandes datasets durante o treinamento, permitindo processamento incremental sem limitações de memória. Cada linha representa um exemplo independente e pode ser validada separadamente.

Para o exemplo do classificador de intenção, utilizou-se script para formatar o dataset ATIS em JSONL. O Nova Micro aceita um conjunto de validação separado — foram reservados 10% dos dados para validação e um conjunto de teste não utilizado no treinamento para testes limpos. Modelos Nova 2 fazem essa divisão automaticamente.

Ao trabalhar com modelos multimodais, confirme uso apenas de formatos de imagem suportados: PNG, JPEG e GIF. Valide o dataset com sua equipe, removendo respostas ambíguas ou contraditórias antes do treinamento.

Para informações detalhadas sobre preparação de dados para fine-tuning Nova, consulte a documentação correspondente.

Considerações de Privacidade de Dados

Ao trabalhar com dados sensíveis, anonimize ou mascare Informações Pessoalmente Identificáveis (nomes, emails, telefones, dados de pagamento) antes do upload para S3. Considere requisitos de residência de dados para conformidade regulatória.

O Amazon Bedrock não utiliza seus dados de treinamento para melhorar modelos base. Para segurança aprimorada, configure endpoints VPC para conectividade privada entre S3 e Amazon Bedrock, eliminando exposição à internet pública.

Hiperparâmetros Críticos

Embora o Amazon Bedrock defina padrões sensatos, três hiperparâmetros merecem atenção:

epochCount especifica quantas passagens completas o modelo faz através do dataset. O modelo Nova suporta 1 a 5 épocas com padrão de 2. Datasets maiores convergem com menos épocas, enquanto datasets menores beneficiam-se de mais iterações. Para o exemplo ATIS com ~5000 amostras, foi utilizado epochCount de 3.

learningRateMultiplier controla quão agressivamente o modelo aprende com erros — essencialmente, o tamanho do passo nas correções. Taxa alta demais resulta em saltos que perdem detalhes. Taxa baixa demais produz aprendizado lento. Para ATIS, utilizou-se 1e-5 (0,00001), proporcionando aprendizado estável e gradual.

learningRateWarmupSteps aumenta gradualmente a taxa de aprendizado durante iterações iniciais, estabilizando o treinamento. O padrão de 10 foi mantido no exemplo.

Para documentação completa sobre hiperparâmetros de modelos Nova, consulte a referência específica.

Iniciando um Job de Fine-Tuning

Pré-requisito: criar bucket S3 com dados de treinamento. Configure o bucket S3 na mesma região do job Bedrock com:

• Criptografia server-side (SSE-S3 ou SSE-KMS)
• Acesso público bloqueado
• Versionamento S3 para proteção contra sobrescrita acidental e rastreamento de mudanças
• Mesmas criptografia e controles de acesso no bucket de saída

Faça upload do arquivo JSONL e organize-o com prefixo /training-data.

Acesse o Console de Gerenciamento AWS, selecione Amazon Bedrock, navegue para “Modelos Personalizados” e escolha “Criar job de fine-tuning supervisionado”. Especifique o modelo Nova Micro como modelo fonte, o caminho S3 do arquivo JSONL de treinamento (exemplo: s3://seu-bucket/training-data/dados-treinamento-v2.jsonl) e o caminho S3 para saída dos resultados.

Configure os hiperparâmetros: epochCount: 3, learningRateMultiplier: 1e-5, learningRateWarmupSteps: 10.

Selecione função IAM com permissões S3 de menor privilégio ou crie uma. A função deve ter permissões limitadas a ações específicas (s3:GetObject e s3:PutObject) em caminhos específicos do bucket. Para orientação detalhada sobre boas práticas de permissões S3, consulte a documentação IAM da AWS.

Monitoramento e Avaliação

Monitore o status do job no dashboard de modelos personalizados. Aguarde conclusão da fase de validação de dados, seguida pela fase de treinamento (durando minutos a horas conforme tamanho e modalidade do dataset). Após conclusão bem-sucedida, um modelo personalizado é criado e pronto para inferência.

Analise as curvas de perda para verificar convergência apropriada. Uma curva de perda decrescente lisa indica sucesso — o modelo está aprendendo efetivamente. Padrões oscilantes (flutuações selvagens) sugerem taxa de aprendizado excessiva; reduza learningRateMultiplier em 50%. Curvas planas ou quase inalteradas indicam necessidade de mais épocas ou dados melhores; aumente epochCount em 1-2 épocas.

Custo e Tempo de Treinamento

Treinar o modelo Nova Micro personalizado para o exemplo ATIS com 4.978 amostras combinadas e 3 épocas (~1,75M tokens totais) completou em aproximadamente 1,5 horas com custo de apenas $2,18, mais taxa de armazenamento mensalrecorrente de $1,75 para o modelo.

Inferência On-Demand usando modelos Amazon Nova personalizado é cobrada à mesma taxa dos modelos não personalizados. Consulte a página de preços do Bedrock para referência atualizada.

O fine-tuning gerenciado do Amazon Bedrock torna a personalização acessível economicamente para a maioria das organizações, abrindo possibilidades para customizar modelos visando melhor desempenho e velocidade sem manutenção de prompts longos ou bases de conhecimento proprietárias.

Implantação e Segurança

Para inferência sob demanda não previsível ou baixo volume, use On-Demand. Para workloads de produção consistentes e alto volume exigindo desempenho garantido e custos menores por token, considere capacidade provisionada.

Implemente restrições de invocação usando políticas de recursos IAM para controlar quais usuários e aplicações podem invocar seu modelo personalizado. Configure autenticação/autorização para chamadas de API através de papéis e políticas IAM.

Configure endpoints VPC para Amazon Bedrock mantendo tráfego dentro de sua rede AWS. Restrinja acesso de rede a pipelines de treinamento e inferência usando grupos de segurança e Network ACLs.

Habilite endpoints VPC e configure CloudTrail para logging de chamadas de API, CloudWatch para métricas de invocação e performance, e logs de acesso S3 para rastreamento de padrões de acesso.

Avaliação do Modelo Personalizado

Após treinamento, é essencial avaliar desempenho em mundo real. Uma abordagem comum é “LLM como juiz”, onde um modelo maior com acesso a base RAG completa avalia respostas do modelo treinado versus respostas esperadas. O Amazon Bedrock oferece o serviço Amazon Bedrock Evaluations ou você pode usar seu próprio framework. Para orientação, consulte o artigo sobre LLM-as-a-judge no Amazon Bedrock Model Evaluation.

Use um conjunto de teste de perguntas e respostas preparado com mesma metodologia dos dados de treinamento, mas mantido separado para validação limpa. Para o exemplo ATIS, o modelo fine-tuned atingiu 97% de precisão no conjunto de testes — melhoria de 55,6% em relação ao modelo base Nova Micro.

Alternativas Avançadas

Para necessidades de customização mais extensas, o Amazon SageMaker AI oferece customização mais ampla e controle detalhado sobre hiperparâmetros.

Para casos demandando customização ainda mais profunda, o Amazon Nova Forge oferece alternativa estratégica a construir modelos fundacionais do zero. Enquanto fine-tuning ensina comportamentos específicos via exemplos rotulados, Nova Forge utiliza pré-treinamento continuado para construir conhecimento de domínio abrangente imergindo o modelo em milhões a bilhões de tokens de dados proprietários não rotulados.

Essa abordagem é ideal para organizações com datasets proprietários massivos, domínios altamente especializados demandando expertise profunda, ou aquelas construindo modelos fundacionais estratégicos de longo prazo servindo como ativos organizacionais. Para exemplos de customização Nova Forge, consulte o Amazon Nova Customization Hub no GitHub.

Próximos Passos

Para iniciar seu próprio projeto de fine-tuning com Amazon Bedrock, explore a documentação de fine-tuning do Amazon Bedrock e revise notebooks de exemplo no repositório AWS Samples no GitHub. Consulte a página de On-Demand inference e verifique a página de preços do Bedrock para taxas atualizadas.

Fonte

Customize Amazon Nova models with Amazon Bedrock fine-tuning (https://aws.amazon.com/blogs/machine-learning/customize-amazon-nova-models-with-amazon-bedrock-fine-tuning/)

Nova funcionalidade de agendamento sincronizado no SageMaker HyperPod

A AWS anunciou que o SageMaker HyperPod agora oferece suporte a gang scheduling em sua governança de tarefas. Esse recurso representa um avanço importante para profissionais que trabalham com treinamento distribuído de modelos de inteligência artificial e aprendizado de máquina em larga escala.

Por que o gang scheduling importa

Em ambientes de computação distribuída, quando cientistas de dados executam trabalhos de treinamento de IA/ML no SageMaker HyperPod usando o orquestrador EKS (Elastic Kubernetes Service), múltiplos pods precisam trabalhar em conjunto em diferentes nós, estabelecendo comunicação pod-a-pod para coordenar o treinamento.

O problema surge quando alguns pods iniciam enquanto outros permanecem indisponíveis. Nessa situação, os jobs em execução continuam ocupando recursos sem fazer progresso real, bloqueando outras cargas de trabalho na fila e elevando custos desnecessariamente. Além disso, podem criar deadlocks quando jobs ficam aguardando recursos que nunca chegam a estar disponíveis simultaneamente.

Como o gang scheduling resolve esses desafios

O novo recurso monitora continuamente todos os pods que compõem uma carga de trabalho e recua a execução se nem todos os pods ficarem prontos dentro de um prazo configurável. Essas cargas de trabalho recuadas são automaticamente reinseridas na fila de espera, evitando travamentos do sistema.

Administradores de infraestrutura ganham controle granular sobre o comportamento do agendamento através do Console HyperPod, podendo ajustar parâmetros como:

• O tempo de espera para que todos os pods fiquem prontos
• Estratégias para lidar com falhas de nós
• Configurações para admitir cargas de trabalho uma de cada vez, reduzindo deadlocks em clusters congestionados
• Políticas de agendamento de novas tentativas

Disponibilidade regional

O recurso está disponível para clusters SageMaker HyperPod que utilizam o orquestrador EKS nas seguintes regiões da AWS: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Jakarta), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain) e South America (São Paulo).

Próximos passos

Para aprender mais sobre essa funcionalidade, consulte a página do SageMaker HyperPod e a documentação de governança de tarefas HyperPod.

Fonte

SageMaker HyperPod now supports gang scheduling for distributed training workloads (https://aws.amazon.com/about-aws/whats-new/2026/04/sagemaker-hyperpod-gang-scheduling/)

Introdução: Por que a Supervisão Humana é Essencial em Saúde

No setor de saúde e ciências da vida, agentes de IA desempenham papéis cada vez mais relevantes: processam dados clínicos, submetem registros regulatórios, automatizam codificação médica e aceleram o desenvolvimento e comercialização de medicamentos. No entanto, a natureza sensível dos dados médicos e requisitos regulatórios como conformidade com Boas Práticas (GxP) exigem supervisão humana em pontos críticos de decisão. É neste contexto que as construções de aprovação humana no fluxo de trabalho (conhecidas como human-in-the-loop ou HITL) se tornam fundamentais.

A AWS apresentou quatro abordagens práticas para implementar esses mecanismos de aprovação usando seus serviços de nuvem, permitindo que organizações de saúde mantenham tanto a segurança regulatória quanto os ganhos de eficiência que a automação inteligente proporciona.

Desafios Únicos da Implementação de Agentes em Saúde

As organizações de saúde e ciências da vida enfrentam desafios específicos ao implantar agentes de IA:

• Conformidade regulatória – As regulamentações GxP exigem supervisão humana para operações sensíveis. Por exemplo, exclusão de registros de pacientes ou modificações em protocolos de ensaios clínicos não podem prosseguir sem autorização documentada.
• Segurança do paciente – Decisões médicas que afetam o cuidado do paciente devem ter validação clínica antes da execução.
• Requisitos de auditoria – Os sistemas de saúde precisam de rastreabilidade completa: quem aprovou cada ação e quando.
• Sensibilidade dos dados – Informações Protegidas de Saúde (PHI) exigem autorização explícita antes de acesso ou modificação.

As construções HITL fornecem esses pontos de controle necessários mantendo os ganhos de eficiência da automação baseada em agentes, permitindo que as organizações atendam a todos esses requisitos simultaneamente.

Quatro Estratégias Complementares de Implementação

A AWS apresenta quatro padrões complementares, cada um adequado para diferentes cenários e perfis de risco. A implementação utiliza o framework Strands Agents, o Amazon Bedrock AgentCore Runtime e o Protocolo de Contexto do Modelo (Model Context Protocol – MCP), com exemplos de código que podem ser adaptados para casos de uso específicos.

Método 1: Interrupção no Loop do Agente (Sistema de Hooks)

O framework Strands Agents fornece um sistema de hooks que intercepta chamadas de ferramentas antes de sua execução no nível do loop do agente. Essa abordagem aplica uma política HITL uniforme a ferramentas sensíveis sem necessidade de modificar as ferramentas em si.

Um HookProvider registra um callback no evento BeforeToolCallEvent. Quando uma ferramenta sensível é invocada, o hook dispara uma interrupção, pausando o loop do agente até que o operador humano responda. O usuário pode responder com “y” (aprovar uma vez), “n” (negar) ou “t” (confiar – aprovar essa ferramenta pelo restante da sessão).

class ApprovalHook(HookProvider):
    SENSITIVE_TOOLS = ["get_patient_condition", "get_patient_vitals"]
    
    def register_hooks(self, registry: HookRegistry, **kwargs: Any) -> None:
        registry.add_callback(BeforeToolCallEvent, self.approve)
    
    def approve(self, event: BeforeToolCallEvent) -> None:
        tool_name = event.tool_use["name"]
        if tool_name not in self.SENSITIVE_TOOLS:
            return
        
        # Pular se o usuário já escolheu "confiar sempre" para esta ferramenta
        approval_key = f"{tool_name}-approval"
        if event.agent.state.get(approval_key) == "t":
            return
        
        approval = event.interrupt(
            approval_key,
            reason={"reason": f"Authorize {tool_name} with args: {event.tool_use.get('input', {})}"},
        )
        
        if approval.lower() not in ["y", "yes", "t"]:
            event.cancel_tool = f"User denied permission to run {tool_name}"
            return
        
        if approval.lower() == "t":
            event.agent.state.set(approval_key, "t")

O hook é anexado ao agente no momento da construção — as ferramentas permanecem completamente desconhecidas da lógica de aprovação, mantendo a separação de responsabilidades:

agent = Agent(
    hooks=[ApprovalHook()],
    tools=[get_patient_name, get_patient_condition, get_patient_vitals],
)

Método 2: Interrupção no Contexto da Ferramenta

Em vez de um hook centralizado, a lógica de aprovação é incorporada diretamente em cada ferramenta usando tool_context.interrupt(). Essa abordagem oferece controle granular por ferramenta: cada uma implementa suas próprias regras de acesso baseadas no contexto da sessão.

Neste exemplo, a sessão do agente carrega um user_role. Uma função check_access compartilhada implementa controle de acesso baseado em papéis. Usuários não-médicos recebem negação imediata, enquanto médicos recebem um prompt de aprovação:

def check_access(tool_context, patient_id: str, action: str):
    user_role = tool_context.agent.state.get("user_role") or "Non-Physician"
    if user_role != "Physician":
        return f"Access denied: {action} requires Physician role (current: {user_role})"
    
    approval_key = f"{action}-{patient_id}-approval"
    if tool_context.agent.state.get(approval_key) == "t":
        return None  # previously trusted
    
    approval = tool_context.interrupt(
        approval_key,
        reason={"reason": f"[{user_role}] Authorize {action} for patient {patient_id}"},
    )
    
    if approval.lower() not in ["y", "yes", "t"]:
        return f"Physician denied access to {action} for patient {patient_id}"
    
    if approval.lower() == "t":
        tool_context.agent.state.set(approval_key, "t")
    return None  # approved

Como no Método 1, a opção de confiança armazena a aprovação para o restante da sessão, evitando prompts repetitivos para a mesma operação.

Método 3: Aprovação Assíncrona com AWS Step Functions

Em muitos cenários empresariais, o fluxo de aprovação requer autorização de um terceiro que não está invocando o agente. Isso necessita de um fluxo de trabalho assíncrono que funcione independentemente da sessão do agente.

Uma abordagem efetiva utiliza AWS Step Functions para orquestrar esses processos de aprovação externa. Neste padrão, a ferramenta do agente dispara uma execução do Step Functions que envia uma solicitação de aprovação a um aprovador externo através de notificação por email via Amazon SNS (Serviço de Notificação Simples).

A ferramenta consulta periodicamente o resultado da aprovação e atualiza o estado da sessão do agente. O usuário também pode verificar o status de aprovação depois usando uma ferramenta separada check_discharge_status:

@tool(context=True)
def discharge_patient(tool_context, patient_id: str, reason: str) -> str:
    # Skip workflow if already approved in this session
    if tool_context.agent.state.get("external-approver-state") == "approved":
        return f"Patient {patient_id} discharged (pre-approved). Reason: {reason}"
    
    response = sfn_client.start_execution(
        stateMachineArn=state_machine_arn,
        input=json.dumps({"patient_id": patient_id, "action": "discharge", "reason": reason}),
    )
    
    return f"Waiting for approval. Execution ARN: {response['executionArn']}"

Essa abordagem assíncrona permite operações não-bloqueantes onde os usuários não são forçados a aguardar aprovações que podem levar horas ou dias. A execução do agente prossegue independentemente. O Step Functions mantém trilhas de auditoria detalhadas com histórico completo de execução, gerenciamento de estado persistente entre timeouts de sessão e integração com canais de comunicação empresariais como email, Slack ou Microsoft Teams.

Método 4: Elicitação via Protocolo de Contexto do Modelo (MCP)

O protocolo MCP (Model Context Protocol) introduziu recentemente o conceito de elicitação, que permite que servidores MCP solicitem informações ou aprovação adicionais do usuário durante a execução da ferramenta.

Quando uma ferramenta sensível é chamada, o servidor MCP pausa a execução e envia um prompt de aprovação de volta através do cliente MCP para o usuário final. O usuário vê o prompt, toma uma decisão e o servidor retoma — procedendo com a operação ou negando acesso. Essa comunicação bidirecional é habilitada pelo transporte HTTP contínuo do MCP, que mantém uma conexão com estado entre cliente e servidor.

No servidor MCP, a lógica de aprovação é uma única chamada ctx.elicit() dentro de cada ferramenta sensível:

@server.tool
async def get_patient_condition(patient_id: str, ctx: Context) -> str:
    """Get patient condition. Sensitive — requires approval via MCP elicitation."""
    result = await ctx.elicit(
        f"⚠️ Approve access to SENSITIVE condition data for patient {patient_id}?"
    )
    
    if result.action != "accept":
        return f"Access to condition data for patient {patient_id} DENIED."
    
    return f"Patient {patient_id} condition: Hypertension Stage 2, Type 2 Diabetes"

No lado do agente, um callback de elicitação é registrado com o cliente MCP. Quando o servidor chama ctx.elicit(), esse callback dispara, transmitindo o prompt de aprovação ao usuário e retornando sua decisão de volta ao servidor. Para agentes locais, este é um prompt terminal. Para agentes implantados no AgentCore Runtime, uma conexão WebSocket retransmite a elicitação para o usuário remoto em tempo real.

Essa abordagem mantém a lógica de aprovação inteiramente dentro das definições de ferramentas do servidor MCP. O agente em si desconhece quais ferramentas exigem aprovação, permitindo adicionar ou modificar requisitos de aprovação de forma independente.

Visão Geral da Arquitetura

A arquitetura da solução utiliza o framework Strands Agents para gerenciamento do ciclo de vida do agente e tratamento de interrupções, implantado no Amazon Bedrock AgentCore Runtime para escalabilidade sem servidor e isolamento de sessão. AWS Step Functions orquestra fluxos de trabalho de aprovação assíncrona com Amazon SNS, enquanto servidores MCP expõem ferramentas ao agente através do MCP — também implantados no AgentCore Runtime.

Todos os códigos para esses padrões de arquitetura estão disponíveis publicamente no repositório GitHub. Cada um dos métodos demonstrados representa uma abordagem autocontida.

Detalhes de Implementação Prática

O agente é implantado no Amazon Bedrock AgentCore Runtime com acesso a ferramentas de saúde em diferentes níveis de sensibilidade. Operações de baixo risco, como buscar o nome de um paciente, executam sem aprovação. Ações de alto risco, como recuperação de sinais vitais ou condições médicas, exigem autorização humana. Operações como alta hospitalar requerem aprovação de supervisor externo através de notificação por email.

A seleção entre os quatro padrões depende do seu caso de uso específico: o Método 1 oferece controle centralizado e uniforme; o Método 2 oferece flexibilidade por ferramenta com controle granular; o Método 3 acomoda aprovações externas assíncronas em ambientes empresariais; e o Método 4 proporciona aprovação interativa em tempo real com protocolo padrão.

Conclusão: Segurança e Eficiência em Harmonia

Os padrões de aprovação humana apresentados permitem que organizações de saúde e ciências da vida construam implantações seguras e compatíveis de agentes de IA. Ao implementar o padrão HITL apropriado para seu caso de uso, é possível implantar fluxos de trabalho prontos para produção que escalem desde projetos piloto até implantações em toda a empresa.

O primeiro passo é identificar quais operações no seu fluxo de trabalho exigem supervisão humana. Em seguida, selecione o padrão HITL que melhor se adequa aos seus requisitos de aprovação — centralizado (Método 1), específico por ferramenta (Método 2), assíncrono (Método 3) ou em tempo real (Método 4).

Para informações adicionais sobre Amazon Bedrock AgentCore, visite a documentação do Amazon Bedrock AgentCore.

Fonte

Human-in-the-loop constructs for agentic workflows in healthcare and life sciences (https://aws.amazon.com/blogs/machine-learning/human-in-the-loop-constructs-for-agentic-workflows-in-healthcare-and-life-sciences/)

O desafio de entender os gastos com IA

Conforme as organizações ampliam suas operações de IA no Amazon Bedrock, compreender o que está impulsionando os gastos se torna essencial. Equipes precisam realizar cobranças internas, investigar picos de custo e orientar decisões de otimização — tudo isso exigindo uma atribuição de custos no nível da carga de trabalho. O desafio cresce quando múltiplos projetos, ambientes e times utilizam os mesmos recursos.

Para endereçar essa necessidade, a AWS desenvolveu o Amazon Bedrock Projects, um recurso que permite atribuir custos de inferência a cargas de trabalho específicas e analisar esses gastos usando ferramentas de billing já consolidadas na plataforma, como AWS Cost Explorer e AWS Data Exports.

Como funcionam os Bedrock Projects e a alocação de custos

Na prática, um projeto no Amazon Bedrock é uma demarcação lógica que representa uma carga de trabalho — pode ser uma aplicação, um ambiente ou até um experimento. Para atribuir custos a esse projeto, você anexa etiquetas de recurso (resource tags) e passa o ID do projeto nas chamadas de API. Posteriormente, essas etiquetas podem ser ativadas como etiquetas de alocação de custos no AWS Billing, permitindo filtrar, agrupar e analisar gastos no Cost Explorer e nos Data Exports.

O fluxo é simples: usuários e aplicações enviam requisições de API com o ID do projeto, que passa por Foundation Models (como OpenAI, Meta e DeepSeek). As etiquetas associadas ao projeto fluem para o AWS Billing & Cost Management, onde você ativa a alocação de custos de forma única. A partir daí, todas as ferramentas de análise ficam cientes dessa dimensão de custo.

Pontos importantes sobre compatibilidade

O Amazon Bedrock Projects oferece suporte aos endpoints Mantle compatíveis com a API OpenAI, incluindo a Responses API e a Chat Completions API. Requisições que não incluem um ID de projeto são automaticamente associadas ao projeto padrão da sua conta AWS.

Preparação: pré-requisitos e permissões

Antes de começar, você precisa de:

• Acesso ao Amazon Bedrock com suporte ao OpenAI SDK. Confira o Guia de Início Rápido do Amazon Bedrock para começar.
• Permissões do IAM (Identity and Access Management) para Amazon Bedrock Projects, inferência e tagging. Para fins de exemplo, você pode anexar a política gerenciada da AWS AmazonBedrockMantleFullAccess. Em produção, consulte Implementando privilégio mínimo para Amazon Bedrock.
• Acesso ao console de Billing e Gerenciamento de Custos da AWS.

Definindo sua estratégia de etiquetagem

As etiquetas que você vincula aos projetos tornam-se as dimensões que você pode filtrar e agrupar nos seus relatórios de custo. Recomenda-se planejar essas dimensões antes de criar o primeiro projeto. Uma abordagem comum é etiquetar por aplicação, ambiente, time e centro de custo:

Chave de Etiqueta	Propósito	Exemplos de Valores
Application	Qual carga de trabalho ou serviço	CustomerChatbot, Experiments, DataAnalytics
Environment	Estágio do ciclo de vida	Production, Development, Staging, Research
Team	Responsabilidade ou propriedade	CustomerExperience, PlatformEngineering, DataScience
CostCenter	Mapeamento financeiro	CC-1001, CC-2002, CC-3003

Para mais orientações sobre construir uma estratégia de alocação de custos, consulte Melhores Práticas para Etiquetar Recursos AWS. Com sua estratégia de etiquetagem definida, você está pronto para criar projetos e começar a atribuir custos.

Criando seu primeiro projeto

Com a estratégia de etiquetagem e as permissões em lugar, você pode criar seu primeiro projeto. Cada projeto tem seu próprio conjunto de etiquetas de alocação de custos que fluem para seus dados de billing. O exemplo a seguir demonstra como criar um projeto usando a Projects API.

Instalando dependências

Comece instalando as bibliotecas necessárias:

$ pip3 install openai requests

Criando um projeto com sua taxonomia de etiquetas

O OpenAI SDK utiliza a variável de ambiente OPENAI_API_KEY. Defina-a com sua chave de API do Bedrock:

import os
import requests

# Configuration
BASE_URL = "https://bedrock-mantle..api.aws/v1"
API_KEY = os.environ.get("OPENAI_API_KEY")

# Your Amazon Bedrock API key

def create_project(name: str, tags: dict) -> dict:
    """Create a Bedrock project with cost allocation tags."""
    response = requests.post(
        f"{BASE_URL}/organization/projects",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json"
        },
        json={"name": name, "tags": tags}
    )
    if response.status_code != 200:
        raise Exception(
            f"Failed to create project: {response.status_code} - {response.text}"
        )
    return response.json()

# Create a production project with full tag taxonomy
project = create_project(
    name="CustomerChatbot-Prod",
    tags={
        "Application": "CustomerChatbot",
        "Environment": "Production",
        "Team": "CustomerExperience",
        "CostCenter": "CC-1001",
        "Owner": "alice"
    }
)
print(f"Created project: {project['id']}")

A API retorna os detalhes do projeto, incluindo o ID e o ARN:

{
    "id": "proj_123",
    "arn": "arn:aws:bedrock-mantle:::project/"
}

Guarde o ID do projeto — você o usará para associar requisições de inferência na próxima etapa. O ARN é utilizado para anexação de políticas do IAM se você precisar restringir o acesso a esse projeto específico.

Repita esse processo para cada carga de trabalho. A tabela a seguir mostra uma estrutura de projeto de exemplo para uma organização com três aplicações:

Nome do Projeto	Application	Environment	Team	Cost Center
CustomerChatbot-Prod	CustomerChatbot	Production	CustomerExperience	CC-1001
CustomerChatbot-Dev	CustomerChatbot	Development	CustomerExperience	CC-1001
Experiments-Research	Experiments	Production	PlatformEngineering	CC-2002
DataAnalytics-Prod	DataAnalytics	Production	DataScience	CC-3003

Você pode criar até 1.000 projetos por conta AWS para atender às necessidades da sua organização.

Associando requisições de inferência ao seu projeto

Com seus projetos criados, você associa requisições de inferência passando o ID do projeto em suas chamadas de API. O exemplo a seguir utiliza a Responses API:

from openai import OpenAI

client = OpenAI(
    base_url="https://bedrock-mantle..api.aws/v1",
    project="",
    # ID returned when you created the project
)

response = client.responses.create(
    model="openai.gpt-oss-120b",
    input="Summarize the key findings from our Q4 earnings report."
)

print(response.output_text)

Para manter uma atribuição de custos limpa e consistente, sempre especifique um ID de projeto em suas chamadas de API em vez de depender do projeto padrão.

Ativando as etiquetas de alocação de custos

Antes que suas etiquetas de projeto apareçam nos relatórios de custo, você deve ativá-las como etiquetas de alocação de custos no AWS Billing. Esse é um processo de configuração único que conecta suas etiquetas de projeto ao pipeline de billing. Para mais informações, consulte a documentação de ativação de etiquetas de alocação de custos no AWS Billing.

Pode levar até 24 horas para as etiquetas se propagarem para o AWS Cost Explorer e AWS Data Exports. Recomenda-se ativar suas etiquetas imediatamente após criar seu primeiro projeto para evitar lacunas nos dados de custo.

Visualizando custos dos projetos

Com os projetos criados, as requisições de inferência etiquetadas e as etiquetas de alocação de custos ativadas, você consegue ver exatamente para onde seus gastos com Amazon Bedrock estão indo. Cada dimensão que você definiu em sua taxonomia agora está disponível como filtro ou agrupamento em seus relatórios de billing da AWS.

Usando o AWS Cost Explorer

O AWS Cost Explorer oferece a forma mais rápida de visualizar seus custos por projeto. Siga estes passos para revisar seus custos por projeto:

• Abra o console de Billing e Gerenciamento de Custos da AWS e escolha Cost Explorer.
• No painel Filtros, expanda Serviço e selecione Amazon Bedrock.
• Em Agrupar por, selecione Etiqueta e escolha sua chave de etiqueta (por exemplo, Application).

Para mais formas de refinar sua visualização, consulte Analisando seus custos e uso com AWS Cost Explorer.

Análise mais granular com Data Exports

Para análise mais granular e detalhes de linha de item com suas etiquetas de projeto, consulte Criando Data Exports na documentação do AWS Billing.

Conclusão

Com o Amazon Bedrock Projects, as organizações conseguem atribuir custos a cargas de trabalho individuais e acompanhar gastos utilizando as ferramentas de billing que já dominam. Conforme suas operações de IA escalam, utilize a estratégia de etiquetagem e os padrões de visibilidade de custos apresentados neste artigo para manter a responsabilidade entre equipes e aplicações.

Para mais informações, consulte a documentação do Amazon Bedrock Projects e o AWS Cost Management User Guide.

Fonte

Manage AI costs with Amazon Bedrock Projects (https://aws.amazon.com/blogs/machine-learning/manage-ai-costs-with-amazon-bedrock-projects/)