機械学習では、ML モデルの作成とパッケージ化を支援する ML 開発プラットフォームの概要を説明しました。モデル構築は、ML システムに必要な多くの機能の 1 つにすぎません。この投稿の最後で、他の種類の ML プラットフォームと、実際の ML システムを構築する際の制限について説明しました。これについて議論する前に、これらのシステムのすべてのコンポーネントと、それらがどのように相互に接続されているかを確認する必要があります。

上の図は、「教師あり学習」システム（分類や回帰など）のクライアント サーバー アーキテクチャに焦点を当てており、予測はクライアントによって要求され、サーバー上で実行されます。 (補足: 一部のシステムではクライアント側で予測を行う方が適しており、クライアント側でモデルのトレーニングを行うことを推奨するシステムもありますが、産業用 ML アプリケーションでこれを効率的に行うツールはまだ存在していません。)

ML システム コンポーネントの概要

先に進む前に、上記のグラフをダウンロードし、画面を分割して、この記事の残りの部分を読みながらグラフを確認できるようにすることをお勧めします。

ML システムが作成される前に「データベース」が存在すると仮定します。濃い灰色と紫色のコンポーネントは、構築中の新しいコンポーネントになります。予測に ML モデルが適用されたものは紫色で表示されます。四角形は、マイクロサービスを提供することが期待されるコンポーネントを表すために使用されます。マイクロサービスは通常、Representational State Transfer (REST) API を介してアクセスされ、サーバーレス プラットフォーム上で実行されます。

ML システムには、予測を要求するクライアントと、モデルを作成/更新するオーケストレーターの 2 つの「エントリ ポイント」があります。クライアントは、ML システムの恩恵を受けるエンドユーザーが使用するアプリケーションを表します。これは、UberEats など、夕食を注文して配達予定時間をリクエストするために使用するスマートフォン アプリである可能性があります。これは、COVID-19 のロックダウン中に大きな使用例となります。

[[346268]]

ロックダウン前の写真はWikipediaより提供。世界中の何百もの都市で、この男性が目的地に到着する時間を 1 日に何千回も予測する高度な ML システムがあります。このシステムが使用するモデルがここ数週間で更新されていることを願っています...

オーケストレーターは通常、スケジューラによって呼び出されるプログラム（モデルを毎週など定期的に更新できるようにするため）、または API 経由で呼び出されるプログラム（継続的インテグレーション/継続的デリバリー パイプラインの一部にできるようにするため）です。モデル ビルダーによって作成されたモデルを機密テスト データセットで評価する役割を担います。これを行うには、テスト予測を評価者に送信します。モデルが十分に優れていると判断された場合、モデル サーバーに渡され、API を通じて利用できるようになります。この API はクライアント ソフトウェアに直接公開できますが、通常はフロントエンドにドメイン固有のロジックを実装する必要があります。

1 つ以上の (ベースライン) モデルが API として利用可能であるが、最終的なアプリケーションにまだ統合されていないと仮定すると、実稼働データでのパフォーマンスを追跡し、モニターを通じて視覚化することで、統合するモデル (および統合しても安全かどうか) を決定します。夕食の配達の例では、モデル化された ETD と、配達された注文の実際の配達時間を比較できます。新しいモデル バージョンが利用可能になると、予測に関するクライアント リクエストは、フロントエンド経由で新しいモデルの API に徐々に送信されるようになります。これは、パフォーマンスを監視し、新しいモデルによって何かが「壊れている」かどうかをチェックしながら、増加するエンドユーザーに対して実行されます。 ML システムの所有者とクライアント アプリケーションの所有者は、モニターのダッシュボードに定期的にアクセスします。

上の図のすべてのコンポーネントをリスト形式で言い換えてみましょう。

1. グラウンドトゥルースコレクター
2. データラベリングマシン
3. 評価者
4. パフォーマンスモニター
5. フィーチャライザー
6. コーディネーター
7. モデルビルダー
8. モデルサーバー
9. フロントエンド

第 3 条、第 4 条、第 6 条、第 7 条、第 8 条、第 9 条についてはすでに簡単に触れました。それでは、もう少し情報を追加して、#1、#2、#5 を確認しましょう。

#1: ファクトコレクター

