Amazon SageMakerStudio fournit une solution entièrement gérée permettant aux data scientists de créer, former et déployer de manière interactive des modèles d'apprentissage automatique (ML). Dans le processus de travail sur leurs tâches de ML, les data scientists démarrent généralement leur flux de travail en découvrant des sources de données pertinentes et en s'y connectant. Ils utilisent ensuite SQL pour explorer, analyser, visualiser et intégrer des données provenant de diverses sources avant de les utiliser dans leur formation et inférence ML. Auparavant, les data scientists se retrouvaient souvent confrontés à plusieurs outils pour prendre en charge SQL dans leur flux de travail, ce qui nuisait à la productivité.

Nous sommes ravis d'annoncer que les notebooks JupyterLab dans SageMaker Studio sont désormais dotés d'une prise en charge intégrée de SQL. Les data scientists peuvent désormais :

• Connectez-vous aux services de données populaires, notamment Amazone Athéna, Redshift d'Amazon, Zone de données Amazon, et Snowflake directement dans les notebooks
• Parcourez et recherchez des bases de données, des schémas, des tables et des vues, et prévisualisez les données dans l'interface du bloc-notes.
• Mélangez le code SQL et Python dans le même notebook pour une exploration et une transformation efficaces des données à utiliser dans les projets ML
• Utilisez les fonctionnalités de productivité des développeurs telles que la complétion des commandes SQL, l'assistance au formatage du code et la coloration syntaxique pour accélérer le développement du code et améliorer la productivité globale des développeurs.

De plus, les administrateurs peuvent gérer en toute sécurité les connexions à ces services de données, permettant ainsi aux data scientists d'accéder aux données autorisées sans avoir besoin de gérer manuellement les informations d'identification.

Dans cet article, nous vous guidons dans la configuration de cette fonctionnalité dans SageMaker Studio et vous présentons les différentes fonctionnalités de cette fonctionnalité. Nous montrons ensuite comment vous pouvez améliorer l'expérience SQL dans un ordinateur portable en utilisant les fonctionnalités Text-to-SQL fournies par les grands modèles de langage (LLM) avancés pour écrire des requêtes SQL complexes en utilisant du texte en langage naturel comme entrée. Enfin, pour permettre à un public plus large d'utilisateurs de générer des requêtes SQL à partir de la saisie en langage naturel dans leurs blocs-notes, nous vous montrons comment déployer ces modèles Text-to-SQL à l'aide de Amazon Sage Maker points finaux.

Vue d'ensemble de la solution

Grâce à l'intégration SQL du notebook SageMaker Studio JupyterLab, vous pouvez désormais vous connecter à des sources de données populaires telles que Snowflake, Athena, Amazon Redshift et Amazon DataZone. Cette nouvelle fonctionnalité vous permet d'exécuter diverses fonctions.

Par exemple, vous pouvez explorer visuellement des sources de données telles que des bases de données, des tables et des schémas directement depuis votre écosystème JupyterLab. Si vos environnements de notebook s'exécutent sur SageMaker Distribution 1.6 ou version ultérieure, recherchez un nouveau widget sur le côté gauche de votre interface JupyterLab. Cet ajout améliore l'accessibilité et la gestion des données au sein de votre environnement de développement.

Si vous n'utilisez pas actuellement la distribution SageMaker suggérée (1.5 ou inférieure) ou si vous êtes dans un environnement personnalisé, reportez-vous à l'annexe pour plus d'informations.

Après avoir configuré les connexions (illustrées dans la section suivante), vous pouvez répertorier les connexions de données, parcourir les bases de données et les tables et inspecter les schémas.

L'extension SQL intégrée de SageMaker Studio JupyterLab vous permet également d'exécuter des requêtes SQL directement à partir d'un bloc-notes. Les notebooks Jupyter peuvent différencier le code SQL du code Python à l'aide de l'outil %%sm_sql commande magique, qui doit être placée en haut de toute cellule contenant du code SQL. Cette commande signale à JupyterLab que les instructions suivantes sont des commandes SQL plutôt que du code Python. Le résultat d'une requête peut être affiché directement dans le bloc-notes, facilitant ainsi l'intégration transparente des flux de travail SQL et Python dans votre analyse de données.

Le résultat d'une requête peut être affiché visuellement sous forme de tableaux HTML, comme le montre la capture d'écran suivante.

Ils peuvent également être écrits dans un pandas dataframe.

Pré-requis

Assurez-vous d'avoir satisfait aux conditions préalables suivantes afin d'utiliser l'expérience SQL du notebook SageMaker Studio :

