Blog

Uma solução inteligente para renderização em nuvem

A AWS anunciou um novo assistente baseado em inteligência artificial para o Deadline Cloud, seu serviço gerenciado que simplifica a gestão de renderização para gráficos 2D/3D, efeitos visuais e conteúdo digital. Essa ferramenta foi desenvolvida para resolver um problema real enfrentado por produtoras de filmes, séries, comerciais, estúdios de games e empresas de design industrial: as falhas que interrompem pipelines de produção.

O desafio das falhas em renderização

Problemas que geram desperdício

Trabalhos de renderização podem falhar por diversos motivos: ativos digitais faltando, erros de software, configurações incompatíveis ou limitações de recursos. Quando isso acontece, não só a produção é interrompida como recursos computacionais são desperdiçados. Historicamente, diagnosticar essas falhas era um processo manual e demorado — especialistas técnicos precisavam analisar centenas de linhas de registros para identificar a causa raiz do problema.

Uma barreira para estúdios menores

Esse cenário criava uma barreira especialmente difícil para estúdios pequenos e médios que não possuem equipes técnicas dedicadas ou não conseguem escalar esse tipo de diagnóstico facilmente.

Como o assistente funciona

O novo assistente do Deadline Cloud investiga trabalhos que falharam, analisa registros e métricas, detecta problemas comuns e recomenda ações corretivas. A base de conhecimento do assistente foi treinada com informações sobre o Deadline Cloud, problemas típicos de render farms e aplicações populares de criação de conteúdo digital, incluindo Autodesk Maya, 3ds Max, VRED, Blender, SideFX Houdini, Maxon Cinema 4D, Foundry Nuke e Adobe After Effects.

Um diferencial importante: o assistente executa dentro da conta da AWS do usuário, utilizando o Amazon Bedrock, mantendo todos os dados e análises sob controle total da organização.

Disponibilidade

O assistente do Deadline Cloud está disponível a partir de agora em todas as regiões da AWS onde o Deadline Cloud é suportado. Para conhecer a ferramenta na prática, é possível assistir a uma demonstração em vídeo ou consultar a documentação do AWS Deadline Cloud para mais detalhes.

Fonte

