Infrastructure RAG pour l'IA générative à l'aide de Vertex AI et d'AlloyDB pour PostgreSQL

Ce document fournit une architecture de référence que vous pouvez utiliser pour concevoir l'infrastructure permettant d'exécuter une application d'intelligence artificielle générative (IA) avec une génération augmentée de récupération (RAG). Ce document s'adresse aux développeurs et administrateurs d'applications d'IA générative et d'architectes cloud. 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.

Remarque : Pour découvrir comment utiliser des outils Open Source tels que Ray, Hugging Face et LangChain pour créer et déployer rapidement une application d'IA générative compatible avec RAG sur Google Kubernetes Engine (GKE), consultez Infrastructure RAG pour l'IA générative à l'aide de GKE et Cloud SQL.

Architecture

Le schéma suivant montre une vue d'ensemble d'une architecture pour une application d'IA générative compatible avec RAG dans Google Cloud :

L'architecture contient les composants interconnectés suivants :

Composant	Objectif	Interactions
Sous-système d'ingestion de données	Préparez et traitez les données externes utilisées pour activer la fonctionnalité RAG.	Le sous-système d'ingestion de données interagit avec les autres sous-systèmes de l'architecture via la couche de base de données.
Sous-système de mise en service	Gérez le flux de requêtes/réponses entre l'application d'IA générative et ses utilisateurs.	Le sous-système de mise en service interagit avec le sous-système d'ingestion de données via la couche de base de données.
Sous-système d'évaluation de la qualité	Évaluez la qualité des réponses générées par le sous-système de mise en service.	Le sous-système d'évaluation de la qualité interagit directement avec le sous-système de mise en service ainsi qu'avec le sous-système d'ingestion de données via la couche de base de données.
Bases de données	Stockez les données suivantes : Requêtes Embeddings vectoriels des données utilisées pour la fonction RAG Configuration des tâches sans serveur dans les sous-systèmes d'ingestion de données et d'évaluation de la qualité	Tous les sous-systèmes de l'architecture interagissent avec les bases de données.

Le diagramme suivant présente une vue détaillée de l'architecture :

Les sections suivantes fournissent des descriptions détaillées des composants et du flux de données dans chaque sous-système de l'architecture.

Sous-système d'ingestion de données

Le sous-système d'ingestion de données ingère des données issues de sources externes telles que des fichiers, des bases de données et des services de streaming. Les données importées incluent des requêtes d'évaluation de la qualité. Le sous-système d'ingestion de données fournit la fonctionnalité RAG dans l'architecture. Le schéma suivant montre les détails du sous-système d'ingestion de données dans l'architecture :

Voici les étapes du flux d'ingestion de données :

1. Les données sont importées dans un bucket Cloud Storage. La source de données peut être un utilisateur d'application effectuant une importation, une ingestion de base de données ou un streaming de données.
2. Quand des données sont importées, une notification est envoyée à un sujet Pub/Sub.
3. Pub/Sub déclenche un job Cloud Run pour traiter les données importées.
4. Cloud Run démarre la tâche en utilisant les données de configuration stockées dans une base de données AlloyDB pour PostgreSQL.
5. Le job Cloud Run utilise Document AI pour préparer les données pour un traitement ultérieur. Par exemple, la préparation peut inclure l'analyse des données, la conversion des données dans le format requis et la division des données en plusieurs fragments.

6. Le job Cloud Run utilise les représentations vectorielles continues Vertex AI pour le texte afin de créer des embeddings vectoriels des données ingérées.

   Remarque : L'application d'IA générative que vous développez doit utiliser les mêmes embeddings pour le modèle et les paramètres de texte afin de convertir les requêtes en langage naturel en embeddings.
   .

7. Cloud Run stocke les embeddings dans une base de données AlloyDB pour PostgreSQL sur laquelle l'extension pgvector est activée. Comme décrit dans la section suivante, lorsque le sous-système de mise en service traite les requêtes des utilisateurs, il utilise les embeddings dans la base de données vectorielles pour récupérer les données spécifiques au domaine pertinentes.

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. Le schéma suivant montre les détails du sous-système de mise en service dans l'architecture :

