アンプ は、Amazon の新しいライブ ラジオ アプリです。 Amp を使用すると、独自のラジオ番組をホストして Amazon Music カタログから曲を再生したり、他の Amp ユーザーがホストしている番組を聴いたりすることができます。 コンテンツが豊富で多様な環境では、各ユーザーの好みに合わせてユーザー エクスペリエンスを調整することが重要です。これにより、ユーザーは好みの番組を簡単に見つけたり、楽しめる新しいコンテンツを見つけたりすることができます。
Amp は機械学習 (ML) を使用して、ライブおよび今後の Amp ショーのパーソナライズされた推奨事項をアプリのホームページに表示します。 レコメンデーションは、番組の人気 (リッスン数やいいね! 数など)、クリエイターの人気 (最近の番組が再生された合計回数など)、およびユーザーの個人的な親和性を表す機能を使用して、ランダム フォレスト モデルを使用して計算されます。番組のトピックと作成者に。 アフィニティは、ユーザーの行動データから暗黙的に計算されるか、ユーザー プロファイルで提供される関心のあるトピック (ポップ ミュージック、野球、政治など) から明示的に計算されます。
これは、Amp にデータ分析と ML を使用し、パーソナライズされたショーのおすすめリスト プラットフォームを作成するシリーズのパート 2 です。 このプラットフォームは、3 年 2022 月のローンチ以来、追跡されるカスタマー エンゲージメント メトリクス (ショーを高く評価する、クリエイターをフォローする、今後のショーの通知を有効にする) が XNUMX% 増加したことを示しています。
参照する 第1部 データおよび分析システムを使用して、行動データがどのように収集および処理されたかを学びます。
ソリューションの概要
次のアーキテクチャ図に示すように、Amp の ML ベースのショー レコメンダーには XNUMX つの主要コンポーネントがあります。
- アンプモバイルアプリ。
- いいねやフォローなどの行動データを収集するバックエンド サービスや、番組のライブ配信時のステータス更新などの番組関連情報をブロードキャストします。
- 行動データとショー データのリアルタイムの取り込み、およびリアルタイム (オンライン) のフィーチャ コンピューティングとストレージ。
- バッチ (オフライン) 機能のコンピューティングとストレージ。
- 番組のリストを取得するために、アプリ バックエンドからの着信要求を処理するレコメンダー システム。 これには、パーソナライズされた機能とパーソナライズされていない機能に基づいてショーをランク付けするためのリアルタイムの推論が含まれます。
この投稿では、次の詳細を説明するために、パート 3、4、および 5 に焦点を当てます。
次の図は、高レベルのアーキテクチャとそのコンポーネントを示しています。
次のセクションでは、リアルタイムの機能コンピューティング、バッチ機能のコンピューティング、リアルタイムの推論、運用の健全性、および観察した結果について詳しく説明します。
リアルタイムの特徴計算
番組のいいねやリッスン カウントなどの一部の機能は、継続的にストリーミングしてそのまま使用する必要がありますが、5 分を超えるリスニング セッション数などの他の機能は生データとしてリアルタイムで変換する必要もあります。セッションがストリーミングされます。 推論時に値を計算する必要があるこれらのタイプの機能は、 ポイントインタイム （ピット）機能。 PIT 機能のデータは迅速に更新する必要があり、最新バージョンは低レイテンシ (20 ショーでユーザーあたり 1,000 ミリ秒未満) で読み書きする必要があります。 また、データの欠落や部分的な不足により、レコメンデーションが低下し、カスタマー エクスペリエンスが低下する可能性があるため、データは耐久性のあるストレージに保存する必要があります。 読み取り/書き込みレイテンシーに加えて、PIT 機能には短い反射時間も必要です。 リフレクション時間は、貢献イベントが発行された後、機能が読み取り可能になるまでにかかる時間です。たとえば、リスナーがショーを気に入ってから PIT LikeCount 機能が更新されるまでの時間です。
データのソースは、アプリに直接サービスを提供するバックエンド サービスです。 一部のデータはメトリクスに変換され、メトリクスによってブロードキャストされます。 Amazon シンプル通知サービス (Amazon SNS) を ML 機能変換パイプラインなどのダウンストリーム リスナーに送信します。 MemoryDB などのインメモリ データベースは、耐久性のあるストレージと大容量での超高速パフォーマンスを実現する理想的なサービスです。 機能を変換して MemoryDB に書き込むコンピューティング コンポーネントは Lambda です。 アプリのトラフィックは、時間と日に応じて、ピークとディップの毎日および毎週のパターンに従います。 Lambda では、受信するイベントの量に合わせて自動スケーリングできます。 個々のメトリック変換の独立した性質により、それ自体がステートレスなサービスである Lambda も、この問題に適しています。 パッティング Amazon シンプル キュー サービス Amazon SNS と Lambda の間の (Amazon SQS) は、メッセージの損失を防ぐだけでなく、事前に構成された Lambda 同時実行数の制限では不十分なトラフィックの予期しないバーストに対するバッファーとしても機能します。
バッチ機能計算
過去の行動データを使用して進化し続けるユーザーの好みを表す機能は、計算がより複雑であり、リアルタイムで計算することはできません。 これらの機能は、XNUMX 日 XNUMX 回など、頻繁に実行されるバッチ プロセスによって計算されます。 バッチ機能のデータは、データのフィルタリングと集計のための高速なクエリをサポートする必要があり、長期間にわたる可能性があるため、ボリュームが大きくなります。 バッチ機能も取得され、リアルタイム推論の入力として送信されるため、低レイテンシで読み取る必要があります。
バッチ機能コンピューティング用の生データの収集には、PIT 機能に必要な XNUMX 分未満の反映時間要件がないため、イベントをより長くバッファリングし、メトリックをバッチで変換することが実現可能になります。 このソリューションは、マネージド サービスである Kinesis Data Firehose を利用して、ストリーミング データを複数の宛先にすばやく取り込みます。 Amazon シンプル ストレージ サービス (Amazon S3) メトリクスを S3 データ レイクに永続化して、オフライン計算で利用できるようにします。 Kinesis Data Firehose は、イベント バッファと Lambda の統合を提供し、これらのメトリクスを簡単に収集、バッチ変換、および Amazon S3 に保存して、後でバッチ機能コンピューティングで利用できるようにします。 バッチ機能の計算には、PIT 機能と同じような低レイテンシーの読み取り/書き込み要件がないため、これらの大量のビジネス指標を保存するための低コストで耐久性のあるストレージを提供する Amazon S3 がより適切な選択肢になります。
最初の ML モデルは、過去 21 か月間に取得されたデータを使用して毎日計算された 2 のバッチ機能を使用します。 このデータには、ユーザーごとの再生履歴とアプリ エンゲージメント履歴の両方が含まれ、ユーザー数とアプリの使用頻度に応じて増加します。 この規模の特徴量エンジニアリングでは、必要な入力データを取得し、並行して処理し、結果を永続ストレージにエクスポートするための自動化されたプロセスが必要です。 処理インフラストラクチャは、計算中にのみ必要です。 SageMakerの処理 分散データ処理ジョブを大規模に実行するために必要な Apache Spark およびその他の依存関係を含むビルド済みの Docker イメージを提供します。 Processing ジョブの基盤となるインフラストラクチャは、SageMaker によって完全に管理されます。 クラスター リソースは、ジョブの実行中にプロビジョニングされ、ジョブが完了するとクリーンアップされます。
バッチ プロセスの各ステップ (データ収集、機能エンジニアリング、機能の永続化) は、エラー処理、再試行、およびその間の状態遷移を必要とするワークフローの一部です。 と AWSステップ関数、ステートマシンを作成し、ワークフローを前処理と後処理のいくつかのステップに分割し、機能を SageMaker Feature Store または他のデータを Amazon S3 に保持するステップに分割できます。 Step Functions のステート マシンは、次の方法でトリガーできます。 アマゾンイベントブリッジ 毎日 10:00 PM UTC など、設定されたスケジュールで実行されるようにバッチ コンピューティングを自動化します。
機能が計算された後、モデルの再トレーニングだけでなく、推論中に読み取られるようにバージョン管理して保存する必要があります。 独自の機能ストレージおよび管理サービスを構築するのではなく、SageMaker Feature Store を使用できます。 Feature Store は、ML モデルの機能を保存、共有、管理するための、完全に管理された専用のリポジトリです。 ML 機能の履歴をオフライン ストア (Amazon S3) に保存し、オンライン ストアに API を提供して、最新の機能を低レイテンシーで読み取ることができるようにします。 オフライン ストアは、さらなるモデルのトレーニングと実験のために履歴データを提供できます。オンライン ストアは、リアルタイムの推論のための機能を取得するために、顧客向け API によって呼び出すことができます。 よりパーソナライズされたコンテンツを提供するためにサービスを進化させるにつれて、追加の ML モデルをトレーニングし、Feature Store の助けを借りて、これらのモデル間で機能を検索、発見、再利用することを期待しています。
リアルタイム推論
通常、リアルタイムの推論では、エンドポイントの背後で ML モデルをホストする必要があります。 これは Web サーバーまたはコンテナーを使用して行うことができますが、これには ML エンジニアリングの労力とインフラストラクチャを管理および維持する必要があります。 SageMaker を使用すると、ML モデルをリアルタイムのエンドポイントに簡単にデプロイできます。 SageMaker を使用すると、ML モデルをトレーニングしてアップロードし、SageMaker エンドポイントを作成して構成することでそれらをホストできます。 リアルタイムの推論は、Amp のホームページで閲覧される番組をランキングするための低遅延要件を満たします。
管理されたホスティングに加えて、SageMaker は管理されたエンドポイントのスケーリングを提供します。 SageMaker 推論を使用すると、最小インスタンス数と最大インスタンス数、およびスケーリングをトリガーするターゲット使用率を使用して Auto Scaling ポリシーを定義できます。 このようにして、需要の変化に応じて簡単にスケールインまたはスケールアウトできます。
運用の健全性
このシステムがリアルタイム機能計算のために処理するイベントの数は、アプリの使用の自然なパターン (時間帯または曜日に基づくトラフィックの増減) に応じて変化します。 同様に、リアルタイムの推論のために受け取るリクエストの数は、同時アプリ ユーザーの数に比例します。 また、これらのサービスは、人気クリエイターによるソーシャル メディアでのセルフ プロモーションにより、予想外のトラフィックのピークを迎えます。 システムがスケールアップおよびスケールダウンして着信トラフィックを適切かつ質素に処理できることを確認することは重要ですが、運用メトリックを監視し、予期しない運用上の問題を警告して、データと顧客へのサービスの損失を防ぐことも重要です。 これらのサービスの正常性を監視するには、 アマゾンクラウドウォッチ. CloudWatch を使用すると、操作の障害やレイテンシーなどの重要なサービスの正常性指標や、メモリ、ディスク、CPU 使用率などの使用率指標をすぐに利用できます。 当社の開発チームは、メトリクス ダッシュボードと自動モニタリングを使用して、高可用性 (99.8%) と低レイテンシ (エンドツーエンドで 200 ミリ秒未満でユーザーごとに推奨番組を取得する) でクライアントにサービスを提供できるようにします。
結果の測定
この投稿で説明する ML ベースのショー レコメンダーの前は、より単純なヒューリスティック アルゴリズムが、プロフィールで自己報告されたユーザーの個人的な関心トピックに基づいて Amp ショーをランク付けしていました。 A/B テストをセットアップして、ML ベースのレコメンダーへの切り替えの影響を、ユーザーの過去のアプリ操作からのデータを使用して測定しました。 成功の指標として、リスニング時間やエンゲージメント アクション (ショーを高く評価する、ショー クリエーターをフォローする、通知をオンにする) の数などの指標の改善を特定しました。 50% のユーザーが ML ベースのレコメンダーを介してランク付けされたショーのレコメンデーションを受け取る A/B テストでは、カスタマー エンゲージメント メトリックが 3% 向上し、再生時間が 0.5% 改善されたことが示されました。
まとめ
専用のサービスを使用して、Amp チームは、この投稿で説明されているように、パーソナライズされた番組レコメンデーション API を 3 か月以内に本番環境にリリースすることができました。 また、このシステムは、ユーザーの流入を生み出す可能性がある、有名な番組ホストやマーケティング キャンペーンによって作成される予測不可能な負荷にも対応できます。 このソリューションは、処理、トレーニング、およびホスティングにマネージド サービスを使用するため、システムの日常的なメンテナンスに費やす時間を削減できます。 また、CloudWatch を介してこれらすべてのマネージド サービスを監視し、運用中のシステムの継続的な健全性を確保することもできます。
Amp の ML ベースのレコメンダーの最初のバージョンをルールベースのアプローチ (顧客の関心のあるトピックのみで並べ替える) に対して A/B テストを行ったところ、ML ベースのレコメンダーがより多様なトピックからの高品質のコンテンツに顧客をさらすことが示されました。 、これにより、フォローと有効な通知の数が増えます。 Amp チームは、関連性の高い推奨事項を提供するために、モデルの改善に向けて継続的に取り組んでいます。
Feature Store の詳細については、次の Web サイトをご覧ください。 Amazon SageMaker フィーチャーストア で他の顧客のユースケースをチェックしてください AWS機械学習ブログ.
著者について
チューリップ・グプタ アマゾン ウェブ サービスのソリューション アーキテクトです。 彼女は Amazon と協力して、AWS でテクノロジー ソリューションを設計、構築、デプロイしています。 彼女は、顧客が AWS にソリューションをデプロイする際にベスト プラクティスを採用するのを支援しており、分析と ML の愛好家でもあります。 余暇には、水泳、ハイキング、ボードゲームを楽しんでいます。
デビッドクオ アマゾン ウェブ サービスのソリューション アーキテクトです。 彼は AWS の顧客と協力して、AWS でテクノロジー ソリューションを設計、構築、デプロイしています。 彼はメディアおよびエンターテイメントの顧客と協力しており、機械学習技術に関心を持っています。 余暇には、余暇を何をすべきかを考えています。
マノリア・マコーミック Amazon の Amp のシニア ソフトウェア開発エンジニアです。 彼女は、AWS を使用して分散システムを設計および構築し、顧客向けアプリケーションにサービスを提供しています。 彼女は余暇に新しいレシピを読んだり料理したりすることを楽しんでいます。
ジェフ・クリストファーセン Amazon の Amp のシニア データ エンジニアです。 彼は、実用的な洞察を促進する AWS でのビッグデータ ソリューションの設計、構築、デプロイに取り組んでいます。 スケーラブルで自動化されたソリューションを採用する社内チームを支援し、分析とビッグデータの愛好家です。 余暇には、彼がスキーを履いていないときは、マウンテン バイクに乗っているのを見つけることができます。
