機械学習モデルの予測品質は、モデルの訓練と使用に使用されるデータの品質に直接反映される。 通常、特徴量、つまりモデルへの入力データは事前に計算され、保存された後、推論のために検索され、モデルに提供される。 モデルの性能は、特徴計算に使用するデータの鮮度と直接相関することが多いため、これらの特徴を事前に計算できない場合に課題が生じる。 オンデマンド・フィーチャー・コンピュテーションを発表することで、このようなフィーチャー・クラスのサービスを簡素化することができる。
レコメンデーション、セキュリティシステム、不正検知などのユースケースでは、これらのモデルのスコアリング時にオンデマンドで機能を計算する必要がある。 シナリオは以下の通り：
distance_from_restaurantは、モバイル機器によって決定されたユーザーの最後の既知の位置を必要とする。デバイスの種類がデスク トップと モバイルでは、エンゲージメントの指標の解釈が大きく異なる。avg_rating_of_similar_moviesのような機能を事前に計算することは法外である。これらのユースケースをサポートするためには、推論時に特徴を計算する必要がある。 しかし、モデル学習のための特徴計算は、通常、Apache Spark(™)のようなコスト効率が高く、スループットが最適化されたフレームワークを使用して実行される。 リアルタイム採点にこれらの機能が必要な場合、これは2つの大きな問題を引き起こす：
上記のアーキテクチャでは、機能定義の更新は大仕事となる可能性がある。 更新されたフィーチャライゼーション・パイプラインは、古い特徴定義でのトレーニングとバッチ推論をサポートし続けるオリジナルと同時に開発され、デプロイされなければならない。 モデルは、更新された特徴定義を使用して再トレーニングされ、検証されなければならない。 デプロイが許可されると、エンジニアはまずフィーチャー・サーバー内のフィーチャー計算ロジックを書き換え、本番トラフィックに影響を与えないように、独立したフィーチャー・サーバー・バージョンをデプロイしなければならない。 デプロイ後、更新されたモデルのパフォーマンスが開発時と同じであることを確認するために、数多くのテストを実行する必要がある。 モデ ルオーケストレーターは、新しいモデルにトラフィックを誘導するように更新されなければならない。 最終的に、ある程度の時間が経てば、旧モデルと旧機能のサーバーを撤去することができる。
このアーキテクチャを簡素化し、エンジニアリング速度を向上させ、可用性を高めるために、Databricksはオンデマンド機能計算のサポートを開始します。 この機能はUnity Catalogに直接組み込まれており、モデルの作成と展開のためのエンドツーエンドのユーザージャーニーを簡素化します。
オンデマンド機能により、フィーチャーエンジニアリングパイプラインの複雑さが大幅に軽減されました。 オンデマンド機能により、顧客ごとに異なる複雑な変換を管理する必要がなくなります。 その代わりに、単純にベースとなる特徴のセットから始めて、トレーニングや推論中にオンデマンドでクライアントごとに変換することができます。 本当にオンデマンドの機能によって、次世代のモデルを作る能力が向上した。 - クリス・メシエ、MissionWiredのシニア機械学習エンジニア
Unity Catalogのフィーチャーエンジニアリングにより、データサイエンティストはテーブルから事前にマテリアライズされたフィーチャーを取得し、関数を使用してオンデマンドでフィーチャー を計算することができる。 オンデマンドの計算はPython User-Defined Functions (UDF)として表現され、Unity Catalogのエンティティとして管理される。 関数はSQLで作成され、SQLクエリ、ダッシュボード、ノートブック、そして現在ではリアルタイムモデルのフィーチャーを計算するために、レイクハウス全体で使用することができる。
UCリネージグラフは、モデルのデータと関数への依存関係を記録する。
CREATE OR REPLACE FUNCTION main.on_demand_demo.avg_hover_time(blob STRING)
RETURNS FLOAT
LANGUAGE PYTHON
COMMENT"JSON blobからホバー時間を抽出し、平均値を計算"
AS $$
import json
def calculate_average_hover_time(json_blob)：
# JSON blobをパースする
data = json.loads(json_blob)
# 'hover_time' リストが存在し、空でないことを確認する
hover_time_list = data.get('hover_time')
if not hover_time_list:
raise ValueError("No hover_time list found or list is empty")
# ホバー時間の持続時間を合計し、平均を計算
total_duration = sum(hover_time_list)
average_duration = total_duration / len(hover_time_list)
return average_duration
return calculate_average_hover_time(blob)
$$.モデルに関数を使用するには、create_training_setの呼び出しに関数を含める。
from databricks.feature_store import FeatureStoreClient
fs = FeatureStoreClient()
features = [
FeatureFunction(
udf_name="main.on_demand_demo.avg_hover_time",
output_name="on_demand_output",
input_bindings={"blob":"json_blob"},
),
...
]
training_set = fs.create_training_set(
) raw_df, feature_lookups=features, label="label", exclude_columns=["id"]
)この関数はSparkによって実行され、モデルのトレーニングデータを生成する。
また、この関数はネイティブのPythonとpandasを使ってリアルタイムで実行される。 スパークはリアルタイムの経路には関与しないが、トレーニング時に使用されたものと同等の計算が保証される。
モデル、ファンクション、データはすべてUnity Catalog内に共存し、統一されたガバナンスを実現する。 共有カタログにより、データサイエンティストはモデリングにフィーチャーや関数を再利用することができ、組織全体でフィーチャーの計算方法に一貫性を持たせることができる。 その際、モデルの系統は、モデルへの入力として使用される関数とテーブルを決定するために使用され、トレーニングに起因するスキューの可能性を排除する。 全体として、この結果、アーキテクチャーは劇的に簡素化された。
Lakehouse AIはモデルのデプロイを自動化する。モデルがデプロイされると、Databricks Model Servingはフィーチャーのライブ計算を可能にするために必要なすべての機能を自動的にデプロイします。 リクエスト時には、事前にマテリアライズされたフィーチャーがオンラインストアから検索され、オンデマンドのフィーチャーはPython UDFのボディを実行することで計算される。
この例では、オンデマンド機能がJSON文字列を解析し、ウェブページ上のホバー時間のリストを抽出している。 これらの時間は平均化され、平均値は特徴量としてモデルに渡される。
モデルへのクエリは、ホバー時間を含むJSON blobを渡す。 例えば、こうだ：
curl ୧
-u token:$DATABRICKS_TOKEN ୧
-X POST ୧
-H"Content-Type: application/json" ୧
-d '{
" dataframe_records" ：[
{"json_blob" ："": [5.5, 2.3, 10.3]}"} {"hover_time
]
}'\
<host>/serving-endpoints/<endpoint_name>/invocationsこのモデルはオンデマンドで平均ホバータイムを計算し、平均ホバータイムを特徴としてモデルを採点する。
この例では、レストラン推薦モデルは、ユーザーの位置情報とレストランIDを含むJSON文字列を受け取る。 レストランの位置は、オンラインストアに公開されたマテリアライズ済みのフィーチャーテーブルから検索され、オンデマンド機能がユーザーからレストランまでの距離を計算する。 この距離はモデルの入力として渡される。
この例では、レストランの場所を検索し、そのレストランからユーザーまでの距離を計算する変換が行われている。
APIドキュメントと追加ガイダンスについては、Pythonユーザー定義関数を使用したオンデマンド機能の計算を参照してください。
Databricksと共有したいユースケースをお持ちですか？ お問い合わせは、[email protected]まで。