Voici les étapes du flux de requêtes-réponses dans le sous-système de mise en service :

1. Les utilisateurs envoient des requêtes à l'application d'IA générative via une interface (par exemple, un chatbot ou une application mobile).

2. L'application d'IA générative convertit la requête en langage naturel en embeddings vectoriels.

   Remarque : Pour créer les représentations vectorielles continues, l'application d'IA générative que vous développez doit utiliser les mêmes représentations vectorielles continues pour le modèle de texte et les mêmes paramètres que ceux utilisés pour convertir les données externes données vers des représentations vectorielles continues.

3. L'application termine la partie récupération de l'approche RAG :

   1. L'application effectue une recherche sémantique de l'embedding dans le magasin de vecteurs AlloyDB pour PostgreSQL géré par le sous-système d'ingestion de données. La recherche sémantique permet de trouver des embeddings basées sur l'intent d'une requête plutôt que sur son contenu textuel.
   2. L'application combine la requête d'origine avec les données brutes récupérées en fonction de l'embedding correspondant pour créer une requête contextualisée.

4. L'application envoie la requête contextualisée à une pile d'inférence LLM qui est exécutée sur Vertex AI.

5. La pile d'inférence LLM utilise un LLM d'IA générative, qui peut être un LLM de base ou un LLM personnalisé, et génère une réponse limitée au contexte fourni.

   1. L'application peut stocker des journaux de l'activité requêtes-réponses dans Cloud Logging. Vous pouvez consulter et utiliser les journaux pour la surveillance à l'aide de Cloud Monitoring. Google n'accède pas aux données de journaux et ne les utilise pas.
   2. L'application charge les réponses dans BigQuery pour effectuer des analyses hors connexion.

6. L'application examine les réponses à l'aide de filtres d'IA responsable.

7. L'application envoie les réponses sélectionnées aux utilisateurs dans l'interface.

Sous-système d'évaluation de la qualité

Le schéma suivant montre les détails du sous-système d'évaluation de la qualité de l'architecture :

Lorsque le sous-système d'évaluation de la qualité reçoit une requête, il effectue les opérations suivantes :

1. Pub/Sub déclenche un job Cloud Run.
2. Cloud Run démarre la tâche en utilisant les données de configuration stockées dans une base de données AlloyDB pour PostgreSQL.
3. Le job Cloud Run extrait les requêtes d'évaluation d'une base de données AlloyDB pour PostgreSQL. Les requêtes ont été précédemment importées dans la base de données par le sous-système d'ingestion de données.

4. Le job Cloud Run utilise les requêtes d'évaluation pour évaluer la qualité des réponses générées par le sous-système de mise en service.

   La sortie de cette évaluation prend la forme de scores d'évaluation pour des métriques comme la justesse factuelle et la pertinence.

5. Cloud Run charge les scores d'évaluation, ainsi que les requêtes et les réponses évaluées dans BigQuery pour une analyse ultérieure.

Produits utilisés

Voici un récapitulatif de tous les produits Google Cloud utilisés par l'architecture précédente :

• 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.
• Cloud Run : plate-forme de calcul gérée qui vous permet d'exécuter des conteneurs directement sur l'infrastructure évolutive de Google.
• 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.
• 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.
• AlloyDB pour PostgreSQL : service de base de données entièrement géré compatible avec PostgreSQL, conçu pour vos charges de travail les plus exigeantes, y compris le traitement hybride transactionnel et analytique.
• Document AI : plate-forme de traitement de documents qui convertit les données non structurées des documents en données structurées.
• 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.

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.

Recherche vectorielle entièrement gérée

Si vous avez besoin d'une architecture qui utilise un produit de recherche vectorielle entièrement géré, vous pouvez utiliser Vertex AI et Vector Search, qui fournit une infrastructure de diffusion optimisée pour la recherche vectorielle à très grande échelle. Pour en savoir plus, consultez Infrastructure RAG pour l'IA générative à l'aide de Vertex AI et de la recherche vectorielle.

