Présentation de l’architecture - Générateur d'applications d'IA générative sur AWS
Schémas d'architecture

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Présentation de l’architecture

Cette section fournit des diagrammes d'architecture d'implémentation de référence pour les composants déployés avec cette solution.

Schémas d'architecture

Pour répondre à de multiples cas d'utilisation et besoins commerciaux, cette solution fournit six CloudFormation modèles AWS :

  1. Tableau de bord de déploiement - Le tableau de bord de déploiement est une interface Web qui sert de console de gestion permettant aux utilisateurs administrateurs de visualiser, de gérer et de créer leurs cas d'utilisation. Ce tableau de bord permet aux clients d'expérimenter, d'itérer et de mettre en production rapidement diverses AI/ML charges de travail en tirant parti de ces outils. LLMs

  2. Cas d'utilisation du texte - Le cas d'utilisation du texte permet aux utilisateurs de découvrir une interface en langage naturel à l'aide de l'IA générative. Ce cas d'utilisation peut être intégré dans des applications nouvelles ou existantes, et peut être déployé via le tableau de bord de déploiement ou indépendamment via une URL fournie.

  3. Cas d'utilisation de l'agent Bedrock - Le cas d'utilisation de l'agent Bedrock permet d'utiliser les agents Bedrock existants pour effectuer des tâches ou automatiser des flux de travail répétés.

  4. Serveur MCP - Le cas d'utilisation du serveur MCP permet le déploiement et la gestion de serveurs Model Context Protocol qui fournissent un accès standardisé aux outils et aux ressources pour les applications d'IA. Supporte à la fois les méthodes de passerelle pour encapsuler les fonctions Lambda existantes et les serveurs MCP externes APIs, ainsi que les méthodes d'exécution pour déployer des serveurs MCP conteneurisés personnalisés.

  5. Agent Builder : l'Agent Builder permet de créer et de déployer des agents d'intelligence artificielle prêts pour la production sur Amazon Bedrock AgentCore avec un contrôle complet de la configuration, l'intégration du serveur MCP et des fonctionnalités de gestion de la mémoire.

  6. Générateur de flux de travail : le générateur de flux de travail permet de créer des agents superviseurs qui orchestrent plusieurs agents Agent Builder à l'aide du modèle de délégation Agents as Tools pour les flux de travail multi-agents complexes.

Tableau de bord de déploiement

Décrit l'architecture du tableau de bord de déploiement (en cas de déploiement avec l'option VPC désactivée)

schéma du tableau de bord de déploiement

Décrit l'architecture du tableau de bord de déploiement (lorsqu'il est déployé avec l'option VPC activée)

schéma d'arc VPC du tableau de bord de déploiement
Note

Les CloudFormation ressources AWS sont créées à partir des constructions du kit AWS Cloud Development Kit (AWS CDK).

Le flux de processus de haut niveau pour les composants de solution déployés avec le CloudFormation modèle AWS est le suivant :

  1. Les utilisateurs administrateurs se connectent à l'interface utilisateur (UI) du tableau de bord de déploiement.

  2. Amazon CloudFront fournit l'interface utilisateur Web, qui est hébergée dans un compartiment Amazon Simple Storage Service (Amazon S3).

  3. AWS WAF les APIs protège des attaques. Cette solution configure un ensemble de règles appelé liste de contrôle d'accès Web (ACL Web) qui autorise, bloque ou compte les requêtes Web en fonction de règles et de conditions de sécurité Web configurables et définies par l'utilisateur.

  4. L'interface utilisateur Web utilise un ensemble de REST APIs qui sont exposés à l'aide d'Amazon API Gateway.

  5. Amazon Cognito authentifie les utilisateurs et soutient à la fois l'interface utilisateur CloudFront Web et l'API Gateway.

  6. AWS Lambda fournit la logique métier pour les points de terminaison REST. Cette fonction Lambda de soutien gère et crée les ressources nécessaires pour effectuer des déploiements de cas d'utilisation à l'aide d'AWS. CloudFormation

  7. Amazon DynamoDB stocke la liste des déploiements.

  8. Lorsqu'un nouveau cas d'utilisation est créé par l'utilisateur administrateur, la fonction Lambda de soutien lance un événement de création de CloudFormation pile pour le cas d'utilisation demandé.

  9. Toutes les options de configuration LLM fournies par l'utilisateur administrateur dans l'assistant de déploiement sont enregistrées dans DynamoDB. Le déploiement utilise cette table DynamoDB pour configurer le LLM lors de l'exécution.

  10. À l'aide d'Amazon CloudWatch, cette solution collecte des métriques opérationnelles auprès de divers services afin de générer des tableaux de bord personnalisés qui vous permettent de surveiller les performances et la santé opérationnelle de la solution.

