Ce document fournit une architecture de référence pour vous aider à concevoir l'infrastructure des applications d'IA générative GraphRAG dans Google Cloud. Il s'adresse aux architectes, développeurs et administrateurs qui créent et gèrent des systèmes intelligents de récupération d'informations. Dans ce document, nous partons du principe que vous possédez des connaissances de base sur les concepts d'IA, de gestion des données de graphe et de Knowledge Graph. Ce document ne fournit pas de conseils spécifiques pour concevoir et développer des applications GraphRAG.
GraphRAG est une approche basée sur les graphes de la génération augmentée par récupération (RAG). Le RAG permet d'ancrer les réponses générées par l'IA en enrichissant les prompts avec des données contextuellement pertinentes récupérées à l'aide de la Vector Search. GraphRAG combine la recherche vectorielle avec une requête de graphe de connaissances pour récupérer des données contextuelles qui reflètent mieux l'interconnexion des données provenant de diverses sources. Les prompts augmentés à l'aide de GraphRAG peuvent générer des réponses d'IA plus détaillées et pertinentes.
Architecture
Le schéma suivant montre une architecture pour une application d'IA générative compatible avec GraphRAG dans Google Cloud :
L'architecture du diagramme précédent se compose de deux sous-systèmes : l'ingestion et la diffusion des données. Les sections suivantes décrivent l'objectif des sous-systèmes et le flux de données au sein de ces sous-systèmes et entre eux.
Sous-système d'ingestion de données
Le sous-système d'ingestion de données ingère des données provenant de sources externes, puis les prépare pour GraphRAG. Le flux d'ingestion et de préparation des données comprend les étapes suivantes :
- Les données sont ingérées dans un bucket Cloud Storage. Ces données peuvent être importées par un analyste de données, ingérées à partir d'une base de données ou diffusées en streaming depuis n'importe quelle source.
- Lorsque des données sont ingérées, un message est envoyé à un sujet Pub/Sub.
- Pub/Sub déclenche une fonction Cloud Run pour traiter les données importées.
- La fonction Cloud Run crée un graphe de connaissances à partir des fichiers d'entrée à l'aide de l'API Gemini et d'outils tels que
LLMGraphTransformerde LangChain. - La fonction stocke le Knowledge Graph dans une base de données Spanner Graph.
- La fonction segmente le contenu textuel des fichiers de données en unités précises à l'aide d'outils tels que
RecursiveCharacterTextSplitterde LangChain ou Layout Parser de Document AI. - La fonction crée des embeddings vectoriels des segments de texte à l'aide des API d'embeddings de Gemini Enterprise Agent Platform.
- La fonction stocke les embeddings vectoriels et les nœuds de graphe associés dans Spanner Graph.
Les embeddings vectoriels servent de base à la récupération sémantique. Les nœuds du graphe de connaissances permettent de parcourir et d'analyser des relations et des modèles de données complexes.
Sous-système de mise en service
Le sous-système de mise en service gère le cycle de vie des requêtes-réponses entre l'application d'IA générative et ses utilisateurs. Le flux de diffusion comprend les étapes suivantes :
- Un utilisateur envoie une requête en langage naturel à un agent IA, qui est déployé sur Agent Runtime sur Gemini Enterprise Agent Platform.
- L'agent traite la requête comme suit :
- Convertit la requête en embeddings vectoriels à l'aide des API d'embeddings Agent Platform.
- Il récupère les nœuds de graphe associés à la requête en effectuant une recherche de similarité vectorielle dans la base de données d'embeddings.
- Récupère les données liées à la requête en parcourant le graphe de connaissances.
- Il augmente le prompt en combinant la requête d'origine avec les données de graphe récupérées.
- Utilise l'API de classement de recherche d'agent pour classer les résultats, qui se composent de nœuds et d'arêtes récupérés à partir de la base de données de graphes. Le classement est basé sur la pertinence sémantique par rapport à la requête.
- Résume les résultats en appelant l'API Gemini.
- L'agent envoie ensuite le résultat résumé à l'utilisateur.
Vous pouvez stocker et afficher les journaux d'activité de requêtes/réponses dans Cloud Logging, mais aussi configurer la surveillance basée sur les journaux en utilisant Cloud Monitoring.
Produits utilisés
Cette architecture de référence utilise les produits et outils Google suivants :
- Spanner Graph : base de données de graphes qui fournit les fonctionnalités d'évolutivité, de disponibilité et de cohérence de Spanner.
- Gemini Enterprise Agent Platform : plate-forme complète qui vous permet de créer, de faire évoluer, de gérer et d'optimiser des agents IA de niveau entreprise.
- Fonctions Cloud Run : plate-forme de calcul sans serveur qui vous permet d'exécuter des fonctions à usage unique directement dans Google Cloud.
- Cloud Storage : store d'objets économique et sans limite pour tout type de données. Les données sont accessibles depuis et en dehors de Google Cloud, et sont répliquées sur plusieurs emplacements à des fins de redondance.
- Pub/Sub : service de messagerie asynchrone et évolutif qui dissocie les services qui produisent des messages des services qui traitent ces messages.
- Cloud Logging : système de gestion des journaux en temps réel avec stockage, recherche, analyse et alertes.
- Cloud Monitoring : service qui offre une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure.
Cas d'utilisation
GraphRAG facilite la récupération intelligente des données pour des cas d'utilisation dans divers secteurs. Cette section décrit quelques cas d'utilisation dans les secteurs de la santé, de la finance, des services juridiques et de l'industrie.
Santé et produits pharmaceutiques : aide à la décision clinique
Dans les systèmes d'aide à la décision clinique, GraphRAG intègre de grandes quantités de données issues de la littérature médicale, des dossiers médicaux électroniques des patients, des bases de données d'interactions médicamenteuses et des résultats d'essais cliniques dans un graphe de connaissances unifié. Lorsque des cliniciens et des chercheurs interrogent les symptômes et les médicaments actuels d'un patient, GraphRAG parcourt le Knowledge Graph pour identifier les affections pertinentes et les interactions médicamenteuses potentielles. Il peut également générer des recommandations de traitement personnalisées en fonction d'autres données, comme le profil génétique du patient. Ce type de récupération d'informations fournit des réponses plus riches en contexte et plus factuelles que la correspondance des mots clés.
Services financiers : unifier les données financières
Les entreprises de services financiers utilisent les graphes de connaissances pour offrir à leurs analystes une vue unifiée et structurée des données provenant de sources disparates, telles que les rapports d'analystes, les conférences sur les résultats et les évaluations des risques. Les Knowledge Graphs identifient les entités de données clés, telles que les entreprises et les dirigeants, et cartographient les relations cruciales entre ces entités. Cette approche fournit un réseau de données riche et interconnecté, qui permet une analyse financière plus approfondie et plus efficace. Les analystes peuvent découvrir des insights auparavant cachés, tels que des dépendances complexes de la chaîne d'approvisionnement, des membres du conseil d'administration qui se chevauchent entre concurrents et l'exposition à des risques géopolitiques complexes.
Services juridiques : recherche de cas et analyse des précédents
Dans le secteur juridique, GraphRAG peut être utilisé pour générer des recommandations juridiques personnalisées basées sur des précédents, des lois, la jurisprudence, des mises à jour réglementaires et des documents internes. Lorsqu'ils préparent des affaires, les avocats peuvent poser des questions nuancées sur des arguments juridiques spécifiques, des décisions antérieures sur des affaires similaires ou les implications d'une nouvelle législation. GraphRAG utilise l'interconnexion des connaissances juridiques disponibles pour identifier les précédents pertinents et expliquer leur applicabilité. Il peut également suggérer des contre-arguments en traçant les relations entre les concepts juridiques, les lois et les interprétations judiciaires. Grâce à cette approche, les professionnels du droit peuvent obtenir des insights plus complets et plus précis qu'avec les méthodes classiques de récupération des connaissances.
Fabrication et chaîne d'approvisionnement : exploiter les connaissances institutionnelles
Les opérations de fabrication et de chaîne d'approvisionnement nécessitent un haut niveau de précision. Les connaissances nécessaires pour maintenir le niveau de précision requis sont souvent enfouies dans des milliers de documents denses et statiques de procédures opérationnelles standards (SOP). Lorsqu'une ligne de production ou une machine d'une usine tombe en panne, ou qu'un problème logistique survient, les ingénieurs et les techniciens perdent souvent un temps précieux à chercher dans des documents PDF déconnectés pour diagnostiquer et résoudre le problème. Les graphes de connaissances et l'IA conversationnelle peuvent être combinés pour transformer des connaissances institutionnelles enfouies en un partenaire de diagnostic interactif.
Alternatives de conception
L'architecture décrite dans ce document est modulaire. Vous pouvez adapter certains composants de l'architecture pour utiliser d'autres produits, outils et technologies en fonction de vos besoins.
Créer le Knowledge Graph
Vous pouvez utiliser l'outil LLMGraphTransformer de LangChain pour créer un Knowledge Graph de zéro. En spécifiant le schéma du graphe avec des paramètres LLMGraphTransformer tels que allowed_nodes, allowed_relationships, node_properties et relationship_properties, vous pouvez améliorer la qualité du Knowledge Graph obtenu. Toutefois, LLMGraphTransformer peut extraire des entités de domaines génériques. Il peut donc ne pas convenir aux domaines de niche tels que la santé ou les produits pharmaceutiques. De plus, si votre organisation dispose déjà d'un processus robuste pour créer des Knowledge Graphs, le sous-système d'ingestion de données présenté dans cette architecture de référence est facultatif.
Stocker le Knowledge Graph et les embeddings vectoriels
L'architecture de ce document utilise Spanner comme datastore pour le graphe de connaissances et les embeddings vectoriels. Si vos graphes de connaissances d'entreprise existent déjà ailleurs (par exemple, sur une plate-forme comme Neo4j), vous pouvez envisager d'utiliser une base de données vectorielle pour les embeddings. Toutefois, cette approche nécessite des efforts de gestion supplémentaires et peut s'avérer plus coûteuse. Spanner fournit un datastore consolidé et cohérent à l'échelle mondiale pour les structures de graphes et les embeddings vectoriels. Un tel datastore permet une gestion unifiée des données, ce qui contribue à optimiser les coûts, les performances, la gouvernance de la sécurité et l'efficacité opérationnelle.
Agent Runtime
Dans cette architecture de référence, l'agent est déployé sur Agent Runtime, qui fournit un environnement d'exécution géré pour les agents IA. Vous pouvez également envisager d'autres options, telles que Cloud Run et Google Kubernetes Engine (GKE). La discussion de ces options n'entre pas dans le cadre de ce document.
Ancrage à l'aide du RAG
Comme indiqué dans la section Cas d'utilisation, GraphRAG permet de récupérer intelligemment des données pour l'ancrage dans de nombreux scénarios. Toutefois, si les données sources que vous utilisez pour augmenter les requêtes ne présentent pas d'interrelations complexes, la RAG peut être un choix approprié pour votre application d'IA générative.
Les architectures de référence suivantes montrent comment créer l'infrastructure requise pour la RAG dans Google Cloud à l'aide de bases de données gérées compatibles avec les vecteurs ou de produits de recherche vectorielle spécialisés :
- Infrastructure RAG pour l'IA générative à l'aide d'Agent Platform et de Vector Search
- Infrastructure RAG pour l'IA générative à l'aide d'Agent Platform et d'AlloyDB pour PostgreSQL
- 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 Gemini Enterprise et d'Agent Platform
Considérations de conception
Cette section décrit les facteurs de conception, les bonnes pratiques et les recommandations à prendre en compte lorsque vous utilisez cette architecture de référence pour développer une topologie répondant à vos exigences spécifiques en termes de sécurité, de fiabilité, de coût et de performances.
Les conseils de cette section ne sont pas exhaustifs. En fonction des exigences de votre charge de travail et des produits et fonctionnalités Google Cloud et tiers que vous utilisez, il peut y avoir d'autres facteurs de conception et compromis à prendre en compte.
Sécurité, confidentialité et conformité
Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de sécurité et de conformité de votre charge de travail.
Points à noter concernant la sécurité d'Agent Platform
Pour vous assurer que les configurations et l'utilisation de votre plate-forme d'agents répondent à vos exigences de sécurité, tenez compte des recommandations suivantes :
Contrôles de sécurité : Agent Platform est compatible avec les contrôles de sécurité 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 la documentation suivante :
Sécurité : les modèles d'IA générative peuvent produire des réponses nuisibles, en particulier lorsqu'ils reçoivent des requêtes explicites en ce sens. Pour améliorer la sécurité et limiter les cas d'usage abusif, vous pouvez configurer des filtres de contenu afin de bloquer les réponses potentiellement nuisibles. Pour en savoir plus, consultez Filtres de sécurité et de contenu.
Chiffrement des données Spanner Graph
Par défaut, les données stockées dans Spanner Graph 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 clés de chiffrement gérées par le client (CMEK). Pour en savoir plus, consultez À propos des CMEK.
Considérations de sécurité pour Cloud Run Functions
Pour vous assurer que votre implémentation de Cloud Run Functions répond à vos exigences de sécurité, tenez compte des recommandations suivantes :
- Chiffrement des données : par défaut, Cloud Run chiffre les données à l'aide de Google-owned and Google-managed encryption keys. Pour protéger vos conteneurs à l'aide de clés que vous contrôlez, vous pouvez utiliser des CMEK. Pour en savoir plus, consultez Utiliser des clés de chiffrement gérées par le client.
- Sécurité des images de conteneurs : pour vous assurer que seules les images de conteneurs autorisées sont déployées sur Cloud Run, vous pouvez utiliser l'autorisation binaire.
- Résidence des données : Cloud Run vous aide à répondre aux exigences de résidence des données. Vos fonctions Cloud Run s'exécutent dans la région sélectionnée.
Considérations de sécurité pour Cloud Storage
Pour vous assurer que votre configuration Cloud Storage répond à vos exigences de sécurité, tenez compte des recommandations suivantes :
- Chiffrement des données : par défaut, les données stockées dans Cloud Storage sont chiffrées à l'aide deGoogle-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.
- Contrôle des accès : Cloud Storage propose deux systèmes pour autoriser des utilisateurs à accéder à vos buckets et objets : Identity and Access Management (IAM) et les listes de contrôle d'accès (LCA). Dans la plupart des cas, nous vous recommandons d'utiliser IAM, qui vous permet d'accorder des autorisations au niveau du bucket et du projet. Pour en savoir plus, consultez la page Présentation du contrôle des accès.
- Protection des données : les données que vous chargez dans le sous-système d'ingestion de données via Cloud Storage peuvent inclure des données sensibles. Vous pouvez utiliser Sensitive Data Protection pour découvrir, classer et anonymiser les données sensibles. Pour en savoir plus, consultez Utiliser Sensitive Data Protection avec Cloud Storage.
- Résidence des données : Cloud Storage vous aide à répondre aux exigences de résidence des données. Les données sont stockées ou répliquées dans la région que vous spécifiez.
Considérations de sécurité pour Pub/Sub
Pour vous assurer que votre configuration Pub/Sub répond à vos exigences de sécurité, tenez compte des recommandations suivantes :
- Chiffrement des données : par défaut, Pub/Sub chiffre tous les messages, au repos et en transit, à l'aide deGoogle-owned and Google-managed encryption keys. Pub/Sub permet d'utiliser des CMEK pour le chiffrement des messages au niveau de la couche d'application. Pour en savoir plus, consultez Configurer le chiffrement des messages.
- Résidence des données : si vous avez des exigences de résidence des données, vous pouvez configurer des règles de stockage des messages pour vous assurer que les données des messages sont stockées dans des emplacements spécifiques.
Considérations de sécurité pour Cloud Logging
Pour vous assurer que votre configuration Cloud Logging répond à vos exigences de sécurité, tenez compte des facteurs de conception et des recommandations suivants :
- Audit des activités d'administration : 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 .
- Audit des accès aux données : pour les services Google Cloud utilisés dans cette architecture, vous pouvez activer les journaux d'audit des 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 requêtes utilisateur visant à créer, modifier ou lire des données de ressources fournies par l'utilisateur.
- Résidence des données : pour répondre aux exigences de résidence des données, vous pouvez configurer Cloud Logging de sorte 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 Google Cloud Framework d'architecture de Google Cloud.
Fiabilité
Cette section décrit les considérations de conception et les recommandations pour créer et exploiter une infrastructure fiable pour votre déploiement dans Google Cloud.
Capacité d'Agent Platform et disponibilité des points de terminaison
Si le nombre de vos requêtes dépasse la capacité allouée, le code d'erreur 429 est renvoyé. Pour les charges de travail critiques qui nécessitent systématiquement un haut débit, vous pouvez réserver du débit à l'aide du débit provisionné. Si les données peuvent être partagées entre plusieurs régions ou pays, vous pouvez utiliser un point de terminaison mondial.
Disponibilité des données et reprise après sinistre dans Spanner Graph
Spanner est conçu pour offrir une haute disponibilité des données et une évolutivité mondiale. Pour garantir la disponibilité même en cas de panne d'une région, Spanner propose des configurations multirégionales, qui répliquent les données dans plusieurs zones de plusieurs régions. En plus de ces fonctionnalités de résilience intégrées, Spanner fournit les fonctionnalités suivantes pour prendre en charge des stratégies complètes de reprise après sinistre :
- Protection contre la suppression de la base de données
- Fonctionnalités de sauvegarde et de restauration robustes, y compris des copies planifiées et interrégionales
- Récupération à un moment précis (PITR) pour une protection contre la corruption logique des données, les erreurs des opérateurs ou les écritures accidentelles pendant une période maximale de sept jours
Pour en savoir plus, consultez Présentation de la reprise après sinistre.
Robustesse de Cloud Run Functions face aux pannes d'infrastructure
Cloud Run est un service régional. Les données sont stockées de manière synchrone dans plusieurs zones d'une même région. Le trafic est automatiquement équilibré entre les zones. En cas de panne zonale, Cloud Run continue de s'exécuter et les données ne sont pas perdues. Si une panne régionale se produit, le service s'arrête jusqu'à ce que Google la résolve.
Disponibilité des données 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.
Points à prendre en compte concernant la fiabilité de Pub/Sub
Pour vous assurer que votre configuration Pub/Sub répond à vos exigences de fiabilité, tenez compte des recommandations suivantes :
- Contrôle du débit : pour éviter les erreurs pendant les pics temporaires de trafic de messages, vous pouvez limiter le débit des requêtes de publication en configurant le contrôle de flux dans les paramètres de l'éditeur.
- Gestion des échecs : pour gérer les échecs de publication, ajustez les variables de nouvelle tentative de requête si nécessaire. Pour en savoir plus, consultez Réessayer d'exécuter des requêtes.
Recommandations de fiabilité pour tous les produits de l'architecture
Après avoir déployé votre charge de travail dans Google Cloud, optimisez davantage la fiabilité de vos ressources cloud en appliquant les recommandations d'Active Assist pertinentes.
Pour connaître les principes et 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 Well-Architected Framework.
Optimisation des coûts
Cette section fournit des conseils pour optimiser les coûts de configuration et d'exploitation d'une topologie Google Cloud que vous créez à l'aide de cette architecture de référence.
Considérations relatives aux coûts d'Agent Platform
Pour vous assurer que les configurations et l'utilisation de votre plate-forme d'agents répondent à vos exigences de coût, tenez compte des recommandations suivantes :
- Analyse et gestion des coûts : pour analyser et gérer les coûts d'Agent Platform, nous vous recommandons de créer une référence de requêtes par seconde (RPS) et de jetons par seconde (TPS), et de surveiller ces métriques après le déploiement. La référence permet également de planifier la capacité. Par exemple, la référence vous aide à déterminer quand le débit provisionné est nécessaire.
- Sélection du modèle : le choix du modèle approprié pour votre application d'IA générative est une décision cruciale qui a un impact direct sur les coûts et les performances. Pour identifier le modèle qui offre un équilibre optimal entre performances et coût pour votre cas d'utilisation spécifique, testez les modèles de manière itérative. Nous vous recommandons de commencer par le modèle le plus économique et de passer progressivement à des options plus puissantes.
- Prompt engineering : la longueur de vos prompts (entrée) et des réponses générées (sortie) a une incidence directe sur les performances et les coûts. Rédigez des prompts courts, directs et fournissant suffisamment de contexte. Concevez vos requêtes de manière à obtenir des réponses concises du modèle. Par exemple, incluez des expressions telles que "résume en deux phrases" ou "liste trois points clés". Pour en savoir plus, consultez les bonnes pratiques pour la conception de requêtes.
- Cache de contexte : pour réduire le coût des requêtes contenant du contenu répété avec un nombre élevé de jetons d'entrée, utilisez le cache de contexte.
- Requêtes par lot : pour les tâches de traitement à grande échelle pouvant être effectuées de manière asynchrone, telles que la génération de contenu et l'analyse hors connexion, envisagez d'utiliser l'inférence par lot. Les requêtes par lot sont facturées à un prix inférieur à celui des requêtes standards.
Considérations sur les coûts de Spanner Graph
Pour vous assurer que votre configuration Spanner Graph répond à vos exigences de coût, tenez compte des recommandations suivantes :
- Autoscaling de la capacité de calcul : pour vous aider à contrôler les coûts, ajustez de manière dynamique la capacité de calcul des bases de données Spanner Graph en fonction de l'utilisation du processeur et des besoins de stockage à l'aide de l'autoscaler géré. Une capacité minimale est souvent requise, même pour les petites charges de travail.
- Optimisation des tarifs : pour une capacité de calcul prévisible, stable ou de référence, souscrivez des remises sur engagement d'utilisation. Les remises sur engagement d'utilisation offrent des remises importantes en échange d'un engagement à dépenser un certain montant horaire pour la capacité de calcul.
- Réplication des sauvegardes : lorsque vous copiez des sauvegardes dans différentes régions à des fins de reprise après sinistre ou de conformité, tenez compte des coûts de sortie réseau. Pour réduire les coûts, ne copiez que les sauvegardes essentielles.
Considérations sur les coûts de Cloud Run Functions
Pour vous assurer que votre implémentation de Cloud Run Functions répond à vos exigences de coût, tenez compte des recommandations suivantes :
Allocation des ressources : lorsque vous créez des fonctions Cloud Run, vous pouvez spécifier la quantité de mémoire et de processeur à allouer. Pour contrôler les coûts, commencez par les allocations de processeur et de mémoire par défaut (minimales). Pour améliorer les performances, vous pouvez augmenter l'allocation en configurant la limite de processeur et la limite de mémoire. Pour en savoir plus, consultez la documentation suivante :
Optimisation des tarifs : si vous pouvez prévoir les besoins en processeur et en mémoire, vous pouvez réaliser des économies grâce aux remises sur engagement d'utilisation.
Classe de stockage et gestion du cycle de vie Cloud Storage
Pour le bucket Cloud Storage du 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 votre charge 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. Cette approche permet de déclasser automatiquement les objets vers une classe de stockage plus économique, ou bien de les supprimer automatiquement en fonction des conditions spécifiées.
Considérations liées aux coûts de Cloud Logging
Pour contrôler le coût de stockage des journaux, tenez compte des recommandations 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.
- Optimisez la durée de conservation des journaux. Pour en savoir plus, consultez Configurer une conservation personnalisée.
Recommandations d'optimisation des coûts pour tous les produits de l'architecture
Pour vous assurer que votre architecture répond à vos exigences de coût, tenez compte des recommandations générales suivantes :
- Optimisation post-déploiement : après avoir déployé votre charge de travail dansGoogle Cloud, optimisez davantage le coût des ressources déployées en appliquant les recommandations pertinentes d'Active Assist.
- Estimation des coûts : pour estimer le coût de vos ressources Google Cloud, utilisez le simulateur de coûtGoogle Cloud .
Pour connaître les principes et recommandations d'optimisation des coûts spécifiques aux charges de travail d'IA et de ML, consultez Perspective IA et ML : optimisation des coûts dans le framework d'architecture.
Optimisation des performances
Cette section décrit les considérations de conception et les recommandations pour concevoir une topologie dans Google Cloud qui répond aux exigences de performances de vos charges de travail.
Considérations sur les performances d'Agent Platform
Pour vous assurer que les configurations et l'utilisation de votre plate-forme d'agents répondent à vos exigences de performances, tenez compte des recommandations suivantes :
- Sélection du modèle : le choix du modèle approprié pour votre application d'IA générative est une décision cruciale qui a un impact direct sur les coûts et les performances. Pour identifier le modèle qui offre un équilibre optimal entre performances et coût pour votre cas d'utilisation spécifique, testez les modèles de manière itérative. Nous vous recommandons de commencer par le modèle le plus économique et de passer progressivement à des options plus puissantes.
- Prompt engineering : la longueur de vos prompts (entrée) et des réponses générées (sortie) a une incidence directe sur les performances et les coûts. Rédigez des prompts courts, directs et fournissant suffisamment de contexte. Concevez vos requêtes de manière à obtenir des réponses concises du modèle. Par exemple, incluez des expressions telles que "résume en deux phrases" ou "liste trois points clés". Pour en savoir plus, consultez les bonnes pratiques pour la conception de requêtes.
- Optimisation des prompts : l'optimiseur de prompts de la plate-forme d'agents vous permet d'améliorer et d'optimiser rapidement les performances des prompts à grande échelle, et d'éliminer le besoin de réécriture manuelle. L'optimiseur vous aide à adapter efficacement les prompts à différents modèles.
Conception de schémas et réglage des requêtes Spanner Graph
Pour obtenir des recommandations afin d'optimiser les performances de Spanner Graph, consultez les ressources documentaires suivantes :
- Bonnes pratiques pour concevoir un schéma Spanner Graph
- Bonnes pratiques pour régler les requêtes Spanner Graph
Allocation de ressources pour Cloud Run Functions
Par défaut, chaque instance de fonction Cloud Run se voit allouer un processeur et 256 Mio de mémoire. En fonction de vos exigences de performances, vous pouvez configurer des limites de processeur et de mémoire. Pour en savoir plus, consultez la documentation suivante :
- Configurer les limites de mémoire pour les services
- Configurer les limites de processeur pour les services
Pour obtenir d'autres conseils d'optimisation des performances, consultez Conseils de développement généraux pour Cloud Run.
Importations composites parallèles Cloud Storage
Pour importer des fichiers volumineux, vous pouvez utiliser des 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.
Recommandations d'optimisation des performances pour tous les produits de l'architecture
Après avoir déployé votre charge de travail dans Google Cloud, optimisez davantage les performances de vos ressources cloud en appliquant les recommandations d'Active Assist pertinentes.
Pour connaître les principes et recommandations d'optimisation des performances spécifiques aux charges de travail d'IA et de ML, consultez Perspective IA et ML : optimisation des performances dans le Well-Architected Framework.
Déploiement
Pour découvrir le fonctionnement de GraphRAG dans Google Cloud, téléchargez et exécutez le notebook Jupyter suivant depuis GitHub : GraphRAG sur Google Cloud avec Spanner Graph et Agent Runtime sur Gemini Enterprise Agent Platform.
Étapes suivantes
- Créer des applications GraphRAG à l'aide de Spanner Graph et de LangChain
- Choisir les composants de votre architecture d'IA agentive
- Infrastructure RAG pour l'IA générative à l'aide d'Agent Platform et de Vector Search
- Infrastructure RAG pour l'IA générative à l'aide d'Agent Platform et d'AlloyDB pour PostgreSQL
- 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 Gemini Enterprise et d'Agent Platform
- Pour en savoir plus sur les principes et recommandations d'architecture pour les charges de travail d'IA dans Google Cloud, consultez le Well-Architected Framework : perspective de l'IA et du ML.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteurs :
- Tristan Li | Architecte principal, IA/ML
- Kumar Dhanagopal Développeur de solutions multiproduits
Autres contributeurs :
- Ahsif Sheikh | Ingénieur client IA
- Ashish Chauhan | Ingénieur client IA
- Greg Brosman | Responsable produit
- Lukas Bruderer | Responsable produit, IA Cloud
- Nanditha Embar | Ingénieur client IA
- Piyush Mathur | Responsable produit, Spanner
- Smitha Venkat | Ingénieur client IA