技術的負債の高利クレジットカード: 最もよく知られているエンドツーエンドの機械学習プラットフォームを詳しく調べる

この記事は、公開アカウント「Reading the Core」（ID: AI_Discovery）から転載したものです。

機械学習 (ML) は、技術的負債の高利クレジットカードと呼ばれています。特定のビジネス上の問題に適したモデルを作成することは比較的簡単ですが、そのモデルをスケーラブルな運用環境で機能させ、常に変化するデータのセマンティクスと関係の混乱に対処し、信頼性の高い自動化された方法でスキーマを進化させることはまったく別の問題です。

[[340153]]

機械学習の運用システムの場合、実際のコードのうちモデルそのものはわずか 5% です。一連の機械学習ソリューションをエンドツーエンドの機械学習プラットフォームに変換するのは、モデリングを加速し、展開を自動化し、運用時のスケーラビリティと信頼性を確保するテクノロジーを使用するアーキテクチャです。

以前、Lean D/MLOps、データ、機械学習の運用についてお話ししました。データなしでの機械学習の運用は意味がないため、エンドツーエンドの機械学習プラットフォームを全体として構築する必要があります。 CI/CD Foundation は、MLOps Special Interest Group (SIG) を立ち上げました。エンドツーエンドの機械学習プラットフォームによって決定される手順を次の図に示します。

しかし、それほど重要ではない詳細のいくつかは省略されています。たとえば、サービスがリアルタイムで実行されるかどうかに応じて、異なるテクニックが必要になる場合があります。スケーラブルなソリューションでは通常、ロード バランサーの背後にあるサービス クラスター内の複数のマシン上のコンテナーでモデルが実行されます。したがって、上の図の 1 つのボックスは、実際のプラットフォームの 1 つのステップ、コンテナー、またはコンポーネントを意味するものではありません。

これは図の手順に対する批判ではなく、単純に見えるものが実際にはそれほど簡単ではないかもしれないという警告です。

図にはモデル（構成）管理がありません。バージョン管理、実験管理、実行時統計、トレーニング、テスト、検証データセットのデータ系統追跡、モデルを最初からまたはモデルのスナップショットから再トレーニングする機能、ハイパーパラメータ値、精度メトリックなどについて考えてみましょう。

さらに、図に欠けているもう 1 つの重要なポイントは、モデルのバイアスを確認する機能です。たとえば、モデルの主要業績評価指標をさまざまな次元に沿って分割する機能です。多くの企業では、モデルをホットスワップしたり、複数のモデルを並行して実行したりする機能も必要です。前者は、モデルがバックグラウンドで更新されている間に、サーバーに送信されるユーザー リクエストの失敗を回避するために重要です。後者は、A/B テストやモデル検証にも重要です。

CI/CD から得られるもう 1 つのポイントは、見落とされがちなデータとコードのバージョン管理の必要性です。

グーグル: TFX

Google が TensorFlow eXtended (TFX) を開発した主な目的は、機械学習モデルの作成時間を数か月から数週間に短縮することでした。 Google のエンジニアや科学者は、「機械学習を本番環境に適用する必要がある場合、実際のワークフローはより複雑になる」ため、これに苦労しています。

TensorFlow と TFX はどちらも無料で使用できますが、後者は Google が提供する ML インフラストラクチャより 2 年遅れて 2019 年にリリースされたばかりであり、前者に比べて成熟度がはるかに低いです。

モデル パフォーマンス メトリックは、安全なサービス モデルを展開するために使用されます。したがって、新しいモデルが既存のモデルと同じパフォーマンスを発揮しない場合は、生産に投入することはできません。 TFXによると、このモデルは幸運ではなかったという。 TFX を使用すると、プロセス全体が自動化されます。

オープンソースの TFX コンポーネントの基本的な概要は次のとおりです。

• ExampleGen は入力データセットを抽出して分割します。
• StatisticsGen はデータセットの統計を計算します。
• SchemaGen は統計を調べてデータ スキーマを作成します。
• ExampleValidator はデータセット内の外れ値と欠損値を検出します。
• Transform はデータセットに対して特徴エンジニアリングを実行します。
• トレーナーは TensorFlow を使用してモデルをトレーニングします。
• 評価者はトレーニング結果を分析します。
• ModelValidator はモデルの高いセキュリティを保証します。
• Pusher はモデルをサービス インフラストラクチャにデプロイします。

TensorFlow Serving は、TensorFlow SavedModel ファイルを提供する C++ バックエンドです。トレーニング/サービングのスキューを最小限に抑えるために、TensorFlow 変換は計算グラフ内の値を「フリーズ」し、トレーニングで見つかったのと同じ値がサービングで使用されるようにします。実行時にトレーニングが単一の固定値である場合、DAG には複数の操作が含まれることがあります。

