広告および推奨システムに機械学習モデルを導入するための 2 つのアーキテクチャ

広告および推奨システムは、機械学習の最も成熟した応用分野です。では、広告システムや推奨システムでは、機械学習モデルをオンラインでどのように展開するのでしょうか?

[[188821]]

1. 予測機能の導入

私が機械学習を学び始めた頃は、広告・レコメンデーションシステムのプロセスは、1) オフライン部分では、ユーザーと広告（アイテム）属性からユーザーとアイテムの特徴を抽出し、抽出した特徴をログにマージしてトレーニングデータを生成し、機械学習モデルをトレーニングする、2) オンライン部分では、リクエストが入り、リクエスト内のユーザーとアイテムの特徴をユーザーと広告（アイテム）属性から抽出し、これらの特徴をリクエストにマージして予測インスタンスを生成し、オンラインモデルを使用して予測結果を得る、という流れだと思っていました。

しかし、このアーキテクチャには 2 つの問題があります。1) ユーザーと広告 (アイテム) の属性から特徴を抽出するためのプログラムがオンラインとオフラインの 2 セットあり、これら 2 セットのプログラムは完全に一貫している必要があります。ただし、パラメータ調整のため、特徴抽出は機械学習システムで最も頻繁に変更されるモジュールです。頻繁に変更されるモジュールは一貫性を保つ必要がありますが、これは困難です。では、一連のプログラムを強制的に使用することはできるでしょうか? たとえば、特徴抽出モジュールと特徴処理モジュールを .so ファイルに書き込みます。これにも問題があります。オフラインでは、エンジニアが機能を調整できるようにするために迅速な変更が必要であり、一部のトレーニング フレームワーク (Spark など) が使用される場合があります。一方、オンラインでは、プログラムは高速かつリアルタイムである必要があり、エンジニアは厳密にコーディングする必要があります。厳密な .so ファイルとして記述されているため、オンライン要件を満たすことができますが、すぐに変更することはできず、Spark で使用することはできません。 2) オンライン特徴抽出は、特にオンラインスループットが非常に高い場合には、非常に高速である必要があります。ただし、広告の過去のクリック率など、一部の重い特徴は短時間で抽出できません (この機能を生成するには、一定期間のクリック ログを走査する必要があります)。

勉強中、この 2 つの疑問が長い間私を悩ませていましたが、2014 年に Redis という魔法のツールについて知るようになりました。 Redis は、クラスター モード、永続性、およびキー値データ構造をサポートするオープン ソースのインメモリ データベースです。使用する場合、Redis を巨大なハッシュ テーブルとして考えることができます。 Redis はバックグラウンド開発でキャッシュ サーバーとしてよく使用され、その後、広告や推奨システムの機能サーバーとしてエンジニアによって使用されるようになりました。エンジニアは、ユーザーと広告（アイテム）の ID をキーとして使用し、ユーザーと広告（アイテム）の特徴を値として Redis に保存します。このようにして、オンライン プログラムは、特徴を知るためにユーザーと広告（アイテム）の ID のみを必要とします。 Redis 導入後の広告・推薦システムのプロセスは次のようになります。1) オフライン部分では、ユーザーと広告 (アイテム) の属性からユーザーと広告 (アイテム) の特徴を抽出し、抽出した特徴をログにマージしてトレーニング マシンのトレーニング データを生成し、抽出した特徴をオンライン Redis サーバーにアップロードします。2) オンライン部分では、リクエストが来ると、Redis サーバーからユーザーと広告 (アイテム) の特徴を取得し、リクエストに特徴をマージして予測インスタンスを生成し、オンライン モデルを使用して予測結果を取得します。

このアーキテクチャにはバリエーションもあります。オフラインで特徴を抽出した後、トレーニング データは生成されずに直接 Redis に送信され、Storm を使用してトレーニング データをオンラインでリアルタイムにつなぎ合わせます。しかし、私はこの変異体の原因と結果についてあまり知らないので、詳細には議論しません。このアーキテクチャは、予測機能 (つまり、トレーニング済みのモデル) をオンラインで展開します。次のアーキテクチャと区別するために、このアーキテクチャを予測機能オンライン アーキテクチャと呼びます。

2. 予測結果はオンラインで公開されます

