Infrastructure pour une application d'IA générative exploitant le RAG, à l'aide de GKE

Last reviewed 2024-04-02 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'IA générative avec la génération augmentée de récupération (RAG), à l'aide de Google Kubernetes Engine (GKE), de Cloud SQL et d'outils Open Source tels que Ray, Hugging Face et LangChain. Pour vous aider à tester cette architecture de référence, un exemple d'application et une configuration Terraform sont fournis sur GitHub.

Ce document est destiné aux développeurs qui souhaitent créer et déployer rapidement des applications d'IA générative exploitant la fonction RAG, à l'aide d'outils et de modèles Open Source. Nous partons du principe que vous avez de l'expérience avec GKE et Cloud SQL, et que vous connaissez les concepts généraux d'IA, de machine learning (ML) et des grands modèles 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 un sous-système d'inférence et un sous-système de représentations vectorielles continues.

  • Le sous-système d'inférence gère le flux de requêtes/réponses entre l'application et ses utilisateurs. Il comprend un serveur frontend, un serveur d'inférence et un service d'IA responsable (RAI). Le sous-système d'inférence interagit avec le sous-système de représentations vectorielles continues via une base de données vectorielles.
  • Le sous-système de représentations vectorielles continues permet de bénéficier de la fonctionnalité RAG dans l'architecture. Ce sous-système effectue les opérations suivantes :
    • Il ingère des données à partir de sources de données situées dans Google Cloud, sur site et sur d'autres plates-formes cloud.
    • Il convertit les données ingérées en représentations vectorielles continues.
    • Il stocke les représentations vectorielles continues dans une base de données vectorielles.

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

Comme le montre le schéma précédent, le serveur frontend, le serveur d'inférence et le service de représentations vectorielles continues sont déployés dans un cluster GKE régional en mode Autopilot. Les données pour le RAG sont ingérées via un bucket Cloud Storage. L'architecture utilise une instance Cloud SQL pour PostgreSQL avec l'extension pgvector comme base de données vectorielles pour stocker les embeddings et effectuer des recherches sémantiques. Les bases de données vectorielles sont conçues pour stocker et récupérer efficacement des vecteurs de grande dimension.

Les sections suivantes décrivent les composants et le flux de données associés à chaque sous-système de l'architecture.

Sous-système de représentations vectorielles continues