画像ソース: unsplash

Uber: ミケランジェロ

2015 年頃、Uber の ML エンジニアは、機械学習システムに隠された技術的負債に気づきました。 Uber は、ML モデルを統合した 1 回限りのカスタム システムを構築していましたが、大規模なエンジニアリング組織全体で拡張できるものではありませんでした。彼ら自身の言葉によれば、大規模なトレーニングおよび予測データを作成および管理するための、信頼性が高く、統合された、繰り返し可能なパイプラインを構築するためのシステムは存在していませんでした。

だから彼らはミケランジェロを作ったのです。これは Uber のデータ レイク (トランザクション データとログ データ) に依存しており、オフライン (バッチ) とオンライン (ストリーミング) の両方の予測をサポートします。オフライン予測の場合、付属の Spark ジョブによってバッチ予測が生成されますが、オンライン展開の場合、モデルは予測提供クラスターで提供されます。予測提供クラスターは通常、ロード バランサーの背後にある数百台のマシンで構成され、クライアントは RPC として単一またはバッチの予測要求をこのクラスターに送信します。

トレーナー実行時統計、モデル構成、系統、特徴の分布と相対的重要度、モデル評価メトリクス、標準評価チャート、学習したパラメータ値と要約統計など、各実験のモデル管理に関連するメタデータを保存します。

Michelangelo では、同じサービス コンテナーに複数のモデルをデプロイできるため、古いモデル バージョンから新しいモデル バージョンへの安全な移行や、モデルの並列 A/B テストが可能になります。

Michelangelo の初期バージョンでは GPU でのディープラーニング トレーニングはサポートされていませんでしたが、開発チームはこの欠陥に対処しました。現在のプラットフォームでは Spark の ML パイプラインのシリアル化が使用されていますが、オンライン サービス用の追加インターフェイスがあり、軽量でありながら不正検出や防止などの厳しい SLA を処理できるシングルトン (オンライン) スコアリング メソッドが追加されています。これは、Spark SQL の Catalyst オプティマイザーのオーバーヘッドをバイパスすることによって行われます。

注目すべきは、Google と Uber の両社が自社のサービス用の内部プロトコル バッファ パーサーと表現を構築し、デフォルトの実装に存在するボトルネックを回避したことです。

Airbnb: ビッグヘッド

Airbnb も同様の理由から、2016/2017 年に独自の ML インフラストラクチャ チームを設立しました。まず、製作中のモデルはわずか数個ですが、1 つあたりの製作には最大 3 か月かかります。第二に、モデル間に一貫性がありません。 3 番目に、オンライン予測とオフライン予測には大きな違いがあります。 Bighead はその努力の集大成です。

データ管理は社内ツール Zipline によって処理されます。 Redspot は、ホストされ、コンテナ化された、マルチユーザーの Jupyter Notebook サービスです。 Bighead ライブラリは、データ変換とパイプライン抽出に使用され、一般的なモデル フレームワークのラッパーを提供します。変換を通じてメタデータが保持されるため、系統を追跡するために使用できます。

Deep Thought は、オンライン予測用の REST API です。 Kubernetes はサービスを慎重に最適化します。オフライン予測については、Airbnb は独自の自動化を使用しています。

Netflixも上記企業と同様の問題に直面している。彼らの解決策は、予測サービスを提供せずにデータ管理とモデルトレーニングを処理するデータサイエンティスト向けの Python ライブラリである Metaflow を使用することです。そのため、これは機械学習のためのエンドツーエンドのプラットフォームではなく、ユーザー向けのユースケースよりも企業内のユースケースに適している可能性があります。もちろん、Kubernetes や AWS SageMaker を搭載した Seldon と組み合わせて、本格的なソリューションにすることもできます。

データ エンジニアが Airflow を使用するのと同じように、データ サイエンティストはワークフローを DAG ステップとして記述します。 Airflow と同様に、Metaflow は Python コードのみを実行するため、任意のデータ サイエンス ライブラリを使用できます。 Metaflow は処理とトレーニングをバックグラウンドで分散します。すべてのコードとデータは自動的に S3 にスナップショットされ、すべてのモデルと実験にバージョン履歴が保持されます。 Pickle はデフォルトのモデルシリアル化形式です。

オープンソースバージョンにはまだスケジューラが組み込まれていません。 AWS と密接に連携する AWS SageMaker を使用すれば水平方向のスケーラビリティを実現できますが、ユーザーは「主に垂直方向のスケーラビリティに依存する」ことが推奨されています。

リフト：フライト

[[340154]]

画像ソース: unsplash

