How Lakehouse AI improves model accuracy with real-time computations | Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
機械学習モデルの予測の品質は、モデルのトレーニングとサービングで使用されるデータの品質を直接反映します。通常は、特徴量、モデルの入力データは事前に計算され、保存され、モデルの推論において検索され、提供されます。これらの特徴量が事前計算できない場合、モデルのパフォーマンスは特徴量の計算で使用されるデータの新鮮度と直接相関するので課題が生じます。このクラスの特徴量のサービングにおける課題をシンプルにするために、オンデマンドの特徴量計算処理を発表できることを嬉しく思っています。
レコメンデーション、セキュリティシステム、不正検知のようなユースケースでは、これらのモデルのスコアリングの際にオンデマンドで特徴量を計算する必要があります。以下のようなシナリオがあります:
- モデルサービングの際にのみ特徴量の入力データが利用できる場合。例えば、
distance_from_restaurantはモバイルデバイスで特定されるユーザーの最終地点が必要となります。 - 使用されるコンテキストに基づいて、特徴量の値が変化するケース。
device_typeがmobileとdesktopとでは、エンゲージメントのメトリクスは全く違う解釈をする必要があります。 - 特徴量を再計算、格納、リフレッシュするコストが膨大になるケース。ビデオストリーミングサービスでは、数百万のユーザーや数万の動画を取り扱っており、
avg_rating_of_similar_moviesのような特徴量の再計算が不可能になってしまいます。
これらのユースケースをサポートするためには、推論時に特徴量を計算する必要があります。しかし、モデルトレーニングの特徴量の計算は、通常Apache Spark(™)のようにコスト効率が高く、スループットが最適化されているフレームワークを用いて実行されます。このため、リアルタイムのスコアリングでこれらの特徴量が必要となる際に、二つの主要な問題が引き起こされます:
- 人手による取り組み、遅延、トレーニング/サービングの偏り: このアーキテクチャでは多くの場合、JavaやC++のようにレーテンシーが最適化された言語を用いて、サーバーサイドで特徴量計算処理を再度記述する必要があります。これは、2つの異なる言語で特徴量が作られることによりトレーニングとサービングで偏りが生じる可能性を持ち込むだけではなく、機械学習エンジニアがオフラインシステムとオンラインシステムの特徴量ロジックを維持、同期する必要が出てきます。
- 特徴量を計算し、モデルに提供するためのアーキテクチャ上の複雑性。これらの特徴量エンジニアリングパイプラインシステムは、サービングされるモデルと一緒にデプロイ、アップデートされる必要があります。新たなバージョンのモデルがデプロイされると、新たな特徴量の定義が必要となります。このようなアーキテクチャは、不必要なデプロイメントの遅延を引き起こします。機械学習エンジニアは、レート制限、リソース制約、ネットワーク帯域を侵害しないように、新たな特徴量計算パイプラインとエンドポイントがプロダクションのシステムと独立になっていることを確実にする必要があります。
オフラインとオンラインの特徴量計算ロジックの動機を必要とする一般的なアーキテクチャ。特徴量定義の更新は灰色で図示。
上のアーキテクチャでは、特徴量定義の更新は大規模な取り組みとなりる場合があります。アップデートされた特徴量計算処理パイプラインは、古い特徴量定義によるトレーニングとバッチ推論をサポートし続けるオリジナルのパイプラインと一緒に開発、デプロイされる必要があります。アップデートされた特徴量定義を用いて、モデルは再トレーニング、検証される必要があります。デプロイメントの準備ができたら、エンジニアは最初に、特徴量サーバーの特徴量計算ロジックを再度記述し、プロダクションのトラフィックに影響を与えないように、独立した特徴量サーバーのバージョンをデプロイしなくてはなりません。デプロイメントの後でアップデートされたモデルのパフォーマンスが従来と変わらないことを保証するために、開発過程で数多くのテストを実行する必要があります。モデルのオーケストレータは新たなモデルにトラフィックを送信するようにアップデートする必要があります。最終的には、ある程度の時間の後で、古いモデルと古い特徴量サーバーを停止することができます。
このアーキテクチャをシンプルにし、エンジアリングのスピードを改善し、可用性を高めるために、Databricksではオンデマンド特徴量の計算処理のサポートをローンチします。この機能は、Unity Catalogに直接組み込まれており、モデルを作成、デプロイするエンドツーエンドユーザーのジャーニーをシンプルにします。
「オンデマンド特徴量によって、我々の特徴量エンジニアリングの複雑性を劇的に削減する助けとなりました。オンデマンド特徴量によって、我々のクライアントのそれぞれにユニークな複雑な変換処理の管理を避けることができます。そうではなく、ベースとなる特徴量セットからシンプルにスタートし、トレーニングや推論の過程でオンデマンドでそれらの特徴量をクライアントごとに変換します。まさに、オンデマンド特徴量は次世代モデルを構築する我々の能力を解放しました。」- Chris Messier, Senior Machine Learning Engineer at MissionWired
機械学習モデルでの関数の活用
Unity Catalogにおける特徴量エンジニアリングによって、データサイエンティストはテーブルから事前にマテリアライズされた特徴量を取得し、関数を用いてオンデマンドの特徴量を計算することができます。オンデマンドの計算処理は、Unity Catalogの管理エンティティであるPythonのユーザー定義関数(UDF)として表現されます。関数はSQLで作成され、SQLクエリー、ダッシュボード、ノートブックで活用することができ、今ではリアルタイムのモデルにおける特徴量の計算にも活用できます。
UCのリネージグラフは、データと関数に対するモデルの依存関係を記録します。
CREATE OR REPLACE FUNCTION main.on_demand_demo.avg_hover_time(blob STRING)
RETURNS FLOAT
LANGUAGE PYTHON
COMMENT "Extract hover time from JSON blob and computes average"
AS $$
import json
def calculate_average_hover_time(json_blob):
# Parse the JSON blob
data = json.loads(json_blob)
# Ensure the 'hover_time' list exists and is not empty
hover_time_list = data.get('hover_time')
if not hover_time_list:
raise ValueError("No hover_time list found or list is empty")
# Sum the hover time durations and calculate the average
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を用いて、リアルタイムサービングでこの関数を実行することもできます。Sparkはリアルタイムの過程に含まれていませんが、トレーニングに使用されるのと同じ計算処理が保証されます。
簡素化されたアーキテクチャ
モデル、関数、データの全てはUnity Catalogに共存することになり、統合ガバナンスを実現します。共有カタログによって、データサイエンティストはモデリングで特徴量と関数を再利用することができ、企業においてどのように特徴量が計算されるのかに関して一貫性を保つことができます。サービングの際には、モデルへの入力として使用される関数やテーブルを特定するためにモデルのリネージが活用され、トレーニング・サービングの偏りの可能性を排除します。全体的に、これによって非常に簡素化されたアーキテクチャが実現されます。
Lakehouse AIはモデルのデプロイメントを自動化します: モデルがデプロイされると、Databricksモデルサービングは、ライブでの特徴量計算処理に必要なすべての関数を自動でデプロイします。リクエストの際には、事前にマテリアライズされた特徴量がオンラインストアから検索され、それらのPython UDFの本体を実行することでオンデマンドの特徴量が計算されます。
Databricksモデルサービングが特徴量検索、オンデマンド関数実行、モデルのスコアリングを管理するアーキテクチャ。
シンプルな例 - ホバー時間の平均
この例では、Webページのホバー時間のリストを抽出するために、オンデマンド特徴量はJSON文字列をパースします。これらの時間の平均が計算され、モデルへの特徴量として平均値が引き渡されます。
モデルにクエリーするには、ホバー時間を含むJSONのblobを引き渡します。
curl \
-u token:$DATABRICKS_TOKEN \
-X POST \
-H "Content-Type: application/json" \
-d '{
"dataframe_records": [
{"json_blob": "{\"hover_time\": [5.5, 2.3, 10.3]}"}
]
}' \
<host>/serving-endpoints/<endpoint_name>/invocations
このモデルはオンデマンドで平均ホバー時間を計算し、特徴量として平均ホバー時間を用いてモデルをスコアリングします。
洗練された例 - レストランへの距離
この例では、レストランのレコメンデーションモデルは、ユーザーの位置とレストランのIDを含むJSON文字列を受け取ります。レストランの位置は、オンラインストラに公開されている事前にマテリアライズされた特徴量から検索され、オンデマンド特徴量はユーザーからレストランへの距離を計算します。この距離はモデルへの入力として引き渡されます。
この例には、レストランの位置の検索し、このレストランからユーザーへの距離を計算するために後続の変換処理を行うことに注意してください。
より詳細は
APIのドキュメントや追加のガイドについては、コンピュート Python ユーザー定義関数を使用したオンデマンド機能をご覧ください。
Databricksと共有したいユースケースがありますか？on-demand-features@databricks.comにコンタクトしてください。