Infrastructure pour une application d'IA générative compatible avec RAG à l'aide de Vertex AI

Last reviewed 2024-06-07 UTC

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.

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 :

Architecture de haut niveau pour une application d'IA générative compatible 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 d'inférence Gérez le flux de requêtes/réponses entre l'application d'IA générative et ses utilisateurs. Le sous-système d'inférence 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 d'inférence. Le sous-système d'évaluation de la qualité interagit directement avec le sous-système d'inférence 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 :

Architecture détaillée pour une application d'IA générative compatible RAG dans Google Cloud

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 :

Sous-système d'ingestion de données pour une application d'IA générative compatible RAG dans Google Cloud.

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. Lorsque des données sont importées, une notification est envoyée à un sujet Pub/Sub.
  3. Pub/Sub déclenche une tâche 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. La tâche Cloud Run utilise Document AI pour préparer les données en vue d'un traitement ultérieur. Par exemple, la préparation peut inclure l'analyse des données, leur conversion au format requis, puis leur division en 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.

    .

  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 d'inférence 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 d'inférence

Le sous-système d'inférence 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 d'inférence dans l'architecture :

Sous-système d'inférence d'une application d'IA générative compatible RAG dans Google Cloud.

Voici les étapes du flux de requêtes-réponses dans le sous-système d'inférence :

  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.

  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 l'invite contextualisée à une pile d'inférence LLM qui s'exécute 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é des requêtes et réponses dans Cloud Logging. Vous pouvez afficher et utiliser les journaux pour la surveillance à l'aide de Cloud Monitoring. Google n'accède pas aux données des journaux et ne les utilise pas.
    2. L'application charge les réponses dans BigQuery pour 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 filtrées aux utilisateurs via 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 :

Sous-système d'évaluation de la qualité pour une application d'IA générative compatible RAG dans Google Cloud.

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 une tâche 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 d'inférence.

    Cette évaluation génère des scores pour des métriques telles que 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 : magasin 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.

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.

Alternative de conception

Pour les composants de stockage vectoriel et de recherche sémantique de l'architecture, vous pouvez utiliser Vertex AI Vector Search. Vector Search est un service entièrement géré qui fournit une infrastructure de diffusion optimisée pour la recherche vectorielle à très grande échelle. Les données brutes (fragments de texte) peuvent être stockées dans des magasins d'objets tels que Cloud Storage ou dans des magasins de paires valeur/clé tels que Filestore. Dans les deux cas, la représentation vectorielle de chaque segment de texte brut est stockée dans Vector Search.

Lorsque les données sont ingérées, un identifiant unique est attribué à chaque fragment de texte brut. Cet ID est utilisé comme nom de fichier de l'objet dans Cloud Storage. Le même ID est utilisé comme ID de vecteur dans Vector Search.

Au moment de la diffusion, une requête de texte entrante est convertie en vecteur d'embedding. Vector Search effectue une recherche de similarités pour renvoyer les vecteurs les plus sémantiquement similaires. Les ID vectoriels sont ensuite utilisés pour rechercher les fragments de texte d'origine. Ensemble, ces segments de texte fournissent le contexte pertinent dont le LLM a besoin pour effectuer une tâche donnée.

Pour savoir comment créer, déployer et interroger un index de recherche vectorielle, consultez le guide de démarrage rapide de Vector Search.

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é de Google Cloud qui vous permettent de 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 clé appartenant à Google 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.

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 clés appartenant à Google et 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 clés CMEK. Pour en savoir plus, consultez la page À propos des clés 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 de proxy d'authentification fournit une autorisation de connexion basée sur IAM (Identity and Access Management) et utilise une connexion TLS 1.3 avec un algorithme AES 256 bits pour vérifier 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 clés 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, 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.

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 clés appartenant à Google et gérées par Google. Pub/Sub accepte l'utilisation de CMEK pour le chiffrement des messages au niveau de la couche d'application. Pour en savoir plus, consultez la page 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 clés CMEK. Pour en savoir plus, consultez la page 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 et 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. Les journaux vous permettent de suivre les appels d'API qui lisent la configuration ou les métadonnées des ressources, ou les requêtes des utilisateurs pour créer, modifier ou lire des données de ressources fournies par l'utilisateur.

Pour répondre aux exigences de résidence des données, vous pouvez configurer Cloud Logging pour stocker les données de journaux dans la région que vous spécifiez. Pour en savoir plus, consultez la page Régionaliser vos journaux.

Pour obtenir des conseils généraux sur les principes de sécurité à prendre en compte pour les applications d'IA, consultez la page Présentation du framework d'IA sécurisé de Google.

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 dans Google 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 tâches Cloud Run continuent de s'exécuter et les données ne sont pas perdues. En cas de panne régionale, les tâches Cloud Run cessent de s'exécuter jusqu'à ce que Google résolve la panne.

Les jobs ou 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 comporte des nœuds redondants situés dans deux zones différentes d'une région. Cette redondance garantit que les clusters sont robustes contre les pannes zonales.

Pour planifier la reprise après une 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 garantir 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 la page 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 publications ayant échoué, ajustez les variables de requête de nouvelle tentative si nécessaire. Pour en savoir plus, consultez la section 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é en charge entre les zones. En cas de panne zonale, les données ne sont pas perdues. Si une panne régionale se produit, Document AI est indisponible jusqu'à ce que Google résolve la panne.

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 tâches 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 processeurs 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.

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 de Cloud Run.

AlloyDB pour PostgreSQL

Par défaut, une instance principale d'un cluster AlloyDB pour PostgreSQL est hautement disponible. L'instance possède 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 contre les pannes zonales et présente des temps d'arrêt plus longs lors des opérations de maintenance. Pour en savoir plus, consultez la page Réduire les coûts à l'aide d'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 la section 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 la section Filtres d'exclusion.
  • Réduisez la période pendant laquelle les entrées de journal sont conservées. Pour en savoir plus, consultez la section Configurer la conservation personnalisée.

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 attribuer un processeur et 512 Mio de mémoire. Selon vos exigences de performances pour 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 la page 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.

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.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :