Blog

Observabilidade Unificada no OpenSearch

A AWS expandiu as capacidades do Amazon OpenSearch Service com uma abordagem integrada para observabilidade. O serviço agora oferece uma experiência unificada que reúne métricas, logs, rastreamentos e rastreamento de agentes de IA em um único ponto de acesso. Essa mudança representa uma resposta direta a dois grandes desafios enfrentados por times de operação: os custos proibitivos de plataformas premium de observabilidade e a complexidade operacional causada pelo uso de múltiplas ferramentas desintegradas.

Capacidades Principais

Integração Nativa com Prometheus

O OpenSearch agora oferece integração nativa com o Amazon Managed Service for Prometheus, permitindo que engenheiros de confiabilidade do site, especialistas em DevOps e times de engenharia de plataforma façam consultas de métricas do Prometheus diretamente usando a sintaxe nativa PromQL (Prometheus Query Language) ao lado de logs e rastreamentos na interface de observabilidade do OpenSearch. Tudo isso ocorre sem necessidade de duplicação de dados, eliminando um dos maiores gargalos de observabilidade tradicional.

Monitoramento Avançado com RED Metrics

A solução incorpora fluxos de trabalho de monitoramento de aplicações potencializados por RED metrics (Métricas de Taxa, Erros e Duração), além de rastreamento de agentes de IA utilizando convenções semânticas OpenTelemetry para IA generativa. Isso permite que times de operação correlacionem rastreamentos lentos com logs de aplicação, sobreponham métricas do Prometheus em dashboards de serviços e rastreiem a execução de agentes LLM, tudo sem necessidade de trocar de ferramentas.

Economia de Custos e Performance

A arquitetura de consulta em tempo real entrega redução significativa de custos comparada a plataformas premium, mantendo excelência operacional. Times podem consolidar sua stack de observabilidade sem os custos de duplicação de dados ou a perda de produtividade causada pela troca constante entre múltiplas ferramentas.

Disponibilidade Regional

A nova experiência unificada de observabilidade está disponível na interface do OpenSearch em 20 regiões da AWS: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm), Canada (Central) e South America (São Paulo).

Próximos Passos

Para aprofundar-se sobre essa capacidade, a AWS disponibiliza documentação técnica completa. Você pode acessar a documentação de observabilidade do OpenSearch Service e a documentação sobre consultas diretas para detalhes de implementação e configuração.

Fonte

Amazon OpenSearch Service supports Managed Prometheus and agent tracing (https://aws.amazon.com/about-aws/whats-new/2026/04/opensearch-managed-prometheus-agent-tracing/)

Interatividade Bidimensional em Agentes de IA

A construção de agentes de IA oferece desafios significativos quando os fluxos de trabalho precisam pausar durante a execução para solicitar esclarecimentos ao usuário, gerar conteúdo via modelo de linguagem ou fornecer atualizações de progresso em operações de longa duração. Até recentemente, servidores MCP sem estado não conseguiam lidar com esses cenários, criando uma limitação fundamental para aplicações reais.

A AWS identificou essa lacuna e anunciou novidades importantes. O Amazon Bedrock AgentCore Runtime agora oferece suporte a três capacidades do cliente definidas na especificação MCP (Protocolo de Contexto de Modelo):

• Elicitação: solicitação de entrada do usuário durante a execução
• Amostragem: solicitação de conteúdo gerado por LLM do cliente
• Notificações de progresso: transmissão de atualizações em tempo real

Essas capacidades transformam a execução de ferramentas em sentido único em conversas bidirecionais entre o servidor MCP e os clientes.

Do Stateless ao Stateful: Uma Evolução Necessária

O Modelo Anterior: Stateless MCP

A implementação anterior do suporte MCP no AgentCore funcionava em modo sem estado: cada requisição HTTP era independente, sem contexto compartilhado entre chamadas. Esse modelo é simples de implementar e funciona bem para servidores de ferramentas que recebem entradas e retornam saídas.

Porém, possui uma restrição fundamental. O servidor não consegue manter uma conversa entre requisições, solicitar esclarecimentos do usuário durante a execução de uma ferramenta ou reportar progresso conforme o trabalho ocorre.

O Novo Paradigma: Stateful MCP

O modo stateful remove essas limitações. Quando você executa seu servidor MCP com stateless_http=False, o AgentCore Runtime provisiona uma máquina virtual dedicada para cada sessão de usuário. Essa máquina virtual persiste pela duração da sessão (até 8 horas, ou 15 minutos de inatividade conforme a configuração idleRuntimeSessionTimeout), com isolamento de CPU, memória e sistema de arquivos entre sessões.

O protocolo mantém a continuidade através de um header Mcp-Session-Id: o servidor retorna este identificador durante o handshake de inicialização, e o cliente o inclui em toda requisição subsequente para rotear de volta à mesma sessão.

A mudança de configuração para ativar o modo stateful é um único parâmetro na inicialização do servidor:

mcp.run(
    transport="streamable-http",
    host="0.0.0.0",
    port=8000,
    stateless_http=False  # Ativa modo stateful
)

Além desse parâmetro, as três capacidades do cliente ficam disponíveis automaticamente quando o cliente MCP declara suporte durante o handshake de inicialização.

Três Capacidades Essenciais para Workflows Produtivos

Elicitação: Coletando Entrada do Usuário em Tempo Real

A elicitação permite que um servidor pause a execução e solicite entrada estruturada do usuário através do cliente. A ferramenta consegue fazer perguntas direcionadas no momento certo do fluxo, coletando preferências, confirmando decisões ou reunindo valores que dependem de resultados anteriores.

O servidor envia uma requisição elicitation/create com uma mensagem e um esquema JSON opcional descrevendo a estrutura de resposta esperada. O cliente renderiza uma interface de entrada apropriada, e o usuário pode aceitar (fornecendo os dados), declinar ou cancelar.

Um exemplo prático é a ferramenta add_expense_interactive, que coleta uma despesa através de quatro etapas sequenciais de elicitação: valor, descrição, categoria e confirmação final antes de escrever no Amazon DynamoDB.

import os
from pydantic import BaseModel
from fastmcp import FastMCP, Context
from fastmcp.server.elicitation import AcceptedElicitation
from dynamo_utils import FinanceDB

mcp = FastMCP(name='ElicitationMCP')
_region = os.environ.get('AWS_REGION') or os.environ.get('AWS_DEFAULT_REGION') or 'us-east-1'
db = FinanceDB(region_name=_region)

class AmountInput(BaseModel):
    amount: float

class DescriptionInput(BaseModel):
    description: str

class CategoryInput(BaseModel):
    category: str

class ConfirmInput(BaseModel):
    confirm: str

@mcp.tool()
async def add_expense_interactive(user_alias: str, ctx: Context) -> str:
    """Interactively add a new expense using elicitation."""
    result = await ctx.elicit('How much did you spend?', AmountInput)
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    amount = result.data.amount

    result = await ctx.elicit('What was it for?', DescriptionInput)
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    description = result.data.description

    result = await ctx.elicit(
        'Select a category (food, transport, bills, entertainment, other):',
        CategoryInput
    )
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    category = result.data.category

    confirm_msg = (
        f'Confirm: add expense of ${amount:.2f} for {description}'
        f' (category: {category})? Reply Yes or No'
    )
    result = await ctx.elicit(confirm_msg, ConfirmInput)
    if not isinstance(result, AcceptedElicitation) or result.data.confirm != 'Yes':
        return 'Expense entry cancelled.'
    
    return db.add_transaction(user_alias, 'expense', -abs(amount), description, category)

if __name__ == '__main__':
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=False
    )