Lyft は、データと機械学習の運用を統合するクラウドネイティブ プラットフォームである Flyte を公開しました。これは私の D/MLOps アプローチと一致しています。データ (Ops) は MLOps にとって、ロケットにとっての燃料のようなものであり、それがなければ何も起こりません。

Flyte は Kubernetes 上に構築されています。これは Lyft 社内で使用されており、少なくとも 7,000 の固有のワークフロー、1 か月あたり 100,000 回以上の実行、100 万のタスク、1,000 万のコンテナーまで拡張できます。

Flyte 内のすべてのエンティティは不変であるため、データ系統を追跡し、実験を再現し、デプロイメントを削減することが可能です。定期的なタスクでは、タスク キャッシュを利用して時間とコストを節約できます。現在サポートされているタスクには、Python、Hive、Presto、Spark、サイドカーが含まれます。ソースコードから見るとEKSのようです。彼らのデータカタログも Amundsen であり、Spotify の Lexikon と非常によく似ています。

AWS、Azure、GCP、その他

パブリック クラウド分野の主要プレーヤーはすべて独自の機械学習プラットフォームを持っていますが、Oracle は例外で、特定のユース ケースと業界向けにクローズドな機械学習ベースのモデルのみを提供しています。

AWS SageMaker は、TensorFlow、Keras、PyTorch、MXNet をサポートするフルスタックの機械学習ソリューションです。 SageMaker Neo を使用すると、モデルをクラウドとエッジにデプロイできます。 Amazon MechanicalTurk を通じて S3 に保存されたデータにラベルを添付する機能が組み込まれています。

Google にはマネージド プラットフォームはありませんが、TFX、Kubeflow、AI Platform を通じて、CPU、GPU、TPU 上でモデルを実行するために必要なコンポーネントをまとめ、ハイパーパラメータを調整し、本番環境へ自動的にデプロイすることが可能です。 Spotify は、TFX/Kubeflow-on-GCP オプションを選択しました。

TensorFlow に加えて、scikit-learn と XGBoost もサポートされています。カスタム コンテナーを使用すると、PyTorch などの任意のフレームワークを使用できます。 SageMaker Ground Truth のラベリング サービスは現在ベータ版です。

Azure Machine Learning は、scikit-learn、Keras、PyTorch、XGBoost、TensorFlow、MXNet などの複数のフレームワークをサポートしています。多数のグラフィックスを含む独自の D/MLOps スイートを備えています。モデル開発を好む場合はドラッグ アンド ドロップ インターフェイスを使用できますが、これにはさまざまな注意点があります。モデルと実験の管理は、予想どおり、Microsoft によってレジストリを通じて実行されます。運用環境の展開には、Azure Kubernetes Service を使用して制御されたロールアウトも可能です。

IBM Watson ML は、ポイント アンド クリックの機械学習オプション (SPSS) と、一般的なフレームワーク グループのサポートを提供します。 2 つの主要なプレーヤーの 1 つとして、モデルは CPU または GPU 上でトレーニングされ、ハイパーパラメータの調整もボックスに含まれています。このプラットフォームには、データとモデルの検証に関する詳細情報はあまりありませんが、これらは他の IBM 製品で提供されています。

2つの流行語を誇示しているにもかかわらず、アリババのAI機械学習プラットフォームはドキュメントを改善しておらず、ベストプラクティスのセクションでは提案ではなくユースケースが取り上げられています。

いずれにしても、特にデータ管理とモデリングではドラッグ アンド ドロップが苦手で、自動化されたエンドツーエンドの ML プラットフォームにはあまり役立たない可能性があります。このプラットフォームは、TensorFlow、MXNet、Caffe などのフレームワークをサポートしていますが、従来のアルゴリズムも多数サポートしています。予想通り、ハイパーパラメータチューナーも含まれています。

モデルのシリアル化は、PMML、TensorFlow の SavedModel 形式、または Caffe 形式を使用して行われます。 PMML、ONNX、または PFA ファイルを採用するスコアリング エンジンでは、迅速な展開が可能になりますが、提供されるモデルが異なる形式から読み込まれるため、トレーニング/サービングのスキューが生じるリスクがあることに注意してください。

その他のプラットフォーム

H2O は、データ操作、複数のアルゴリズム、クロス検証、ハイパーパラメータ調整のためのグリッド検索、機能のランキング、POJO または MOJO を使用したモデルのシリアル化のためのプラットフォームを提供します。

valohai (フィンランド語で「軽いサメ」の意味) は、プライベート、パブリック、ハイブリッド、またはマルチクラウド設定で実行できるマネージド機械学習プラットフォームです。