Note

  • Si vous choisissez de déployer cette solution dans un Amazon VPC, les données seront acheminées au sein de votre réseau privé.

  • Bien que le tableau de bord de déploiement puisse être lancé dans la plupart des régions AWS, les cas d'utilisation déployés sont soumis à certaines restrictions en fonction de la disponibilité des services. Consultez la section Régions AWS prises en charge pour plus de détails.

Cas d'utilisation du texte

Décrit l'architecture des cas d'utilisation du texte (en cas de déploiement avec l'option VPC désactivée)

diagramme de cas d'utilisation du texte

Décrit l'architecture des cas d'utilisation du texte (lorsqu'elle est déployée avec l'option VPC activée)

schéma d'arc VPC du cas d'utilisation du texte

Le flux de processus de haut niveau pour les composants de solution déployés avec le CloudFormation modèle AWS est le suivant :

  1. Les utilisateurs administrateurs déploient le cas d'utilisation à l'aide du tableau de bord de déploiement. Les utilisateurs professionnels se connectent à l'interface utilisateur du cas d'utilisation.

  2. CloudFront fournit l'interface utilisateur Web hébergée dans un compartiment S3.

  3. L'interface utilisateur Web tire parti d'une WebSocket intégration créée à l'aide d'API Gateway. L'API Gateway est soutenu par une fonction d'autorisation Lambda personnalisée, qui renvoie la politique AWS Identity and Access Management (IAM) appropriée en fonction du groupe Amazon Cognito auquel appartient l'utilisateur authentifié. La politique est stockée dans DynamoDB.

  4. Amazon Cognito authentifie les utilisateurs et soutient à la fois l'interface utilisateur CloudFront Web et l'API Gateway.

  5. Les demandes entrantes de l'utilisateur professionnel sont transmises d'API Gateway à une file d'attente Amazon SQS, puis à l'LangChain orchestrateur. L'LangChain orchestrateur est un ensemble de fonctions et de couches Lambda qui fournissent la logique métier permettant de répondre aux demandes émanant de l'utilisateur professionnel. La file d'attente permet le fonctionnement asynchrone de l'intégration entre API Gateway et Lambda. La file d'attente transmet les informations de connexion aux fonctions Lambda qui publieront ensuite les résultats directement sur la connexion Websocket d'API Gateway afin de prendre en charge les appels d'inférence de longue durée.

  6. L'LangChain orchestrateur utilise Amazon DynamoDB pour obtenir les options LLM configurées et les informations de session nécessaires (telles que l'historique des discussions).

  7. Si une base de connaissances est activée pour le déploiement, l'LangChain orchestrateur utilise Amazon Kendra ou Knowledge Bases for Amazon Bedrock pour exécuter une requête de recherche afin de récupérer des extraits de documents.

  8. À l'aide de l'historique des discussions, de la requête et du contexte de la base de connaissances, l'LangChain orchestrateur crée l'invite finale et envoie la demande au LLM hébergé sur Amazon Bedrock ou Amazon AI. SageMaker

  9. Lorsque la réponse provient du LLM, l'LangChain orchestrateur la renvoie via l'API Gateway WebSocket pour être consommée par l'application cliente.

  10. À l'aide d'Amazon CloudWatch, cette solution collecte des métriques opérationnelles auprès de différents services afin de générer des tableaux de bord personnalisés qui vous permettent de surveiller les performances et la santé opérationnelle du déploiement.

  11. Si la collecte de commentaires est activée, un point de terminaison d'API REST, exploitant Amazon API Gateway, est mis à disposition pour recueillir les commentaires des utilisateurs.

  12. Le feedback, qui soutient Lambda, complète le feedback envoyé avec des métadonnées supplémentaires spécifiques au cas d'utilisation (par exemple, le modèle utilisé) et stocke les données dans Amazon S3 pour une analyse et des rapports ultérieurs par les DevOps utilisateurs.

Note

Si vous choisissez de déployer cette solution dans un Amazon VPC, les données seront acheminées vers votre réseau privé.

Cas d'utilisation de Bedrock Agent

Décrit l'architecture du cas d'utilisation de Bedrock Agent (lorsqu'il est déployé avec l'option VPC désactivée)

schéma de cas d'utilisation de l'agent

Décrit l'architecture du cas d'utilisation de Bedrock Agent (lorsqu'il est déployé avec l'option VPC activée)

schéma d'architecture VPC du cas d'utilisation de l'agent