AWS Deadline Cloud announces AI-powered troubleshooting assistant for render jobs (https://aws.amazon.com/about-aws/whats-new/2026/04/deadline-cloud-ai-troubleshooting/)

Por que a busca semântica em vídeos importa

A demanda por experiências centradas em vídeo está transformando a forma como as organizações entregam conteúdo. Usuários esperam encontrar rapidamente momentos específicos dentro de arquivos de vídeo, e as indústrias de mídia estão enfrentando desafios reais para atender essa expectativa.

Transmissoras de esportes precisam identificar o exato instante em que um jogador marca um gol para disponibilizar o destaque aos fãs instantaneamente. Estúdios de cinema buscam cada cena que apresenta um ator específico ao longo de milhares de horas de arquivo para criar trailers personalizados. Agências de notícias recuperam vídeos por estado emocional, localização ou tipo de evento para publicar reportagens antes dos concorrentes. O denominador comum é claro: entregar conteúdo de vídeo aos usuários rapidamente, capturar o momento certo e monetizar a experiência.

O desafio fundamental reside na complexidade inerente ao vídeo. Diferentemente de texto ou imagens isoladas, um arquivo de vídeo combina múltiplos sinais não estruturados simultaneamente: a cena visual que se desenrola, o áudio ambiente, efeitos sonoros, diálogos, informações temporais e metadados estruturados descrevendo o ativo.

Uma busca por “perseguição de carro com sirenes” envolve tanto um evento visual quanto um evento de áudio. Uma busca por um atleta específico pelo nome pode retornar alguém que aparece de forma proeminente na tela, mas nunca é mencionado na fala. Converter vídeo em texto inevitavelmente perde informações críticas: contexto temporal desaparece e erros de transcrição emergem de problemas de qualidade visual e áudio.

A abordagem inovadora: Embeddings Multimodais do Amazon Nova

A AWS apresentou os Embeddings Multimodais do Amazon Nova, um modelo de embedding unificado que processa nativamente texto, documentos, imagens, vídeo e áudio em um espaço vetorial semântico compartilhado. O modelo oferece precisão de recuperação líder da indústria com eficiência de custo notável.

Diferentemente de abordagens tradicionais que mapeiam todos os sinais de vídeo em texto antes da busca, esse modelo multimodal processa todos os sinais simultaneamente sem perder detalhes essenciais. A solução construída sobre o Amazon Bedrock demonstra como integrar embeddings multimodais com uma arquitetura híbrida inteligente que funde sinais semânticos e lexicais em todos os tipos de mídia do vídeo.

Arquitetura da solução

A solução foi desenvolvida em duas fases distintas: um pipeline de ingestão que converte vídeo em embeddings pesquisáveis, e um pipeline de busca que roteia consultas de usuários inteligentemente entre essas representações.

Pipeline de ingestão

O fluxo de ingestão segue seis etapas principais. Primeiro, vídeos enviados via navegador são armazenados no Amazon DynamoDB para rastreamento de status enquanto um pipeline do AWS Step Functions é iniciado através de um orquestrador em AWS Lambda.

Na etapa de segmentação, o AWS Fargate utiliza detecção de cenas com FFmpeg para dividir o vídeo em segmentos semanticamente coerentes. Três branches paralelos então processam cada segmento: embeddings visuais e de áudio são gerados e armazenados, Amazon Transcribe converte fala em texto, e Amazon Rekognition identifica celebridades.

O Amazon Nova 2 Lite sintetiza legendas em nível de segmento e rótulos de gênero. Uma função Lambda monta todos os metadados e recupera os embeddings do Amazon S3 Vectors. Os documentos completos de segmento, com metadados e vetores, são então indexados em massa no Amazon OpenSearch Service.

Pipeline de consulta

Usuários autenticam através do Amazon Cognito e acessam a interface pela Amazon CloudFront. O Amazon API Gateway roteia requisições para uma função Lambda de busca, que executa duas operações paralelas.

A análise de intenção utiliza Amazon Bedrock com Anthropic Claude Haiku para atribuir pesos de relevância entre os canais visual, áudio, transcrição e metadados. Simultaneamente, os Embeddings Multimodais do Amazon Nova processam a consulta três vezes para correspondência de similaridade visual, áudio e transcrição.

Decisões de design críticas

Segmentação semântica para continuidade de contexto

Antes de gerar qualquer embedding, o vídeo deve ser dividido em unidades pesquisáveis, e as fronteiras traçadas impactam diretamente a precisão da busca. Cada segmento se torna a unidade atômica de recuperação.

Segmentos muito curtos perdem o contexto circundante que confere significado a um momento. Segmentos muito longos fundem múltiplos tópicos ou cenas, diluindo a relevância. Blocos de comprimento fixo são diretos de produzir, mas ignoram a estrutura natural do conteúdo—uma transição de cena no meio de um segmento divide uma ideia visual entre dois chunks.

A solução usa detecção de cenas do FFmpeg para identificar onde o conteúdo visual realmente muda. O framework FFmpeg é amplamente utilizado para processamento de vídeo, conversão de formatos e análise. A função de detecção retorna timestamps marcando limites naturais de cena. O algoritmo de segmentação então alinha cada corte ao limite de cena mais próximo dentro de uma janela aceitável, buscando aproximadamente dez segundos com mínimo de cinco e máximo de quinze segundos.

O resultado são segmentos que soam naturais—oito a doze segundos cada—alinhados a transições visuais reais em vez de divisões arbitrárias. Essa abordagem simples baseada em cenas garante que limites de segmento correspondam a transições visuais naturais.

Embeddings separados para sinais visuais, de áudio e transcrição

Com segmentos definidos, a escolha do modelo de embedding é onde a maior lacuna de qualidade emerge. A abordagem dominante atualmente fundamenta todos os sinais de vídeo em texto antes de gerar embeddings. Enquanto isso funciona para conteúdo repleto de diálogos, converter vídeo em texto inevitavelmente perde informações críticas.

Os Embeddings Multimodais do Amazon Nova mudam isso fundamentalmente porque é um modelo nativo de vídeo que pode gerar embeddings em dois modos. O modo combinado funde sinais visual e de áudio em uma representação unificada, capturando os sinais mais importantes juntos. Essa abordagem beneficia custo de armazenamento e latência de recuperação ao exigir apenas um embedding por segmento.

Alternativamente, o modo AUDIO_VIDEO_SEPARATE gera embeddings visuais e de áudio distintos. Essa abordagem oferece máxima representação em embeddings específicos da modalidade e oferece melhor controle sobre quando buscar conteúdo visual versus conteúdo de áudio. A implementação adicionou até um terceiro embedding de fala derivado do Amazon Transcribe.

Os três embeddings cobrem o espaço completo de sinais de um segmento de vídeo. O embedding visual captura o que a câmera vê: objetos, cenas, ações, cores e composição espacial. O embedding de áudio captura o que o microfone ouve: música, efeitos sonoros, ruído ambiente e textura acústica. O embedding de transcrição captura o que as pessoas dizem, representando o significado semântico da fala e narração.

Busca híbrida combinando metadados e embeddings

Mesmo com três embeddings independentes cobrindo conteúdo visual, áudio e falado, existe uma classe de consultas que o sistema não pode responder bem. Embeddings são projetados para capturar similaridade semântica. Eles excelem em encontrar um “momento de multidão tensa” ou um “pôr do sol sobre a água” porque são conceitos com significado visual e áudio rico.

Mas quando um usuário busca por um nome específico, número de modelo de produto, geolocalização ou data particular, embeddings provavelmente falharão. Essas são entidades discretas com poucos sinais semânticos próprios. Aqui entra a busca híbrida. Em vez de confiar apenas em embeddings, o sistema executa dois caminhos de recuperação paralelos: um caminho semântico que corresponde aos embeddings visuais, de áudio e transcrição para capturar similaridade conceitual, e um caminho lexical que realiza correspondência exata de palavra-chave e entidade contra metadados estruturados.

A quantidade de metadados necessária depende do tipo de conteúdo, organização e caso de uso. Para a implementação, foram selecionadas categorias representando tipos comuns em mídia e entretenimento: título de vídeo e datetime (metadados técnicos), legendas de segmento, gênero e reconhecimento de celebridades (metadados contextuais). As legendas são geradas a partir do vídeo e transcrição de cada segmento. O gênero é previsto a partir da transcrição completa de vídeo. Identificação de celebridades é tratada pelo Amazon Rekognition.

Roteamento de consulta consciente de intenção

Com três embeddings e metadados, há quatro dimensões pesquisáveis. Mas como saber qual usar para uma consulta fornecida? A intenção é tudo. Para resolver isso, foi construído um roteador de análise de intenção que usa o modelo Haiku para analisar cada consulta e atribuir peso a cada canal de modalidade: visual, áudio, transcrição e metadados.

O modelo Haiku recebe uma consulta e retorna um objeto JSON com pesos que somam um, junto com um breve rastreamento explicando a atribuição. Os pesos controlam diretamente quais sub-consultas executam. Qualquer modalidade abaixo do limiar de cinco por cento é completamente ignorada, eliminando chamadas de API de embedding desnecessárias e reduzindo latência sem sacrificar precisão.

Os canais restantes executam em paralelo, cada um buscando seu próprio índice independentemente. Resultados de todos os canais ativos são então pontuados usando uma média aritmética ponderada. As pontuações BM25 (uma medida de relevância lexical baseada em frequência de termo e comprimento de documento) e pontuações de similaridade de cosseno (uma medida geométrica de quão proximamente dois vetores de embedding apontam na mesma direção) existem em escalas muito diferentes. Para resolver isso, cada pontuação de sub-consulta é primeiro normalizada para um intervalo de zero a um, depois combinada usando os pesos de intenção do roteador.

Estratégia de armazenamento para vetores e metadados

A decisão final de design é onde e como armazenar tudo isso. Cada segmento de vídeo produz até três embeddings e um conjunto de campos de metadados, e como eles são armazenados determina tanto o desempenho de busca quanto o custo em escala.

A solução divide isso entre dois serviços com papéis complementares: Amazon S3 Vectors para armazenamento de vetores e Amazon OpenSearch Service para busca híbrida. O S3 Vectors armazena três índices de vetores por projeto, um para cada tipo de embedding: visual, áudio e transcrição. O OpenSearch contém um índice por projeto, onde cada documento representa um único segmento de vídeo contendo campos de texto para busca BM25 e campos de vetor para busca de k-vizinhos mais próximos.

O S3 Vectors foi escolhido pelos benefícios de custo-performance. O Amazon S3 Vectors reduz o custo de armazenamento e consulta de vetores em até noventa por cento comparado a soluções especializadas alternativas. Se latência de busca não é crítica para o caso de uso, S3 Vectors é uma escolha padrão forte. Se a menor latência possível é necessária, recomenda-se usar vetores em memória com o mecanismo Hierarchical Navigable Small World (HNSW) do OpenSearch.

Vale ressaltar que alguns casos de uso requerem busca dentro de segmentos de vídeo mais longos e semanticamente densos, como uma entrevista completa, uma cena documentária de vários minutos ou uma demonstração de produto estendida. A maioria dos modelos de embedding multimodal, incluindo os Embeddings Multimodais do Amazon Nova, tem duração máxima de entrada de trinta segundos. O suporte de vetor aninhado no OpenSearch resolve isso permitindo que um único documento contenha múltiplos embeddings de sub-segmentos.

Resultados de desempenho

Para validar as decisões de design, a abordagem híbrida otimizada foi comparada com a linha de base do modo AUDIO_VIDEO_COMBINED dos Embeddings Multimodais do Amazon Nova. A comparação usou dez vídeos long-form internos (cinco a vinte minutos) avaliados em vinte consultas abrangendo buscas focadas em visual, áudio, transcrição e metadados.

A linha de base usa um único vetor unificado por segmento de dez segundos com um índice e uma consulta de k-vizinhos mais próximos. A abordagem otimizada gera embeddings visual, áudio e transcrição separados, enriquece segmentos com metadados estruturados e aplica roteamento consciente de intenção que pondera dinamicamente canais de modalidade.

Os resultados mostram melhorias substanciais em todas as métricas de recuperação. A busca híbrida atingiu Recall@5 e Recall@10 acima de noventa por cento versus cinquenta e um e sessenta e quatro por cento para a linha de base—um ganho de cerca de quarenta pontos percentuais em precisão de cobertura. Mean Reciprocal Rank saltou de quarenta e oito para noventa por cento, e NDCG@10 subiu de cinquenta e quatro para oitenta e oito por cento. Esses ganhos de trinta a quarenta pontos percentuais validam as decisões arquiteturais centrais: segmentação semântica preserva continuidade de conteúdo, embeddings separados oferecem controle preciso de busca, enriquecimento de metadados captura entidades factuais, e roteamento consciente de intenção garante que os sinais certos direcionem cada consulta.

Implementação prática

Uma implementação de referência completa está disponível no GitHub, permitindo seguir o passo a passo e ver como cada decisão contribui para busca precisa e escalável entre todos os tipos de sinais.

Para evitar incurrer em futuras cobranças, os recursos usados na solução podem ser deletados removendo a stack do AWS CloudFormation. Comandos detalhados estão disponíveis no repositório GitHub.

Próximos passos e otimizações

Mais otimizações podem ser realizadas para afinar ainda mais a precisão de busca, incluindo personalização de modelo para a camada de roteamento de intenção. Recomenda-se ler a Parte 2 para aprofundar essas técnicas.

Para uma implementação pronta para produção desta técnica de busca semântica de vídeo e gerenciamento de metadados em escala, consulte a Orientação para um Media Lake na AWS.

Considerações finais

A solução de busca semântica em vídeo construída sobre os Embeddings Multimodais do Amazon Nova demonstra como transformar um conjunto fragmentado de sinais em uma experiência de busca unificada e precisa que compreende vídeo. Ao manter contexto temporal, processar embeddings separados para cada modalidade, enriquecer com metadados estruturados e aplicar roteamento inteligente baseado em intenção, as organizações podem escalar de forma eficiente entre arquivos de vídeo massivos mantendo precisão de recuperação.

Essa abordagem abre possibilidades para transmissoras de esportes, estúdios de cinema, agências de notícias e qualquer organização que necessite encontrar rapidamente momentos específicos dentro de conteúdo de vídeo—capturando o momento, entregando aos usuários e monetizando a experiência.

Fonte

Power video semantic search with Amazon Nova Multimodal Embeddings (https://aws.amazon.com/blogs/machine-learning/power-video-semantic-search-with-amazon-nova-multimodal-embeddings/)

Balanceando Precisão, Custo e Latência em Buscas de Vídeo

Otimizar modelos para busca semântica de vídeos apresenta um dilema clássico em machine learning: modelos menores e rápidos carecem de inteligência de roteamento, enquanto modelos maiores e mais precisos adicionam latência significativa. A AWS, por meio de seu portfólio de serviços de inteligência artificial, oferece agora uma solução que permite alcançar os três objetivos simultaneamente.

Em um artigo anterior da série, foi apresentado como construir um sistema de busca semântica multimodal em vídeos utilizando roteamento inteligente de intenções com o modelo Anthropic Claude Haiku no Amazon Bedrock. Embora o modelo Haiku entreguasse forte precisão para interpretar intenções de busca, aumentava o tempo total de processamento para 2 a 4 segundos, representando aproximadamente 75% da latência geral.

O cenário fica ainda mais desafiador quando a lógica de roteamento se torna mais complexa. Metadados empresariais costumam ir muito além dos cinco atributos simples (título, legenda, pessoas, gênero e timestamp), incluindo ângulos de câmera, sentimentos, janelas de direitos e licenças, além de taxonomias específicas de domínio. Prompts mais sofisticados exigem modelos maiores, que aumentam custos e latência de forma desproporcional.

A Solução: Destilação de Modelos

Em vez de escolher entre um modelo rápido mas superficial ou um modelo preciso mas custoso, a destilação de modelos — uma técnica de personalização disponível no Amazon Bedrock — permite treinar um modelo pequeno para realizar tarefas complexas com latência e custo significativamente reduzidos.

O processo envolve transferir inteligência de um modelo professor (Amazon Nova Premier, o mais capaz da família) para um modelo aluno (Amazon Nova Micro, otimizado para alta vazão). Essa abordagem reduz custos de inferência em mais de 95% e latência em 50%, mantendo a qualidade de roteamento exigida por sistemas de produção.

Arquitetura da Solução Passo a Passo

1. Preparação de Dados de Treinamento

Uma das principais vantagens da destilação sobre outras técnicas como ajuste fino supervisionado (SFT) é que não requer um conjunto de dados completamente rotulado. No SFT, cada exemplo precisa de respostas geradas por humanos. Na destilação, você precisa apenas de prompts — o Amazon Bedrock invoca automaticamente o modelo professor para gerar respostas de alta qualidade.

A plataforma aplica técnicas de síntese e aumento de dados para produzir um conjunto de treinamento diverso contendo até 15 mil pares prompt-resposta. Para este exemplo, foram preparados 10 mil exemplos sintéticos com o Nova Premier, distribuídos uniformemente entre consultas de sinais visuais, áudio, transcrição e metadados, cobrindo o intervalo completo de entradas esperadas.

Cada registro segue o esquema bedrock-conversation-2024, onde a função usuário (prompt de entrada) é obrigatória e a função assistente (resposta desejada) é opcional. Um exemplo prático:

{
  "schemaVersion": "bedrock-conversation-2024",
  "system": [{
    "text": "Return JSON with visual, audio, transcription, metadata weights (sum=1.0) and reasoning for the given video search query."
  }],
  "messages": [
    {
      "role": "user",
      "content": [{
        "text": "Olivia talking about growing up in poverty"
      }]
    },
    {
      "role": "assistant",
      "content": [{
        "text": "{\"visual\": 0.2, \"audio\": 0.1, \"transcription\": 0.6, \"metadata\": 0.1, \"reasoning\": \"The query focuses on spoken content ('talking about'), making transcription most important. Visual and audio elements are secondary since they support the context, while metadata is minimal.\"}"
      }]
    }
  ]
}

Para adaptar a distribuição a domínios específicos, está disponível um script de geração de dados que permite criar mais exemplos sintéticos usando o Nova Premier.

2. Executando o Trabalho de Destilação

Com os dados de treinamento no Amazon Simple Storage Service (Amazon S3), o próximo passo é submeter o trabalho de destilação. O processo utiliza os prompts para gerar respostas do modelo professor, então usa esses pares para ajustar o modelo aluno. O Amazon Bedrock gerencia toda a orquestração e infraestrutura automaticamente — não há cluster para provisionar, hiperparâmetros para ajustar ou pipelines complexos para configurar.

Você especifica o modelo professor, o modelo aluno, o caminho S3 dos dados e uma função de Controle de Acesso à Identidade (IAM – Identity and Access Management). O resto é gerenciado pela plataforma. Veja um exemplo de código:

import boto3
from datetime import datetime

bedrock_client = boto3.client(service_name="bedrock")

teacher_model = "us.amazon.nova-premier-v1:0"
student_model = "amazon.nova-micro-v1:0:128k"
job_name = f"video-search-distillation-{datetime.now().strftime('%Y-%m-%d-%H-%M-%S')}"
model_name = "nova-micro-video-router-v1"

response = bedrock_client.create_model_customization_job(
    jobName=job_name,
    customModelName=model_name,
    roleArn=distillation_role_arn,
    baseModelIdentifier=student_model,
    customizationType="DISTILLATION",
    trainingDataConfig={"s3Uri": training_s3_uri},
    outputDataConfig={"s3Uri": output_s3_uri},
    customizationConfig={
        "distillationConfig": {
            "teacherModelConfig": {
                "teacherModelIdentifier": teacher_model,
                "maxResponseLengthForInference": 1000
            }
        }
    }
)

job_arn = response['jobArn']

O trabalho executa de forma assíncrona. Para 10 mil exemplos com o Nova Micro, esperase conclusão em poucas horas.

3. Implantando o Modelo Destilado

Após a conclusão, o modelo personalizado fica disponível e pronto para implantação. O Amazon Bedrock oferece duas opções: Throughput Provisionado para cargas de trabalho previsíveis e de alto volume, ou Inferência sob Demanda para acesso flexível com pagamento por uso. Para equipes começando, a inferência sob demanda é a recomendada — sem endpoints para provisionar, sem compromissos horários e sem requisitos de uso mínimo.

Uma vez com status “InService”, o modelo pode ser invocado usando as APIs padrão InvokeModel ou Converse. Você paga apenas pelos tokens consumidos, aos custos do Nova Micro: $0,000035 por 1 mil tokens de entrada e $0,000140 por 1 mil tokens de saída.

import boto3
import json

bedrock_runtime = boto3.client(service_name="bedrock-runtime")

custom_model_arn = bedrock_client.get_model_customization_job(
    jobIdentifier=job_arn
)['outputModelArn']

response = bedrock_runtime.converse(
    modelId=custom_model_arn,
    messages=[
        {
            "role": "user",
            "content": [{"text": query}]
        }
    ]
)

routing_weights = json.loads(
    response['output']['message']['content'][0]['text']
)
print(routing_weights)
# {"visual": 0.7, "audio": 0.1, "transcription": 0.1, "metadata": 0.1}

Avaliação e Resultados

Qualidade de Roteamento

Antes de comparar com o roteador original, é importante validar que a destilação melhorou a capacidade do modelo base. O modelo Nova Micro destilado demonstrou formato JSON consistente com pesos numéricos que somam 1,0, enquanto a versão base produzia respostas em texto livre, JSON incompleto e valores de peso não-numéricos.

Para uma consulta sobre “CEO discutindo resultados trimestrais”, o modelo destilado retornou pesos apropriados com raciocínio específico, enquanto a versão base lutava com inconsistências de formato e lógica genérica.

Comparação com o Baseline Original

Ambos os modelos foram avaliados contra um conjunto de 100 exemplos de teste usando a Avaliação de Modelos do Amazon Bedrock. Foi definida uma rubrica personalizada de “Qualidade Geral” que instrui o Claude Sonnet a avaliar cada predição em duas dimensões: precisão dos pesos comparados à verdade esperada e qualidade do raciocínio.

O modelo Nova Micro destilado alcançou pontuação 4,0 em 5, praticamente idêntica ao Claude 4.5 Haiku mas com latência aproximadamente 50% menor (833ms versus 1.741ms). A vantagem de custo é ainda mais dramática: redução de mais de 95% tanto em tokens de entrada quanto de saída, sem compromissos antecipados.

Resumo comparativo de métricas:

• Pontuação LLM-as-judge: Nova Micro destilado (4,0/5) versus Claude 4.5 Haiku (4,0/5)
• Latência média: Nova Micro destilado (833ms) versus Claude 4.5 Haiku (1.741ms)
• Custo por 1k tokens entrada: Nova Micro destilado ($0,000035) versus Claude 4.5 Haiku ($0,80–$1,00)
• Custo por 1k tokens saída: Nova Micro destilado ($0,000140) versus Claude 4.5 Haiku ($4,00–$5,00)
• Consistência de formato: Nova Micro destilado (JSON consistente) versus Claude 4.5 Haiku (inconsistente)

Implementação Completa e Recursos

Para explorar a implementação completa, incluindo notebook, script de geração de dados de treinamento e utilitários de avaliação, visite o repositório GitHub. Lá você encontrará todos os componentes necessários para replicar a solução em seu ambiente.

Para não gerar cobranças contínuas, execute a seção de limpeza do notebook para remover recursos provisionados, incluindo endpoints de modelo implantados e dados armazenados no Amazon S3.

Conclusão

Este artigo encerra uma série de dois posts. A destilação de modelos oferece um caminho prático para alcançar eficiência de custo em produção sem sacrificar precisão de busca. Ao transferir comportamento de roteamento do Nova Premier para o Nova Micro usando destilação, reduz-se custo de inferência em mais de 95% e latência de pré-processamento pela metade, preservando a qualidade de roteamento necessária.

Para equipes operando busca de vídeo multimodal em larga escala, a destilação de modelos é um caminho consolidado para produção, balanceando inteligência de roteamento com velocidade e custo ao mesmo tempo. Para mergulhar na implementação, consulte o repositório GitHub e experimente a solução.

Fonte

Optimize video semantic search intent with Amazon Nova Model Distillation on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/optimize-video-semantic-search-intent-with-amazon-nova-model-distillation-on-amazon-bedrock/)

Entendendo o Ajuste Fino com Mistura de Dados

O ajuste fino de modelos de linguagem é uma técnica fundamental para empresas que desejam especializar sistemas de IA em seus próprios domínios. No entanto, existe um dilema clássico: ao treinar um modelo apenas com dados do seu negócio, ele pode perder suas capacidades gerais. A AWS abordou este desafio através da técnica de mistura de dados, que blenda informações específicas do domínio com conjuntos de dados curados pela empresa.

Esta é a segunda parte de uma série sobre a Nova Forge SDK. Os artigos anteriores cobriram a introdução ao SDK e os primeiros passos com experimentos de customização. O diferencial desta abordagem está na capacidade de manter o desempenho do modelo em testes de conhecimento geral (como Massive Multitask Language Understanding, MMLU) enquanto melhora significativamente o desempenho em tarefas específicas do negócio.

Em um caso demonstrado pela AWS, a mistura de dados produziu uma melhoria de 12 pontos em F1 em uma tarefa de classificação complexa, mantendo simultaneamente scores MMLU próximos aos do modelo original. Por contraste, o ajuste fino apenas com dados do cliente causou uma queda drástica nas capacidades gerais.

Visão Geral do Fluxo de Trabalho

O processo completo organiza-se em cinco etapas principais:

• Configuração de Ambiente: instalação da SDK e preparação de recursos da AWS
• Preparação de Dados: limpeza, transformação e validação dos dados de treinamento
• Configuração de Treinamento: setup do HyperPod, MLflow e proporções de mistura de dados
• Treinamento do Modelo: execução do ajuste fino com adaptadores de baixo-rank (LoRA)
• Avaliação: testes em benchmarks públicos e avaliações específicas do domínio

Pré-requisitos e Considerações de Custo

Para executar este workflow, você precisará de uma conta AWS com acesso à Amazon Nova Forge, um cluster SageMaker HyperPod provisionado com instâncias GPU (o guia usa instâncias ml.p5.48xlarge, e uma aplicação Amazon SageMaker MLflow para rastreamento de experimentos.

A configuração do cluster HyperPod envolve configurar um cluster Amazon Elastic Kubernetes Service (EKS), provisionar nós de computação e criar papéis de execução. Para instruções detalhadas, consulte a documentação sobre Como Começar com SageMaker HyperPod.

Importante: este guia utiliza 4 instâncias ml.p5.48xlarge para treinamento e avaliação. Recomenda-se começar com um teste curto (por exemplo, max_steps=5) para validar sua configuração antes de se comprometer com um treinamento completo. Consulte a página de preços do Amazon SageMaker para taxas atualizadas.

Preparação de Dados e Sanitização

A Nova Forge SDK aceita formatos JSONL, JSON e CSV. O guia utiliza o dataset MedReason publicamente disponível no Hugging Face, contendo aproximadamente 32.700 pares de pergunta-resposta para demonstrar o ajuste fino em um caso de uso específico do domínio médico.

Um passo crítico é a sanitização de dados. A SDK implementa validação a nível de token, e certos tokens entram em conflito com o template de chat interno do modelo. Strings literais como System: ou Assistant: podem ser interpretadas como delimitadores de turno, corrompendo o sinal de treinamento. O processo de sanitização insere um espaço antes do dois-pontos (por exemplo, System: → System :) para quebrar o padrão, preservando legibilidade, e remove tokens especiais como [EOS] e <image> que possuem significado reservado.

Após o carregamento e limpeza dos dados, a SDK fornece um JSONLDatasetLoader que converte dados brutos no formato esperado pelos modelos Nova. O método transform() envolve cada par pergunta-resposta no template de chat Nova, convertendo:

Antes da transformação (JSONL bruto):

{ "question": "What are the causes of chest pain in a 45-year-old patient?", "answer": "Chest pain in a 45-year-old can result from cardiac causes such as..." }

Depois da transformação (formato template Nova):

{ "messages": [ {"role": "user", "content": "What are the causes of chest pain in a 45-year-old patient?"}, {"role": "assistant", "content": "Chest pain in a 45-year-old can result from cardiac causes such as..."} ] }

O método validate() verifica então se os dados transformados estão corretos, confirmando que a estrutura do template está apropriada, que nenhum token inválido permanece, e que os dados estão em conformidade com os requisitos do modelo e método de treinamento escolhido.

Configuração e Execução do Treinamento

Ao ativar a mistura de dados, a Nova Forge automaticamente blenda seus dados específicos do domínio com conjuntos de dados curados pela AWS durante o ajuste fino. Isso impede que o modelo esqueça suas capacidades gerais enquanto aprende seu domínio.

A AWS oferece dois métodos principais de ajuste fino. O guia utiliza Supervised Fine-Tuning (SFT) com LoRA (Adaptadores de Baixo Rank), que atualiza apenas um pequeno conjunto de pesos do adaptador, resultando em treinamento mais rápido, custos menores de computação e é o ponto de partida recomendado. A AWS também suporta SFT de rank completo, que atualiza todos os parâmetros do modelo e pode incorporar mais conhecimento do domínio, mas exige mais computação e é mais suscetível ao esquecimento catastrófico.

Configuração de Mistura de Dados

A mistura de dados controla como os lotes de treinamento são compostos. O parâmetro customer_data_percent determina que fração de cada lote vem de seus dados de domínio. A fração restante é preenchida por conjuntos de dados curados pela Nova, com cada parâmetro nova_*_percent controlando o peso relativo dessa categoria de capacidade dentro da porção Nova.

Por exemplo, com uma configuração típica: 50% de cada lote de treinamento consiste em seus dados de domínio, e 50% em dados curados pela Nova, distribuídos entre categorias de capacidade conforme seus pesos relativos. Os percentuais no lado Nova devem somar 100.

O post anterior desta série demonstrou que até uma divisão 75/25 de cliente-para-Nova preserva MMLU praticamente no baseline (0,74 versus 0,75 baseline) enquanto entrega uma melhoria de 12 pontos F1 em uma tarefa de classificação complexa.

Parâmetros de Treinamento Principais

Os hiperparâmetros chave permitem controlar o comportamento do treinamento:

• lr (learning rate): 1e-5 é um padrão razoável para ajuste fino com LoRA
• warmup_steps: passos para aumentar gradualmente a taxa de aprendizado, tipicamente 5-10% do total de passos
• global_batch_size: número de exemplos por atualização de gradiente em todas as GPUs
• max_length: comprimento máximo da sequência em tokens; 65.536 suporta casos de uso de contexto longo
• max_steps: passos totais de treinamento; comece pequeno (5-10) para validar seu setup

Monitoramento e Avaliação do Modelo

A avaliação é crítica quando você usa mistura de dados, pois você precisa medir simultaneamente se o modelo melhorou em sua tarefa de domínio e se reteve suas capacidades gerais. Se você medir apenas um eixo, não saberá se a mistura está funcionando.

A Nova Forge suporta três abordagens complementares de avaliação:

Benchmarks Públicos

Estes medem se a mistura de dados está preservando as capacidades gerais. Testes como MMLU (conhecimento amplo e raciocínio em 57 assuntos) e IFEval (capacidade de seguir instruções estruturadas) indicam se sua mistura está sendo efetiva. Se MMLU cair significativamente do baseline, sua mistura precisa de mais dados Nova. Se IFEval cair, aumente o peso de instrução-seguimento.

Dados Próprios (Bring-Your-Own-Data)

Use seu conjunto de teste retido para medir se o ajuste fino melhorou o desempenho em sua tarefa real.

LLM como Juiz

Para domínios onde métricas automatizadas são insuficientes, você pode usar outro LLM para avaliar a qualidade das respostas.

Interpretando Resultados

Use este framework de decisão para guiar sua próxima iteração:

• MMLU próximo do baseline: A mistura de dados está prevenindo esquecimento catastrófico com sucesso. Sua mistura está funcionando — foque em desempenho de domínio.
• MMLU degradado significativamente: O modelo está esquecendo capacidades gerais. Diminua customer_data_percent ou aumente pesos de dados Nova.
• Desempenho de tarefa de domínio abaixo do esperado: O modelo não está aprendendo o suficiente de seus dados. Aumente customer_data_percent, adicione mais dados de treinamento, ou aumente max_steps.
• IFEval degradado: O modelo está perdendo a capacidade de seguir instruções. Aumente nova_instruction-following_percent.
• MMLU e desempenho de tarefa de domínio melhoraram: Resultado ideal. Documente sua configuração e promova para produção.

Melhores Práticas

Comece com as proporções de mistura padrão — elas foram ajustadas para um equilíbrio bem calibrado. Só customize após ter resultados de avaliação de baseline para comparar contra.

Sempre avalie em ambos os eixos. Execute pelo menos um benchmark público (como MMLU) juntamente com sua avaliação específica do domínio. Sem ambas, você não consegue dizer se a mistura está funcionando.

Use MLflow para comparar experimentos. Ao iterar sobre proporções de mistura e hiperparâmetros, MLflow simplifica significativamente a comparação de execuções lado a lado e a identificação da melhor configuração.

Itere sobre a mistura, não apenas hiperparâmetros. Se seu modelo está esquecendo capacidades gerais, ajustar a mistura de dados é frequentemente mais efetivo do que tunar taxa de aprendizado ou tamanho de lote.

Comece com LoRA e mude para rank completo se necessário. LoRA é mais rápido e barato. Só mude para SFT de rank completo se LoRA não atingir adaptação de domínio suficiente para seu caso de uso.

Próximos Passos

Para começar, consulte a Nova Forge Developer Guide para documentação detalhada e explore a Nova Forge SDK para referência completa da API.

O fluxo de trabalho descrito fornece um playbook repetível que você pode adaptar ao seu caso de uso específico. A mistura de dados é o que torna o ajuste fino prático para produção — em vez de escolher entre expertise de domínio e inteligência geral, você obtém ambas. A chave é tratar isso como um processo iterativo: treina, avalia em ambos os eixos, ajusta a mistura, e repete até encontrar o equilíbrio certo.

Fonte

Nova Forge SDK series part 2: Practical guide to fine-tune Nova models using data mixing capabilities (https://aws.amazon.com/blogs/machine-learning/nova-forge-sdk-series-part-2-practical-guide-to-fine-tune-nova-models-using-data-mixing-capabilities/)

Novo Recurso de Flexibilidade no SageMaker HyperPod

A AWS anunciou suporte a grupos de instâncias flexíveis no Amazon SageMaker HyperPod, um avanço significativo para clientes que precisam executar cargas de trabalho de treinamento e inferência em ambientes com requisitos complexos de infraestrutura. Esse novo recurso permite especificar múltiplos tipos de instância e múltiplas subnets dentro de um único grupo de instâncias, simplificando a gestão de clusters heterogêneos.

O Desafio Anterior

Clientes que utilizam o HyperPod frequentemente necessitam distribuir suas workloads através de múltiplos tipos de instância e zonas de disponibilidade. Isso ocorre por três razões principais: resiliência de capacidade, otimização de custos e melhor aproveitamento de subnets. Até agora, esse cenário exigia que os usuários criassem e gerenciassem um grupo de instâncias separado para cada combinação de tipo de instância e zona de disponibilidade.

Essa abordagem gerava sobrecarga operacional considerável. Os times precisavam lidar com complexidade adicional em configuração de cluster, escalabilidade, aplicação de patches e monitoramento — tudo multiplicado pelo número de combinações de instâncias necessárias.

Como os Grupos Flexíveis Resolvem o Problema

Com os grupos de instâncias flexíveis, a configuração muda radicalmente. Os usuários podem agora definir uma lista ordenada de tipos de instância usando o novo parâmetro InstanceRequirements e fornecer múltiplas subnets distribuídas entre zonas de disponibilidade em um único grupo de instâncias.

O HyperPod provisiona instâncias começando pelo tipo de maior prioridade e executa um fallback automático para tipos de menor prioridade quando a capacidade não está disponível. Isso elimina a necessidade de clientes tentarem manualmente diferentes grupos de instâncias quando uma opção não está disponível.

Benefícios por Caso de Uso

Para Cargas de Treinamento

Clientes de treinamento se beneficiam da distribuição entre múltiplas subnets dentro de uma mesma zona de disponibilidade, evitando esgotamento de endereços IP em uma subnet individual — um problema comum em ambientes de larga escala.

Para Cargas de Inferência

Clientes que fazem escalabilidade manual ganham fallback automático baseado em prioridade entre tipos de instância, sem precisar retentar cada grupo individualmente. Aqueles que utilizam Karpenter para autoscaling podem fazer referência a um único grupo de instâncias flexível. O Karpenter detecta automaticamente os tipos de instância suportados a partir do grupo flexível e provisiona o tipo e zona de disponibilidade ótima com base nos requisitos do pod.

Como Usar

Os grupos de instâncias flexíveis podem ser criados através das APIs CreateCluster e UpdateCluster, via AWS CLI, ou através do AWS Management Console. Esse recurso está disponível para clusters SageMaker HyperPod utilizando o orquestrador EKS (Elastic Kubernetes Service) em todas as regiões AWS onde SageMaker HyperPod é suportado.

Para detalhes técnicos completos e instruções de implementação, consulte a documentação sobre grupos de instâncias flexíveis.

Fonte

Amazon SageMaker HyperPod now supports flexible instance groups (https://aws.amazon.com/about-aws/whats-new/2026/04/sagemaker-hyperpod-flexible-instance-groups/)

Expansão geográfica do FSx for Lustre Persistent-2

A AWS anunciou em abril de 2026 a expansão do Amazon FSx for Lustre Persistent-2 para quatro novas regiões. O serviço de sistemas de arquivos agora está disponível em regiões estratégicas que ampliam o alcance global da plataforma: Asia Pacific (Hyderabad e Jakarta), Europe (Zurich) e South America (São Paulo).

Para os usuários brasileiros, esta é uma notícia particularmente relevante, já que a região de São Paulo agora oferece suporte nativo ao Amazon FSx for Lustre Persistent-2, reduzindo latência e melhorando a conformidade com requisitos de residência de dados.

Características técnicas e melhorias

A geração Persistent-2 foi desenvolvida com base em AWS Graviton processors, trazendo melhorias significativas em relação às versões anteriores:

• Throughput aprimorado: até 1 GB/s por terabyte, oferecendo maior performance por unidade de armazenamento
• Redução de custos: menor custo de throughput em comparação com gerações anteriores do FSx for Lustre
• Otimização de arquitetura: aproveitamento da eficiência dos processadores Graviton para operações de I/O intensivas

Casos de uso beneficiados

O Amazon FSx for Lustre Persistent-2 é especialmente adequado para workloads exigentes que requerem performance de armazenamento elevada:

• Machine Learning: treinamento de modelos com acesso rápido a grandes volumes de dados
• Computação de alto desempenho (HPC): simulações científicas e de engenharia
• Media & Entertainment: processamento e renderização de conteúdo de mídia
• Simulações financeiras: análise de risco e modelagem quantitativa que exigem throughput consistente

Ao utilizar estes sistemas de arquivos, organizações conseguem acelerar a execução de suas cargas de trabalho enquanto reduzem o custo total de armazenamento e throughput.

Como começar

Os usuários interessados em aproveitar o Amazon FSx for Lustre Persistent-2 nas novas regiões podem iniciar criando um sistema de arquivos através da AWS Management Console.

Para informações técnicas detalhadas sobre o serviço, a AWS disponibiliza documentação completa na página do produto Amazon FSx for Lustre. Além disso, a Tabela de Regiões AWS oferece uma visão completa sobre a disponibilidade regional de todos os serviços.

Implicações para o mercado brasileiro

A chegada do FSx for Lustre Persistent-2 à região de São Paulo representa um passo importante para empresas brasileiras que trabalham com cargas de trabalho de data science, simulação computacional e processamento de mídia. A redução de latência, aliada à conformidade com residência de dados, pode impulsionar a adoção de soluções de machine learning e HPC no país.

Fonte

Amazon FSx for Lustre Persistent-2 file systems are now available in four additional AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-fsx-lustre-persistent-2-aws/)

O desafio da geração de texto para SQL em aplicações empresariais

A conversão de linguagem natural para consultas SQL permanece como um dos desafios mais complexos em aplicações de inteligência artificial empresarial, especialmente quando envolvem dialetos SQL customizados ou esquemas de banco de dados específicos de cada domínio. Embora os modelos de fundação (FMs) demonstrem um desempenho sólido com SQL padrão, alcançar precisão adequada para produção com dialetos especializados exige ajustes finos no modelo.

Acontece que o ajuste fino introduz uma questão operacional delicada: manter modelos customizados em infraestrutura persistente gera custos contínuos, mesmo durante períodos sem qualquer utilização. A Amazon Bedrock oferece uma alternativa através de inferência sob demanda com modelos Amazon Nova Micro ajustados. Ao combinar a eficiência do ajuste fino LoRA (Adaptação de Rank Baixo) com inferência serverless baseada em tokens pagos, as organizações conseguem implementar capacidades de texto para SQL customizadas sem os custos adicionais de hospedagem em modelo persistente.

Este artigo apresenta duas abordagens práticas para ajuste fino do Amazon Nova Micro, visando à geração de dialetos SQL customizados, entregando tanto eficiência de custos quanto desempenho pronto para produção. No exemplo de carga de trabalho demonstrado, manteve-se um custo mensal de apenas USD 0,80 com aproximadamente 22.000 consultas por mês — economias significativas se comparadas a infraestrutura de modelo hospedado permanentemente.

Preparação do ambiente e visão geral da solução

Pré-requisitos

Para implantar essas soluções, você precisará de:

• Uma conta AWS com faturamento habilitado
• Permissões padrão de IAM e papel configurados para acessar Amazon Bedrock, modelo Nova Micro, Amazon SageMaker AI e customização de modelo em Bedrock
• Cota para instância ml.g5.48xl no Amazon SageMaker AI para treinamento

Arquitetura geral

A solução segue uma sequência lógica de etapas:

• Preparar dataset de treinamento SQL customizado com pares entrada-saída específicos do dialeto SQL e requisitos de negócio da sua organização
• Iniciar o processo de ajuste fino no modelo Amazon Nova Micro usando o dataset preparado
• Escolher entre duas abordagens: customização de modelo gerenciada via Amazon Bedrock ou treinamento granular com Amazon SageMaker AI
• Implantar o modelo customizado na Bedrock para usar inferência sob demanda, eliminando gerenciamento de infraestrutura e pagando apenas pelo uso de tokens
• Validar desempenho do modelo com consultas de teste específicas para seu dialeto SQL e casos de uso

Preparação do dataset

A demonstração utiliza o dataset sql-create-context, uma combinação curada de WikiSQL e datasets Spider contendo mais de 78 mil exemplos de perguntas em linguagem natural emparelhadas com consultas SQL em diversos esquemas de banco de dados. Esse dataset oferece uma base ideal para ajuste fino de texto para SQL devido à sua variedade em complexidade de consultas, desde simples instruções SELECT até joins multi-tabela complexos com agregações.

Formatação e estrutura dos dados

Os dados de treinamento são estruturados conforme descrito na documentação. Isso envolve criar arquivos JSONL contendo instruções de prompt do sistema emparelhadas com consultas do usuário e respostas SQL correspondentes de complexidade variada. O dataset de treinamento formatado é então dividido em conjuntos de treinamento e validação, armazenado como arquivos JSONL e carregado no Amazon Simple Storage Service (Amazon S3) para o processo de ajuste fino.

Um exemplo de registro convertido segue o padrão bedrock-conversation-2024:

{ "schemaVersion": "bedrock-conversation-2024", "system": [ { "text": "You are a powerful text-to-SQL model. Your job is to answer questions about a database. You can use the following table schema for context: CREATE TABLE head (age INTEGER)" } ], "messages": [ { "role": "user", "content": [ { "text": "Return the SQL query that answers the following question: How many heads of the departments are older than 56 ?" } ] }, { "role": "assistant", "content": [ { "text": "SELECT COUNT(*) FROM head WHERE age > 56" } ] } ] }

Abordagem 1: Ajuste fino gerenciado via Amazon Bedrock

A customização de modelo via Amazon Bedrock oferece uma abordagem totalmente gerenciada e simplificada para ajuste fino de modelos Amazon Nova sem necessidade de provisionar ou gerenciar infraestrutura de treinamento. Esse método é ideal para equipes que buscam iteração rápida e complexidade operacional mínima enquanto alcançam desempenho de modelo customizado adequado para seus casos de uso de texto para SQL.

Usando as capacidades de customização da Bedrock, os dados de treinamento são carregados no S3, e os trabalhos de ajuste fino são configurados através do console AWS ou API. A AWS então gerencia toda a infraestrutura de treinamento subjacente. O modelo customizado resultante pode ser implantado usando inferência sob demanda, mantendo o mesmo preço baseado em tokens do modelo Nova Micro base sem markup adicional — tornando-se uma solução econômica para cargas de trabalho variáveis.

Criando um trabalho de ajuste fino

A Amazon Bedrock suporta ajuste fino tanto via Console AWS quanto via AWS SDK para Python (Boto3). A documentação AWS contém orientação geral sobre como enviar um trabalho de treinamento com ambas as abordagens. Você pode consultar o notebook de exemplo em nosso repositório GitHub para ver a implementação passo a passo.

Configuração de hiperparâmetros

Após selecionar o modelo a ajustar, você configura os hiperparâmetros para seu caso de uso. Para ajuste fino do Amazon Nova Micro na Bedrock, você pode customizar os seguintes hiperparâmetros para otimizar seu modelo de texto para SQL:

• Epochs (1–5): Número de passagens completas pelo dataset de treinamento — utilizamos 5 epochs
• Batch Size (fixo em 1): Número de amostras processadas antes de atualizar os pesos do modelo
• Learning Rate (0.000001–0.0001): Tamanho do passo para otimização de gradiente descendente — utilizamos 0.00001 para convergência estável
• Learning Rate Warmup Steps (0–100): Número de passos para aumentar gradualmente a taxa de aprendizado — utilizamos 10

No dataset de exemplo, essa configuração proporcionou um equilíbrio melhorado entre precisão do modelo e tempo de treinamento, completando em aproximadamente 2-3 horas.

Análise de métricas de treinamento

A Bedrock gera automaticamente métricas de treinamento e validação, armazenadas em seu local de saída especificado no S3. Essas métricas incluem perda de treinamento (como o modelo se ajusta aos dados de treinamento) e perda de validação (indicador de desempenho de generalização em dados não vistos). As curvas de perda de treinamento e validação demonstram treinamento bem-sucedido: ambas decrescem consistentemente, seguem padrões similares e convergem para valores finais comparáveis.

Implantação com inferência sob demanda

Após concluir com sucesso o trabalho de ajuste fino, você pode implantar seu modelo Nova Micro customizado usando inferência sob demanda. Essa opção de implantação oferece escalabilidade automática e preço por token, tornando-a ideal para cargas de trabalho variáveis sem necessidade de provisionar recursos computacionais dedicados.

Após a implantação, você invoca seu modelo customizado usando o ARN de implantação como ID do modelo na API Converse da Amazon Bedrock:

# Use the deployment ARN as the model ID
deployment_arn = "arn:aws:bedrock:us-east-1::deployment/"

# Prepare the inference request
response = bedrock_runtime.converse(
    modelId=deployment_arn,
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "text": """Database schema: CREATE TABLE sales ( id INT, product_name VARCHAR(100), category VARCHAR(50), revenue DECIMAL(10,2), sale_date DATE ); Question: What are the top 5 products by revenue in the Electronics category?"""
                }
            ]
        }
    ],
    inferenceConfig={
        "maxTokens": 512,
        "temperature": 0.1,  # Low temperature for deterministic SQL generation
        "topP": 0.9
    }
)