Voici le flux de données du sous-système de représentations vectorielles continues :

  1. Les données provenant de sources externes et internes sont importées dans le bucket Cloud Storage, par des utilisateurs humains ou bien de façon automatisée. Les données importées peuvent se trouver dans des fichiers, des bases de données ou des données diffusées.
  2. (Non illustré dans le schéma de l'architecture.) L'activité d'importation de données déclenche un événement publié sur un service de messagerie, tel que Pub/Sub. Le service de messagerie envoie une notification au service de représentations vectorielles continues.
  3. Le service de représentations vectorielles continues effectue les opérations suivantes lorsqu'il reçoit une notification d'événement d'importation de données :
    1. Il récupère les données du bucket Cloud Storage via le pilote CSI Cloud Storage FUSE.
    2. Il lit les données importées et les prétraite à l'aide de Ray Data. Le prétraitement peut inclure la fragmentation des données et leur transformation dans un format adapté à la génération de représentations vectorielles continues.
    3. Il exécute un job Ray visant à créer des embeddings à partir des données prétraitées, à l'aide d'un modèle Open Source tel que intfloat/multilingual-e5-small, déployé dans le même cluster.
    4. Il écrit les embeddings dans la base de données vectorielles Cloud SQL pour PostgreSQL.

Comme décrit dans la section suivante, lorsque le sous-système d'inférence traite les requêtes des utilisateurs, il utilise les représentations vectorielles continues dans la base de données vectorielles pour récupérer les données pertinentes spécifiques au domaine.

Sous-système d'inférence

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

  1. Un utilisateur envoie une requête en langage naturel à un serveur frontend via une interface de chat Web. Le serveur frontend s'exécute sur GKE.
  2. Le serveur frontend exécute un processus LangChain qui effectue les opérations suivantes :
    1. Il convertit la requête en langage naturel en embeddings, en utilisant le même modèle et les mêmes paramètres que le service d'embeddings.
    2. Il récupère les données d'ancrage adaptées en effectuant une recherche sémantique de représentations vectorielles continues, dans la base de données vectorielle. La recherche sémantique permet de trouver des représentations vectorielles continues basées sur l'intent d'une requête, plutôt que sur son contenu textuel.
    3. Il construit une requête contextualisée en combinant la requête d'origine avec les données d'ancrage qui ont été récupérées.
    4. Il envoie la requête contextualisée au serveur d'inférence qui s'exécute sur GKE.
  3. Le serveur d'inférence utilise le framework de diffusion Hugging Face TGI pour diffuser un LLM Open Source, tel que Mistral-7B-Instruct ou un modèle ouvert Gemma.

  4. Le LLM génère une réponse à la requête, et le serveur d'inférence envoie la réponse au serveur frontend.

    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.

  5. Le serveur frontend appelle un service de RAI pour appliquer les filtres de sécurité requis à la réponse. Vous pouvez utiliser des outils tels que Sensitive Data Protection et l'API Cloud Natural Language pour découvrir, filtrer, classer et anonymiser les contenus sensibles dans les réponses.

  6. Le serveur frontend envoie la réponse filtrée à l'utilisateur.

Produits utilisés

Voici un récapitulatif des produits Google Cloud et Open Source utilisés par l'architecture précédente :

Produits Google Cloud

  • Google Kubernetes Engine (GKE) : service Kubernetes que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle, à l'aide de l'infrastructure de Google.
  • 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.
  • Cloud SQL : service de base de données relationnelle entièrement gérée qui vous aide à provisionner, exploiter et gérer vos bases de données MySQL, PostgreSQL et SQL Server sur Google Cloud.

Produits Open Source

  • Hugging Face Text Generation Inference (TGI) : kit de déploiement et de diffusion de LLM.
  • Ray : framework de calcul unifié Open Source qui facilite le scaling des charges de travail d'IA et Python.
  • LangChain : framework pour le développement et le déploiement d'applications basées sur des LLM.

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.

Considérations de conception

Cette section fournit des conseils pour vous aider à développer et à exécuter une architecture d'IA générative exploitant le RAG et hébergée sur GKE, 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 et des produits et fonctionnalités Google Cloud que vous utilisez, vous devrez peut-être prendre en compte d'autres facteurs de conception et faire des compromis.

Pour obtenir des conseils de conception sur les outils Open Source utilisés dans cette architecture de référence, tels que Hugging Face TGI, consultez la documentation de ces outils.

Sécurité, confidentialité et conformité

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

Produit Considérations de conception
GKE

En mode Autopilot, GKE préconfigure votre cluster et gère les nœuds conformément aux bonnes pratiques de sécurité, ce qui vous permet de vous concentrer sur les problématiques de sécurité spécifiques aux charges de travail. Pour en savoir plus, consultez les ressources suivantes :

Pour garantir un contrôle des accès efficace pour vos applications exécutées dans GKE, vous pouvez utiliser Identity-Aware Proxy (IAP). IAP s'intègre à la ressource GKE Ingress et garantit que seuls les utilisateurs authentifiés disposant du rôle IAM approprié peuvent accéder aux applications. Pour en savoir plus, consultez la page Activer IAP pour GKE.

Par défaut, vos données dans GKE subissent un chiffrement au repos et en transit, à l'aide de clés appartenant à Google et gérées par Google. Pour renforcer la sécurité des données sensibles, vous pouvez chiffrer les données au niveau de la couche application à l'aide d'une clé dont vous êtes propriétaire et que vous gérez avec Cloud KMS. Pour en savoir plus, consultez la page Chiffrer les secrets au niveau de la couche d'application.

Si vous utilisez un cluster GKE Standard, vous pouvez utiliser les autres fonctionnalités suivantes de chiffrement de données :

Cloud SQL

L'instance Cloud SQL de l'architecture n'a pas besoin d'être accessible depuis l'Internet public. Si un accès externe à l'instance Cloud SQL est nécessaire, vous pouvez chiffrer les connexions externes via SSL/TLS ou à l'aide du connecteur Proxy d'authentification Cloud SQL. Le connecteur de proxy d'authentification fournit l'autorisation de connexion à l'aide d'IAM. Le connecteur 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 les connexions créées à l'aide de Java, Python, Go ou Node.js, utilisez le connecteur de langage approprié au lieu du connecteur du proxy d'authentification.

Par défaut, Cloud SQL utilise des clés de chiffrement des données (DEK, Data Encryption Key) et des clés de chiffrement de clé (KEK, Key Encryption Key) appartenant à Google et gérées par Google pour chiffrer les données au repos. Si vous devez utiliser des KEK que vous contrôlez et gérez, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK).

