iQIYI機械学習プラットフォーム構築実践

機械学習プラットフォームを構築する以前、iQiyi にはすでに比較的成熟したディープラーニング プラットフォームである Jarvis がありました。しかし、Jarvis のユーザーは比較的高度な専門アルゴリズム エンジニアであり、専用のコンピューティング クラスターにコードを送信して計算を実行する必要があり、使用のハードルが比較的高いものでした。

また、アルゴリズムにはディープラーニング以外にも、機械学習、データマイニング、データ分析などの分野も含まれます。多くの中小企業では、これらの非ディープラーニングビジネスをサポートする対応するプラットフォームが存在せず、実装をサポートするアルゴリズムとエンジニアリングプラットフォームを独自に開発する必要があります。

これはよく煙突を建てると言われるものです。各ビジネスは独自のアルゴリズム プラットフォームを構築する必要がありますが、これは簡単に 2 つの問題につながります。1 つはアルゴリズムに関する問題です。多くのビジネスはアルゴリズムを中核として構築されておらず、機械学習はビジネスの支援や最適化にのみ使用される可能性があります。そのため、モデルやアルゴリズムをより深く理解している非常に専門的なアルゴリズム担当者がいない可能性があります。もう 1 つの問題は、アルゴリズム担当者はいるものの、アルゴリズムを実装するためには依然としてエンジニアリング作業が必要であり、これはさまざまなビジネスのために車輪の再発明をするケースであるということです。

さらに、iQiyi のデータ ミドル プラットフォーム戦略にとって、インテリジェント サービスはデータ ミドル プラットフォームの必須機能です。

上記3つの観点から見ると、機械学習プラットフォームの構築は比較的明確な位置づけを持っています。

機械学習プラットフォームは、アルゴリズムエンジニア、データアナリスト、ビジネスR＆Dエンジニアにサービスを提供します。効率的なオフラインのリアルタイム予測サービスを構築することで、ユーザーの機械学習コストを削減し、アクセスアルゴリズムの効率を向上させ、データミドルプラットフォームの利点を活用してデータとモデルの標準化と共有を促進したいと考えています。

開発の歴史

iQiyiの機械学習プラットフォームの開発の歴史を簡単に紹介します。

これまで、3つの大きなバージョンを経てきました。最初のバージョンも、ビジネスをベースに煙突を建てる段階でした。このバージョンでは、特定の業務を中心にサービスを構築しているため、アーキテクチャ全体ではアルゴリズムの数が非常に少ないですが、Spark ML スケジューリング アルゴリズムのコア システムを通じて、アルゴリズムの非同期分散スケジューリングを実装しました。オンライン化後、アルゴリズムのアクセス効率が大幅に向上しました。

第 1 版で蓄積された技術的経験に基づいて、汎用的な機械学習プラットフォームに対する現在の需要を発見したため、汎用的なニーズに対応する機械学習プラットフォームを実現するために第 2 版を繰り返し作成しました。

2 番目のバージョンの最も注目すべき機能は、ユーザー レベルでのビジュアル フロントエンドの追加です。これにより、ユーザーはドラッグ アンド ドロップで独自の機械学習プロセスを構築できます。アルゴリズムコンポーネントを自由に組み立てることで、ユーザーは一般化後の繁栄のプロセス要件を解決できます。

もう 1 つの重要なポイントは、スケジュール サービスを分離することです。その中で、実験的なスケジューリングサブシステムはタスクの状態を監視し、タスクのスケジューリングを担当します。タスクのハートビートをまとめることで、いつでもタスククラスターのグローバル状態を把握できます。タスク実行ノードが異常に中断された場合、すぐに再試行したり、他のノードに再配布したりできるため、サービスの安定性が大幅に確保されます。

タスク実行エンジンはタスク操作の中核です。タスク実行エンジンは、実験スケジューリング サービスによってプッシュされたタスクを受信し、モデル プールからモデル リソースを取得し、データ管理サブシステムからデータを読み書きし、タスク構成の内容に従ってスクリプトを実行します。タスク実行エンジンは特定のアルゴリズム フレームワークにバインドされていないため、さまざまなアルゴリズム フレームワークやプラットフォームにわたってアルゴリズム実行を簡単に実装できます。

