機械学習実践体験: データプラットフォームの設計と構築

近年人気の技術である機械学習は、数多くの「人工知能」製品でよく知られているだけでなく、従来のインターネット製品の機能を根本的に強化します。以下の記事では、私が担当している Getui ビッグデータ プラットフォームの構築作業に基づいて、Getui データ プラットフォームのアーキテクチャに関する私の経験と、遭遇したいくつかの落とし穴について紹介します。

1. 背景：パーソナルプロモーションビジネスにおける機械学習の応用シナリオ

独立したインテリジェント ビッグデータ サービス プロバイダーとして、Getui の主な事業には、開発者サービス、精密マーケティング サービス、さまざまな垂直分野におけるビッグデータ サービスが含まれます。機械学習技術は多くのビジネスや製品に活用されています。

1. Getui は、正確なユーザー ポートレートに基づいてインテリジェントなプッシュを提供できます。ユーザー タグは主に機械学習に基づいており、モデルをトレーニングした後に人物を予測して分類します。

2. 広告対象者のターゲティング

3. ビジネス地区や観光地における旅客流動の予測

4. モバイル開発の分野では偽造デバイスが頻繁に出現します。機械学習は、開発者が新しく追加されたユーザーの信頼性を識別するのに役立ちます。

5. パーソナライズされたコンテンツの推奨

6. ユーザーの離脱と維持サイクルの予測。

[[237115]]

2. 機械学習の具体的なプロセス

1. 元のデータは ETL によって処理され、データ ウェアハウスに保存されます。

2. 上記の青い部分は機械学習を表しています。まず、サンプルデータを独自のデータと照合し、データに対する洞察を得て特徴を生成します。このプロセスは特徴エンジニアリングと呼ばれます。次に、これらの特徴に基づいて適切なアルゴリズムを選択し、それをトレーニングしてモデルを取得します。最後に、モデルをデータ全体に適用して予測結果を出力します。

標準的な機械学習ワークフロー: 特定のビジネス上の問題に対して、それをデータの問題に変換するか、データで解決できるかどうかを評価します。データをインポートしてフィルタリングした後、データとビジネス上の問題や目標との相関関係を分析し、具体的な状況に基づいてデータの二次処理を実行する必要があります。

次のステップは特徴エンジニアリングです。データから対象に関連する特徴変数を見つけて、いくつかの特徴を構築または導出し、同時に無意味な特徴を排除します。時間の約 80% を機能エンジニアリングに費やす必要があります。特徴を選択したら、ロジスティック回帰や RNN などのアルゴリズムを使用してモデルをトレーニングします。次に、モデルが目的を満たしているかどうかを判断するためにモデルを検証する必要があります。目標を達成できない理由は、データがターゲットに無関係であり、再収集する必要があることが考えられます。また、探索中に十分な作業を行わなかったために、既存のデータを再探索してから、特徴エンジニアリング手順を実行する必要がある可能性もあります。最終モデルがビジネスの期待を満たす場合は、それをビジネス ラインに適用します。

3. 機械学習プロジェクトの実装における一般的な問題

上記のプロセスは非常に明確ですが、実際の実装中に多くの問題に遭遇します。ここでは、これまでの実践経験に基づいていくつかの点についてお話ししたいと思います。

1. 現在、ほとんどの企業はビッグデータの時代に突入しています。以前のスモールデータの段階と比較すると、機械学習やデータマイニングのモデラーやアルゴリズムの専門家に対するスキル要件は高くなり、仕事の難易度も大幅に増加しています。

これまでは、機械学習データの前処理、データ分析、最終的な機械学習分析、起動を 1 台のマシンで完了できました。しかし、データが大量である場合は、Hadoop エコシステムにアクセスする必要があるかもしれません。

2. 教師あり学習を行う場合、一致するサンプルが必要になることがよくあります。データ ウェアハウス内のデータは数兆レベルに達する場合があります。データ抽出サイクルは非常に長く、マシンがこのデータを抽出するのを待つのに多くの時間がかかります。

3. 多くの場合、1 人または 2 人のアルゴリズム エンジニアが多くの業務の探索を担当するため、異なるグループのモデリング ツールが統一されていなかったり、実装プロセスが標準化されていなかったりすることがよくあります。一貫性がないと、多くのコードの重複が発生し、モデリング プロセスがチーム内で適切に確立されません。