Pour empêcher tout accès non autorisé à l'API Cloud SQL Admin, vous pouvez créer un périmètre de service à l'aide de VPC Service Controls.

Pour en savoir plus sur la configuration de Cloud SQL afin de répondre aux exigences de résidence des données, consultez la page Présentation de la résidence des données.

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 contrôler l'accès des utilisateurs à 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 de telles données, vous pouvez utiliser le service Sensitive Data Protection pour assurer la découverte, le classement et l'anonymisation des données. Pour en savoir plus, consultez la page Utiliser Sensitive Data Protection avec Cloud Storage.

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.

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.

Tous les produits de cette architecture

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. 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.

Les journaux d'audit des accès aux données sont également activés par défaut pour tous les services Google Cloud de cette architecture. Vous pouvez utiliser ces journaux pour surveiller les éléments suivants :

  • Les appels d'API qui lisent la configuration ou les métadonnées des ressources.
  • Les requêtes utilisateur visant à créer, modifier ou lire des données de ressources fournies par l'utilisateur.

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
GKE

Avec le mode de fonctionnement Autopilot utilisé dans cette architecture, GKE fournit les fonctionnalités de fiabilité intégrée suivantes :

  • Votre charge de travail utilise un cluster GKE régional. Le plan de contrôle et les nœuds de calcul sont répartis sur trois zones différentes au sein d'une même région. Vos charges de travail offrent une bonne résistance aux pannes zonales. Les clusters GKE régionaux disposent d'un contrat de niveau de service spécifiant un temps d'activité plus conséquent que les clusters zonaux.
  • Vous n'avez pas besoin de créer de nœuds ni de gérer des pools de nœuds. GKE crée automatiquement les pools de nœuds et leur applique un autoscaling en fonction des exigences de vos charges de travail.

Pour vous assurer de disposer d'une capacité de GPU suffisante en cas de besoin pour l'autoscaling du cluster GKE, vous pouvez créer et utiliser des réservations. Une réservation fournit une assurance de capacité dans une zone spécifique, pour une ressource spécifiée. Une réservation peut être spécifique à un projet ou partagée entre plusieurs projets. Des frais vous sont facturés pour les ressources réservées, même si elles ne sont pas provisionnées ou utilisées. Pour en savoir plus, consultez la section Consommer des ressources zonales réservées.

Cloud SQL

Pour vous assurer de la résistance de la base de données vectorielles face aux défaillances de base de données et aux pannes zonales, utilisez une instance Cloud SQL configurée pour la haute disponibilité. En cas de défaillance de la base de données principale ou de panne zonale, Cloud SQL bascule automatiquement vers la base de données de secours dans une autre zone. Vous n'avez pas besoin de modifier l'adresse IP du point de terminaison de la base de données.

Pour vous assurer que vos instances Cloud SQL sont couvertes par le contrat de niveau de service, suivez les consignes opérationnelles recommandées. Par exemple, assurez-vous que les ressources processeur et mémoire sont correctement dimensionnées pour la charge de travail, et activez l'augmentation automatique de l'espace de stockage. Pour en savoir plus, consultez la section Consignes opérationnelles.

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.

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
GKE

En mode Autopilot, GKE optimise l'efficacité de l'infrastructure de votre cluster en fonction des exigences de la charge de travail. Vous n'avez pas besoin de surveiller en permanence l'utilisation des ressources ni de gérer la capacité afin de maîtriser les coûts.

Si vous pouvez prédire l'utilisation du stockage éphémère et des ressources processeur et mémoire de votre cluster GKE Autopilot, 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 GKE.

Pour réduire le coût d'exécution de votre application, vous pouvez utiliser des VM Spot pour vos nœuds GKE. Les prix des VM Spot sont inférieurs à ceux des VM standards, mais elles n'offrent aucune garantie de disponibilité. Pour en savoir plus sur les avantages des nœuds qui utilisent des VM Spot, leur fonctionnement dans GKE et la planification des charges de travail sur ces nœuds, consultez la page VM Spot.

Pour obtenir plus de conseils sur l'optimisation des coûts, consultez la page Bonnes pratiques pour l'exécution d'applications Kubernetes à coût maîtrisé sur GKE.

Cloud SQL

Une configuration à haute disponibilité permet de réduire les temps d'arrêt de votre base de données Cloud SQL en cas d'indisponibilité de la zone ou de l'instance. Cependant, le coût d'une instance configurée pour la haute disponibilité est supérieur à celui d'une instance autonome. Si vous n'avez pas besoin de la haute disponibilité pour la base de données vectorielle, vous pouvez réduire les coûts en utilisant une instance autonome, qui n'offre pas la même résistance face aux pannes zonales.