メッセージログ監視により、各種スケジューリングアルゴリズムやプラットフォームで生成されたログ情報や端末情報を自動的に収集し、キーワード設定により有用な情報やデータを抽出し、フロントエンドに集約して表示したり、特定機能のリアルタイムチャート機能を実現したりします。

アルゴリズム モデル プールも独立したサービスとして管理され、オフラインおよびリアルタイムの予測モデルの取得とモデルの同期を担当します。

同システムは、v1でEuropaを介したSparkクラスタータスクのスケジューリングと、独自に維持していたスケジュールタスクを廃止し、iQiyiのビッグデータプラットフォームBabelとスケジュールタスクスケジューリングサービスプラットフォームGearに接続した。これら2つのプラットフォームに接続することで、データミドルプラットフォームとの接続だけでなく、オフラインサービスも実現できるようになります。

アルゴリズムフレームワークに関しては、実行エンジンが分離されているため、より多くのフレームワークを簡単に追加できます。第2バージョンでは、SparkMLでよく使用されるいくつかのアルゴリズムに加えて、XGBoostやグラフアルゴリズムなどのよく使用されるアルゴリズムも拡張されています。

3.0 の主な目標は、機能マップを改善し、主にオンライン予測サービスを実現することです。効率化を求めるユーザーからの要望に応えて、パラメータの自動調整や、モデルデータ量を拡大するためのパラメータサーバーの追加もサポートしています。また、ユーザーは他のプラットフォームを介して機械学習プラットフォームにアクセスする必要があるため、APIサービスも提供されます。

これまでのところ、基本的に機械学習の全プロセスをカバーするワンストッププラットフォームが形成されています。プラットフォームの操作を通じて、ユーザーは特徴エンジニアリングからモデルトレーニング、モデル評価、オンラインおよびオフライン予測まで、機械学習プロセス全体を実装できます。機械学習プロセスのデータソースとデータ送信先をビッグデータ開発プラットフォーム全体に接続することで、完全なクローズドループが完成します。

システム体験

実際のプロセスでの経験をいくつか共有します。

自動パラメータ調整

ユーザーがモデルを調整するときに、モデル パラメーターが正しく設定されていないと、モデルの精度に大きな影響が出ます。モデルのパラメータも異なります。LR や線形回帰などの一部のモデルには 4 つのパラメータがありますが、XGBoost などの一部のモデルには 17 個のパラメータがあります。すべてのパラメータがパラメータ調整に関係しているわけではありませんが、常にいくつかの順列と組み合わせが存在します。手動でパラメータを調整する必要がある場合、パラメータ グループの組み合わせは数十または数百になる可能性があります。例えば、XGBoost の場合、パラメータの調整に人力を使うことは基本的に考えられません。

現在の機械学習フレームワークには、Spark ML などのパラメータ調整機能が組み込まれているのが一般的ですが、ランダムな組み合わせと完全な組み合わせ (網羅的探索) しか実行できないため、パラメータ調整機能は非常に制限されています。 Spark の組み込みパラメータ調整方法を使用する場合、ユーザーがパラメータ調整範囲を除外するための直感的な経験がない場合、計算リソースまたは運が必要になります。

アルゴリズム フレームワークに付属するパラメータ調整システムには、パラメータ調整アルゴリズムをプラットフォーム間で再利用できないという別の制限があります。そこで、SparkやPythonなどの異なるアルゴリズムフレームワークを呼び出すことができ、またアルゴリズムフレームワークの言語制限に縛られることなく独自のパラメータ調整アルゴリズムを開発することもできるシステムレベルのパラメータ調整フレームワークを設計しました。

当社の自動パラメータ調整システムは、プロセス的には比較的シンプルです。システムはパラメータ調整を複数の反復ラウンドに分割します。ランダムパラメータ調整やグリッドサーチパラメータ調整などの従来のパラメータ調整アルゴリズムでは、調整は 1 回のみです。高度なアルゴリズムでは、調整は複数回行われます。調整間隔は、前回の調整の評価結果に基づいて適切に狭められ、パラメータは最終的に最適な値に収束します。

