Uso de funciones LLM en transformaciones de datos

Nota:

Check out the official Snowflake documentation on Snowflake AI and ML for an overview of Snowflake's artificial intelligence and machine learning capabilities.

Only the explicit data passed in function calls is sent to the LLM.

1. Data does not leave the Snowflake environment.
2. Data is not retained beyond processing and is not used for training.
3. Snowflake contracts and architecture are designed to meet enterprise data governance standards.

Introducción

Las funciones de LLM te permiten procesar texto no estructurado en salida categórica para el análisis agregado en tus paneles. El uso de funciones LLM elimina la necesidad de expresiones regulares complejas en SQL, lo que facilita la configuración y adaptación de tus transformaciones en función de los nuevos datos.

Consulta la documentación oficial de Snowflake sobre Cortex AISQL (incluidas las funciones LLM) para obtener más información sobre el uso de las funciones LLM.

Advertencia: El uso de funciones LLM en tu SQL puede afectar significativamente al tiempo de transformación. Por ejemplo, aplicar una función de clasificación a 1 millón de registros puede aumentar el tiempo de procesamiento en al menos media hora.

Ejemplos de casos de uso de funciones LLM en transformaciones de datos son:

• Función AI_CLASSIFY para la clasificación de datos. Consulta la documentación oficial de Snowflake en AI_CLASSIFY para obtener más información.
• Función ENTITY_SENTIMENT para el análisis de sentimientos. Consulta la documentación oficial de Snowflake sobre ENTITY_SENTIMENT para obtener más información.

Nota: En el improbable caso de que superes tus límites de uso justo para el uso de LLM, UiPath® no impone ninguna restricción inmediata, por lo que las operaciones del cliente pueden continuar sin interrupciones. Cualquier cambio en esta oferta o en la oferta comercial se comunicará con antelación, para proporcionar una experiencia fluida y sin problemas.

Clasificación

En esta sección se describe cómo utilizar la función AI_CLASSIFY en un contexto de Process Mining, incluidos ejemplos.

Ejemplo: análisis de proceso de alto nivel

Los procesos pueden constar de muchas actividades diferentes, algunas de las cuales pueden ser muy similares y pueden asignarse a categorías de nivel superior. Este tipo de asignación reduce el número de variantes del proceso y permite el análisis a un nivel más abstracto.

Por ejemplo, en un proceso Purchase-to-Pay, los eventos de aprobación pueden ocurrir en diferentes niveles, como "Aprobar solicitud de compra", "Aprobar orden de nivel 1", "Aprobación del administrador", etc. Cada una de estas actividades puede asignarse a una actividad genérica "Aprobar".

Otro ejemplo son los eventos de "Cambiar", como "Cambiar precio", "Cambiar fecha de entrega" o "Cambiar proveedor". Asignarlos a una sola actividad "Cambiar" reduce el número de rutas en el proceso y simplifica la vista del gráfico de proceso.

El siguiente bloque de código muestra un ejemplo de SQL sobre cómo aplicar la función AI_CLASSIFY para definir el proceso de alto nivel.

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

Como primer argumento de esta función, proporciona la columna Actividad original de tu tabla de eventos. El segundo argumento debe ser una lista de actividades de alto nivel a las que se asignarán las actividades. En este ejemplo, las actividades se asignan a "Crear", "Cambiar", "Aprobar", "Completar" o "Cancelar".

Pasos para implementar el análisis de procesos de alto nivel:

1. Crea un archivo SQL independiente en tu proyecto, por ejemplo High_level_events.sql, y añádele la lógica SQL del proceso de alto nivel.
2. Añade High_level_events al modelo de datos y configura la relación. En este ejemplo, los eventos de alto nivel están conectados a la tabla de elementos de la orden de compra en función de Purchase_order_item_ID.
3. Añade un proceso adicional con los elementos de la orden de compra como objeto principal y los eventos de alto nivel como eventos para este proceso.
4. Al aplicar tus cambios a los paneles, puedes crear el gráfico de proceso y otros paneles basados en el proceso de alto nivel.