4. 多くの機械学習アルゴリズム エンジニアは、専門的なバックグラウンドに限界があり、コード エンジニアリングの認識と経験が比較的弱い場合があります。一般的なやり方としては、アルゴリズム エンジニアが実験段階で特徴生成コードとトレーニング コードを作成し、エンジニアリング開発を行う学生に引き渡しますが、これらのコードは全量のデータでは実行できません。その後、エンジニアリング開発者はコードを再実装して、高い可用性と効率性を確保します。しかし、それでも不十分な翻訳が頻繁に発生し、その結果、通信コストが高くなり、オンライン申請サイクルが長くなります。

5. 機械学習の分野における大きな課題はデータの使用であり、データの探索に多くの時間を費やすため、非常にコストがかかります。

6. Getui には機械学習を活用した複数の事業がありますが、それらは統合されておらず、その結果、開発が重複し、沈殿・共有のプラットフォームが不足しています。この結果、派生したより有用な機能の一部が広く使用されなくなってしまいました。

4. 機械学習の問題に対する解決策を提案する

まず、私たちのプラットフォームの目標についてお話しします。

まず第一に、内部モデリングプロセスを標準化したいと考えています。

第二に、モデル開発からオンラインアプリケーションまでの全プロセスをカバーするエンドツーエンドのソリューションを提供したいと考えています。

3つ目は、プラットフォームデータ、特に開発された機能データが運用化され、社内のさまざまなチーム間で共有できるようになることを期待しています。

4 番目に、このプラットフォームは機械学習の知識がない開発者向けではなく、専門家や準専門家のアルゴリズム エンジニアを対象としており、モデリングの効率を向上させることができます。同時に、このプラットフォームはデータのセキュリティを確保するためにマルチテナントをサポートする必要があります。

以下は私たちの全体計画であり、主に 2 つの部分に分かれています。

下部はモデリング プラットフォームで、実験プラットフォームとも呼ばれ、主にアルゴリズム エンジニアによって使用されます。モデリング プラットフォームには次のものが含まれます。

1. 対応するIDE。このプラットフォームは、データの探索やデータ実験に使用できるほか、プロジェクトの管理と共有もサポートできます。

2. 開発された機能データを管理し、プラットフォームユーザー全員がデータ資産の状態を確認できるようにしたいと考えています。

3. サンプルを照合する場合、サンプル ID が内部 ID と一致しない場合があります。この場合、統一された ID 照合サービスが必要です。

4. アルゴリズム エンジニアが数兆のデータから必要なデータを迅速に抽出できるように支援することも非常に重要です。

5. 機械学習のプロセスでは、基本的なアルゴリズムに加えて、実際には繰り返し使用されるコードや類似するコードが多数あります。これらのよく使用されるコードを関数にカプセル化する必要があります。

6. モデル サービスのパッケージ化と展開をサポートします。

7. モデルはバージョン管理もサポートする必要があります。

8. 実際の業務にモデルを適用する際には、リアルタイムで監視し、モデルの可用性と精度を追跡する必要があります。

上部は、データ処理パイプラインを実行し、データ モデリング プラットフォームに接続された実稼働環境です。

実稼働環境では、モデルに対応する機能データは次の 2 つのカテゴリに分類されます。

1 つのタイプは、リアルタイム データ収集などのリアルタイム機能データです。これは、いくつかのリアルタイム機能を生成し、さまざまなビジネス ニーズに応じて異なるクラスターに保存されます。

もう 1 つのタイプはオフライン機能データであり、モデル アプリケーション側で使用するために Hive で処理され、保存されます。

実稼働環境では、ビジネス ラインで使用するためのオンライン予測 API またはオフライン予測データを提供できます。

5. プログラム実施の具体的なポイント

最後に、jupyter についてお話しましょう。

