Ce document fournit une architecture de référence que vous pouvez utiliser pour concevoir l'infrastructure d'une application d'IA générative avec génération augmentée de récupération (RAG) à l'aide de Vector Search. Vector Search est un service Google Cloud entièrement géré qui fournit une infrastructure de diffusion optimisée pour la mise en correspondance de similarités vectorielles à très grande échelle.
Ce document s'adresse aux architectes, aux développeurs et aux administrateurs d'applications d'IA générative. Dans ce document, nous partons du principe que vous possédez des connaissances de base sur les concepts d'IA, de machine learning (ML) et de grand modèle de langage (LLM). Ce document ne fournit pas de conseils sur la conception et le développement d'une application d'IA générative.
Architecture
Le diagramme suivant présente une vue d'ensemble de l'architecture décrite dans ce document :
L'architecture du diagramme précédent comporte deux sous-systèmes : l'ingestion de données et la diffusion.
- Le sous-système d'ingestion de données ingère les données importées à partir de sources externes. Le sous-système prépare les données pour le RAG et interagit avec Vertex AI pour générer des embeddings pour les données ingérées, et pour créer et mettre à jour l'index vectoriel.
- Le sous-système de mise en service contient les services frontend et backend de l'application d'IA générative.
- Le service de frontend gère le flux de requêtes/réponses avec les utilisateurs de l'application et transfère les requêtes au service de backend.
- Le service de backend utilise Vertex AI pour générer des embeddings de requêtes, effectuer une recherche de similarité vectorielle et appliquer des filtres de sécurité et des instructions système de l'IA responsable.
Le diagramme suivant présente une vue détaillée de l'architecture :
Les sections suivantes décrivent le flux de données dans chaque sous-système du diagramme d'architecture précédent.
Sous-système d'ingestion de données
Le sous-système d'ingestion de données ingère des données provenant de sources externes et les prépare pour le système RAG. Voici les étapes du flux d'ingestion et de préparation des données :
- Les données sont importées depuis des sources externes vers un bucket Cloud Storage. Les sources externes peuvent être des applications, des bases de données ou des services de streaming.
- Lorsque des données sont importées dans Cloud Storage, un message est publié dans un sujet Pub/Sub.
- Lorsque le sujet Pub/Sub reçoit un message, il déclenche une fonction Cloud Run.
- La fonction Cloud Run analyse les données brutes, les met en forme comme requis et les divise en blocs.
- La fonction utilise l' API Vertex AI Embeddings pour créer des embeddings des blocs à l'aide d'un modèle d'embedding que vous spécifiez. Vertex AI est compatible avec les modèles d'embedding textuels et multimodaux.
- La fonction crée ensuite un index Vector Search des embeddings, puis le déploie.
Lorsque de nouvelles données sont ingérées, les étapes précédentes sont effectuées pour ces nouvelles données et l'index est mis à jour à l'aide des mises à jour en continu.
Lorsque le sous-système de mise en service traite les requêtes des utilisateurs, il utilise l'index Vector Search pour la recherche de similarité vectorielle. La section suivante décrit le flux de diffusion.
Sous-système de mise en service
Le sous-système de mise en service gère le flux de requêtes-réponses entre l'application d'IA générative et ses utilisateurs. Voici les étapes du flux de diffusion :
- Un utilisateur envoie une requête en langage naturel à un service Cloud Run qui fournit une interface frontend (comme un chatbot) pour l'application d'IA générative.
- Le service d'interface transmet la requête de l'utilisateur à un service Cloud Run de backend.
- Le service de backend traite la requête en procédant comme suit :
- Il convertit la requête en représentations vectorielles continues en utilisant le même modèle et les mêmes paramètres que ceux utilisés par le sous-système d'ingestion de données pour générer les représentations vectorielles continues des données ingérées.
- Récupère les données d'ancrage pertinentes en effectuant une recherche de similarité vectorielle pour les embeddings de la requête dans l'index Vector Search.
- Il construit une requête augmentée en combinant la requête d'origine avec les données d'ancrage.
- Envoie la requête augmentée à un LLM déployé sur Vertex AI.
- Le LLM génère une réponse.
- Pour chaque requête, Vertex AI applique les filtres de sécurité de l'IA responsable que vous avez configurés, puis envoie la réponse filtrée et les scores de sécurité de l'IA au service de backend Cloud Run.
- L'application envoie la réponse à l'utilisateur via le service de frontend Cloud Run.
Vous pouvez stocker et afficher les journaux de l'activité de requêtes/réponses dans Cloud Logging, mais aussi configurer la surveillance basée sur les journaux en utilisant Cloud Monitoring. Vous pouvez également charger les réponses générées dans BigQuery pour des analyses hors connexion.
L'optimiseur de requêtes Vertex AI vous aide à améliorer les requêtes à grande échelle, à la fois lors de la conception initiale des requêtes et pour l'ajustement continu des requêtes. L'optimiseur de requêtes évalue la réponse de votre modèle à un ensemble d'exemples de requêtes fournis par les ingénieurs en ML. La sortie de l'évaluation inclut les réponses du modèle aux exemples de requêtes, les scores des métriques spécifiées par les ingénieurs en ML et un ensemble d'instructions système optimisées que vous pouvez envisager d'utiliser.
Produits utilisés
Cette architecture de référence utilise les produits Google Cloud suivants :
- Vertex AI : plate-forme de ML qui vous permet d'entraîner et de déployer des modèles de ML et des applications d'IA, et de personnaliser les LLM à utiliser dans des applications basées sur l'IA.
- Vector Search : service de mise en correspondance des similarités vectorielles qui vous permet de stocker, d'indexer et de rechercher des données sémantiquement similaires ou associées.
- Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
- Fonctions Cloud Run : plate-forme de calcul sans serveur qui vous permet d'exécuter des fonctions à usage unique directement dans Google Cloud.
- Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.
- Pub/Sub : service de messagerie asynchrone et évolutif qui dissocie les services qui produisent des messages des services qui traitent ces messages.
- Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
- Cloud Monitoring : service qui offre une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure.
- BigQuery : entrepôt de données d'entreprise qui vous aide à gérer et analyser vos données grâce à des fonctionnalités intégrées telles que l'analyse géospatiale du machine learning et l'informatique décisionnelle.
Cas d'utilisation
La génération augmentée de récupération (RAG) est une technique efficace pour améliorer la qualité des résultats générés à partir d'un LLM. Cette section fournit des exemples de cas d'utilisation pour lesquels vous pouvez utiliser des applications d'IA générative compatibles avec la fonction RAG.
Recommandations de produits personnalisées
Un site de shopping en ligne peut utiliser un chatbot basé sur un LLM pour aider les clients à trouver des produits ou à obtenir de l'aide sur leur expérience d'achat. Il est possible d'augmenter les questions d'un utilisateur en utilisant les données historiques sur le comportement d'achat de l'utilisateur et les schémas d'interaction sur le site Web. Les données peuvent inclure des avis et des commentaires d'utilisateurs stockés dans un datastore non structuré, ou des métriques liées à la recherche qui sont stockées dans un entrepôt de données d'analyse d'audience Internet. La question augmentée peut ensuite être traitée par le LLM pour générer des réponses personnalisées que l'utilisateur pourrait trouver plus attrayantes et plus convaincantes.
Systèmes d'assistance clinique
Les médecins urgentistes doivent analyser et diagnostiquer rapidement l'état de santé d'un patient, afin de décider des soins et traitements appropriés. Une application d'IA générative qui utilise un LLM médical tel que Med-PaLM peut être utilisée pour aider les médecins dans leur processus de diagnostic clinique. Les réponses générées par l'application peuvent s'appuyer sur l'historique des dossiers des patients en contextualisant les demandes des médecins avec les données de la base de données des dossiers médicaux électroniques (DME) de l'hôpital ou d'une base de connaissances externe, telle que PubMed.
Recherches juridiques efficaces
La recherche juridique basée sur l'IA générative permet aux avocats d'interroger rapidement de grands volumes de lois et de cas juridiques afin d'identifier les précédents juridiques pertinents ou de résumer des concepts juridiques complexes. Les résultats de ces recherches peuvent être améliorés en augmentant les requêtes d'un avocat par des données extraites du corpus propriétaire du cabinet d'avocats, regroupant contrats, communications juridiques antérieures et dossiers internes. Cette approche de conception garantit que les réponses générées sont adaptées au domaine juridique de spécialité de l'avocat.
Alternatives de conception
Cette section présente d'autres approches de conception que vous pouvez envisager pour votre application d'IA générative compatible RAG dans Google Cloud.
Alternatives à l'infrastructure d'IA
Si vous souhaitez profiter des fonctionnalités de magasin de vecteurs d'une base de données entièrement gérée Google Cloud comme AlloyDB pour PostgreSQL ou Cloud SQL pour votre application RAG, consultez Infrastructure pour une application d'IA générative compatible avec RAG à l'aide de Vertex AI et d'AlloyDB pour PostgreSQL.
Si vous souhaitez créer et déployer rapidement des applications d'IA générative compatibles avec RAG à l'aide des outils et modèles Open Source Ray, Hugging Face et LangChain, consultez Infrastructure pour une application d'IA générative compatible avec RAG à l'aide de GKE et Cloud SQL.
Options d'hébergement d'applications
Dans l'architecture présentée dans ce document, Cloud Run est l'hôte de l'application d'IA générative et du traitement des données. Cloud Run est une plate-forme d'applications entièrement gérée et axée sur les développeurs. Si vous avez besoin d'une plus grande flexibilité de configuration et d'un meilleur contrôle sur l'infrastructure de calcul, vous pouvez déployer votre application sur des clusters GKE ou sur des VM Compute Engine.
La décision d'utiliser Cloud Run, GKE ou Compute Engine comme hôte d'application implique un compromis entre la flexibilité de la configuration et les efforts de gestion. Avec l'option Cloud Run sans serveur, vous déployez votre application dans un environnement préconfiguré qui nécessite un effort de gestion minimal. Avec les VM Compute Engine et les conteneurs GKE, vous êtes responsable de la gestion des ressources de calcul sous-jacentes, mais vous bénéficiez d'une plus grande flexibilité et d'un meilleur contrôle de la configuration. Pour en savoir plus sur le choix d'un service d'hébergement d'applications approprié, consultez les documents suivants :
- Mon application est-elle adaptée à Cloud Run ?
- Sélectionner un environnement d'exécution de conteneur géré
- Héberger des applications sur Google Cloud
Autres options
Pour en savoir plus sur les autres options d'infrastructure, les modèles compatibles et les techniques d'ancrage que vous pouvez utiliser pour les applications d'IA générative dansGoogle Cloud, consultez Choisir des modèles et une infrastructure pour votre application d'IA générative.
Considérations de conception
Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations de conception à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et de performances.
Les conseils de cette section ne sont pas exhaustifs. En fonction des exigences spécifiques de votre application et des produits et fonctionnalités Google Cloud et tiers que vous utilisez, il peut y avoir d'autres facteurs de conception et compromis à prendre en compte.
Sécurité, conformité et confidentialité
Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité et de conformité de vos charges de travail.
| Produit | Remarques et recommandations concernant la conception |
|---|---|
| Vertex AI |
Contrôles de sécurité : Vertex AI est compatible avec les contrôles de sécurité Google Cloud que vous pouvez utiliser pour répondre à vos exigences en termes de résidence des données, de chiffrement des données, de sécurité réseau et de transparence des accès. Pour en savoir plus, consultez Contrôles de sécurité pour Vertex AI et Contrôles de sécurité pour l'IA générative. Accès aux modèles : vous pouvez configurer des règles d'administration pour limiter le type et les versions des LLM pouvant être utilisés dans un projet Google Cloud . Pour en savoir plus, consultez Contrôler l'accès aux modèles Model Garden. Responsabilité partagée : Vertex AI sécurise l'infrastructure sous-jacente et fournit des outils et des contrôles de sécurité pour vous aider à protéger vos données, votre code et vos modèles. Pour en savoir plus, consultez Responsabilité partagée de Vertex AI. Protection des données : utilisez l'API Cloud Data Loss Prevention pour découvrir et désidentifier les données sensibles, telles que les informations permettant d'identifier personnellement l'utilisateur, dans les requêtes et les réponses, ainsi que dans les données de journaux. Pour en savoir plus, regardez cette vidéo : Protéger les données sensibles dans les applications d'IA. |
| Cloud Run |
Sécurité de l'entrée (service de frontend) : pour contrôler l'accès externe à l'application, désactivez l'URL run.app par défaut du service Cloud Run de frontend et configurez un équilibreur de charge d'application externe régional. En plus d'équilibrer la charge du trafic entrant vers l'application, l'équilibreur de charge gère les certificats SSL. Pour une protection renforcée, vous pouvez utiliser les stratégies de sécurité Google Cloud Armor pour filtrer les requêtes, protéger contre les attaques DDoS et limitation du débit du service.
Sécurité de l'entrée (service de backend) : le service Cloud Run pour le backend de l'application dans cette architecture n'a pas besoin d'accéder à Internet. Pour vous assurer que seuls les clients internes peuvent accéder au service, définissez le paramètre Chiffrement des données : par défaut, Cloud Run chiffre les données à l'aide d'une Google-owned and Google-managed encryption key. Pour protéger vos conteneurs à l'aide d'une clé que vous contrôlez, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK). Pour en savoir plus, consultez Utiliser des clés de chiffrement gérées par le client. Sécurité des images de conteneurs : pour vous assurer que seules les images de conteneurs autorisées sont déployées sur les services Cloud Run, vous pouvez utiliser l'autorisation binaire. Résidence des données : Cloud Run vous aide à répondre aux exigences de résidence des données. Les instances de conteneur Cloud Run s'exécutent dans la région que vous sélectionnez. Pour obtenir plus de conseils sur la sécurité des conteneurs, consultez Conseils de développement généraux pour Cloud Run. |
| Cloud Storage |
Chiffrement des données : par défaut, les données stockées dans Cloud Storage sont chiffrées à l'aide de Google-owned and Google-managed encryption keys. Si nécessaire, vous pouvez utiliser des clés CMEK ou vos propres clés que vous gérez à l'aide d'une méthode de gestion externe, telle que les clés de chiffrement fournies par le client (CSEK). Pour en savoir plus, consultez Options de chiffrement des données. Contrôle des accès : Cloud Storage propose deux méthodes pour contrôler l'accès des utilisateurs à vos buckets et objets : Identity and Access Management (IAM) et les listes de contrôle d'accès (LCA). Dans la plupart des cas, nous vous recommandons d'utiliser IAM, qui vous permet d'accorder des autorisations au niveau du bucket et du projet. Pour en savoir plus, consultez la page Présentation du contrôle des accès. Protection des données : les données que vous chargez dans le sous-système d'ingestion de données via Cloud Storage peuvent inclure des données sensibles. Pour protéger de telles données, vous pouvez utiliser le service Sensitive Data Protection pour assurer la découverte, le classement et l'anonymisation des données. Pour en savoir plus, consultez Utiliser Sensitive Data Protection avec Cloud Storage. Contrôle du réseau : pour limiter le risque d'exfiltration de données depuis Cloud Storage, vous pouvez créer un périmètre de service à l'aide de VPC Service Controls. Résidence des données : Cloud Storage vous aide à répondre aux exigences de résidence des données. Les données sont stockées ou répliquées dans les régions que vous spécifiez. |
| Pub/Sub |
Chiffrement des données : par défaut, Pub/Sub chiffre tous les messages, au repos et en transit, à l'aide de Google-owned and Google-managed encryption keys. Pub/Sub permet d'utiliser des CMEK pour le chiffrement des messages au niveau de l'application. Pour en savoir plus, consultez Configurer le chiffrement des messages. Résidence des données : si vous avez des exigences de résidence des données, vous pouvez configurer des règles de stockage des messages pour vous assurer que les données des messages sont stockées dans des emplacements spécifiques. |
| Cloud Logging |
Audit des activités d'administration : la journalisation des activités d'administration est activée par défaut pour tous les services Google Cloud utilisés dans cette architecture de référence. Vous pouvez accéder aux journaux via Cloud Logging et les utiliser pour surveiller les appels d'API ou d'autres actions qui modifient la configuration ou les métadonnées des ressources Google Cloud . Audit de l'accès aux données : la journalisation des événements d'accès aux données est activée par défaut pour BigQuery. Pour les autres services utilisés dans cette architecture, vous pouvez activer les journaux d'audit d'accès aux données. Vous pouvez utiliser ces journaux pour surveiller les éléments suivants :
Sécurité des données de journaux : Google n'accède pas aux données de Cloud Logging et ne les utilise pas. Résidence des données : pour vous aider à répondre aux exigences de résidence des données, vous pouvez configurer Cloud Logging afin de stocker les données de journaux dans la région de votre choix. Pour en savoir plus, consultez Régionaliser vos journaux. |
| Tous les produits de l'architecture |
Limitez le risque d'exfiltration de données : pour réduire ce risque, créez un périmètre VPC Service Controls autour de l'infrastructure. VPC Service Controls est compatible avec tous les services utilisés dans cette architecture de référence. Optimisation post-déploiement : après avoir déployé votre application dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations qui peuvent vous aider à optimiser davantage la sécurité de vos ressources cloud. Examinez les recommandations et appliquez-les en fonction de votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le Centre de recommandations. Contrôle des accès : suivez le principe du moindre privilège pour chaque service cloud. |
Pour obtenir des conseils généraux sur la sécurité des déploiements d'IA et de ML dansGoogle Cloud, consultez les ressources suivantes :
- (Blog) Présentation du framework d'IA sécurisé de Google
- (Documentation) Enjeux spécifiques à l'IA et au ML : sécurité dans le Google Cloud Well-Architected Framework
- (Documentation) Responsabilité partagée de Vertex AI
- (Livre blanc) IA générative, confidentialité et Google Cloud
- (Vidéo) Protéger les données sensibles dans les applications d'IA
Fiabilité
Cette section décrit les considérations de conception et les recommandations pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.
| Produit | Remarques et recommandations concernant la conception |
|---|---|
| Vector Search |
Scaling des requêtes : pour vous assurer que l'index Vector Search peut gérer les augmentations de la charge de requêtes, vous pouvez configurer l'autoscaling pour le point de terminaison de l'index. Lorsque la charge de requêtes augmente, le nombre de nœuds augmente automatiquement jusqu'à la limite que vous spécifiez. Pour en savoir plus, consultez Activer l'autoscaling. |
| Cloud Run |
Robustesse en cas de panne de l'infrastructure : Cloud Run est un service régional. Les données sont stockées de manière synchrone dans plusieurs zones d'une même région. Le trafic est automatiquement équilibré entre les zones. En cas de panne zonale, Cloud Run continue de s'exécuter et les données ne sont pas perdues. En cas de panne régionale, Cloud Run cesse de fonctionner jusqu'à ce que Google résolve le problème. |
| Cloud Storage | Disponibilité des données : vous pouvez créer des buckets Cloud Storage dans l'un des trois types d'emplacements suivants : régional, birégional ou multirégional. Les données stockées dans des buckets régionaux sont répliquées de manière synchrone dans plusieurs zones d'une même région. Pour une disponibilité plus élevée, vous pouvez utiliser des buckets birégionaux ou multirégionaux, dans lesquels les données sont répliquées de manière asynchrone entre les régions. |
| Pub/Sub |
Contrôle du débit : pour éviter les erreurs lors des pics temporaires de trafic de messages, vous pouvez limiter le taux de requêtes de publication en configurant le contrôle de flux dans les paramètres de l'éditeur. Gestion des échecs : pour gérer les échecs de publication, ajustez les variables de nouvelle tentative de requête si nécessaire. Pour en savoir plus, consultez Requêtes de nouvelle tentative. |
| BigQuery | Robustesse en cas de panne d'infrastructure : les données que vous chargez dans BigQuery sont stockées de manière synchrone dans deux zones de la région que vous spécifiez. Cette redondance permet de s'assurer que vos données ne sont pas perdues en cas de panne zonale. Pour en savoir plus sur les fonctionnalités de fiabilité dans BigQuery, consultez Comprendre la fiabilité. |
| Tous les produits de l'architecture | Optimisation post-déploiement : une fois votre application déployée dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations permettant d'optimiser davantage la fiabilité de vos ressources cloud. Examinez les recommandations et appliquez-les en fonction de votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. |
Pour obtenir des principes et des recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : fiabilité dans le Framework Well-Architected.
Optimisation des coûts
Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.
| Produit | Remarques et recommandations concernant la conception |
|---|---|
| Vector Search |
La facturation de Vector Search dépend de la taille de votre index, des requêtes par seconde (RPS), ainsi que du nombre et du type de machine des nœuds que vous utilisez pour le point de terminaison de l'index. Pour les charges de travail à RPS élevé, le regroupement des requêtes peut aider à réduire les coûts. Pour savoir comment estimer le coût de Vector Search, consultez les exemples de tarification de Vector Search. Pour améliorer l'utilisation des nœuds de calcul sur lesquels l'index Vector Search est déployé, vous pouvez configurer l'autoscaling pour le point de terminaison d'index. Lorsque la demande est faible, le nombre de nœuds est automatiquement réduit au minimum que vous spécifiez. Pour en savoir plus, consultez Activer l'autoscaling. |
| Cloud Run |
Lorsque vous créez des services Cloud Run, vous spécifiez la quantité de mémoire et de processeur à allouer à l'instance de conteneur. Pour contrôler les coûts, commencez par les allocations de processeur et de mémoire par défaut (minimales). Pour améliorer les performances, vous pouvez augmenter l'allocation en configurant la limite de processeur et la limite de mémoire. Pour en savoir plus, consultez la documentation suivante :
Si vous pouvez prévoir les besoins en processeur et en mémoire de vos services Cloud Run, vous pouvez réaliser des économies en obtenant des remises sur engagement d'utilisation. Pour en savoir plus, consultez la page Remises sur engagement d'utilisation dans Cloud Run. |
| Cloud Storage | Pour le bucket Cloud Storage que vous utilisez pour charger des données dans le sous-système d'ingestion de données, choisissez une classe de stockage appropriée. Lorsque vous choisissez la classe de stockage, tenez compte des exigences de conservation des données et de fréquence d'accès de vos charges de travail. Par exemple, pour contrôler les coûts de stockage, vous pouvez choisir la classe Standard et utiliser la gestion du cycle de vie des objets. Vous pouvez ainsi déclasser automatiquement les objets vers une classe de stockage plus économique, ou bien les supprimer en fonction des conditions que vous avez définies. |
| Cloud Logging |
Pour contrôler le coût de stockage des journaux, vous pouvez effectuer les opérations suivantes :
|
| BigQuery | BigQuery vous permet d'estimer le coût des requêtes avant de les exécuter. Pour optimiser les coûts des requêtes, vous devez optimiser le stockage et le calcul des requêtes. Pour en savoir plus, consultez Estimer et contrôler les coûts. |
| Tous les produits de l'architecture | Une fois votre application déployée dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations permettant d'optimiser davantage le coût de vos ressources cloud. Examinez les recommandations et appliquez-les en fonction de votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. |
Pour estimer le coût de vos ressources Google Cloud , utilisez le simulateur de coûtGoogle Cloud .
Pour obtenir des principes et des recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des coûts dans le framework Well-Architected.
Optimisation des performances
Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de vos charges de travail.
| Produit | Remarques et recommandations concernant la conception |
|---|---|
| Vector Search |
Lorsque vous créez l'index, définissez la taille de la partition, le type de mesure de distance et le nombre d'embeddings pour chaque nœud feuille en fonction de vos exigences en termes de performances. Par exemple, si votre application est extrêmement sensible à la variabilité de la latence, nous vous recommandons de choisir une grande taille de segments. Pour en savoir plus, consultez Paramètres de configuration ayant un impact sur les performances. Lorsque vous configurez la capacité de calcul des nœuds sur lesquels l'index Vector Search est déployé, tenez compte de vos exigences en termes de performances. Choisissez un type de machine approprié et définissez le nombre maximal de nœuds en fonction de la charge de requêtes que vous prévoyez. Pour en savoir plus, consultez Paramètres de déploiement ayant une incidence sur les performances.
Configurez les paramètres de requête pour l'index Vertex Search en fonction de vos exigences en termes de performances, de disponibilité et de coûts.
Par exemple, le paramètre Un index à jour permet d'améliorer la précision des réponses générées. Vous pouvez mettre à jour votre index Vector Search à l'aide de mises à jour groupées ou en continu. Les mises à jour en streaming vous permettent d'effectuer des requêtes en temps quasi réel sur les données mises à jour. Pour en savoir plus, consultez Mettre à jour et recompiler un index actif. |
| Cloud Run |
Par défaut, chaque instance de conteneur Cloud Run reçoit un processeur et 512 Mio de mémoire. En fonction des exigences de performances, vous pouvez configurer la limite de processeur et la limite de mémoire. Pour en savoir plus, consultez la documentation suivante :
Pour garantir une latence optimale même après une période sans trafic, vous pouvez configurer un nombre minimal d'instances. Lorsque ces instances sont inactives, le processeur et la mémoire qui leur sont alloués sont facturés à un prix inférieur. Pour obtenir d'autres conseils sur l'optimisation des performances, consultez Conseils de développement généraux pour Cloud Run. |
| Cloud Storage | Pour importer des fichiers volumineux, vous pouvez utiliser une méthode appelée "importations composites parallèles". Grâce à cette stratégie, les fichiers volumineux sont divisés en fragments. Les fragments sont importés dans Cloud Storage en parallèle, puis les données sont recomposées dans le cloud. Lorsque la bande passante réseau et la vitesse du disque ne sont pas des facteurs limitants, les importations composites parallèles peuvent se révéler plus rapides que les opérations d'importation standards. Cependant, cette stratégie présente certaines limites et a des répercussions en termes de coûts. Pour en savoir plus, consultez la section Importations composites parallèles. |
| BigQuery |
BigQuery fournit un graphique d'exécution de requêtes que vous pouvez utiliser pour analyser les performances des requêtes et obtenir des informations sur les performances pour des problèmes tels que les conflits d'emplacements et le quota de brassage insuffisant. Pour en savoir plus, consultez Obtenir des insights sur les performances des requêtes. Une fois que vous avez résolu les problèmes identifiés via les insights sur les performances des requêtes, vous pouvez optimiser davantage les requêtes en utilisant des techniques telles que la réduction du volume de données d'entrée et de sortie. Pour en savoir plus, consultez Optimiser le calcul des requêtes. |
| Tous les produits de l'architecture | Après avoir déployé votre application dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations permettant d'optimiser davantage les performances de vos ressources cloud. Examinez les recommandations et appliquez-les en fonction de votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. |
Pour obtenir des principes et des recommandations d'optimisation des performances spécifiques aux charges de travail d'IA et de ML, consultez Perspective de l'IA et du ML : optimisation des performances dans le framework Well-Architected.
Déploiement
Pour déployer une topologie basée sur cette architecture de référence, vous pouvez télécharger et utiliser l'exemple de configuration Terraform disponible dans un dépôt sur GitHub. Suivez les instructions du fichier README du dépôt. L'exemple de code n'est pas destiné aux cas d'utilisation en production.
Étapes suivantes
- Choisir des modèles et une infrastructure pour votre application d'IA générative
- Infrastructure pour une application d'IA générative compatible avec RAG à l'aide de Vertex AI et d'AlloyDB pour PostgreSQL
- Infrastructure pour une application d'IA générative compatible avec RAG à l'aide de GKE et Cloud SQL
- Pour obtenir une présentation des principes et des recommandations d'architecture spécifiques aux charges de travail d'IA et de ML dans Google Cloud, consultez la perspective de l'IA et du ML dans le framework Well-Architected.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteur : Kumar Dhanagopal | Cross-product solution developer
Autres contributeurs :
- Assaf Namer | Architecte principal de sécurité cloud
- Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
- Divam Anand | Responsable de la stratégie et des opérations produit
- Eran Lewis | Responsable produit senior
- Jerome Simms | Directeur de la gestion des produits
- Katie McLaughlin | Ingénieure senior des relations avec les développeurs
- Mark Schlagenhauf | Rédacteur technique, Mise en réseau
- Megan O'Keefe | Cadre chez Industry Compete, membre de l'équipe Cloud Platform Evaluations
- Nicholas McNamara | Responsable principal de la stratégie produit et de commercialisation
- Preston Holmes | Responsable produit orienté client – Accélération des applications
- Rob Edwards | Responsable de la pratique technologique, DevOps
- Victor Moreno | Responsable produit, Mise en réseau cloud
- Wietse Venema | Ingénieur relations avec les développeurs