AWS Startup ブログ

【開催報告&資料公開】ML@Loft #3 – Recommendation

AWS 機械学習ソリューションアーキテクトの宇都宮 (Twitter: @shokout) です。本ブログでは ML@Loft 第３回「レコメンド」の開催概要を報告します。

ML@Loft は、 機械学習を AWS 上でプロダクション運用しているデベロッパー・データサイエンティストのためのコミュニティイベントです。毎月テーマを設定し、前半は各分野のエキスパートの方々からのLT、後半は機械学習のサービス導入のノウハウや様々なツラミについて、LT のご講演者の方々を交えて参加者全員参加型のお悩み相談ラウンドテーブルという構成で AWS Loft Tokyo にて実施しています。

第２回 [Blog] は、第１回で好評だった MLOps のテーマを引き続き、そして今回 6/21 (金) の第３回は過去の参加者アンケートで最も人気の高かった「レコメンド」をテーマに、豪華な LT 登壇者の方々にご協力いただき開催しました。

次回 7/19 (金) は “Edge Deep Learning” をテーマにお申し込み受け付け中です、ぜひお申込み下さい！ [ML@Loft #4 Edge 登録ページはこちら]

当日のタイムテーブル

1. 19:05 – 19:45: LTセッション (10分×4セッション）

Graph Convolutional Networksを使った推薦システム  (エムスリー株式会社 西場正浩 氏)

まず、エムスリー西場さんからは、エムスリーにおけるニュース等のレコメンドシステムで利用している Graph Convolutional Network (GCN) についてお話しいただきました。 エムスリーでは30万人のお医者様という限られたユーザーへのニュースのレコメンデーションを考える際、対象とするアイテムへのアクセス数が少ないため A/B テストも難しい、という課題があります。またユーザーの好みには偏りがあり、inactive なユーザーへもいい感じにアイテムを出し分け、全てのテキスト記事から満遍なくレコメンドをしたいというモチベーションがあります。

30万人という限定されたユーザーだからこそ直接的な Graph Embedding 手法も検討できるということで、GCN と Latent Cross を組み合わせた手法を紹介されました。クリックによるユーザーxアイテムの二部グラフを用いて、Graph Convolution には message passing、属性データには Latent cross、クリックしたアイテム、クリックしたユーザーの embedding 平均をとることで各ノードの embedding を学習します。GCN はコールドスタートにも向いていて、実際オフライン評価を行うと、RankingModel と遜色ない結果で、属性データを入れることで inactive なユーザーにも自然な推薦になり、エムスリーの編集部による定性的な調査においても評価が良かったそうです。現状はユーザークラスタに対してクリックに応じてアイテムを埋め込むモデルになっているため、全てのユーザーに人気のアイテムなど品質を考慮したレコメンドが今後の課題とのことで、限定されたユーザーの属性を活かした GCN の手法をご紹介いただきました。

 

 
登壇 スライド はこちら

 

AbemaTVを支える推薦システム (株式会社サイバーエージェント 前田英行 氏)

次にサイバーエージェントの前田さんより、インターネットテレビ AbemaTV の推薦システムについてご紹介いただきました。 AbemaTV の推薦機能としては、選択中の番組を起点にその関連番組を番組詳細ページなどで推薦する場合と、ユーザーの直近の視聴履歴を元にビデオトップページなどで番組を推薦する二つの機能があります。また、推薦システムとしては、下記の二つの処理から構成されています。１つは、事前に計算された番組の類似度に基づき候補を絞る「推薦候補生成処理」、もう一つは、推薦候補生成処理で生成された推薦候補の中からユーザーとの関連度スコアを付与し推薦結果を並び替える「リランキング処理」です。これらの二つをアーキテクチャ上で分離します。

推薦候補生成処理では、データ処理基盤 Patriot 上でユーザーの視聴履歴のデータを元に類似番組の事前計算を行い、似ている番組を DB に書き出し、Recommendation API で推薦候補を取得します。また、直近の視聴履歴に基づく推薦は、ストリーム処理エンジン Zero から直近の視聴データを取得し、DB の結果とマージし推薦結果を返します。リランキング処理に関して、モデル学習時は Patriot から視聴履歴、ユーザーの行動ログや番組メタ情報を取り出し、ランキング学習をします。推論時は、推薦候補を Recommendation API から受け取り、ユーザーデモグラ情報・番組メタ情報などの特徴量を DB から取得し、上記学習モデルをデプロイしたモデルサーバーで、ユーザーと各番組の関連度スコア計算を行い、Recommendation API で関連度スコア順に並び替え、Client に結果を返します。このように推薦システムを推薦候補生成とリランキング処理の２段階処理に分けることで、計算時間の削減と、リランキングでよりパーソナライズされた精度の高い推薦を実現するなど、様々な変更に柔軟に対応できるようになっています。

登壇 スライド はこちら

 

Gunosyにおけるパーソナライズシステム (株式会社Gunosy 小澤俊介 氏)

次に Gunosy の小澤さんから、Gunosy におけるパーソナライズシステムとして、情報キュレーションサービスにおけるデータ分析とレコメンド開発についてお話しいただきました。

ニュース推薦の特徴としては、1日に数千記事、ユーザーの興味サイクルの速さという更新性の高さや、アイテム価値の時間減衰の観点から、既存アルゴリズムの単純適用の難しさという課題があります。そのためニュース推薦の要求仕様では、興味を捉えられるよう話題の変化に対応した表現として分散表現を利用してベクトル空間で興味を表現、リアルタイム性を考慮したスコアリング、ニュースの価値・ユーザーとの接触への時間考慮といった点を定義されています。

システムアーキテクチャとしては、記事・ユーザーベクトルの更新、スコアリングデータ生成、推薦 API という３つの構成となっています。 記事ベクトルとユーザーベクトルの更新はリアルタイムに行うことが非常に重要で、Crawler が新着記事を取得するのをトリガーに、 ユーザーベクトルはユーザークリックをトリガーに、記事ベクトルとユーザーベクトルをリアルタイムに更新します。スコアリングでは、ユーザーの興味に応じたスコアを興味ベクトルとユーザーベクトルの距離に応じた重み付けをしパーソナライズスコアを決定し、さらに時間減衰を考慮します。ニュースの価値は時間とともに減衰し、一度見たニュースは再度見られることが少ないので、リスト面への表示はできれば一度だけにしたい。そのためにスコア減衰を時間の関数として取り入れています。推薦 API ではユーザーのリクエストごとにスコアリングを返しますが、リアルタイム性を考慮するため データの I/O を極力なくし、行列演算のみで行うことでできるだけ 50 msec を超えないようにレスポンスを返します。最後に、ラウンドテーブルの議題へ繋げるべく、推薦システム運用の課題として、開発環境だとデータ数が少なくパーソナライズは検証が難しいこと、分散表現のモデル更新をしたい場合にシステム全体の更新が必要なこと、オフライン実験の限界などを挙げていただきました。

登壇 スライド はこちら

 

ユーザエンゲージメントを良くするためのターゲットの設定 (ウォンテッドリー株式会社 久保長礼 氏)

LT の最後は、ウォンテッドリーの三人目の社員である久保長さんより、Wantedly におけるレコメンデーションのターゲットメトリクスの設定についてお話しいただきました。久保長さんはチームリーダーとしてレコメンデーションチームを立ち上げられてからこの２年で、「募集を表示してから、話を聞きに行く確率」という指標を２倍以上に改善されたそうです。レコメンドとしてはユーザーへ企業を推薦、企業へユーザーを推薦の二種類があり、「おすすめの募集」、「フィルタリング」、「キーワード検出」とそれぞれの機能に異なるアルゴリズムが使われています。Wantedly Visit のレコメンデーションでは、ユーザーの閲覧などの行動データ、属性や応募履歴等のユーザーデータ、募集要項などのアイテムのデータ、検索クエリをデータなどに対して、ユーザエンゲージメントスコアをターゲットとしています。ここでは、サービスに対する愛着、クリック数や応募数などのユーザー体験の質などを用いてユーザーエンゲージメントスコアを定義しています。レコメンデーションの実装としては、ユーザー・アイテムデータからグラフ処理と NLP を用いて特徴抽出し、フィーチャーからユーザーエンゲージメントスコアの計算には LightGBM/NN を用いています。前処理のグラフ処理では、月単位のコンテンツの時間減衰を考慮したり、プロフィールが類似しているユーザー間の結びつきを考慮に入れたり、自然言語処理では重要単語を TopicModel のような形で分類し特徴量に加えるような処理を行っています。

Wantedly Visit のようにユーザーのライフイベント等に応じて利用が発生するサービスの場合、必ずしも長期的かつ頻繁に使うことが直接良い ユーザーエンゲージメントとなるわけでなく、そのスコア定義が難しい課題があります。例えば、単に閲覧しても応募しなかったり、閲覧数が増えるのは悪い体験になっている可能性もあります。そのため Visit ではユーザーエンゲージメントに相関がある数字として、いかに Active であり続けるか、訪問頻度や利用時間といった Stickiness をターゲットとしています。サービスのフェーズによって最適化するものも変わるため、常にオンラインテストとオフラインテストの結果を比較し、その差分を見ながらアルゴリズムだけでなく、ターゲットとなるエンゲージメントの見直しもすることが重要だと指摘されました。

登壇 スライド はこちら

 

2. 7:50PM–8:40PM ラウンドテーブル (25分 x 2テーブル)

上記４名の LT 登壇者に加え、株式会社 Gunosy の大曽根圭輔さんにもファシリテーターに加わっていただき、+ AWS (ソリューションアーキテクト 針原・データサイエンティスト チャールズ がファシリテート) の６テーブルでラウンドテーブルを実施しました。２回のラウンドテーブルで出た議論をいくつかピックアップしてご紹介します。

  • インフラエンジニアと、データサイエンティストは分けるべき？
    • Gunosy では機械学習を専任にやってる人はいない。個人のスキルアップのため、タスク単位で個人で分担できるようにしている。今後はチームを分けることも検討。
    • ある会社ではもともと ML リサーチャをたくさん雇用していたが、インフラエンジニアとの間にコミュニケーションボトルネックが。そのため ML エンジニアを採用した。
  • 価値を時間の経過によって減衰させるという話について，昔の記事でも見る価値があるものはあるのでは？
    • 記事のカテゴリによって減衰のさせ方を変えている。
  • 自然言語処理を伴うレコメンデーションの難しさは？
    • たとえば、同じ単語でも、コモディティ商品の名前があったり、辞書的なものもあって難しい。
  • ニュースアプリの記事配置はどうしているのか？
    • ある会社では、上の方は見て欲しい記事、下の方にパーソナライズした記事を表示している。似てる記事だけだと飽きるしサプライズがなくなるのでそこのさじ加減を国・地域ごとに変えている。
  • 報酬はどうしている？
    • ブックマークやクリックなどポジティブなものを。
    • ログの取り方、ポジネガの取り方、が難しい。
  • API の指標の話で、スコアがどうすれば良くなるかの基準はどうやって選んでいる？
    • スパムユーザーを除外するアルゴリズムとか、難しい場合もある。
    • レコメンドの理由を入れてランダムで出すより20%くらい良くなった。
    • UI としての解決も大事。
    • 記事の出品者を増やす。分散していろんな会社に応募できるように。
    • Uber Eats はレストランの売り上げ、配送者も含めた３者の満足の最適化を目指している。
  • マネージャという立場でチームを取りまとめるのって大変ですよね。
    • 自分で勉強しなきゃマネージャって務まらないよね。
    • 自分で検証もする時期もあった。マネジメントタスクがおろそかになることも。
    • 5名くらいのチームに分けて、サブリーダーを育てている。
    • 1on1 をずっとしてる、みんなと月1回くらい、成長のアドバイスをしている。
    • 海外のメンバーがいるから、コミュニケーションも課題があるときも。話さないより話した方がいい。
  • 強化学習は検討してる？
    • オフラインの評価で活用することを考えている。
    • ポジティブな活動が全体の1 %くらいしかない。
    • データを減らして学習してるから、データを全部活用するために強化学習もありかなと考えている。
  • どうやってレコメンデーションチームの予算を取ってくる？
    • ドメイン知識がないと成果が出しにくいから、新たにチームとか部門を立ち上げるのが難しい。
    • ビジネス的に重要な KPI をまずはちゃんと設定すること。
    • 他社の事例とかを見せて説得する。
  • どうやってレコメンドすれば良いかを測定する方法は？
    • はじめに何の情報を集めるかのルールを決めてシステムを作っておく。
    • オフラインテスト： すでに手に入っているログから検証すること。
    • オンラインテスト： ユーザをグループに分けて表示するものを切り替えて検証する。
    • オフラインではうまくいくけどオンラインだとうまくいかないこともある。オフラインでうまくいかなければオンラインでもうまくいかないため、まずはオフラインテストをしっかりやる。
  • 全ての記事を対象するとぼんやりしてしまうので、限定的な内容に絞ると自社の既存レコメンドシステムでもそれなりに動くがそういうもの？
    • 属性を限定するのは良い方法。
    • サッカーの記事をクリックした人にスポーツ全体の記事の中からオススメするのか、サッカーの記事の中からオススメするのか、という話。
  • レコメンドのサービスとして Amazon Personalize が気になっているがどれくらい自由度があるのか？
    • 基本的にはユーザーとアイテムの相互作用のデータ ([USER_ID, ITEM_ID, TIMESTAMP] のリスト) [Docs] があれば動く。
    • AutoML でモデルを自動選択することもできるし、手動でモデル (レシピと呼ばれている) [Docs] を選ぶこともできる。
    • ハイパーパラメータ最適化 (HPO) も使えるが、HPO の対象とならないものもある [Docs]。
  • データがスパース過ぎて上手くいかない場合の一般的な解決策は？
    • ユーザー・アイテムをクラスタリングしてから推薦する、低頻度なアイテム・ユーザーは除く、など。
  • ニュース記事の鮮度の話があったが、他のサービスでもそういうものを考慮したほうがいいか？
    • アイテム消費のライフサイクルによって、固有な時間スケールがあるはずなので、そこは意識しておいた方が良い。
  • Amazon Personalize を使っているがいくつか要望がある。
    • ユースケースをお聞きして機能追加のリクエストを上げさせて頂きます。

などなど、多くのディスカッションが行われました。ご登壇・ご参加頂いた皆様、改めてありがとうございます。次回の ML@Loft #4 は 7月19日 (金曜日) 開催予定です。皆様のご参加をお待ちしております！お申し込みはこちらから https://mlloft4.splashthat.com/

 

このブログの著者

宇都宮 聖子 (Shoko Utsunomiya)

機械学習ソリューションアーキテクト。スタートアップで機械学習活用をされているお客様のサポートの他、Automotive・AIヘルスケアライフサイエンスなどを専門領域としています。好きなサービスは Amazon SageMaker 。