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. La recherche vectorielle est un service Google Cloud entièrement géré qui fournit une infrastructure de diffusion optimisée pour la mise en correspondance de similarité vectorielle à très grande échelle.
Ce document s'adresse aux architectes, développeurs et 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 présentée dans ce document:
L'architecture du diagramme précédent comporte deux sous-systèmes: l'ingestion de données et le traitement.
- 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 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 représentations vectorielles continues de requêtes, effectuer une recherche de similarité vectorielle et appliquer des filtres de sécurité et des instructions système Responsible AI.
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 RAG. Voici les étapes du flux d'ingestion et de préparation des données:
- Les données sont importées à partir de sources externes dans 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 tâche Cloud Run.
- La tâche Cloud Run analyse les données brutes, les met en forme selon les besoins et les divise en blocs.
- Le job Cloud Run utilise l' API Vertex AI d'embeddings pour créer des embeddings des segments à l'aide d'un modèle d'embedding que vous spécifiez. Vertex AI accepte les modèles d'embedding textuel et multimodal.
- La tâche Cloud Run crée 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 les nouvelles données et l'index est mis à jour à l'aide de mises à jour en streaming.
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 frontale (par exemple, un chatbot) pour l'application d'IA générative.
- Le service d'interface transfère 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:
- Convertit la requête en représentations vectorielles continues à l'aide du même modèle et des mêmes paramètres que le sous-système d'ingestion de données pour générer des représentations vectorielles continues des données ingérées.
- Il récupère les données d'ancrage pertinentes en effectuant une recherche de similarité vectorielle pour les représentations vectorielles continues de la requête dans l'index de recherche vectorielle.
- Il construit une requête étendue en combinant la requête d'origine avec les données d'ancrage.
- Envoie la requête avancé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é d'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 ML. La sortie de l'évaluation comprend les réponses du modèle aux invites d'exemple, les scores des métriques spécifiées par les ingénieurs 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.
- 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 avec le RAG dans Google Cloud.
Alternatives à l'infrastructure d'IA
Si vous souhaitez profiter des fonctionnalités de stockage vectoriel d'une base de données Google Cloud entièrement gérée, comme AlloyDB pour PostgreSQL ou Cloud SQL pour votre application RAG, consultez la section 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 la page Infrastructure pour une application d'IA générative compatible avec 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 héberge les services d'application d'IA générative et la tâche de traitement des données. Cloud Run est une plate-forme d'applications entièrement gérée, axée sur les développeurs. Si vous avez besoin d'une plus grande flexibilité de configuration et d'un contrôle plus poussé 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 plus grand 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 que vous devez prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie qui répond à 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, vous devrez peut-être prendre en compte d'autres facteurs de conception et compromis.
Sécurité, conformité et confidentialité
Cette section décrit les considérations et les recommandations de conception pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité et de conformité de vos charges de travail.
| Produit | Recommandations et considérations concernant la conception |
|---|---|
| Vertex AI |
Contrôles de sécurité: Vertex AI est compatible avec les contrôles de sécurité de 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 les pages Contrôles de sécurité pour Vertex AI et Contrôles de sécurité pour l'IA générative. Accès au modèle: vous pouvez configurer des règles d'organisation pour limiter le type et les versions de 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 la section 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 de journal. 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 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 la gestion des certificats SSL. Pour une protection supplémentaire, vous pouvez utiliser les stratégies de sécurité Google Cloud Armor pour fournir un filtrage des requêtes, une protection contre les attaques DDoS et limitation du débit pour le service.
Sécurité d'entrée (service de backend): le service Cloud Run du backend de l'application dans cette architecture n'a pas besoin d'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'une clé de chiffrement détenue et gérée par Google . 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 conteneur: pour vous assurer que seules les images de conteneur autorisées sont déployées sur les jobs et 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 les conseils généraux de développement 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 clés de chiffrement appartenant à Google et gérées par Google. 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, comme 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 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 ces données, vous pouvez utiliser la protection des données sensibles pour les découvrir, les classer et les anonymiser. Pour en savoir plus, consultez Utiliser la protection des données sensibles 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, à la fois au repos et en transit, à l'aide de clés de chiffrement gérées et détenues par Google . Pub/Sub prend en charge l'utilisation de clés CMEK pour le chiffrement des messages au niveau de la couche 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 administratives: la journalisation des activités administratives 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 journal: Google n'accède pas aux données de Cloud Logging et ne les utilise pas. Résidence des données: pour vous aider à respecter les exigences de résidence des données, vous pouvez configurer Cloud Logging pour stocker les données de journal dans la région que vous spécifiez. 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 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 qui peuvent vous aider à optimiser davantage la sécurité de vos ressources cloud. Examinez les recommandations et appliquez-les selon les besoins de votre environnement. Pour en savoir plus, consultez Trouver des recommandations dans le centre de recommandations. Contrôle des accès: respectez 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) Perspective de sécurité de l'IA et du ML dans le Google Cloud Framework d'architecture
- (Documentation) Responsabilité partagée 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 et les recommandations de conception pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.
| Produit | Recommandations et considérations concernant la conception |
|---|---|
| Recherche vectorielle |
Échelle des requêtes: pour vous assurer que l'index Vector Search peut gérer l'augmentation 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'au nombre maximal que vous spécifiez. Pour en savoir plus, consultez Activer l'autoscaling. |
| Cloud Run |
Robustesse face 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 s'exécuter et les données ne sont pas perdues. En cas de panne régionale, Cloud Run s'arrête de s'exécuter jusqu'à ce que Google résolve la panne. Gestion des échecs: des tâches ou des jobs Cloud Run individuels peuvent échouer. Pour gérer ces échecs, vous pouvez utiliser les nouvelles tentatives d'exécution de tâches et la création de points de contrôle. Pour en savoir plus, consultez la section Bonnes pratiques en matière de nouvelles tentatives d'exécution et de points de contrôle de tâches. |
| 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 de débit: pour éviter les erreurs lors de pics temporaires de trafic de messages, vous pouvez limiter le débit des 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 Réessayer les requêtes. |
| BigQuery | Résistance aux 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 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é de BigQuery, consultez 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 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 connaître les principes et recommandations de fiabilité spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: fiabilité du framework d'architecture.
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 | Recommandations et considérations 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 à haut RPS, le traitement par lot des requêtes peut contribuer à réduire les coûts. Pour savoir comment estimer le coût de Vector Search, consultez les exemples de tarification pour Vector Search. Pour améliorer l'utilisation des nœuds de calcul sur lesquels l'index de recherche vectorielle 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 nombre minimal que vous spécifiez. Pour en savoir plus, consultez la section Activer l'autoscaling. |
| Cloud Run |
Lorsque vous créez des tâches et 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 CPU 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 et tâches 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. Cela permet de rétrograder automatiquement des objets vers une classe de stockage moins chère ou de les supprimer en fonction des conditions que vous définissez. |
| 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 que vous avez déployé votre application dans Google Cloud, utilisez le service Active Assist pour obtenir des recommandations afin 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 prixGoogle Cloud .
Pour connaître les principes et les recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: optimisation des coûts du framework d'architecture.
Optimisation des performances
Cette section décrit les considérations et les recommandations de conception pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de vos charges de travail.
| Produit | Recommandations et considérations concernant la conception |
|---|---|
| Recherche vectorielle |
Lorsque vous créez l'index, définissez la taille de la partition, le type de mesure de la 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 segment. 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êtes attendue. Pour en savoir plus, consultez la section Paramètres de déploiement ayant une incidence sur les performances.
Configurez les paramètres de requête pour l'index Vector Search en fonction de vos exigences en termes de performances, de disponibilité et de coûts des requêtes.
Par exemple, le paramètre Un indice à jour permet d'améliorer la précision des réponses générées. Vous pouvez mettre à jour votre index de recherche vectorielle à 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 la section Mettre à jour et recompiler un index actif. |
| Cloud Run |
Par défaut, chaque instance de conteneur Cloud Run est allouée un processeur et 512 Mo de mémoire. Selon les exigences de performances, vous pouvez configurer la limite de CPU 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 d'absence de 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 des conseils d'optimisation des performances, consultez les conseils généraux de développement pour Cloud Run. |
| Cloud Storage | Pour importer de gros fichiers, 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 segments 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. Toutefois, cette stratégie présente certaines limites et des implications 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 la section 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 page 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 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 connaître les principes et les recommandations d'optimisation des performances spécifiques aux charges de travail d'IA et de ML, consultez la section Perspective IA et ML: optimisation des performances du framework d'architecture.
Étape suivante
- 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 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 IA et ML dans le framework d'architecture.
- 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 principal
- Jerome Simms | Directeur de la gestion des produits
- Mark Schlagenhauf | Rédacteur technique, Mise en réseau
- Nicholas McNamara | Directeur de la stratégie produit et 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