# Extract the generated SQL query
sql_query = response['output']['message']['content'][0]['text']
print(f"Generated SQL: {sql_query}")

Abordagem 2: Ajuste fino com Amazon SageMaker AI

Enquanto a abordagem Bedrock simplifica a customização de modelo através de uma experiência de treinamento gerenciada, organizações que buscam controle de otimização mais profundo podem se beneficiar da abordagem SageMaker AI. O Amazon SageMaker AI oferece controle extenso sobre parâmetros de treinamento que impactam significativamente a eficiência e desempenho do modelo.

Você pode ajustar o tamanho do lote para otimização de velocidade e memória, ajustar regularização dropout nas camadas para prevenir sobreajuste, e configurar cronogramas de taxa de aprendizado para estabilidade de treinamento. Para ajuste fino LoRA especificamente, você pode customizar fatores de escala e parâmetros de regularização com diferentes configurações otimizadas para datasets multimodais versus apenas texto.

Preparação de dados e carregamento

O processo de preparação e carregamento de dados para a abordagem SageMaker AI é idêntico à implementação Bedrock. Ambas as abordagens convertem o dataset SQL para o formato de schema bedrock-conversation-2024, dividem os dados em conjuntos de treinamento e teste, e carregam os arquivos JSONL diretamente no S3:

