FILE型のご紹介：マルチモーダルデータに対応するネイティブな列型

データ資産には、構造化されたテーブル、メトリクス、トランザクションログだけでなく、契約書、製品画像、通話録音、ビデオなど、はるかに多くのデータが含まれています。AIは現在、こうした非構造化データをクエリや分析が可能なものに変換できますが、それには他のすべてのデータと同様にガバナンスが適用され、管理されている必要があります。

本日、FILE型のベータ版を発表します。これは、非構造化データをテーブル内のネイティブでガバナンスが適用された列として保存する、新しい列タイプです。FILEを使用すると、非構造化データはAIに対応した状態（AI-ready）になります。別のシステムに分離されることなく、構造化データとまったく同じ場所でクエリ可能、安全、かつ管理された状態になります。FILEのメリットは以下の通りです。

• 統合されたガバナンス。 標準的なテーブルに適用するのとまったく同じ、きめ細かなアクセス制御とセキュリティポリシーを生ファイルに適用できます。
• コンプライアンスの自動化。 FILEを含む行を削除すると、オブジェクトストレージ内のファイルのバイナリも削除されるため、GDPRの"忘れられる権利"への対応が容易になります。
• SQLとPythonのサポート。 通常の列と同じように、非構造化ファイルに対して標準のSQLやPython UDFを直接実行できます。また、マテリアライズドビューを作成してAI関数を段階的に実行することも可能です。
• 設計による高パフォーマンス。 FILE列には、重いファイルのバイナリではなく軽量なポインタのみが保存され、クエリが明示的に必要とする場合にのみ実際のファイルコンテンツが処理されます。

FILEは、私たちがオープンに推進しているイノベーションです。コミュニティと協力して、Parquet、Delta Lake、Apache Iceberg、Apache Sparkに直接サポートを組み込み、エコシステム全体で活用できるように取り組んでいます。これにより、マルチモーダルデータのオープン性とポータビリティが維持され、特定のベンダーやモデルプロバイダーにロックインされることがなくなります。

FILE型でできること

現在、データチームはビジネスインパクトをもたらすために、マルチモーダルデータ上にアプリケーションを構築したいと考えています。

• 契約書、ポリシー、研究資料を対象とした企業向けドキュメントアシスタント：事務書類をインタラクティブなナレッジベースに変換します。
• 製品画像を対象とした外観検査：すべてを目視で確認する代わりに、大規模に欠陥を検出します。
• 音声録音を対象とした通話分析：既存の会話から、顧客が成約または解約する理由を明らかにします。
• イベントを対象としたビデオ理解：何時間もの映像を検索およびクエリ可能にします。
• テキストだけでなく、実際の証拠を引用して行動する必要があるエージェント向けのマルチモーダル検索。

FILEは、探索的分析からモデルのトレーニング、リアルタイムでのエージェントへのデータ提供に至るまで、マルチモーダルデータのライフサイクル全体における摩擦を軽減します。これを実証するために、1つの例を紹介します。読み進めながら、ご自身のユースケースに置き換えて考えてみてください。

自動運転企業のCEOからの鋭い質問から例を始めましょう。

「理由のない停車の回数を減らすことはできないでしょうか？自動運転車が明らかな理由もなく停車すると、乗客はサービスへの信頼を失ってしまいます」

これに対処するために必要なデータは、各自動運転車からキャプチャされた非構造化のドライブレコーダーのビデオです。CEOの要望に対応するために、FILEがどのようにそのデータをAIに対応させるかをご紹介します。

1. まず、FILEの列を作成します。ドライブレコーダーのビデオが保存されているストレージボリュームから読み取る、FILE列を持つテーブルを作成します。

図1：ビデオを保存するFILE列を示す概念図

1. FILE型として定義された footage 列を追加し、オブジェクトストレージ内の各クリップを行にマッピングします
2. テーブルには、構造化されたメタデータの隣にそのFILE列が保持されるようになります
3. これらのドライブレコーダーのクリップの1つには、車が明確な理由なく停車している様子が映っています。これは、私たちが発見して調査する必要がある事例の1つです

以下は、FILE列を持つテーブルを作成するための構文例です。FILEを使用したファイル処理パイプラインの一連の流れを試すには、サンプルノートブックを含む付属のドキュメントを参照してください。

1. ドライブレコーダーのビデオを高いパフォーマンスで処理します。 列がFILE型として定義されているため、他の列と同じように操作できます。組み込みのAI関数や、独自のPython UDFを利用できます。ここでは、UDFが各クリップからフレームをサンプリングして画像の新しいFILE列に格納し、物体検出モデルが既存のメタデータにさらに1つの列を追加して、車の前方に実際に停車が必要な障害物があるかどうかを示します。

図2：処理されたビデオFILEを示す図

1. サンプリングされたフレームは、同様にFILE型として定義された新しいframe列に格納されます
2. そのFILE列に対して直接関数を実行し、各フレームの hazard 値を取得します
3. 停車したクリップは hazard = none を返します。これが私たちが求めているインサイトです

FILEを使用するメリットは、クエリのパフォーマンスを低下させることなく、数ギガバイトのビデオを簡単に処理できる点です。FILE列は軽量な参照を保持するため、エンジンはそれらを必要とするステップでのみ実際のバイトをプルします。これとは対照的に、テーブル内に生のバイナリをエンコードすると、すべての操作で大きなバイナリがエンジンのメモリを経由することになり、パフォーマンスが低下します。

1. CEOの質問に答えます。 これにより、エージェントはマルチモーダルデータ資産全体を推論できるようになります。抽出された情報を構造化された走行データと結合し、前方に障害物がないにもかかわらず車が急停車したすべてのビデオを表面化させます。

図3：マルチモーダルテーブルのクエリを示す図