• SageMaker Studio V2 – Assurez-vous que vous utilisez la version la plus récente de votre Domaine SageMaker Studio et profils utilisateur. Si vous utilisez actuellement SageMaker Studio Classic, reportez-vous à Migration depuis Amazon SageMaker Studio Classic.
• Rôle IAM – SageMaker nécessite un Gestion des identités et des accès AWS (IAM) à attribuer à un domaine ou à un profil utilisateur SageMaker Studio pour gérer efficacement les autorisations. Une mise à jour du rôle d'exécution peut être nécessaire pour intégrer la navigation dans les données et la fonctionnalité d'exécution SQL. L'exemple de stratégie suivant permet aux utilisateurs d'accorder, de répertorier et d'exécuter Colle AWS, Athéna, Service de stockage simple Amazon (Amazon S3), AWS Secrets Manageret ressources Amazon Redshift :

  {
     "Version":"2012-10-17",
     "Statement":[
        {
           "Sid":"SQLRelatedS3Permissions",
           "Effect":"Allow",
           "Action":[
              "s3:ListBucket",
              "s3:GetObject",
              "s3:GetBucketLocation",
              "s3:ListMultipartUploadParts",
              "s3:AbortMultipartUpload",
              "s3:PutObject"
           ],
           "Resource":[
              "arn:aws:s3:::sagemaker*/*",
              "arn:aws:s3:::sagemaker*"
           ]
        },
        {
           "Sid":"GlueDataAccess",
           "Effect":"Allow",
           "Action":[
              "glue:GetDatabases",
              "glue:GetSchema",
              "glue:GetTables",
              "glue:GetDatabase",
              "glue:GetTable",
              "glue:ListSchemas",
              "glue:GetPartitions",
              "glue:GetConnections",
              "glue:GetConnection",
              "glue:CreateConnection"
           ],
           "Resource":[
              "arn:aws:glue:<region>:<account>:table/sagemaker*/*",
              "arn:aws:glue:<region>:<account>:database/sagemaker*",
              "arn:aws:glue:<region>:<account>:schema/sagemaker*",
              "arn:aws:glue:<region>:<account>:connection/sagemaker*",
              "arn:aws:glue:<region>:<account>:registry/sagemaker*",
              "arn:aws:glue:<region>:<account>:catalog"
           ]
        },
        {
           "Sid":"AthenaQueryExecution",
           "Effect":"Allow",
           "Action":[
              "athena:ListDataCatalogs",
              "athena:ListDatabases",
              "athena:ListTableMetadata",
              "athena:StartQueryExecution",
              "athena:GetQueryExecution",
              "athena:RunQuery",
              "athena:StartSession",
              "athena:GetQueryResults",
              "athena:ListWorkGroups",
              "athena:GetDataCatalog",
              "athena:GetWorkGroup"
           ],
           "Resource":[
              "arn:aws:athena:<region>:<account>:workgroup/sagemaker*",
              "arn:aws:athena:<region>:<account>:datacatalog/sagemaker*"
           ]
        },
        {
           "Sid":"GetSecretsAndCredentials",
           "Effect":"Allow",
           "Action":[
              "secretsmanager:GetSecretValue",
              "redshift:GetClusterCredentials"
           ],
           "Resource":[
              "arn:aws:secretsmanager:<region>:<account>:secret:sagemaker*",
              "arn:aws:redshift:<region>:<account>:dbuser:sagemaker*/sagemaker*",
              "arn:aws:redshift:<region>:<account>:dbgroup:sagemaker*/sagemaker*",
              "arn:aws:redshift:<region>:<account>:dbname:sagemaker*/sagemaker*"
           ]
        }
     ]
  }

• Espace JupyterLab – Vous devez accéder à SageMaker Studio et à JupyterLab Space mis à jour avec Distribution SageMaker v1.6 ou versions d'image ultérieures. Si vous utilisez des images personnalisées pour JupyterLab Spaces ou des versions antérieures de SageMaker Distribution (v1.5 ou inférieure), reportez-vous à l'annexe pour obtenir des instructions sur l'installation des packages et modules nécessaires pour activer cette fonctionnalité dans vos environnements. Pour en savoir plus sur les espaces SageMaker Studio JupyterLab, reportez-vous à Augmentez la productivité sur Amazon SageMaker Studio : présentation des espaces JupyterLab et des outils d'IA générative.

• Identifiants d'accès à la source de données – Cette fonctionnalité de bloc-notes SageMaker Studio nécessite un accès par nom d'utilisateur et mot de passe aux sources de données telles que Snowflake et Amazon Redshift. Créez un accès basé sur un nom d'utilisateur et un mot de passe à ces sources de données si vous n'en avez pas déjà un. L'accès basé sur OAuth à Snowflake n'est pas une fonctionnalité prise en charge au moment d'écrire ces lignes.
• Charger la magie SQL – Avant d'exécuter des requêtes SQL à partir d'une cellule de notebook Jupyter, il est essentiel de charger l'extension SQL Magics. Utilisez la commande %load_ext amazon_sagemaker_sql_magic pour activer cette fonctionnalité. De plus, vous pouvez exécuter le %sm_sql? pour afficher une liste complète des options prises en charge pour les requêtes à partir d'une cellule SQL. Ces options incluent, entre autres, la définition d'une limite de requêtes par défaut de 1,000 XNUMX, l'exécution d'une extraction complète et l'injection de paramètres de requête. Cette configuration permet une manipulation flexible et efficace des données SQL directement dans votre environnement de bloc-notes.

Créer des connexions à la base de données

Les capacités de navigation et d'exécution SQL intégrées de SageMaker Studio sont améliorées par les connexions AWS Glue. Une connexion AWS Glue est un objet AWS Glue Data Catalog qui stocke des données essentielles telles que les informations de connexion, les chaînes URI et les informations de cloud privé virtuel (VPC) pour des magasins de données spécifiques. Ces connexions sont utilisées par les robots d'exploration, les tâches et les points de terminaison de développement AWS Glue pour accéder à différents types de magasins de données. Vous pouvez utiliser ces connexions pour les données source et cible, et même réutiliser la même connexion sur plusieurs robots d'exploration ou tâches d'extraction, de transformation et de chargement (ETL).

Pour explorer les sources de données SQL dans le volet gauche de SageMaker Studio, vous devez d'abord créer des objets de connexion AWS Glue. Ces connexions facilitent l'accès à différentes sources de données et vous permettent d'explorer leurs éléments de données schématiques.

Dans les sections suivantes, nous passons en revue le processus de création de connecteurs AWS Glue spécifiques à SQL. Cela vous permettra d'accéder, de visualiser et d'explorer des ensembles de données dans une variété de magasins de données. Pour des informations plus détaillées sur les connexions AWS Glue, reportez-vous à Connexion aux données.

Créer une connexion AWS Glue

La seule façon d'importer des sources de données dans SageMaker Studio consiste à utiliser les connexions AWS Glue. Vous devez créer des connexions AWS Glue avec des types de connexion spécifiques. Au moment d'écrire ces lignes, le seul mécanisme pris en charge pour créer ces connexions consiste à utiliser le Interface de ligne de commande AWS (AWS CLI).

Fichier JSON de définition de connexion