# S3 prefix for training data
training_input_path = f's3://{sess.default_bucket()}/datasets/nova-sql-context'

# Upload datasets to S3
train_s3_path = sess.upload_data(
    path='data/train_dataset.jsonl',
    bucket=bucket_name,
    key_prefix=training_input_path
)
test_s3_path = sess.upload_data(
    path='data/test_dataset.jsonl',
    bucket=bucket_name,
    key_prefix=training_input_path
)

print(f'Training data uploaded to: {train_s3_path}')
print(f'Test data uploaded to: {test_s3_path}')

Criando um trabalho de ajuste fino com SageMaker AI

Você seleciona o ID do modelo, a receita de treinamento e a URI de imagem:

# Nova configuration
model_id = "nova-micro/prod"
recipe = "https://raw.githubusercontent.com/aws/sagemaker-hyperpod-recipes/refs/heads/main/recipes_collection/recipes/fine-tuning/nova/nova_1_0/nova_micro/SFT/nova_micro_1_0_g5_g6_48x_gpu_lora_sft.yaml"
instance_type = "ml.g5.48xlarge"
instance_count = 1

# Nova-specific image URI
image_uri = f"708977205387.dkr.ecr.{sess.boto_region_name}.amazonaws.com/nova-fine-tune-repo:SM-TJ-SFT-latest"