独自に開発したビジュアル ドラッグ アンド ドロップ モデリング ツールの代わりに Jupyter をメインのモデリング IDE として選択すると、インタラクティブな分析を実行でき、モデリング効率が高く、拡張が容易で、研究開発コストが低いという利点があります。もちろん、Microsoft Azure のような視覚的なドラッグ アンド ドロップ モデリング プラットフォームを使用すると、プロセス全体を非常に明確に確認できるため、初級レベルの学生がすぐに始めるのに適しています。しかし、私たちのターゲットユーザーは専門家と準専門家なので、最も適したものとして Jupyter を選択しました。

Jupyter を使用する場合、マルチテナントをサポートするために、Jupyterhub を使用します。基盤となる機械学習フレームワークとして、Tensorflow、Pyspark、Sklearn などを使用しました。データ処理を検討する場合、sparkmagic と組み合わせて、Jupyter で記述された Spark コードを Spark クラスター上で簡単に実行できます。

Jupyter には既成のバージョン管理とプロジェクト管理がないため、git を使用して解決します。

さらに、Jupyter のモデラーの効率を向上させるために、より多くのプラグインを導入しました。たとえば、いくつかの典型的なマイニング パイプラインは Jupyter テンプレートになっています。このようにして、同様の業務を再度行う必要がある場合は、テンプレートに基づいて開発を展開するだけで済みます。これにより、非標準化の問題がより適切に解決され、大量の重複コードが回避され、実験コードを製品コードに変換するための優れた基盤も構築されます。

次に、ツール機能について説明します。

当社は、以下の機械学習関連の関数ライブラリとツールを提供しています。

1) 標準化された ID マッピング サービス API。

2) データ抽出用の API を作成します。ストレージの種類に関係なく、アナリストは均一にこの API を呼び出すだけで済みます。 3) 視覚化には標準化された関数ライブラリとツールクラスがあります。

4) Jupyter2AzkabanFlow: 元々 Jupyter で記述されたコードまたはスクリプトを AzkabanFlow に自動的に変換し、機能エンジニアリング段階でのコード再利用の問題を解決します。

3 番目のポイントは Tensorflow の使用についてです。

Tensorflow を使用する場合、TensorflowOnSpark を選択します。ネイティブ Tensorflow の分散サポートは十分ではなく、いくつかのノード情報を指定する必要があり、使いにくくなっています。

TensorflowOnSpark はネイティブの Tensorflow Cluster 分散問題を解決でき、基本的に変更を加えることなくコードを簡単に TensorflowOnSpark に移行できます。

同時に、YARN は GPU と CPU の混合クラスターをサポートできるため、リソースの再利用が容易になります。

4点目、モデル納品申請に関して：

モデルの配信に関しては、予測コード全体をフレームワーク化し、アナリストが直接選択できるさまざまな標準フレームワークを提供しています。出力モデル ファイルには形式要件があります。たとえば、pmml 形式または tensorflow pb 形式のみを選択できます。標準化後は、標準の予測関数ライブラリを使用するだけで、モデラーとシステム開発者の作業を切り離すことができます。

***私たちの経験をいくつか共有します:

***、TensorflowOnSpark 上の PS の数は限られており、Worker ノードと PS ノードのリソース割り当てはそれほど柔軟ではなく、サイズはすべて同じです。

次に、Jupyter を使用する場合、一部のオープンソース ライブラリ バージョンには互換性の問題があるために、自分でいくつかの変更を加える必要があります。

3 つ目は、PMML を使用する場合にパフォーマンスのボトルネックが発生することです。これは、Java オブジェクトの再構築が繰り返されることによるものもあれば、フォーマット変換の損失によるものもあります。詳細については、分析と最適化のために jvm 情報をキャプチャできます。

4 番目に、実装プロセスで Spark と Hive を使用する場合、使いやすい診断ツールを提供する必要があります。モデラーは Spark と Hive の専門家ではないため、診断や最適化の方法に精通していない可能性があります。

5 番目に、モデルと機能ライブラリを資産として扱い、その価値を定期的に評価し、そのライフサイクルを適切に管理します。

6 番目は、より低レベルの問題です。たとえば、ハードウェアを選択するときは、帯域幅、メモリ、GPU のバランスに注意する必要がある場合があります。

***、テクノロジー スタックの増加とメンテナンス コストのバランスを取り、新しいツールやテクノロジーを過度に導入して運用上の困難を招くことを避ける必要があります。