Outils et modèles Open Source

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 RAG pour l'IA générative à l'aide de GKE et Cloud SQL.

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 fournit des conseils pour vous aider à développer dans Google Cloud une architecture d'IA générative compatible avec la fonction RAG qui répond à vos exigences spécifiques en termes de sécurité, de conformité, 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 d'IA générative et des produits et fonctionnalités Google Cloud que vous utilisez, vous devrez peut-être prendre en compte des facteurs de conception et des compromis supplémentaires.

Sécurité et conformité

Cette section décrit les facteurs à prendre en compte lorsque vous concevez et créez une application d'IA générative compatible RAG dans Google Cloud , qui répond à vos exigences de sécurité et de conformité.

Produit	Considérations de conception
Vertex AI	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 les pages Contrôles de sécurité pour Vertex AI et Contrôles de sécurité pour l'IA générative.
Cloud Run	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 la page Utiliser des clés de chiffrement gérées par le client. Pour vous assurer que seules les images de conteneurs autorisées sont déployées sur les jobs Cloud Run, vous pouvez utiliser l'autorisation binaire. 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.
AlloyDB pour PostgreSQL	Par défaut, les données stockées dans AlloyDB pour PostgreSQL sont chiffrées à l'aide de Google-owned and Google-managed encryption keys. Si vous devez utiliser des clés de chiffrement que vous contrôlez et gérez, vous pouvez utiliser des CMEK. Pour en savoir plus, consultez À propos de CMEK. Pour limiter le risque d'exfiltration de données des bases de données AlloyDB pour PostgreSQL, vous pouvez créer un périmètre de service à l'aide de VPC Service Controls. Par défaut, une instance AlloyDB pour PostgreSQL n'accepte que les connexions utilisant SSL. Pour sécuriser davantage les connexions à vos bases de données AlloyDB pour PostgreSQL, vous pouvez utiliser le connecteur du proxy d'authentification AlloyDB pour PostgreSQL. Le connecteur Auth Proxy fournit une autorisation de connexion basée sur Identity and Access Management (IAM) et utilise une connexion TLS 1.3 avec un algorithme de chiffrement AES 256 bits pour valider les identités du client et du serveur, et chiffrer le trafic de données. Pour en savoir plus, consultez la page À propos du proxy d'authentification AlloyDB pour PostgreSQL. Pour les connexions créées à l'aide de Java, Python ou Go, utilisez le connecteur de langage approprié au lieu du connecteur de proxy d'authentification. AlloyDB pour PostgreSQL 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.
BigQuery	BigQuery fournit de nombreuses fonctionnalités permettant de contrôler l'accès aux données, de protéger les données sensibles et d'assurer la précision et la cohérence des données. Pour en savoir plus, consultez la page Présentation de la gouvernance des données dans BigQuery. BigQuery vous aide à répondre aux exigences de résidence des données. Les données sont stockées dans la région que vous spécifiez.
Cloud Storage	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. Cloud Storage propose deux systèmes pour autoriser des utilisateurs à accéder à vos buckets et objets : 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. 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 la page Utiliser la protection des données sensibles avec Cloud Storage. 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	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 chiffrer les messages au niveau de l'application. Pour en savoir plus, consultez Configurer le chiffrement des messages. 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.
Document AI	Par défaut, les données au repos sont chiffrées à l'aide de clés de chiffrement gérées par Google. Si vous devez utiliser des clés de chiffrement que vous contrôlez et gérez, vous pouvez utiliser des CMEK. Pour en savoir plus, consultez Sécurité et conformité de Document AI.
Cloud Logging	Les journaux d'audit des activités d'administration sont activés par défaut pour tous les services Google Cloud utilisés dans cette architecture de référence. Ces journaux enregistrent les appels d'API ou d'autres actions qui modifient la configuration ou les métadonnées des ressources Google Cloud . Les journaux d'audit pour l'accès aux données sont activés 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. Ces journaux vous permettent de suivre les appels d'API qui lisent la configuration ou les métadonnées des ressources, ou les demandes utilisateur visant à créer, modifier ou lire des données de ressources fournies par l'utilisateur. Pour vous aider à répondre aux exigences de résidence des données, vous pouvez configurer Cloud Logging afin qu'il stocke les données de journaux dans la région de votre choix. Pour en savoir plus, consultez Régionaliser vos journaux.