Le flux de processus de haut niveau pour les composants de solution déployés avec le CloudFormation modèle AWS est le suivant :

  1. Les utilisateurs administrateurs déploient le cas d'utilisation à l'aide du tableau de bord de déploiement. Les utilisateurs professionnels se connectent à l'interface utilisateur du cas d'utilisation.

  2. CloudFront fournit l'interface utilisateur Web hébergée dans un compartiment S3.

  3. L'interface utilisateur Web tire parti d'une WebSocket intégration créée à l'aide d'API Gateway. L'API Gateway est soutenu par une fonction d'autorisation Lambda personnalisée, qui renvoie la politique AWS Identity and Access Management (IAM) appropriée en fonction du groupe Amazon Cognito auquel appartient l'utilisateur authentifié. La politique est stockée dans DynamoDB.

  4. Amazon Cognito authentifie les utilisateurs et soutient à la fois l'interface utilisateur CloudFront Web et l'API Gateway.

  5. Les demandes entrantes de l'utilisateur professionnel sont transmises d'API Gateway à une file d'attente Amazon SQS, puis à la fonction AWS Lambda. La file d'attente permet le fonctionnement asynchrone de l'intégration entre API Gateway et Lambda. La file d'attente transmet les informations de connexion à la fonction Lambda qui publiera ensuite les résultats directement sur la connexion Websocket d'API Gateway afin de prendre en charge les appels d'inférence de longue durée.

  6. La fonction AWS Lambda utilise Amazon DynamoDB pour obtenir les configurations de cas d'utilisation nécessaires

  7. À l'aide de l'entrée utilisateur et de toute configuration de cas d'utilisation pertinente, la fonction AWS Lambda crée et envoie une charge utile de demande à l'agent Amazon Bedrock configuré afin de répondre à l'intention de l'utilisateur.

  8. Lorsque la réponse provient de l'agent Amazon Bedrock, la fonction Lambda la renvoie via l'API WebSocket Gateway pour être consommée par l'application cliente.

  9. À l'aide d'Amazon CloudWatch, cette solution collecte des métriques opérationnelles auprès de différents services afin de générer des tableaux de bord personnalisés qui vous permettent de surveiller les performances et la santé opérationnelle du déploiement.

  10. Si la collecte de commentaires est activée, un point de terminaison d'API REST, exploitant Amazon API Gateway, est mis à disposition pour recueillir les commentaires des utilisateurs.

  11. Le feedback, qui soutient Lambda, complète le feedback envoyé avec des métadonnées supplémentaires spécifiques aux cas d'utilisation et stocke les données dans Amazon S3 pour une analyse et des rapports ultérieurs par les DevOps utilisateurs.

Note

Si vous choisissez de déployer cette solution dans un Amazon VPC, les données seront acheminées au sein de votre réseau privé.

Cas d'utilisation du serveur MCP

Décrit l'architecture des cas d'utilisation du serveur MCP

schéma de cas d'utilisation du serveur mcp

Le cas d'utilisation du serveur MCP permet le déploiement et la gestion de serveurs Model Context Protocol sur Amazon AgentCore Bedrock. Les serveurs MCP fournissent une interface standardisée permettant aux applications d'IA d'accéder aux outils, aux ressources et aux sources de données d'entreprise.

La solution prend en charge deux méthodes de déploiement :

  • Méthode de passerelle : transforme les fonctions Lambda existantes, les serveurs APIs REST ou les serveurs MCP externes en outils MCP, gérant automatiquement la traduction des protocoles

  • Méthode d'exécution : déploie des serveurs MCP conteneurisés personnalisés à partir d'images Amazon ECR

Le flux de processus de haut niveau pour le déploiement du serveur MCP est le suivant :

  1. Les utilisateurs administrateurs déploient le cas d'utilisation du serveur MCP à l'aide du tableau de bord de déploiement, en sélectionnant la méthode de déploiement Gateway ou Runtime.

  2. Cette action est authentifiée avec Amazon Cognito.

  3. Pour le déploiement de la passerelle, la solution crée une AgentCore passerelle Amazon Bedrock qui transforme les fonctions APIs Lambda existantes ou les serveurs MCP externes en outils compatibles avec le protocole MCP. Pour le déploiement du Runtime, la solution déploie des serveurs MCP conteneurisés sur Amazon Bedrock AgentCore Runtime à l'aide des images ECR fournies.

  4. Les déploiements de passerelles récupèrent les API/Lambda/Smithy schémas nécessaires depuis leur emplacement de téléchargement dans Amazon S3 ou se connectent directement aux points de terminaison URL du serveur MCP.

  5. Les déploiements d'exécution extraient le serveur MCP conteneurisé fourni par l'utilisateur depuis Amazon Elastic Container Registry (ECR)

  6. Le serveur MCP est équipé d'un client Amazon Bedrock Identity AgentCore OAuth

  7. Le serveur MCP met les outils associés à disposition sur le point de terminaison /mcp pour que les agents puissent les découvrir.

  8. Amazon CloudWatch collecte des statistiques opérationnelles et des journaux à partir des déploiements de serveurs MCP à des fins de surveillance et de résolution des problèmes.