print(f'Model ID: {model_id}')
print(f'Recipe: {recipe}')
print(f'Instance type: {instance_type}')
print(f'Instance count: {instance_count}')
print(f'Image URI: {image_uri}')

Receitas customizadas de treinamento

Um diferencial importante ao usar Amazon SageMaker AI para ajuste fino de modelo Nova é a capacidade de customizar uma receita de treinamento. As receitas são pilhas de treinamento pré-configuradas fornecidas pela AWS para ajudá-lo a iniciar rapidamente. Enquanto mantêm compatibilidade com o conjunto padrão de hiperparâmetros da Bedrock (epochs, tamanho do lote, taxa de aprendizado e warmup steps), as receitas estendem as opções de hiperparâmetros através de:

• Parâmetros de regularização: hidden_dropout, attention_dropout, ffn_dropout para prevenir sobreajuste
• Configurações de otimizador: Coeficientes beta customizáveis e configurações de weight decay
• Controles de arquitetura: Rank de adaptador e fatores de escala para treinamento LoRA
• Agendamento avançado: Cronogramas customizados de taxa de aprendizado e estratégias de warmup

Você pode consultar a receita completa que foi utilizada. Para o trabalho de treinamento SageMaker AI neste exemplo, foram usados parâmetros de receita padrão incluindo 2 epochs e tamanho de lote de 64. Com dados contendo 20 mil linhas, o trabalho de treinamento completo durou 4 horas usando a instância ml.g5.48xlarge, com custo total de USD 65 para ajuste fino do modelo Nova Micro.