Lors de la connexion à différentes sources de données dans AWS Glue, vous devez d'abord créer un fichier JSON qui définit les propriétés de connexion, appelées fichier fichier de définition de connexion. Ce fichier est crucial pour établir une connexion AWS Glue et doit détailler toutes les configurations nécessaires pour accéder à la source de données. Pour les meilleures pratiques de sécurité, il est recommandé d'utiliser Secrets Manager pour stocker en toute sécurité des informations sensibles telles que les mots de passe. Parallèlement, d'autres propriétés de connexion peuvent être gérées directement via les connexions AWS Glue. Cette approche garantit que les informations d'identification sensibles sont protégées tout en rendant la configuration de la connexion accessible et gérable.

Voici un exemple de définition de connexion JSON :

{
    "ConnectionInput": {
        "Name": <GLUE_CONNECTION_NAME>,
        "Description": <GLUE_CONNECTION_DESCRIPTION>,
        "ConnectionType": "REDSHIFT | SNOWFLAKE | ATHENA",
        "ConnectionProperties": {
            "PythonProperties": "{"aws_secret_arn": <SECRET_ARN>, "database": <...>}"
        }
    }
}

Lors de la configuration des connexions AWS Glue pour vos sources de données, vous devez suivre quelques directives importantes pour assurer à la fois la fonctionnalité et la sécurité :

• Stringification des propriétés - Dans le PythonProperties clé, assurez-vous que toutes les propriétés sont paires clé-valeur stringifiées. Il est crucial d'échapper correctement aux guillemets doubles en utilisant le caractère barre oblique inverse () si nécessaire. Cela permet de maintenir le format correct et d'éviter les erreurs de syntaxe dans votre JSON.
• Gestion des informations sensibles – Bien qu'il soit possible d'inclure toutes les propriétés de connexion dans PythonProperties, il est conseillé de ne pas inclure de détails sensibles comme les mots de passe directement dans ces propriétés. Utilisez plutôt Secrets Manager pour gérer les informations sensibles. Cette approche sécurise vos données sensibles en les stockant dans un environnement contrôlé et crypté, loin des principaux fichiers de configuration.

Créer une connexion AWS Glue à l'aide de l'AWS CLI

Après avoir inclus tous les champs nécessaires dans votre fichier JSON de définition de connexion, vous êtes prêt à établir une connexion AWS Glue pour votre source de données à l'aide de l'AWS CLI et de la commande suivante :

aws --region <REGION> glue create-connection 
--cli-input-json file:///path/to/file/connection/definition/file.json

Cette commande initie une nouvelle connexion AWS Glue en fonction des spécifications détaillées dans votre fichier JSON. Voici une présentation rapide des composants de la commande :

• -région – Ceci spécifie la région AWS dans laquelle votre connexion AWS Glue sera créée. Il est crucial de sélectionner la région où se trouvent vos sources de données et autres services afin de minimiser la latence et de respecter les exigences de résidence des données.
• –cli-input-json fichier:///path/to/file/connection/definition/file.json – Ce paramètre demande à l'AWS CLI de lire la configuration d'entrée à partir d'un fichier local contenant votre définition de connexion au format JSON.

Vous devriez pouvoir créer des connexions AWS Glue avec la commande AWS CLI précédente à partir de votre terminal Studio JupyterLab. Sur le Déposez votre dernière attestation menu, choisissez Nouveauté ainsi que terminal.

Si la create-connection La commande s'exécute avec succès, vous devriez voir votre source de données répertoriée dans le volet du navigateur SQL. Si votre source de données ne figure pas dans la liste, choisissez Refresh pour mettre à jour le cache.

Créer une connexion Snowflake

Dans cette section, nous nous concentrons sur l'intégration d'une source de données Snowflake avec SageMaker Studio. La création de comptes, de bases de données et d'entrepôts Snowflake n'entre pas dans le cadre de cet article. Pour démarrer avec Snowflake, reportez-vous au Guide d'utilisation du flocon de neige. Dans cet article, nous nous concentrons sur la création d'un fichier JSON de définition Snowflake et l'établissement d'une connexion à la source de données Snowflake à l'aide d'AWS Glue.

Créer un secret Secrets Manager

Vous pouvez vous connecter à votre compte Snowflake soit en utilisant un identifiant et un mot de passe, soit en utilisant des clés privées. Pour vous connecter avec un identifiant et un mot de passe, vous devez stocker en toute sécurité vos informations d'identification dans Secrets Manager. Comme mentionné précédemment, bien qu'il soit possible d'intégrer ces informations sous PythonProperties, il n'est pas recommandé de stocker les informations sensibles au format texte brut. Assurez-vous toujours que les données sensibles sont traitées en toute sécurité pour éviter les risques de sécurité potentiels.

Pour stocker des informations dans Secrets Manager, procédez comme suit :

1. Sur la console Secrets Manager, choisissez Stocker un nouveau secret.
2. Pour Type secret, choisissez Autre type de secret.
3. Pour la paire clé-valeur, choisissez Plaintext et entrez ce qui suit:

   {
       "user":"TestUser",
       "password":"MyTestPassword",
       "account":"AWSSAGEMAKERTEST"
   }

4. Saisissez un nom pour votre secret, tel que sm-sql-snowflake-secret.
5. Laissez les autres paramètres par défaut ou personnalisez-les si nécessaire.
6. Créez le secret.

Créer une connexion AWS Glue pour Snowflake

Comme indiqué précédemment, les connexions AWS Glue sont essentielles pour accéder à n'importe quelle connexion depuis SageMaker Studio. Vous pouvez trouver une liste de toutes les propriétés de connexion prises en charge pour Snowflake. Voici un exemple de définition de connexion JSON pour Snowflake. Remplacez les valeurs d'espace réservé par les valeurs appropriées avant de les enregistrer sur le disque :

{
    "ConnectionInput": {
        "Name": "Snowflake-Airlines-Dataset",
        "Description": "SageMaker-Snowflake Airlines Dataset",
        "ConnectionType": "SNOWFLAKE",
        "ConnectionProperties": {
            "PythonProperties": "{"aws_secret_arn": "arn:aws:secretsmanager:<region>:<account>:secret:sm-sql-snowflake-secret", "database": "SAGEMAKERDEMODATABASE1"}"
        }
    }
}