Cas d'utilisation d'Agent Builder

Décrit l'architecture d'Agent Builder

schéma de déploiement d'agent builder

Le flux de processus de haut niveau pour les composants Agent Builder déployés avec le CloudFormation modèle AWS est le suivant :

  1. Les utilisateurs administrateurs déploient le cas d'utilisation à l'aide du tableau de bord de déploiement. Les utilisateurs professionnels se connectent à l'interface utilisateur du cas d'utilisation.

  2. CloudFront fournit l'interface utilisateur Web hébergée dans un compartiment S3.

  3. L'interface utilisateur Web tire parti d'une WebSocket intégration créée à l'aide d'API Gateway. L'API Gateway est soutenu par une fonction d'autorisation Lambda personnalisée, qui renvoie la politique AWS Identity and Access Management (IAM) appropriée en fonction du groupe Amazon Cognito auquel appartient l'utilisateur authentifié. La politique est stockée dans DynamoDB.

  4. Amazon Cognito authentifie les utilisateurs et soutient à la fois l'interface utilisateur CloudFront Web et l'API Gateway.

  5. Les demandes entrantes de l'utilisateur professionnel sont transmises d'API Gateway à une file d'attente Amazon SQS, puis à la fonction AWS Lambda. La file d'attente permet le fonctionnement asynchrone de l'intégration entre API Gateway et Lambda. La file d'attente transmet les informations de connexion à la fonction Lambda qui publiera ensuite les résultats directement sur la connexion Websocket d'API Gateway afin de prendre en charge les appels d'inférence de longue durée.

  6. La fonction AWS Lambda extrait la configuration de l'agent depuis DynamoDB.

  7. À l'aide de l'entrée utilisateur et de toute configuration de cas d'utilisation pertinente, la fonction AWS Lambda crée et envoie une charge utile de demande à l'agent, qui s'exécute sur Amazon Bedrock Runtime. AgentCore

  8. L'agent se connecte aux serveurs MCP associés et enregistre les outils sur l'instance de l'agent Strands. L'agent sélectionne et exécute ensuite des actions de manière autonome en fonction des descriptions des outils et des exigences des tâches.

  9. Lorsque la réponse provient de l' AgentCore environnement d'exécution Amazon Bedrock, la fonction Lambda la renvoie via l'API WebSocket Gateway pour être consommée par l'application cliente.

Note

  • Le traitement de l'agent est limité au délai d'exécution de Lambda (15 minutes).

Cas d'utilisation de Workflow Builder

Décrit l'architecture de Workflow Builder

schéma de déploiement du flux de travail

Le flux de processus de haut niveau pour les composants de Workflow Builder déployés avec le CloudFormation modèle AWS est le suivant :

  1. Les utilisateurs administrateurs déploient le flux de travail à l'aide du tableau de bord de déploiement, en sélectionnant les agents Agent Builder à inclure en tant qu'agents spécialisés.

  2. CloudFront fournit l'interface utilisateur Web hébergée dans un compartiment S3.

  3. L'interface utilisateur Web tire parti d'une WebSocket intégration créée à l'aide d'API Gateway. L'API Gateway est soutenu par une fonction d'autorisation Lambda personnalisée, qui renvoie la politique AWS Identity and Access Management (IAM) appropriée en fonction du groupe Amazon Cognito auquel appartient l'utilisateur authentifié. La politique est stockée dans DynamoDB.

  4. Amazon Cognito authentifie les utilisateurs et soutient à la fois l'interface utilisateur CloudFront Web et l'API Gateway.

  5. Les demandes entrantes de l'utilisateur professionnel sont transmises d'API Gateway à une file d'attente Amazon SQS, puis à la fonction AWS Lambda. La file d'attente permet le fonctionnement asynchrone de l'intégration entre API Gateway et Lambda.

  6. La fonction AWS Lambda extrait la configuration du flux de travail depuis DynamoDB, y compris la liste des agents Agent Builder spécialisés.

  7. À l'aide de la saisie utilisateur et de la configuration du flux de travail, Lambda envoie des demandes à l'Amazon Bedrock AgentCore Runtime hébergeant l'agent de supervision.

  8. L'agent superviseur crée des instances locales de tous les agents Agent Builder spécialisés dans l'environnement AgentCore d'exécution. Ces agents spécialisés sont enregistrés en tant qu'outils en utilisant le modèle Agents as Tools. Le superviseur sélectionne et délègue ensuite le travail de manière autonome à des agents spécialisés en fonction des descriptions des agents et des exigences des tâches.

  9. L'agent superviseur agrège les résultats des agents spécialisés et formule la réponse finale, la renvoyant au Lambda pour être retransmise à l'application cliente via le Websocket API Gateway.

Note

  • Le traitement du flux de travail est limité au délai d'exécution de Lambda (15 minutes).