NetEase Cloud Music アルゴリズム プラットフォームの研究開発専門家 Huang Bin 氏: NetEase Cloud Music オンライン予測システムの実践と考察

ゲスト | Huang Bin

コンピレーション | Tu Chengye

最近、51CTO が主催する AISummit グローバル人工知能テクノロジーカンファレンスで、NetEase クラウド ミュージック アルゴリズム プラットフォームの研究開発の専門家である Huang Bin が登壇しました。 、基調講演「NetEase Cloud Music Online 予測システムの実践と考察」では、技術研究と発達。

皆さんにインスピレーションを与えていただければと思い、スピーチの内容を以下のように整理しました。

全体的なシステム アーキテクチャ

まず、次の図に示すように、推定システム全体のアーキテクチャを見てみましょう。

システム アーキテクチャ全体の中央にある予測サーバー

## は、クエリ コンポーネント、特徴処理コンポーネント、モデル計算コンポーネントを含む、予測システムのコア コンポーネントです。左側の監視システムは、システム ネットワークのスムーズな流れを確保するために回線ネットワーク サービスを監視するために使用されます。右側の PushServer はモデル プッシュに使用され、最新モデルをオンライン予測システムにプッシュして予測します。

目標は、高性能で使いやすく、機能が豊富な予測システムを構築することです。

ハイ パフォーマンス コンピューティング

コンピューティング パフォーマンスを向上させるにはどうすればよいですか?私たちによくあるコンピューティング パフォーマンスの問題は何ですか? 3 つの側面から詳しく説明します。

特徴処理

一般的なソリューションでは、特徴計算とモデル計算は別のプロセスにデプロイされるため、サービス全体にわたって多数の機能が存在することになります。言語間転送では複数のエンコード、デコード、メモリ コピーが発生し、パフォーマンスのオーバーヘッドが比較的大きくなります。

モデルの更新

モデルが更新されると、大きなブロック タイプのアプリケーションとリリースが存在することがわかっています。ただし、一部の一般的なソリューションにはモデルの予熱ソリューションが付属していないため、モデルの更新プロセスで比較的時間がかかるジッターが発生し、モデルのリアルタイム更新をサポートできません。

コンピューティング スケジューリング

一般的なフレームワークは同期メカニズムを使用しますが、同時実行性が不十分で CPU 使用率が低く、高い同時実行性のコンピューティング ニーズを満たすことができません。

それでは、推定システムにおけるこれらのパフォーマンスのボトルネックをどのように解決すればよいでしょうか?

1. 機械学習ライブラリのシームレスな統合

なぜそのようなことを行う必要があるのでしょうか?従来のソリューションでは、特徴処理とモデル計算が別のプロセスにデプロイされ、その結果、より具体的なクロスネットワーク送信、シリアル化、逆シリアル化、および頻繁なメモリのアプリケーションとリリースが発生することを誰もが知っているからです。特に、おすすめシーンの特徴量が特に多い場合には、パフォーマンスのオーバーヘッドが大きくなります。以下の図の上部のフローチャートは、一般的なソリューションにおける特定の状況を示しています。

コンピュータ学習ライブラリのシームレスな統合

上記の問題を解決するために、ハイパフォーマンス コンピューティング学習フレームワークを予測システムに統合します。このシステムの利点は、特徴処理とモデル計算を同じプロセスに確実にデプロイでき、ポインターの形式で特徴操作を実装できるため、シリアル化、逆シリアル化、ネットワーク送信のオーバーヘッドが回避され、それによって機能が向上することです。計算と特徴処理により、コンピューティング パフォーマンスの向上がもたらされます。これは、機械学習のシームレスな統合の利点です。

2. アーキテクチャ設計の考慮事項

まず、システム全体が完全に非同期のアーキテクチャ設計を採用しています。非同期アーキテクチャの利点は、外部呼び出しがノンブロッキングで待機しているため、非同期メカニズムにより、60% ～ 70% などの高い CPU 負荷の下でも、時間のかかるネットワーク サービスの安定性が維持されることを保証できることです。

2 つ目は、メモリ アクセスの最適化です。メモリアクセスの最適化は主にサーバーのNUMAアーキテクチャに基づいており、コアバウンドの運用方式を採用しています。このようにして、以前の NUMA アーキテクチャに存在していたリモート メモリ アクセスの問題を解決できるため、サービスのコンピューティング パフォーマンスが向上します。