Pour connaître les principes et recommandations de sécurité spécifiques aux charges de travail d'IA et de ML, consultez Enjeux spécifiques à l'IA et au ML : sécurité dans le framework Well-Architected.

Fiabilité

Cette section décrit les facteurs de conception à prendre en compte pour créer et exploiter une infrastructure fiable pour une application d'IA générative compatible RAG dansGoogle Cloud.

Produit	Considérations de conception
Cloud Run	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, les jobs Cloud Run continuent de s'exécuter et les données ne sont pas perdues. En cas de panne régionale, les jobs Cloud Run cessent de s'exécuter jusqu'à ce que Google résolve la panne. Des jobs ou des tâches Cloud Run individuelles 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.
AlloyDB pour PostgreSQL	Par défaut, les clusters AlloyDB pour PostgreSQL offrent une haute disponibilité avec basculement automatique. L'instance principale dispose de nœuds redondants situés dans deux zones différentes d'une région. Cette redondance garantit que les clusters résistent aux pannes zonales. Pour planifier la reprise après sinistre en cas de panne régionale, vous pouvez utiliser la réplication interrégionale.
BigQuery	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é.
Cloud Storage	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	Pour gérer les pics temporaires de trafic de messages, vous pouvez configurer le contrôle de flux dans les paramètres de l'éditeur. Pour gérer les échecs de publication, ajustez les variables de demande de réessai si nécessaire. Pour en savoir plus, consultez Requêtes de nouvelle tentative.
Document AI	Document AI 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, aucune donnée n'est perdue. En cas de panne régionale, Document AI est indisponible jusqu'à ce que Google résolve le problème.

Remarque : Pour en savoir plus sur les considérations spécifiques à la région, consultez Zones géographiques et régions.

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 vous aider à optimiser les coûts de configuration et de fonctionnement d'une application d'IA générative compatible RAG dans Google Cloud.

Produit	Considérations de conception
Cloud Run	Lorsque vous créez des jobs 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. Si vous pouvez prévoir les besoins en processeur et en mémoire de vos jobs 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.
AlloyDB pour PostgreSQL	Par défaut, une instance principale d'un cluster AlloyDB pour PostgreSQL est hautement disponible. L'instance comporte un nœud actif et un nœud de secours. Si le nœud actif échoue, AlloyDB pour PostgreSQL bascule automatiquement vers le nœud de secours. Si vous n'avez pas besoin de la haute disponibilité pour les bases de données, vous pouvez réduire les coûts en faisant de l'instance principale du cluster une instance de base. Une instance de base n'est pas robuste en cas de panne zonale et son temps d'arrêt est plus long lors des opérations de maintenance. Pour en savoir plus, consultez Réduire les coûts en utilisant des instances de base. Si vous pouvez prédire les besoins en processeur et en mémoire de votre instance AlloyDB pour PostgreSQL, 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 d'AlloyDB pour PostgreSQL.
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.
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 en fonction des exigences de conservation des données et de fréquence d'accès de vos charges de travail. Par exemple, vous pouvez choisir la classe de stockage standard et utiliser la gestion du cycle de vie des objets pour contrôler les coûts de stockage en revenant automatiquement à une classe de stockage plus économique ou en supprimant des objets en fonction de 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 : Réduisez le volume des journaux en excluant ou en filtrant les entrées de journal inutiles. Pour en savoir plus, consultez Filtres d'exclusion. Réduisez la période de conservation des entrées de journal. Pour en savoir plus, consultez Configurer la conservation personnalisée.

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.

Performances

Cette section décrit les facteurs à prendre en compte lorsque vous concevez et créez une application d'IA générative compatible RAG dans Google Cloud et répondant à vos exigences de performances.