Pour créer un objet de connexion AWS Glue pour la source de données Snowflake, utilisez la commande suivante :

aws --region <REGION> glue create-connection 
--cli-input-json file:///path/to/file/snowflake/definition/file.json

Cette commande crée une nouvelle connexion à la source de données Snowflake dans le volet de votre navigateur SQL qui est consultable, et vous pouvez exécuter des requêtes SQL sur celle-ci à partir de votre cellule de notebook JupyterLab.

Créer une connexion Amazon Redshift

Amazon Redshift est un service d'entrepôt de données entièrement géré à l'échelle du pétaoctet qui simplifie et réduit le coût de l'analyse de toutes vos données à l'aide du SQL standard. La procédure de création d'une connexion Amazon Redshift reflète étroitement celle d'une connexion Snowflake.

Créer un secret Secrets Manager

Semblable à la configuration de Snowflake, pour vous connecter à Amazon Redshift à l'aide d'un identifiant et d'un mot de passe, vous devez stocker en toute sécurité les informations secrètes dans Secrets Manager. Effectuez les étapes suivantes :

1. Sur la console Secrets Manager, choisissez Stocker un nouveau secret.
2. Pour Type secret, choisissez Informations d'identification pour le cluster Amazon Redshift.
3. Saisissez les informations d'identification utilisées pour vous connecter afin d'accéder à Amazon Redshift en tant que source de données.
4. Choisissez le cluster Redshift associé aux secrets.
5. Saisissez un nom pour le secret, tel que sm-sql-redshift-secret.
6. Laissez les autres paramètres par défaut ou personnalisez-les si nécessaire.
7. Créez le secret.

En suivant ces étapes, vous vous assurez que vos informations d'identification de connexion sont traitées en toute sécurité, en utilisant les fonctionnalités de sécurité robustes d'AWS pour gérer efficacement les données sensibles.

Créer une connexion AWS Glue pour Amazon Redshift

Pour configurer une connexion avec Amazon Redshift à l'aide d'une définition JSON, remplissez les champs nécessaires et enregistrez la configuration JSON suivante sur le disque :

{
    "ConnectionInput": {
        "Name": "Redshift-US-Housing-Dataset",
        "Description": "sagemaker redshift us housing dataset connection",
        "ConnectionType": "REDSHIFT",
        "ConnectionProperties": {
            "PythonProperties": "{"aws_secret_arn": "arn:aws:secretsmanager:<region>:<account>:sm-sql-redshift-secret", "database": "us-housing-database"}"
        }
    }
}

Pour créer un objet de connexion AWS Glue pour la source de données Redshift, utilisez la commande AWS CLI suivante :

aws --region <REGION> glue create-connection 
--cli-input-json file:///path/to/file/redshift/definition/file.json

Cette commande crée une connexion dans AWS Glue liée à votre source de données Redshift. Si la commande s'exécute correctement, vous pourrez voir votre source de données Redshift dans le bloc-notes SageMaker Studio JupyterLab, prête à exécuter des requêtes SQL et à effectuer une analyse des données.

Créer une connexion Athena

Athena est un service de requête SQL entièrement géré d'AWS qui permet d'analyser les données stockées dans Amazon S3 à l'aide du SQL standard. Pour configurer une connexion Athena en tant que source de données dans le navigateur SQL du notebook JupyterLab, vous devez créer un exemple de définition de connexion Athena JSON. La structure JSON suivante configure les détails nécessaires pour se connecter à Athena, en spécifiant le catalogue de données, le répertoire intermédiaire S3 et la région :

{
    "ConnectionInput": {
        "Name": "Athena-Credit-Card-Fraud",
        "Description": "SageMaker-Athena Credit Card Fraud",
        "ConnectionType": "ATHENA",
        "ConnectionProperties": {
            "PythonProperties": "{"catalog_name": "AwsDataCatalog","s3_staging_dir": "s3://sagemaker-us-east-2-123456789/athena-data-source/credit-card-fraud/", "region_name": "us-east-2"}"
        }
    }
}

Pour créer un objet de connexion AWS Glue pour la source de données Athena, utilisez la commande AWS CLI suivante :

aws --region <REGION> glue create-connection 
--cli-input-json file:///path/to/file/athena/definition/file.json

Si la commande réussit, vous pourrez accéder au catalogue de données et aux tables Athena directement à partir du navigateur SQL dans votre bloc-notes SageMaker Studio JupyterLab.

Interroger des données à partir de plusieurs sources

Si vous disposez de plusieurs sources de données intégrées à SageMaker Studio via le navigateur SQL intégré et la fonctionnalité SQL du bloc-notes, vous pouvez exécuter rapidement des requêtes et basculer sans effort entre les backends de sources de données dans les cellules suivantes d'un bloc-notes. Cette fonctionnalité permet des transitions transparentes entre différentes bases de données ou sources de données pendant votre flux de travail d'analyse.

Vous pouvez exécuter des requêtes sur une collection diversifiée de backends de sources de données et importer les résultats directement dans l'espace Python pour une analyse ou une visualisation plus approfondie. Ceci est facilité par le %%sm_sql commande magique disponible dans les blocs-notes SageMaker Studio. Pour afficher les résultats de votre requête SQL dans un DataFrame pandas, il existe deux options :

• Dans la barre d'outils des cellules de votre bloc-notes, choisissez le type de sortie Trame de données et nommez votre variable DataFrame
• Ajoutez le paramètre suivant à votre %%sm_sql commander:

  --output '{"format": "DATAFRAME", "dataframe_name": "df"}'

Le diagramme suivant illustre ce flux de travail et montre comment vous pouvez exécuter sans effort des requêtes sur diverses sources dans les cellules suivantes du bloc-notes, ainsi que former un modèle SageMaker à l'aide de tâches de formation ou directement dans le bloc-notes à l'aide d'un calcul local. De plus, le diagramme montre comment l'intégration SQL intégrée de SageMaker Studio simplifie les processus d'extraction et de construction directement dans l'environnement familier d'une cellule de bloc-notes JupyterLab.