No cliente, registrar um elicitation_handler tanto ativa o handler quanto declara suporte ao servidor durante a inicialização. Cada await ctx.elicit() suspende a ferramenta e envia uma requisição elicitation/create sobre a sessão ativa. A verificação isinstance(result, AcceptedElicitation) trata declínio e cancelamento uniformemente em cada etapa.

Use elicitação quando sua ferramenta precisa de informações que dependem de resultados anteriores, são melhor coletadas interativamente do que antecipadamente, ou variam entre usuários de forma que não pode ser parametrizada de antemão.

Amostragem: Delegando Geração de Conteúdo ao LLM do Cliente

A amostragem permite que um servidor MCP solicite uma conclusão gerada por LLM do cliente. O servidor envia uma requisição sampling/createMessage contendo uma lista de mensagens de conversa, um prompt do sistema e preferências opcionais de modelo. O cliente encaminha a requisição para seu modelo de linguagem conectado e retorna a resposta gerada.

O grande diferencial é que o servidor não precisa de chaves de API ou integração direta com modelo. O cliente retém controle total sobre qual modelo é usado, e a especificação MCP prevê uma etapa de verificação humana onde usuários podem revisar e aprovar requisições de amostragem antes do envio.

Um exemplo prático é a ferramenta analyze_spending, que recupera transações do DynamoDB, constrói um prompt com os dados estruturados e delega a análise ao LLM do cliente:

@mcp.tool()
async def analyze_spending(user_alias: str, ctx: Context) -> str:
    """Fetch expenses from DynamoDB and ask the client's LLM to analyse them."""
    transactions = db.get_transactions(user_alias)
    if not transactions:
        return f'No transactions found for {user_alias}.'
    
    lines = '\n'.join(
        f"- {t['description']} (${abs(float(t['amount'])):.2f}, {t['category']})"
        for t in transactions
    )
    prompt = (
        f'Here are the recent expenses for a user:\n{lines}\n\n'
        f'Please analyse the spending patterns and give 3 concise, '
        f'actionable recommendations to improve their finances. '
        f'Keep the response under 120 words.'
    )
    
    ai_analysis = 'Analysis unavailable.'
    try:
        response = await ctx.sample(messages=prompt, max_tokens=300)
        if hasattr(response, 'text') and response.text:
            ai_analysis = response.text
    except Exception:
        pass
    
    return f'Spending Analysis for {user_alias}:\n\n{ai_analysis}'

No cliente, o sampling_handler recebe o prompt do servidor e o encaminha a um modelo de linguagem. Registrar o handler também é como o cliente declara suporte de amostragem ao servidor durante inicialização.

Use amostragem quando sua ferramenta deve produzir saída em linguagem natural que se beneficia das capacidades de um modelo de linguagem. Um exemplo: ferramenta que coletou preferências de viagem do usuário e quer gerar uma narrativa de itinerário personalizada. Amostragem não é apropriada para operações determinísticas como consultas a banco de dados ou cálculos com saídas bem definidas — use lógica de ferramenta para esses casos.

Notificações de Progresso: Visibilidade em Tempo Real

