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 la 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 à très grande échelle de similarités vectorielles.
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 schéma suivant présente une vue d'ensemble de l'architecture présentée 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 la RAG et interagit avec Vertex AI pour générer des représentations vectorielles continues pour les données ingérées, ainsi que pour créer et mettre à jour l'index vectoriel.
- Le sous-système de diffusion contient les services d'interface et de backend de l'application d'IA générative.
- Le service de frontend gère le flux requête-réponse avec les utilisateurs de l'application et transmet les requêtes au service de backend.
- Le service de backend utilise Vertex AI pour générer des représentations vectorielles continues de requêtes, effectuer une recherche par similarité vectorielle, et appliquer des filtres de sécurité et des instructions système pour 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 schéma 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 à partir de sources externes et les prépare pour la 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 selon vos besoins et les divise en fragments.
- La fonction utilise l' API Vertex AI Embeddings pour créer des représentations vectorielles continues des fragments à l'aide d'un modèle de représentation vectorielle continue que vous spécifiez. Vertex AI est compatible avec les modèles de représentations vectorielles continues textuelles et multimodales.
- La fonction crée ensuite un index Vector Search des représentations vectorielles continues, puis déploie l'index.
Lorsque de nouvelles données sont ingérées, les étapes précédentes sont effectuées pour les nouvelles données et l'index est mis à jour à l'aide de mises à jour en flux continu.
Lorsque le sous-système de diffusion traite les requêtes des utilisateurs, il utilise l'index Vector Search pour la recherche vectorielle. La section suivante décrit le flux d'inférence.
Sous-système de mise en service
Le sous-système d'inférence gère le flux requête-réponse entre l'application d'IA générative et ses utilisateurs. Voici les étapes du flux d'inférence:
- Un utilisateur envoie une requête en langage naturel à un service Cloud Run qui fournit une interface (telle qu'un chatbot) à l'application d'IA générative.
- Le service de frontend transfère la requête utilisateur à un service Cloud Run de backend.
- Le service de backend traite la requête en procédant comme suit:
- Convertit la requête en représentations vectorielles continues en utilisant le même modèle et les mêmes paramètres de représentations vectorielles continues 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 représentations vectorielles continues de requêtes dans l'index Vector Search.
- 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 d'interface Cloud Run.
Vous pouvez stocker et afficher les journaux de l'activité de requête-réponse dans Cloud Logging, et configurer la surveillance basée sur les journaux à l'aide de Cloud Monitoring. Vous pouvez également charger les réponses générées dans BigQuery pour les analyser hors connexion.
L'optimiseur d'invites Vertex AI vous aide à améliorer les requêtes à grande échelle, à la fois lors de la conception initiale de la requête et lors de son réglage continu. 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. Le résultat de l'évaluation comprend 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, ainsi qu'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 de 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: environnement d'exécution sans serveur permettant de créer et de connecter des services cloud.
- Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis l'intérieur et l'extérieur de Google Cloud, et sont répliquées sur les différents 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 avec la RAG dans Google Cloud.
Solutions alternatives pour l'infrastructure d'IA
Si vous souhaitez exploiter les fonctionnalités de stockage vectoriel d'une base de données Google Cloud entièrement gérée telle qu'AlloyDB pour PostgreSQL ou Cloud SQL pour votre application RAG, consultez la page Infrastructure pour une application d'IA générative compatible avec la RAG utilisant Vertex AI et AlloyDB pour PostgreSQL.
Si vous souhaitez créer et déployer rapidement des applications d'IA générative compatibles avec la RAG à l'aide d'outils et de modèles Open Source Ray, Hugging Face et LangChain, consultez la page Infrastructure pour une application d'IA générative compatible avec la RAG à l'aide de Google Kubernetes Engine (GKE).
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 de plus de flexibilité de configuration et de contrôle sur l'infrastructure de calcul, vous pouvez déployer votre application sur des clusters GKE ou des VM Compute Engine.
La décision d'utiliser Cloud Run, GKE ou Compute Engine en tant qu'hôte d'application implique un compromis entre flexibilité de configuration et travail 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'un contrôle et d'une flexibilité de configuration plus élevés. 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ébergement d'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 la section 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 ainsi que des produits et fonctionnalités Google Cloud et tiers que vous utilisez, vous devez envisager 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éponde aux exigences de sécurité et de conformité de vos charges de travail.
| Produit | Considérations et recommandations concernant la conception |
|---|---|
| Vertex AI |
Contrôles de sécurité: Vertex AI propose Google Cloud des contrôles de sécurité qui vous permettent de répondre à vos exigences en termes de résidence des données, de chiffrement des données, de sécurité des réseaux et de transparence des accès. Pour en savoir plus, consultez les pages Commandes de sécurité pour Vertex AI et Commandes de sécurité pour l'IA générative. Accès au modèle: vous pouvez configurer des règles d'administration pour limiter le type et les versions des LLM utilisables dans un projet Google Cloud . Pour en savoir plus, consultez la section 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 la page Responsabilité partagée de Vertex AI. Protection des données: utilisez l'API Cloud Data Loss Prevention pour découvrir et anonymiser 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 des journaux. Pour en savoir plus, regardez cette vidéo : Protéger les données sensibles dans les applications d'IA. |
| Cloud Run |
Sécurité d'entrée (service d'interface): 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 la gestion des certificats SSL. Pour une protection supplémentaire, vous pouvez utiliser les règles de sécurité Google Cloud Armor afin d'assurer le filtrage des requêtes, la protection contre les attaques DDoS et la limitation du débit pour le service.
Sécurité d'entrée (service de backend): le service Cloud Run pour le backend de l'application dans cette architecture n'a pas besoin d'un accès depuis 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'un 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 la page 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 conteneur 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 en savoir plus sur la sécurité des conteneurs, consultez la page Conseils généraux sur le développement sur 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 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 la page Options de chiffrement des données. Contrôle des accès: Cloud Storage accepte 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 ces données, vous pouvez utiliser Sensitive Data Protection afin d'identifier, de classer et d'anonymiser les données. Pour en savoir plus, consultez la page Utiliser la protection des données sensibles avec Cloud Storage. Contrôle réseau: pour limiter le risque d'exfiltration de données à partir de 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 clés CMEK pour le chiffrement des messages au niveau de la couche d'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 des 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 des 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 dans Cloud Logging et ne les utilise pas. Résidence des données: pour répondre aux exigences de résidence des données, vous pouvez configurer Cloud Logging pour qu'il stocke les données des journaux dans la région que vous spécifiez. Pour en savoir plus, consultez la page Régionaliser vos journaux. |
| Tous les produits de l'architecture |
Limiter le risque d'exfiltration de données: pour réduire le risque d'exfiltration de données, 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 pouvant vous aider à optimiser 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 concernant 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) Point de vue de la sécurité de l'IA et du ML dans le Google Cloud framework bien conçu
- (Documentation) Vertex AI Responsabilité partagée
- (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 et les recommandations de conception pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.
| Produit | Considérations et recommandations concernant la conception |
|---|---|
| Recherche vectorielle |
Scaling des requêtes: pour vous assurer que l'index Vector Search peut gérer l'augmentation de la charge des requêtes, vous pouvez configurer l'autoscaling pour le point de terminaison de l'index. Lorsque la charge de la requête augmente, le nombre de nœuds augmente automatiquement jusqu'au maximum spécifié. Pour en savoir plus, consultez la section Activer l'autoscaling. |
| Cloud Run |
Fiabilité aux pannes d'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 fonctionner et les données ne sont pas perdues. En cas de panne régionale, Cloud Run cesse de s'exécuter jusqu'à ce que Google la résolve. |
| 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 des 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 tentatives de publication ayant échoué, ajustez les variables de nouvelle tentative de requête si nécessaire. Pour en savoir plus, consultez la section Relancer les requêtes. |
| BigQuery | Fiabilité contre les pannes 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 garantir que vos données ne sont pas perdues en cas de panne zonale. Pour en savoir plus sur les fonctionnalités de fiabilité de BigQuery, consultez la page Comprendre la fiabilité. |
| Tous les produits de l'architecture | Optimisation post-déploiement: après avoir déployé votre application dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations afin d'optimiser la fiabilité de vos ressources cloud. Examinez les recommandations et appliquez-les selon votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. |
Pour obtenir les principes et les recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez la section Point de vue de l'IA et du ML: fiabilité dans le framework bien conçu.
Optimisation des coûts
Cette section fournit des conseils pour optimiser le coût de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.
| Produit | Considérations et recommandations concernant la conception |
|---|---|
| Recherche vectorielle |
La facturation de Vector Search dépend de la taille de votre index, du nombre de 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 nécessitant un grand nombre de requêtes par seconde, le traitement par lot des requêtes peut aider à réduire les coûts. Pour en savoir plus sur l'estimation du 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 de l'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 la section Activer l'autoscaling. |
| Cloud Run |
Lorsque vous créez des services Cloud Run, vous spécifiez la quantité de mémoire et de processeurs à allouer à l'instance de conteneur. Pour contrôler les coûts, commencez par les allocations de processeur et de mémoire par défaut (minimum). 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 exigences en termes de processeur et de 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 section Remises sur engagement d'utilisation de 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. Cela permet de rétrograder automatiquement les objets vers une classe de stockage moins coûteuse ou de 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 la section Estimer et contrôler les coûts. |
| 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 afin d'optimiser le coût de vos ressources cloud. Examinez les recommandations et appliquez-les selon 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 Google Cloud simulateur de coût.
Pour obtenir des recommandations et des principes d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez la page Point de vue de l'IA et du ML: optimisation des coûts du framework bien conçu.
Optimisation des performances
Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui réponde aux exigences de performances de vos charges de travail.
| Produit | Considérations et recommandations concernant la conception |
|---|---|
| Recherche vectorielle |
Lorsque vous créez l'index, définissez la taille de la partition, le type de mesure de distance et le nombre de représentations vectorielles continues pour chaque nœud feuille en fonction de vos exigences de performances. Par exemple, si votre application est extrêmement sensible à la variabilité de la latence, nous vous recommandons d'utiliser une taille de segment importante. Pour en savoir plus, consultez la section Paramètres de configuration affectant 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ête attendue. Pour en savoir plus, consultez la section Paramètres de déploiement affectant les performances.
Configurez les paramètres de requête de l'index Vertex Search en fonction de vos exigences en termes de performances, de disponibilité et de coût des requêtes.
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 streaming. Les mises à jour en flux continu vous permettent d'exécuter des requêtes sur des données mises à jour en temps quasi réel. Pour en savoir plus, consultez la section Mettre à jour et recompiler un index actif. |
| Cloud Run |
Par défaut, chaque instance de conteneur Cloud Run se voit attribuer 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ées sont facturés à un prix inférieur. Pour plus de conseils sur l'optimisation des performances, consultez la page Conseils généraux sur le développement de Cloud Run. |
| Cloud Storage | Pour importer des fichiers volumineux, vous pouvez utiliser une méthode appelée "importations composites parallèles". Avec cette stratégie, le fichier volumineux est divisé en plusieurs fragments. Les fragments sont importés en parallèle dans Cloud Storage, 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 être plus rapides que les opérations d'importation classiques. Cependant, cette stratégie présente des limites et des conséquences en termes de coûts. Pour en savoir plus, consultez la section Importations composites parallèles. |
| BigQuery |
BigQuery fournit un graphique d'exécution des requêtes qui vous permet d'analyser les performances des requêtes et d'obtenir des insights sur les performances pour des problèmes tels que les conflits d'emplacements et les quotas de brassage insuffisants. 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 la section 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 afin d'optimiser les performances de vos ressources cloud. Examinez les recommandations et appliquez-les selon votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. |
Pour obtenir des recommandations et des principes d'optimisation des performances spécifiques aux charges de travail d'IA et de ML, consultez la section Perspectives d'IA et de ML: optimisation des performances du framework bien conçu.
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.
Étape suivante
- Choisissez 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 la RAG, utilisant Vertex AI et AlloyDB pour PostgreSQL
- Infrastructure pour une application d'IA générative exploitant le RAG, à l'aide de GKE
- Pour obtenir un aperçu des principes et des recommandations d'architecture spécifiques aux charges de travail d'IA et de ML dans Google Cloud, consultez la perspective sur l'IA et le 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 produit et des opérations
- Eran Lewis | Chef de produit senior
- Jérôme Simms | Directeur de la gestion des produits
- Katie McLaughlin | Ingénieure senior en charge 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 | Directeur de la stratégie de produits et de commercialisation
- Preston Holmes | Responsable des produits sortants – Accélération des applications
- Rob Edwards | Technology Practice Lead, DevOps
- Victor Moreno | Responsable produit, Mise en réseau cloud
- Wietse Venema | Ingénieur des relations avec les développeurs