Text to SQL : utilisation du langage naturel pour améliorer la création de requêtes

SQL est un langage complexe qui nécessite une compréhension des bases de données, des tables, des syntaxes et des métadonnées. Aujourd'hui, l'intelligence artificielle (IA) générative peut vous permettre d'écrire des requêtes SQL complexes sans nécessiter une expérience SQL approfondie. Les progrès des LLM ont eu un impact significatif sur la génération SQL basée sur le traitement du langage naturel (NLP), permettant la création de requêtes SQL précises à partir de descriptions en langage naturel, une technique appelée Text-to-SQL. Cependant, il est essentiel de reconnaître les différences inhérentes entre le langage humain et SQL. Le langage humain peut parfois être ambigu ou imprécis, alors que SQL est structuré, explicite et sans ambiguïté. Combler cette lacune et convertir avec précision le langage naturel en requêtes SQL peut représenter un formidable défi. Lorsqu'ils sont fournis avec des invites appropriées, les LLM peuvent aider à combler cette lacune en comprenant l'intention derrière le langage humain et en générant des requêtes SQL précises en conséquence.

Avec la sortie de la fonctionnalité de requête SQL intégrée au notebook de SageMaker Studio, SageMaker Studio facilite l'inspection des bases de données et des schémas, ainsi que la création, l'exécution et le débogage de requêtes SQL sans jamais quitter l'IDE du notebook Jupyter. Cette section explore comment les fonctionnalités Text-to-SQL des LLM avancés peuvent faciliter la génération de requêtes SQL à l'aide du langage naturel dans les notebooks Jupyter. Nous utilisons le modèle Text-to-SQL de pointe defog/sqlcoder-7b-2 en collaboration avec Jupyter AI, un assistant d'IA génératif spécialement conçu pour les notebooks Jupyter, pour créer des requêtes SQL complexes à partir du langage naturel. En utilisant ce modèle avancé, nous pouvons créer sans effort et efficacement des requêtes SQL complexes en utilisant le langage naturel, améliorant ainsi notre expérience SQL dans les notebooks.

Prototypage d'ordinateurs portables à l'aide du Hugging Face Hub

Pour commencer le prototypage, vous avez besoin des éléments suivants :

• Code GitHub – Le code présenté dans cette section est disponible dans ce qui suit GitHub repo et en faisant référence au exemple de cahier.
• Espace JupyterLab – L’accès à un espace SageMaker Studio JupyterLab soutenu par des instances basées sur GPU est essentiel. Pour le defog/sqlcoder-7b-2 modèle, un modèle de paramètres 7B, utilisant une instance ml.g5.2xlarge est recommandé. Des alternatives telles que defog/sqlcoder-70b-alphun ou defog/sqlcoder-34b-alpha sont également viables pour la conversion du langage naturel vers SQL, mais des types d'instances plus volumineux peuvent être nécessaires pour le prototypage. Assurez-vous de disposer du quota nécessaire pour lancer une instance basée sur GPU en accédant à la console Service Quotas, en recherchant SageMaker et en recherchant Studio JupyterLab Apps running on <instance type>.

Lancez un nouvel espace JupyterLab basé sur GPU depuis votre SageMaker Studio. Il est recommandé de créer un nouvel espace JupyterLab avec au moins 75 Go de Boutique de blocs élastiques Amazon Stockage (Amazon EBS) pour un modèle de paramètres 7B.

• Visage câlin – Si votre domaine SageMaker Studio a accès au téléchargement de modèles à partir du Visage câlin, vous pouvez utiliser le AutoModelForCausalLM classe de câlins/transformateurs pour télécharger automatiquement des modèles et les épingler sur vos GPU locaux. Les poids du modèle seront stockés dans le cache de votre machine locale. Voir le code suivant :

  model_id = "defog/sqlcoder-7b-2" # or use "defog/sqlcoder-34b-alpha", "defog/sqlcoder-70b-alpha
  
  # download model and tokenizer in fp16 and pin model to local notebook GPUs
  model = AutoModelForCausalLM.from_pretrained(
      model_id, 
      device_map="auto",
      torch_dtype=torch.float16
  )
  
  tokenizer = AutoTokenizer.from_pretrained(model_id)
  tokenizer.pad_token = tokenizer.eos_token

Une fois le modèle entièrement téléchargé et chargé en mémoire, vous devriez observer une augmentation de l'utilisation du GPU sur votre ordinateur local. Cela indique que le modèle utilise activement les ressources GPU pour les tâches de calcul. Vous pouvez le vérifier dans votre propre espace JupyterLab en exécutant nvidia-smi (pour un affichage unique) ou nvidia-smi —loop=1 (à répéter toutes les secondes) depuis votre terminal JupyterLab.

Les modèles Text-to-SQL excellent dans la compréhension de l'intention et du contexte de la demande d'un utilisateur, même lorsque le langage utilisé est conversationnel ou ambigu. Le processus implique la traduction des entrées en langage naturel en éléments de schéma de base de données corrects, tels que les noms de tables, les noms de colonnes et les conditions. Cependant, un modèle Text-to-SQL prêt à l'emploi ne connaîtra pas intrinsèquement la structure de votre entrepôt de données, les schémas de base de données spécifiques, ni ne sera capable d'interpréter avec précision le contenu d'une table en se basant uniquement sur les noms de colonnes. Pour utiliser efficacement ces modèles afin de générer des requêtes SQL pratiques et efficaces à partir d'un langage naturel, il est nécessaire d'adapter le modèle de génération de texte SQL au schéma de votre base de données d'entrepôt spécifique. Cette adaptation est facilitée par l'utilisation de Invites LLM. Voici un modèle d'invite recommandé pour le modèle Text-to-SQL defog/sqlcoder-7b-2, divisé en quatre parties :

