Introdução: O Desafio Real da IA Autônoma

Este é o segundo artigo de uma série em duas partes publicada pelo Centro de Inovação em IA Generativa da AWS. Se você perdeu a primeira parte sobre a operacionalização de IA autônoma, vale a pena revisitar aquele conteúdo para compreender os fundamentos.

A barreira mais importante para a adoção de IA autônoma nas empresas não é tecnológica — é organizacional. Na primeira parte desta série, estabeleceu-se que organizações que geram valor real com agentes de IA compartilham três características: definem o trabalho com precisão, estabelecem limites claros para a autonomia, e tratam a melhoria contínua como um hábito permanente, não como um projeto pontual.

Também foram apresentados os quatro ingredientes essenciais para um trabalho verdadeiramente adequado aos agentes: um início e fim bem definidos, exigência de julgamento sobre múltiplas ferramentas, sucesso observável e mensurável, e um modo de falha seguro. Sem esses fundamentos, até o agente mais sofisticado será um fracasso em produção.

Agora vem a pergunta mais difícil: quem faz isso funcionar, e como? Este artigo fala diretamente com os líderes que precisam transformar essa base compartilhada em ação concreta. Cada função executiva traz um conjunto distinto de responsabilidades, riscos e pontos de alavancagem. Independentemente de você gerenciar um centro de lucro, conduzir arquitetura empresarial, liderar segurança, governar dados ou supervisionar conformidade — este texto é escrito na linguagem do seu trabalho. É exatamente nessas funções que a IA autônoma prospera ou desaparece silenciosamente.

Orientação por Persona: Papéis e Responsabilidades

Para o Dono do Negócio: Conecte o Agente aos seus KPIs

Se você é responsável por um centro de lucro, não precisa de um brinquedo tecnológico novo. O que você realmente precisa é reduzir o número de tickets abertos, diminuir os dias do seu ciclo de conversão de caixa, reduzir carrinhos de compras abandonados, diminuir exceções de conformidade. Um agente é útil apenas quando pode ser conectado diretamente a esses números.

O primeiro passo é escrever uma descrição de trabalho para o agente da mesma forma que você faria para um novo funcionário. Algo como: “Este agente recebe uma entrada de tipo X, verifica Y, executa Z e encaminha para essa equipe quando termina.” Inclua o que significa “terminar” em termos operacionais: tempo de resposta, limiar de qualidade, gatilhos de escalação, e compromissos voltados para o cliente.

O segundo passo é fundamentar o caso de negócio nos números que sua equipe já acompanha. Quantas unidades por semana passam por esse fluxo de trabalho? Qual é o custo unitário em mão de obra, retrabalho e perdas? Quanto tempo fica aguardando em filas? Com que frequência retorna porque falta algo ou está errado? Se você não consegue responder essas perguntas hoje, seu primeiro projeto não é um agente — é instrumentalizar o fluxo de trabalho.

O terceiro passo é a sequência de implementação. No início da jornada, o agente mais útil é frequentemente aquele que elimina transferências manuais: lê a solicitação de entrada, coleta contexto de múltiplos sistemas, propõe um plano, e entrega esse plano à sua equipe com tudo pré-preparado. Pode não fechar a solução sozinho, mas remove horas ou dias de ida e volta entre equipes. Ganhos de economia como este constroem credibilidade com o CFO e lhe dão capital político para perseguir casos de uso mais ambiciosos, focados em receita, depois.

O dono do negócio não precisa entender modelos ou prompts. Precisa possuir um pequeno portfólio de trabalhos de agentes conectados diretamente às suas métricas e insistir que cada iniciativa comece com um contrato de trabalho escrito, não com um slide com um rótulo bonito.

Para o CTO ou Arquiteto Chefe: Decida se Quer Dez ou Cem Agentes

Se você é CTO, um dos seus maiores riscos é o sucesso. Assim que o primeiro agente funciona bem, outras equipes vão querer um. Se cada equipe constrói seu próprio stack — framework próprio, conectores próprios, modelo de acesso próprio — você acabará com um zoológico de agentes que parecem diferentes, são testados diferentemente, e são impossíveis de monitorar como um todo.

A questão arquitetural é simples de enunciar, mas difícil de executar: você quer dez agentes impressionantes pontuais, ou quer um sistema que suporte com segurança cem agentes?

O caminho sistêmico exige trabalho árduo no início. Significa padronizar como as ferramentas são expostas para que cada agente chame a mesma integração quando precisa ler dados de clientes, atualizar um ticket, ou processar um pagamento. Significa separar pensamento de ação no seu design: um componente planeja, outro chama ferramentas, outro valida conformidade, outro explica decisões aos usuários. Significa capturar rastreamentos de decisões em um formato consistente para que observabilidade e debug funcionem entre casos de uso. E exige pensar em agentes como serviços de longa duração, não scripts de curta vida. Precisam de identidades, permissões, rotação de credenciais, gestão de ciclo de vida, e uma forma de serem atualizados sem quebrar seus consumidores.

É mais trabalho no dia um, mas é o que permite você dizer “sim” à décima equipe que quer um agente sem começar do zero. O trabalho do CTO não é escolher o melhor framework de agentes no vácuo. É construir um piso robusto — identidade, execução de políticas, logging, conectores, e ganchos de avaliação — que permita muitas equipes entregar agentes com segurança, rapidez e consistência.

Para o CISO: Trate Agentes como Colegas, Não como Código

Se você é responsável por segurança, está acostumado a pensar em ativos: sistemas, repositórios de dados, credenciais. Agentes adicionam algo novo ao seu modelo de ameaça: entidades autorizadas que podem tomar decisões e executar ações à velocidade da máquina. O erro é tratar agentes como apenas outra aplicação. Eles são mais parecidos com colegas. Têm contas. Têm papéis. Têm ferramentas que podem usar. Podem cometer erros. Podem ser mal configurados.

A abordagem prática é configurar identidades não-humanas para agentes com a mesma seriedade que você aplica a identidades humanas. Cada agente deve ter suas próprias credenciais, suas próprias permissões, e seu próprio rastro de auditoria. Não deve herdar todos os direitos da conta de serviço na qual acaba sendo executado. Quando um agente lê dados sensíveis ou chama uma ferramenta de alto risco, isso deve ser visível em seus logs de forma que sua equipe reconheça.

Você também vai querer formas de parar agentes de forma limpa. Isso significa interruptores de emergência que realmente funcionam, não apenas uma linha em um documento de design. Significa políticas que dizem “Esta classe de ação sempre exige aprovação humana” e as impõe no nível da ferramenta, não apenas no prompt do agente. Significa observar comportamentos que se desviam: um agente que de repente chama uma ferramenta muito mais vezes que o usual, ou começa a ler dados que não precisava antes.

CISOs que se adaptam bem à IA autônoma não tentam bloquear autonomia inteiramente. Definem onde a autonomia é aceitável, que evidências são necessárias para confiar nela, e o que acontece quando essa confiança é quebrada. Participam da conversa de design cedo e fazem política parte da forma do agente, não uma porta de entrada no final.

Para o Diretor de Dados: Torne os Dados Mundanos

Agentes amplificam qualquer base de dados que você já possui. Se seus dados são fragmentados, desatualizados e mal documentados, agentes podem tornar esses problemas visíveis para todos rapidamente. Se seus dados são consistentes, bem governados e simples de entender, agentes podem multiplicar seu valor.