As notificações de progresso são eventos que um servidor emite durante operações de longa duração para manter o cliente e o usuário informados sobre quanto trabalho foi concluído. await ctx.report_progress(progress, total) emite uma mensagem notifications/progress e retorna imediatamente. O servidor não espera por resposta — é fire-and-forget em ambas as direções.

O padrão é chamar report_progress em cada etapa lógica de uma operação multi-estágio, com o progresso incrementando em direção ao total. A ferramenta generate_report constrói um relatório financeiro mensal em cinco etapas, emitindo notificação de progresso no início de cada uma:

import os
from fastmcp import FastMCP, Context
from dynamo_utils import FinanceDB

mcp = FastMCP(name='Progress-MCP-Server')
_region = os.environ.get('AWS_REGION') or os.environ.get('AWS_DEFAULT_REGION') or 'us-east-1'
db = FinanceDB(region_name=_region)

@mcp.tool()
async def generate_report(user_alias: str, ctx: Context) -> str:
    """Generate a monthly financial report, streaming progress at each stage."""
    total = 5
    
    # Step 1: Fetch transactions
    await ctx.report_progress(progress=1, total=total)
    transactions = db.get_transactions(user_alias)
    
    # Step 2: Group by category
    await ctx.report_progress(progress=2, total=total)
    by_category = {}
    for t in transactions:
        cat = t['category']
        by_category[cat] = by_category.get(cat, 0) + abs(float(t['amount']))
    
    # Step 3: Fetch budgets
    await ctx.report_progress(progress=3, total=total)
    budgets = {b['category']: float(b['monthly_limit']) for b in db.get_budgets(user_alias)}
    
    # Step 4: Compare spending vs budgets
    await ctx.report_progress(progress=4, total=total)
    lines = []
    for cat, spent in sorted(by_category.items(), key=lambda x: -x[1]):
        limit = budgets.get(cat)
        if limit:
            pct = (spent / limit) * 100
            status = 'OVER' if spent > limit else 'OK'
            lines.append(f' {cat:<15} ${spent:>8.2f} / ${limit:.2f} [{pct:.0f}%] {status}')
        else:
            lines.append(f' {cat:<15} ${spent:>8.2f} (no budget set)')
    
    # Step 5: Format and return
    await ctx.report_progress(progress=5, total=total)
    total_spent = sum(by_category.values())
    
    return (
        f'Monthly Report for {user_alias}\n'
        f'{"=" * 50}\n'
        f' {"Category":<15} {"Spent":>10} {"Budget":>8} Status\n'
        f'{"-" * 50}\n'
        + '\n'.join(lines)
        + f'\n{"-" * 50}\n'
        f' {"TOTAL":<15} ${total_spent:>8.2f}\n'
    )

if __name__ == '__main__':
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=False
    )

No cliente, o progress_handler recebe progresso, total e uma mensagem opcional cada vez que o servidor emite notificação. O cliente consegue renderizar uma barra de progresso ou indicador de status, mantendo o usuário informado em vez de observar uma tela em branco.

Use notificações de progresso para qualquer chamada de ferramenta que leva mais alguns segundos e envolve etapas discretas mensuráveis. Operações como buscar em múltiplas fontes de dados, executar sequências de chamadas de API, processar lotes de registros ou executar fluxos de reserva multi-etapa são bons candidatos. Uma ferramenta que completa em menos de um segundo geralmente não precisa de relatório de progresso.

Primeiros Passos na Prática

Para começar a explorar essas capacidades, a AWS disponibiliza recursos técnicos de referência. O código de exemplo no GitHub inclui configuração completa do DynamoDB e deployment no AgentCore. A documentação do Amazon Bedrock AgentCore Runtime oferece guias detalhados, enquanto a documentação de funcionalidades stateful do MCP cobre especificações técnicas. Também recomenda-se consultar a especificação completa do MCP para entender o protocolo subjacente.

A implementação dessas capacidades representa evolução significativa na construção de agentes de IA interativos, oferecendo infraestrutura gerenciada e isolada para workflows bidirecionais.

Fonte