La siguiente ilustración muestra un ejemplo.

Nota:

• La función AI_CLASSIFY devuelve valores en el formato { “labels”: [“Create”] }. :labels recupera el valor ”Create” y la función to_varchar() elimina las comillas que lo rodean.
• Cuando ninguna de las categorías parece ser una buena coincidencia, el valor generado por la función AI_CLASSIFY sigue siendo null. Para evitar que estos registros se excluyan del conjunto de datos, asigna los valores null a una constante (por ejemplo, "Unmapped") para indicar que estas actividades no se clasificaron.

Ejemplo: clasificar tipos de solicitudes de clientes

Las solicitudes de los clientes son un ejemplo típico de datos no estructurados. Cada tipo de solicitud requiere una siguiente acción diferente. Para analizar los diferentes tipos de solicitudes de forma más eficaz en los paneles, puedes categorizarlos utilizando LLM, sin necesidad de la intervención manual del usuario.

El siguiente bloque de código muestra un ejemplo de SQL sobre cómo se pueden categorizar las solicitudes en "Comentario", "Pregunta" o "Reclamación".

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

Consejo: Clasificar valores para cada registro puede afectar al rendimiento de la ingestión. Para optimizar el tiempo de procesamiento, considera filtrar las tablas en las que aplicas la función AI_CLASSIFY para incluir solo los registros relevantes para tu análisis.

Puedes añadir los tipos de solicitudes clasificadas a la aplicación y los paneles para permitir un análisis más agregado. Esto proporciona una mayor comprensión en comparación con el uso directo del texto de la solicitud original, que a menudo es único para cada registro y puede dar lugar a un gran número de valores distintos.

La siguiente ilustración muestra un ejemplo de clasificación.

Análisis de sentimiento

Esta sección describe cómo utilizar las funciones ENTITY_SENTIMENT y SENTIMENT en un contexto de Process Mining, incluidos ejemplos.

Puedes aplicar el análisis de sentimientos al texto no estructurado para clasificar si el contenido es positivo o negativo. Este tipo de análisis puede utilizarse, por ejemplo, para:

• Analizar los comentarios para mejorar los productos o servicios.
• Realice un seguimiento de las tendencias de sentimiento a lo largo del tiempo para la toma de decisiones.

Hay dos tipos de funciones de análisis de sentimiento disponibles.

• Utiliza la función ENTITY_SENTIMENT para resultados categóricos (por ejemplo, "Positivo", "Negativo", "Neutro", "Mixto" o "Desconocido"). De forma predeterminada, la entrada se analiza en busca de la opinión general del texto. La salida se devuelve en el siguiente formato:

  { "categories": [ { "name": "overall", "sentiment": "positive" } ] }
  

• Utiliza la función SENTIMENT para resultados numéricos (por ejemplo, una puntuación de sentimiento en una escala). La función SENTIMENT devuelve un valor entre -1 y 1, que indica el grado de negatividad o positividad en el texto de entrada. Puedes utilizar estos valores de opinión numéricos en las métricas del panel para analizar la opinión en diferentes niveles de agregación.

Consulta la documentación oficial de Snowflake sobre ENTITY_SENTIMENT para obtener más información.

Ejemplo: comentarios de los usuarios sobre el análisis de sentimientos

El siguiente bloque de código muestra un ejemplo de SQL sobre el uso del análisis de sentimientos para los comentarios de los usuarios.

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

De forma predeterminada, solo se determina la opinión general. Si quieres especificar temas específicos sobre los que quieres obtener la opinión, por ejemplo, "Precio" o "Soporte", puedes añadir las categorías como segundo argumento a la función ENTITY_SENTIMENT . El resultado será un valor de sentimiento para cada una de las categorías especificadas.

Para extraer los valores correctos, debes ajustar la lógica SQL. En lugar de hacer referencia a category[0] (que solo selecciona la primera categoría), modifica la consulta para seleccionar los valores de sentimiento para las categorías específicas de interés.

La siguiente ilustración muestra resultados de ejemplo del análisis de opinión de los comentarios de los usuarios.