データウェアハウスでのAI_Functionsの活用：主なユースケース

多くの組織では、データウェアハウスに構造化データが保持され、非構造化データはデータレイクに保管されています。これは、構造化データを大規模に消費し、日々決まったレポートを提供する分析ワークロードにとってはうまく機能します。

しかし、AIワークロードには異なるインプットが必要です。AIモデルは、レビュー、サポートチケット、PDFなどの非構造化データを解析し、それらを構造化データと組み合わせてモデルのトレーニング、構築、サービングを行う必要があります。そのため、サポートチケットのセンチメントを分析したいアナリストは、行データを外部サービスに送信し、予測を待ち、手作業でテーブルに結合し直さなければなりません。これでは処理が遅く、スキーマが変更されると破損し、不要なセキュリティやガバナンスのリスクが生じます。

AI Functionsは、データを別のAI環境に移動させるのではなく、AIをデータに直接もたらすことでこの問題を解決します。標準的なSQLクエリ内でモデルを呼び出すため、推論プロセス全体を既存のパイプラインとUnity Catalogのガバナンス内に維持できます。このアーキテクチャは、データウェアハウスでのAIの活用方法を根本から変えます。

• デフォルトでのガバナンス： AI FunctionsはUnity Catalogの権限を尊重するため、データは安全かつプライベートに保たれます。モデルは、明示的に許可されたデータにのみアクセスします。
• SQLネイティブなシンプルさ： SELECT文を書くことができれば、AIを活用した構築が可能です。Databricksがプランニング、並列化、再試行などの複雑な処理を管理するため、クラスター管理や外部のオーケストレーションを心配する必要はありません。1行に対する推論と同様に、数百万行に対する推論も簡単に実行でき、同じクエリを書き直すことなくスケールできます。
• 統合された課金： 異なるダッシュボードを突き合わせる複雑さを解消します。AIの使用状況は、標準的なDatabricks SQLウェアハウスのコストと並んで、system.billing.usageに表示されます。
• 特化型関数： より低コストで優れた結果を得られます。ai_classify、ai_extract、ai_translate、およびai_parse_documentなどのタスク固有の関数を使用することで、汎用的な推論に過剰なコストを支払うことなく、特定のジョブに合わせて調整されたモデルを活用できます。

これらのAI関数は、ノートブック、Lakeflow Spark Declarative Pipelines、Workflowなど、Databricks上のどこからでも使用できます。しかし、このブログ記事では、特にDatabricks Lakehouseからこれらの関数を呼び出すことに焦点を当てます。以下のユースケースでは、データウェアハウス外から取得した、またはGenAI対応の関数を通じて自身で生成した非構造化データと、データウェアハウス内の構造化データを組み合わせる必要があるワークロードに、これらのAI関数を統合する方法を紹介します。

ユースケース1：ドキュメントインテリジェンス（生ファイルから構造化された行へ）

ai_parse_documentは、PDFや画像などの生のバイナリファイルコンテンツを読み取り可能なテキストに変換する取り込みブリッジとして機能します。解析が完了すると、ai_extractが特定のキーと値の詳細な抽出を処理します。この組み合わせアプローチにより、スキーマ変更時に破損しやすい、不安定なカスタムOCRパイプラインやサードパーティの解析サービスが不要になります。

このユースケースでは、請求書が含まれるDatabricksボリュームにai_parse_documentを指定します。これらの請求書が解析されると、AI parse documentが結果をJSON形式で生成し、それがai_extract関数に渡されます。この関数で、請求書から抽出したいエンティティを定義します。その結果、請求書から抽出したいフィールドを持つ構造化テーブルが得られます。

リネージは、単一のクエリプラン内で生のPDFから抽出された行まで実行されるようになります。これまで手作業で構築されていたブリッジ（PythonのOCRサービス、LLMの呼び出し、JSONのフラット化ステップ）はすべて、クエリ内に統合されます。

デモノートブック：ドキュメントインテリジェンス

ユースケース2：顧客フィードバックのセンチメント分析

ai_classify関数はゼロショット分類を実行し、モデルのトレーニングを必要とせずに、自由形式のテキストフィードバックをユーザー定義の特定のラベルセットにマッピングします。このプロセスにより、混沌とした非構造化テキストがガバナンスの効いたクエリ可能な列に変換され、センチメントやトピックのデータをBIダッシュボードや経営陣向けレポートですぐに利用できるようになります。

この例では、bronze.nps_responsesテーブルの顧客レビューを、positive（ポジティブ）、negative（ネガティブ）、neutral（ニュートラル）、mixed（混在）に分類します。

デモノートブック：センチメント分析

ユースケース3：多言語データのインライン翻訳

ai_translateを使用すると、クエリレイヤー内で多言語データを単一のターゲット言語に直接正規化できます。これにより、データのサイロ化や断片化を防ぎ、英語のみのスライスを処理するのではなく、下流のすべての分析（分類や抽出を含む）をグローバルデータセット全体に対して同時に実行できるようになります。