Testes e avaliação de desempenho

A avaliação do modelo abrangeu testes tanto operacionais quanto de precisão. Para avaliar a precisão, implementou-se uma abordagem “LLM-as-a-Judge” onde coletaram-se perguntas e respostas SQL do modelo ajustado fino, usando um modelo juiz para pontuação comparada às respostas corretas (ground truth).

Para testes operacionais, coletaram-se métricas incluindo TTFT (Tempo para Primeiro Token) e OTPS (Tokens de Saída por Segundo). Comparado ao modelo Nova Micro base, experimentou-se tempo de início frio até primeiro token em média de 639 ms em 5 execuções — um aumento de 34%. Esse aumento de latência provém da aplicação de adaptadores LoRA no tempo de inferência em vez de incorporá-los aos pesos do modelo. Contudo, essa escolha arquitetural entrega benefícios substanciais de custo, já que o modelo Nova Micro ajustado custa o mesmo que o modelo base, permitindo preço sob demanda com flexibilidade de pagamento por uso e sem compromissos mínimos.

Durante operação normal, o tempo até primeiro token em média é de 380 ms em 50 chamadas — um aumento de apenas 7%. A latência end-to-end total é aproximadamente 477 ms para geração completa de resposta. A geração de tokens mantém uma taxa de aproximadamente 183 tokens por segundo, representando apenas 27% de diminuição do modelo base, mantendo-se altamente adequada para aplicações interativas.