予測機能のオンライン アーキテクチャを理解した後、私はそれを広告および推奨システム用モデルのオンライン展開の「正統派」と見なします。 そのため、2014年に別の建築物に触れたとき、私はそれを心の中で拒否しました。このアーキテクチャの重要なポイントは、予測結果をオンラインにすることです。具体的なプロセスは次のとおりです。1)オンラインでは、ユーザーと広告（アイテム）の属性からユーザーとアイテムの特徴を抽出し、抽出した特徴をログにマージしてトレーニングデータを生成し、機械学習モデルをトレーニングします。ほぼすべての可能なリクエストの特徴をマージして予測インスタンスを生成し、モデルを使用して予測結果を取得します。2)オンラインは非常に簡単で、オフラインでアップロードされた予測結果にアクセスします。ここで少し理解しにくいのは、「ほぼすべての可能なリクエストを尽くす」ということです。どのようにして、これほど多くの可能なリクエストを尽くすことができるのでしょうか? (架空の) Weibo 広告システムの可能なリクエストはたくさんあるように見えますが、各ユーザーは一定数の広告に一致すればいいだけです。そのため、Weibo 広告システムの予測結果「userid、adid1、adid2...、adidn」がオンラインでアップロードされます。広告の表示を要求するためにユーザー ID がオンラインでアップロードされると、オンライン モジュールは特定のロジックに従って予測結果でユーザーに対応する広告を返します。このアーキテクチャは予測結果をオンラインで展開します。これを予測結果オンライン アーキテクチャと呼びます。

徐々に、予測結果をオンラインで公開することの利点を理解し始めました。結果を予測するためのオンライン アーキテクチャは、機械学習プロセス全体と制御ロジックの大部分をオフラインに移行し、さまざまなオンライン リスクを回避します。この方法により、非力なエンジニアでも、非力なマシンを使用してオンライン モジュールを処理できるようになります。結局のところ、オンライン モジュールでは、少量の制御ロジックと表示を実装するだけで済みます。これにより、広告システムや推奨システムの構築の難易度が大幅に軽減されます。

私が正式に就職してからは、業務支援を行うグループのレコメンデーションシステムは、予測結果をオンラインで公開するアーキテクチャを採用しました。一時的にアイテムを追加したり削除したりする必要がある場合があり、データの再実行に多くの時間が浪費されていることがわかりました。アイテムが追加または削除されると、予測結果をオンラインにする推奨システムは予測データを再生成する必要があります (そのため、以前に実行されたデータには、追加するアイテムがないか、削除するデータがあります)。もう 1 つの問題は、予測結果のオンライン アーキテクチャに遅延があることです。今日オンラインに表示されるのは昨日準備された予測結果であり、今日準備された予測結果が表示されるのは明日まで待たなければならないため、ペースが遅くなります。 ***別の問題もあります。結果を予測するためのオンライン アーキテクチャは、ほぼすべての可能なリクエストが使い果たされるシナリオにのみ適用できます。たとえば、予測結果オンライン アーキテクチャは、検索広告システムではすべての可能なリクエストに対応できないため、検索広告システムには適していません。

3. 結論

予測機能オンライン アーキテクチャは、予測結果オンライン アーキテクチャの適用可能なシナリオをカバーできますが、予測結果オンライン アーキテクチャは、予測機能オンライン アーキテクチャの適用可能なシナリオをカバーすることはできません。同時に、予測機能のオンライン アーキテクチャはより柔軟になります。予測機能オンライン アーキテクチャは、機械学習モデルを展開するための正当な方法です。

予測結果のオンラインアーキテクチャの利点は、比較的簡単なことです。結果を予測するためのオンライン アーキテクチャは、機械学習プロセス全体と制御ロジックの大部分を統合し、さまざまなオンライン リスクを回避します。機械、時間、人員などさまざまな条件が不十分な場合は、予測結果をオンラインで公開することが良い選択です。予測結果オンライン アーキテクチャは、機械学習モデルを展開する従来とは異なる方法です。孫子の兵法にはこうあります。「団結には普通を使い、勝利には普通でないものを使おう」。どのアーキテクチャを使用するかを選択するには、慎重な分析と検討が必要です。

[この記事は51CTOコラムニスト「Li Li」によるオリジナル記事です。転載する場合は51CTOに連絡して許可を得てください]

この著者の他の記事を読むにはここをクリックしてください