• Tâche – Cette section doit spécifier une tâche de haut niveau à accomplir par le modèle. Il doit inclure le type de backend de base de données (tel qu'Amazon RDS, PostgreSQL ou Amazon Redshift) pour que le modèle soit conscient de toute différence syntaxique nuancée pouvant affecter la génération de la requête SQL finale.
• Instructions – Cette section doit définir les limites des tâches et la connaissance du domaine pour le modèle, et peut inclure quelques exemples pour guider le modèle dans la génération de requêtes SQL affinées.
• Schéma de base de données – Cette section doit détailler les schémas de votre base de données d'entrepôt, en décrivant les relations entre les tables et les colonnes pour aider le modèle à comprendre la structure de la base de données.
• Compagnie de Solution – Cette section est réservée au modèle pour générer la réponse à la requête SQL à l'entrée en langage naturel.

Un exemple du schéma de base de données et de l'invite utilisés dans cette section est disponible dans le Repo GitHub.

### Task
Generate a SQL query to answer [QUESTION]{user_question}[/QUESTION]

### Instructions
- If you cannot answer the question with the available database schema, return 'I do not know'

### Database Schema
The query will run on a database with the following schema:
{table_metadata_string_DDL_statements}

### Answer
Given the database schema, here is the SQL query that 
 [QUESTION]
    {user_question}
 [/QUESTION]

[SQL]

L’ingénierie rapide ne consiste pas seulement à formuler des questions ou des déclarations ; c'est un art et une science nuancés qui ont un impact significatif sur la qualité des interactions avec un modèle d'IA. La façon dont vous créez une invite peut profondément influencer la nature et l’utilité de la réponse de l’IA. Cette compétence est essentielle pour maximiser le potentiel des interactions de l’IA, en particulier dans les tâches complexes nécessitant une compréhension spécialisée et des réponses détaillées.

Il est important d'avoir la possibilité de créer et de tester rapidement la réponse d'un modèle pour une invite donnée et d'optimiser l'invite en fonction de la réponse. Les notebooks JupyterLab offrent la possibilité de recevoir des commentaires instantanés sur un modèle exécuté sur un calcul local, d'optimiser l'invite et d'ajuster davantage la réponse d'un modèle ou de modifier entièrement un modèle. Dans cet article, nous utilisons un notebook SageMaker Studio JupyterLab soutenu par le GPU NVIDIA A5.2G 10 Go de ml.g24xlarge pour exécuter l'inférence de modèle Text-to-SQL sur le notebook et créer de manière interactive notre invite de modèle jusqu'à ce que la réponse du modèle soit suffisamment ajustée pour fournir réponses directement exécutables dans les cellules SQL de JupyterLab. Pour exécuter l'inférence de modèle et diffuser simultanément les réponses du modèle, nous utilisons une combinaison de model.generate ainsi que TextIteratorStreamer tel que défini dans le code suivant :

streamer = TextIteratorStreamer(
    tokenizer=tokenizer, 
    timeout=240.0, 
    skip_prompt=True, 
    skip_special_tokens=True
)


def llm_generate_query(user_question):
    """ Generate text-gen SQL responses"""
    
    updated_prompt = prompt.format(question=user_question)
    inputs = tokenizer(updated_prompt, return_tensors="pt").to("cuda")
    
    return model.generate(
        **inputs,
        num_return_sequences=1,
        eos_token_id=tokenizer.eos_token_id,
        pad_token_id=tokenizer.eos_token_id,
        max_new_tokens=1024,
        temperature=0.1,
        do_sample=False,
        num_beams=1, 
        streamer=streamer,
    )

La sortie du modèle peut être décorée avec la magie SageMaker SQL %%sm_sql ..., qui permet au notebook JupyterLab d'identifier la cellule en tant que cellule SQL.

Héberger des modèles Text-to-SQL en tant que points de terminaison SageMaker

À la fin de la phase de prototypage, nous avons sélectionné notre LLM Text-to-SQL préféré, un format d'invite efficace et un type d'instance approprié pour héberger le modèle (soit mono-GPU, soit multi-GPU). SageMaker facilite l'hébergement évolutif de modèles personnalisés grâce à l'utilisation de points de terminaison SageMaker. Ces points de terminaison peuvent être définis selon des critères spécifiques, permettant le déploiement de LLM en tant que points de terminaison. Cette fonctionnalité vous permet d'adapter la solution à un public plus large, en permettant aux utilisateurs de générer des requêtes SQL à partir d'entrées en langage naturel à l'aide de LLM hébergés personnalisés. Le diagramme suivant illustre cette architecture.

Pour héberger votre LLM en tant que point de terminaison SageMaker, vous générez plusieurs artefacts.

Le premier artefact concerne les poids du modèle. Service de la bibliothèque SageMaker Deep Java (DJL) les conteneurs vous permettent de mettre en place des configurations via une méta servant.propriétés , qui vous permet de déterminer la manière dont les modèles proviennent, soit directement à partir du Hugging Face Hub, soit en téléchargeant des artefacts de modèle depuis Amazon S3. Si vous précisez model_id=defog/sqlcoder-7b-2, DJL Serving tentera de télécharger directement ce modèle depuis le Hugging Face Hub. Cependant, vous pouvez devoir payer des frais d'entrée/sortie réseau à chaque fois que le point de terminaison est déployé ou mis à l'échelle de manière élastique. Pour éviter ces frais et potentiellement accélérer le téléchargement des artefacts de modèle, il est recommandé de ne pas utiliser model_id in serving.properties et enregistrez les poids du modèle en tant qu'artefacts S3 et spécifiez-les uniquement avec s3url=s3://path/to/model/bin.

L'enregistrement d'un modèle (avec son tokenizer) sur le disque et son téléchargement sur Amazon S3 peuvent être réalisés avec seulement quelques lignes de code :

# save model and tokenizer to local disk
model.save_pretrained(local_model_path)
tokenizer.save_pretrained(local_model_path)
...
...
...
# upload file to s3
s3_bucket_name = "<my llm artifact bucket name>>"
# s3 prefix to save model weights and tokenizer defs
model_s3_prefix = "sqlcoder-7b-instruct/weights"
# s3 prefix to store s
meta_model_s3_prefix = "sqlcoder-7b-instruct/meta-model"

sagemaker.s3.S3Uploader.upload(local_model_path,  f"s3://{s3_bucket_name}/{model_s3_prefix}")

Vous utilisez également un fichier d'invite de base de données. Dans cette configuration, l'invite de base de données est composée de Task, Instructions, Database Schemaet Answer sections. Pour l'architecture actuelle, nous allouons un fichier d'invite distinct pour chaque schéma de base de données. Cependant, il est possible d'étendre cette configuration pour inclure plusieurs bases de données par fichier d'invite, permettant ainsi au modèle d'exécuter des jointures composites sur plusieurs bases de données sur le même serveur. Au cours de notre étape de prototypage, nous enregistrons l'invite de la base de données sous forme de fichier texte nommé <Database-Glue-Connection-Name>.prompt, Où Database-Glue-Connection-Name correspond au nom de connexion visible dans votre environnement JupyterLab. Par exemple, cet article fait référence à une connexion Snowflake nommée Airlines_Dataset, le fichier d'invite de la base de données est donc nommé Airlines_Dataset.prompt. Ce fichier est ensuite stocké sur Amazon S3, puis lu et mis en cache par notre logique de diffusion de modèles.

De plus, cette architecture permet à tout utilisateur autorisé de ce point de terminaison de définir, stocker et générer des requêtes SQL en langage naturel sans avoir besoin de plusieurs redéploiements du modèle. Nous utilisons ce qui suit exemple d'invite de base de données pour démontrer la fonctionnalité Text-to-SQL.

Ensuite, vous générez une logique de service de modèle personnalisé. Dans cette section, vous décrivez une logique d'inférence personnalisée nommée modèle.py. Ce script est conçu pour optimiser les performances et l'intégration de nos services Text-to-SQL :

• Définir la logique de mise en cache des fichiers d'invite de base de données – Pour minimiser la latence, nous implémentons une logique personnalisée pour le téléchargement et la mise en cache des fichiers d'invite de base de données. Ce mécanisme garantit que les invites sont facilement disponibles, réduisant ainsi la surcharge associée aux téléchargements fréquents.
• Définir une logique d'inférence de modèle personnalisé – Pour améliorer la vitesse d'inférence, notre modèle texte vers SQL est chargé au format de précision float16 puis converti en un modèle DeepSpeed. Cette étape permet un calcul plus efficace. De plus, dans cette logique, vous spécifiez les paramètres que les utilisateurs peuvent ajuster lors des appels d'inférence pour adapter la fonctionnalité en fonction de leurs besoins.
• Définir une logique d'entrée et de sortie personnalisée – L’établissement de formats d’entrée/sortie clairs et personnalisés est essentiel pour une intégration fluide avec les applications en aval. L'une de ces applications est JupyterAI, dont nous discutons dans la section suivante.

%%writefile {meta_model_filename}/model.py
...

predictor = None
prompt_for_db_dict_cache = {}

def download_prompt_from_s3(prompt_filename):

    print(f"downloading prompt file: {prompt_filename}")
    s3 = boto3.resource('s3')
    ...


def get_model(properties):
    
    ...
    print(f"Loading model from {cwd}")
    model = AutoModelForCausalLM.from_pretrained(
        cwd, 
        low_cpu_mem_usage=True, 
        torch_dtype=torch.bfloat16
    )
    model = deepspeed.init_inference(
        model, 
        mp_size=properties["tensor_parallel_degree"]
    )
    
    ...


def handle(inputs: Input) -> None:

    ...

    global predictor
    if not predictor:
        predictor = get_model(inputs.get_properties())

    ...
    result = f"""%%sm_sql --metastore-id {prompt_for_db_key.split('.')[0]} --metastore-type GLUE_CONNECTIONnn{result}n"""
    result = [{'generated_text': result}]
    
    return Output().add(result)

De plus, nous incluons un serving.properties , qui fait office de fichier de configuration global pour les modèles hébergés à l'aide du service DJL. Pour plus d'informations, reportez-vous à Configurations et paramètres.

Enfin, vous pouvez également inclure un requirements.txt pour définir les modules supplémentaires requis pour l'inférence et regrouper le tout dans une archive tar pour le déploiement.

Voir le code suivant:

os.system(f"tar czvf {meta_model_filename}.tar.gz ./{meta_model_filename}/")

>>>./deepspeed-djl-serving-7b/
>>>./deepspeed-djl-serving-7b/serving.properties
>>>./deepspeed-djl-serving-7b/model.py
>>>./deepspeed-djl-serving-7b/requirements.txt

Intégrez votre point de terminaison à l'assistant IA de SageMaker Studio Jupyter

IA Jupyter est un outil open source qui apporte l'IA générative aux notebooks Jupyter, offrant une plate-forme robuste et conviviale pour explorer les modèles d'IA générative. Il améliore la productivité dans JupyterLab et les notebooks Jupyter en fournissant des fonctionnalités telles que la magie %%ai pour créer un terrain de jeu d'IA génératif dans les notebooks, une interface utilisateur de chat native dans JupyterLab pour interagir avec l'IA en tant qu'assistant conversationnel et la prise en charge d'un large éventail de LLM de des fournisseurs comme Titan d'Amazonie, AI21, Anthropic, Cohere et Hugging Face ou des services gérés comme Socle amazonien et les points de terminaison SageMaker. Pour cet article, nous utilisons l'intégration prête à l'emploi de Jupyter AI avec les points de terminaison SageMaker pour intégrer la fonctionnalité Text-to-SQL dans les notebooks JupyterLab. L'outil Jupyter AI est préinstallé dans tous les espaces SageMaker Studio JupyterLab soutenus par Images de la distribution SageMaker; les utilisateurs finaux ne sont pas tenus d'effectuer des configurations supplémentaires pour commencer à utiliser l'extension Jupyter AI afin de s'intégrer à un point de terminaison hébergé par SageMaker. Dans cette section, nous discutons des deux manières d'utiliser l'outil Jupyter AI intégré.

Jupyter AI dans un notebook utilisant la magie

IA Jupyter %%ai La commande magique vous permet de transformer vos blocs-notes SageMaker Studio JupyterLab en un environnement d'IA génératif reproductible. Pour commencer à utiliser la magie de l'IA, assurez-vous d'avoir chargé l'extension jupyter_ai_magics à utiliser %%ai magie, et chargez en plus amazon_sagemaker_sql_magic à utiliser %%sm_sql la magie:

# load sm_sql magic extension and ai magic extension
%load_ext jupyter_ai_magics
%load_ext amazon_sagemaker_sql_magic

Pour exécuter un appel vers votre point de terminaison SageMaker à partir de votre ordinateur portable à l'aide du %%ai commande magique, fournissez les paramètres suivants et structurez la commande comme suit :

• –nom-région – Spécifiez la région dans laquelle votre point de terminaison est déployé. Cela garantit que la demande est acheminée vers le bon emplacement géographique.
• –requête-schéma – Inclure le schéma des données d’entrée. Ce schéma décrit le format et les types attendus des données d'entrée dont votre modèle a besoin pour traiter la demande.
• – chemin de réponse – Définissez le chemin dans l’objet de réponse où se trouve la sortie de votre modèle. Ce chemin est utilisé pour extraire les données pertinentes de la réponse renvoyée par votre modèle.
• -f (facultatif) - C'est un formateur de sortie indicateur qui indique le type de sortie renvoyé par le modèle. Dans le contexte d'un notebook Jupyter, si la sortie est du code, cet indicateur doit être défini en conséquence pour formater la sortie sous forme de code exécutable en haut d'une cellule du notebook Jupyter, suivi d'une zone de saisie de texte libre pour l'interaction de l'utilisateur.

Par exemple, la commande dans une cellule de notebook Jupyter peut ressembler au code suivant :

%%ai sagemaker-endpoint:<endpoint-name> --region-name=us-east-1 
--request-schema={
    "inputs":"<prompt>", 
    "parameters":{
        "temperature":0.1,
        "top_p":0.2,
        "max_new_tokens":1024,
        "return_full_text":false
    }, 
    "db_prompt":"Airlines_Dataset.prompt"
  } 
--response-path=[0].generated_text -f code

My natural language query goes here...

Fenêtre de discussion Jupyter AI

Vous pouvez également interagir avec les points de terminaison SageMaker via une interface utilisateur intégrée, simplifiant ainsi le processus de génération de requêtes ou d'engagement de dialogue. Avant de commencer à discuter avec votre point de terminaison SageMaker, configurez les paramètres pertinents dans Jupyter AI pour le point de terminaison SageMaker, comme indiqué dans la capture d'écran suivante.

Conclusion

SageMaker Studio simplifie et rationalise désormais le flux de travail des data scientists en intégrant la prise en charge de SQL dans les notebooks JupyterLab. Cela permet aux data scientists de se concentrer sur leurs tâches sans avoir besoin de gérer plusieurs outils. De plus, la nouvelle intégration SQL intégrée dans SageMaker Studio permet aux data personas de générer sans effort des requêtes SQL en utilisant du texte en langage naturel comme entrée, accélérant ainsi leur flux de travail.

Nous vous encourageons à explorer ces fonctionnalités dans SageMaker Studio. Pour plus d'informations, reportez-vous à Préparer les données avec SQL dans Studio.

Appendice

Activer le navigateur SQL et la cellule SQL du bloc-notes dans des environnements personnalisés

Si vous n'utilisez pas d'image de distribution SageMaker ou si vous utilisez des images de distribution 1.5 ou antérieures, exécutez les commandes suivantes pour activer la fonctionnalité de navigation SQL dans votre environnement JupyterLab :

npm install -g vscode-jsonrpc
npm install -g sql-language-server
pip install amazon-sagemaker-sql-execution==0.1.0
pip install amazon-sagemaker-sql-editor
restart-jupyter-server

Déplacer le widget du navigateur SQL

Les widgets JupyterLab permettent la relocalisation. Selon vos préférences, vous pouvez déplacer les widgets de chaque côté du volet des widgets JupyterLab. Si vous préférez, vous pouvez déplacer la direction du widget SQL vers le côté opposé (de droite à gauche) de la barre latérale avec un simple clic droit sur l'icône du widget et en choisissant Changer le côté de la barre latérale.

À propos des auteurs

Pranav Murthy est un architecte de solutions spécialisé en IA/ML chez AWS. Il s'efforce d'aider les clients à créer, former, déployer et migrer des charges de travail d'apprentissage automatique (ML) vers SageMaker. Il a auparavant travaillé dans l'industrie des semi-conducteurs en développant de grands modèles de vision par ordinateur (CV) et de traitement du langage naturel (NLP) pour améliorer les processus de semi-conducteurs à l'aide de techniques de pointe de ML. Pendant son temps libre, il aime jouer aux échecs et voyager. Vous pouvez trouver Pranav sur LinkedIn.

Varun Shah est un ingénieur logiciel travaillant sur Amazon SageMaker Studio chez Amazon Web Services. Il se concentre sur la création de solutions ML interactives qui simplifient les parcours de traitement et de préparation des données. Dans ses temps libres, Varun aime les activités de plein air, notamment la randonnée et le ski, et est toujours prêt à découvrir de nouveaux endroits passionnants.

Sumedha Swamy est chef de produit principal chez Amazon Web Services où il dirige l'équipe SageMaker Studio dans sa mission de développement d'IDE de choix pour la science des données et l'apprentissage automatique. Il a consacré les 15 dernières années à la création de produits grand public et d'entreprise basés sur l'apprentissage automatique.

Bosco Albuquerque est un architecte de solutions partenaire senior chez AWS et a plus de 20 ans d'expérience de travail avec des produits de base de données et d'analyse de fournisseurs de bases de données d'entreprise et de fournisseurs de cloud. Il a aidé des entreprises technologiques à concevoir et à mettre en œuvre des solutions et des produits d'analyse de données.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/explore-data-with-ease-using-sql-and-text-to-sql-in-amazon-sagemaker-studio-jupyterlab-notebooks/