Usando funções LLM em transformações de dados

Observação:

Confira a documentação oficial do Snowflake sobre IA e ML do Snowflake para obter uma visão geral da inteligência artificial e dos recursos de machine learning do Snowflake.

Apenas os dados explícitos passados em chamadas de função são enviados para o LLM.

1. Os dados não saiem do ambiente do Snowflake.
2. Os dados não são retidos além do processamento e não são usados para treinamento.
3. Os contratos e a arquitetura do Snowflake são projetados para atender aos padrões de governança de dados empresariais.

Introdução

As funções LLM permitem processar texto não estruturado em saída categorizada para análise agregada em seus painéis. O uso de funções LLM elimina a necessidade de regex complexo no SQL, facilitando a configuração e adaptação de suas transformações com base em novos dados.

Consulte a documentação oficial do Snowflake no Cortex AISQL (incluindo funções LLM) para obter mais informações sobre o uso de funções LLM.

Aviso: o uso de funções LLM em seu SQL pode afetar significativamente o tempo de transformação. Por exemplo, a aplicação de uma função de classificação a 1 milhão de registros pode aumentar o tempo de processamento em pelo menos meia hora.

Exemplos de casos de uso de funções LLM em transformações de dados são:

• Função AI_CLASSIFY para classificação de dados. Consulte a documentação oficial do Snowflake em AI_CLASSIFY para obter mais informações.
• Função ENTITY_SENTIMENT para análise de sentimento. Consulte a documentação oficial do Snowflake em ENTITY_SENTIMENT para obter mais informações.

Observação: no caso improvável de você exceder seus limites de uso permitido para o uso de LLM, a UiPath® não impõe nenhuma restrição imediata, para que as operações do cliente possam continuar ininterruptas. Qualquer alteração neste pacote ou na oferta comercial será comunicada com antecedência para proporcionar uma experiência tranquila e perfeita.

Classificação

Esta seção descreve como usar a função AI_CLASSIFY em um contexto do Process Mining, incluindo exemplos.

Exemplo: análise de processo de alto nível

Os processos podem consistir em muitas atividades diferentes, algumas das quais podem ser muito semelhantes e podem ser mapeadas para categorias de nível superior. Esse tipo de mapeamento reduz o número de variantes do processo e permite a análise em um nível mais abstrata.

Por exemplo, em um processo Purchase-to-Pay, os eventos de aprovação podem ocorrer em diferentes níveis, como “Aprovar requisição de compra”, “Aprovar pedido nível 1”, “Aprovação do gerente” etc. Cada uma dessas atividades pode ser mapeada para uma atividade genérica "Aprovar".

Outro exemplo são os eventos de “Alteração”, como “Alterar preço”, “Alterar data de entrega” ou “Alterar fornecedor”. O mapeamento delas para uma única atividade “Change” reduz o número de caminhos no processo e simplifica a exibição do gráfico do processo.

O bloco de código a seguir mostra um exemplo de SQL sobre como aplicar a função AI_CLASSIFY para definir o processo de alto nível.

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 o primeiro argumento dessa função, forneça a coluna Atividade original da sua tabela de eventos. O segundo argumento deve ser uma lista de atividades de alto nível para as quais as atividades serão mapeadas. Neste exemplo, as atividades são mapeadas para "Criar", "Alterar", "Aprovar", "Concluir" ou "Cancelar".

Etapas para implementar a análise de processo de alto nível:

1. Crie um arquivo SQL separado em seu projeto, por exemplo High_level_events.sql, e adicione a lógica SQL de processo de alto nível a ele.
2. Adicione o High_level_events ao modelo de dados e configure a relação. Neste exemplo, os eventos de alto nível estão conectados à tabela de itens de ordem de compra com base no Purchase_order_item_ID.
3. Adicione um processo adicional com os itens de ordem de compra como objeto principal e os eventos de alto nível como os eventos para esse processo.
4. Ao aplicar suas alterações aos painéis, você pode criar o gráfico do processo e outros painéis com base no processo de alto nível.