3 番目は、並列コンピューティングです。コンピューティング タスクをスライスで処理し、マルチスレッドの同時実行性を使用して計算を実行することで、サービス時間の消費を大幅に削減し、リソースの使用率を向上させることができます。

アーキテクチャ設計の考慮事項

上記は、システムのシステム アーキテクチャの考慮事項を見積もる際の実践です。

3. マルチレベル キャッシュ

マルチレベル キャッシュは、主に特徴クエリ ステージとプライマリ ステージで使用されます。私たちがカプセル化したキャッシュ メカニズムは、一方ではクエリへの外部呼び出しを減らし、他方では特徴抽出によって引き起こされる無効な計算の繰り返しを減らすことができます。

キャッシュにより、クエリと抽出の効率が大幅に向上します。特にクエリの段階では、同期クエリ、非同期クエリ、機能の一括インポートなど、機能の重要性や機能の大きさに応じてさまざまなコンポーネントをカプセル化します。

1 つ目は同期クエリです。これは主に、より重要な機能に適しています。もちろん、同期クエリのパフォーマンスはそれほど効率的ではありません。

2 番目のタイプは非同期クエリで、主に一部の「Aite ディメンション」機能をターゲットとしています。これらの機能はそれほど重要ではない可能性があるため、この非同期クエリ方法を使用できます。

3 番目のタイプは特徴量一括インポートで、主に特徴量がそれほど大きくない特徴量データに適しています。これらの機能をプロセスにバッチでインポートすることで、機能のローカライズされたクエリを実装でき、パフォーマンスが非常に効率的になります。

マルチレベル キャッシュ

4. モデル計算の最適化

キャッシュ メカニズムを導入した後、動作の最適化を見てみましょう。モデル計算のモデル計算では、主にモデル入力の最適化、モデル読み込みの最適化、カーネルの最適化の3つの側面から最適化を行います。

• モデル入力の最適化

モデル入力領域では、TF Servering が Example の入力を使用していることは誰もが知っています。 Example 入力には、Example の構築、Example のシリアル化と逆シリアル化、モデル内の Parse Example の呼び出しが含まれますが、これには比較的時間がかかります。

下の図では、[最適化前] のスクリーンショットを見て、モデルの計算と最適化の前のデータ統計を示します。解析に時間がかかる比較的長い解析例があり、解析例が解析される前に他の操作が並列スケジューリングを実行できないことがわかります。モデル ツリーのパフォーマンスの問題を解決するために、予測システムに高性能モデル入力ソリューションをカプセル化しました。新しいソリューションを通じて、フィーチャ入力のコピーをゼロにすることができるため、この例の時間のかかる構築と解析が削減されます。

下の図では、[最適化後] のスクリーンショットを見て、モデルの計算と最適化後のデータ統計を示しています。解析例の解析時間がなくなり、例の解析のみが行われていることがわかります。時間がかかります。

#モデル計算の最適化

モデル読み込みの最適化

モデル入力の最適化を紹介した後、見てみましょう。モデルの読み込みの最適化で。 Tensorflow のモデルの読み込みは遅延読み込みモードです。モデルが内部的に読み込まれた後は、モデルを予熱しません。代わりに、ネットワークからの正式なリクエストが来るまでモデルを予熱しません。これにより、モデルはその後ロードされます。深刻な時間のかかるジッターが発生します。

この問題を解決するために、予測システム内でのモデルの自動予熱機能、新旧モデル間のホットスイッチング、旧モデルの非同期アンロードとメモリ解放を実装しました。このようにして、これらのモデルをロードするためのいくつかの最適化メソッドを通じて、モデルの分単位の更新機能が実現されます。

カーネルの最適化

次に、モデル カーネルの最適化を見てみましょう。現時点では主に Tensorflow カーネル上でカーネル同期の最適化を行っており、モデルなどに応じて ops 間および ops 内の一部のスレッド プールを調整する予定です。

上記は、モデル計算のパフォーマンスを最適化するための試みの一部です。

上記のパフォーマンス最適化ソリューションを導入した後、最終的なパフォーマンス最適化の結果を見てみましょう。

パフォーマンス最適化の結果

