Author: Make.com Service User

  • 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/)

  • CloudTroop Weekly #006 — 2026-w14





    CloudTroop Weekly #006 — 2026-w14

    5 de abril de 2026

    Resumo da Semana

    A semana foi dominada por segurança e IA agêntica em produção. A AWS entregou ferramentas que mudam a régua: pentests contínuos com IA, Bedrock Guardrails entre contas e controle de domínios para agentes autônomos saíram do papel. Ao mesmo tempo, ficou claro que frameworks tradicionais de segurança não dão conta de agentes autônomos — novos controles determinísticos são necessários. Compliance também ganhou força, com automação de evidências e guia prático para ISO 27001:2022. Quem opera multi-conta e workloads de IA precisa revisar postura agora.

    O que muda na prática

    • Pentests deixam de ser eventos pontuais: o AWS Security Agent automatiza avaliações contínuas com IA, reduzindo custo em até 90% e eliminando janelas cegas entre ciclos de auditoria.
    • Governança de IA agêntica vira obrigação operacional: Bedrock Guardrails entre contas e controle de domínios via Network Firewall permitem centralizar políticas de segurança para agentes em produção sem configuração manual por conta.
    • Coleta de evidências de compliance pode ser automatizada: a combinação de IA com fluxos de captura reduz drasticamente o esforço manual em auditorias, mudando o papel do time de GRC de executor para revisor.

    Ações da semana

    • Habilite o Bedrock Guardrails com escopo entre contas na sua organização AWS e mapeie quais workloads de IA generativa ainda operam sem controles centralizados — é configuração de horas, não dias.
    • Acesse o guia de conformidade ISO/IEC 27001:2022 para AWS e identifique pelo menos três controles da sua certificação que podem ser mapeados diretamente para serviços que você já usa.

    Top 10 da Semana

    1

    Testes de Penetração Contínuos com AWS Security Agent agora GA

    Reduz em até 90% o custo de pentests ao automatizá-los com IA 24/7, mudando avaliações periódicas para contínuas.

    Para quem: Times de segurança e arquitetos responsáveis por compliance e postura de segurança em nuvem.

    Segurança, IA

    2

    Quatro Princípios de Segurança para Sistemas de IA Autônoma

    Frameworks tradicionais de segurança são insuficientes para agentes autônomos; este guia define controles determinísticos externos essenciais.

    Para quem: Arquitetos de soluções e engenheiros de segurança que constroem ou governam sistemas de IA agêntica.

    Segurança, IA agêntica

    3

    Bedrock Guardrails: proteções entre contas agora GA

    Permite centralizar controles de segurança de IA em toda a organização AWS sem configuração manual por conta.

    Para quem: Equipes de segurança e cloud governance que gerenciam múltiplas contas com workloads de IA generativa.

    Segurança, IA

    4

    AWS KMS e Encryption SDK superam limites da criptografia AES-GCM

    Elimina o risco operacional de ultrapassar limites de criptografia simétrica em escala sem rastreamento manual de chaves.

    Para quem: Engenheiros de segurança e desenvolvedores que implementam criptografia em aplicações de alto volume na AWS.

    Segurança, Criptografia

    5

    Controle de domínios para agentes de IA com Bedrock AgentCore

    Resolve um gap crítico de segurança ao restringir o acesso à internet de agentes de IA com filtragem corporativa via Network Firewall.

    Para quem: Engenheiros de segurança e arquitetos que colocam agentes de IA em produção com acesso à internet.

    Segurança, IA agêntica

    6

    Amazon Bedrock AgentCore Evaluations: avalie agentes em produção

    Oferece avaliação sistemática de agentes de IA em três níveis hierárquicos, essencial para garantir qualidade antes e após o deploy.

    Para quem: Engenheiros de ML e times de produto que desenvolvem e operam agentes de IA baseados em Bedrock.

    IA agêntica, Qualidade

    7

    Amazon ECS: Daemons Gerenciados para instâncias ECS

    Simplifica o deploy centralizado de agentes de segurança e observabilidade em toda a frota de containers, reduzindo drift de configuração.

    Para quem: Engenheiros de plataforma e DevOps que operam clusters ECS com requisitos de segurança e observabilidade uniformes.

    Containers, Operações

    8

    Guia de Conformidade ISO/IEC 27001:2022 para AWS disponível

    Fornece mapeamento prático de controles ISO 27001:2022 para serviços AWS, acelerando certificações e auditorias de SGSI.

    Para quem: Arquitetos de segurança, equipes de compliance e profissionais que conduzem ou preparam auditorias ISO 27001.

    Compliance, Segurança

    9

    CloudWatch integra achados CSPM do Security Hub org-wide

    Centraliza vulnerabilidades e achados de conformidade de múltiplas contas no CloudWatch, unificando observabilidade e postura de segurança.

    Para quem: Times de segurança e SREs responsáveis por monitoramento centralizado em ambientes multi-conta.

    Observabilidade, Segurança

    10

    Automatizando coleta de evidências de conformidade com IA

    Reduz drasticamente o esforço manual de auditorias ao gerar fluxos automatizados de captura de evidências a partir de documentos de compliance.

    Para quem: Profissionais de GRC, auditores internos e equipes de compliance que gerenciam evidências para certificações regulatórias.

    Compliance, IA


  • Amazon Bedrock Guardrails anuncia disponibilidade geral de proteções entre contas

    Controle de segurança centralizado para modelos de IA

    A AWS anunciou a disponibilidade geral de uma capacidade significativa no Amazon Bedrock Guardrails: as proteções entre contas (cross-account safeguards). Essa funcionalidade permite que as equipes de segurança central de uma organização implementem automaticamente controles de segurança em todas as contas AWS, eliminando a necessidade de configurações repetitivas em cada conta individual.

    O Amazon Bedrock Guardrails já oferecia salvaguardas configuráveis capazes de bloquear até 88% do conteúdo prejudicial em múltiplas modalidades (texto, imagem e outros formatos), tanto em prompts de entrada quanto em respostas dos modelos de fundação. Agora, com as proteções entre contas, essa capacidade ganhou uma camada de automação e centralização organizacional.

    Como funcionam as proteções entre contas

    O mecanismo é direto: administradores podem especificar um identificador de guardrail da conta de gerenciamento em uma nova política do Amazon Bedrock que se propaga automaticamente para todas as entidades membro, incluindo unidades organizacionais (OUs) e contas individuais. Dessa forma, toda e qualquer invocação de modelo no Amazon Bedrock passa automaticamente pelos mesmos controles de segurança definidos centralmente.

    Esse modelo de enforçamento oferece três níveis de implementação:

    • Proteção de baseline organizacional: Define um padrão de segurança uniforme para toda a organização
    • Controles por conta: Permite ajustes específicos conforme necessidade de departamentos ou unidades de negócio
    • Salvaguardas específicas de aplicação: Completa as políticas organizacionais com proteções direcionadas para casos de uso particulares

    Durante as invocações do modelo, múltiplos guardrails são aplicados de forma conjunta, garantindo que o conteúdo prejudicial seja bloqueado mesmo com regras em diferentes níveis de hierarquia.

    Disponibilidade e acesso

    A funcionalidade já está disponível em todas as regiões comerciais da AWS e em regiões GovCloud onde o Bedrock Guardrails é suportado. Ela pode ser acessada tanto pelo console de gerenciamento da AWS quanto através das APIs suportadas.

    Para quem deseja aprofundar a implementação dessa capacidade, a AWS disponibiliza recursos complementares. Recomendamos consultar o artigo de blog sobre guardrails centralizados, explorar a documentação completa do Amazon Bedrock Guardrails e conferir a página de serviço do Amazon Bedrock Guardrails para informações adicionais. Também existe documentação específica sobre políticas do Amazon Bedrock no guia de organizações da AWS.

    Impacto para equipes de segurança

    Essa mudança reduz significativamente o overhead operacional de grandes organizações que precisam manter padrões de segurança consistentes em dezenas ou centenas de contas AWS. Em vez de replicar manualmente cada guardrail em cada ambiente, as equipes de segurança central podem agora estabelecer políticas uma única vez e deixar que elas se propaguem automaticamente para toda a infraestrutura de IA da organização.

    Fonte

    Amazon Bedrock Guardrails announces general availability of cross-account safeguards (https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-guardrails-cross-account-safeguards/)

  • Agentes de Troubleshooting e Upgrade do Apache Spark Agora Disponíveis como Poderes Kiro

    Automação Inteligente para Operações com Apache Spark

    A AWS anunciou a disponibilidade de dois agentes especializados para Apache Spark no Amazon EMR, agora integrados como poderes no Kiro — uma plataforma que oferece acesso em um clique a operações Spark assistidas por inteligência artificial. Essa integração representa um avanço significativo na forma como engenheiros de dados lidam com desafios comuns em ambientes de processamento de dados em larga escala.

    Os novos poderes transformam a experiência dos profissionais ao reduzir drasticamente o tempo necessário para resolver problemas. Enquanto troubleshooting manual poderia demandar horas, o agente especializado comprime esse processo em minutos. De forma similar, atualizações de versão do Spark — que tradicionalmente consumiam meses de planejamento e execução — agora podem ser completadas em semanas.

    Capacidades dos Agentes

    Agente de Troubleshooting

    O agente de diagnóstico funciona através de análise profunda de logs, métricas e configurações. Ele opera tanto no EMR em EC2 quanto no EMR Serverless, oferecendo uma visão integrada do ambiente. Quando um job Spark falha, o agente identifica a causa raiz e fornece recomendações de código específicas para aplicações PySpark, acelerando a recuperação de falhas.

    Agente de Upgrade

    O agente de atualização automatiza o processo de upgrade de versões Spark, como migração do EMR 6.5 para EMR 7.12. A ferramenta gerencia transformação de código e resolução de dependências, realizando validação remota e comparação de qualidade de dados no EMR — tarefas que normalmente exigem intervenção manual extensiva.

    Segurança e Auditoria

    Ambos os poderes conectam aos agentes Spark através do MCP Proxy para AWS, utilizando autenticação baseada em papéis IAM. Cada ação executada pelos agentes é registrada no AWS CloudTrail, garantindo rastreabilidade completa e conformidade com políticas de auditoria empresariais.

    Como Começar

    Os agentes estão disponíveis em todas as regiões comerciais da AWS. Para iniciá-los, engenheiros de dados podem instalar o poder de troubleshooting do Apache Spark ou o poder de upgrade diretamente do Kiro IDE. A documentação dos agentes de troubleshooting e agentes de upgrade fornece instruções detalhadas para configuração e uso.

    Impacto para Equipes de Dados

    Essa inovação tem implicações práticas significativas para organizações que operam Apache Spark em escala. A redução de tempo em troubleshooting libera recursos de engenharia para trabalhos de maior valor agregado. A aceleração de upgrades de versão reduz ciclos de manutenção e permite que equipes aproveitem mais rapidamente melhorias de performance e segurança em versões mais recentes.

    Fonte

    Apache Spark troubleshooting and upgrade agents now available as Kiro powers (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-emr-spark-troubleshooting-upgrade-kiro-power/)

  • Como AWS KMS e AWS Encryption SDK Superam os Limites da Criptografia Simétrica

    Entendendo o Desafio da Criptografia em Escala

    Aplicações que operam em larga escala e lidam com volumes significativos de dados criptografados enfrentam um desafio técnico importante: acompanhar os limites de criptografia e gerenciar a rotação de chaves de forma eficiente. Este artigo explora como a AWS Key Management Service (AWS KMS) e o AWS Encryption SDK resolvem automaticamente os limites de criptografia do padrão AES-GCM (Advanced Encryption Standard em Galois Counter Mode), utilizando métodos de derivação de chaves. Isso elimina a necessidade de os desenvolvedores rastrearem manualmente esses limites.

    A abordagem utiliza chaves derivadas que são geradas a partir de uma chave principal por meio de um valor aleatório chamado nonce. Dessa forma, cada operação de criptografia usa uma chave única, permitindo que a chave principal seja reutilizada por muito mais tempo. Métodos similares de derivação de chaves têm sido propostos em esquemas recentes como o (KC-)XAES, DNDK v2, e outros trabalhos acadêmicos da comunidade criptográfica.

    Os Limites da Criptografia Simétrica

    Criptografia AEAD e AES-GCM

    Algoritmos de criptografia simétrica protegem grandes volumes de dados, tanto em trânsito quanto em repouso. Os cifras modernos também autenticam os dados usando uma tag de autenticação — essas são chamadas de cifras AEAD (Authenticated Encryption with Additional Data). Exemplos incluem o AES-GCM e o ChaCha20/Poly1305.

    O AES-GCM é o algoritmo de criptografia mais amplamente utilizado e foi padronizado pelo NIST na especificação SP 800-38D. Este algoritmo utiliza uma chave de 128 ou 256 bits (K), um vetor de inicialização (IV) de 96 bits e criptografa um texto simples (P), autenticando também dados adicionais (AAD). O resultado é um texto cifrado (C) e uma tag de autenticação (T).

    Na descriptografia, o receptor recupera o texto simples original utilizando a chave, o IV e os dados autenticados, depois valida a tag para garantir a integridade da mensagem.

    Limite de Invocações de Criptografia

    Um requisito crítico para a segurança do AES-GCM é que o par (chave K, IV) nunca se repita durante toda a vida útil da chave. Se isso acontecer, as propriedades de segurança do algoritmo são comprometidas. A especificação SP 800-38D exige que a implementação mantenha uma probabilidade de reutilização inferior a 1 em 4,29 bilhões (menor que 2⁻³²).

    Isso pode ser alcançado utilizando um IV determinístico que não se repete ou um IV aleatório. Se um IV aleatório é usado, torna-se necessário trocar a chave após 2³² criptografias. Protocolos comuns como TLS ou IKEv2/IPsec evitam colisões do par (K, IV) usando IVs determinísticos que começam com um valor aleatório e são incrementados para cada conexão.

    Limite de Volume de Dados

    Além do limite de invocações, existe também um limite relacionado ao volume total de dados que pode ser criptografado com a mesma chave. O contador de blocos no AES-GCM é de 32 bits, o que resulta em um limite de 2³²-2 bytes (aproximadamente 68,72 GB) por operação de criptografia, ou seja, por cada par único (K, IV).

    Quando não se restringe o volume total de dados criptografados, reduz-se a garantia de segurança de indistinguibilidade — a capacidade de um adversário de não conseguir distinguir entre dois textos cifrados diferentes. Quanto maior a proteção de indistinguibilidade, menor é o total de bytes que podem ser criptografados sob uma única chave.

    A especificação do NIST sugere um limite de 2⁶⁸ bytes protegidos sob uma chave única, o que fornece uma probabilidade de indistinguibilidade de 50%. Porém, margens de segurança mais conservadoras baseadas em diferentes análises criptográficas são frequentemente utilizadas. A AWS adota uma abordagem ainda mais conservadora, impondo por padrão uma probabilidade de indistinguibilidade negligenciável (menor que 2⁻³²).

    Quando se atinge os limites de dados do AES-GCM para uma determinada margem de segurança, é necessário fazer a rotação da chave simétrica. Em aplicações modernas de criptografia em larga escala, esses limites (por exemplo, 2³² criptografias com IVs aleatórios ou o volume máximo de dados por chave) podem ser atingidos. Rastrear esses limites em sistemas distribuídos com muitas sessões concorrentes adiciona complexidade operacional significativa. A AWS compartilhou essas dificuldades em um documento detalhado e uma apresentação no terceiro Workshop do NIST sobre Modos de Cifra em Blocos de 2023.

    Como AWS KMS Utiliza Chaves Derivadas

    A AWS KMS é um serviço gerenciado que permite criar e controlar as chaves utilizadas para criptografar e assinar dados. A API Encrypt do KMS suporta criptografia simétrica e assimétrica. Para criptografia com chaves simétricas, o AWS KMS utiliza AES-GCM com chaves de 256 bits para criptografar um texto simples de até 4 KB.

    Quando uma solicitação ao KMS Encrypt é feita, ela inclui o texto simples e o identificador da chave simétrica gerenciada pelo cliente armazenada no KMS. A chamada da API de Encrypt usa a chave para derivar uma chave de criptografia simétrica antes de criptografar o texto simples.

    O processo funciona da seguinte forma: a AWS KMS gera um nonce aleatório de 128 bits e produz uma chave simétrica de 256 bits a partir da chave principal especificada, utilizando uma função de derivação de chaves (KDF). Essa função recebe a chave, um rótulo e contexto, um nonce específico da invocação, e um comprimento de saída desejado, produzindo material de chave do tamanho especificado.

    Para o AWS KMS, a função KDF é o Counter Mode KDF conforme a especificação SP 800-108r1 do NIST, que produz 256 bits de material de chave utilizando HMAC-SHA256 como função pseudoaleatória. A chave derivada é produzida com uma chamada ao HMAC-SHA256 com a chave principal:

    Subsequentemente, o AWS KMS gera um IV aleatório de 96 bits e criptografa o texto simples de entrada com AES-GCM. O resultado inclui o IV, o nonce, o texto cifrado e a tag de autenticação. Estes componentes são retornados em um blob de texto cifrado (CiphertextBlob) que pode ser descriptografado em chamadas posteriores à API Decrypt.

    Intuitivamente, o nonce aleatório de 128 bits usado para derivar uma chave única de criptografia sob uma chave gerenciada permite que o chamador ultrapasse significativamente o limite de 2³² invocações de criptografia sob essa chave. Além disso, o limite de 4 KB no tamanho da carga útil para uma chamada AWS Encrypt garante que o volume total de dados criptografados sob uma chave de criptografia permaneça bem abaixo dos limites totais de criptografia do NIST ou de outras margens mais conservadoras. Para mais detalhes sobre os fundamentos matemáticos e criptográficos desse esquema, consulte o artigo Key Management Systems at the Cloud Scale.

    Como AWS Encryption SDK Aplica Modos de Chave Derivada

    O AWS Encryption SDK é uma biblioteca de criptografia do lado do cliente usada para criptografar e descriptografar dados. Pode ser configurado para usar cache de chaves de dados, reduzindo chamadas de API ao criptografar múltiplas cargas úteis.

    Usar uma chave derivada baseada em nonce para cada invocação de AES-GCM elimina a necessidade de os clientes acompanharem o volume total de dados que criptografam sob uma única chave de dados. Embora o AWS Encryption SDK ofereça muita flexibilidade para acomodar diversos cenários de criptografia, a configuração padrão lida com derivação de chaves e dimensionamento de frames automaticamente, elimando a necessidade de ajustar essas configurações para a maioria dos casos de uso.

    Para derivar uma chave diferente para cada invocação, assim como o AWS KMS, o SDK utiliza um valor aleatório gerado, a chave principal e contexto específico da invocação na KDF. O valor aleatório tem 256 bits na configuração padrão. A KDF subjacente é a Função de Derivação de Chaves baseada em HMAC (HKDF — HMAC-based Extract-and-Expand Key Derivation Function) com SHA512 como o hash padrão.

    A chave derivada é produzida com uma chamada ao HKDF com a chave principal, usando um rótulo constante e um contexto que consiste em constantes concatenadas com um valor aleatório de 256 bits. Subsequentemente, o AWS Encryption SDK usa a chave derivada para criptografar o conteúdo do usuário, dividido em frames de 4 KB por padrão.

    Cada frame de texto simples é criptografado com AES-GCM usando um IV determinístico que consiste em um contador de frames, onde o ID do frame é menor que 2³². O dado autenticado adicional (AAD) é específico do frame de dados do Encryption SDK. Na descriptografia, o receptor deriva a chave da mesma forma e descriptografa o texto cifrado para produzir o texto simples do frame, validando a tag de autenticação.

    O tamanho padrão de 4 KB por frame garante que por padrão não mais que 2⁴⁴ bytes (2³² frames de 4 KB cada) possam ser criptografados sob uma única chave de criptografia. Isso está bem abaixo do limite sugerido pelo NIST (2⁶⁸ bytes), mesmo com cache de chaves de dados. Também está bem abaixo do requisito conservador da AWS de probabilidade de indistinguibilidade menor que 2⁻³².

    O limite de invocações por chave, mesmo com cache de chaves de dados, excede as contagens de criptografia na maioria das aplicações em larga escala.

    Considerações sobre Versões Anteriores

    Enquanto a configuração padrão do AWS Encryption SDK faz escolhas conservadoras, se você estiver usando a versão legada 1.0 ou fizer alterações de configuração, poderá ter garantias de segurança menores. Por exemplo, um tamanho máximo customizado de frame de 2³²-1 bytes levaria a um tamanho total de texto simples maior, que ainda está abaixo do limite sugerido pelo NIST de 2⁶⁸ bytes, mas não necessariamente abaixo de outras margens conservadoras.

    Vale notar que a configuração padrão do AWS Encryption SDK também fornece propriedades de segurança menos conhecidas, como compromisso de chave. A string de comprometimento é produzida de forma similar à chave derivada, utilizando a chave principal e HKDF.

    Conclusão

    Ao derivar uma chave única para cada chamada de criptografia, a AWS KMS e o AWS Encryption SDK eliminam a necessidade de rastrear manualmente os limites do AES-GCM. Para compreender os fundamentos acadêmicos dos limites do AES-GCM, consulte a especificação SP 800-38D e o rascunho draft-irtf-cfrg-aead-limits.

    Para leitura adicional sobre a análise criptográfica do esquema de derivação de chaves utilizado no KMS, consulte Key Management Systems at the Cloud Scale. Para mais detalhes sobre a derivação de chaves AES-GCM do Encryption SDK, veja a referência de algoritmos do AWS Encryption SDK.

    Fonte

    How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds (https://aws.amazon.com/blogs/security/how-aws-kms-and-aws-encryption-sdk-overcome-symmetric-encryption-bounds/)

  • Amazon SageMaker Data Agent: novas capacidades de visualização e suporte a materialized views

    Novas funcionalidades do Data Agent no SageMaker

    A AWS expandiu as capacidades do Amazon SageMaker Data Agent com recursos que vão muito além da simples geração de código. O serviço agora oferece uma abordagem completa para fluxos de análise de dados, integrando visualização interativa, suporte a fontes externas e otimização automática de consultas — tudo operado por prompts em linguagem natural dentro dos notebooks do SageMaker Unified Studio.

    Gráficos interativos sob demanda

    Uma das novidades mais práticas é a geração automática de gráficos interativos. Você pode simplesmente solicitar ao Data Agent: “plot monthly revenue trends by region for 2025” (plote as tendências de receita mensal por região para 2025). O sistema gera um gráfico interativo diretamente no notebook, permitindo que você passe o mouse sobre os pontos de dados e realize modificações — sem precisar escrever uma única linha de código.

    Integração com Snowflake e dados externos

    O Data Agent agora permite que suas análises atravessem múltiplas plataformas. Quando você trabalha simultaneamente com dados da AWS e Snowflake, é possível consultar tabelas Snowflake através de conexões externas e combiná-las com dados do AWS Glue Data Catalog em um único comando. Essa integração elimina a necessidade de movimentar dados ou escrever lógica complexa de join manualmente.

    Otimização automática com materialized views

    Um dos recursos mais inteligentes é a capacidade do agente em analisar seus notebooks e sugerir otimizações. Você pode pedir: “analyze my notebook and suggest which queries would benefit from materialized views” (analise meu notebook e sugira quais consultas se beneficiariam de materialized views). O sistema então recomenda otimizações baseadas nos padrões de suas consultas, cria as views automaticamente e configura cronogramas de atualização.

    Como começar

    Para utilizar essas funcionalidades, abra um notebook em seu projeto SageMaker Unified Studio e acesse o painel de chat do Data Agent. Os recursos estão disponíveis em todas as regiões AWS onde o SageMaker Unified Studio é suportado.

    Para aprofundar os detalhes técnicos, consulte a documentação do SageMaker Data Agent no SageMaker Unified Studio User Guide.

    Fonte

    Amazon SageMaker Data Agent introduces charting capabilities and support for materialized views (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-sgmkr-dataagent-chart-mv/)