Amazon apresentou uma arquitetura de análise agêntica baseada em SageMaker, Athena e Quick

AWS demonstrou uma arquitetura na qual o assistente agente Amazon Quick transforma análise de lakehouse em self-service para equipes de negócios. A arquitetura combina S3, SageMaker, AWS Glue e Athena, permitindo que usuários façam perguntas sobre dados em linguagem natural em vez de através de SQL.

Como a Arquitetura Funciona

Na demonstração, AWS usa o conjunto TPC-H e constrói um lakehouse com múltiplas camadas sobre ele. Os dados são armazenados no Amazon S3, metadados são gerenciados através do AWS Glue, e o Amazon Athena se torna uma camada SQL unificada para consultas em diferentes formatos de armazenamento. O exemplo usa simultaneamente tabelas CSV externas comuns, tabelas Iceberg em Parquet e S3 Tables gerenciadas. Essa abordagem não é apenas por elegância arquitetônica: a empresa demonstra que a mesma pergunta de negócio pode ser endereçada a fontes heterogêneas sem construção manual de data marts para cada cenário. Por cima disso, uma camada de usuário é montada no Amazon Quick:

• conjuntos de dados no SPICE para respostas rápidas e dashboards
• Topic como uma camada semântica para termos de negócio
• dashboards com consultas em linguagem natural
• Knowledge Base baseada em documentação e especificações
• Quick Space e chat agent como uma interface unificada

O que o Agente Faz

A parte-chave não é apenas um chat sobre tabelas, mas uma combinação de Topic, Space e Knowledge Base. Topic atua como uma camada semântica: conecta formulações familiares como receita, segmento de cliente ou trimestre passado a campos específicos, datas e filtros no conjunto de dados. Dentro do Quick, os dados são carregados primeiro no SPICE, portanto dashboards e respostas a perguntas típicas devem funcionar rapidamente mesmo com o crescimento do lakehouse de origem.

Para grandes conjuntos de dados, AWS recomenda pré-combinar tabelas no Athena via SQL Personalizado, depois passar o resultado plano para Quick. Para fazer o agente responder não apenas por números, AWS adiciona contexto não-estruturado às tabelas estruturadas. No Knowledge Base, um rastreador da web carrega a especificação TPC-H em PDF, e no Quick Space, Topic, a base de conhecimento e um dashboard pronto são montados.

Depois disso, o agente de chat recebe um loop de conhecimento gerenciado: pode responder perguntas sobre receita e status de pedidos, e ao mesmo tempo extrair definições de campos, lógica de negócio de consultas e o significado de consultas de benchmark da documentação. A ideia é simples: uma interface em vez de um conjunto de telas BI e páginas de wiki díspares.

Onde Está o Efeito

Para negócios, o principal benefício é que análise deixa de ser uma fila para especialistas em SQL e equipes de BI. O usuário pode perguntar sobre receita por segmento, dinâmica de pedidos, descontos ou itens de produto em linguagem comum e obter uma resposta vinculada a dados e visualizações. AWS enfatiza particularmente que esse modelo é projetado não apenas para modo de demonstração: o acesso é restringido por funções, e os limites de visibilidade são herdados do IAM e do Lake Formation.

Ou seja, um funcionário vê apenas aquelas tabelas, colunas e fontes para as quais já possui permissões. Mas o post simultaneamente mostra o preço dessa conveniência. Antes do lançamento, você precisa configurar o catálogo Glue, permissões do Lake Formation, conexão do Athena, carregamento no SPICE, Topic, Space, dashboard e um agente separado.

Ou seja, AWS não promete mágica fora da caixa: análise agente aparece onde um lakehouse, modelos de acesso e semântica de dados cuidadosa já estão em vigor. Mas em troca, a empresa obtém um caminho mais curto da pergunta para a resposta e menos trabalho manual do lado da análise.

O que Isso Significa

AWS está efetivamente promovendo o próximo estágio de BI: não um novo dashboard, mas uma camada de interface agente no topo do lakehouse existente. Se a abordagem pegar, usuários de negócios recorrerão cada vez mais aos dados através do diálogo, e equipes de dados se concentrarão não em exportações pontuais, mas na qualidade de modelos, permissões e contexto.