現実世界では、機械が学習するための新しいデータを継続的に取得できることが重要です。特に重要なデータが 1 つあります。それは、グラウンド トゥルース データです。これは、不動産の販売価格、顧客関連のイベント (解約など)、入力オブジェクトに割り当てられたラベル (受信メッセージ内の「スパム」など) など、ML モデルで予測する内容に対応します。場合によっては、入力オブジェクトを観察し、予測したいオブジェクトを観察するためにしばらく待つ必要があります。たとえば、不動産が販売されるのを待つ、顧客がサブスクリプションを更新またはキャンセルするのを待つ、ユーザーが受信トレイ内の電子メールを操作するのを待つなどです。 ML システムが誤った予測を行った場合に、ユーザーに知らせてほしい場合があります (下の図を参照)。ユーザーがこの種のフィードバックを提供できるようにしたい場合は、フィードバックを送信するマイクロサービスが必要になります。

#2: データラベラー

大量の入力データにアクセスできる場合でも、関連する真実のデータを手動で作成する必要があることがあります。これは、画像からスパム検出器やオブジェクト検出器を構築する場合に当てはまります。データ注釈を簡素化するための既製のオープンソース Web アプリケーション (Label Studio など) があり、手動のデータ注釈をアウトソーシングするための専用サービス (図 8 や Google のデータ注釈サービスなど) もあります。

[[346269]]

航空機部門: タグスタジオの活動

#3: 評価者

機械学習用の初期データセットがある場合、ML モデルの構築を開始する前に、計画した ML システムを評価する方法を定義することが重要です。予測精度の測定に加えて、アプリケーション固有のパフォーマンス メトリックや、レイテンシやスループットなどのシステム メトリックを通じて、短期的および長期的な影響を評価する必要があります。

モデル評価には、モデルを比較することと、モデルをアプリケーションに統合しても安全かどうかを判断することという 2 つの重要な目標があります。予測が何であるか（つまり、真実）がわかっているので、事前に決定された一連のテスト ケースに対して評価を実行できます。エラーの分布を調べ、エラーをパフォーマンス メトリックに集計できます。これを行うには、評価者がテスト セットの真実にアクセスして、入力に対して予測されたときに予測誤差を計算し、パフォーマンス メトリックを返す必要があります。

ML モデルを構築する前にこの評価ツールを実装することをお勧めします。ベースライン モデルによる予測を評価して、参照を提供します。ベースラインは通常、入力機能 (特性) に基づいたヒューリスティックです。それらは非常にシンプルで手作りのルールになることもあります...

• 解約予測の場合、顧客が過去 30 日間に 3 回未満しかログインしていない場合は、解約する可能性が高いという基準を設定できます。
• 食品の配達時間の予測では、過去 1 週間に注文したレストランと配達員の平均配達時間を基準にすることができます。

明日複雑な ML モデルを開発する前に、ベースラインが今日価値を生み出せるかどうかを確認してください。

# 4: パフォーマンスモニター

(ベースライン) モデルをアプリケーションに統合してもよいかどうかを判断するための次のステップは、本番環境で発生する入力 (「本番環境データ」と呼ばれる) に対して本番環境と同様の設定でモデルを使用し、時間の経過に伴うパフォーマンスを監視することです。

生産データのパフォーマンス メトリックを計算して監視するには、生産入力、グラウンド トゥルース、予測をデータベースにキャプチャして保存する必要があります。パフォーマンス モニターは、データベースからデータを読み取り、評価プログラムを呼び出すプログラムと、時間の経過に伴うパフォーマンス指標の推移を示すダッシュボードで構成されます。一般的に、モデルが時間の経過とともに適切に機能するかどうか、また、モデルが統合されているアプリケーションに継続的にプラスの影響を与えているかどうかを確認したいと考えています。モニターは、生産データの分布を表示するデータ視覚化ウィジェットで強化することもできるため、予想どおりであることを確認したり、ドリフトや異常を監視したりすることができます。

解約モデルの監視ダッシュボード（出典）

#5: フィーチャライザー

予測 API を設計するときは、API が入力として何を受け取るかを決定する必要があります。たとえば、顧客について予測を行う場合、入力は顧客の完全な特徴表現にすべきでしょうか、それとも顧客 ID だけにすべきでしょうか?

いずれの場合も、完全な数値表現が一般的ですが (テキストや画像の入力と同様に)、モデルに渡す前に計算する必要があります。顧客入力の場合、一部の特徴（生年月日など）はすでにデータベースに保存されていますが、他の特徴は計算する必要があります。これは、一定期間にわたって顧客が製品とどのようにやり取りするかを説明する行動特性の場合に当てはまります。これらの特性は、顧客と製品のやり取りを記録するデータを照会して集計することによって計算されます。