Introducing stateful MCP client capabilities on Amazon Bedrock AgentCore Runtime (https://aws.amazon.com/blogs/machine-learning/introducing-stateful-mcp-client-capabilities-on-amazon-bedrock-agentcore-runtime/)

Por que incorporar Live View em sua aplicação

Quando você constrói aplicações com IA, uma questão fundamental emerge: como seus usuários podem confiar em agentes que navegam de forma autônoma pela web? Quando um agente interage com conteúdo web por conta própria, os usuários precisam enxergar o que está acontecendo para manter controle e confiança — capacidades que hoje faltam na maioria das implementações.

A Amazon Bedrock AgentCore Browser agora oferece uma solução para esse desafio através do componente BrowserLiveView. Este componente fornece um feed de vídeo em tempo real da sessão de navegação do agente diretamente dentro de sua aplicação React. Trata-se de um recurso que faz parte do Bedrock AgentCore TypeScript SDK, permitindo que você integre um stream de browser ao vivo com apenas três linhas de código.

O componente BrowserLiveView utiliza o protocolo Amazon DCV para renderizar a sessão do browser, criando transparência completa das ações do agente. A implementação requer apenas uma URL pré-assinada do seu servidor, sem necessidade de construir infraestrutura de streaming do zero.

Incorporar o Live View dentro de sua própria aplicação desbloqueia valor adicional para seus usuários em escala. Com o Live View embutido, seus usuários acompanham cada navegação, cada envio de formulário e cada busca conforme o agente as realiza. Eles recebem confirmação visual imediata de que o agente está na página correta, interagindo com os elementos apropriados e avançando pelo fluxo de trabalho.

Essa retroalimentação em tempo real oferece aos usuários finais visibilidade direta do comportamento do agente sem ter que esperar pelo resultado final. Usuários que delegam tarefas de navegação para um agente de IA sentem-se mais seguros quando conseguem observar o trabalho acontecendo. Observar o agente preenchendo um formulário campo por campo é mais tranquilizador do que receber apenas uma confirmação textual.

Para fluxos de trabalho regulamentados, a evidência visual das ações do agente pode atender a requisitos de auditoria. Em workflows que exigem supervisão humana — como lidar com contas de clientes e processar dados sensíveis — um supervisor pode utilizar o Live View embutido para observar o agente em tempo real e intervir se necessário, tudo sem sair de sua aplicação.

As organizações também ganham suporte a trilhas de auditoria através de evidência visual das ações do agente, valor essencial para conformidade regulatória e cenários de troubleshooting. Combinada com gravações de sessão para Amazon Simple Storage Service (Amazon S3) e replay de sessão baseado em console, você obtém tanto observação em tempo real quanto revisão posterior.

Como funciona a arquitetura

A integração possui três componentes principais:

No browser do usuário: Uma aplicação React contém o componente BrowserLiveView, que recebe uma URL pré-assinada com credenciais SigV4 e estabelece uma conexão WebSocket persistente para receber o stream de vídeo DCV da sessão de browser remoto. A aplicação React gerencia a renderização de vídeo e apresentação da interface enquanto mantém a conexão WebSocket para streaming contínuo.

No servidor de aplicação: Funciona como um agente de IA dentro do ciclo de vida da sessão Amazon Bedrock, orquestrando a conexão entre browsers do cliente e sessões de browser hospedadas na nuvem. Ele inicia sessões usando a API Amazon Bedrock AgentCore e gera URLs pré-assinadas com SigV4 que concedem acesso seguro e limitado no tempo ao stream Live View. Esta camada gerencia autenticação, autenticação e distribuição de stream.

Na nuvem AWS: Hospeda Amazon Bedrock AgentCore Browser e serviços Amazon Bedrock que fornecem as capacidades subjacentes de automação de browser e streaming. O Amazon Bedrock AgentCore hospeda as sessões de browser isoladas dentro da nuvem AWS, oferecendo tanto o endpoint de automação (usando o Playwright Chrome DevTools Protocol) quanto o endpoint de streaming Live View (DCV).

A vantagem de eficiência-chave nesta arquitetura é que o stream Live View DCV flui diretamente de Amazon Bedrock AgentCore para o browser do usuário. Ele não passa pelo seu servidor de aplicação. Seu servidor gera a URL e executa o agente, mas o stream de vídeo é uma conexão WebSocket direta da AWS para o cliente. Isso ajuda a minimizar latência e reduzir requisitos de infraestrutura.

Implementação passo a passo

Pré-requisitos

Antes de começar, verifique se você possui:

• Node.js 20 ou posterior
• Uma conta AWS em uma região AWS suportada
• Credenciais AWS com permissões Amazon Bedrock AgentCore Browser
• Acesso a um modelo de IA para dirigir o agente (este artigo usa a Amazon Bedrock Converse API com Anthropic Claude, mas Live View é agnóstico a modelo e você pode usar qualquer provedor ou framework de sua escolha)

Observação importante: Live View (Passos 1 e 2) requer apenas permissões Amazon Bedrock AgentCore. Ele não depende de Amazon Bedrock ou nenhum modelo de IA específico. O agente de IA no Passo 3 usa a Amazon Bedrock Converse API, que requer permissões adicionais de Amazon Bedrock, mas isto é específico ao nosso exemplo. Você pode substituir por um provedor de modelo ou framework de agente de sua escolha.

Use credenciais temporárias do AWS IAM Identity Center ou AWS Security Token Service (AWS STS). Não use chaves de acesso de longa duração. Siga o princípio do menor privilégio ao configurar permissões AWS Identity and Access Management (IAM).

Instale o Amazon Bedrock AgentCore TypeScript SDK:

npm install bedrock-agentcore

Para o agente de IA no Passo 3, você também precisa do AWS SDK para JavaScript:

npm install @aws-sdk/client-bedrock-runtime

O código neste artigo executa em dois ambientes: código servidor (Passos 1 e 3) executa em Node.js, e código cliente (Passo 2) executa em uma aplicação React empacotada com Vite.

Passo 1: Inicie uma sessão de browser e gere a URL Live View

No seu servidor de aplicação, use a classe Browser para iniciar uma sessão e gerar a URL pré-assinada. A API retorna um identificador de sessão e URL de streaming, que o servidor converte em uma URL pré-assinada com tempo de expiração definido (300 segundos por padrão). Ela contém credenciais SigV4 nos parâmetros de query, portanto nenhum segredo atinge o browser. Passe esta URL para seu frontend através de um endpoint de API.

import { Browser } from 'bedrock-agentcore/browser'

const browser = new Browser({ region: 'us-west-2' })

await browser.startSession({ viewport: { width: 1920, height: 1080 } })

const signedUrl = await browser.generateLiveViewUrl()

// Send signedUrl to your frontend via API

Passo 2: Renderize o componente BrowserLiveView em sua aplicação React

No seu browser, importe o componente BrowserLiveView do Bedrock AgentCore TypeScript SDK e renderize-o com a URL pré-assinada. O componente gerencia conexão WebSocket, negociação do protocolo DCV, decodificação do stream de vídeo e renderização de frames. Ele se adapta automaticamente para caber em seu container pai enquanto preserva a proporção de aspecto. Os valores remoteWidth e remoteHeight devem corresponder ao viewport definido no Passo 1. Valores incompatíveis causam corte ou barras pretas.

import { BrowserLiveView } from 'bedrock-agentcore/browser/live-view'

Após adicionar este componente, o Live View começa a fazer streaming assim que a URL pré-assinada é válida e a sessão de browser está ativa. Você deve ver o desktop do browser remoto aparecer dentro do container do componente. Se o container permanecer vazio, verifique se a URL pré-assinada não expirou e se a sessão de browser ainda está em execução.

Passo 3: Conecte um agente de IA para dirigir as ações do browser

Com o Live View já fazendo streaming, você precisa de algo interessante para observar. O exemplo a seguir usa a Amazon Bedrock Converse API, mas Live View é agnóstico a modelo. Você pode usar um modelo de IA ou framework de agente de sua escolha para dirigir o browser. O código cria um cliente PlaywrightBrowser, que inicia uma nova sessão AgentCore Browser e se conecta a ela usando o protocolo Playwright Chrome DevTools. Trata-se do mesmo tipo de sessão de browser em nuvem do Passo 1, mas acessado através da interface de automação Playwright em vez da interface Live View. O modelo decide quais ferramentas de browser chamar, incluindo navigate, click, type, getText, getHtml e pressKey. Seu servidor executa essas ferramentas e alimenta os resultados de volta ao modelo para a próxima iteração.

import { BedrockRuntimeClient, ConverseCommand } from '@aws-sdk/client-bedrock-runtime'
import { PlaywrightBrowser } from 'bedrock-agentcore/browser/playwright'

const browser = new PlaywrightBrowser({ region: 'us-west-2' })

await browser.startSession()

// Define browser tools as JSON Schema
// (navigate, click, type, getText, and more)

while (step < maxSteps) {
  const response = await bedrockClient.send(
    new ConverseCommand({
      modelId: modelId,
      system: [{ text: systemPrompt }],
      messages,
      toolConfig: browserTools,
    })
  )

  if (response.stopReason === 'tool_use') {
    // Run browser tool, add result
    // to conversation, continue loop
  } else {
    break // Final answer from model
  }
}

O modelo é configurável. Você pode usar Anthropic Claude, Amazon Nova ou outro modelo Amazon Bedrock que suporte uso de ferramentas. Cada chamada de ferramenta que o modelo faz fica visível ao seu usuário através do Live View. Ele vê o browser navegar, a caixa de busca preencher e a página de resultados carregar.

Observação: O TypeScript SDK também inclui uma integração Vercel AI SDK (BrowserTools) que envolve essas operações de browser como ferramentas nativas do framework.

Testando com a aplicação de exemplo

A AWS construiu uma aplicação de exemplo completa no GitHub que integra os Passos 1–3. A amostra inclui um dashboard React com o Live View embutido, um log de atividades mostrando raciocínio e ações do agente, e um servidor Fastify executando o agente de IA. O agente navega para Wikipedia, busca um tópico, lê o conteúdo da página e resume o que encontra enquanto você observa cada passo.

Clonando e executando a aplicação de exemplo

Siga os passos abaixo para clonar e executar a aplicação de exemplo:

Etapa 1: Clone o repositório e navegue para a pasta de exemplo.

git clone https://github.com/awslabs/bedrock-agentcore-samples-typescript.git
cd bedrock-agentcore-samples-typescript
cd use-cases/browser-live-view-agent

Etapa 2: Instale as dependências.

npm install

Etapa 3: Exporte suas credenciais AWS.

export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export AWS_SESSION_TOKEN=
export AWS_REGION=us-west-2

Importante: Use credenciais temporárias. Não faça commit de credenciais no controle de versão.

Etapa 4: Inicie a aplicação.

npm run dev

Etapa 5: Abra http://localhost:5173, digite um prompt e escolha Launch Agent.

Configuração do bundler

O componente BrowserLiveView utiliza o Amazon DCV Web Client SDK, que distribui arquivos vendored dentro do pacote npm bedrock-agentcore. Você não precisa baixar ou instalar DCV separadamente. Sua configuração Vite precisa de três adições:

• resolve.alias aponta os identificadores bare dcv e dcv-ui para os arquivos SDK vendored.
• resolve.dedupe verifica que React e dependências compartilhadas são resolvidas de seu node_modules, não do caminho vendored.
• viteStaticCopy copia os arquivos de runtime DCV (workers, decodificadores WASM) para sua saída de build.

O arquivo vite.config.ts da aplicação de exemplo possui a configuração completa pronta para usar. Para mais detalhes sobre o componente BrowserLiveView, consulte a pasta source live-view no TypeScript SDK.

Limpando recursos

Para evitar incorrer em cobranças, pare a sessão de browser e desligue a aplicação quando terminar:

• Na interface da aplicação, escolha Stop Session para encerrar a sessão Amazon Bedrock AgentCore Browser.
• No seu terminal, pressione Ctrl+C para parar os servidores de desenvolvimento.
• Se você criou funções ou políticas IAM especificamente para esta demonstração, delete-as do console IAM.

As sessões Amazon Bedrock AgentCore Browser incorrem em cobranças enquanto ativas. Para detalhes de preços, consulte a página de preços Amazon Bedrock AgentCore.

Próximos passos

Agora que você tem uma integração Live View funcional, aqui estão algumas coisas para explorar.

Para começar, clone a aplicação de exemplo, preencha suas credenciais AWS e execute npm run dev para ver a demonstração completa em ação. Para instruções, consulte a seção Como clonar e executar a aplicação de exemplo neste artigo.

A aplicação de exemplo usa Anthropic Claude por padrão, mas você pode trocar para Amazon Nova ou outro modelo Amazon Bedrock que suporte uso de ferramentas definindo a variável de ambiente BEDROCK_MODEL_ID. Para uma lista de modelos disponíveis e suas capacidades de uso de ferramentas, consulte a documentação de modelos Amazon Bedrock.

O dashboard React na aplicação de exemplo é um ponto de partida para sua própria implementação. Você pode adaptar o layout para corresponder ao seu sistema de design, integrar o Live View em uma aplicação existente ou adicionar controles que permitam aos usuários intervir no meio do fluxo de trabalho. Para orientação sobre construção de aplicações React com o AgentCore SDK, consulte a documentação do Bedrock AgentCore TypeScript SDK.

O componente BrowserLiveView suporta múltiplas instâncias na mesma página, cada uma fazendo streaming de uma sessão de browser diferente. Esta capacidade é útil para dashboards de monitoramento. O código-fonte do componente, incluindo lógica de scaling e fluxo de autenticação DCV, está disponível na pasta source live-view no TypeScript SDK.

Conclusão

Neste artigo, você aprendeu como usar o componente BrowserLiveView para incorporar uma visualização ao vivo de uma sessão Amazon Bedrock AgentCore Browser dentro de sua aplicação React. A implementação em três passos e a arquitetura que transmite vídeo diretamente da AWS para browsers do cliente tornam a visualização de agentes ao vivo acessível sem necessidade de expertise em streaming especializado.

Para uma análise mais profunda das capacidades de Amazon Bedrock AgentCore Browser, consulte a documentação Amazon Bedrock AgentCore Browser. Se tiver feedback ou perguntas, abra uma issue no repositório GitHub.

Importante: Esta aplicação de exemplo destina-se a desenvolvimento local e demonstração. Para uso em produção, adicione autenticação aos seus endpoints de API, habilite HTTPS, restrinja origens CORS, implemente rate limiting e siga o pilar de segurança da AWS Well-Architected Framework.

Fonte

Embed a live AI browser agent in your React app with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/embed-a-live-ai-browser-agent-in-your-react-app-with-amazon-bedrock-agentcore/)

