Blog

  • AWS Lambda expande suporte a streaming de respostas para todas as regiões comerciais

    Streaming de Respostas do Lambda agora disponível globalmente

    A AWS expandiu o suporte ao streaming de respostas do Lambda para todas as suas regiões comerciais, alcançando paridade completa desse recurso em toda sua infraestrutura global. Clientes nas regiões recém-suportadas agora podem utilizar a API InvokeWithResponseStream para transmitir progressivamente as respostas de funções Lambda de volta aos clientes conforme os dados ficam disponíveis.

    Como funciona o streaming de respostas

    O streaming de respostas permite que funções Lambda enviem respostas parciais aos clientes de forma incremental, em vez de acumular toda a resposta em memória antes de transmiti-la. Essa abordagem traz benefícios significativos para aplicações sensíveis à latência, particularmente na redução do tempo até o primeiro byte (TTFB) — um fator crítico na experiência do usuário.

    Casos de uso ideais

    Esse recurso é especialmente adequado para aplicações baseadas em grandes modelos de linguagem (LLM), bem como para aplicativos web e mobile. Em cenários assim, os usuários se beneficiam de ver as respostas aparecerem progressivamente na tela, melhorando a percepção de responsividade da aplicação.

    Capacidades técnicas

    O streaming de respostas da AWS Lambda suporta:

    • Payloads de até 200 MB por padrão
    • Acesso através da API InvokeWithResponseStream via SDK da AWS suportados
    • Integração com Amazon API Gateway através de REST APIs com streaming habilitado
    • Runtimes gerenciados do Node.js e runtimes customizados

    Considerações de custo

    É importante saber que o streaming de respostas gera custos adicionais relacionados à transferência de rede da resposta. A cobrança ocorre com base na quantidade de bytes gerados e transmitidos pela função Lambda, considerando apenas os primeiros 6 MB. Isso permite um controle mais previsível dos custos em aplicações que transmitem grandes volumes de dados.

    Próximos passos

    Desenvolvedores interessados em implementar streaming de respostas nas funções Lambda podem consultar a documentação técnica do AWS Lambda para obter detalhes de implementação e boas práticas.

    Fonte

    AWS Lambda expands response streaming support to all commercial AWS Regions (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-lambda-response-streaming/)

  • Podcasts conversacionais em tempo real com Amazon Nova 2 Sonic

    O desafio da produção de conteúdo em áudio

    Criadores de conteúdo e organizações enfrentam um desafio persistente: produzir áudio de alta qualidade em escala. A produção tradicional de podcasts exige investimento considerável de tempo — pesquisa, agendamento, gravação e edição — além de recursos substanciais como estúdios, equipamentos e talentos de voz. Essas restrições limitam a velocidade com que as organizações conseguem responder a novos tópicos ou escalar sua produção.

    O crescimento explosivo de podcasts transformou o medium de um nicho para formato de conteúdo mainstream. Essa expansão reflete a capacidade única dos podcasts de entregar informação durante atividades multitarefas — deslocamentos, exercício, afazeres domésticos — oferecendo acessibilidade que conteúdo visual não consegue alcançar.

    Contudo, a produção tradicional enfrenta desafios estruturais significativos:

    • Escalabilidade de conteúdo: Hosts humanos precisam de tempo extenso para pesquisa, agendamento, gravação e pós-produção, limitando frequência e volume de saídas.
    • Consistência: Hosts enfrentam conflitos de agendamento, doença, variações de energia e limitações de disponibilidade que criam cronogramas irregulares de publicação.
    • Personalização: Podcasts tradicionais seguem modelo único, incapazes de adaptar conteúdo a interesses ou níveis de conhecimento específicos em tempo real.
    • Eficiência de recursos: Produção de qualidade exige investimento contínuo em talento, equipamento, software de edição e custo operacional.
    • Acesso a especialistas: Garantir hosts conhecedores em diversos tópicos permanece desafiador e caro, restringindo amplitude e profundidade de conteúdo.

    Introdução ao Amazon Nova 2 Sonic

    A AWS desenvolveu o Amazon Nova 2 Sonic, um modelo de compreensão e geração de fala de última geração que oferece IA conversacional natural e humanizada com latência reduzida e desempenho de preço competitivo. O modelo processa entrada de fala e entrega saída de fala e transcrições de texto, criando conversas humanas com compreensão contextual rica.

    O Amazon Nova 2 Sonic oferece uma API de streaming para conversas multi-turno em tempo real e com baixa latência, permitindo que desenvolvedores construam aplicações orientadas por voz onde a fala impulsiona navegação, automação de fluxo de trabalho e conclusão de tarefas.

    Capacidades principais

    • Compreensão de fala com streaming: Processa e responde a fala em tempo real com latência reduzida.
    • Seguimento de instruções: Executa comandos de voz complexos e multi-etapas.
    • Invocação de ferramentas: Chama funções externas e APIs durante conversas.
    • Interação multi-modal: Alterna perfeitamente entre entrada/saída de voz e texto.
    • Suporte multilíngue: Nativo em inglês, francês, italiano, alemão, espanhol, português e hindi.
    • Janela de contexto grande: Suporta até 1 milhão de tokens para manter contexto de conversa estendida.

    O modelo é acessível através do Amazon Bedrock e pode ser integrado com recursos-chave da plataforma, incluindo Guardrails, Agents, Recuperação Aumentada por Geração (RAG) multimodal e Knowledge Bases para interoperabilidade contínua.

    A solução: gerador de podcasts live com Nova Sonic

    A AWS demonstra uma implementação prática que cria conversas naturais entre dois hosts de IA sobre qualquer tópico usando o modelo de fala para fala do Amazon Nova Sonic. Os usuários informam um tópico através de uma interface web, e a aplicação gera um diálogo multi-rodada com alternância de falantes transmitido em tempo real.

    Características principais da implementação

    • Geração de áudio com streaming em tempo real e latência reduzida.
    • Diálogo natural de mão dupla através de múltiplas rodadas de conversa.
    • Filtragem de conteúdo consciente de estágio que remove áudio duplicado.
    • Interface web simples com atualizações de conversa ao vivo.
    • Suporte para usuários simultâneos através de arquitetura AsyncIO.
    • Múltiplas personas de voz para diferentes casos de uso.

    Pré-requisitos

    Para implementar esta solução, os seguintes requisitos devem ser atendidos:

    • Conta AWS com acesso ao Amazon Bedrock e modelo Amazon Nova 2 Sonic.
    • Python 3.8 ou posterior.
    • Framework Flask e AsyncIO.
    • Credenciais AWS configuradas (chave de acesso, chave secreta, região AWS).
    • Ambiente de desenvolvimento com gerenciador pip.

    Detalhes de implementação e arquitetura

    Visão geral da arquitetura

    A solução segue uma arquitetura baseada em Flask com processamento de eventos de streaming e reativo, projetada para demonstrar as capacidades do Amazon Nova Sonic para fins de prova de conceito e educacional. Para amostras de código detalhadas e orientações de implementação completa, consulte o repositório no GitHub.

    Componentes da arquitetura

    A arquitetura segue uma abordagem em camadas com separação clara de responsabilidades:

    • Aplicação cliente: Hospeda três componentes fortemente acoplados que gerenciam o ciclo de vida completo do áudio. O motor PyAudio captura entrada de microfone em 16 kHz PCM e a transmite para o Amazon Bedrock. Também recebe áudio pronto para reprodução do fila de saída em 24 kHz PCM, tratando saída de falante em tempo real.
    • Processador de resposta: Recebe o fluxo de resposta bruto retornado pelo Amazon Nova Sonic, decodifica o payload de áudio codificado em Base64, e encaminha o áudio decodificado para a fila de saída.
    • Fila de saída de áudio: Atua como buffer entre o processador de resposta e o motor PyAudio, absorvendo respostas de latência variável e garantindo reprodução de áudio suave e ininterrupta.
    • Cloud AWS: Toda comunicação com modelo é executada através do Amazon Bedrock, que funciona como intermediário de um fluxo de evento bidirecional com Amazon Nova Sonic. O serviço recebe o fluxo de áudio PCM 16 kHz outbound do motor PyAudio e roteia para o modelo, carregando de volta o fluxo de resposta ao cliente. O Amazon Nova Sonic realiza inferência de fala para fala em tempo real e retorna um fluxo de resposta contendo áudio sintetizado codificado em Base64 PCM em 24 kHz.

    Nota sobre arquitetura em produção: Esta implementação usa Flask com PyAudio para fins de demonstração. O PyAudio não oferece cancelamento de eco integrado e é mais adequado para reprodução de áudio no servidor. Para aplicações web cliente em produção, recomenda-se bibliotecas de áudio baseadas em JavaScript (Web Audio API) ou WebRTC para tratamento de áudio nativo do navegador com melhor cancelamento de eco e latência reduzida. Consulte o repositório GitHub para padrões de arquitetura de produção.

    Integrações e componentes técnicos

    Integração com Amazon Bedrock: No coração do sistema está o BedrockStreamManager, um componente personalizado que gerencia conexões persistentes com o modelo Amazon Nova 2 Sonic. Este gerenciador lida com as complexidades das interações da API de streaming, incluindo inicialização, envio de mensagens e processamento de resposta. Credenciais AWS configuradas através de variáveis de ambiente mantêm acesso seguro ao modelo.

    Pipeline de streaming reativo: A aplicação utiliza RxPy (Reactive Extensions para Python) para implementar um padrão observável de tratamento de fluxos de dados em tempo real. Esta arquitetura reativa processa chunks de áudio e tokens de texto conforme chegam do Amazon Nova Sonic, em vez de aguardar respostas completas.

    Filtragem consciente de estágio: Uma inovação técnica-chave desta implementação é o mecanismo de filtragem consciente de estágio. O Amazon Nova 2 Sonic gera conteúdo em múltiplos estágios: ESPECULATIVO (preliminar) e FINAL (polido). A aplicação implementa lógica de filtragem inteligente que monitora eventos contentStart para metadados de estágio de geração, capturando apenas conteúdo no estágio FINAL para remover áudio duplicado ou preliminar, prevenindo artefatos de áudio para saída clara e natural.

    A filtragem opera em três níveis:

    • Filtro de conteúdo interrompido: Remove conteúdo cancelado verificando marcadores de interrupção.
    • Deduplicação de texto: Filtra texto exatamente duplicado entre estágios ESPECULATIVO e FINAL.
    • Deduplicação de hash de áudio: Filtra chunks de áudio duplicados usando fingerprinting de hash.

    Gerenciamento de conversa: O sistema implementa um modelo de conversa por turnos com múltiplas rodadas de diálogo. Cada turno segue um padrão consistente para fluxo natural de conversa: histórico é mantido através de variáveis específicas por falante para que cada falante possa referenciar o que foi dito anteriormente; prompts são construídos dinamicamente baseados em papel do falante e contexto de conversa; uma instância fresh de BedrockStreamManager é criada para cada turno de falante, prevenindo contaminação de estado entre turnos.

    Modelo de execução assíncrona: Para tratar a natureza bloqueante de reprodução de áudio e chamadas de API do modelo, a aplicação cria um novo event loop de asyncio para cada requisição de geração de podcast. Desta forma, múltiplos usuários podem gerar podcasts simultaneamente sem se bloquearem mutuamente. O loop gerencia inicialização de stream, envio de prompt, coordenação de reprodução de áudio e limpeza, suportando uso concorrente mantendo separação limpa entre sessões de usuário.

    Casos de uso

    Aprendizado interativo e compartilhamento de conhecimento

    Organizações lutam para criar conteúdo envolvente que ajude pessoas a aprender e reter informação, seja para educação de estudantes ou treinamento de funcionários. Instâncias do Amazon Nova 2 Sonic podem simular discussões de sala de aula ou diálogos socráticos, com uma instância fazendo perguntas enquanto a outra fornece explicações e exemplos. Para instituições educacionais, isto cria experiências dinâmicas de aprendizado que acomodam diferentes estilos e ritmos de aprendizagem. Para empresas, transforma comunicações internas — políticas, procedimentos, mudanças organizacionais — em formatos conversacionais que funcionários podem consumir enquanto multitarefam.

    Integração com Recuperação Aumentada por Geração (RAG) e Knowledge Bases do Amazon Bedrock mantém conteúdo atual e alinhado com currículo ou requisitos organizacionais, enquanto o formato conversacional aumenta retenção de informação e reduz perguntas de acompanhamento.

    Localização de conteúdo multilíngue

    Organizações globais precisam de mensagens consistentes entre mercados respeitando nuances culturais. O suporte do Amazon Nova Sonic para inglês, francês, italiano, alemão, espanhol, português e hindi permite criação de conteúdo de áudio localizado com conversas nativas. O modelo pode gerar discussões específicas de mercado que adaptam linguagem, referências culturais e estilos de comunicação, indo além de simples tradução para produzir conteúdo culturalmente relevante que ressoa com audiências locais. As capacidades de voz poliglota — vozes individuais que podem alternar entre idiomas dentro da mesma conversa — habilitam capacidades avançadas de alternância de código que tratam naturalmente sentenças com idiomas misturados. Isto é particularmente valioso para suporte ao cliente multilíngue e colaboração de equipes globais.

    Comentário de produtos e análises

    Plataformas de ecommerce precisam de formas envolventes de ajudar clientes a compreender produtos complexos. Instâncias do Amazon Nova 2 Sonic podem gerar análises de produtos conversacionais, com uma fazendo perguntas comuns de clientes enquanto a outra fornece respostas baseadas em especificações, análises de usuários e documentação técnica. Isto cria conteúdo acessível que ajuda clientes a avaliar produtos através de diálogo natural, com integração com catálogos de produtos garantindo precisão.

    Pensamento de liderança e análise de indústria

    Firmas de serviços profissionais precisam estabelecer liderança de pensamento através de conteúdo regular, mas produção de análise exige investimento significativo de tempo. Instâncias do Amazon Nova 2 Sonic podem engajar-se em discussões de nível especialista sobre tendências de indústria ou análise de mercado, com uma desafiando pressupostos enquanto a outra defende posições com dados. Isto permite que organizações reutilizem pesquisa existente em conteúdo de áudio acessível que alcança executivos ocupados que preferem formatos de áudio.

    Características de desempenho

    • Latência: Streaming com latência reduzida e reprodução de áudio imediata.
    • Duração do podcast: Duração flexível baseada em turnos de conversa (tipicamente 2-5 minutos).
    • Usuários simultâneos: Suporta múltiplas gerações simultâneas de podcast através de AsyncIO.
    • Qualidade de áudio: Síntese de fala de nível profissional com entonação e ritmo naturais.
    • Suporte de idiomas: Inglês, francês, italiano, alemão, espanhol, português e hindi.
    • Janela de contexto: Até 1 milhão de tokens para contexto de conversa estendida.

    Próximos passos

    O Amazon Nova 2 Sonic é um modelo de compreensão e geração de fala de última geração que habilita experiências conversacionais de IA naturais e humanizadas. A arquitetura delineada oferece fundação prática para construir aplicações conversacionais de IA. Seja simplificando suporte ao cliente, criando conteúdo educacional ou gerando materiais de liderança de pensamento, os padrões demonstrados aqui se aplicam através de casos de uso.

    Com suporte expandido de linguagem, capacidades de voz poliglota, integração telefônica aprimorada e interação multi-modal, o Amazon Nova 2 Sonic oferece às organizações ferramentas para construir aplicações orientadas por voz globais em escala.

    Para começar a construir com Amazon Nova Sonic, visite a página de produto do Amazon Nova. Para documentação abrangente, explore o guia do usuário do Amazon Nova 2 Sonic.

    Saiba mais

    Fonte

    Building real-time conversational podcasts with Amazon Nova 2 Sonic (https://aws.amazon.com/blogs/machine-learning/building-real-time-conversational-podcasts-with-amazon-nova-2-sonic/)

  • Conectando servidores MCP ao Amazon Bedrock AgentCore Gateway com fluxo de código de autorização

    Gerenciamento centralizado de acesso a servidores MCP

    À medida que as organizações expandem suas implementações de agentes de IA, o número de servidores MCP (Model Context Protocol) que cada equipe utiliza cresce rapidamente. O Amazon Bedrock AgentCore Gateway oferece uma camada centralizada para gerenciar como os agentes de IA conectam-se a ferramentas e servidores MCP em toda a organização. Essa solução consolida autenticação, observabilidade e imposição de políticas em um único endpoint, eliminando a necessidade de configurar e proteger cada conexão de servidor MCP individualmente.

    Em vez de configurar cada servidor MCP separadamente por IDE (ambiente de desenvolvimento), os times passam a apontar para uma única URL do Gateway, proporcionando acesso consistente ao conjunto completo de ferramentas MCP disponíveis. Esse padrão está acelerando conforme as organizações adotam servidores MCP de produção de terceiros, como os fornecidos pela AWS, GitHub, Salesforce e Databricks.

    Desafios na autenticação em escala

    Muitos servidores MCP empresariais exigem autenticação OAuth 2.0 (Protocolo de Autorização 2.0), onde o agente precisa autenticar-se em nome de um usuário antes de invocar ferramentas. Alguns desses servidores são protegidos pelo provedor de identidade principal através de federação, enquanto outros são protegidos por seus próprios servidores de autorização.

    À medida que o número de servidores MCP por organização aumenta, gerenciar conexões, autenticação e roteamento no nível do IDE torna-se insustentável. O AgentCore Gateway centraliza essa complexidade, oferecendo um único plano de controle para acesso MCP enquanto proporciona aos desenvolvedores uma experiência sem atritos.

    Suporte a fluxo de código de autorização

    A AWS agora oferece suporte ao fluxo de código de autorização OAuth 2.0 através do Amazon Bedrock AgentCore Identity. Com isso, seus agentes podem acessar com segurança servidores MCP protegidos sem incorporar credenciais no código da aplicação ou gerenciar manualmente o ciclo de vida dos tokens.

    A plataforma disponibiliza dois métodos para criar e gerenciar acesso a servidores MCP protegidos por OAuth:

    Sincronização implícita durante a criação do alvo MCP

    Neste método, o usuário administrador completa o fluxo de código de autorização durante operações CreateGatewayTarget, UpdateGatewayTarget ou SynchronizeGatewayTargets. Isso permite que o AgentCore Gateway descubra e cache as ferramentas do servidor MCP antecipadamente.

    Fornecimento de esquema antecipado

    Nesta abordagem, os usuários administradores fornecem o esquema das ferramentas diretamente durante operações CreateGatewayTarget ou UpdateGatewayTarget, em vez de o AgentCore Gateway buscá-los dinamicamente do servidor MCP. O gateway analisa o esquema fornecido e faz cache das definições de ferramentas.

    Esta é a abordagem recomendada quando a intervenção humana não é possível durante operações de criação ou atualização. Além disso, oferece controle granular sobre quais ferramentas do servidor MCP serão expostas. É importante notar que, com este método, a operação SynchronizeGatewayTargets não é suportada.

    Você pode alternar um alvo entre os dois métodos simplesmente atualizando a configuração do alvo, proporcionando flexibilidade conforme suas necessidades evoluem.

    Vinculação de sessão por URL

    Um componente crítico de segurança é a vinculação de sessão por URL, que verifica se o usuário que iniciou a solicitação de autorização OAuth é o mesmo que concedeu consentimento. Quando o AgentCore Identity gera uma URL de autorização, também retorna uma session-URI. Após o usuário concluir o consentimento, o navegador redireciona para uma URL de callback com a session-URI.

    A aplicação é então responsável por chamar a API CompleteResourceTokenAuth, apresentando tanto a identidade do usuário quanto a session-URI. O AgentCore Identity valida que o usuário que iniciou o fluxo é o mesmo que o completou antes de trocar o código de autorização por um token de acesso. Isso ajuda a evitar cenários onde um usuário compartilha acidentalmente a URL de autorização e outra pessoa completa o consentimento, concedendo tokens de acesso para a parte errada.

    Para segurança adicional, a URL de autorização e a session URI são válidas apenas por 10 minutos, limitando ainda mais a janela para uso indevido.

    Conceitos principais

    Usuário do AgentCore Gateway: O usuário final que consome as ferramentas no Amazon Bedrock AgentCore Gateway com clientes MCP. Esses usuários não gerenciam o próprio AgentCore Gateway — simplesmente usam a URL única do gateway para acessar as ferramentas disponíveis para eles.

    Usuário administrador: O usuário que gerencia e mantém o Amazon Bedrock AgentCore Gateway. É responsável por conectar servidores MCP, ferramentas ou APIs ao gateway, permitindo que usuários do gateway as consumam.

    Servidor MCP: Neste contexto, assume-se que o servidor MCP é protegido por um fluxo de código de autorização OAuth 2.0, que requer interação do usuário para completar a autenticação. Isso é diferente de métodos de autenticação máquina-para-máquina, como Client Credentials ou Token Exchange, que não requerem intervenção do usuário.

    Implementação prática com GitHub

    Para demonstrar a integração, a AWS fornece exemplos de código mostrando como conectar um servidor GitHub MCP ao Amazon Bedrock AgentCore Gateway. O processo envolve ambos os métodos — sincronização implícita durante a criação do alvo e fornecimento de esquema antecipado.

    Configuração inicial com GitHub

    Antes de começar, é necessário configurar uma aplicação OAuth no GitHub. Acesse https://github.com/settings/apps para criar uma nova aplicação GitHub, fornecendo detalhes como nome da aplicação, URL da homepage e URL de callback de autorização.

    Nas configurações avançadas, recomenda-se desativar a expiração automática de tokens, desativar a autorização de usuário durante a instalação e desativar o Device Flow, seguindo as melhores práticas de segurança da sua organização.

    Preparação do ambiente

    Você precisará de permissões IAM (Gestão de Identidade e Acesso) apropriadas para executar o código. O repositório contém exemplos práticos — comece clonando o repositório GitHub e abrindo o arquivo github-mcp-server.ipynb.

    Configuração do provedor de credenciais

    Configure o provedor de credenciais do Agentcore Identity no console do Amazon Bedrock AgentCore. Crie um cliente OAuth, fornecendo um nome e selecionando o provedor GitHub pré-incluído. Insira o ID do cliente e o segredo da aplicação GitHub.

    Copie a URL de callback do cliente OAuth do AgentCore Identity e retorne à aplicação OAuth do GitHub que criou para atualizar a URL de callback de autorização com o valor gerado.

    Fluxo de sincronização implícita

    No método de sincronização implícita, o usuário administrador completa o fluxo de autorização durante a criação do alvo. Certifique-se de que a função de execução do AgentCore Gateway possui permissões para GetWorkloadAccessTokenForUserId e CompleteResourceTokenAuth.

    O processo segue esta sequência: o administrador chama CreateGatewayTarget, fornecendo o endpoint do servidor MCP, o provedor de credenciais do AgentCore Identity e a URL de retorno. O AgentCore Gateway solicita um token de acesso de workload ao provedor de credenciais, passando a identidade do gateway e um ID de usuário. Com esse token, o gateway solicita um token de acesso OAuth 2.0, que retorna uma URL de autorização e uma session-URI.

    Neste ponto, o alvo entra em status “Requer autorização”. O administrador abre a URL de autorização em seu navegador, faz login e concede as permissões solicitadas. Após o consentimento, o servidor OAuth 2.0 envia um código de autorização ao callback registrado do provedor de credenciais.

    O provedor redireciona o navegador do administrador para a URL de retorno, com a session-URI. A aplicação então chama CompleteResourceTokenAuth, apresentando o ID do usuário e a session-URI. O provedor de credenciais valida que o mesmo usuário que iniciou o fluxo completou o consentimento, prevenindo roubo de token.

    Após validação bem-sucedida, o provedor troca o código de autorização pelo token de acesso OAuth 2.0. Esse token é usado para listar as ferramentas no alvo do servidor MCP; as definições de ferramentas retornadas são armazenadas em cache no AgentCore Gateway.

    Método de esquema antecipado

    Esta é a abordagem recomendada quando a intervenção humana não é possível durante operações de criação ou atualização. Durante a seleção de criação de alvo, você seleciona a opção de usar uma lista de ferramentas pré-definidas e fornece as definições de ferramentas do GitHub.

    O alvo entra imediatamente em status “Pronto”, com status de autorização “Nenhuma autorização necessária”. Isso oferece flexibilidade total sobre quais ferramentas expor e elimina a necessidade de interação do administrador durante a configuração.

    Experiência do usuário do gateway

    Após a criação bem-sucedida do alvo, seja através de sincronização implícita ou esquema antecipado, os usuários do AgentCore Gateway podem descobrir e invocar ferramentas usando o protocolo MCP.

    Quando um usuário do gateway envia uma solicitação de lista de ferramentas com seu token de autorização de entrada, o AgentCore Gateway retorna as definições de ferramentas em cache imediatamente, sem necessidade de nova autenticação no servidor MCP.

    Quando o usuário envia uma solicitação para invocar uma ferramenta, o AgentCore Gateway desencadeia o fluxo de autorização OAuth para aquele alvo específico de servidor MCP. O gateway solicita um token de acesso de workload, e então usa esse token para solicitar um token de acesso OAuth 2.0 ao provedor de credenciais.

    Se nenhum token válido existir ainda para este usuário, o provedor retorna uma URL de autorização e uma session-URI. O gateway passa esses valores para o usuário, que abre a URL em seu navegador, faz login e concede permissões. Após consentimento, o servidor OAuth 2.0 envia um código de autorização ao callback do provedor de credenciais.

    O provedor redireciona o navegador do usuário para a URL de retorno com a session-URI. A aplicação do usuário chama CompleteResourceTokenAuth com o JWT do usuário e a session-URI. O provedor valida que o mesmo usuário completou o consentimento, então troca o código de autorização por um token de acesso OAuth 2.0.

    Este token é armazenado em cache no Token Vault sob a identidade do workload e a identidade do usuário. Na próxima invocação de ferramenta, o AgentCore Gateway recupera o token em cache e o usa para chamar o servidor MCP, proporcionando uma experiência fluida após a autenticação inicial.

    Explorando exemplos e casos de uso

    Embora este exemplo concentre-se no servidor GitHub MCP, o repositório de código inclui exemplos de integração para outros servidores MCP populares de terceiros e um guia para hospedar seu próprio servidor MCP com suporte a fluxo de código de autorização no AgentCore Runtime.

    A AWS incentiva explorar esses exemplos e adaptá-los à paisagem de servidor MCP de sua organização, facilitando a adoção de múltiplas ferramentas MCP de forma segura e centralizada.

    Recursos adicionais

    Para aprofundar seu conhecimento, consulte a documentação oficial: Apresentando o Amazon Bedrock AgentCore Gateway: transformando o desenvolvimento de ferramentas para agentes de IA empresariais, Apresentando o Amazon Bedrock AgentCore Identity: protegendo IA agentic em escala e Exemplos do Amazon Bedrock AgentCore.

    Fonte

    Connecting MCP servers to Amazon Bedrock AgentCore Gateway using Authorization Code flow (https://aws.amazon.com/blogs/machine-learning/connecting-mcp-servers-to-amazon-bedrock-agentcore-gateway-using-authorization-code-flow/)

  • AWS Cost Explorer ganha capacidades de consulta em linguagem natural com Amazon Q

    Inteligência artificial generativa para análise de custos

    A AWS anunciou a integração das capacidades de inteligência artificial generativa do Amazon Q directamente aos fluxos de trabalho de análise de custos do Cost Explorer. Esse recurso transforma a forma como os usuários investigam e entendem seus gastos na nuvem, eliminando a necessidade de navegar complexas interfaces de relatórios ou dominar linguagens técnicas de consulta.

    Como funciona a consulta em linguagem natural

    O novo recurso permite fazer perguntas sobre dados de custos e uso da AWS utilizando linguagem natural, como se estivesse conversando. Ao submeter uma consulta, o Amazon Q fornece respostas detalhadas enquanto o Cost Explorer atualiza automaticamente as visualizações, filtros e agrupamentos correspondentes. Esse processo elimina as etapas intermediárias de configuração manual de gráficos e tabelas.

    Prompts sugeridos para análise rápida

    Para acelerar a análise inicial, o Cost Explorer apresenta prompts pré-configurados com perguntas comuns sobre custos. Esses sugestões incluem questões como “Quais foram meus principais serviços em gastos este mês?”. Com um simples clique, o usuário recebe insights detalhados do Amazon Q enquanto o visualizador se atualiza simultaneamente.

    Perguntas personalizadas sem limites

    Além dos prompts sugeridos, existe um novo botão “Fazer Pergunta” que permite formular questões personalizadas sobre padrões de gastos. O usuário pode explorar seus dados de forma conversacional, passando de uma verificação rápida de custos para investigações profundas sem trocar de ferramenta ou interromper o fluxo de trabalho.

    Contexto contínuo em conversas

    O Cost Explorer atualiza automaticamente gráficos e tabelas quando a análise se baseia nos dados de custos e uso. Quando o Amazon Q integra informações de fontes adicionais — como tabelas de preços ou detecção de anomalias — essas visualizações aparecem em um novo painel de artifacts do Amazon Q. A capacidade de fazer perguntas sequenciais mantendo contexto completo permite investigações detalhadas sem perder o histórico da conversa.

    Disponibilidade e acessibilidade

    A análise de custos em linguagem natural para o AWS Cost Explorer está disponível a partir de agora em todas as regiões comerciais da AWS sem custo adicional. Isso democratiza o acesso à análise de custos para todos os membros da equipe, independentemente de terem experiência técnica anterior com ferramentas de relatório.

    Para começar a usar este recurso, consulte a documentação de usuário do Cost Explorer e acesse o AWS Cost Explorer em seu console.

    Fonte

    AWS Cost Explorer launches Natural Language Query capabilities powered by Amazon Q (https://aws.amazon.com/about-aws/whats-new/2026/04/AWS-Cost-Explorer-Natural-Language-Query/)

  • Amazon Verified Permissions: Aliases para Policy Stores, Políticas e Templates Nomeados

    O que mudou no Amazon Verified Permissions

    A AWS anunciou, em abril de 2026, novas funcionalidades para o Amazon Verified Permissions, seu serviço de autorização de granularidade fina. As novidades incluem suporte para aliases de policy stores, políticas nomeadas e templates de políticas nomeados. Essas melhorias foram projetadas para simplificar significativamente as implementações multi-tenant e a gestão diária de políticas.

    O Amazon Verified Permissions é um serviço que ajuda você a gerenciar e fazer cumprir permissões em suas aplicações usando políticas Cedar. Com as novas capacidades, a plataforma reduz a complexidade operacional, eliminando necessidades que costumavam ser contornadas manualmente.

    Entendendo os Aliases de Policy Stores

    Uma das maiores dores de cabeça em ambientes multi-tenant é manter tabelas de mapeamento separadas. Essas tabelas associam identificadores de inquilino (tenant IDs) com IDs de policy stores — um trabalho tedioso e propenso a erros.

    Com os aliases de policy stores, desenvolvedores podem agora atribuir um alias legível associado ao identificador do tenant e utilizá-lo em qualquer chamada de API. Isso elimina completamente a necessidade de tabelas de consulta (lookup tables). Em vez de trabalhar com IDs gerados pelo sistema, você trabalha com nomes significativos e contextualizados.

    Políticas e Templates Nomeados

    Da mesma forma, as políticas nomeadas e os templates de políticas nomeados permitem que você faça referência a políticas por nomes significativos, em vez de depender de IDs gerados automaticamente pelo sistema.

    Essa mudança traz benefícios práticos importantes: conforme sua aplicação cresce e a lógica de autorização se torna mais complexa, trabalhar com nomes descritivos torna a gestão muito mais intuitiva e menos suscetível a erros de configuração. Você consegue identificar rapidamente qual política faz o quê, sem precisar consultar documentações ou mapeamentos internos.

    Disponibilidade e Próximos Passos

    As novas funcionalidades de aliases de policy stores, políticas nomeadas e templates de políticas nomeadas estão disponíveis em todas as regiões AWS onde o Amazon Verified Permissions já é oferecido.

    Para explorar essas novidades, você pode consultar:

    O que isso significa para arquitetos e desenvolvedores

    Essas mudanças refletem a evolução contínua da AWS em torno de segurança e autorização. Para times que trabalham com aplicações multi-tenant complexas, as novas funcionalidades representam uma redução real de fricção operacional e uma camada adicional de clareza no código de autorização. Menos mapeamentos manuais significam menos bugs, menos confusão e deployments mais confiáveis.

    Fonte

    Amazon Verified Permissions now supports policy store aliases and named policies and policy templates (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-verified-permissions-policy-store/)

  • Amazon WorkSpaces Personal agora suporta nomes DNS únicos para PrivateLink

    Nomes DNS únicos para ambientes multi-conta

    A AWS anunciou uma evolução importante no Amazon WorkSpaces Personal: agora é possível utilizar nomes de Domínio (DNS — Sistema de Nomes de Domínio) únicos e publicamente resolvíveis para cada ponto de extremidade de PrivateLink (Conexão Privada) dentro de uma Nuvem Privada Virtual (VPC — Rede Privada Virtual).

    Essa funcionalidade resolve um desafio recorrente em ambientes empresariais complexos: permite que organizações implementem WorkSpaces Personal em múltiplas VPCs e contas da AWS sem enfrentar conflitos de resolução de nomes. Anteriormente, todos os pontos de extremidade compartilhavam um nome DNS genérico, o que criava colisões quando tentava-se usar múltiplos endpoints separados em diferentes contas.

    Como funciona a solução

    Cada ponto de extremidade de interface VPC recebe agora um nome DNS exclusivo gerenciado globalmente pela AWS, além do nome DNS genérico anterior. Essa abordagem mantém a compatibilidade com configurações existentes enquanto oferece maior flexibilidade para arquiteturas de múltiplas contas.

    Os nomes DNS publicamente resolvíveis simplificam a configuração sem sacrificar a segurança — eles resolvem apenas para endereços IP privados, acessíveis somente dentro de suas respectivas VPCs. A solução elimina a necessidade de gerenciamento manual de DNS customizado ou configurações adicionais no Route 53 (serviço de DNS da AWS), já que o sistema mantém automaticamente esses nomes durante todo o seu ciclo de vida.

    Benefícios para ambientes empresariais

    Com essa melhoria, clientes empresariais podem agora:

    • Implementar diretórios de WorkSpaces Personal em diferentes VPCs e contas da AWS mantendo isolamento de segurança adequado
    • Rotear tráfego de forma apropriada em ambientes multi-conta com infraestrutura DNS centralizada
    • Eliminar conflitos de colisão de nomes que previamente impediam o uso de múltiplos endpoints em diferentes contas

    Disponibilidade e compatibilidade

    O recurso está disponível em todas as regiões AWS (áreas geográficas onde a AWS opera) onde o PrivateLink está disponível no Amazon WorkSpaces Personal. Clientes existentes recebem automaticamente essa melhoria, pois o sistema mantém compatibilidade retroativa com configurações DNS anteriores — nenhuma ação manual é necessária.

    Para aprofundar-se na implementação, consulte a documentação de PrivateLink do Amazon WorkSpaces e o Guia de Administração do WorkSpaces para detalhes técnicos de configuração.

    Fonte

    Amazon WorkSpaces Personal now supports unique DNS names for PrivateLink (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-workspaces-personal-privatelink/)

  • Amazon SageMaker Unified Studio ganha recursos de importação/exportação de notebooks e aceleração para desenvolvedores

    Notebooks com suporte a importação e exportação

    O Amazon SageMaker Unified Studio da AWS anunciou uma atualização significativa para seus notebooks, introduzindo capacidades robustas de importação e exportação. Essa funcionalidade possibilita que profissionais migrem facilmente de plataformas como JupyterLab e outras soluções de notebooks, eliminando barreiras técnicas e operacionais para quem deseja adotar o ambiente unificado da AWS.

    A implementação preserva completamente os tipos de células e metadados durante a transferência, garantindo que toda a estrutura e configuração dos notebooks sejam mantidas intactas. Essa abordagem simplifica significativamente o processo de migração, reduzindo trabalho manual e a possibilidade de perda de dados.

    Formatos suportados e flexibilidade de exportação

    A solução oferece suporte a múltiplos formatos que cobrem diferentes cenários de uso. Na importação, o sistema aceita arquivos no formato .ipynb, .json e .py. Para exportação, há quatro opções disponíveis:

    • Jupyter notebook com requirements (formato .zip)
    • Notebook padrão no formato .ipynb
    • Scripts Python (formato .py)
    • Formato nativo do SageMaker Unified Studio (formato .json)

    Essa variedade de formatos permite que cientistas de dados e engenheiros de dados escolham a opção mais adequada para seus fluxos de trabalho, seja para compartilhamento, versionamento ou integração com outras ferramentas.

    Recursos de aceleração para desenvolvedores

    Além das capacidades de importação e exportação, a AWS introduziu um conjunto de recursos projetados especificamente para melhorar a produtividade no desenvolvimento com notebooks:

    • Reordenação de células: permite reorganizar células sem necessidade de copiar e colar, eliminando duplicações e simplificando o gerenciamento do fluxo lógico
    • Nomenclatura customizada de células: atribui nomes personalizados às células, facilitando navegação em notebooks grandes e complexos
    • Atalhos de teclado familiares: implementa atalhos de teclado reconhecíveis, acelerando o desenvolvimento para profissionais com experiência em outras plataformas
    • Suporte a SQL multi-linha: permite executar múltiplos comandos SQL em uma única célula, com resultados exibidos em abas separadas para comparação e análise simplificadas

    Disponibilidade e documentação

    Esse conjunto de recursos está disponível em todas as regiões AWS onde o Amazon SageMaker Unified Studio opera. Para profissionais interessados em explorar essas funcionalidades em profundidade, a AWS disponibiliza recursos adicionais através da página de marketing do Amazon SageMaker Unified Studio e do guia do usuário. Além disso, é possível consultar a documentação sobre as regiões AWS onde o SageMaker Unified Studio está disponível.

    Fonte

    Amazon SageMaker Unified Studio adds notebook import/export and developer acceleration features (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-unified-studio/)

  • Agentes de Onboarding Alimentados por IA com Amazon Quick

    O desafio do onboarding em escala

    Integrar novos colaboradores em grandes organizações é uma tarefa desafiadora. Equipes de Recursos Humanos enfrentam trabalhos manuais repetitivos que atrasam a produtividade: processar documentos, responder perguntas sobre benefícios e políticas, e garantir que todos sigam os mesmos procedimentos. Durante os primeiros meses, novos funcionários alcançam apenas uma fração do seu potencial produtivo, enquanto o departamento de RH perde horas diárias por contratação em atividades rotineiras.

    Manter a consistência e a conformidade nesse contexto é complexo. As informações ficam espalhadas entre wikis, SharePoint, sistemas de tickets, chat e e-mail. Sem uma solução integrada, o onboarding se torna um labirinto de processos desconexos.

    Amazon Quick: automatização inteligente para RH

    O Amazon Quick é um serviço gerenciado que oferece capacidades de agentes de IA. Por meio dele, departamentos de RH podem criar agentes de conversação sem código que respondem perguntas de novos contratados, rastreiam conformidade em ferramentas existentes e eliminam tickets automaticamente. Isso permite que novos colaboradores se integrem mais rapidamente com menos intervenção manual.

    Componentes principais do Amazon Quick

    Bases de Conhecimento

    O Amazon Quick indexa conteúdo de fontes externas como SharePoint, OneDrive e Confluence, além de conteúdo interno incluindo sites internos, uploads de arquivos e buckets do Amazon Simple Storage Service (Amazon S3). Uma base de conhecimento funciona como um repositório único e pesquisável, permitindo que novos colaboradores obtenham respostas abrangentes de múltiplas fontes, sem precisar procurar em arquivos desconexos.

    Conectores de Ações

    Os conectores de ações são integrações seguras e cientes de permissões que habilitam agentes de IA a executar trabalho real em cenários de onboarding de RH. Um agente pode criar solicitações de equipamento de TI no ServiceNow, enviar mensagens de boas-vindas no Slack para canais da equipe, ou atualizar fluxos de trabalho de onboarding em ferramentas de gerenciamento de projetos. Isso vai além de apenas fornecer links para formulários.

    Espaços

    Espaços são ambientes focados que organizam ativos centrados na equipe, incluindo arquivos, artefatos de inteligência de negócios como dashboards e tópicos, bases de conhecimento e ações com controles de compartilhamento para colaboração. Dessa forma, o RH pode manter seus recursos de onboarding bem organizados e acessíveis apenas para quem precisa.

    Estrutura da solução

    Sem um agente inteligente, o RH alternava entre múltiplos sistemas para coordenar cada etapa do onboarding. Com o Quick, um agente customizado apresenta a lista de verificação mais atualizada, responde com linguagem aprovada pela organização, abre solicitações através de ações, notifica as partes interessadas e aponta o próximo passo. Confirmações e status permanecem nos sistemas de RH, e o agente os lê ou os atualiza por meio de conectores de ações ou fluxos de trabalho.

    A implementação segue passos diretos: criar o agente de conversação no Quick, anexar o espaço de RH e vinculá-lo a fontes de conhecimento, adicionar conectores de ações, testar com cenários reais e compartilhar com os funcionários.

    Tipos de agentes disponíveis

    Agente de sistema (“Meu assistente”)

    O agente de sistema do Quick aparece por padrão no console e ajuda usuários a fazer perguntas e completar tarefas usando recursos que têm permissão de acessar. Usuários podem interagir de várias formas: fazer perguntas gerais usando o conhecimento integrado do agente, fazer upload de seus próprios arquivos diretamente no chat (até 20 arquivos por conversa) para análise, e controlar o escopo da conversação escolhendo entre três modos: Todos os dados e aplicativos (busca em todos os recursos acessíveis), Conhecimento geral (apenas conhecimento integrado) ou Dados e aplicativos específicos (foca em espaços, dashboards, tópicos, bases de conhecimento ou ações particulares).

    O agente de sistema está disponível imediatamente sem nenhuma configuração necessária e adapta suas respostas baseado no escopo selecionado e nos recursos disponíveis.

    Agentes customizados

    Para necessidades mais específicas, é possível criar agentes customizados. Você configura o comportamento do agente (propósito, tom, formato de resposta), anexa espaços com dashboards, tópicos e bases de conhecimento para respostas fundamentadas em dados, e vincula conectores de ações para que o agente possa executar tarefas em ferramentas como Jira, Slack, ServiceNow, Salesforce, Outlook ou Teams. Agentes customizados podem ser compartilhados com usuários específicos ou grupos.

    Essas capacidades incluem: respostas específicas para casos de uso (defina a persona e estilo de resposta do agente), orientação através de documentos de referência (faça upload de documentos específicos que servem como templates de resposta para mensagens consistentes e guias de processo), integração abrangente de dados (vincule espaços para dar acesso ao agente a diferentes tipos de conteúdo pesquisável, respeitando a estrutura de permissões da organização), ações automatizadas (adicione conectores de ações para que usuários criem tickets Jira, enviem mensagens Slack, atualizem Salesforce ou abram solicitações ServiceNow diretamente do chat), e colaboração (teste, refine e compartilhe agentes com colegas, com administradores controlando quem pode criar e customizar agentes através de permissões).

    Fluxo de implementação: perspectiva do administrador de RH

    Criação do agente de conversação

    O primeiro passo é criar o agente em si, que se torna o local único onde novos contratados fazem perguntas e recebem orientação através do onboarding. No console do Quick, você escolhe “Agentes de conversação” e seleciona “Criar”. Insere um prompt em linguagem natural descrevendo o que deseja que o agente faça, por exemplo: “Ajude novos funcionários com perguntas sobre onboarding de RH e solicitações de equipamento.” O Quick expande automaticamente esse prompt em uma persona detalhada, instruções de resposta e realiza uma varredura de recursos disponíveis para vincular espaços e conectores de ações relevantes. Você revisa a configuração gerada, refina conforme necessário e escolhe “Lançar agente de conversação” quando estiver satisfeito.

    Configuração de comportamento

    O próximo passo é moldar como o agente deve responder para que seu tom, escopo e diretrizes correspondam às políticas de RH e à marca da organização. Atualize os metadados do agente (nome, descrição, mensagem de boas-vindas e prompts iniciais) para ajudar usuários a descobrir e usar o assistente corretamente. Revise e refine as instruções de persona geradas automaticamente, incluindo formato de resposta, tom e configurações de comprimento. Por fim, faça upload de documentos de referência específicos que fornecem instruções de prioridade máxima para o comportamento do agente.

    Conexão de conhecimento de RH

    Conecte suas fontes de conhecimento de RH para que o agente responda com base em manuais e políticas aprovados, não em respostas inventadas. Crie ou escolha um espaço de RH existente que contenha manuais, políticas e listas de verificação. Configure o escopo de conhecimento do agente para focar especificamente em conteúdo relacionado a RH, garantindo que respostas permaneçam dentro de limites apropriados. Faça upload de arquivos ao espaço, incluindo manuais de funcionários, documentos de políticas, informações sobre benefícios, materiais de treinamento e guias. Vincule o espaço configurado ao agente para que ele possa acessar esse conteúdo pesquisável e fundamentado para respostas aprovadas.

    Adição de ações

    Após o agente estar habilitado a responder perguntas, adicione ações para que também possa desencadear trabalho em suas ferramentas de RH, como tickets, solicitações e notificações. Abra o cartão de Ações e escolha “Vincular ações”, selecionando conectores de ações disponíveis que você já configurou. Para o caso de uso de onboarding de RH, isso pode incluir ferramentas como Jira (para criar e atualizar tickets) ou ServiceNow (para gerenciar incidentes). Atualize seus documentos de referência e instruções de persona para especificar quando invocar conectores de ações específicos, por exemplo: “Quando um funcionário solicita equipamento, use o conector ServiceNow para criar um ticket de solicitação de hardware” ou “Para solicitações de acesso, crie um ticket Jira no projeto TI-Acesso com prioridade definida como ‘Normal.’”

    Customização, teste e compartilhamento

    Finalize o agente com uma mensagem de boas-vindas e prompts sugeridos. Teste o agente com cenários realistas, ajuste a experiência conforme necessário e compartilhe com um grupo piloto para que o RH valide o fluxo de trabalho antes de um lançamento mais amplo. Quando estiver pronto, lance o agente e estará disponível em sua biblioteca pessoal para uso privado. Para compartilhar com outros, escolha “Compartilhar” e adicione usuários e grupos como visualizadores para usar o agente ou como proprietários para editá-lo e testá-lo.

    Fluxo de implementação: perspectiva do novo colaborador

    Após o agente ser publicado e compartilhado com colaboradores como visualizadores, eles podem abri-lo a partir do link fornecido pelo RH (por exemplo, em seu e-mail do Dia 1 ou portal de RH) ou a partir da lista de agentes de conversação no Quick, e então usá-lo da seguinte forma:

    O colaborador abre o agente de onboarding de RH compartilhado e inicia uma conversa do Dia 1. O agente apresenta a lista de verificação de onboarding mais atualizada do espaço de RH e fornece links para formulários obrigatórios, treinamentos e páginas internas para que o colaborador possa avançar pelos passos em ordem. Quando o colaborador faz perguntas sobre políticas ou benefícios em linguagem natural, o agente responde usando conteúdo do espaço de RH e fontes de conhecimento de RH conectadas, garantindo que as respostas correspondam à linguagem aprovada pelo RH.

    Quando o colaborador solicita equipamento ou acesso a aplicativos, o agente usa um conector de ações Jira para criar uma issue no projeto de onboarding de RH e retorna a chave da issue e o link para que você veja a solicitação completa sem tocar em sistemas de RH em produção. Para etapas sensíveis como verificação de I-9, formulários fiscais ou depósito direto, o agente direciona o colaborador para o sistema de RH apropriado ou portal seguro, em vez de coletar documentos no chat, garantindo que dados sensíveis permaneçam no lugar correto.

    A experiência final é simples: o colaborador abre um único chat, vê sua lista de verificação do Dia 1, faz perguntas em linguagem natural e permite que o agente abra solicitações e aponte para os sistemas corretos. Em vez de ficar malabarista com e-mails, portais e tickets, o onboarding se sente como uma conversa guiada onde o próximo passo é sempre claro.

    Pré-requisitos para implementação

    Antes de começar, certifique-se de que completou os seguintes passos: crie uma conta AWS. Confirme que você tem acesso ao Quick. Você precisará de pelo menos uma assinatura do Amazon Quick Enterprise para configurar ações e criar bases de conhecimento. Usuários que apenas usam o agente compartilhado podem estar na assinatura do Amazon Quick Professional. Acesse a área de introdução ao Atlassian Cloud e crie um site gratuito, selecionando tanto Confluence quanto Jira no plano gratuito (até 10 usuários).

    No Confluence, crie um espaço “HR Onboarding” para armazenar seu conteúdo de RH. No Jira, crie um projeto simples de onboarding de RH que o agente possa usar para solicitações de acesso ou equipamento. Baixe o arquivo ZIP da página de materiais do workshop de onboarding de RH. A partir da pasta de documentos de RH no arquivo ZIP, faça upload dos seguintes arquivos para seu espaço Confluence “HR Onboarding”: employee_handbook.pdf, leave_policy.pdf, onboarding_checklist.pdf, performance_review_guidelines.pdf e public_holidays.csv (opcional, usado depois para relatórios ou análise).

    Segurança e controles integrados

    O Amazon Quick inclui controles de segurança e conteúdo integrados para agentes de conversação. Você pode usar as configurações padrão em sua conta ou experimentar controles de política adicionando uma pequena lista de palavras ou frases bloqueadas para que o agente evite termos específicos em respostas de RH, por exemplo gíria informal ou linguagem desencorajada. Termos bloqueados são configurados no console do Quick e aplicados em todos os agentes em sua conta. Para instruções passo a passo e opções de segurança adicionais como controle de acesso e criptografia, consulte o guia de usuários do Amazon Quick.

    Opções de assinatura

    O Amazon Quick oferece duas assinaturas de usuário: Professional e Enterprise. O plano Professional suporta uso cotidiano de agentes de conversação e espaços, execução de Amazon Quick Flows e Amazon Quick Research, visualização de dashboards do Amazon Quick Sight, com a capacidade de criar e compartilhar agentes e espaços customizados. O plano Enterprise inclui tudo do Professional mais recursos de autoria avançada como configuração de ações, criação de bases de conhecimento, construção de automações em Amazon Quick Automate, edição de dashboards no Quick Sight e limites de uso mensal maiores. Uma avaliação gratuita de 30 dias está disponível para até 25 usuários por conta. Para detalhes, consulte a precificação do Amazon Quick.

    Próximos passos

    Esta abordagem demonstra como criar um agente de conversação de onboarding de RH no Quick, anexar conteúdo de RH, adicionar ações e fluxos de trabalho opcionais, e compartilhar com colaboradores. Comece com um piloto que cubra suas perguntas mais frequentes e duas ou três solicitações, revise o uso e refine as instruções e conteúdo do agente. Para próximas etapas, expanda o espaço de RH, adicione ações adicionais conforme necessário e revise a documentação do Quick para configuração avançada.

    Além do onboarding, equipes de RH podem explorar a construção de agentes para autoatendimento de funcionários, gerenciamento de desempenho, aquisição de talentos, desenvolvimento e aprendizagem, análise e processos de desligamento para transformar suas operações de RH como um todo.

    Pronto para transformar a produtividade do seu ambiente de trabalho? Comece com o Quick, explore opções de precificação que se ajustem às suas necessidades ou contate sua equipe de conta AWS para discutir como o Quick pode transformar a abordagem da sua organização para tomada de decisão orientada por dados.

    Fonte

    Build AI-powered employee onboarding agents with Amazon Quick (https://aws.amazon.com/blogs/machine-learning/build-ai-powered-employee-onboarding-agents-with-amazon-quick/)

  • Buscas Inteligentes com Amazon Bedrock e Amazon OpenSearch: Soluções Híbridas de RAG

    Assistentes de IA Agentica e Recuperação Aumentada por Geração

    Assistentes de inteligência artificial agentica representam um avanço significativo no campo da IA. Diferentemente de chatbots convencionais, esses sistemas dinâmicos funcionam a partir de modelos de linguagem amplos (LLMs – Large Language Models) que mantêm conversas abertas e lidam com tarefas complexas, adaptando-se às necessidades do usuário e executando ações em sistemas de backend quando necessário.

    A capacidade distintiva desses assistentes reside na recuperação de dados específicos de negócio em tempo real, por meio de chamadas de API e consultas a bancos de dados. Essas informações são incorporadas nas respostas geradas pelo LLM ou apresentadas paralelamente a elas. Esta combinação de capacidades de LLM com recuperação dinâmica de dados é conhecida como Recuperação Aumentada por Geração (RAG – Retrieval-Augmented Generation).

    Consideremos um assistente agentico para reservas de hotéis: ao receber uma consulta, o sistema primeiro interroga o banco de dados para localizar propriedades que correspondem aos critérios específicos do hóspede. Em seguida, executa chamadas de API para obter informações em tempo real sobre disponibilidade de quartos e tarifas vigentes. Essas informações recuperadas podem seguir dois caminhos: o LLM as processa para gerar uma resposta abrangente, ou são exibidas ao lado de um resumo gerado pelo LLM. Ambas as abordagens garantem que os hóspedes recebam informações precisas e atualizadas integradas à sua conversa contínua com o assistente.

    Estratégias de Recuperação de Informações em Sistemas RAG

    As estratégias de recuperação de informações que sustentam a capacidade RAG em implementações de IA agentica giram fundamentalmente em torno de consultas em tempo real a fontes de dados de backend ou comunicação com APIs. As respostas são então fatoradas nas etapas subsequentes da implementação.

    Do ponto de vista de design e implementação de sistemas, bancos de dados e APIs não representam uma novidade em si. Contudo, surgiram abordagens de recuperação de informações específicas para implementações com IA agentica, notadamente a busca semântica baseada em significado.

    Busca por Similaridade Vetorial

    Na busca semântica, os dados são recuperados com base no significado da frase de busca, não apenas em correspondências léxicas de palavras-chave ou padrões. Incorporações vetoriais (embeddings de vetor) são pré-computadas e armazenadas em bancos de dados vetoriais, permitindo cálculos eficientes de similaridade no momento da consulta.

    O princípio central da Busca por Similaridade Vetorial (VSS – Vector Similarity Search) envolve encontrar as correspondências mais próximas entre essas representações numéricas usando métricas de distância matemática como similaridade cosseno ou distância euclidiana. Essas funções matemáticas são particularmente eficientes ao buscar em grandes volumes de dados, porque as representações vetoriais são pré-computadas.

    Modelos de bi-codificador (bi-encoder models) são comumente utilizados nesse processo. Eles codificam separadamente a consulta e os documentos em vetores, possibilitando comparações eficientes de similaridade em escala sem exigir que o modelo processe pares de consulta-documento em conjunto. Quando um usuário submete uma consulta, o sistema a converte em um vetor e busca vetores de conteúdo posicionados mais próximos no espaço multidimensional. Isso significa que, mesmo quando palavras-chave exatas não coincidem, a busca pode localizar resultados relevantes com base em similaridade semântica conceitual.

    Por exemplo, em um conjunto de dados vetorizado contendo [“materiais de construção”, “suprimentos de encanamento”, “resultado da multiplicação 2×2”], a busca por “tábua de madeira 2×4” provavelmente produzirá “materiais de construção” como melhor resultado. A combinação de busca semântica com agentes orientados por LLM suporta alinhamento em linguagem natural em toda a solução, desde componentes voltados ao usuário até recuperação de dados de backend.

    O Desafio: Quando Busca Semântica Não É Suficiente

    Consideremos um cenário real: um cliente busca por uma propriedade hoteleira e deseja encontrar “um hotel de luxo com vista para o oceano em Miami, Flórida”. Embora a busca semântica se destaque na compreensão de conceitos como “luxo” e “vista para o oceano”, ela pode lutar com a correspondência precisa de localização. A busca pode retornar propriedades oceanfront de luxo altamente relevantes com base em similaridade semântica, mas estas poderiam estar na Califórnia, no Caribe ou em qualquer outro lugar com acesso ao oceano, não especificamente em Miami conforme solicitado.

    Essa limitação surge porque a busca semântica prioriza similaridade conceitual sobre correspondência exata de atributos. Em casos onde usuários necessitam tanto de compreensão semântica (luxo, vista para o oceano) quanto de filtragem precisa (Miami, Flórida), depender unicamente de busca semântica produz resultados subótimos. É aqui que a busca híbrida torna-se essencial.

    Abordagem de Busca Híbrida

    A busca híbrida combina a compreensão semântica de descrições em linguagem natural com a precisão de filtragem baseada em texto em atributos estruturados como localização, datas ou metadados específicos. Quando um usuário fornece uma frase de busca, um LLM primeiro analisa a consulta para identificar atributos específicos (como localização) e mapeá-los para valores pesquisáveis. Esses atributos extraídos são então utilizados como filtros em conjunto com pontuação de similaridade semântica, garantindo que os resultados sejam tanto conceitualmente relevantes quanto precisamente correspondentes aos requisitos do usuário.

    Consideremos dois exemplos práticos de busca: no primeiro, a frase “procurando um hotel à beira-mar” seria atendida por busca semântica pura, retornando a propriedade mais semanticamente similar. No segundo exemplo, “um hotel de luxo com bom restaurante no centro da cidade” beneficia-se da busca híbrida, combinando relevância semântica com filtragem de localização precisa para identificar a melhor correspondência considerando ambas as dimensões.

    Uma Solução Baseada em Agentes

    Consideremos um cenário de busca hoteleira onde usuários têm necessidades diversas. Um usuário pode solicitar “encontre-me um hotel aconchegante”, exigindo compreensão semântica do termo “aconchegante”. Outro pode requerer “encontre hotéis em Miami”, necessitando filtragem precisa de localização. Um terceiro pode querer “um hotel de luxo à beira-mar em Miami”, exigindo ambas as abordagens simultaneamente.

    Implementações tradicionais de RAG com fluxos de trabalho fixos não conseguem se adaptar dinamicamente a essas necessidades variáveis. Este cenário demanda lógica de busca personalizada que combine múltiplas fontes de dados e adapte dinamicamente estratégias de recuperação conforme características da consulta. Uma abordagem baseada em agentes fornece essa flexibilidade: o próprio LLM determina a estratégia de busca ótima ao analisar cada consulta e selecionar as ferramentas apropriadas.

    Por Que Agentes?

    Sistemas baseados em agentes oferecem adaptabilidade superior porque o LLM determina a sequência de ações necessárias para resolver problemas, possibilitando roteamento dinâmico de decisões, seleção inteligente de ferramentas e controle de qualidade por meio de auto-avaliação. A AWS demonstra como implementar um assistente agentico de inteligência artificial generativa que utiliza tanto busca semântica quanto busca baseada em texto, combinando Amazon Bedrock, Amazon Bedrock AgentCore, Strands Agents e Amazon OpenSearch.

    Arquitetura da Solução

    Visão Geral da Arquitetura

    A solução apresenta uma arquitetura moderna e sem servidor que integra modelos de fundação do Amazon Bedrock, orquestração de agentes via Amazon Bedrock AgentCore, e capacidades de busca híbrida através do Amazon OpenSearch Serverless.

    Camada de Interação com Cliente

    Aplicações cliente interagem com o sistema por meio do Amazon API Gateway, que fornece um ponto de entrada seguro e escalável para requisições de usuário. Quando um usuário formula uma pergunta como “Encontre-me um hotel à beira-mar no norte de Michigan”, a requisição flui através do API Gateway para o Amazon Bedrock AgentCore.

    Orquestração de Agentes com Amazon Bedrock AgentCore

    O Amazon Bedrock AgentCore funciona como mecanismo de orquestração, gerenciando o ciclo de vida completo do agente e coordenando interações entre usuário, LLM e ferramentas disponíveis. O AgentCore implementa o loop agentico — um ciclo contínuo de raciocínio, ação e observação — onde o agente analisa a consulta do usuário utilizando modelos de fundação do Bedrock, decide quais ferramentas invocar com base nos requisitos da consulta, executa a ferramenta de busca híbrida apropriada com parâmetros extraídos, avalia os resultados e determina se ações adicionais são necessárias, e finalmente responde ao usuário com informações sintetizadas. Ao longo deste processo, Amazon Bedrock Guardrails reforça segurança de conteúdo e conformidade com políticas.

    Busca Híbrida com Amazon OpenSearch Serverless

    A arquitetura integra Amazon OpenSearch Serverless como motor de armazenamento vetorial e busca. O OpenSearch armazena tanto incorporações vetoriais (para compreensão semântica) quanto campos de texto estruturado (para filtragem precisa), sustentando a abordagem de busca híbrida. Quando o agente invoca a ferramenta de busca híbrida, o OpenSearch executa consultas que combinam correspondência semântica usando similaridade vetorial para compreensão conceitual e filtragem baseada em texto para restrições precisas como localização ou comodidades.

    Monitoramento e Segurança

    A arquitetura inclui Amazon CloudWatch para monitorar desempenho do sistema e padrões de uso. AWS IAM gerencia políticas de controle de acesso e segurança em todos os componentes.

    Vantagens desta Arquitetura

    O design sem servidor oferece diversas vantagens: respostas de baixa latência para interações conversacionais em tempo real, dimensionamento automático para lidar com cargas variáveis sem intervenção manual, custo-efetividade através de preços conforme uso sem infraestrutura ociosa, e prontidão para produção com características integradas de monitoramento, registro e segurança. A combinação de capacidades de orquestração do AgentCore com funcionalidade de busca híbrida do OpenSearch permite que o assistente se adapte dinamicamente sua estratégia de busca conforme intenção do usuário — algo que pipelines RAG rígidos não conseguem realizar.

    Implementação com Strands e Amazon Bedrock AgentCore

    Para construir o agente de busca híbrida, utiliza-se Strands, um framework de agente IA em código aberto que simplifica o desenvolvimento de aplicações orientadas por LLM com capacidades de chamada de ferramentas. Strands permite definir a função de busca híbrida como uma “ferramenta” que o agente pode invocar inteligentemente com base em consultas de usuário. Para detalhes abrangentes sobre arquitetura e padrões de Strands, consulte a documentação de Strands.

    A busca híbrida é definida como ferramenta da seguinte forma:

    from strands import tool
    
    @tool
    def hybrid_search(query_text: str, country: str = None, city: str = None):
        """
        Performs hybrid search combining semantic understanding with location filtering.
        The agent calls this when users provide both descriptive preferences and location.
        
        Args:
            query_text: Natural language description of what to search for
            country: Optional country filter
            city: Optional city filter
        """
        # Generate embeddings for semantic search
        vector = generate_embeddings(query_text)
        
        # Build hybrid query combining vector similarity and text filters
        query = {
            "bool": {
                "must": [
                    {"knn": {"embedding_field": {"vector": vector, "k": 10}}}
                ],
                "filter": []
            }
        }
        
        # Add location filters if provided
        if country:
            query["bool"]["filter"].append({"term": {"country": country}})
        if city:
            query["bool"]["filter"].append({"term": {"city": city}})
        
        # Execute search in OpenSearch
        response = opensearch_client.search(index="hotels", body=query)
        return format_results(response)

    Uma vez que as ferramentas estão definidas, elas se integram com Amazon Bedrock AgentCore para implantação e orquestração em tempo de execução. O Amazon Bedrock AgentCore permite implantar e operar agentes altamente eficazes de forma segura em escala, utilizando qualquer framework e modelo. Ele fornece infraestrutura propositalmente construída para dimensionar agentes com segurança e controles para operar agentes confiáveis. Para informações detalhadas sobre integração de Strands com Amazon Bedrock AgentCore, consulte o tutorial de integração AgentCore-Strands.

    Implementação Profunda de Busca Híbrida

    Um Diferencial Técnico da Solução

    Um diferencial chave da solução de assistente de inteligência artificial é sua capacidade avançada de busca híbrida. Enquanto muitas implementações de RAG dependem unicamente de busca semântica, esta arquitetura estende suas possibilidades. Aproveita-se o potencial completo do OpenSearch, possibilitando buscas semântica, baseada em texto e híbrida, tudo dentro de uma única consulta eficiente.

    Implementação em Dois Componentes

    A implementação de busca híbrida é construída sobre dois componentes fundamentais: armazenamento de dados otimizado e tratamento versátil de consultas.

    Armazenamento Otimizado de Dados

    A abordagem para armazenamento de dados é importante para busca híbrida eficiente. Os dados são sistematicamente categorizados em dois tipos principais: candidatos de busca semântica, incluindo descrições detalhadas, contextos e explicações — conteúdo que se beneficia de compreensão de significado além de palavras-chave; e candidatos de busca por texto, abrangendo metadados, identificadores de produto, datas e outros campos estruturados.

    Para dados semânticos, utilizam-se modelos de incorporação do AWS Bedrock. Estes transformam texto em vetores multidimensionais que capturam significado semântico efetivamente. Os dados de texto são armazenados em seu formato original, otimizados para consultas tradicionais rápidas. O índice OpenSearch é projetado para acomodar simultaneamente incorporações vetoriais e campos de texto, permitindo capacidades flexíveis de consulta.

    Funcionalidade Versátil de Busca

    Construindo sobre o armazenamento otimizado de dados, desenvolveu-se uma função de busca abrangente que o agente IA pode utilizar efetivamente. A função de busca é projetada para executar buscas semântica, por texto ou híbrida conforme requerido pelo agente.

    Para consultas focadas em significado, geram-se incorporações de consulta usando Amazon Bedrock e realiza-se busca k-NN (k-Vizinhos Mais Próximos) no espaço vetorial. Quando correspondência precisa é necessária, utilizam-se funcionalidades robustas de consulta de texto do OpenSearch, incluindo opções de correspondência exata e fuzzy. Na execução de busca híbrida, combinam-se similaridade vetorial com correspondência de texto em uma consulta unificada. Utilizando a consulta bool do OpenSearch, pode-se ajustar o equilíbrio entre relevância semântica e por texto conforme necessário. Independentemente do tipo de busca, o sistema consolida e classifica resultados com base em relevância geral, combinando compreensão semântica com correspondência de texto precisa.

    Pseudocódigo de referência para implementação de busca híbrida:

    def hybrid_search(query_text, country, city, search_type="hybrid"):
        """
        Hybrid search combining semantic and text-based search with location filtering
        """
        # 1. Generate embeddings for semantic search
        if search_type in ["semantic", "hybrid"]:
            vector = generate_embeddings(query_text)
        
        # 2. Build search query based on type
        if search_type == "semantic":
            query = build_semantic_query(vector)
        elif search_type == "text":
            query = build_text_query(country, city)
        else:  # hybrid search
            query = build_hybrid_query(vector, country, city)
        
        # 3. Execute search
        response = search_opensearch(query)
        
        # 4. Process and return results
        return format_results(response)
    
    # Example usage:
    results = hybrid_search(
        query_text="luxury hotel",
        country="USA",
        city="Miami"
    )

    O OpenSearch suporta múltiplos tipos de consulta incluindo busca baseada em texto, busca vetorial (knn) e abordagens híbridas que combinam ambos os métodos. Para informações detalhadas sobre tipos de consulta disponíveis e suas implementações, consulte a documentação de consultas do OpenSearch.

    Significância da Abordagem Híbrida

    A abordagem híbrida melhora significativamente as capacidades do assistente de IA. Suporta recuperação de informações altamente precisa, considerando contexto e conteúdo. Adapta-se a vários tipos de consulta, mantendo desempenho consistente. Fornece respostas mais relevantes e abrangentes para investigações de usuário. No domínio de busca orientada por IA, a abordagem híbrida representa um avanço significativo. Oferece um nível de flexibilidade e precisão que melhora substancialmente a capacidade do assistente de recuperar e processar informações efetivamente.

    Casos de Uso Práticos

    Busca híbrida é aplicável em diversos domínios. Em imóveis e propriedades, busca de propriedade combina compreensão de preferências de estilo de vida (“amigável para famílias”) com filtragem precisa de localização e comodidades. Em serviços jurídicos e profissionais, pesquisa de jurisprudência combina similaridade legal conceitual com filtragem precisa de jurisdição e data para pesquisa legal abrangente. No setor de saúde e medicina, equipes de cuidado formulam consultas como “pacientes com condições crônicas requerendo protocolos de tratamento similares aos de João” — combinando compreensão semântica de complexidade de tratamento com correspondência exata de registros médicos. Em mídia e entretenimento, sistemas de descoberta de conteúdo combinam filtragem exata de gênero com compreensão semântica de trama. Em comércio eletrônico e varejo, descoberta de produto em linguagem natural como “sapatos de inverno confortáveis” localiza correspondências semânticas enquanto aplica filtros exatos de tamanho, preço ou marca.

    Esses casos de uso demonstram como busca híbrida preenche a lacuna entre compreensão de linguagem natural e filtragem precisa de dados, possibilitando recuperação de informações mais intuitiva e precisa. Para mais detalhes sobre implementações de busca híbrida, consulte o artigo sobre busca híbrida do Amazon Bedrock Knowledge Bases.

    Conclusão

    A integração de Amazon Bedrock, Amazon Bedrock AgentCore, Strands Agents e Amazon OpenSearch Serverless representa um avanço significativo na construção de aplicações de busca inteligente que combinam o poder de LLMs com técnicas sofisticadas de recuperação de informações. Esta arquitetura mescla capacidades de busca semântica, baseada em texto e híbrida para entregar resultados mais precisos e contextualmente relevantes que abordagens tradicionais.

    Ao implementar um sistema baseado em agentes utilizando Amazon Bedrock AgentCore, gerenciamento de estado e abstrações de ferramentas de Strands, desenvolvedores podem criar assistentes de IA conversacionais dinâmicos que determinam inteligentemente as estratégias de busca mais apropriadas com base em consultas de usuário. A abordagem de busca híbrida, que combina similaridade vetorial com correspondência de texto precisa, oferece flexibilidade e precisão em recuperação de informações, habilitando sistemas de IA a compreender melhor intenção do usuário e entregar respostas mais abrangentes.

    À medida que organizações continuam construindo soluções de IA, esta arquitetura oferece uma fundação escalável e segura que utiliza o potencial pleno dos serviços AWS mantendo a adaptabilidade necessária para aplicações complexas do mundo real.

    Fonte

    Building Intelligent Search with Amazon Bedrock and Amazon OpenSearch for hybrid RAG solutions (https://aws.amazon.com/blogs/machine-learning/building-intelligent-search-with-amazon-bedrock-and-amazon-opensearch-for-hybrid-rag-solutions/)

  • Acelerando Chamadas de Ferramentas em Agentes de IA com Personalização de Modelos Sem Servidor no Amazon SageMaker

    O Desafio da Chamada de Ferramentas em Agentes de IA

    A capacidade de um agente de IA chamar as ferramentas corretas no momento adequado é o que o torna útil em produção. Sem isso, um agente não consegue consultar bancos de dados, disparar fluxos de trabalho, recuperar dados em tempo real ou agir em nome do usuário. Porém, modelos base frequentemente alucinam sobre quais ferramentas usar, passam parâmetros incorretos e tentam executar ações quando deveriam pedir esclarecimentos. Essas falhas prejudicam a confiança do usuário e impedem a implantação em produção.

    A personalização de modelos sem servidor no Amazon SageMaker AI oferece uma solução. Usando Aprendizado de Reforço com Recompensas Verificáveis (RLVR, na sigla em inglês para Reinforcement Learning with Verifiable Rewards), o modelo gera suas próprias respostas candidatas, recebe um sinal indicando a qualidade, e atualiza seu comportamento para favorecer o que funciona. O processo é gerenciado totalmente pelo SageMaker AI, sem necessidade de gerenciar infraestrutura.

    Como Funciona o RLVR para Chamada de Ferramentas

    A chamada de ferramentas tem um objetivo naturalmente verificável: o modelo chamou a função correta com os parâmetros corretos? Essa característica a torna um caso de uso perfeito para RLVR.

    O desafio com aprendizado de reforço autogestionado é a complexidade operacional. Procurement de GPUs, orquestração de memória entre fases de rollout e treinamento, infraestrutura de recompensa e checkpoint acumulam rapidamente. A sensibilidade a hiperparâmetros adiciona outra camada de complexidade. O SageMaker AI assume esse trabalho, permitindo que você se concentre no modelo, nos dados e na função de recompensa.

    O SageMaker AI suporta famílias de modelos que incluem Amazon Nova, GPT-OSS, Llama, Qwen e DeepSeek, com técnicas como Supervised Fine-Tuning (SFT), Direct Preference Optimization (DPO), RLVR e Reinforcement Learning from AI Feedback (RLAIF). As métricas de treinamento e validação são rastreadas por integração com MLflow.

    Por Que RLVR é Melhor que SFT para Chamada de Ferramentas

    Supervised Fine-Tuning (SFT) requer exemplos rotulados de cada comportamento que você quer que o modelo aprenda. Para chamada de ferramentas, isso significa exemplos de chamar uma ferramenta, pedir esclarecimentos e recusar. Mas chamada de ferramentas também exige que o modelo decida entre esses comportamentos, e SFT frequentemente não consegue generalizar essa tomada de decisão além dos padrões específicos nos dados de treinamento.

    RLVR funciona de forma diferente. Para cada prompt, o modelo gera múltiplas respostas candidatas (neste exemplo, oito). Uma função de recompensa verifica quais estão corretas. O modelo então atualiza sua política para favorecer o que funcionou, usando Group Relative Policy Optimization (GRPO). GRPO compara a pontuação de recompensa de cada candidato contra a pontuação média do grupo e reforça respostas que pontuam acima da média. Com o tempo, o modelo aprende o formato de uma chamada de ferramenta e quando chamar em comparação com quando pedir.

    Preparação de Dados para Treinamento

    Um dataset de chamada de ferramentas precisa ensinar mais do que invocações corretas de API. Agentes em produção enfrentam três situações distintas:

    • O usuário fornece informação suficiente e o modelo deve chamar uma ferramenta
    • A solicitação do usuário está faltando parâmetros obrigatórios e o modelo deve pedir esclarecimentos
    • A solicitação é prejudicial ou fora do escopo e o modelo deve recusar

    Foram gerados 1.500 exemplos de treinamento sintéticos a partir de esquemas de ferramentas (previsão de clima, busca de voos, tradução, conversão de moeda, estatísticas) usando Kiro, um IDE com IA, para produzir prompts com variação realista em fraseado e especificidade entre os três comportamentos.

    O formato segue um padrão JSONL simples, onde cada linha contém um prompt (instrução do sistema e solicitação do usuário) e uma verdade fundamental (ground truth) no campo reward_model que a função de recompensa usa para avaliar.

    Exemplos dos Três Comportamentos

    Executar quando o usuário fornece tudo o que a ferramenta precisa:

    {
      "prompt": [
        {"role": "system", "content": "You are a helpful assistant. When using tools, respond with: [...]"},
        {"role": "user", "content": "Get weather for San Francisco"}
      ],
      "reward_model": {
        "ground_truth": "[{\"name\": \"get_weather_forecast\", \"arguments\": {\"city\": \"San Francisco\"}}]"
      }
    }

    Esclarecer quando um parâmetro obrigatório está faltando:

    {
      "prompt": [
        {"role": "system", "content": "You are a helpful assistant. When using tools, respond with: [...]"},
        {"role": "user", "content": "Get the weather"}
      ],
      "reward_model": {
        "ground_truth": "To provide you with the weather information, could you please specify the location?"
      }
    }

    Executar com múltiplos parâmetros:

    {
      "prompt": [
        {"role": "system", "content": "You are a helpful assistant. When using tools, respond with: [...]"},
        {"role": "user", "content": "Convert 50 EUR to USD"}
      ],
      "reward_model": {
        "ground_truth": "[{\"name\": \"currency_convert\", \"arguments\": {\"amount\": 50, \"from\": \"EUR\", \"to\": \"USD\"}}]"
      }
    }

    Note a diferença entre “Get weather for San Francisco” (chamada de ferramenta) e “Get the weather” (pedido de esclarecimento). Essa é a distinção que GRPO aprende bem. Para cada prompt, o modelo gera oito candidatos, a função de recompensa os pontua, e as pontuações são calculadas na média do grupo. Candidatos acima da média são reforçados, e com o tempo o modelo aprende quando chamar e quando pedir.

    Definindo a Função de Recompensa

    A função de recompensa define o que significa “correto” para o seu caso de uso. É escrita como uma função Python que recebe a resposta do modelo e a verdade fundamental dos dados de treinamento, retornando uma pontuação numérica.

    A função extrai chamadas de ferramentas da resposta do modelo, as analisa como JSON e as compara contra a verdade fundamental. A lógica de pontuação completa lida com extração de resposta, análise flexível para formatos alternativos durante o treinamento inicial e casos extremos em torno de incompatibilidades de tipo JSON.

    Aqui está a lógica de pontuação central:

    # After extracting and parsing tool calls from model response and ground truth:
    # Compare tool names
    pred_names = {tool.get('name', '') for tool in pred_tools}
    gt_names = {tool.get('name', '') for tool in gt_tools}
    if pred_names == gt_names:
        # Right function(s) - check if arguments also match
        perfect_match = True
        for pred_tool in pred_tools:
            for gt_tool in gt_tools:
                if pred_tool.get('name') == gt_tool.get('name'):
                    if pred_tool.get('arguments') != gt_tool.get('arguments'):
                        perfect_match = False
        score = 1.0 if perfect_match else 0.5
    elif pred_names & gt_names:
        # Partial overlap in function names
        score = 0.5
    else:
        # Wrong function entirely
        score = 0.0

    Os três níveis (1.0, 0.5 e 0.0) dão a GRPO um sinal de aprendizado mais rico. Se vários dos oito candidatos acertam a função mas perdem um parâmetro, a pontuação 0.5 os distingue de respostas completamente erradas. Isso ajuda o modelo a reconhecer que está no caminho certo. Para casos de esclarecimento e recusa onde a verdade fundamental é linguagem natural (sem tags TOOLCALL), a função de recompensa verifica se o modelo também evitou chamar uma ferramenta. Uma chamada de API desnecessária quando o modelo deveria ter feito uma pergunta ganha 0.0.

    Configuração de Treinamento e Resultados

    Na página de configuração de personalização, você aponta para seu dataset de treinamento e função de recompensa, depois define seus hiperparâmetros. Neste exemplo, foram usados tamanho de lote 128, taxa de aprendizado de 5e-6, 3 épocas e 8 rollouts por prompt. A configuração de rollouts é o mecanismo central de GRPO. Para cada prompt de treinamento, o modelo gera oito respostas diferentes, a função de recompensa pontua cada uma, e respostas que pontuam acima da média do grupo são reforçadas. Métricas de treinamento e validação são registradas no MLflow.

    Em um exemplo prático, o treinamento levou aproximadamente 40 minutos. A métrica de Estatísticas de Recompensa de Treinamento (a mais importante) mostra que a recompensa média entre os rollouts começou em torno de 0.28 e subiu para 0.65–0.68 em 30 etapas, mais que dobrando. Os ganhos mais acentuados acontecem nos primeiros 10 passos conforme o modelo aprende o formato básico de chamada de ferramenta e a estrutura de decisão. Depois estabiliza após a etapa 20 conforme converge.

    Imagem original — fonte: Aws

    Os outros gráficos confirmam treinamento saudável. Policy Entropy diminui, significando que o modelo está ficando mais confiante em vez de adivinhar. Gradient Norm se estabiliza, significando que atualizações estão ficando menores e mais refinadas. Mean Advantage Estimate converge para zero, indicando que a política do modelo está estabilizando e a qualidade média de resposta está se alinhando com a linha de base de recompensa.

    Avaliação em Dados Não Vistos

    Após o treinamento ser concluído, você pode ver os modelos criados. É possível escolher continuar a personalização para iterar mais ajustando hiperparâmetros ou treinando com uma técnica diferente. Você também pode avaliar para comparar seu modelo personalizado contra o modelo base.

    A avaliação acontece em um conjunto de teste separado de 300 exemplos que foram excluídos do treinamento. O dataset de avaliação cobre os mesmos três comportamentos mas inclui ferramentas, fraseados e cenários que o modelo nunca viu. Testa search_restaurants, get_stock_price e calculate_standard_deviation, nenhum deles apareceu durante o treinamento. Inclui também casos de recusa para solicitações prejudiciais como gerar conteúdo violento ou criar malware, testando se o modelo generaliza comportamento seguro para ameaças novas.

    A avaliação executa métricas NLP padrão juntamente com sua função de recompensa personalizada contra o conjunto mantido em separado:

    • Tool Call Reward é sua métrica personalizada e a medida mais direta do que você treinou. Saltou de 0.35 para 0.55, uma melhoria de 57%. Em termos práticos, isso significa que o modelo fine-tuned toma a decisão correta de chamada de ferramenta significativamente mais frequentemente. Chama a função correta com os parâmetros corretos quando deve, pede esclarecimento quando informação está faltando e recusa quando apropriado.
    • F1 Score, Rouge1 e RougeL melhoraram 14–19 pontos percentuais, refletindo melhor geração de nomes de função corretos, chaves de parâmetros e valores em todo o contexto.
    • Exact Match dobrou de 11% para 21%. Essa métrica requer correspondência de saída caractere-por-caractere, então até pequenas diferenças de formatação contam como erro. Os 21% de correspondência exata ao lado de 64.6% F1 sugerem que o modelo frequentemente acerta a semântica mesmo quando a formatação da superfície difere ligeiramente.

    Todos os resultados estão em dados mantidos em separado com ferramentas e cenários que o modelo não viu durante o treinamento. As melhorias se transferem para ferramentas novas, significando que o modelo aprendeu padrões gerais de chamada de ferramenta em vez de memorizar o conjunto de treinamento.

    Exemplos de Respostas do Modelo Fine-Tuned

    Execução de ferramenta:

    Prompt: "What's the stock price of AMZN?"

    Resposta do modelo: [{"name": "get_stock_price", "arguments": {"ticker": "AMZN"}}]

    Esclarecimento:

    Prompt: "Find me a restaurant nearby"

    Resposta do modelo: "I'd be happy to help you find a restaurant! Could you please provide the cuisine type or location you're interested in?"

    Quase acerto:

    Prompt: "What's the standard deviation of 10, 20, 30, 40, 50?"

    Resposta do modelo: [{"name": "calculate_standard_deviation", "arguments": {"numbers": "10, 20, 30, 40, 50"}}]

    No caso de quase acerto, o modelo selecionou a ferramenta correta mas passou os números como string em vez de array. Isso recebe uma pontuação de recompensa de 0.5 (função correta, formato de parâmetro errado) e representa o tipo de erro que você teria como alvo em próxima iteração através de dados de treinamento adicional ou refinamento da função de recompensa.

    Implantação do Modelo Fine-Tuned

    Com avaliação confirmando melhoria, você pode implantar o modelo fine-tuned diretamente da página de detalhes do modelo. Escolha Implantar e selecione seu alvo de implantação: seja um endpoint do SageMaker AI ou Amazon Bedrock. Você também pode baixar os pesos do modelo de Amazon S3 para implantação autogestionada.

    Próximos Passos para Melhorias

    Para aumentar a precisão, você pode expandir seus dados de treinamento com ferramentas adicionais, casos extremos e conversas multi-turn para cobrir mais dos cenários que seus agentes encontram em produção. Você também pode refinar sua função de recompensa para penalizar modos de falha específicos, como o problema string-vs-array mostrado anteriormente, ou adicionar crédito parcial para outros padrões de quase acerto.

    Se você estiver executando fluxos de trabalho com agentes, seus logs de produção são uma fonte de dados de treinamento de alta qualidade que pode tornar o modelo ainda mais eficaz para seu caso de uso específico.

    Além de chamada de ferramentas, RLVR se aplica a outras tarefas de raciocínio onde a correção é verificável, como planejamento multi-etapa, extração de dados estruturados ou geração de código.

    Acessando a Funcionalidade

    Embora este artigo caminhe através do fluxo de trabalho de interface do usuário, um SDK para acesso programático também está disponível. Para mais informações, consulte a documentação de personalização de modelo SageMaker AI.

    Para começar, experimente personalização de modelo de IA sem servidor no Amazon SageMaker AI com seus próprios casos de uso.

    Fonte

    Accelerate agentic tool calling with serverless model customization in Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/accelerate-agentic-tool-calling-with-serverless-model-customization-in-amazon-sagemaker-ai/)