特徴が本質的に頻繁に変化しない場合は、バッチで計算できます。しかし、UberEats の予想配達時間などの ML ユースケースでは、特定のレストランの過去 X 分間の平均配達時間など、急速に変化する「ホット」な機能をリアルタイムで計算する必要があることがあります。

これには、ID に基づいて入力のバッチの特徴を抽出する特徴化マイクロサービスを少なくとも 1 つ作成する必要があります。リアルタイム機能のマイクロサービスも必要になる場合がありますが、これにより ML システムの複雑さが増します。

機能アナライザーは、さまざまなデータベースを照会し、照会されたデータに対してさまざまな集計と処理を実行できます。モデルのパフォーマンスに影響を及ぼす可能性のあるパラメーター (上記の例の分数 X など) がある場合があります。

#6 コーディネーター

ワークフロー

オーケストレーターは ML システムの中核に位置し、他の多くのコンポーネントと対話します。ワークフロー/パイプラインの手順は次のとおりです。

1. 抽出、変換、ロードし、（生の）データをトレーニング、検証、テスト セットに分割します。
2. 機能が飽和したトレーニング/検証/テスト セット (ある場合) を送信します。
3. 専用のトレーニング/検証/テストセットを準備する
4. 準備されたトレーニング/検証セットのURIと最適化するメトリックをモデルビルダーに送信します。
5. 最適なモデルを取得し、それをテストセットに適用し、予測結果を評価者に送信する
6. パフォーマンス値を取得し、モデルをサーバーにプッシュできるかどうかを決定します (例: 実稼働データでの Kanata テストの場合)。

ステップ 3 (「専用のトレーニング/検証/テスト セットを準備する」) の詳細:

• トレーニング データの拡張 (例: アップサンプリング/アンダーサンプリング、画像の回転/反転/切り取り)
• データのサニタイズ（モデリングや予測に安全に使用できるように）や問題固有の準備（画像の彩度低下やサイズ変更など）を含む、トレーニング/検証/テスト セットの前処理。

ワークフローを実行する方法

ワークフロー全体は手動で実行できますが、モデルを頻繁に更新したり、モデラーとモデラーのハイパーパラメータを共同で調整したりするには、自動化する必要があります。このワークフローは単純なスクリプトとして実装し、単一のスレッドで実行できますが、並列で実行することで計算効率を高めることができます。エンドツーエンドの ML プラットフォームではこれが可能になり、完全な ML パイプラインを定義して実行するための環境を提供できます。たとえば、Google AI Platform では、Dataprep（Trifacta が提供するデータ ラングリング ツール）、Dataflow（簡素化されたストリームおよびバッチ データ処理ツール）、BigQuery（サーバーレス クラウド データ ウェアハウス）などの Google Cloud Data プロダクトを使用したり、TensorFlow または組み込みアルゴリズム（XGBoost など）に基づいてトレーニング アプリケーションを定義したりできます。大量のデータを扱う場合には、Spark が人気のある選択肢です。 Spark を開発している Databricks も、エンドツーエンドのプラットフォームを提供しています。

あるいは、ワークフローの各ステップを異なるプラットフォームまたは異なるコンピューティング環境で実行することもできます。 1 つのオプションは、これらの手順を異なる Docker コンテナーで実行することです。 Kubernetes は、ML 実践者の間で最も人気のあるオープンソース コンテナ オーケストレーション システムの 1 つです。 Kubeflow と Seldon Core は、ユーザーが ML パイプラインを記述し、それを Kubernetes クラスター アプリケーションに変換できるようにするオープン ソース ツールです。これはローカル環境で実行でき、アプリケーションはローカルにインストールできる Kubernetes クラスター、または Google AI Platform や Azure Kubernetes Service、Amazon EKS で使用される Google Kubernetes Engine などのクラウド プラットフォームで提供される Kubernetes クラスター上で実行できます。 Amazon は、Kubernetes に匹敵する Fargate と ECS も提供しています。 Apache Airflow は、もともと Airbnb によって開発されたもう 1 つのオープン ソース ワークフロー管理ツールです。 Airflow は、ML タスクを含む一般的な IT タスクの実行をオーケストレーションするための一般的な方法になり、Kubernetes とも統合されています。

より高度なワークフローのためのアクティブラーニング

前述のように、ドメイン エキスパートはデータ ラベラーを訪問して、入力内容を示してラベル付けを依頼する必要がある場合があります。これらのラベルはデータベースに保存され、オーケストレーターがデータのトレーニング/検証/テストで使用できるようになります。タグを提供する入力は手動で選択することも、コーディネーターでプログラムすることもできます。これは、モデルが正しいが不確実である、または非常に確実であるが不確実である生産入力を観察することによって実行できます。これが「アクティブ ラーニング」の基礎です。