Por Que Entender o Ciclo de Vida dos Modelos?

A AWS libera regularmente novas versões de modelos de fundação (FM – Foundation Models) no Bedrock, trazendo melhorias em capacidades, precisão e segurança. Para quem constrói aplicações de IA sobre essa plataforma, compreender como funcionam essas transições entre versões é fundamental. Não se trata apenas de ficar atualizado: é sobre garantir que suas aplicações continuem funcionando conforme os modelos evoluem, planejando migrações de forma estratégica e sem interrupções indesejadas.

Antes de migrar suas aplicações para novos modelos, você pode testá-los através do console do Amazon Bedrock ou via API para avaliar desempenho e compatibilidade. Este guia explora como gerenciar essas transições de forma planejada, abordando os três estados do ciclo de vida, a nova feature de acesso estendido e práticas concretas para transicionar suas aplicações sem disrupções.

Os Três Estados do Ciclo de Vida

Um modelo oferecido no Amazon Bedrock pode existir em um dos três estados: Ativo, Legado ou Fim de Vida (End-of-Life – EOL). O status atual é visível tanto no console do Amazon Bedrock quanto nas respostas das APIs. Por exemplo, quando você faz uma chamada GetFoundationModel ou ListFoundationModels, o estado do modelo aparece no campo modelLifecycle da resposta.