システムは、ユーザーが設定したパラメータ間隔を読み取った後、ユーザーのニーズに応じて間隔を複数のサブ間隔に分割し、各サブ間隔内のパラメータを最初のパラメータ調整の組み合わせとしてランダムにサンプリングし、タスク配信サービスを通じて実行エンジンに送信して、対応するアルゴリズム フレームワークのトレーニングと評価をスケジュールします。トレーニング タスクが完了すると、実行エンジンは評価結果をパラメータ調整サービスに返します。

現在のラウンドの評価結果をすべて収集した後、パラメータ調整サービスは、次のラウンドのパラメータ調整スペースを計算するアルゴリズムを開始し、次のラウンドのサンプル数を調整し、再度テストのために実行エンジンに送信し、最大ラウンド制限または収束レベルに達するまでこのサイクルを繰り返します。

パラメータ調整プロセス全体を、結果のフィードバックを通じて極値を継続的に見つけるプロセスである大規模モデルトレーニングプロセスと見なすことができます。この考え方に基づいて、パラメータ調整アルゴリズムとして適用可能なアルゴリズムを多数追加できます。

現在の機械学習プラットフォームでは、ランダム アルゴリズムとグリッド検索アルゴリズムのサポートに加えて、ベイズ最適化と独自開発の遺伝的アルゴリズムも実装されています。テストの結果、独自に開発したアルゴリズムのパラメータ調整の効率は、従来のデフォルト アルゴリズムよりもはるかに優れていることがわかりました。

データスケールのサポート

当初、システムは SparkML フレームワークのみをサポートしています。通常、数万のデータ セットのトレーニングは数分で完了します。ただし、ユーザー データ セットが数十から数百の桁しかない場合、タスクの実行にも数分かかります。これは、単一マシンの Python トレーニング時間が数秒であることと比較するとかなり遅いです。その理由の 1 つは、Spark クラスターに送信されたタスクがリソースの割り当てを待機する必要があることです。実際のトレーニング時間は短いですが、その他の準備時間もユーザーに遅く感じさせます。そのため、以降のバージョンでもスタンドアロンの Python エンジンを参照するようになりました。データ量が少ない場合、ユーザーはこの操作を 1 台のマシンで直接実行できます。

一方、従来の SparkML トレーニングでは、トレーニング データ量が 1 億を超えると非常に遅くなったり、クラッシュしたりすることがあります。これは、Spark が超大規模モデルのトレーニングに適していないためです。Spark のトレーニング モデルは、複数の反復ラウンドに分割されます。各ラウンドでは、すべてのエグゼキューターがタスクを完了してからでないと、パラメーターが要約されません。バレルの原則によると、Spark タスク全体は、最も遅いワーカーの実行時間の影響を受けます。

さらに、すべてのエグゼキュータはブロードキャストを通じてパラメータを共有するため、パラメータ数が多いモデルではネットワーク帯域幅が大量に消費され、システム使用率も非常に低くなります。

解決策は、パラメータ サーバーを使用することです。パラメータ サーバー自体は、分散トレーニングの原理にいくつかの改善を加えています。すべてのエグゼキュータの実行が完了するのを待つのではなく、一部のエグゼキュータが事前設定された値を超えると強制的に終了します。クラスター全体の効率を向上させるために、一部の収束速度を犠牲にしました。また、パラメータを送信するブロードキャストメカニズムを廃止し、パラメータをパラメータサーバーと呼ばれる独立したサーバーに配置して、そこから読み取るようにすることで、ネットワーク消費も節約しました。

iQiyi の機械学習プラットフォームは、クロスアルゴリズム フレームワークのスケジューリングをサポートするように設計されています。さまざまなオープンソース パラメータ サーバーを調査し、最終的に Tencent の Angel パラメータ サーバーを統合し、いくつかの典型的なモデルをテストしました。テストでは、1億を超える規模のモデルをトレーニングする場合、パラメータ サーバーのトレーニング効率が Spark と比較して 50% 以上大幅に向上することが示されています。

モデル管理プラットフォームとアルゴリズムのスケジューリング

Sklearn または Spark ML モデルの予測のいずれの場合でも、コードの観点から見ると、予測関数はさまざまなモデル内のメソッドです。すべてのモデルと互換性のある普遍的な予測方法はありません。独自のコードを作成する開発者にとってはこれで問題ありませんが、汎用的なプラットフォームを作成する場合は、すべてのモデル予測を処理し、ある程度のスケーラビリティを備えた統合予測コンポーネントを検討して、異なるアルゴリズム フレームワークのモデルが 1 つの予測コンポーネントを通じて互換性を持つようにする必要があります。