O trabalho do CDO na era dos agentes é tornar os dados mundanos, da melhor forma possível. Significa que quando um agente pergunta “mostre-me todos os sinistros abertos acima desse limite”, ele recebe uma resposta consistente independentemente de qual região ou linha de negócio está operando. Significa que existe uma única definição de “pontuação de saúde do cliente” e é documentada bem o suficiente para que pessoas e agentes a usem. Significa que a linhagem é clara: quando algo dá errado, você consegue rastrear a decisão através das métricas, através das features, até o sistema de origem.

Também significa ser realista sobre prontidão. Alguns fluxos de trabalho simplesmente não estão prontos para decisões autônomas porque os dados nos quais dependem são muito incompletos ou contraditórios. Os melhores CDOs abraçam isso. Não dizem “não conseguimos suportar agentes.” Dizem “conseguimos suportar essa classe de trabalho hoje. Se quer automatizar aquela outra classe, aqui estão as melhorias de dados que precisamos primeiro.”

Uma das contribuições mais valiosas que um CDO pode dar à conversa sobre agentes é um mapa: quais domínios têm dados em qualidade de produção, quais estão em progresso, e onde estão as armadilhas. Esse mapa ajuda todos os outros a escolherem seus primeiros trabalhos com sabedoria, em vez de descobrir débito técnico de dados no meio da implementação.

Para o Chefe de Ciência de Dados ou IA: Avaliação é seu Produto Real

Se você lidera ciência de dados ou IA, é tentador focar em modelos: qual modelo fundacional, qual técnica de fine-tuning, qual pontuação em benchmarks. Essas decisões importam, mas em produção, seu produto real é o sistema de avaliação que envolve o modelo. Agentes podem falhar de formas que benchmarks não medem. Ficam presos em loops. Chamam ferramentas incorretamente. Completam tarefas parcialmente de forma que parecem plausíveis mas estão erradas. Se comportam bem em dados de teste limpos e desabam em casos extremos que ninguém pensou em incluir.

Um sistema de avaliação efetivo faz três coisas. Primeiro, transforma trabalho real em testes. Quando um agente comete um erro em produção, esse cenário se torna parte de uma suíte de avaliação crescente. Com o tempo, os casos mais difíceis que você encontra se tornam guardrails que protegem você de regressões. Segundo, executa automaticamente. Mudanças em prompts, modelos, ferramentas, ou índices de recuperação desencadeiam avaliação antes dessa mudança ir para produção. Isso lhe dá confiança para iterar rapidamente, porque você não está contando com alguns testes pontuais e esperança. Terceiro, mede o que o negócio se importa. Isso inclui métricas técnicas como latência e taxa de sucesso das ferramentas, mas também taxa de conclusão de tarefas, taxa de escalação, custo por decisão, e a parcela de trabalho onde humanos aceitam a recomendação do agente como está.

Quando esses números são visíveis e melhorando, a confiança segue. Equipes que investem aqui cedo descobrem que escolhas de modelos ficam mais simples, não mais difíceis. Uma vez que você pode ver como um modelo se comporta em suas tarefas reais, o debate “qual modelo é melhor?” se torna uma comparação fundamentada em vez de uma discussão filosófica.

Para o Oficial de Conformidade ou Legal: Projete para Auditorias Antes de Enfrentá-las

Se você é responsável por conformidade ou risco legal, IA autônoma provavelmente parece um alvo móvel. Regulações estão evoluindo, e marketing de fornecedores está à frente da clareza regulatória. Você não pode congelar a organização até cada padrão se estabelecer, mas também não pode tolerar “vamos resolver a governança depois.”

Uma abordagem pragmática é trabalhar para trás a partir de uma auditoria. Imagine um regulador ou comitê de auditoria interna perguntando “nessa data, por que esse agente tomou essa ação?” Decida agora que evidências você precisaria para responder essa pergunta claramente e rapidamente. Isso implica algumas escolhas de design. Cada agente deve deixar um rastro: que inputs viu, que ferramentas chamou, que opções considerou, o que escolheu, e que regras aplicou. Para domínios de alto risco como decisões de crédito, subscrição de seguros, e ações relacionadas a emprego, humanos devem permanecer no loop, e o papel do agente deve ser consultivo ou preparatório: coletando dados, organizando evidências, propondo ações. A aprovação do humano se torna parte do registro.

Também implica que nem toda ideia de agente é permitida. Alguns casos de uso vivem solidamente dentro de zonas de risco regulatório até que frameworks e controles amadureçam. Seu trabalho é tornar essas linhas visíveis cedo. Quando você consegue dizer “sim” a alguns agentes com condições claras, “sim depois” a outros com pré-requisitos específicos, e “não” a alguns poucos com lógica clara, você pode se tornar um facilitador em vez de um bloqueador.

Uma das coisas mais úteis que você pode fazer para o resto da equipe de liderança é transformar preocupações abstratas como “precisamos de IA responsável” em uma checklist concreta que pode ser aplicada a cada agente proposto antes do trabalho começar.

Cinco Movimentos para Começar

Se os padrões neste artigo soam familiares, você não está atrasado. Você está onde a maioria das empresas está. O que separa quem avança é a decisão de tratar IA autônoma como um desafio de modelo operacional, não como um experimento tecnológico.

Convoque a sala certa. Reúna seu dono de linha de negócio, CTO, CISO, CDO, líder de IA/Ciência de Dados, e responsável de conformidade — não para uma demonstração, mas para uma sessão de trabalho. Cada pessoa responde uma pergunta: “Qual é a única coisa mais importante bloqueando a gente de colocar um agente em produção em um fluxo de trabalho real?” A partir daí, identifique padrões. Alinhe sobre prioridades comuns.

Escolha um trabalho, não um caso de uso. Identifique uma peça de trabalho concreta com início claro, fim claro, ferramentas definidas, e medida de sucesso que alguém fora da equipe pode verificar. Escreva a descrição de trabalho do agente juntos. Se a sala não conseguir concordar no que significa “concluído”, encontrou o primeiro problema a resolver.

Desenhe seu mapa de prontidão. Tenha seu CDO e CISO esboçar conjuntamente quais domínios de dados e sistemas estão prontos para decisões autônomas hoje, quais precisam de melhorias primeiro, e onde estão as fronteiras rígidas. Esse mapa de uma página pode economizar meses de esforço desperdiçado.

Comprometa-se com uma cadência. Configure uma revisão recorrente semanal ou quinzenal onde a equipe multifuncional examina como o agente se comportou, o que funcionou, o que quebrou, e o que ajustar. Se você só avalia no lançamento, está construindo uma demonstração. Se avalia continuamente, está construindo uma capacidade.

Faça da governança uma entrada de design, não uma porta de lançamento. Decida agora que evidências você precisaria se um auditor perguntasse “por que esse agente fez isso?” seis meses a partir de hoje. Integre isso na arquitetura antes da primeira linha de código ser escrita.

Próximos Passos

As empresas que geram valor real de IA autônoma chegaram lá fazendo o trabalho sem glória: definindo trabalhos com precisão, limitando autonomia deliberadamente, investindo relentlessly em avaliação, e alinhando stakeholders em um modelo operacional compartilhado. Não é tecnologia sofisticada que diferencia — é disciplina organizacional.