Estado Ativo (Active)

Modelos ativos recebem manutenção contínua, atualizações e correções de bugs dos seus fornecedores. Enquanto um modelo está neste estado, você pode utilizá-lo para inferência através de APIs como InvokeModel ou Converse, personalizá-lo caso suportado e solicitar aumentos de cota através do AWS Service Quotas.

Estado Legado (Legacy)

Quando um fornecedor de modelo transiciona para o estado Legado, a AWS notifica seus clientes com no mínimo 6 meses de antecedência em relação à data de EOL, proporcionando tempo essencial para planejar e executar a migração. Durante esse período, clientes existentes podem continuar usando o modelo, embora novos clientes possam não ter acesso. Clientes existentes podem perder acesso se suas contas ficar inativas por 15 dias ou mais sem chamar o modelo.

Organizações devem estar cientes de que criar novo throughput provisionado (provisioned throughput) por unidades de modelo deixa de estar disponível, e capacidades de customização do modelo podem sofrer restrições.

Para modelos com data de EOL após 1º de fevereiro de 2026, a AWS introduz uma fase adicional dentro do estado Legado:

Período de Acesso Estendido Público (Public Extended Access Period)

Após permanecer no mínimo 3 meses em status Legado, o modelo entra nessa fase de acesso estendido. Usuários ativos podem continuar usando por no mínimo mais 3 meses até o EOL. Durante esse período, solicitações de aumento de cota via AWS Service Quotas não devem ser aprovadas — é importante planejar suas necessidades de capacidade antes dessa fase. O preço pode ser ajustado, e você receberá notificações sobre a data de transição e qualquer mudança.