1. 1つのクエリで、抽出された hazard 列を構造化された走行データと結合し、前方の道路に障害物がない状態で車が完全に停車したビデオをフィルタリングします
2. ここから、機械学習チームはトレーニングセットを簡単にキュレートして、自動運転システムを向上させることができます

グラウンドトゥルース（正解データ）としてのオリジナルのビデオフレーム、埋め込み（embedding）、検出された障害物などの抽出されたインサイト、および走行メタデータ（速度、タイムスタンプなど）がすべて並んで1つの行に収まっているため、エージェントは質問に対して迅速かつ正確に回答できるようになります。

お客様がこのようなユースケースを解決するために、ファイルへのパスを含むURL文字列をテーブルに保存しようとするのをよく見かけます。しかし、これらの文字列は、フォルダレベルの広範な権限という、まったく異なるシステムによって管理されています。そのため、1つのデータセットに対して2つの権限モデルを維持することを余儀なくされ、パスを保護する行フィルターは、その先にあるビデオを保護するためには何の役にも立ちません。

私たちは、FILEをUnity Catalogに統合することで、このガバナンスの課題を解決しました。Unity Catalogでは、FILEも行および列レベルのアクセス制御、および属性ベースのアクセス制御（ABAC）によって保護され、適切なユーザーのみがデータにアクセスできるようになります。

現在チームが直面しているもう1つの問題は、非構造化データのライフサイクルの調整です。誰かがオブジェクトストレージ内のビデオを削除した場合、テーブルはストレージのライフサイクルポリシーを認識せず、テーブルとストレージは互いについて何も知らないため、何も指していない参照だけが残されてしまいます。

FILEを使用すると、ビデオのライフサイクルはデータセット内のその行と連動します。行を削除すると、データとその参照の同期が維持されるため、孤立したファイルやコンプライアンスのギャップは発生しません。これにより、チームは「忘れられる権利」の要求（GDPRなど）や、データのすべてのコピーを手動で探し回る手間に煩わされることなく、迅速に作業を進めることができます。

FILEはすでにお使いのツールと統合されています

FILEにより、構造化データですでに使用しているものと同じオープンな基盤、ガバナンスモデル、AIスタックを、非構造化データでも活用できるようになります。

• 簡単に取り込むか、その場で参照する。ポイント＆クリックのLakeflowコネクタを使用して、SharePointやGoogle Driveなどのソースに直接接続できます。また、データがすでにクラウドストレージやオンプレミスにある場合、FILE列はデータを移動することなく、その場所にあるデータを直接参照できます。
• Spark Declarative Pipelinesでマルチモーダルパイプラインを構築する。ドキュメントを再処理するたびに高コストなモデルのAPI呼び出しが発生する可能性があるため、非構造化データをインクリメンタル（増分）に処理することがこれまで以上に重要になっています。また、従来のデータパイプラインと同様に、1つのファイルが失敗したからといって、エンジニアが午前3時に叩き起こされるようなことがあってはなりません。FILEとSDPを使用すると、必要なマルチモーダルテーブルを宣言するだけで、DAGが自動的に解決されます。取り込みはインクリメンタルに行われるため、新しいドキュメントのみが処理されます。再試行とリカバリ機能が組み込まれているため、一時的な障害が発生しても最初からやり直す必要はありません。
• クラス最高のAI関数を含む、あらゆるモデルを使用して非構造化データを処理する。FILE列に対して直接、AI_PARSE_DOCUMENT、AI_QUERY、および独自のUDFを実行することで、生のドキュメント、画像、ビデオを、エージェントやアナリストがすでにクエリしている構造化された列に変換できます。
  また、Databricksは最初からマルチクラウド環境向けに構築されているため、FILEはクラウドプロバイダー間で自然に適合し、チームに1つの統合されたレイクハウスを提供します。

FILEタイプの利用を開始する

FILEタイプは現在ベータ版で提供されており、皆様からのフィードバックをお待ちしております。本日お試しいただける機能の全リストとステップバイステップのガイダンスについては、こちらのベータ版ドキュメントをご覧ください。

これはFILEタイプの始まりに過ぎません。AIプロジェクトを加速させる、以下のような魅力的な機能のロードマップを近日公開予定です。

• 追加コストなしで、より迅速に実験を行う。データセットでのトレーニングや反復のために、テラバイト単位の非構造化データを複製する必要はありません。FILEを使用すると、基盤となるバイナリをコピーすることなくデータのバージョン管理やクローン作成が可能になり、複数のテーブルから同時に同じバイトを参照できます。例えば、機械学習エージェントが実際のデータ上で隔離されたサンドボックスを立ち上げ、リネージによって、あらゆるデグラデーションの原因となった正確なアセットまで遡って追跡することができます。
• データセットをPyTorchに直接ストリーミングする。FILEデータに対してSQLクエリを実行し、その結果をネイティブのPyTorch Datasetsに即座にロードすることで、追加のデータ準備なしでGPU対応のテンソルをトレーニングループに直接配信できます。
• テーブルを書き換えることなく特徴量エンジニアリングを行う。元の非構造化データの大きなバイナリを含むテーブル全体を書き換えることなく、抽出されたテキスト、埋め込み（embedding）、分類などの派生列を追加またはバックフィルできます。
• 分析とサービングの両方で非構造化データのコピーを1つに共有する。テーブル自体にベクトル、全文、ポイントルックアップのインデックスを作成し、テーブルから直接検索および取得できるため、取得レイヤーと信頼できる唯一の情報源（Source of Truth）が同じレイクハウスになります。

DatabricksにおけるAIワークロードの最適化方法について詳しくお知りになりたい場合は、Databricksのアカウントチームまでお問い合わせください。

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