Análise de custos

Custos únicos (one-time):

• Treinamento de modelo Amazon Bedrock: USD 0,001 por 1 mil tokens × número de epochs. Para 2 mil exemplos, 5 epochs e aproximadamente 800 tokens cada = USD 8,00
• Treinamento de modelo SageMaker AI: Instância ml.g5.48xlarge custa USD 16,288/hora. Treinamento de 4 horas com dataset de 20 mil linhas = USD 65,15

Custos contínuos (ongoing):

• Armazenamento: USD 1,95 por mês por modelo customizado
• Inferência sob demanda: Mesmo preço por token do Nova Micro base
  • Tokens de entrada: USD 0,000035 por mil tokens
  • Tokens de saída: USD 0,00014 por mil tokens

Exemplo de cálculo para carga de trabalho em produção:

Para 22 mil consultas por mês (100 usuários × 10 consultas/dia × 22 dias úteis), com média de 800 tokens de entrada + 60 tokens de saída por consulta:

• Custo de entrada: (22.000 × 800 / 1.000) × 0,000035 = USD 0,616
• Custo de saída: (22.000 × 60 / 1.000) × 0,00014 = USD 0,184
• Custo mensal total de inferência: USD 0,80

Essa análise valida que, para casos de uso customizados de texto para SQL, ajuste fino de modelo Nova usando PEFT LoRA na Amazon Bedrock é significativamente mais econômico que auto-hospedagem de modelos customizados em infraestrutura persistente. Abordagens auto-hospedadas podem ser adequadas para casos que requerem máximo controle sobre infraestrutura, configurações de segurança ou requisitos de integração. Mas o modelo de custo sob demanda da Amazon Bedrock oferece economias significativas para a maioria das cargas de trabalho de texto para SQL em produção.

