Utilisation des fonctions LLM dans les transformations de données

Remarque :

Consultez la documentation officielle de Snowflake sur Snowflake AI et ML pour obtenir un aperçu des capacités d’intelligence artificielle et d’apprentissage automatique de Snowflake.

Seules les données explicites transmises dans les appels de fonction sont envoyées au LLM.

1. Les données ne quittent pas l’environnement Snowflake.
2. Les données ne sont pas conservées au-delà du traitement et ne sont pas utilisées à des fins d'entraînement.
3. Les contrats et l’architecture de Snowflake sont conçus pour répondre aux normes de gouvernance des données d’entreprise.

Introduction

Les fonctions LLM vous permettent de traiter du texte non structuré en sortie catégorielle pour une analyse agrégée dans vos tableaux de bord. L'utilisation des fonctions LLM élimine le besoin de regex complexes dans SQL, ce qui facilite la configuration et l'adaptation de vos transformations basées sur les nouvelles données.

Reportez-vous à la documentation officielle de Snowflake sur Cortex AISQL (y compris les fonctions LLM) pour plus d'informations sur l'utilisation des fonctions LLM.

Avertissement : l'utilisation de fonctions LLM dans votre SQL peut avoir un impact significatif sur le temps de transformation. Par exemple, l'application d'une fonction de classification à 1 million d'enregistrements peut augmenter le temps de traitement d'au moins 30 heures.

Exemple de cas d'utilisation des fonctions LLM dans les transformations de données :

• Fonction AI_CLASSIFY de classification des données. Reportez-vous à la documentation officielle de Snowflake sur AI_ClassIFY pour plus d'informations.
• Fonction ENTITY_SENTIMENT pour l'analyse des sentiments. Reportez-vous à la documentation officielle de Snowflake sur entité_Sentiment pour plus d'informations.

Remarque : dans le cas peu probable où vous dépasseriez vos limites d’utilisation adéquate pour l’utilisation de LLM, UiPath® n’impose aucune restriction immédiate, de sorte que les opérations des clients peuvent continuer sans interruption. Toute modification apportée à cette offre ou à son offre commerciale sera communiquée à l’avance afin de garantir une expérience fluide et transparente.

Classification

Cette section décrit comment utiliser la fonction AI_CLASSIFY dans un contexte Process Mining, y compris des exemples.

Exemple : analyse du processus de haut niveau

Les processus peuvent être constitués de nombreuses activités différentes, dont certaines peuvent être très similaires et peuvent être mappées à des catégories de niveau supérieur. Ce type de mappage réduit le nombre de variantes de processus et permet l'analyse à un niveau plus abstraite.

Par exemple, dans un processus Purchase-to-Pay, les événements d'approbation peuvent se produire à différents niveaux, tels que « Approuver la demande d'achat », « Approuver la commande de niveau 1 », « Approbation du gestionnaire », etc. Chacune de ces activités peut être mappée sur une activité générique « Approuver ».

Un autre exemple est les événements « Modifier », tels que « Modifier le prix », « Modifier la date de livraison » ou « Changer de fournisseur ». Leur mappage à une seule activité « Modifier » réduit le nombre de chemins dans le processus et simplifie l’affichage du graphique de processus.

Le bloc de code suivant montre un exemple SQL d'application de la fonction AI_CLASSIFY pour définir le processus de haut niveau.

select
    {{ pm_utils.id() }} as "Event_ID",
    Purchase_order_item_event_log."Purchase_order_item_ID",
    Purchase_order_item_event_log."Event_end",
    coalesce(
        to_varchar(
            AI_CLASSIFY(
                Purchase_order_item_event_log."Activity",
                ['Create', 'Change', 'Approve', 'Complete', 'Cancel']):labels[0]), 
        'Not mapped') as "High_level_activity"
from {{ ref('Purchase_order_item_event_log') }} as Purchase_order_item_event_log

Comme premier argument de cette fonction, fournissez la colonne Activité (Activity) d'origine de votre table d'événements. Le deuxième argument doit être une liste d'activités de haut niveau auxquelles les activités seront mappées. Dans cet exemple, les activités sont mappées sur « Créer », « Modifier », « Approuver », « Terminer » ou « Annuler ».

Étapes de mise en œuvre de l'analyse de processus de haut niveau :

1. Créez un fichier SQL distinct dans votre projet, par exemple High_level_events.sql, et ajoutez-y la logique SQL de processus de haut niveau.
2. Ajoutez High_level_events au modèle de données et configurez la relation. Dans cet exemple, les événements de haut niveau sont connectés à la table des éléments de commande d'achat basée sur Purchase_order_item_ID.
3. Ajoutez un processus supplémentaire avec les éléments de commande d'achat comme objet principal et les événements de haut niveau comme événements de ce processus.
4. Lorsque vous appliquez vos modifications aux tableaux de bord, vous pouvez créer le graphique de processus et d'autres tableaux de bord basés sur le processus de haut niveau.