この例では、さまざまな顧客レビューからセンチメントを抽出し、それらを英語に翻訳します。

デモノートブック：翻訳と正規化

ユースケース4：大規模な分類とルーティング

業務効率化に焦点を当てたai_classifyは、サポートチケットや通話の文字起こしなどの自由形式の入力を、実用的なカテゴリに変換します。取り込み時に入力されたフィードバックの意図と緊急度を特定することで、適切なチームや自動応答システムへの自動化されたインテリジェントなルーティングを可能にします。

以下のユースケースでは、テーブルからさまざまなサポートチケットを取り込み、ai_classifyを使用してユーザーの意図とチケットの緊急度を判定します。

デモノートブック：分類とルーティング

ユースケース 5：ai_extract を使用した営業通話の構造化データ抽出

ai_extract関数は、営業通話の書き起こし（トランスクリプト）などの長文コンテンツから半構造化情報をマイニングし、ナラティブテキスト（語り口のテキスト）を個別の構造化フィールドに変換するように設計されています。これにより、定性的な情報を BI ツールに直接取り込むことができ、会話の内容を商談フェーズやリスクフラグといったクエリ可能な指標に効果的に変換できるため、大きな価値をもたらします。

このユースケースでは、長い書き起こしデータをマイニングして、次のステップ、商談フェーズ、リスクフラグ、およびリスクの理由を特定し、営業担当者が書き起こし元のミーティング結果に基づいて具体的なアクションを取れるようにします。

デモノートブック：営業通話からのデータ抽出

ユースケース 6：ai_query を使用した生成的なドラフト作成

ai_queryは最も汎用的な関数であり、他の関数の基盤となるものです。アクセス権を持つ任意のDatabricksがホストする基盤モデル（Foundation Model）のサービングエンドポイントにプロンプトを送信し、各行に対するモデルの回答を取得できます。

このユースケースでは、ai_query を使用して、更新の準備が整っているアカウントを示す架空の gold.renewal_signals テーブル内のすべての顧客アカウントに対して、更新案内のアプローチメールのドラフトを作成できます。

プロンプトを自分で記述するため、モデルにできることであれば何でも実行できます。そのため、より特化した関数では対応できないケースを処理するのに適しています。

デモノートブック：生成的なドラフト作成

本番環境向けのプロのヒント

• 初日からジョブにタグを付ける：これにより、AI Functions のコストを適切なジョブに紐付けることができます
• まずはタスク固有の関数を試す：ai_classify、ai_extract、ai_parse_document、ai_translate のいずれも適合しない場合にのみ、ai_query を使用します
• 構造化出力を要求する：ai_query で構造化出力を得るには、responseFormat を使用します。DDL STRUCT スキーマを渡すと、生の文字列ではなく型定義されたフィールドが返されます。JSON-schema や json_object フォーマットは、引き続き JSON 文字列を返します。
• モデルの選択は意図を持って行う：すべての基盤モデルには、コスト、パフォーマンス、サポートされる入力フォーマットなどのトレードオフがあります。どのユースケースにどのモデルを選択するか、意図を持って決定するようにしてください
• スケールアップする前にサンプリングする：少なくとも 10,000 行を実行して出力を確認し、その後に残りを実行します。コストと精度のトレードオフは、ユースケースごとに異なります。
• プロンプトをコードとして扱う：バージョン管理を行い、プルリクエストでレビューし、コメントを記述します。このワークフローにおいて、プロンプトはビジネスロジックを含む変換処理です

これがデータウェアハウス戦略にとって何を意味するか

6つのユースケースすべてに共通するテーマは同じです。AI は、ウェアハウスの他の部分と同じ場所で実行されます。つまり、1つのプラットフォーム、1つのガバナンスモデル、1つの請求、1つのパイプラインセットです。既存の SQL ETL の任意の行に、ホスト用のシステムを立ち上げることなく AI ステップを組み込むことができ、これまで個別にデータの翻訳、スコアリング、分類を行っていた各 Python スクリプトは、1行のコードに置き換える候補になります。

まずは1つの列から始めてみましょう。現在のサービスが最も不安定なワークロードを選択し、それを SELECT 文として書き換え、10,000 行で実行して、返ってくる結果を確認します。簡単なスプリントの後、それが適しているかどうかがわかります。そして、データを外部に送信して利用するためだけに発生していた余分なオーバーヘッドコストを支払う必要はなくなります。

デモノートブック

各ノートブックには、インラインのサンプルデータ、ステップバイステップの SQL、および期待される出力が含まれています。

• ユースケース 1：生成的なドラフト作成
• ユースケース 2：ドキュメントインテリジェンス
• ユースケース 3：感情分析
• ユースケース 4：翻訳と正規化
• ユースケース 5：分類とルーティング
• ユースケース 6：営業通話からのデータ抽出
• すべてのノートブック

次におすすめのコンテンツ

• AI Functions ドキュメント
• AI Functions の価格
• Databricks Lakehouse とは

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事