Vous pouvez détecter si votre instance Cloud SQL est surprovisionnée, et optimiser ainsi la facturation, à l'aide des insights et recommandations Cloud SQL sur les coûts, qui sont fournis par Active Assist. Pour en savoir plus, consultez la page Réduire les instances Cloud SQL surprovisionnées.

Si vous pouvez prévoir les besoins en processeur et en mémoire de votre instance Cloud SQL, 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 SQL.

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. Lors du choix de la classe de stockage, tenez compte des exigences de conservation des données et de fréquence d'accès de vos charges de travail. Par exemple, pour contrôler les coûts de stockage, vous pouvez choisir la classe Standard et utiliser la gestion du cycle de vie des objets. Vous pouvez ainsi déclasser automatiquement les objets vers une classe de stockage plus économique, ou bien les supprimer en fonction des conditions que vous avez définies.

Pour estimer le coût de vos ressources Google Cloud, utilisez le simulateur de coût Google Cloud.

Optimisation des 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
GKE Choisissez les classes de calcul appropriées pour vos pods en fonction des exigences de performances des charges de travail. Pour les pods qui exécutent le serveur d'inférence et le service de représentations vectorielles continues, nous vous recommandons d'utiliser un type de machine intégrant des GPU, tel que nvidia-l4.
Cloud SQL

Pour optimiser les performances de votre instance Cloud SQL, assurez-vous que les ressources processeur et mémoire allouées à l'instance sont adaptées à la charge de travail. Pour en savoir plus, consultez la page Optimiser les instances Cloud SQL sous-provisionnées.

Pour améliorer le temps de réponse pour la recherche vectorielle des plus proches voisins approximatifs (ANN), utilisez l'index Inverted File with Flat Compression (IVFFlat) ou l'index Hierarchical Navigable Small World (HNSW).

Pour vous aider à analyser et à améliorer les performances des requêtes dans les bases de données, Cloud SQL fournit l'outil "Insights sur les requêtes". 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 Utiliser Insights sur les requêtes pour améliorer les performances des requêtes.

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 l'utilisation du disque, vous pouvez utiliser le tableau de bord "Insights sur le système". Pour en savoir plus, consultez l'article Améliorer les performances du système à l'aide des insights système.

Cloud Storage Pour importer des fichiers volumineux, vous pouvez utiliser une méthode appelée importations composites parallèles. Grâce à cette stratégie, les fichiers volumineux sont divisés en fragments. Les fragments sont importés dans Cloud Storage en parallèle, puis les données sont recomposées dans le cloud. Lorsque la bande passante réseau et la vitesse du disque ne sont pas des facteurs limitants, les importations composites parallèles peuvent se révéler plus rapides que les opérations d'importation standards. Cependant, cette stratégie présente certaines limites et a des répercussions en termes de coûts. Pour en savoir plus, consultez la section Importations composites parallèles.

Déploiement

Pour déployer une topologie basée sur cette architecture de référence, vous pouvez télécharger et utiliser l'exemple de code Open Source disponible dans un dépôt sur GitHub. L'exemple de code n'est pas destiné aux cas d'utilisation en production. Vous pouvez utiliser ce code pour tester la configuration de l'infrastructure d'IA pour une application d'IA générative exploitant le RAG.

Cet exemple de code effectue les opérations suivantes :

  1. Il provisionne une instance Cloud SQL pour PostgreSQL qui servira de base de données vectorielles.
  2. Il déploie Ray, JupyterHub et Hugging Face TGI sur un cluster GKE que vous spécifiez.
  3. Il déploie un exemple d'application de chatbot Web sur votre cluster GKE, pour vous permettre de vérifier que le RAG est bien effective.

Pour obtenir des instructions sur l'utilisation de l'exemple de code, consultez le fichier README associé à celui-ci. Si des erreurs se produisent lors de l'utilisation de l'exemple de code, alors qu'aucun problème GitHub à résoudre ne correspond à ces erreurs, vous devez alors créer des problèmes dans GitHub.

L'exemple de code déploie des ressources Google Cloud qui sont facturables. Lorsque vous avez fini d'utiliser le code, supprimez toutes les ressources dont vous n'avez plus besoin.

Étapes suivantes

Contributeurs

Auteur : Kumar Dhanagopal | Cross-product solution developer

Autres contributeurs :