予測コンポーネントに似たもう 1 つの質問は、異なるアルゴリズム モデル、さらにはクロスフレームワーク モデルをオンライン予測サービスに均一に展開するにはどうすればよいかということです。

上記 2 つの問題は、モデル ファイルをカスタマイズすることで解決できます。モデルのトレーニングが完了すると、デフォルトのモデル ファイルに加えて、カスタム ファイルと PMML ファイルが出力されます。 PMML は、プラットフォーム間でモデルを読み取るために使用できる標準モデル定義言語であり、オフライン トレーニング + オンライン予測シナリオに適しています。さらに、モデル評価スコア、モデルタイプ、モデルトレーニングの関連テーブルとフィールド名、モデルパラメータ、トレーニングコンテキストなど、プラットフォームに役立つより詳細な情報をカスタムファイルに出力できます。

モデルが予測コンポーネントに接続されると、予測コンポーネントはカスタム ファイルを読み取り、モデル フレームワークとモデル タイプを取得し、対応するモデル フレームワークを通じてモデル ファイルを読み込みます。

オンライン予測では、トレーニングコンテキストを読み込むことで、上流のモデルトレーニングに必要な前処理プロセスをオンライン予測プロセスに組み込むことができ、ユーザーにかかる個別の前処理プロセスの負担を軽減します。

オンライン予測システム構築

オンライン予測システムは、さまざまなユーザー需要シナリオに応じてさまざまな呼び出し方法を提供します。

ローカル モードでは、オンライン予測プラットフォームはモデル情報全体をサービス jar パッケージに自動的にカプセル化し、軽量呼び出し用にユーザーに提供します。クラウド モードでは、オンライン予測サービス プラットフォームは Docker サービスを組み合わせてコンピューティング クラスターのセットを生成します。クラウド モードでは、HTTP サービスと RPC サービスがサポートされます。 HTTP サービスでは、システムは Consul サービスを通じて動的ドメイン名を申請し、自動検出サービスを通じて Docker サービスを関連付けます。ユーザーは、バックエンドの展開プロセスを理解する必要はなく、サービスによって提供されるドメイン名を通じてサービスにアクセスするだけで済みます。

RPC サービスは Dubbo に基づいて実装されています。モデル予測サービスは Dubbo によってカプセル化され、Docker を介して ZooKeeper に接続され、サービス検出を実現します。クライアントは、サービスにアクセスするために、指定された接続文字列に接続するだけで済みます。

オフライン予測プラットフォームはプロセスに基づいて公開されますが、オンライン予測はモデルとモデルコンテキスト情報に基づいて公開されます。モデル管理プラットフォームは、プッシュ モードとプル モードの両方を使用してオンライン サービスを展開します。プル モードは、ユーザーがサービスをアクティブに更新するモードです。一方、プッシュ モードは、モデル管理プラットフォームで更新された後にモデルがパッシブに更新されるモードです。 2 つの方法を組み合わせることで、オンライン サービスはすべてのモデル更新シナリオをカバーします。

事例紹介

不正行為防止ビジネスは、不正行為防止に関するビジネスロジックとビジネスデータを管理する独立したビジネスシステムです。不正行為防止プラットフォームは、さまざまな不正行為防止識別およびフィルタリング シナリオを定義および構築し、それらをデータ センター内の特定の操作とメンテナンスのワークフローに自動的に分解します。アルゴリズムを伴うプロセスはデータセンターを介して機械学習プラットフォームに転送され、処理され、処理された結果もデータセンターに返されます。

下の図には、一般的な教師ありアルゴリズム、教師なしアルゴリズム、白黒サンプル、クラスタリング アルゴリズム、異常検出アルゴリズム、グループ ベースのアルゴリズム、およびいくつかのディープラーニング アルゴリズムなど、トラフィック詐欺防止のすべてのシナリオと関連アルゴリズムが含まれています。

毎日1,000万件以上のログをフィルタリングでき、オンライン予測のピークは10,000 KPSを超えると予想されます。このようなプラットフォームにより、効率を80％以上向上できます。