Escolhendo a abordagem adequada

Ambas as implementações compartilham o mesmo modelo de implantação serverless e preço sob demanda, permitindo que você escolha baseado na expertise e requisitos da sua equipe, não em restrições de custo.

Escolha customização de modelo Amazon Bedrock quando:

• Você precisa de iteração rápida, possui expertise limitada em infraestrutura ML, ou deseja minimizar complexidade operacional enquanto alcança desempenho de modelo customizado

Escolha treinamento SageMaker AI quando:

• Você requer controle fino sobre parâmetros, possui requisitos específicos de infraestrutura ou conformidade, precisa integrar com pipelines MLOps existentes, ou quer otimizar cada aspecto do processo de treinamento

Começando

Pronto para construir sua própria solução de texto para SQL econômica? Acesse nossas implementações completas:

• Notebook de Ajuste Fino Bedrock: Abordagem gerenciada e simplificada
• Notebook de Ajuste Fino SageMaker AI: Customização avançada e controle

Ambas as abordagens usam o mesmo modelo de implantação econômico, então você pode escolher baseado na expertise da sua equipe e requisitos, em vez de restrições de custo.

Fonte

Cost-efficient custom text-to-SQL using Amazon Nova Micro and Amazon Bedrock on-demand inference (https://aws.amazon.com/blogs/machine-learning/cost-efficient-custom-text-to-sql-using-amazon-nova-micro-and-amazon-bedrock-on-demand-inference/)