データ変換で LLM 関数を使用する

注:

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.

はじめに

LLM 関数を使用すると、非構造化テキストをカテゴリの出力に処理して、ダッシュボードで集計して分析できます。LLM 関数を使用すると、SQL で複雑な正規表現を使用する必要がなくなり、新しいデータに基づいて変換を簡単に設定および適応させることができます。

LLM 関数の使用について詳しくは、 Cortex AISQL (LLM 関数を含む) に関する Snowflake の公式ドキュメントをご覧ください。

警告： SQL で LLM 関数を使用すると、変換に大きく影響する可能性があります。たとえば、分類関数を 100 万件のレコードに適用すると、処理時間が少なくとも 30 分長くなる可能性があります。

データ変換における LLM 関数のユース ケースの例を次に示します。

• AI_CLASSIFY データを分類するための関数です。詳しくは、 AI_CLASSIFY に関する Snowflake の公式ドキュメントをご覧ください。
• ENTITY_SENTIMENT センチメント分析のための関数です。詳しくは、 ENTITY_SENTIMENT に関する Snowflake の公式ドキュメントをご覧ください。

手記： 万が一、LLM の使用に関するフェアユースの制限を超えた場合でも、UiPath® は直ちに制限を課さないため、顧客の業務を中断することなく継続できます。この変更または商用サービスに対する変更は、スムーズでシームレスなエクスペリエンスを提供するために、事前に通知されます。

分類

このセクションでは、プロセス マイニングのコンテキストで AI_CLASSIFY 関数を使用する方法を例を交えて説明します。

例: ハイレベル プロセスの分析

プロセスはさまざまなアクティビティで構成され、その一部は非常によく似ており、上位レベルのカテゴリにマッピングできます。この種類のマッピングにより、プロセス バリアントの数が減り、より抽象的なレベルでの分析が可能になります。

たとえば Purchase-to-Pay プロセスでは、承認イベントは「購買依頼の承認」、「注文レベル 1 の承認」、「マネージャーの承認」など、さまざまなレベルで発生する可能性があります。これらの各アクティビティは、汎用の「承認」アクティビティにマッピングできます。

別の例としては、「Change price」、「Change Delivery Date」、「Change supplier」などの「Change」イベントがあります。これらを単一の「変更」アクティビティにマッピングすると、プロセス内のパスの数が減り、プロセス グラフの表示が簡素化されます。

次のコード ブロックに、高レベル プロセスを定義するための AI_CLASSIFY 関数の適用方法を示す SQL の例を示します。

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

この関数の最初の引数として、イベント テーブルの元の Activity 列を指定します。2 番目の引数は、アクティビティをマップする高レベルのアクティビティのリストである必要があります。この例では、アクティビティは「作成」、「変更」、「承認」、「完了」、「キャンセル」にマップされています。

高レベルのプロセス分析を実装する手順

1. プロジェクト内に別の SQL ファイル ( High_level_events.sqlなど) を作成し、ハイレベル プロセスの SQL ロジックをそのファイルに追加します。
2. データ モデルに High_level_events を追加し、リレーションを設定します。この例では、 Purchase_order_item_IDに基づいて上位レベルのイベントが発注品目テーブルに接続されています。
3. 発注品目をメイン オブジェクトとして、ハイレベルなイベントをこのプロセスのイベントとして、プロセスを追加します。
4. ダッシュボードに変更を適用するときに、プロセス グラフや、プロセスの概要に基づいたその他のダッシュボードを作成できます。

次の図に例を示します。

注:

• AI_CLASSIFY 関数は、{ “labels”: [“Create”] }の形式で値を返します。:labelsは値”Create”を取得し、to_varchar() 関数は周囲の引用符を削除します。
• どのカテゴリも適切に一致しないと思われる場合、 AI_CLASSIFY 関数によって生成される値は nullのままです。これらのレコードがデータセットから除外されないようにするには、 null 値を定数 (例: "Unmapped") にマッピングして、これらのアクティビティが分類されなかったことを示します。

例: 顧客のリクエストの種類を分類する

顧客の要求は、非構造化データの典型的な例です。リクエストの種類ごとに、必要な次のアクションは異なります。ダッシュボードでさまざまなリクエストの種類をより効果的に分析するには、LLM を使用してそれらのリクエストの種類を分類します。ユーザーが手動で介入する必要はありません。

以下のコード ブロックに、要求を「フィードバック」、「質問」、または「苦情」にどのように分類するかについての SQL の例を示します。

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

先端： 各レコードの値を分類すると、取り込みのパフォーマンスに影響が出る場合があります。処理時間を最適化するには、 AI_CLASSIFY 関数を適用するテーブルをフィルター処理して、分析に関連するレコードのみを含めることを検討してください。

分類されたリクエストの種類をアプリとダッシュボードに追加して、より集約した分析を行うことができます。これにより、元の要求テキストを直接使用する場合と比較して、洞察を深めることができます。元の要求テキストは多くの場合、レコードごとに一意であり、多数の個別の値につながる可能性があります。

分類の例を次に示します。

Sentiment Analysis (感情分析)

このセクションでは、Process Mining のコンテキストで ENTITY_SENTIMENT 関数と SENTIMENT 関数を使用する方法を例を交えて説明します。

非構造化テキストに感情分析を適用して、コンテンツが肯定的か否定的かを分類できます。このタイプの分析は、たとえば、以下の目的に使用できます。

• フィードバックを分析して製品やサービスを改善します。
• 感情の傾向を経時的に追跡して意思決定に役立てる

感情分析関数には次の 2 種類があります。

• カテゴリの結果 (例: "Positive"、"Negative"、"Neutral"、"Mixed"、"Unknown") には ENTITY_SENTIMENT 関数を使用します。既定では、入力 テキストの全体的な感情を分析します。出力は次の形式で返されます。

  {
    「カテゴリ」: [
      {
        "name": "全体",
        "sentiment": "肯定的"
      }
    ]
  }
  

• 数値の結果 (例: スケール上の感情スコア) には SENTIMENT 関数を使用します。SENTIMENT 関数は、入力テキストの否定性または肯定性の度合いを示す -1 から 1 の間の値を返します。これらの感情の数値をダッシュボードのメトリックで使用すると、さまざまなレベルの集計にわたって感情を分析できます。

詳しくは、 ENTITY_SENTIMENT に関する Snowflake の公式ドキュメントをご覧ください。

例: 感情分析のユーザーフィードバック

次のコード ブロックに、ユーザー フィードバックに感情分析を使用する SQL の例を示します。

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

既定では、全体的な感情のみが決定されます。「価格」や「サポート」など、感情を取得する特定のトピックを指定する場合は、 ENTITY_SENTIMENT 関数の 2 番目の引数としてカテゴリを追加できます。出力は、指定したカテゴリそれぞれの感情値になります。

正しい値を抽出するには、SQL ロジックを調整する必要があります。category[0] (最初のカテゴリのみを選択する) を参照する代わりに、関心のある特定のカテゴリの感情値を選択するようにクエリを変更します。

ユーザーからのフィードバックの感情分析の結果の例を次に示します。