Estado Fim de Vida (End-of-Life – EOL)

Quando um modelo atinge sua data de EOL, torna-se completamente inacessível em todas as regiões da AWS, a menos que especificamente listado no EOL list. Requisições de API para modelos em EOL falharão, deixando-os indisponíveis para a maioria dos clientes, a menos que exista arranjo especial entre cliente e fornecedor. A transição para EOL requer ação proativa do cliente — a migração não ocorre automaticamente. Você deve atualizar o código da sua aplicação para usar modelos alternativos antes que a data de EOL chegue.

Cronograma Mínimo de Disponibilidade

Após o lançamento no Amazon Bedrock, um modelo permanece disponível por no mínimo 12 meses e fica em estado Legado por pelo menos 6 meses antes do EOL. Esse timeline ajuda os clientes a planejar migrações sem pressão de urgência.

Preços Durante Acesso Estendido

Durante o período de acesso estendido, o fornecedor do modelo pode ajustar preços. Se mudanças de preço estiverem planejadas, você será notificado no anúncio inicial de legado e antes que qualquer mudança entre em vigor — não haverá aumentos retroativos surpresa.

Clientes com acordos de preço privado com fornecedores ou aqueles usando throughput provisionado continuarão operando sob seus termos de preço atuais durante esse período. Isso garante que clientes que fizeram arranjos específicos com fornecedores ou investiram em capacidade provisionada não sejam afetados inesperadamente.

Como Você é Notificado sobre Mudanças

Clientes recebem notificação 6 meses antes da data de EOL de um modelo quando o fornecedor o transiciona para estado Legado. Essa abordagem proativa garante tempo suficiente para planejar e executar estratégias de migração. As notificações incluem detalhes do modelo sendo descontinuado, datas importantes, disponibilidade de acesso estendido e quando o modelo chegará ao EOL.

A AWS usa múltiplos canais para garantir que essas comunicações importantes alcancem as pessoas certas:

• Notificações por email
• Alertas no AWS Health Dashboard
• Alertas no console do Amazon Bedrock
• Acesso programático via API

Para garantir que você receba essas notificações, verifique e configure os endereços de email de contato da sua conta. Por padrão, notificações são enviadas para o email do usuário root da sua conta e para contatos alternativos (operações, segurança e billing). Você pode revisar e atualizar esses contatos na página da sua conta AWS na seção Alternate contacts.

Para adicionar recipients adicionais ou canais de entrega (como Slack ou listas de distribuição de email), acesse o console de Notificações da AWS e escolha AWS managed notifications subscriptions para gerenciar seus canais de entrega e contatos da conta. Se não estiver recebendo notificações esperadas, verifique que seus endereços de email estejam configurados corretamente e que emails de health@aws.com não estejam sendo filtrados pelo seu provedor de email.

Estratégias e Boas Práticas de Migração

Ao migrar para um novo modelo, você precisa atualizar o código da aplicação e verificar que suas cotas de serviço conseguem lidar com o volume esperado. Planejar com antecedência ajuda a transição suave com disrupção mínima.

Planejando sua Linha do Tempo de Migração

Comece a planejar assim que um modelo entra em estado Legado. O processo se desdobra em fases:

Fase de Avaliação: Avalie seu uso atual do modelo legado, incluindo quais aplicações dependem dele, padrões típicos de requisições e comportamentos ou saídas específicas que suas aplicações utilizam.

Fase de Pesquisa: Investigue o modelo de substituição recomendado, entendendo suas capacidades, diferenças em relação ao modelo legado, novas features que poderiam aprimorar suas aplicações e a disponibilidade regional do novo modelo. Revise mudanças de API e documentação.

Fase de Testes: Conduza testes minuciosos com o novo modelo e compare métricas de desempenho entre eles. Isso ajuda a identificar ajustes necessários no código da aplicação ou na engenharia de prompts.

Fase de Migração: Implemente mudanças usando uma abordagem de deployment faseado. Monitore o desempenho do sistema durante a transição e mantenha capacidade de rollback.

Fase Operacional: Após migração, monitore continuamente suas aplicações e feedback de usuários para garantir que estejam performando como esperado com o novo modelo.

Passos Técnicos de Migração

Teste sua migração minuciosamente seguindo estes passos:

Atualize referências de API: Modifique o código da sua aplicação para referenciar o novo ID do modelo. Por exemplo, mudando de anthropic.claude-3-5-sonnet-20240620-v1:0 para anthropic.claude-sonnet-4-5-20250929-v1:0 ou global cross-Region inference global.anthropic.claude-sonnet-4-5-20250929-v1:0. Atualize estruturas de prompt de acordo com as melhores práticas do novo modelo. Para orientação detalhada, consulte Migrate from Anthropic’s Claude Sonnet 3.x to Claude Sonnet 4.x on Amazon Bedrock.

Solicite aumentos de cota: Antes de migrar completamente, certifique-se de ter quotas suficientes para o novo modelo solicitando aumentos através do console AWS Service Quotas se necessário.

Ajuste prompts: Novos modelos podem responder diferentemente aos mesmos prompts. Revise e refine seus prompts de acordo com as especificações do novo modelo. Você também pode usar ferramentas como o prompt optimizer no Amazon Bedrock para ajudar a reescrever seu prompt para o modelo alvo.

Atualize tratamento de respostas: Se o novo modelo retorna respostas em formato diferente ou com características distintas, atualize sua lógica de parsing e processamento conforme necessário.