ここでは、推定システムと一般的な解決システムを比較します。推定されたシステムの CPU 使用率が 80% に達すると、サービス全体の計算時間とタイムアウト率が非常に安定し、非常に低いことがわかります。比較すると、新しいソリューション (予測システム) は計算と処理の点で 2 倍のパフォーマンスがあり、CPU 抽出機能が強化され、サービス時間が短縮されていると結論付けることができます。

システムの最適化のおかげで、ビジネス アルゴリズムに対してより多くのモデルの複雑さの計算とより多くの候補セットの計算を提供できるようになりました。

上の図は例を示しています。候補セットは、以前の 300 の候補セットから 1,000 の候補セットに拡張されました。同時に、モデルの計算の複雑さが増加し、いくつかのより複雑な機能が使用されました。 . このビジネスの業績向上がもたらされました。

上記は、推定システムのパフォーマンス最適化とパフォーマンス最適化結果の紹介です。

開発効率を向上させる方法

1. システムの階層化設計

システムは階層化されたアーキテクチャ設計を採用しています。推定システム全体を、基礎となるアーキテクチャ層、中間テンプレート層、上部構造層を含む 3 つの層に分割します。

基盤となるアーキテクチャ層は、主に非同期メカニズム、タスクキュー、同時スケジューリング、ネットワーク通信などを提供します。

中間テンプレート層は主に、クエリ管理、キャッシュ管理、モデル読み込み管理、モデル計算管理などのモデル計算に関連するコンポーネントを提供します。

上位インターフェイス層は主にハイレベル インターフェイスを提供しており、企業はこの層インターフェイスを実装するだけで済み、コード開発が大幅に軽減されます。

システムの階層構造設計により、最下層と中間層のコードを異なるビジネス間で再利用できるため、開発は小規模なシステムの開発のみに集中する必要があります。最上層のコード量。同時に、上位インターフェイス層のコード開発をさらに削減する方法はないか、ということも考えています。以下で詳しく紹介していきましょう。

2. ユニバーサルクエリのカプセル化

ダイナミック PB テクノロジーに基づく特徴クエリと特徴分析によって形成される一般的なソリューションのカプセル化を通じて、テーブル名、クエリ KEY、キャッシュを構成することができます。 XML 、クエリの依存関係などを介してのみ、機能のクエリ、解析、キャッシュのプロセス全体を実現できます。

下の図に示すように、数行の構成で複雑なクエリ ロジックを実装できます。同時に、クエリのカプセル化によってクエリ効率が向上します。

3. 特徴計算のカプセル化

特徴計算は、​​推定システム全体の中でコード開発の複雑さが最も高いモジュールであると言えます。特徴?計算についてはどうですか?

特徴量計算にはオフラインプロセスとオンラインプロセスが含まれます。オフライン プロセスは実際にはオフライン サンプルであり、TF Recocd の形式など、オフライン トレーニング プラットフォームに必要ないくつかの形式を取得するために処理されます。オンライン プロセスは主にオンライン リクエストに対していくつかの特徴計算を実行し、処理を通じてオンライン予測プラットフォームに必要ないくつかの形式を取得します。実際、特徴処理の計算ロジックはオフライン プロセスでもオンライン プロセスでもまったく同じです。しかし、オフライン処理とオンライン処理では計算プラットフォームが異なり、使用言語も異なるため、特徴量計算を実装するには複数のコードを開発する必要があり、以下の3つの問題があります。

#一貫性の保証が難しい

一貫性の保証が難しい根本的な理由は、機能を統合するのが難しいことです。オフライントレーニングとオンライン予測の処理ロジック。一方で、アルゴリズムの効果に影響を及ぼしますが、他方では、開発プロセス中の 1 回限りの検証コストが比較的高くなります。

効率が悪い

新しい機能を追加する場合、オフライン処理とオンライン処理を含む複数のコードを開発する必要があり、開発効率が非常に低くなります。 。

再利用の難しさ

再利用が難しい主な理由は、フレームワークが再利用機能をサポートしていないため、異なるビジネス間で特徴量計算が重複することです。 . 非常に使いにくくなります。

上記は、特徴量計算フレームワークに存在するいくつかの問題です。

これらの問題を解決するために、以下の4つのポイントに従って徐々に解決していきます。