#7 モデルビルダー

モデルビルダーは最適なモデルを提供する責任があります。これを行うには、トレーニング セットでさまざまなモデルをトレーニングし、指定されたメトリックを使用して検証セットで評価し、最適性を評価します。これは前回の投稿で説明した OptiML の例と同じであることに注意してください。

$ curl https://bigml.io/optiml?$BIGML_AUTH -d '{"dataset": "<training_dataset_id>", "test_dataset": "<test_dataset_id>", "metric": "area_under_roc_curve", "max_training_time": 3600 }'

BigML は API を通じてモデルを自動的に利用できるようにしますが、他の ML 開発プラットフォームの場合は、モデルをパッケージ化してファイルとして保存し、モデル サーバーにそのファイルをロードさせる必要がある場合があります。

Azure ML で実行された自動 ML 実験の結果。見つかった最適なモデルをダウンロードしたり、Azure にデプロイしたりできます。

別の ML 開発プラットフォームを使用している場合、またはプラットフォームをまったく使用していない場合は、トレーニング セット、検証セット、およびパフォーマンス メトリックを最適化する専用サービスによってモデルの作成が自動化されるようにシステムを設計する価値がある場合があります。

# 8 モデルサーバー

モデル サーバーの役割は、特定のモデルの予測に関する API 要求を処理することです。これを行うには、ファイルに保存されたモデル表現を読み込み、モデル インタープリターを介して API リクエストの入力に適用し、API レスポンスで予測を返します。サーバーは、複数の API リクエストとモデル更新を並行して処理できるようにする必要があります。

以下は、単一のテキスト機能のみを入力として受け取る感情分析モデルのリクエストと応答の例です。

$ curl https://mydomain.com/sentiment -H 'X-ApiKey: MY_API_KEY' -d '{"input": "ML プラットフォームに関するこの一連の記事が大好きです"}'{"prediction": 0.90827194878055087}

ONNX や PMML など、さまざまなモデル表現が存在します。もう 1 つの標準的な方法は、モデルをコンピューティング環境内のオブジェクトとしてファイルに保存することです。また、モデル オブジェクトを再度作成できるように、計算環境の表現、特にその依存関係を保存する必要もあります。この場合、モデルの「説明者」は、単に model.predict(new_input) のようなものから構成されます。

#9 フロントエンド

フロントエンドは複数の目的に使用できます。

• クラス確率のリストを最も可能性の高いクラスに変換するなど、モデルの出力を簡素化します。
• モデルの出力に追加します。たとえば、ブラックボックス モデルの説明を使用して予測の説明を提供します (Indico と同じアプローチ)。
• 予測に基づく意思決定や、異常な入力を受け取ったときのフォールバックなどのドメイン固有のロジックを実装します。
• 生産入力とモデル予測を送信して生産データベースに保存します。
• 新しいモデルをテストするには、その予測を（「ライブ」モデルに加えて）クエリして保存します。これにより、モニターはこれらの新しい候補モデルのパフォーマンス メトリックをプロットできるようになります。

モデルのライフサイクル管理

新しい候補モデルがテスト データセットで現在のモデルよりも優れたパフォーマンスを発揮する場合、フロントエンドでこのモデルの予測をアプリケーションのエンド ユーザーの小さなサブセットに返すことで、アプリケーションへの実際の影響をテストできます (カナリア テスト)。これには、評価者とモニターがアプリケーション固有のパフォーマンス メトリックを実装する必要があります。テスト ユーザーは、リストから選択することも、属性の 1 つや地理的な場所に基づいて選択することも、完全にランダムに選択することもできます。パフォーマンスを監視し、新しいモデルが何も壊さないことを確信した後、開発者はテスト ユーザーの割合を徐々に増やし、A/B テストを実行して、新しいモデルと古いモデルをさらに比較できます。新しいモデルの方が優れていることが判明した場合、フロントエンドは常に新しいモデルの予測を返すことで古いモデルを「置き換え」ます。新しいモデルによってシステムが壊れてしまった場合は、フロントエンドを通じてロールバックも実行できます。

徐々にトラフィックをモデル B に誘導し、モデル A を段階的に廃止します (出典)

結論は

現実世界の ML に興味がある方にとって、エンド ユーザーに実際に影響を与えるシステムを作成するには、ML 開発プラットフォームとモデル構築だけでは不十分なことが多い理由をこの記事で理解していただけたら幸いです。