各アクション (または実行) は、Kubeflow と同様に、Docker イメージ上でコマンドを実行します。両者の主な違いは、Valohai は Kubernetes デプロイメント クラスターを直接管理するのに対し、Kubeflow では開発者がこのタスクを実行する必要があることです。

ただし、Kubeflow と TFX は、TensorFlow 関連のツールをいくつか提供していると考えています。 Valohai では、既存の Docker イメージを再利用するか、独自の Docker イメージを作成する必要があります。つまり、任意の機械学習フレームワークを使用できますが、その自由度と保守性を考慮する必要があります。

したがって、トレーニングは Spark、Horovod、TensorFlow など、ニーズやインフラストラクチャに適したツールを通じて配布できますが、それはあなた次第です。これは、トレーニング/サービングの偏りを回避するために、データ変換の互換性を確保する責任を負うことも意味します。現在はオブジェクト ストレージのみがサポートされていることに注意してください。

Iguazio 氏は、ノートブックや IDE から数秒でデプロイできる機能について言及しましたが、CI/CD パイプラインや、TFX の Pusher コンポーネントを備えたプラットフォーム自体など、最も一般的なシナリオが欠けているようです。ワークフロー オーケストレーションには Kubeflow を使用します。

Iguazio には、キーと値のペアおよび時系列用の統合 API を提供する機能ストアがあります。大手テクノロジー企業のほとんどには専門店がありますが、販売されている製品の多くは専門店ではありません。

中核となるのは、複数のモデル間で共有してモデル開発を加速できる、すぐに再利用できる機能を備えた機能ストアです。エンタープライズ規模で機能エンジニアリングを自動化します。たとえば、タイムスタンプからは、年、季節、月、曜日、時刻、現地の祝日かどうか、最新の関連イベントからの経過時間、固定ウィンドウ内で特定のイベントが発生する頻度など、多くの特徴を抽出できます。

SwiftStack AI は、RAPIDS スイートを通じて NVIDIA GPU 上での高スループットのディープラーニングをターゲットにしています。 RAPIDS は、使い慣れた scikit-learn API を使用しながら GPU アクセラレーション アルゴリズムのメリットを享受できる cuML や、GPU を活用したグラフ分析用の cuGraph などのライブラリを提供します。

AI レイヤーは、複数のデータ ソース、プログラミング言語、機械学習フレームワークのサポートが組み込まれた D/MLOps API です。

MLflow は Databricks を搭載しており、Spark との緊密な統合が実現されています。限定された一連の展開オプションが提供されます。たとえば、PySpark でモデルをベクトル化された UDF としてエクスポートする機能は、Python UDF によって Python ランタイム環境と JVM 間の通信オーバーヘッドが発生するため、リアルタイム システムには最適ではありません。

オーバーヘッドは標準の PySpark UDF を使用する場合ほど大きくはありませんが、Python と JVM 間の転送に Apache Arrow (メモリ内列形式) を使用するため、無視できない大きさになります。デフォルトのデータ取り込みソリューションとして Spark Streaming を使用する場合、Spark のマイクロバッチ モデルを使用して 1 秒未満のレイテンシを実現するのは難しい場合があります。

ログ記録のサポートはまだ実験段階ですが、これは D/MLOps にとって非常に重要です。ドキュメントによると、MLflow は、少なくともプラットフォームの標準的な部分としては、データとモデルの検証に重点を置いていないようです。より多くの機能を提供する MLflow のホストバージョン (AWS および Azure 上) があります。

D2iQ の KUDO for Kubeflow は、エンタープライズ顧客向けの Kubeflow ベースのプラットフォームです。オープンソースの Kubeflow とは異なり、Spark と Horovod が付属しているほか、TensorFlow、PyTorch、MXNet などの主要なフレームワーク用に事前に構築され、完全にテストされた CPU/GPU イメージも付属しています。データ サイエンティストはコンテキストを切り替えることなく、ノートブックにフォームを展開できます。

[[340155]]

画像ソース: unsplash

デフォルトでは、マルチユーザーの使用をサポートします。セキュリティと認証を強化するために Istio と Dex を統合します。 Kubeflow の KUDO は、D2iQ のマネージド Kubernetes プラットフォームである Konvoy 上に構築されます。クラウド、オンプレミス、ハイブリッド、エッジで実行でき、エアギャップ クラスターのポートにも使用できます。

Kubernetes では、Kubeflow の KUDO は、Go ではなく YAML を使用して Kubernetes オペレーターを作成するための宣言型ツールキットである KUDO で定義されたオペレーターのコレクションです。 Cassandra、Elastic、Flink、Kafka、Redis などの Kubernetes Unified Declarative Operators (KUDO) はすべてオープンソースであり、プラットフォームに統合できます。