L'illustration suivante montre un exemple.

Remarque :

• La fonction AI_CLASSIFY renvoie des valeurs au format { “labels”: [“Create”] }. La :labels récupère la valeur ”Create” et la fonction to_varchar() supprime les guillemets voisines.
• Lorsqu'aucune des catégories ne semble correspondre, la valeur générée par la fonction AI_CLASSIFY reste null. Pour éviter que ces enregistrements ne soient exclus de l'ensemble de données, mappez les valeurs null à une constante (par exemple, "Unmapped") pour indiquer que ces activités n'ont pas été classées.

Exemple : classer les types de demande des clients

Les demandes des clients sont un exemple typique de données non structurées. Chaque type de requête nécessite une action suivante différente. Pour analyser plus efficacement les différents types de demandes dans les tableaux de bord, vous pouvez les catégoriser à l'aide de LLM, sans avoir besoin d'une intervention manuelle de l'utilisateur.

Le bloc de code suivant montre un exemple SQL sur la façon dont les requêtes peuvent être classées dans « Commentaire », « Question » ou « Réclamation ».

select
    Requests_input."Request_ID"
    Requests_input."Request",
    to_varchar(
        AI_CLASSIFY(
            Requests_input."Request",
            ['Feedback', 'Question', 'Complain']):labels[0])
    as "Request_classified"
from {{ ref('Requests_input') }} as Requests_input

Astuce : La classification des valeurs pour chaque enregistrement peut avoir un impact sur les performances d'ingestion. Pour optimiser le temps de traitement, envisagez de filtrer les tables sur lesquelles vous appliquez la fonction AI_CLASSIFY afin d'inclure uniquement les enregistrements pertinents pour votre analyse.

Vous pouvez ajouter les types de requêtes classées à l’application et aux tableaux de bord pour permettre une analyse plus agrégée. Cela fournit de meilleures informations par rapport à l'utilisation directe du texte de demande d'origine, qui est souvent unique pour chaque enregistrement et peut conduire à un grand nombre de valeurs distinctes.

L'illustration suivante montre un exemple de classification.

Analyse des sentiments

Cette section décrit comment utiliser les fonctions ENTITY_SENTIMENT et SENTIMENT dans un contexte Process Mining, y compris des exemples.

Vous pouvez appliquer l'analyse des sentiments à du texte non structuré pour classer si le contenu est positif ou négatif. Ce type d'analyse peut être utilisé, par exemple, pour :

• Analyser les commentaires pour améliorer les produits ou les services.
• Suivre l'évolution des sentiments au fil du temps pour la prise de décisions.

Deux types de fonctions d'analyse des sentiments sont disponibles.

• Utilisez la fonction ENTITY_SENTIMENT pour des résultats classés (par exemple, « Posif », « Négatif », « Neutre », « Mixé » ou « Inconnu »). Par défaut, l'entrée est analysée pour le sentiment général du texte. La sortie est renvoyée au format suivant :

  { "categories": [ { "name": "Overall", "sentiment": "positif" } ] }
  

• Utilisez la fonction SENTIMENT pour les résultats numériques (par exemple, un score de sentiment sur une échelle). La fonction SENTIMENT renvoie une valeur comprise entre -1 et 1, indiquant le degré de négativité ou de positivité dans le texte d'entrée. Vous pouvez utiliser ces valeurs de sentiment numériques dans les métriques de tableau de bord afin d'analyser le sentiment à différents niveaux d'agrégation.

Reportez-vous à la documentation officielle de Snowflake sur entité_Sentiment pour plus d'informations.

Exemple : commentaires des utilisateurs sur l'analyse des sentiments

Le bloc de code suivant montre un exemple SQL d'utilisation de l'analyse des sentiments pour les commentaires des utilisateurs.

select
    Feedback_input."Feedback_ID",
    Feedback_input."Feedback",
    to_varchar(
        SNOWFLAKE.CORTEX.ENTITY_SENTIMENT(
            Feedback_input."Feedback"):categories[0]:sentiment)
    as "Sentiment_category",
    SNOWFLAKE.CORTEX.SENTIMENT(
        Feedback_input."Feedback")
    as "Sentiment_value"
from {{ ref('Feedback_input') }} as Feedback_input

Par défaut, seul le sentiment global est déterminé. Si vous souhaitez spécifier des sujets spécifiques sur lesquels vous souhaitez obtenir le sentiment, par exemple « Prix » ou « Assistance », vous pouvez ajouter les catégories comme deuxième argument de la fonction ENTITY_SENTIMENT . La sortie sera une valeur de sentiment pour chacune des catégories spécifiées.

Pour extraire les valeurs correctes, vous devez ajuster la logique SQL. Au lieu de référencer category[0] (qui ne sélectionne que la première catégorie), modifiez la requête pour sélectionner les valeurs de sentiment des catégories d'intérêt spécifiques.

L'illustration suivante montre des exemples de résultats d'analyse des sentiments des commentaires des utilisateurs.