Se você está planejando seu primeiro piloto de agentes ou escalando para uma capacidade em toda a empresa, o Centro de Inovação em IA Generativa da AWS está disponível para uma conversa fundamentada em seus fluxos de trabalho, seus dados, e seus resultados de negócio.

Fonte

Agentic AI in the Enterprise Part 2: Guidance by Persona (https://aws.amazon.com/blogs/machine-learning/agentic-ai-in-the-enterprise-part-2-guidance-by-persona/)

O Desafio da Decodificação Especulativa em LLMs

EAGLE estabeleceu-se como o método de referência para decodificação especulativa na inferência de modelos de linguagem de grande escala (LLM). Sua abordagem inovadora permite gerar múltiplos tokens especulados simultaneamente, reduzindo a latência de forma significativa. Porém, sua estratégia de geração autorregressiva esconde um gargalo crítico: quanto mais tokens são especulados, mais passagens sequenciais pela rede neural o modelo auxiliar precisa realizar. Eventualmente, esse overhead consome os ganhos conquistados.

A AWS identificou essa limitação e desenvolveu P-EAGLE, uma evolução que remove esse teto de desempenho ao gerar todos os K tokens de rascunho em uma única passagem pela rede. O resultado? Até 1,69× de aceleração em relação ao EAGLE-3 vanilla em cenários reais utilizando GPUs NVIDIA B200.

Para começar, basta fazer o download (ou treinar) de uma cabeça de modelo auxiliar compatível com paralelismo e adicionar "parallel_drafting": true à sua configuração de pipeline no vLLM. Modelos P-EAGLE pré-treinados já estão disponíveis no HuggingFace para GPT-OSS 120B, GPT-OSS 20B e Qwen3-Coder 30B.

Como P-EAGLE Funciona

Eliminando o Gargalo Sequencial

EAGLE consegue acelerações de 2–3× sobre decodificação autorregressiva padrão e está amplamente implementado em estruturas de inferência em produção, incluindo vLLM, SGLang e TensorRT-LLM. No entanto, sua abordagem gera tokens especulados de forma sequencial — para produzir K tokens de rascunho, são necessárias K passagens completas pela rede do modelo auxiliar. À medida que esses modelos melhoram sua capacidade de geração, o overhead dessa abordagem se torna cada vez mais significativo: a latência do modelo auxiliar escala linearmente com a profundidade de especulação, limitando agressividade possível.

A Abordagem P-EAGLE

P-EAGLE transforma EAGLE de geração de rascunho autorregressiva para paralela. Em GPUs B200, o método alcança 1,05×–1,69× de aceleração em relação ao EAGLE-3 vanilla no GPT-OSS 20B, testado em MT-Bench, HumanEval e SpeedBench. Agora integrado ao vLLM desde a versão 0.16.0, está pronto para acelerar implantações no mundo real.

Dois Passos Fundamentais

Passo 1: Prefenchimento. O modelo alvo processa o prompt e gera um novo token, como faria durante inferência normal. Durante esse processo, P-EAGLE captura os estados ocultos internos do modelo: h_prompt para cada posição do prompt e h_context para o token recém-gerado. Esses estados codificam o que o modelo alvo “compreende” em cada posição e guiam as predições do modelo auxiliar. Este passo é idêntico ao EAGLE autorregressivo.

Passo 2: Modelo Auxiliar P-EAGLE. O modelo auxiliar constrói entradas para cada posição em paralelo. Cada entrada consiste em um embedding de token concatenado a um estado oculto. Para posições do prompt, cada embedding de token do prompt (emb(p)) é pareado com seu correspondente h_prompt do modelo alvo. Seguindo a mesma convenção do EAGLE autorregressivo, as posições são deslocadas por uma unidade: a posição i recebe o token e estado oculto da posição i-1, permitindo que ela prediga o token na posição i.

Para a posição 1 (Predição do Próximo Token — NTP), a entrada pareia o embedding do token recém-gerado (emb(new)) com h_context. Essa posição funciona de forma idêntica ao EAGLE autorregressivo padrão.

Para as posições 2 a K (Predição de Múltiplos Tokens — MTP), as entradas necessárias — embedding de token e estado oculto — ainda não existem. P-EAGLE preenche esses espaços com dois parâmetros treináveis: um embedding de máscara compartilhado (emb(mask)) e um estado oculto compartilhado (h_shared). Esses são vetores fixos aprendidos durante o treinamento que atuam como placeholders neutros. Todas as posições passam simultaneamente por N camadas de transformador e, em seguida, pela cabeça do modelo de linguagem para predizer tokens de rascunho t1, t2, t3 e t4 em uma única passagem.

Treinamento em Sequências Longas

Modelos de raciocínio moderno geram saídas extensas. No conjunto de dados UltraChat, GPT-OSS 120B produz sequências (incluindo prompts) com comprimento mediano de 3.891 tokens e percentil 90 de 10.800 tokens. Modelos auxiliares devem ser treinados em comprimentos de contexto correspondentes para serem efetivos na inferência.

Um desafio-chave é que a decodificação especulativa paralela amplifica requisitos de memória durante o treinamento. Treinar K grupos paralelos em uma sequência de comprimento N cria N × K posições totais. Com N = 8.192 e K = 8, um único exemplo de treinamento contém 65.536 posições. Atenção requer que cada posição atenda a todas as posições válidas — 65K × 65K significa mais de 4 bilhões de elementos, consumindo 8GB em bf16.

Amostragem de posições reduz memória saltando aleatoriamente posições, mas pular de forma muito agressiva degrada a qualidade do rascunho. Acumulação de gradientes é a solução padrão para treinamento com memória limitada, mas divide entre diferentes exemplos de treinamento. Quando uma sequência única excede a memória disponível, não há nada para dividir.

P-EAGLE introduz um algoritmo de particionamento de sequência para divisão intra-sequência. O algoritmo divide a sequência de posições N × K em pedaços contíguos, mantém dependências de atenção corretas através das fronteiras dos pedaços e acumula gradientes através de pedaços da mesma sequência. Para detalhes técnicos, consulte o paper de P-EAGLE.

Integração no vLLM

Desafios da Decodificação Especulativa Paralela

Em muitas configurações de decodificação especulativa, rascunho e verificação compartilham o mesmo layout de token por requisição. Isso é geralmente verdadeiro para EAGLE: o modelo auxiliar consome uma janela que já corresponde ao que o verificador checará — K tokens especulados e um token adicional amostrado.

Decodificação paralela quebra essa consistência. Para predizer K tokens em uma passagem do modelo auxiliar, placeholders de MÁSCARA são anexados (por exemplo, [token, MÁSCARA, MÁSCARA, …]). Essas posições extras existem apenas para rascunho, então a forma do lote de rascunho não corresponde mais à forma do lote de verificação. Como metadados de verificação não podem ser reutilizados, o metadata do lote deve ser reconstruído. Os IDs de token de entrada, estados ocultos e posições são expandidos para inserir espaços para tokens/embeddings de máscara, posições por requisição são incrementadas, então o mapeamento de slot e índices de início por requisição são recomputados a partir das posições atualizadas.

Kernel Triton Otimizado

Para compensar o overhead da reconstrução de metadata do lote, um kernel Triton fundido popula o lote de entrada do modelo auxiliar na GPU copiando e expandindo o lote do modelo alvo. Em uma única passagem, o kernel copia os IDs de token e posições anteriores do lote alvo para novos slots de destino, insere o token bônus por requisição amostrado pelo modelo alvo e preenche os slots adicionais de decodificação paralela com um ID de token MÁSCARA especial. Por fim, gera metadata leve: máscara de token rejeitado, máscara de token mascarado para slots de decodificação paralela, índices de novo-token para amostragem de tokens de rascunho e mapeamento de estado oculto. Essa lógica, de outra forma, demandaria muitas operações GPU (cópia/espalhamento + inserção + preenchimento + máscara + remapeamento). Fundindo em um kernel único reduz overhead de lançamento e tráfego extra de memória, mantendo a configuração de rascunho eficiente.

Gestão de Estados Ocultos

Para métodos baseados em EAGLE que passam estados ocultos ao modelo auxiliar, decodificação paralela trata esse preenchimento separadamente. Como estados ocultos são significativamente maiores que o resto do lote de entrada, o trabalho é dividido: o kernel Triton produz um mapeamento, e um kernel de cópia dedicado transmite o placeholder de estado oculto aprendido para slots de token mascarado.

# Copiar estados ocultos alvo para suas novas posições
self.hidden_states[out_hidden_state_mapping] = target_hidden_states

# Preencher posições mascaradas com o estado oculto aprendido de Decodificação Paralela
mask = self.is_masked_token_mask[:total_num_output_tokens]
torch.where(
    mask.unsqueeze(1),
    self.parallel_drafting_hidden_state_tensor,
    self.hidden_states[:total_num_output_tokens],
    out=self.hidden_states[:total_num_output_tokens],
)

O parallel_drafting_hidden_state_tensor é carregado do buffer mask_hidden do modelo, uma representação aprendida que informa ao modelo que essas posições devem predizer tokens futuros. Para mapeamento de slot de cache KV, tokens válidos recebem atribuição de slot normal enquanto tokens rejeitados são mapeados para PADDING_SLOT_ID (-1) para evitar escritas spurias em cache. Para grafos CUDA, o intervalo de captura é estendido por K × max_num_seqs para acomodar o lote de rascunho maior introduzido pela decodificação paralela.

Resultados de Benchmark

P-EAGLE foi treinado em GPT-OSS-20B e avaliado em três benchmarks: MT-Bench para instrução multi-turno, SPEED-Bench para geração de código longo e HumanEval para síntese de código em nível de função. P-EAGLE entrega 55–69% de throughput superior em baixa concorrência (c=1), com ganhos de 5–25% sustentados em alta concorrência (c=64), comparado ao checkpoint público vanilla EAGLE-3.

O modelo auxiliar P-EAGLE é um modelo leve de 4 camadas treinado para predizer até 10 tokens em paralelo. Para avaliação de desempenho, profundidades de especulação K ∈ {3, 5, 7} foram testadas em níveis de concorrência C ∈ {1, 2, 4, 8, 16, 32, 64}. P-EAGLE alcança TPS (Tokens Por Segundo) máximo em K=7 em todos os níveis de concorrência. Em contraste, EAGLE-3 vanilla atinge seu TPS máximo em K=3, com profundidade melhorada ocasionalmente deslocando para valores maiores dependendo da concorrência. Esse padrão reflete a vantagem fundamental da decodificação paralela.

P-EAGLE gera todos os K tokens de rascunho em uma única passagem, permitindo que se beneficie de especulação mais profunda sem incorrer em overhead sequencial adicional. Rascunhadores autorregressivos, por contraste, devem gerar tokens especulativos passo a passo, o que limita sua capacidade de escalar eficientemente para K maiores.

Comprimento de Aceitação Aprimorado

Além de reduzir overhead de rascunho, ganhos de throughput do P-EAGLE também são impulsionados por melhor comprimento de aceitação (AL — do inglês Acceptance Length) — a média de tokens de rascunho aceitos pelo verificador por rodada de especulação. AL maior significa mais do trabalho de rascunho se transforma em saída real, o que impulsiona diretamente OTPS/TPS (Tokens de Saída Por Segundo / Tokens Por Segundo) efetivo.

P-EAGLE alcança consistentemente AL superior ao EAGLE-3 na mesma profundidade de especulação K. Em K=7, P-EAGLE supera EAGLE-3 por 30% em HumanEval (3,94 vs 3,03), 31% em SPEED-Bench (3,38 vs 2,59) e 13% em MT-Bench (3,70 vs 3,27). Notavelmente, P-EAGLE se beneficia mais de especulação mais profunda. De K=3 para K=7, AL do P-EAGLE aumenta 0,92 em HumanEval (3,02 para 3,94), enquanto EAGLE-3 ganha apenas 0,38 (2,65 para 3,03). Essa lacuna crescente em K maior é consistente com decodificação especulativa paralela de passagem única do P-EAGLE, que não incorre em custo adicional de especulação mais profunda.

Como Começar

Configuração Básica

P-EAGLE pode ser ativado com uma mudança simples de configuração na classe SpeculativeConfig:

# vllm/config/speculative.py
parallel_drafting: bool = True

Aqui está um comando de exemplo no vLLM para ativar decodificação paralela com P-EAGLE como modelo auxiliar:

vllm serve openai/gpt-oss-20b \
  --speculative-config '{"method": "eagle3", "model": "amazon/gpt-oss-20b-p-eagle", "num_speculative_tokens": 5, "parallel_drafting": true}'

Executando Benchmarks

Após lançar o servidor, execute benchmarks com vllm bench serve:

#MT-Bench
export MODEL="openai/gpt-oss-20b"
export BASE_URL="http://localhost:8000"
vllm bench serve \
  --dataset-name hf \
  --dataset-path philschmid/mt-bench \
  --num-prompts 80 \
  --max-concurrency 1 \
  --model $MODEL \
  --base-url $BASE_URL \
  --temperature 0.0 \
  --hf-output-len 2048

#HumanEval
# Baixar dataset HumanEval openai/openai_humaneval
vllm bench serve \
  --dataset-name custom \
  --dataset-path  \
  --num-prompts 164 \
  --max-concurrency 1 \
  --model $MODEL \
  --base-url $BASE_URL \
  --temperature 0.0 \
  --custom-output-len 2048

Nota Importante: Servir GPT-OSS-20B com rascunhadores EAGLE atualmente requer um patch vLLM de uma linha (PR#36684). Aplique-o antes de lançar. Essa correção deve chegar em uma versão próxima do vLLM.

Recursos Disponíveis

Para explorar P-EAGLE, a AWS disponibilizou:

• Paper ArXiv com detalhes técnicos completos
• Modelos pré-treinados no HuggingFace: GPT-OSS 120B, GPT-OSS 20B, Qwen3-Coder-30B-A3B-Instruct
• Integração vLLM a partir da versão 0.16.0 com Unified Parallel Drafting
• Discussões técnicas: RFC e PR no repositório vLLM-Speculators

Conclusão

P-EAGLE remove o gargalo sequencial da decodificação especulativa, entregando até 1,69× de aceleração em relação ao EAGLE-3 vanilla em cargas reais. Ao desacoplar contagem de rascunho de contagem de passagens diretas, agora é possível explorar arquiteturas de rascunho maiores, que podem até permitir taxas de aceitação aumentadas comparadas a baselines de camada única.

A implementação lida com cuidado com complexidades de preparação de entrada, gerenciamento de metadata de atenção e mapeamento de slot de cache KV através de kernels fundidos escritos manualmente. Embora requeira modelos especialmente treinados, os benefícios de desempenho a tornam uma adição valiosa às capacidades de decodificação especulativa do vLLM. Conforme mais modelos treinados em paralelo se tornem disponíveis, espera-se que essa abordagem se torne a escolha preferida para implantações de LLM em produção.

Para começar agora: baixe uma cabeça P-EAGLE pré-treinada do HuggingFace, configure "parallel_drafting": true em seu config vLLM para qualquer um dos modelos suportados e veja a aceleração em ação.

Fonte

P-EAGLE: Faster LLM inference with Parallel Speculative Decoding in vLLM (https://aws.amazon.com/blogs/machine-learning/p-eagle-faster-llm-inference-with-parallel-speculative-decoding-in-vllm/)

Uma nova abordagem para desenvolvimento serverless

A AWS anunciou o lançamento do SAM Kiro Power, uma extensão que traz expertise em desenvolvimento serverless para o ambiente de desenvolvimento assistido por inteligência artificial do Kiro. Essa ferramenta permite que desenvolvedores construam, implantem e gerenciem aplicações serverless com assistência de agente de IA, tudo diretamente no ambiente local.

O Serverless Application Model (SAM) é um framework de código aberto que simplifica a criação de aplicações serverless na AWS. Com essa integração, o SAM Kiro Power carrega dinamicamente orientações e expertise específicas que o agente de IA precisa para construir essas aplicações, tornando o processo mais intuitivo e guiado.

Capacidades e funcionalidades

O SAM Kiro Power oferece suporte completo ao ciclo de vida do desenvolvimento serverless. Ele auxilia na inicialização de projetos SAM, no build e deploy de aplicações para a AWS, além de permitir testes locais de funções Lambda com feedback em tempo real.

A ferramenta suporta padrões dirigidos por eventos, incluindo integração com Amazon EventBridge, Amazon Managed Streaming para Apache Kafka (MSK), Amazon Kinesis, Amazon DynamoDB Streams e Amazon Simple Queue Service (SQS). Além disso, ela aborda boas práticas de segurança, com orientações sobre políticas IAM.

Boas práticas desde o início

Uma característica importante do SAM Kiro Power é que ele impõe automaticamente o uso de recursos SAM e Powertools para AWS Lambda, garantindo observabilidade e logging estruturado por padrão. Essa abordagem elimina a necessidade de retrofit de boas práticas, pois elas já estão incorporadas desde o início do desenvolvimento.

Essa orientação integrada acelera a jornada desde o conceito até a produção, independentemente do tipo de aplicação: desde websites estáticos com backends de API, passando por microsserviços dirigidos por eventos, até aplicações full-stack completas.

Acesso e documentação

O SAM Kiro Power está disponível hoje com instalação em um clique tanto na IDE do Kiro quanto na página de Poderes do Kiro. Desenvolvedores interessados podem explorar o código-fonte no repositório GitHub ou consultar o guia do desenvolvedor para aprender mais detalhes sobre o SAM.

Fonte

Accelerate serverless application development with new SAM Kiro power (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-sam-kiro-power/)

Monitorando Cargas de IA Generativa em Escala

À medida que organizações expandem suas cargas de trabalho de inteligência artificial generativa no Amazon Bedrock, compreender o desempenho da inferência e o consumo de recursos torna-se essencial para manter a confiabilidade operacional. Equipes que executam aplicações sensíveis à latência precisam entender com que rapidez os modelos começam a gerar respostas. Aquelas que gerenciam cargas de alto throughput precisam acompanhar como suas requisições consomem quota para evitar limitações inesperadas.

Até então, obter essa visibilidade exigia instrumentação customizada no lado do cliente ou investigação reativa após problemas ocorrerem. A AWS anunciou duas novas métricas do CloudWatch para o Amazon Bedrock: TimeToFirstToken e EstimatedTPMQuotaUsage. Essas métricas oferecem visibilidade no lado do servidor sobre latência de streaming e consumo de quota, são emitidas automaticamente para cada requisição de inferência bem-sucedida, não geram custos adicionais, não requerem mudanças nas APIs e estão disponíveis agora no namespace AWS/Bedrock do CloudWatch.

O Fundamento: Métricas Existentes do Bedrock

O Amazon Bedrock já fornecia um conjunto de métricas do CloudWatch para monitorar cargas de inferência. O namespace AWS/Bedrock incluía métricas como Invocations, InvocationLatency, InvocationClientErrors, InvocationThrottles, InputTokenCount e OutputTokenCount. Essas métricas ofereciam visibilidade sobre volume de requisições, latência fim-a-fim, taxas de erro e uso de tokens. Estavam disponíveis nas APIs Converse, ConverseStream, InvokeModel e InvokeModelWithResponseStream, podendo ser filtradas pela dimensão ModelId.

Embora essas métricas fornecessem uma base operacional sólida, deixavam duas lacunas importantes: não capturavam a rapidez com que uma resposta em streaming começava (tempo até o primeiro token) e não refletiam a quota efetivamente consumida por uma requisição após considerar os multiplicadores de redução de token.

Observabilidade de Aplicações de Inferência em Produção

Em aplicações de inferência com streaming, como chatbots, assistentes de codificação ou geração de conteúdo em tempo real, o tempo que o modelo leva para retornar seu primeiro token afeta diretamente a responsividade percebida pela aplicação. Um atraso no primeiro token impacta a experiência do usuário, mesmo quando o throughput geral permanece dentro de intervalos aceitáveis.

Medir essa métrica no lado do servidor anteriormente exigia instrumentar o código da aplicação para capturar timestamps ao redor das chamadas de API. Isso adicionava complexidade e poderia introduzir imprecisões que não refletiam o comportamento real do lado do serviço.

A gestão de quota apresenta um desafio diferente, mas igualmente crítico. O Amazon Bedrock aplica multiplicadores de redução de token para certos modelos. Isso significa que a quota efetivamente consumida por uma requisição pode diferir dos contadores brutos de tokens vistos nas métricas de faturamento. Por exemplo, modelos Anthropic Claude, incluindo Claude Sonnet 4.6, Claude Opus 4.6, Claude Sonnet 4.5 e Claude Opus 4.5, aplicam um multiplicador de 5x em tokens de saída para fins de quota. Uma requisição que produz 100 tokens de saída consome efetivamente 500 tokens de sua quota de Tokens Por Minuto (TPM). O faturamento ocorre apenas sobre o uso real de tokens.

Sem visibilidade nesse cálculo, a limitação de taxa pode parecer imprevisível, dificultando a definição de alarmes apropriados ou planejamento de aumentos de capacidade antecipadamente. Para clientes usando inferência entre regiões, esses desafios se multiplicam porque é necessária visibilidade por perfil de inferência para compreender desempenho e consumo entre configurações geográficas e globais.

As Novas Métricas: TimeToFirstToken e EstimatedTPMQuotaUsage

TimeToFirstToken: Medindo Latência de Streaming

A métrica TimeToFirstToken mede a latência, em milissegundos, do momento em que o Amazon Bedrock recebe sua requisição de streaming até quando o serviço gera o primeiro token de resposta. É emitida para as APIs de streaming: ConverseStream e InvokeModelWithResponseStream. Por ser medida no lado do servidor, reflete a latência real do serviço sem ruído das condições de rede ou processamento no cliente.

Com essa métrica, é possível:

• Definir alarmes de latência — Criar alarmes do CloudWatch que notifiquem quando o tempo até o primeiro token ultrapassa limites aceitáveis, detectando degradação de desempenho antes que afete usuários.
• Estabelecer baselines de SLA — Analisar dados históricos de TimeToFirstToken entre modelos para definir baselines informados de desempenho para as aplicações.
• Diagnosticar problemas de desempenho — Correlacionar TimeToFirstToken com outras métricas do Amazon Bedrock, como InvocationLatency (Tempo até Último Token), isolando se questões de latência originam-se do tempo de resposta inicial do modelo ou do processamento geral da requisição.

A métrica é publicada com a dimensão ModelId e, opcionalmente, com dimensões ServiceTier e ResolvedServiceTier. Para perfis de inferência entre regiões, o ModelId corresponde ao identificador do seu perfil de inferência (por exemplo, us.anthropic.claude-sonnet-4-5-v1), permitindo monitorar TimeToFirstToken separadamente para cada perfil. É emitida apenas para requisições de streaming completadas com sucesso.

EstimatedTPMQuotaUsage: Entendendo Consumo Real de Quota

A métrica EstimatedTPMQuotaUsage acompanha a quota estimada de Tokens Por Minuto (TPM) consumida por suas requisições. Diferentemente dos contadores brutos de tokens, essa métrica leva em conta os fatores que o Amazon Bedrock considera ao avaliar consumo de quota, incluindo tokens de escrita em cache e multiplicadores de redução de tokens de saída. O nome da métrica inclui “Estimated” para refletir que fornece uma aproximação próxima do consumo de quota para fins de monitoramento e planejamento de capacidade.

As decisões internas de limitação do Amazon Bedrock baseiam-se em cálculos em tempo real que podem diferir ligeiramente dessa métrica, mas EstimatedTPMQuotaUsage foi projetada para fornecer um sinal confiável e acionável. Deve ser precisa o suficiente para definir alarmes, rastrear tendências de consumo e planejar aumentos de quota com confiança. É emitida em todas as APIs de inferência: Converse, InvokeModel, ConverseStream e InvokeModelWithResponseStream.

Fórmulas de Cálculo de Quota

O cálculo da quota estimada depende de seu tipo de throughput:

Para inferência sob demanda:

EstimatedTPMQuotaUsage = InputTokenCount + CacheWriteInputTokens + (OutputTokenCount × burndown_rate)

A taxa de redução varia por modelo. Para a lista completa de modelos e suas respectivas taxas, consulte a documentação sobre multiplicadores de redução de token para gestão de quota. Para inferência sob demanda, tokens de leitura em cache não contam para a quota.

Como exemplo, Claude Sonnet 4.5 aplica uma taxa de redução de 5x em tokens de saída. Uma requisição sob demanda com 1.000 tokens de entrada, 200 tokens de escrita em cache e 100 tokens de saída consome 1.000 + 200 + (100 × 5) = 1.700 tokens de quota. Isso é 400 tokens a mais do que se estimasse apenas a partir dos contadores brutos.

Para Throughput Provisionado (camada reservada):

EstimatedTPMQuotaUsage = InputTokenCount + (CacheWriteInputTokens × 1.25) + (CacheReadInputTokens × 0.1) + OutputTokenCount

No Throughput Provisionado, o multiplicador de redução em tokens de saída não se aplica. Contudo, tokens de leitura em cache contribuem com taxa 0.1 e tokens de escrita em cache são ponderados em 1.25. Note que faturamento difere de uso de quota — você é faturado pelo uso real de tokens, não pelos valores ajustados ou ponderados. Para mais detalhes, consulte multiplicadores de redução de token para gestão de quota.

Com essa métrica, é possível:

• Definir alarmes proativos de quota — Criar alarmes do CloudWatch que disparem quando o uso de quota estimado se aproxima do limite de TPM, permitindo agir antes que requisições sejam limitadas.
• Rastrear consumo entre modelos — Comparar uso de quota entre diferentes modelos para entender quais cargas consumem mais capacidade e otimizar adequadamente.
• Planejar aumentos de quota — Usar tendências históricas de consumo para solicitar aumentos de quota através das quotas de serviço da AWS antes que o crescimento de uso cause limitação.

Dimensões e Filtragem de Métricas

Ambas as métricas compartilham as seguintes características:

• Incluem dimensões como ModelId, permitindo filtrar e agregar dados por modelo.
• Ao usar um perfil de inferência entre regiões, seja geográfico (por exemplo, us.anthropic.claude-sonnet-4-5-v1) ou global (por exemplo, global.anthropic.claude-sonnet-4-5-v1), a dimensão ModelId corresponde ao identificador do seu perfil de inferência.
• Isso oferece visibilidade granular sobre desempenho e consumo entre suas configurações de inferência, permitindo visualizar métricas separadas para cada combinação de perfil de inferência entre regiões e modelo.
• Isso é consistente com métricas CloudWatch existentes do Amazon Bedrock como Invocations, InvocationLatency e métricas de contagem de tokens.

Atributo	TimeToFirstToken	EstimatedTPMQuotaUsage
Namespace CloudWatch	AWS/Bedrock	AWS/Bedrock
Unidade	Milissegundos	Contagem
APIs Suportadas	ConverseStream, InvokeModelWithResponseStream	Converse, InvokeModel, ConverseStream, InvokeModelWithResponseStream
Frequência de Atualização	Agregação de 1 minuto	Agregação de 1 minuto
Escopo	Requisições de streaming completadas com sucesso	Requisições completadas com sucesso
Dimensão Principal	ModelId	ModelId
Dimensões Opcionais	ServiceTier, ResolvedServiceTier	ServiceTier, ResolvedServiceTier, ContextWindow (para contextos de entrada superiores a 200K tokens)
Tipos de Inferência Suportados	Inferência entre regiões (geográfica e global), inferência na mesma região	Inferência entre regiões (geográfica e global), inferência na mesma região

Começando a Usar as Novas Métricas

Essas métricas já estão disponíveis em seu dashboard do CloudWatch. Quando sua aplicação chama uma API de inferência do Amazon Bedrock, o serviço processa a requisição, invoca o modelo e publica todas as métricas aplicáveis — incluindo TimeToFirstToken e EstimatedTPMQuotaUsage — no namespace AWS/Bedrock em sua conta CloudWatch. Você pode então usar dashboards, alarmes e matemática de métricas do CloudWatch para monitorar, alertar e analisar essas métricas.

Para começar:

1. Abra a console do Amazon CloudWatch e navegue para Métricas > Todas as métricas.
2. Selecione o namespace AWS/Bedrock.
3. Encontre as métricas TimeToFirstToken ou EstimatedTPMQuotaUsage e filtre por ModelId para visualizar dados de modelos específicos.
4. Crie alarmes para receber notificações sobre degradação de latência ou consumo de quota aproximando-se de seus limites.

Exemplos Práticos

Gerando Dados de Métrica com Requisições de Inferência

Para gerar pontos de dados de métrica, faça requisições de inferência contra o Amazon Bedrock. Os exemplos a seguir usam o AWS SDK para Python (Boto3) para demonstrar uma requisição sem streaming (que emite EstimatedTPMQuotaUsage) e uma com streaming (que emite TimeToFirstToken e EstimatedTPMQuotaUsage). Nesses exemplos, usamos us-east-1 como a Região AWS e us.anthropic.claude-sonnet-4-6-v1 como um perfil de inferência entre regiões. Substitua pelos seus próprios valores.

Converse (sem streaming):

import boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock.converse(
    modelId='us.anthropic.claude-sonnet-4-6-v1',
    messages=[
        {
            'role': 'user',
            'content': [{'text': 'What is the capital of France?'}]
        }
    ]
)

print(response['output']['message']['content'][0]['text'])
print(f"Input tokens: {response['usage']['inputTokens']}")
print(f"Output tokens: {response['usage']['outputTokens']}")

ConverseStream (com streaming):

import boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')

response = bedrock.converse_stream(
    modelId='us.anthropic.claude-sonnet-4-6-v1',
    messages=[
        {
            'role': 'user',
            'content': [{'text': 'What is the capital of France?'}]
        }
    ]
)

for event in response['stream']:
    if 'contentBlockDelta' in event:
        print(event['contentBlockDelta']['delta']['text'], end='')

print()

As mesmas métricas são emitidas para as APIs InvokeModel (sem streaming) e InvokeModelWithResponseStream (com streaming). A tabela abaixo resume quais métricas cada API emite:

API	Métricas Emitidas
Converse	EstimatedTPMQuotaUsage
ConverseStream	EstimatedTPMQuotaUsage, TimeToFirstToken
InvokeModel	EstimatedTPMQuotaUsage
InvokeModelWithResponseStream	EstimatedTPMQuotaUsage, TimeToFirstToken

Após fazer essas requisições, aguarde aproximadamente 1 a 2 minutos para que as métricas apareçam. Então navegue até a console CloudWatch em Métricas > Todas as métricas > AWS/Bedrock para verificar que os pontos de dados estão presentes para seu modelo.

Consultando Métricas Usando a AWS CLI

Você pode usar a AWS CLI para verificar que as novas métricas estão disponíveis e recuperar seus valores. Primeiro, confirme que as métricas estão sendo publicadas para seu modelo:

# Listar métricas disponíveis de TimeToFirstToken
aws cloudwatch list-metrics --namespace AWS/Bedrock --metric-name TimeToFirstToken

# Listar métricas disponíveis de EstimatedTPMQuotaUsage
aws cloudwatch list-metrics --namespace AWS/Bedrock --metric-name EstimatedTPMQuotaUsage

Conclusão

Com as novas métricas TimeToFirstToken e EstimatedTPMQuotaUsage do CloudWatch, o Amazon Bedrock oferece a observabilidade necessária para executar cargas de trabalho de inteligência artificial generativa em produção com confiança.

Pontos principais:

• Medir latência de streaming no lado do servidor — TimeToFirstToken fornece medição precisa de latência no lado do servidor para APIs de streaming sem exigir nenhuma instrumentação no cliente.
• Compreender o verdadeiro consumo de quota — EstimatedTPMQuotaUsage reflete o impacto estimado de quota de suas requisições, incluindo multiplicadores de redução, permitindo prever e prevenir limitação.
• Nenhuma ação necessária para começar — Ambas as métricas são emitidas automaticamente sem custo adicional. Abra seu dashboard do CloudWatch para começar a usá-las.
• Definir alarmes proativos — Use essas métricas para criar alarmes que detectem problemas de desempenho e pressão de quota antes que afetem suas aplicações.

Abra sua console do Amazon CloudWatch hoje mesmo para explorar essas novas métricas e configurar alarmes adaptados aos requisitos de sua carga de trabalho.

Referências

• Documentação de monitoramento do Amazon Bedrock
• Multiplicadores de redução de token para gestão de quota
• Quotas e limites do Amazon Bedrock
• Documentação de alarmes do Amazon CloudWatch

Fonte

Improve operational visibility for inference workloads on Amazon Bedrock with new CloudWatch metrics for TTFT and Estimated Quota Consumption (https://aws.amazon.com/blogs/machine-learning/improve-operational-visibility-for-inference-workloads-on-amazon-bedrock-with-new-cloudwatch-metrics-for-ttft-and-estimated-quota-consumption/)

Buscando além das palavras-chave tradicionais

A busca em repositórios de vídeo costuma depender de etiquetagem manual ou palavras-chave predefinidas. A AWS apresenta uma alternativa que vai além: uma arquitetura escalável para busca multimodal em vídeos, capaz de processar consultas em linguagem natural e encontrar conteúdo relevante não apenas pelas tags, mas pela compreensão semântica do que realmente acontece no vídeo.

A solução integra os modelos Amazon Nova com o Amazon OpenSearch Service, gerando embeddings que capturam informações visuais e de áudio simultaneamente. O resultado é um sistema que entende o contexto do conteúdo videográfico de forma muito mais rica que abordagens tradicionais.

Processando escala em volume real

Para demonstrar a viabilidade dessa abordagem, a AWS processou 792.270 vídeos de dois conjuntos de dados públicos: Multimedia Commons (787.479 vídeos com média de 37 segundos) e MEVA (4.791 vídeos com média de 5 minutos). No total, foram processadas 8.480 horas de conteúdo em 41 horas de computação.

Os custos ficaram em torno de R$ 27 mil no primeiro ano (utilizando OpenSearch sob demanda) ou R$ 23 mil com instâncias reservadas. A ingestão única custou aproximadamente R$ 18 mil, enquanto a assinatura anual do OpenSearch ficou entre R$ 5,5 mil e R$ 9,2 mil, dependendo do modelo de pagamento escolhido.

Arquitetura em duas camadas: ingestão e busca

A solução é organizada em dois fluxos de trabalho principais que trabalham em conjunto.

O pipeline de ingestão de vídeos

O processamento utiliza quatro instâncias Amazon EC2 do tipo c7i.48xlarge, cada uma executando 600 trabalhadores paralelos para processar aproximadamente 19.400 vídeos por hora. A API assíncrona de embeddings multimodais permite que o sistema segmente vídeos em trechos de 15 segundos (otimizados para capturar mudanças de cena) e gere embeddings de 1.024 dimensões.

A escolha por embeddings de 1.024 dimensões em vez de 3.072 dimensões resultou em economia de três vezes no armazenamento, com impacto mínimo na precisão. O processamento responde pela maior parte do custo: aproximadamente R$ 17 mil dos R$ 18 mil da ingestão.

Além dos embeddings, o sistema utiliza Amazon Nova Pro (ou Amazon Nova 2 Lite para melhor custo-benefício) para gerar entre 10 e 15 etiquetas descritivas por vídeo a partir de uma taxonomia predefinida, facilitando buscas por palavras-chave complementares.

Armazenamento em índices especializados

Os embeddings são indexados em um índice k-NN do OpenSearch para buscas semânticas vetoriais, enquanto as etiquetas de metadados ficam em um índice de texto separado para correspondências por palavras-chave. Essa arquitetura dual permite otimizar cada tipo de busca independentemente.

Três formas de buscar: texto, vídeo e híbrida

A arquitetura suporta três modos de consulta distintos, cada um atendendo a casos de uso diferentes.

Busca por texto em vídeos

O usuário digita uma consulta em linguagem natural. O sistema converte essa consulta em um embedding utilizando a API síncrona do Amazon Nova Multimodal Embeddings e realiza uma busca de similaridade vetorial (k-NN) contra todos os segmentos indexados. Uma consulta como “pessoa caminhando na praia ao pôr do sol” encontra segmentos de vídeo com significado semelhante, não necessariamente com essas palavras exatas.

Busca vídeo a vídeo

A busca por similaridade também funciona ao contrário: seleciona-se um segmento de um vídeo já indexado e encontram-se segmentos similares de toda a biblioteca. Não há necessidade de invocar o modelo novamente — o embedding já existe no OpenSearch.

Busca híbrida

A abordagem mais robusta combina os dois métodos: busca vetorial por similaridade (70% do peso) com busca textual por palavras-chave (30% do peso). Segmentos que aparecem em ambas as consultas recebem uma pontuação combinada, entregando resultados mais precisos quando a qualidade das etiquetas é elevada.

Performance em escala de produção

Depois de indexar mais de 792 mil vídeos, o sistema foi testado em relação à velocidade de resposta:

• Busca semântica k-NN: ~76 ms (utilizando algoritmo HNSW com complexidade logarítmica)
• Busca textual BM25: ~30 ms
• Busca híbrida: ~106 ms

O armazenamento total necessário foi de 29,8 GB — 28,8 GB para o índice vetorial e 1 GB para o índice de texto. Todas as três modalidades de busca mantêm latências abaixo de 200 ms mesmo em escala de centenas de milhares de vídeos, atendendo aos requisitos típicos de aplicações interativas.

Implementando a solução na prática

Pré-requisitos

Para começar, é necessário ter acesso a uma conta AWS com Amazon Bedrock na região us-east-1, Python 3.9 ou superior, AWS CLI configurada, um domínio do OpenSearch Service com instâncias r6g.large ou maiores, um bucket Amazon S3 para armazenar vídeos e embeddings, e permissões apropriadas de Controle de Acesso à Identidade (IAM).

Configurando permissões

O primeiro passo é criar uma função IAM com permissões para invocar modelos do Amazon Bedrock, escrever em índices do OpenSearch e ler/escrever objetos no S3. A política deve permitir as ações específicas de invocação de modelos Nova, operações no OpenSearch e acesso aos buckets de vídeos e embeddings.

Criando índices no OpenSearch

É necessário criar dois índices do OpenSearch Service: um para embeddings vetoriais (k-NN) e outro para metadados de texto. O primeiro deve habilitar a funcionalidade k-NN com dimensão de 1.024 e usar o algoritmo HNSW com similitude de cosseno. O segundo segue a estrutura padrão de índice de texto com dois campos: identificador do vídeo, índice do segmento, e etiquetas.

Processando vídeos com Nova

A API assíncrona do Amazon Bedrock processa vídeos e gera embeddings. O sistema segmenta vídeos em trechos de 15 segundos, combina informações visuais e de áudio, e retorna os embeddings via S3. Como há um limite de 30 trabalhos simultâneos por conta, a implementação inclui uma fila de trabalhos com polling — submeter jobs até o limite, aguardar conclusão e submeter novos conforme slots ficam disponíveis.

Gerando etiquetas com Nova Pro

Após gerar embeddings, o sistema utiliza Nova Pro (ou Nova Lite para melhor custo-benefício) para extrair etiquetas descritivas de uma taxonomia predefinida. Isso enriquece a capacidade de busca por palavras-chave e melhora significativamente os resultados da busca híbrida.

Indexando dados no OpenSearch

Os embeddings e etiquetas são carregados no OpenSearch usando indexação em massa para eficiência. Cada segmento de vídeo gera uma entrada no índice vetorial com sua dimensão de 1.024 componentes, e outra entrada no índice de texto com suas etiquetas associadas.

Executando buscas

Após a ingestão, o sistema está pronto para receber consultas. Para buscas por texto em vídeos, o sistema converte a consulta em embedding usando a API síncrona do Amazon Nova e realiza uma busca de similaridade no índice k-NN. Para buscas vídeo a vídeo, recupera-se o embedding de um segmento de referência e realiza-se a mesma busca de similaridade. Buscas híbridas combinam os dois métodos, agregando pontuações ponderadas de ambos os índices.

Escalando para produção

Conforme o volume de vídeos cresce, recomenda-se utilizar AWS Batch para processar lotes de vídeos em paralelo em múltiplas instâncias, particionando o dataset entre diferentes trabalhadores. O monitoramento da saúde do cluster OpenSearch Service é importante para escalar nós de dados conforme o índice cresce. A arquitetura de dois índices escala bem porque buscas vetoriais e textuais podem ser otimizadas independentemente.

Os pesos da busca híbrida (70% vetor, 30% texto) podem ser ajustados conforme o caso de uso. Se as etiquetas forem de alta qualidade, aumentar o peso textual para 50% pode melhorar resultados para consultas específicas.

Considerações de custo e desempenho

O tempo de processamento de um vídeo depende de sua duração. Um vídeo de 45 segundos leva aproximadamente 70 segundos para ser totalmente processado pela API assíncrona. Escolher embeddings de 1.024 dimensões em vez de 3.072 reduz custos de armazenamento em três vezes com mínimo impacto em precisão.

A cobrança pelos embeddings ocorre por segundo de vídeo processado (R$ 0,00056 por segundo no modo de lote), então a duração total do vídeo é o fator determinante, não a dimensão dos embeddings. A API assíncrona é significativamente mais econômica que processar vídeos quadro a quadro.

Para o OpenSearch Service, instâncias r6g oferecem melhor relação preço-desempenho que gerações anteriores, e é possível implementar estratificação de dados para mover conteúdo frio para S3 e economizar ainda mais.

Limpeza de recursos

Ao finalizar os testes, para evitar cobranças contínuas, é importante deletar o domínio do OpenSearch Service, limpar e remover os buckets S3 usados para vídeos e embeddings, e remover qualquer função IAM criada especificamente para a solução. Cobranças pelo Amazon Bedrock baseiam-se em uso real, portanto nenhuma limpeza adicional é necessária para os modelos.

Abrindo caminhos para novos casos de uso

A solução apresentada oferece uma base sólida para buscas inteligentes em repositórios de vídeo em escala. A combinação de processamento multimodal com índices vetoriais mantém custos gerenciáveis mesmo com centenas de milhares de vídeos, enquanto entrega experiências de busca muito superiores aos métodos tradicionais.

Para aprofundar nos detalhes técnicos, consulte a documentação de Amazon Nova Multimodal Embeddings e Busca Híbrida com Amazon OpenSearch Service.

Fonte

Multimodal embeddings at scale: AI data lake for media and entertainment workloads (https://aws.amazon.com/blogs/machine-learning/multimodal-embeddings-at-scale-ai-data-lake-for-media-and-entertainment-workloads/)