翻訳:Junichi Maruyama. - Original Blog Link
どのデータサイエンス組織と話しても、高品質なAIモデルを構築するための最大の課題はデータへのアクセスと管理であると、ほぼ全員が口を揃えて言うだろう。長年にわたり、実務家は実験と開発を加速させるために様々なテクノロジーと抽象化を利用してきた。ここ数年、フィーチャーストアは、機械学習のためにデータを整理し準備する方法として、実務家の間でますます普及している。2022年初頭、Databricksはフィーチャーストアの一般提供を開始しました。この夏、Databricks Unity Catalogのネイティブ機能としてフィーチャーエンジニアリングと管理を導入できることを嬉しく思います。これは、AIデータをよりシンプルに管理する方法の大きな進化を意味します。この進化は、フィーチャー管理とクラス最高のデータカタログを一体化させ、フィーチャーを作成し、それらを使用してモデルをトレーニングし、サービスを提供するプロセスを簡素化し、安全にします。
フィーチャーストアは、2つの主要な要件を満たすように設計されたカタログの一種です。それは、MLデータの容易な発見と利用を促進すること、そして、安定した高品質なデータを高性能なモデル学習・提供システムが容易に利用できるようにすることです。フィーチャーストアは、データサイエンティストが組織で利用可能な新しいフィーチャーを簡単に発見し、新しいフィーチャーを追加し、MLアプリケーションでそれらを簡単に直接使用できるようにします。
Unity Catalogは、LakehouseとDatabricksのワークスペースを横断して、一元化されたアクセス制御、共有、監査、リネージ、データ発見機能を提供します。フィーチャーストアの顧客と仕事をする中で、彼らはフィーチャーの共有やガバナンスといったUnityカタログの機能を何度も求めてきました。そして、次第に明らかになっていった......「なぜ2つのカタログを別々に持つのか:一つは自分の機能用、もう一つはそれ以外のもの用?」
ユニティ・カタログ・エクスペリエンスに統一されたフィーチャーを実装し始めたら、このフィーチャーストアの進化が、AI開発のワークフローの多くの側面にどれほどの影響を与えるかは明らかだった。
Unity Catalogのフィーチャーエンジニアリングは、Lakehouseを管理するカタログであるUnity Catalogにフィーチャーストア機能を直接組み込むことで、モデルのトレーニングとデプロイを簡素化します。
組織は通常、一貫性を維持し、企業ポリシーが Lakehouse 内のすべてのデータセットに適用されるようにするために、すべてのデータエンジニアリングパイプラインを単一の ELT フレームワークで標準化したいと考えています。フィーチャーエンジニアリング機能をUnity Catalogに統合することで、組織は同じ標準化されたELTフレームワークを使用して、フィーチャーエンジニアリングパイプラインを作成および維持することができます。
Unity Catalogで新しいフィーチャーを作成するプロセスを簡素化するために、SQL構文をアップグレードし、PRIMARY KEY制約の一部としてTIMESERIES句をサポートしました。これにより、モデルのトレーニングやスコアリングにフィーチャーを自動的に使用するアプリケーションは、適切なポイントインタイムジョインを実行できるようになります[AWS][Azure][GCP]
顧客は、自前のフィーチャーストアの実装、オープンソースライブラリ、またはベンダーの DSL を使用して作成された既存のフィーチャーテーブルを持っているかもしれません。これらの Delta テーブルに PRIMARY KEY 制約を追加することで、これらのフィーチャーを直接使用して、ML モデルをトレーニングし、提供することができます。
特徴量を使用して Databricks 上でトレーニングされた MLflow モデルでは、モデル・トレーニングで使用された特徴量へのリネージュが自動的に取得されます。このリネージュは、モデル内の feature_spec.yaml アーティファクトとして保存されます。これは、ユーザがモデルとフィーチャーのマッピングを独自に管理する必要がないというペインポイントに対応します。推論システムは、この仕様と特徴のメタデータをモデルのスコアリングに使用することができる。さらに、この情報は、モデルに必要なすべての機能と、ある機能からその機能を使用するすべてのモデルへのフォワードリンクを表示するリネージュグラフシステムにも使用できます。
Databricks Model Servingでモデルがデプロイされると、システムは推論に必要な特徴量をリネージで追跡し、Lakehouseの適切なオンラインテーブルを使用して特徴量を提供します。これにより、MLOpsエンジニアがモデルスコアリングのために記述する必要があるコードが簡素化されます。必要なIDでモデル提供エンドポイントを呼び出すだけで、特徴量は自動的に検索される。さらに、モデル、フィーチャー、その他のデータ資産がUnityカタログにあるため、これらの資産へのアクセスはすべて同じエンタープライズガバナンスに従います。
データサイエンティストは、Databricks Feature Store APIまたは他のELTフレームワークやSDKを使用して作成されたすべての特徴量を見つけることができます。Unity Catalogから特定のカタログを選択すると、プライマリキーを持つすべてのデルタテーブルを一覧表示できます。しかし、ユーザータグはこのキュレーションと発見の旅を簡素化し、以下のような様々なユースケースに対応します。
Unityカタログの発見タグは、カタログとスキーマにまたがって適用できます。ユーザーは、テーブル、ビュー、モデル、関数などのさまざまなエンティティにこれらのタグを適用できます。Unity Catalogのユーザータグを探索するための追加ガイドラインは、以下のとおりです。 AWS, Azure, GCP.
左ナビゲーションの機械学習の下にあるFeaturesボタンをクリックすると、Lakehouseで新しいフィーチャーを発見することができます。カタログを選択することで、MLモデルの学習に特徴として使用できる既存のテーブルをすべて見ることができます。
開始するには、Unityカタログドキュメントのフィーチャーエンジニアリングに従ってください。 AWS, Azure, GCP. このエンド・ツー・エンド notebookで始めることができる。