まず、演算子の概念と抽象的な特徴計算を演算子のカプセル化に提案します。次に、演算子をカプセル化した後、演算子ライブラリを構築します。これにより、ビジネス間で演算子を再利用できるようになります。次に、演算子に基づいて特徴量計算記述言語 DSL を定義します。この記述言語により、特徴量計算の構成表現を完成させることができます。最後に、前述したように、オンライン プロセスとオフライン プロセスには複数のロジックが存在し、論理的な不整合が発生するため、ワンタイム機能の問題を解決する必要があります。

上記の 4 つのポイントは、特徴量計算フレームワークをカプセル化する方法に関する私たちのアイデアです。

#演算子の抽象化

• 演算子の抽象化を実現するには、まずデータ プロトコルの統一を達成する必要があります。当社では、ダイナミック PB テクノロジーを使用して、フィーチャの元のデータ情報に基づく統一データに従ってフィーチャを処理し、オペレータ カプセル化のデータ基盤を提供します。次に、特徴処理プロセスをサンプリングしてカプセル化し、特徴計算プロセスを解析、計算、アセンブリ、例外処理に抽象化し、計算プロセス API を統合して演算子の抽象化を実現します。

演算子ライブラリの確立

• 演算子の抽象化が完了したら、演算子ライブラリを構築できます。オペレータ ライブラリは、プラットフォーム一般オペレータ ライブラリとビジネスカスタマイズ オペレータ ライブラリに分かれています。プラットフォームの一般的な演算子ライブラリは、主に企業レベルの再利用を実現するために使用されます。ビジネス カスタム オペレーター ライブラリは、グループ内での再利用を実現するために、ビジネスのいくつかのカスタム シナリオと特性を主な目的としています。演算子のカプセル化と演算子ライブラリの構築により、複数のシナリオでの特徴量計算の再利用を実現し、開発効率を向上します。

• 計算記述言語 DSL

特徴量計算の設定式とは、DSL と呼ばれる特徴量計算式を定義する設定済み言語を指します。設定言語により、演算子や四則演算などの多段の入れ子表現を実現できます。以下の最初のスクリーンショットは、構成された言語の特定の構文を示しています。

#特徴計算の構成言語を通じてどのようなメリットが得られるでしょうか?

まず、特徴量計算全体をコンフィグレーションで完了できるため、開発効率が向上します。

2 番目に、構成された特徴計算の式を公開することで、特徴計算のホット アップデートを実現できます。

3 番目に、トレーニングと予測は同じ特徴計算構成を使用して、オンラインとオフラインの一貫性を実現します。

これが特徴量計算式によるメリットです。

• 特徴の一貫性

前述したように、特徴の計算はオフラインプロセスとオンラインプロセスに分かれています。オフラインとオンラインのマルチプラットフォームの理由により、論理計算に一貫性がありません。この問題を解決するために、特徴コンピューティング フレームワークのクロスプラットフォーム実行機能を特徴コンピューティング フレームワークに実装しました。コア ロジックは C で開発され、C インターフェイスと Java インターフェイスは外部に公開されます。パッケージ化と構築のプロセス中に、C の so ライブラリと jar パッケージをワンクリックで実装できるため、オンライン計算の場合は C プラットフォームで、オフラインの Spark プラットフォームまたは Flink プラットフォームでは特徴計算を実行でき、特徴計算で表現できるようになります。特徴量の計算 オンラインとオフラインのロジックの一貫性を実現します。

上記は、特徴量計算の具体的な状況を説明しています。特徴量コンピューティングがこれまでに達成した成果の一部を見てみましょう。

現在120社のオペレーターを蓄積しており、特徴量計算のDSL言語により設定を実現し、特徴量計算全体を完了することができます。当社が提供するクロスプラットフォーム操作機能により、オンラインとオフラインのロジックの不一致の問題が解決されます。

下図のスクリーンショットは、少ない構成で特徴量計算のプロセス全体を実現でき、特徴量計算の開発効率が大幅に向上することを示しています。

上記では、開発効率を向上させるための検討を紹介しました。一般に、システムの階層設計を通じてコードの再利用を改善し、クエリ、抽出、モデル計算をカプセル化することで構成可能な開発プロセスを実現できます。

4. モデル計算のカプセル化

モデル計算もカプセル化の形式を採用します。構成表現形式により、モデルの読み込み、モデルの入力構造、モデルの計算等を実現し、数行の構成でモデル計算全体の表現処理を実現します。