Otimize uso de tokens: Aproveite as melhorias de eficiência em modelos mais novos revisando e otimizando seus padrões de uso de tokens. Por exemplo, modelos que suportam prompt caching podem reduzir o custo e latência de suas invocações.

Estratégias de Testes

Testes minuciosos são críticos para uma migração bem-sucedida:

Comparação lado a lado: Execute as mesmas requisições contra o modelo legado e o novo para comparar saídas e identificar diferenças que possam afetar sua aplicação. Para ambientes de produção, considere shadow testing — enviando requisições duplicadas para o novo modelo junto ao modelo existente sem afetar usuários finais. Essa abordagem permite avaliar desempenho, latência, taxas de erro e outros fatores operacionais antes da migração completa.

Testes A/B: Conduza testes A/B para avaliar impacto em usuários rotacionando uma porcentagem controlada de tráfego ao vivo para o novo modelo enquanto monitora métricas-chave como engagement de usuário, taxas de conclusão de tarefas, scores de satisfação e KPIs de negócio.

Testes de desempenho: Meça tempos de resposta, uso de tokens e outras métricas de desempenho para entender como o novo modelo se compara à versão legada. Valide métricas de sucesso específicas do seu negócio.

Testes de regressão e casos extremos: Garanta que funcionalidades existentes continuam funcionando como esperado com o novo modelo. Dê atenção especial a inputs incomuns ou complexos que possam revelar diferenças em como os modelos lidam com cenários desafiadores.

Conclusão

A política de ciclo de vida de modelos no Amazon Bedrock oferece estágios bem definidos para gerenciar a evolução de modelos de fundação. Períodos de transição oferecem opções de acesso estendido, e disposições para modelos customizados ajudam a equilibrar inovação com estabilidade. Fique informado sobre estados de modelos através do AWS Health Dashboard, planeje migrações quando modelos entram em estado Legado e teste versões mais novas minuciosamente. Essas diretrizes ajudam a manter continuidade em suas aplicações de IA enquanto você aproveita as capacidades melhoradas em modelos mais recentes.

Para aprendizado continuado e suporte de implementação, explore a documentação oficial do AWS Bedrock com guias abrangentes e referências de API. Além disso, visite o AWS Machine Learning Blog e AWS Architecture Center para estudos de caso do mundo real, migration best practices e arquiteturas de referência que podem ajudar a otimizar sua estratégia de gerenciamento de ciclo de vida de modelos.

Fonte

Understanding Amazon Bedrock model lifecycle (https://aws.amazon.com/blogs/machine-learning/understanding-amazon-bedrock-model-lifecycle/)

Transformando Áudio em Conhecimento Buscável

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

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

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

Compreendendo Embeddings de Áudio: Conceitos Fundamentais

Representações Vetoriais do Conteúdo Sonoro

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

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

Medindo Similaridade Entre Áudios

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

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

Arquitetura de Processamento e Modalidades de Áudio

Fluxo de Trabalho Completo

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

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

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

Processamento de Sinais Acústicos

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

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

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

Quando Usar Geração Síncrona de Embeddings

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

Aqui está um exemplo:

import boto3
import json

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

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

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

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

Compreendendo Parâmetros de Requisição

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

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

Quando Usar Processamento Assíncrono

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

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

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

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

Segmentação e Metadados Temporais

Por Que Segmentação é Importante

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

"segmentationConfig": {
    "durationSeconds": 15
}

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

Entendendo Saída Segmentada

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

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

Armazenamento Vetorial e Estratégias de Indexação

Compreendendo Seus Requisitos de Armazenamento

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

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

Usando Amazon S3 Vectors

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

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

Usando Amazon OpenSearch Service

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

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

Por Que Processamento em Lote é Importante

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

Suporte Multilíngue

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

Amazon Nova: Especificações Técnicas Profundas

Arquitetura e Capacidades do Modelo

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

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

Fluxo de Trabalho Completo

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

Entradas Suportadas

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

Capacidades Principais

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

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

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

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

Quando Escolher Amazon Nova

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

Domínios de Aplicação Principal

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

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

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

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

Conclusão

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

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

Fonte

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

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

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

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

Onde o ajuste com reforço se destaca

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

Tarefas com critérios verificáveis automaticamente

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

Tarefas subjetivas com avaliação por modelo

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

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

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

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

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

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

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

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

Preparando dados de treinamento eficazes

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

Diretrizes de tamanho de dataset

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

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

Princípios de qualidade de dados

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

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

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

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

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

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

Projetando funções de recompensa eficazes

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

Recompensas para tarefas verificáveis

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

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

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

Recompensas baseadas em feedback de IA

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

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

Refinando design de funções de recompensa

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

Monitorando progresso de treinamento

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

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

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

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

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

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

Ajuste de hiperparâmetros: diretrizes práticas

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

Contagem de épocas

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

Tamanho de batch

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

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

Taxa de aprendizado

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

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

Comprimento de prompt e comprimento de resposta

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

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

Parada antecipada e intervalo de avaliação

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

Armadilhas comuns e como evitá-las

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

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

Próximos passos

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

Para começar:

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

Fonte

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

Nova funcionalidade de agendamento sincronizado no SageMaker HyperPod

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

Por que o gang scheduling importa

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

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

Como o gang scheduling resolve esses desafios

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

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

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

Disponibilidade regional

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

Próximos passos

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

Fonte

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