stack retrieval augmented generation
v2.1.0
L'architecture déployable suivante automatise le déploiement d'un exemple de modèle gen AI sur IBM Cloud, y compris toute l'infrastructure IBM Cloud et WatsonX sous-jacente. Cette architecture implémente les meilleures pratiques pour le déploiement de Watsonx gen AI Pattern sur IBM Cloud, comme décrit dans l'architecture de référence.
Cette architecture déployable fournit une base complète pour la confiance, l'observabilité, la sécurité et la conformité réglementaire. L'architecture configure un compte IBM Cloud pour s'aligner sur les paramètres de conformité. Il déploie également des services de gestion des clés et des secrets ainsi que l'infrastructure pour prendre en charge les pipelines d'intégration continue (CI), de livraison continue (CD) et de conformité continue (CC) pour une gestion sécurisée du cycle de vie des applications. Il déploie également la suite de services WatsonX et IBM Cloud Elasticsearch pour faciliter un modèle RAG. Ces pipelines facilitent le déploiement de l'application, vérifient les vulnérabilités et l'auditabilité, et contribuent à garantir un déploiement sécurisé et fiable des applications d'IA générative sur IBM Cloud.
Deux variantes sont disponibles pour cette architecture déployable :
Variante de base :
Variante standard :
Cette architecture déployable est conçue pour présenter un déploiement entièrement automatisé d'une application de génération augmentée de récupération via IBM Cloud Projects. Il fournit une base flexible et personnalisable pour vos propres applications Watsonx sur IBM Cloud. Cette architecture déploie l'exemple d'application suivant par défaut.
En utilisant cette architecture, vous pouvez accélérer votre déploiement et l'adapter aux besoins et aux objectifs de votre entreprise.
Cette architecture peut vous aider à atteindre les objectifs suivants :
Avant de déployer l'architecture déployable, assurez-vous d'effectuer les actions suivantes :
Important
Vous devez utiliser une clé API associée à un utilisateur. Vous ne pouvez pas utiliser de clés d'ID de service ou de profils approuvés.
Copiez la valeur de la clé API. Vous en aurez besoin dans les étapes suivantes.
Dans les environnements de test ou d'évaluation, vous pouvez accorder le rôle d'administrateur sur les services suivants
User API key creator , car il est obligatoire pour un déploiement de cluster OpenShift réussi.Pour rendre l'accès plus restrictif pour un environnement de production, reportez-vous au niveau d'autorisation minimum dans l'onglet d'autorisation de cette architecture déployable.
gpg --gen-key sans phrase secrète (si elle n'a pas expirée, vous pouvez utiliser une clé générée précédemment).gpg --export-secret-key <email address> | base64 . Pour plus d'informations sur le stockage de la clé, consultez Génération d'une clé GPG.Ajoutez un nom et une description.
Sélectionnez une région et un groupe de ressources pour le projet. Par exemple, à des fins d'évaluation, vous pouvez sélectionner la région la plus proche de vous et le groupe de ressources par défaut.
Pour plus d’informations sur les structures de comptes d’entreprise, consultez le livre blanc sur les comptes d’administration centrale.
Entrez un nom de configuration. Par exemple, « RAG », « dev » ou « prod ». Le nom peut vous aider ultérieurement à correspondre à votre cible de déploiement.
Vous pouvez maintenant créer votre configuration en définissant des variables.
Dans le panneau Sécurité , sélectionnez la méthode d'authentification que vous souhaitez utiliser pour déployer votre architecture.
Ajoutez la clé API à partir des prérequis dans Avant de commencer.
Dans l'onglet Sécurité > Authentification de la section Configurer , sélectionnez la clé API.
Entrez les valeurs des champs obligatoires dans l'onglet Obligatoire .
Vérifiez les valeurs des champs facultatifs dans l'onglet Facultatif :
signing_key à partir des conditions préalables dans Avant de commencer.Cliquez sur Enregistrer . Une fois les valeurs d'entrée validées, le bouton devient View stack configurations .
Vous pouvez déployer une architecture déployable empilée via la console IBM Cloud de deux manières :
En utilisant le déploiement automatique : la méthode de déploiement peut être utile pour les environnements de démonstration et de non-production. Avec le déploiement automatique, toutes les configurations des membres de la pile sont validées puis approuvées et déployées.
Vous pouvez vérifier le paramètre de déploiement automatique de votre projet en cliquant sur Gérer > Paramètres . En activant le déploiement automatique, vous activez le paramètre pour toutes les configurations du projet.
Individuellement en déployant chaque configuration de membre. La méthode manuelle est appropriée pour les projets qui contiennent des environnements de production. Vous pouvez examiner les modifications apportées à chaque configuration de membre avant l'exécution de l'automatisation.
Conseil
Après avoir approuvé la configuration, vous pourriez recevoir le message d'erreur « Impossible de valider votre configuration ». Pour résoudre le problème, actualisez votre navigateur.
Vous verrez peut-être des notifications « Nouvelle version disponible » dans la colonne Nécessite une attention particulière dans la configuration de votre projet. Vous pouvez ignorer ces messages car ils ne vous empêchent pas de déployer la pile.
Cliquez sur l'icône Options en regard de Afficher les configurations de pile et cliquez sur Valider .
Si le paramètre Déploiement automatique est désactivé dans votre projet, seules les configurations de membres prêtes sont validées.
Dans votre projet, cliquez sur l'onglet Configurations .
Si la première configuration membre de la pile ( Account Infrastructure Base ) n'est pas marquée comme Prête à valider , actualisez la page dans votre navigateur.
Cliquez sur Valider au statut Brouillon dans la ligne Account Infrastructure Base .
Approuvez la configuration et cliquez sur Déployer une fois la validation terminée.
Après avoir déployé la configuration de membre initiale, vous pouvez valider et déployer la configuration de membre restante en même temps. Répétez ces étapes de déploiement pour chaque configuration de membre dans l'architecture.
L’architecture déployable Retrieval Augmented Generation Pattern est désormais déployée dans le compte cible.
Une fois l’architecture déployée, l’exemple d’application démarre dans le service DevOps nouvellement provisionné.
Pour surveiller la création et le déploiement de l'application, procédez comme suit :
resource_group_name de l'architecture déployable.Workload - Sample RAG App Configuration .Outputs , l'URL de l'application déployée est répertoriée sous la sortie sample_app_public_url . Pour minimiser les coûts, l'automatisation déploie un plan tarifaire d'essai de Secrets Manager. Vous ne pouvez créer qu'une seule instance d'évaluation de Secrets Manager. Vous pouvez déployer une instance du plan Standard de Secrets Manager à partir des paramètres facultatifs de la pile.
Pour résoudre ce problème, supprimez l'instance d'essai. Après la suppression, supprimez également le service de l’état de récupération.
Dans IBM Cloud, lorsque vous supprimez une ressource, elle ne disparaît pas immédiatement. Au lieu de cela, il entre dans un état de récupération, où il reste pendant une courte période (généralement 7 jours) avant d'être définitivement supprimé. Pendant l'état de récupération, vous pouvez récupérer la ressource, si nécessaire.
Exécutez les commandes IBM Cloud CLI suivantes pour supprimer le service de l'état de récupération.
La première commande répertorie toutes les ressources en état de récupération.
# List all the resources in reclamation state with its reclamation ID
ibmcloud resource reclamationsRecherchez l'ID de récupération du service Secrets Manager. Utilisez cet ID dans la commande suivante.
ibmcloud resource reclamation-delete < reclamation-id >Ce problème particulier peut se produire lorsque votre déploiement ALM/toolchain date de plus de 14 jours et que la configuration de l'application DA a été non déployée/redéployée. Cela est dû au fait que le service de livraison continue est requis pour créer et supprimer des propriétés de pipeline, et que le déploiement se produit lorsque le service CD n'existe pas. Nous travaillons sur une solution à long terme pour ce bug, mais en attendant, il peut être atténué en garantissant l'existence d'un service CD dans le groupe de ressources où les chaînes d'outils devraient être créées.
Le problème se produira dans l’architecture déployable Workload - Sample RAG App Configuration , dans les variantes Code Engine et OCP. L'erreur contiendra généralement ce message :
"errors": [
{
"code": 403,
"message": "Continuous Delivery service required"
}
]
De nombreuses personnalisations sont possibles avec cette architecture. Voici quelques options courantes.
Chaque configuration de membre comprend un grand nombre de paramètres d'entrée. Vous pouvez modifier la configuration pour modifier les valeurs par défaut.
Par exemple, en modifiant la configuration des membres, vous pouvez effectuer les opérations suivantes :
Pour modifier la configuration du membre, sélectionnez Modifier à partir de l'icône Options dans la ligne de configuration du membre.
Vous pouvez supprimer de la pile une configuration membre dont d’autres configurations ne dépendent pas.
Vous pouvez supprimer les configurations suivantes dans cette architecture :
Pour supprimer une configuration de membre, sélectionnez Supprimer de la pile à partir de l'icône Options dans la ligne de configuration de membre.
Vous pouvez ajouter ou supprimer des variables d'entrée et de sortie au niveau de la pile en suivant ces étapes :
Vous pouvez provisionner de manière sélective des ressources d'observabilité telles que des routes et des cibles Activity Tracker et des instances Cloud Monitoring en suivant ces étapes :
cloud_logs_provision ) : définissez cette option pour mettre à disposition ou ignorer la mise à disposition d'une instance IBM Cloud Logs.cloud_monitoring_provision ) : définissez cette option pour mettre à disposition ou ignorer la mise à disposition d'une instance de surveillance IBM Cloud.enable_at_event_routing_to_cos_bucket ) : définissez cette option pour activer ou désactiver le routage d'événements d'Activity Tracker vers le bucket Object Storage.enable_at_event_routing_to_cloud_logs ) : définissez cette option pour activer ou désactiver le routage d'événements d'Activity Tracker vers Cloud Logs.Après avoir modifié votre architecture déployable dans des projets, vous pouvez la partager avec d'autres via un catalogue IBM Cloud privé. Pour partager votre architecture déployable, suivez les étapes décrites dans Partage de votre architecture déployable avec votre entreprise.
Vous pouvez utiliser le code de cet exemple d’automatisation comme guide pour personnaliser l’exemple d’application afin de répondre à vos besoins. Le code est disponible sur https://github.com/terraform-ibm-modules/terraform-ibm-rag-sample-da.
Pour utiliser votre propre application, supprimez la configuration du membre Workload - Sample RAG App Configuration de la pile. Cette configuration de membre est spécifique à l’exemple d’application par défaut.
Nettoyer la configuration
Cette étape est facultative si vous envisagez de détruire toutes les ressources Watson. Les artefacts créés par l'application sont supprimés dans le cadre de l'annulation du déploiement des ressources Watson.
Suivez les étapes décrites dans le fichier cleanup.md pour supprimer la configuration de l’exemple d’application.
Supprimer les ressources créées par la chaîne d'outils CI
Les ressources suivantes, créées par la chaîne d'outils, ne sont pas détruites dans le cadre de l'annulation du déploiement de la pile dans Project.
Supprimez le projet.
Pour annuler le déploiement de l'infrastructure créée par l'architecture déployable, suivez les étapes décrites dans Suppression d'un projet dans la documentation IBM Cloud.
