Créer des applications RAG avec GKE et Cloud SQL

Cet article explore une architecture de référence pour le déploiement d'applications de Génération Augmentée par Récupération (RAG) sur Google Cloud, en tirant parti de Google Kubernetes Engine (GKE), de Cloud SQL et d'outils open-source populaires. Le RAG améliore la qualité des sorties de l'IA Générative en les basant sur des connaissances récupérées, ce qui le rend idéal pour les applications nécessitant des réponses précises et contextuelles. Ce guide s'adresse aux développeurs familiers avec GKE et Cloud SQL, et qui possèdent une compréhension conceptuelle de l'IA, du Machine Learning (ML) et des Grands Modèles de Langage (LLM). Nous examinerons les composants de l'architecture, le flux de données et les considérations clés pour la construction d'un système RAG robuste et efficace.

L'architecture comprend deux sous-systèmes principaux : le sous-système d'embedding et le sous-système de service. Le sous-système d'embedding est responsable de l'ingestion des données provenant de diverses sources, de leur transformation en embeddings vectoriels et du stockage de ces embeddings dans une base de données vectorielle. Le sous-système de service gère les requêtes des utilisateurs, récupère les informations pertinentes de la base de données vectorielle à l'aide de la recherche sémantique et génère des réponses à l'aide d'un LLM. Cette séparation des responsabilités permet un traitement efficace des données et une prestation de services évolutive.

Les données provenant de sources internes et externes sont téléchargées sur Cloud Storage. Ce téléchargement déclenche un événement qui notifie le service d'embedding. Le service d'embedding récupère ensuite les données, les prétraite à l'aide de Ray Data (ce qui peut impliquer le découpage et le formatage), et génère des embeddings vectoriels à l'aide de modèles open-source comme intfloat/multilingual-e5-small. Ces embeddings sont ensuite écrits dans une base de données vectorielle Cloud SQL pour PostgreSQL, optimisée pour le stockage et la récupération de vecteurs de haute dimension.

Un utilisateur soumet une requête en langage naturel via une interface de chat web. Le serveur front-end, exécuté sur GKE, utilise LangChain pour convertir la requête en un embedding. Cet embedding est utilisé pour effectuer une recherche sémantique dans la base de données vectorielle, récupérant ainsi les données pertinentes. La requête originale est ensuite combinée avec les données récupérées pour créer une invite contextualisée, qui est envoyée au serveur d'inférence. Le serveur d'inférence, alimenté par Hugging Face TGI, utilise un LLM open-source (par exemple, Mistral-7B-Instruct ou Gemma) pour générer une réponse. La réponse est filtrée pour des raisons de sécurité à l'aide des services Responsible AI (RAI) avant d'être renvoyée à l'utilisateur.

Cette architecture exploite plusieurs produits clés de Google Cloud et open-source. Google Kubernetes Engine (GKE) fournit la plateforme d'orchestration de conteneurs. Cloud Storage offre un stockage d'objets évolutif. Cloud SQL pour PostgreSQL, amélioré avec l'extension pgvector, sert de base de données vectorielle. Les outils open-source incluent Hugging Face Text Generation Inference (TGI) pour le service LLM, Ray pour le calcul distribué, et LangChain pour la construction d'applications basées sur les LLM.

Le RAG est applicable à divers scénarios. Pour des recommandations de produits personnalisées, un chatbot peut exploiter les données historiques des utilisateurs pour fournir des suggestions plus pertinentes. Dans l'assistance clinique, les médecins peuvent utiliser le RAG pour accéder à l'historique des patients et aux bases de connaissances externes pour améliorer les diagnostics. Dans la recherche juridique, les avocats peuvent interroger rapidement les réglementations et la jurisprudence, enrichies par des données provenant de contrats internes et de dossiers d'affaires.

Pour une solution de recherche vectorielle entièrement gérée, envisagez d'utiliser Vertex AI et Vector Search. Alternativement, vous pouvez exploiter les capacités de stockage vectoriel d'autres bases de données Google Cloud comme AlloyDB pour PostgreSQL. Ces alternatives offrent différents compromis en termes de surcharge de gestion et de performances.

La sécurité est primordiale. Utilisez les fonctionnalités de sécurité intégrées de GKE Autopilot. Implémentez Identity-Aware Proxy (IAP) pour le contrôle d'accès. Chiffrez les données au repos et en transit à l'aide de Cloud KMS. Pour Cloud SQL, enforcez les connexions sécurisées à l'aide de SSL/TLS ou du proxy d'authentification Cloud SQL. Utilisez Sensitive Data Protection pour identifier et anonymiser les données sensibles dans Cloud Storage. Exploitez VPC Service Controls pour empêcher l'exfiltration de données. Assurez la conformité avec les exigences de résidence des données en spécifiant la région appropriée pour le stockage des données.

Assurez une haute disponibilité en utilisant des clusters GKE régionaux et en configurant des instances Cloud SQL avec haute disponibilité. Utilisez les options de stockage régional ou multirégional de Cloud Storage pour la redondance des données. Envisagez d'utiliser la capacité réservée pour les ressources GPU afin d'assurer la disponibilité lors des événements d'autoscaling.

Optimisez les coûts en tirant parti de l'efficacité de GKE Autopilot. Envisagez les Committed Use Discounts pour les charges de travail prévisibles. Utilisez les Spot VMs pour les nœuds GKE afin de réduire les coûts de calcul. Pour Cloud SQL, utilisez des instances autonomes si la haute disponibilité n'est pas requise. Exploitez les informations d'analyse des coûts de Cloud SQL pour identifier les instances surprovisionnées. Choisissez la classe Cloud Storage appropriée en fonction de la fréquence d'accès aux données et des exigences de rétention.

Sélectionnez la catégorie de calcul appropriée pour les pods GKE en fonction des exigences de performance. Utilisez des types de machines GPU pour les serveurs d'inférence et les services d'embedding. Optimisez les performances de Cloud SQL en allouant suffisamment de CPU et de mémoire. Utilisez les index IVFFlat ou HNSW pour une recherche vectorielle plus rapide par voisins les plus proches approximatifs (ANN). Exploitez l'outil Query Insights de Cloud SQL pour identifier et résoudre les goulots d'étranglement de performance. Pour les téléchargements de fichiers volumineux vers Cloud Storage, envisagez d'utiliser des téléchargements composites parallèles.

Un exemple de codebase est disponible sur GitHub pour déployer cette architecture. Ce code est destiné à l'expérimentation et non à une utilisation en production. Il provisionne Cloud SQL, déploie Ray, JupyterHub et Hugging Face TGI sur GKE, et déploie une application de chatbot exemple. N'oubliez pas de supprimer toutes les ressources inutilisées après l'expérimentation. Explorez davantage en examinant les meilleures pratiques GKE, en étudiant les options de grounding de l'IA générative de Google Cloud, et en étudiant les architectures utilisant Vertex AI et Vector Search ou AlloyDB. Consultez le Well-Architected Framework pour l'IA et le Machine Learning pour les principes et recommandations architecturaux.