reinforce dap341 genai data protection
1.0.0
Ce référentiel héberge l'exemple de code qui prend en charge le discours RE: Inforce 2024 Talk avec l'ID de session DAP341. Le code de ce référentiel est intentionnellement simple à optimiser pour la lisibilité pendant la session et n'est pas destiné à être utilisé dans un paramètre de production.
L'objectif du code dans ce référentiel est de démontrer le noyau fonctionnel d'un chatbot de génération augmentée (RAG) de récupération, tout en mettant en évidence certaines des considérations de protection des données pertinentes pour les charges de travail génératrices d'IA en général.
Si vous souhaitez déployer un cas d'utilisation de style Chatbot avec AWS en production, considérez l'une des options suivantes:
Ce référentiel contient une série de "scripts" Python qui peuvent être exécutés pour démontrer une série d'idées. Les scripts sont numérotés car, lorsqu'ils sont exécutés séquentiellement, ils racontent une histoire sur le fonctionnement d'un chatbot de chiffon et comment les données peuvent être protégées au sein d'une charge de travail basée sur Genai. Cependant, les scripts sont tous autonomes et idempotents et n'ont pas besoin d'être exécutés séquentiellement.
Certains des scripts Python fournis ici doivent être modifiés avant leur exécution. Les scripts sont stockés ici exactement tels qu'ils sont montrés dans la présentation RE: Inforce pour la cohérence. Les instances où vous devez mettre à jour le script sont annotées avec #UPDATE_TO_RUN_YOURSELF .
Les ressources AWS requises pour exécuter l'exemple Python Scripts, par exemple un index d'Amazon Kendra, des exemples de données, etc., peuvent être fournis par l'utilisateur de ce référentiel, mais ci-dessous sont des instructions sur la façon dont ces ressources pourraient être créées.
Les principales ressources AWS qui doivent être créées et référencées avant que les scripts Python fonctionneront sont un index Amazon Kendra et une source de données Kendra qui l'accompagne qui pointe vers des données sur un seau Amazon S3. Notez qu'un indice Amazon Kendra a un coût non négligeable et qu'il faut prendre soin de comprendre ces coûts avant de déployer cette solution.
Le code fourni dans ce référentiel est destiné à être complémentaire à un déploiement du générateur de l'application AI génératif sur AWS. Si vous déploiez le générateur d'applications AI génératif sur AWS et que vous déployez un déploiement de cas d'utilisation "texte" avec l'option "RAG" activée, un index de Kendra peut être créé pour vous comme indiqué dans la section suivante:
Déployez le générateur de l'application AI générative sur la solution AWS selon le guide de déploiement.
En ce qui concerne la protection des données, envisagez de déployer la solution avec l'option VPC activée, ce qui minimise le trafic qui coule sur Internet public en tirant parti des points de terminaison VPC.
Une fois le tableau de bord de déploiement déployé, vous pourrez déployer un cas d'utilisation.
Lors du déploiement d'un cas d'utilisation, sélectionnez l'option text . Dans la section Select knowledge base , sélectionnez yes vers l'option RAG, choisissez Kendra comme base de connaissances et, si vous n'avez pas déjà d'index Kendra, sélectionnez no pour "Avez-vous un index Kendra existant?" pour en avoir un pour vous. Toutes les autres valeurs par défaut sont très bien, mais ajustez si / si nécessaire pour répondre à vos besoins.
Une fois que votre générateur de créances généatifs AI est déployé, vous aurez un index Amazon Kendra. Vous devez maintenant ajouter une source de données Kendra à cet index. Tout d'abord, créez ou réutilisez un seau Amazon S3 existant pour stocker les données. Téléchargez le contenu du répertoire data , ainsi que le src/kendra-acl.json dans ce référentiel à ce seau S3 de telle sorte que la structure résultante ressemble à ceci:
engineering/rootrunner3k-techspecs.txt
wiki/ecorobopotato.txt
kendra-acl.json
Accédez à votre index Amazon Kendra dans la console de gestion AWS et choisissez l'option Add Data Sources . Choisissez l'option Amazon S3 connector . Donnez un nom à la source de données. Créez un rôle IAM ou utilisez un existant comme vous le souhaitez. Dans Configure sync settings , entrez l'emplacement de votre compartiment S3, définissez le fichier kendra-acl.json dans le paramètre Access control list configuration file location , développez Additional configuration et ajoutez engineering et marketing comme préfixes à indexer. Toutes les autres valeurs par défaut sont suffisantes pour créer et déployer votre source de données Kendra. Une fois la source de données créée, vous devez lancer une opération sync de source de données au moins une fois et attendre que cette synchronisation se termine avant d'exécuter des scripts Python.
Avant de pouvoir appeler tous les modèles de substratum rocheux Amazon, vous devez activer l'accès au modèle. Ce référentiel utilise Claude 3 Sonnet, donc au moins ce modèle doit être activé.
Afin d'exécuter spécifiquement le fichier Python CloudWatch, vous devez activer la journalisation de l'invocation du modèle de fonderie Amazon, en particulier avec une destination de journaux Amazon CloudWatch.
Dans le cadre de ce processus, vous créerez un groupe de journaux CloudWatch, qui doit être mis à jour dans le script Python qui l'accompagne.
Pour exécuter les scripts Python liés aux garde-corps, vous devez créer un garde-corps. Pour ce faire à l'aide de la console de gestion AWS, accédez au service du substratum rocheux d'Amazon et sélectionnez la section Guar-Rudra-Frails. Choisissez Create guardrail . Donnez-lui un nom et configurez-le avec des valeurs par défaut ou les options que vous préférez. Cependant, assurez-vous que dans la section Add sensitive information filters , vous ajoutez le type d' Address PII et sélectionnez Mask comme comportement de gardien. Cela garantit que votre garde-corps reproduira le comportement destiné à être démontré dans les scripts Python de ce projet.
Les fichiers Markdown, les images et le fichier de code Python dans le répertoire src sont destinés à être vus et exécutés dans l'ordre spécifié par leur schéma de numérotation. Comme suit est une explication de chaque fichier pour aider à guider le lecteur à travers l'intention de la présentation qui accompagne ces échantillons de code.
Donne le point principal de ces extraits de code, qui est de vous montrer un code Python très simplifié qui est lisible et montre comment RAG fonctionne à un niveau de base, tout en mettant en évidence les considérations de protection des données pour les charges de travail Genai plus largement.
Image utilisée pour introduire le produit et l'organisation notionnelles dont nous utilisons les données. Les données sont intentionnellement absurdes afin que les LLM ne disposent pas accidentellement de données de formation liées à ce produit ou organisation notionnel. Cependant, comme ce référentiel qui l'accompagne est désormais open source, il est possible qu'un LLM puisse éventuellement utiliser ce référentiel comme source de données de formation, ce qui pourrait éventuellement rompre cette hypothèse!
Affiche simplement le contenu du seau Amazon S3 que nous avons configuré qui contient nos données source. Il met également en évidence le type de chiffrement pour ces données sur S3 pour souligner l'importance de crypter les données au repos.
Imprime certaines des informations de base sur notre index Amazon Kendra pour introduire le concept de Kendra et comment il est capable d'effectuer des recherches sémantiques contre nos sources de données.
Démontre un simple appel API retrieve contre notre index Kendra, qui récupère le contexte en fonction de la question que nous posons.
Appelle le fondement d'Amazon et pose une question sans rapport avec nos données de propriété théorique. Cela est destiné à démontrer comment un LLM est en mesure de répondre à de nombreuses questions sur les choses accessibles au public, car les LLM sont souvent formées contre des quantités massives de données grattées de l'Internet ouvert.
Appelle le substratum rocheux et pose une question sur nos données propriétaires. Démontre comment un LLM ne peut pas répondre aux questions sur les données propriétaires et qui ne fait pas partie de son ensemble de données de formation.
Appelle d'abord Kendra pour récupérer le contexte pertinent à partir de nos données propriétaires, puis utilise ce contexte lors de l'appel d'un LLM dans le fondement d'Amazon. Ce modèle est appelé génération augmentée de récupération, ou chiffon.
Ajoute la liste de contrôle d'accès dans l'appel à Amazon Kendra. Étant donné que notre groupe "marketing" n'est pas autorisé à accéder au document de spécifications techniques de Kendra, notre réponse n'inclut pas les détails sur le contenu que le marketing n'est pas autorisé à afficher. Cela montre comment nous pouvons atteindre l'autorisation au niveau du document lors de l'utilisation d'une approche basée sur des chiffons. Il convient de noter que si vous utilisez plutôt vos données propriétaires pour effectuer un réglage fin ou une pré-formation continue pour personnaliser un LLM, vous perdez cette capacité à faire une autorisation à grain fin au niveau du document; Vos utilisateurs ont accès à ce modèle personnalisé ou non.
Effectue une requête RAG qui comprend une adresse spécifique. Mais peut-être que nous ne voulons pas d'adresses, ou d'autres types de PII ou de contenu sensible / nocif à inclure dans notre chatbot ...
Énumére simplement nos attributs d'une garde-roche Amazon pré-traitée que nous utiliserons à l'étape suivante. Plus précisément, nous constatons que notre garde-corps révèle les types de données d'adressage.
Effectue le même appel basé sur des chiffons que 09_RAG_ADDRESS.py, mais ajoute la garde-corps du substratum rocheux dans le cadre de l'appel au fondement. Ceci à son tour révèle les données PII d'adresse spécifique de la réponse.
Énumère 3 instances récentes Cloudtrail d'invoquer le substratum rocheux. Cela montre simplement comment Cloudtrail peut B utilisé pour auditer l'utilisation du service de substratum rocheux Amazon. D'autres services AWS génèrent également des événements CloudTrail, et ces données peuvent être utilisées pour auditer et protéger vos ressources AWS.
Répertorie 3 journaux d'invocation du modèle CloudWatch récent. Cela montre comment vos données peuvent être incluses dans les journaux d'invocation du modèle CloudWatch. Par conséquent, si vous activez les journaux d'invocation du modèle, vous devez les protéger avec le même niveau de soins que vous protégez la source de données elle-même.
Après avoir exécuté les scripts Python, vous aurez été guidé à travers quelques exemples qui démontrent des considérations de protection des données pour les charges de travail généatives de l'IA. Certains des clés à emporter sont:
Les bases de la protection des données s'appliquent toujours.
L'IA générative introduit de nouvelles considérations
Voir contribuer pour plus d'informations.
Cette bibliothèque est autorisée sous la licence MIT-0. Voir le fichier de licence.
