Amazon a présenté une architecture d’analytique agentique basée sur SageMaker, Athena et Quick

AWS a démontré une architecture dans laquelle l'assistant agent Amazon Quick transforme l'analyse de lakehouse en libre-service pour les équipes métier. L'architecture combine S3, SageMaker, AWS Glue et Athena, permettant aux utilisateurs de poser des questions sur les données en langage naturel plutôt que via SQL.

Comment fonctionne l'architecture

Dans la démonstration, AWS utilise l'ensemble TPC-H et construit un lakehouse avec plusieurs couches dessus. Les données sont stockées dans Amazon S3, les métadonnées sont gérées via AWS Glue, et Amazon Athena devient une couche SQL unifiée pour les requêtes sur différents formats de stockage. L'exemple utilise simultanément des tables CSV externes ordinaires, des tables Iceberg en Parquet et des S3 Tables gérées. Cette approche n'est pas seulement pour l'élégance architecturale : l'entreprise démontre que la même question métier peut être adressée à des sources hétérogènes sans construction manuelle de data marts pour chaque scénario. Par-dessus cela, une couche utilisateur est assemblée dans Amazon Quick :

• ensembles de données dans SPICE pour les réponses rapides et les tableaux de bord
• Topic comme couche sémantique pour les termes métier
• tableaux de bord avec requêtes en langage naturel
• Knowledge Base basée sur la documentation et les spécifications
• Quick Space et chat agent comme interface unifiée

Ce que fait l'agent

La partie clé n'est pas simplement un chat sur les tables, mais une combinaison de Topic, Space et Knowledge Base. Topic agit comme une couche sémantique : il lie des formulations familières comme le revenu, le segment client ou le trimestre dernier à des champs spécifiques, des dates et des filtres dans l'ensemble de données. À l'intérieur de Quick, les données sont d'abord chargées dans SPICE, donc les tableaux de bord et les réponses aux questions typiques doivent fonctionner rapidement même à mesure que le lakehouse source se développe.

Pour les grands ensembles de données, AWS recommande de pré-combiner les tables dans Athena via du SQL personnalisé, puis de transmettre le résultat plat à Quick. Pour que l'agent réponde non seulement par des chiffres, AWS ajoute du contexte non structuré aux tables structurées. Dans la Knowledge Base, un rastreneur web charge la spécification TPC-H en PDF, et dans Quick Space, Topic, la base de connaissances et un tableau de bord prêt sont assemblés.

Après cela, l'agent de chat reçoit une boucle de connaissances gérée : il peut répondre aux questions sur les revenus et les statuts des commandes, et en même temps extraire les définitions des champs, la logique métier des requêtes et le sens des requêtes de benchmark de la documentation. L'idée est simple : une interface au lieu d'un ensemble d'écrans BI et de pages wiki disparates.

Où se trouve l'effet

Pour les affaires, le principal avantage est que l'analyse cesse d'être une file d'attente vers les spécialistes SQL et les équipes BI. L'utilisateur peut poser des questions sur le revenu par segment, la dynamique des commandes, les remises ou les articles de produits en langage ordinaire et obtenir une réponse liée aux données et visualisations. AWS souligne particulièrement que ce modèle est conçu non seulement pour le mode de démonstration : l'accès est restreint par les rôles, et les limites de visibilité sont héritées d'IAM et de Lake Formation.

C'est-à-dire qu'un employé ne voit que les tables, colonnes et sources pour lesquelles il dispose déjà de permissions. Mais le post montre simultanément le prix de telle commodité. Avant le lancement, vous devez configurer le catalogue Glue, les permissions Lake Formation, la connexion Athena, le chargement dans SPICE, Topic, Space, tableau de bord et un agent séparé.

C'est-à-dire qu'AWS ne promet pas la magie prête à l'emploi : l'analyse agent apparaît là où un lakehouse, des modèles d'accès et une sémantique de données soignée sont déjà en place. Mais en retour, l'entreprise obtient un chemin plus court de la question à la réponse et moins de travail manuel du côté des analystes.

Ce que cela signifie

AWS promeut effectivement l'étape suivante de la BI : non pas un nouveau tableau de bord, mais une couche d'interface agent sur le lakehouse existant. Si l'approche prend pied, les utilisateurs métier auront de plus en plus recours aux données par le dialogue, et les équipes de données se concentreront non pas sur les extractions ponctuelles, mais sur la qualité des modèles, des permissions et du contexte.