Produit	Considérations de conception
Cloud Run	Par défaut, chaque instance de conteneur Cloud Run se voit allouer un processeur et 512 Mio de mémoire. En fonction des exigences de performances de vos jobs Cloud Run, vous pouvez configurer la limite de processeur et la limite de mémoire.
AlloyDB pour PostgreSQL	Pour vous aider à analyser et à améliorer les performances des requêtes des bases de données, AlloyDB pour PostgreSQL fournit un outil Query Insights. Cet outil vous permet de surveiller les performances et de suivre la source d'une requête problématique. Pour en savoir plus, consultez la page Présentation de Query Insights. Pour obtenir un aperçu de l'état et des performances de vos bases de données, ainsi que pour afficher des métriques détaillées telles que les pics de connexion et le délai avant réplication maximum, vous pouvez utiliser le tableau de bord "Insights sur le système". Pour en savoir plus, consultez la page Surveiller une instance à l'aide du tableau de bord des insights système d'AlloyDB pour PostgreSQL. Pour réduire la charge sur votre instance AlloyDB pour PostgreSQL principale et effectuer un scaling horizontal de la capacité de gestion des requêtes de lecture, vous pouvez ajouter des instances de pool de lecture au cluster. Pour en savoir plus, consultez la page Nœuds et instances AlloyDB pour PostgreSQL.
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 la page Optimiser le calcul des requêtes.
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. Les importations composites parallèles peuvent être plus rapides que les opérations d'importation standards lorsque la bande passante réseau et la vitesse des disques ne sont pas des facteurs limitants. Cependant, cette stratégie présente certaines limites et implications en termes de coûts. Pour en savoir plus, consultez la section Importations composites parallèles.

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 commencer et tester la création d'une infrastructure sur Google Cloud pour les applications d'IA générative compatibles avec la fonction RAG, vous pouvez utiliser la solution de démarrage rapide : RAG d'IA générative avec Cloud SQL. Cette solution déploie une application de chat basée sur Python sur Cloud Run et utilise une base de données Cloud SQL entièrement gérée pour la recherche vectorielle. L'exemple de code de cette solution est disponible dans GitHub.

Remarque :La solution de démarrage rapide utilise Cloud SQL comme base de données vectorielle, tandis que cette architecture de référence utilise AlloyDB pour PostgreSQL. Cloud SQL et AlloyDB pour PostgreSQL sont tous deux compatibles avec l'extension pgvector, qui vous permet d'exécuter une recherche vectorielle dans une base de données PostgreSQL.

Étapes suivantes

• Choisir des modèles et une infrastructure pour votre application d'IA générative
• Créer une application de chat basée sur un LLM et un RAG à l'aide d'AlloyDB pour PostgreSQL et de LangChain
• Infrastructure RAG pour l'IA générative à l'aide de Vertex AI et Vector Search
• Infrastructure RAG pour l'IA générative à l'aide de GKE et Cloud SQL
• Infrastructure RAG pour l'IA générative à l'aide de Google Agentspace et Vertex AI
• Infrastructure GraphRAG pour l'IA générative à l'aide de Vertex AI et Spanner Graph
• 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 :

• Andrew Brook | Directeur de l'ingénierie
• Anna Berenberg | Engineering Fellow
• Assaf Namer | Architecte principal de sécurité cloud
• Balachandar Krishnamoorthy | Ingénieur logiciel principal
• Daniel Lees | Architecte en sécurité cloud
• Derek Downey | Ingénieur relations avec les développeurs
• Eran Lewis | Responsable produit senior
• Geoffrey Anderson | Responsable produit
• Gleb Otochkin | Cloud Advocate, Bases de données
• Hamsa Buvaraghan | Responsable produit d'IA
• Irina Sigler | Responsable produit
• Jack Wotherspoon | Developer Advocate
• Jason Davenport | Developer Advocate
• Jordan Totten | Ingénieur client
• Julia Wiesinger | Responsable produit
• Kara Greenfield | ingénieur client
• Kurtis Van Gent | Ingénieur logiciel
• Per Jacobsson | Ingénieur logiciel
• Pranav Nambiar | Directeur
• Richard Hendricks | Personnel Architecture Center
• Safiuddin Khaja | Ingénieur cloud
• Sandy Ghai | Responsable groupe de produits
• Vladimir Vuskovic | Directeur de la gestion des produits
• Steren Giannini | Responsable groupe de produits
• Wietse Venema | Ingénieur relations avec les développeurs