[2021/04/01]Machine Learning 輪講

[hakubishin3]

Why

Machine Learning 輪講は最新の技術や論文を追うことで、エンジニアが「技術で解決できること」のレベルをあげていくことを目的にした会です。

prev. https://github.com/wantedly/machine-learning-round-table/issues/91

What

話したいことがある人はここにコメントしましょう！ 面白いものを見つけた時点でとりあえず話すという宣言だけでもしましょう！

[hakubishin3]

Leave No User Behind: Towards Improving the Utility of Recommender Systems for Non-mainstream Users

WSDM 2021 https://dl.acm.org/doi/10.1145/3437963.3441769

• 概要
  • mainstream bias によって non-mainstream なユーザに対する CF の推薦精度が悪くなることに対して, 各ユーザ固有の表現が出来るだけ保持されるような手法を提案している.
• mainstream bias とは?
  • 多くの人に好まれるアイテムを好み, 多くの人に嫌われるアイテムを嫌う mainstream user に対して, 嗜好性が少数派である (逆の対応を見せる) のを non-mainstream user と定義している. 大体外れ値に該当する.
  • non-mainstream user は CF においてあまり類似していないユーザのpreferenceを使った推薦が行われたりする. また学習が mainstream user に支配的であることで, mainstream user に比べると推薦性能が悪くなる.
• どう対応するか
  • AE を導入したアーキテクチャを提案. ユーザとアイテムそれぞれの再構成損失と予測損失のバランスを取って学習.
  • mainstream かどうかに関わらず, ユーザとアイテムの表現がそれぞれの固有の特性を保持できるようにする.
• 結果は ?
  • ハイパラが結構過敏らしい
  • 提案手法はMF に比べて, ユーザごとの評価値が全体的に改善されていることが示された.

[yu-ya4]

なんか読みたいですねん

[kur0cky]

Salience and Market-aware Skill Extraction for Job Targeting

SIGKDD'20 https://dl.acm.org/doi/abs/10.1145/3394486.3403338

ちょっと変化球的に HR tech の論文を紹介。口頭メインになりそう

概要

適切さと人材市場からの供給を考慮した求人からのスキル抽出

• ユーザは既にスキルを設定している．
• 採用プラットフォームの第一歩（推薦など）として，自動でマッチさせることを考える
• 書類通過ぐらいの質は担保しつつもトータルのマッチが一番多くなるように求人にスキルを付与したい．

モチベ

• 既存の「求人からの情報抽出」では，全体の効用最大化を考えていない

• 「求人に対して候補者リストを出し，△△人通過する」の全求人での和（eq）

• market-aware <-> market-agnostic (求人にスキルが紐付くかどうか)

  

• ユーザ数は6億とかなので爆発して無理 -> 属性情報使うのが一般的．特にスキルは実績ある

• 定式化して考えると，「市場からの供給がある」，「その求人に深く関連する」の2点が特に重要 (Sec. 2)

タスク設計

（求人，スキル）ペアが適切であるかの教師あり学習

データ

2種類のデータを用意．それぞれの分布は一緒

• Job Targeting (JT)：スキル候補推薦 -> 採用担当者による選別（少）
• Quality Applicant (QA)：求職者が書類選考を通過したかどうか -> 共有されている上位と下位（多）

特徴量エンジニアリング

• スキルがどの程度求人を代表しているか（Fig. 3）
  • Sentence level: BERTとかfasttextでスキルとセンテンス夫々埋め込み -> concate
  • Segment level: LinkedIn で持っているword2vec．あとはいっしょ．(e.g., summary, requirement, etc)
  • Job level: スキルと，求人の中で言及されているスキルがどのぐらい近いか (mean-pool)．
• スキルを持つ人材の供給について
  • 単純なスキルの供給量（ユーザ数）
  • メンバーをコホートに分け、その中での自己相互情報量 (PMI)と全体のエントロピー　（コホートはたとえば業種×職種など）
  • 求人側からの需要量
  • 求人 segment (e.g., summary, requirement, etc)ごとの PMI

実験・結果

ベースラインモデルは，market-agnostic なロジスティック回帰（詳細不明）

• オフライン検証：精度向上 (AUROC)
  • train / val / test : 60 / 20 / 20
• オンライン検証：A/Bテスト（ただし，計算時間からBERTではなくfasttext）
• ablation study：

定性分析

• スキルトレンド：算出方法書いて無いけど、おそらく効用U(s, p)の合計
• 実例（ベースラインとの比較）

[osuossu8]

[2021] Personalized Embedding-based e-Commerce Recommendations at eBay

論文

https://arxiv.org/pdf/2102.06156.pdf

参考 : eBay について