A ilustração a seguir mostra um exemplo.

Observação:

• A função AI_CLASSIFY retorna valores no formato { “labels”: [“Create”] }. O :labels recupera o valor ”Create” e a função to_varchar() remove as aspas ao redor.
• Quando nenhuma das categorias parece ser uma boa correspondência, o valor gerado pela função AI_CLASSIFY permanece null. Para evitar que esses registros sejam excluídos do conjunto de dados, mapeie os valores null para uma constante (por exemplo, "Unmapped") para indicar que essas atividades não foram classificadas.

Exemplo: classificar os tipos de solicitação do cliente

As solicitações de clientes são um exemplo típico de dados não estruturados. Cada tipo de solicitação requer uma próxima ação diferente. Para analisar os diferentes tipos de solicitações de forma mais eficaz em painéis, é possível categorizá-los usando LLMs, sem a necessidade de intervenção manual do usuário.

O bloco de código a seguir mostra um exemplo de SQL sobre como as solicitações podem ser categorizadas em “Feedback”, “Pergunta” ou “Reclamação”.

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

Dica: a classificação de valores para cada registro pode afetar o desempenho da ingestão. Para otimizar o tempo de processamento, considere filtrar as tabelas nas quais você aplica a função AI_CLASSIFY para incluir apenas os registros relevantes para sua análise.

Você pode adicionar os tipos de solicitações classificados ao aplicativo e aos painéis para habilitar uma análise mais agregada. Isso fornece um insight maior em comparação com o uso direto do texto da solicitação original, que geralmente é exclusivo para cada registro e pode levar a um grande número de valores distintos.

A ilustração a seguir mostra um exemplo de classificação.

Análise de opinião

Esta seção descreve como usar as funções ENTITY_SENTIMENT e SENTIMENT em um contexto do Process Mining, incluindo exemplos.

Você pode aplicar a análise de sentimentos a textos não estruturados para classificar se o conteúdo é positivo ou negativo. Esse tipo de análise pode ser usado, por exemplo, para:

• Analise o feedback para melhorar produtos ou serviços.
• Acompanhe as tendências de sentimento ao longo do tempo para a tomada de decisões.

Há dois tipos de funções de análise de sentimento disponíveis.

• Use a função ENTITY_SENTIMENT para resultados categorizados (por exemplo, "Positivo", "Negativo", "Neutro", "Misto" ou "Desconhecido"). Por padrão, a entrada é analisada para o sentimento geral do texto. A saída é retornada no seguinte formato:

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

• Use a função SENTIMENT para resultados numéricos (por exemplo, uma pontuação de sentimento em uma escala). A função SENTIMENT retorna um valor entre -1 e 1, indicando o grau de negatividade ou positividade no texto de entrada. Você pode usar esses valores numéricos de sentimento em métricas do painel para analisar o sentimento em diferentes níveis de agregação.

Consulte a documentação oficial do Snowflake em ENTITY_SENTIMENT para obter mais informações.

Exemplo: feedback do usuário para análise de sentimento

O bloco de código a seguir mostra um exemplo de SQL sobre o uso da análise de sentimento para o feedback do usuário.

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

Por padrão, apenas o sentimento geral é determinado. Se você quiser especificar tópicos específicos sobre os quais deseja obter o sentimento, por exemplo, “Preço” ou “Suporte”, você pode adicionar as categorias como um segundo argumento para a função ENTITY_SENTIMENT . A saída será um valor de sentimento para cada um dos membros da categoria especificada.

Para extrair os valores corretos, você deve ajustar a lógica SQL. Em vez de fazer referência a category[0] (que seleciona apenas a primeira categoria), modifique a consulta para selecionar os valores de sentimento para as categorias específicas de interesse.

A ilustração a seguir mostra resultados de exemplo da análise de sentimento do feedback do usuário.