# モデルのリアルタイム実装

モデルのリアルタイム実装ケースを見てみましょう。

1. リアルタイム プロジェクトの背景

なぜこのようなモデル リアルタイム プロジェクトを行う必要があるのでしょうか?

主な理由は、従来のレコメンド システムはユーザーのレコメンデーション結果を毎日更新するシステムであり、リアルタイム性が非常に低く、リアルタイム性が要求されるシナリオなどに対応できないためです。ライブ ブロードキャスト シーン、またはより高いリアルタイム要件が必要なその他のシナリオ。

もう 1 つの理由は、従来のサンプル作成方法には特徴の交差の問題があることです。機能交差とは何ですか?次の図は、特徴交差の根本的な理由を示しています. サンプルの結合のプロセスでは、「T-1」時点で推定されたモデルの構造を使用し、それを「T」時点の特徴と結合します。交差点が生じます。特徴の交差は回線ネットワークの推奨効果に大きく影響します。リアルタイム問題とサンプル交差の問題を解決するために、予測システムにそのようなモデルリアルタイムソリューションを実装しました。

2. リアルタイム ソリューションの紹介

モデル リアルタイム ソリューションは 3 つの次元から精緻化されています。

• サンプルのリアルタイム生成
• 増分モデル トレーニング
• リアルタイム予測システム

サンプルはリアルタイムで生成されます。オンライン予測システムに基づいて、予測システムの機能をリアルタイムで Kafka に実装し、RACE ID の形式で関連付けることにより、サンプルが数秒以内にディスクに配置されることを保証し、問題を解決できます。機能交差。

モデルの増分トレーニング。サンプルが数秒で​​ディスクに配置された後、トレーニング モジュールを変更してモデルの増分トレーニングを実装し、モデルの分単位の更新を実現できます。

予測システムはリアルタイムです。分単位でモデルをエクスポートした後、モデルプッシュサービス「Push Server」を通じて最新モデルをオンライン予測システムにプッシュすることで、現場予測システムが最新モデルを予測に利用できるようになります。

一般的に言えば、リアルタイム モデル ソリューションは、数秒でサンプル配置、分レベルのトレーニング、分レベルのモデルのオンライン更新を実現することです。

当社の現在のモデルのリアルタイム ソリューションは、複数のシナリオに実装されています。リアルタイムモデルソリューションにより、業績は大幅に向上しました。

上の図は、主にモデル リアルタイム ソリューションの具体的な実験データを示しています。段階的なトレーニングが見られ、トレーニング期間は短いほど良いことがわかります。具体的なデータから、15 分のサイクルの効果が 2 時間、10 時間、または 1 日の効果よりもはるかに大きいことがわかります。現在のモデルのリアルタイム ソリューションには、標準化されたアクセス プロセスがすでに組み込まれており、バッチ処理でビジネスにより良い結果をもたらすことができます。

上記では、予測システムがコンピューティングのパフォーマンスを向上させる方法、開発効率を向上させる方法、エンジニアリング手段を通じてプロジェクトのアルゴリズムを改善する方法の 3 つの側面での探求と試みを紹介しています。

見積りシステム全体のプラットフォーム価値、あるいは見積りシステム全体のプラットフォームの目的は、「速い、良い、経済的」の 3 つの言葉に要約できます。

「クイック」とは、先ほど紹介したアプリケーション構築のことです。継続的にアプリケーションを構築することで、ビジネスの繰り返しがより効率化されることを期待しています。

「良好」とは、リアルタイム モデル ソリューションや特徴量計算によるオンラインおよびオフラインの論理的一貫性ソリューションなどのエンジニアリング手段を通じて、ビジネスにより良い結果をもたらすことを期待していることを意味します。

「保存」とは、推定されたシステムのより高いパフォーマンスを使用することを意味します。これにより、より多くのコンピューティング リソースが節約され、コンピューティング コストが節約されます。

#今後もこの 3 つの目標に向かって取り組んでまいります。

以上、クラウド音楽予測システムの紹介でしたが、ここで私の共有は終了です、皆さんありがとうございました!

以上がNetEase Cloud Music アルゴリズム プラットフォームの研究開発専門家 Huang Bin 氏: NetEase Cloud Music オンライン予測システムの実践と考察の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。