• 16億以上の商品と1億8300万人以上のユーザー 　- ユーザ-アイテム行列の規模と極端な疎性 　- 毎日何百万もの新しいアイテムが出品されているため，コールドスタート問題 　- ライブリストの半分以上は単品であり， つまり，最大で1人が購入できる 　- 購入された後は購入されたアイテムはサイトから削除され、ユーザーはアクセスできなくなる 　 - クリックや購入などの暗黙のユーザーフィードバック信号は非常に希薄

• ユーザープロファイル

  • 主にマーケットプレイス上でのユーザーの活動
  • ユーザーの情報 :
    • サイト登録時アンケートへの回答 (明示的) --> 潜在的関心の網羅性に弱い、参加率が低い、入力が不完全である可能性の高さ、長期的な関心が短期的な買い物の目的を捉えていない可能性
    • ユーザーのショッピング履歴を解析 (暗黙的) --> embedding 作成

着目した理由

• 新しめの論文で
• ドメインがEC サイトでの商品推薦で
• 訓練データの作成や、評価の部分がきちんと記述されている (参考にしたい) の観点を満たすものを探して見つけた。

内容

サマリ

• アイテムとユーザーを同じベクトル空間に埋め込むことを学習することで、eコマース・マーケットプレイスにおいてパーソナライズされたアイテム推薦を生成するアプローチを紹介
• オフライン指標 (Recall@k), オンライン指標 (サーフェイス・レート, リスティング・ページ・インプレッション?) 両方でベースラインに勝ち

Model

• ユーザーエンベディングとアイテムエンベディングを同時に生成する2タワーの深層学習モデル
• データセットで観測されたユーザーのクリックの負の対数尤度（NLL）を最小化するように学習

Feature

• アイテム : 一意の識別子（アイテムID）ではなく，アイテムのタイトル，カテゴリ（携帯電話など），構造的側面（ブランド：Apple，ネットワーク：Verizonなど）などのコンテンツベースの特徴のみを用いて表現 過去のアイテム行動の特徴（例：過去のClick-ThroughRate、Purchase-ThroughRate）をモデルに組み込まない (save, load に手間)
• ユーザー : アイテム閲覧と検索クエリのログなどを使用, GRU で時系列特徴を抽出

Result

• 評価セットとは別に用意した 7,000人のユーザと1,000万個の候補アイテムからなる別のテストセットを用いて行った
• 候補アイテムの数は，生産現場で予測時に一般的に使用される候補アイテムの数と同程度の規模

ロバスト性についての考察

• ユーザー履歴の一部が欠落した場合のモデルの性能を調べるために、ユーザー履歴データに関するモデルのアブレーション分析を行った
• 予測時に最新のユーザー履歴がない場合にどのような影響があるかを理解するために，いくつかの実験を行い，その結果を図3に示した
  • 図3の青い破線の曲線からわかるように，直近の5分間のユーザー行動がない場合，Recall@20指標は0.9から0.62へと30％以上低下
  • 直近の60分以内のユーザーアクティビティがない場合、この指標は50%も低下して0.45
• この問題を解決するために、ユーザー履歴からランダムなものではなく、最新のユーザーアクティビティを削除してモデルを学習することにしました
  • バッチモデルの予測出力とユーザーの印象との間に時間的なギャップがあるような、本番システムで発生するシナリオによりよく沿うようにするため
  • 予測時刻に60分のユーザー行動が欠けていた場合、すべての「スキップされた」モデルは、オリジナルモデルの0.45に対し、Recall@20は0.56を達成することができました（青の破線の曲線）
  • より多くの履歴をスキップして学習すると、曲線がより平坦になり、履歴の欠落が変動する状況下でよりロバストなモデルであることが示唆されました。しかし、特に0分（スキップなし）から30分の範囲では、脱落したユーザーの履歴を多く使って学習すると、モデルのパフォーマンスが低下することも分かりました
  • パフォーマンスと一貫性のバランスをとるために、10分間のユーザー活動をスキップして学習したモデルの中で、図3の曲線の下の面積が最も大きいものをプロダクションモデルとして選択しました（緑の曲線）

所感

技術的な感想

• ユーザー情報とアイテム情報を同一空間に埋め込んで一緒に学習するというアイデア自体は kaggle でもよく見る - リークしないように時系列で train / valid / test を分けている点、負例の選定をミニバッチ内でやってる点、予測時に最新のユーザー履歴がない場合を想定し、訓練時に新しいのユーザーログを除いて学習データを作っている点などは基本はしっかりしていてその上で工夫がなされているなと感じた
• 比較手法が Recently Viewed Items とはいえここまで露骨に差が出るのかなるほどといった感じ
• 協調フィルタリングや行列分解法だと不十分だと intro にあったのに比較対象に出てきていないのは :thinking_face:?