Workshop Report: Decision Intelligence and Analytics for Online Marketplaces Jun Ernesto Okumura @ KDD2022 論文読み会 2022/9/26 https://line.connpass.com/event/258930/

登壇者紹介: 奥村 純 ( ) ● Career ○ 2020.3〜 Data Director @Eureka ○ 2014.4〜 データアナリスト, MLエンジニア @DeNA ○ note | データアナリストの成長段階 ● Interest ○ データ組織マネジメント ○ 強化学習 ○ 検索・推薦技術 ● Decks ○ Speaker Deck: https://speakerdeck.com/pacocat ○ SlideShare: https://www.slideshare.net/juneokumura/ ○ note: https://note.com/pacocat 『データサイエンティスト養成読本ビジネス活用編』 （技術評論社） 『強化学習（第2版）』監訳（森北出版） @pacocat

本日紹介する話題 Motivation ● フィードバックがスパースで遅延がある状況での推薦システムに興味がある ● Multi-stakeholderの問題に興味がある ● Modelingの他に、Servingのためのシステム設計や運用、評価についての知見が多い Workshop “Decision Intelligence and Analytics for Online Marketplaces: Jobs, Ridesharing, Retail, and Beyond” で行われたLinkedInチームによるKeynoteの話題をまとめます。 Workshop URL https://sites.google.com/view/kdd22onlinemarketplaces/home Workshop Proceeding https://dl.acm.org/doi/10.1145/3534678.3542895 Disclaimer ● KDD2022の採択論文の紹介はありません ● 15分枠に対してボリュームが多いので発表では部分的に紹介します（後ほど資料共有します）

本日紹介する文献 Qi He, Bee-Chung Chen, Deepak Agarwal. "Building The LinkedIn Knowledge Graph." LinkedIn Engineering Blog. 2016. Duan, Weitao, Shan Ba, and Chunzhe Zhang. "Online Experimentation with Surrogate Metrics: Guidelines and a Case Study." Proceedings of the 14th ACM International Conference on Web Search and Data Mining. 2021. Benjamin Le, Benjamin Le, Daniel Gmach, Aman Grover, Roshan Lal, Jerry Lin, Austin Lu, Qingyun Wan, and Leighton Zhang. "Pensieve: An embedding feature platform." LinkedIn Engineering Blog. 2020. Rupesh Gupta, Sasha Ovsankin, Qing Li, Seunghyun Lee, Benjamin Le, and Sunil Khanal. "Near real-time features for near real-time personalization." LinkedIn Engineering Blog. 2022. Alex Tsun, Bo Ling, Nikita Zhiltsov, Declan Boyd, Benjamin Le, Aman Grover, and Daniel Hewlett. "Improving job matching with machine-learned activity features." LinkedIn Engineering Blog. 2022. Huang, Po-Sen, et al. "Learning deep structured semantic models for web search using clickthrough data." Proceedings of the 22nd ACM international conference on Information & Knowledge Management. 2013.

LinkedInについて ● 世界最大級のビジネス特化型SNS。Microsoftが親会社。 ● 1秒間に100のJob Application、21のInMail送信、0.1のHire（採用）が発生※1 ※1 講演資料より数字を抜粋 ※ 図は講演資料より翻訳・修正 Job Seeker Hirer Job Application InMail Sent Interection InMail Acceppt Interview Confirmed Hire 一方向の興味 双方向の興味

LinkedInにおける推薦 ● LinkedInの推薦 ○ 検索結果のランキング ○ 広告 ○ ニュースフィード ○ 人・仕事・記事・学習コンテンツの推薦 ● ジョブマッチ問題の特徴 ○ 双方向の興味がマッチする必要がある ○ アウトカムがわかるまでに時間がかかる（数ヶ月） ○ 特徴がスパース ○ 部分観測性 Figure2 from Weitao et al. 2021

紹介する話題 データの取得・処理 特徴量エンジニアリング モデリング デプロイ モデル評価 どのような特徴量を使う か どのようなモデルを 構築しているか ビジネス要求と効率性を どのように追求している か 遅延するフィードバックを どのように扱っているか ● Knowledge Graph ● Pensieve Modeling ● Pyramid Block ● Machine-learned activity embedding ● Pensieve ● Feature Store ● Surroagte Metrics ● 各工程における工夫を紹介 ● 一貫している態度：どれだけ実験を高速化できるか、運用を効率化できるか

Knowledge Graph：エンティティ構築 ● データを動的グラフとして取得・提供 ○ エンティティ：メンバー（ 850M）、ジョブ、スキル（39K）、会社（59M）、地域、学歴（128K）、… ● エンティティ構築のプロセス Generate Candidates Disambiguage eneities De-duplicate eneities Translation entities into other languages エンティティを生成。ユーザーがプロフィールや履歴書から作成するものと、プラットフォーム側で外部データも使いな がら生成したものがある。 同じエンティティでも文脈によって意味が異なることがあるため（例：アナリスト）、文章内の単語の共起をもとにソフト クラスタリングを施す。曖昧なものは複数のクラスタに属することになる。 word2vecなどでベクトル化したエンティティに対して、距離が近いものはまとめていく （略語や表記ゆれなど） 多言語に翻訳。エンティティの頻度はロングテールになるため、重要度が高く精度に影響する Topのエンティティは社 内の専門家が丁寧に翻訳し、テールのものは機械翻訳などを使い Recallを改善。

Knowledge Graph：リレーションの学習 ● リレーションの種類 ○ メンバーが直接入力した Explicitなものと、プラットフォーム側が推測した Inferedなものがある 例：会社名にlinkedin_と入力した場合は、LinkedInと推測する ○ Explicitな情報も完全には信用できる訳ではない 例：1-10名の社員しかいないはずの uberというデザイン会社に、 96名の（恐らくUberで働く）社員が マッピングされてしまっていた ● リレーションの学習 ○ 各エンティティのペアがどのような関係にあるかを二値分類している ○ ユーザーの入力をpositive example、ノイズを加えたものを negative sampleとして学習 ○ 頻度が多いエンティティでは上手く学習できるが、分布のテールについてはクラウドソーシングによっ て追加のラベリングを施す ○ 推論されたリレーションはさらにメンバーからのフィードバックを取得することで正例を増やす

Knowledge Graph：学習結果 “Web Developper”を中心としたエンティティの分布 （He et al. 2016） member→skillの推論例 （He et al. 2016）

Knowledge Graph：Data representation ● 標準化されたグラフを特徴量として提供 ○ 異なるチームでも同じデータ認識のもとで作業できる ○ アプリケーションチームに対して様々なインターフェースを提供 Java library、REST API、Kafka Stream Event、HDFS file、… ○ 生データだけでなくグラフ情報を潜在空間に埋め込んだ embeddingベクトルも提供 ● ユースケース ○ 履歴書やJD内の単語から文章をベクトル化 ○ 特定地域の特定職種に要求されるスキルリストの集計 ○ … He et al. 2016

Pensieve Platform ● 背景 ○ 継続的に機械学習モデルを改善するためには特徴量エンジニアリングと知見の横展開が重要 → 特徴量エンジニアリングを効率化し、そこでの知見がアクセス可能な状態にしたい ○ 有用な表現はDeepモデルのような表現力の高いモデルで実現できるが、順伝搬が重い → ニアラインの推論が必要なケースにも対応できるようなシステムを構築したい ○ 上記を解決するPensieve Platform※を提案 ※ Pensieveは、ハリーポッターに登場する魔法道具。記憶や思考を保存でき、必要な時に取り出すことができる。憂いの篩（ふるい）とも。

Pensieveの全体像 He et al. 2016 Offline Training Pipeline Feature Marketplaceから特徴量を取得して Tensorflow On Yarn※1で学習。 Pensieve Model 有用な表現ベクトルを生成する部分。アプリケーションチームは（データ加工や後続のデプロ イを意識しすぎることなく） embeddingの質を改善することに時間を費やせる。 Embedding Serving Framework オフラインとニアラインでのサービングを可能にする部分。 emmbedingベクトルはFeature Marketplaceに登録され、他の機械学習モデルなどに再利用される。 ※ Hadoop上での深層学習をサポートするフレームワーク。 TensofFlow、PyTorch、MXNet、 Horovodをサポート。 https://github.com/tony-framework/TonY

Pensieve Modeling ● 初期にはDeep Structured Semantic Models※を採用 ○ メンバーと求人のembeddingを別のMLPで計算し、要素積を使いロジスティック回帰を行う ○ 構造が分かれているのは好ましかったが、層を深くしようとすると途端にスケーラビリティと性能の 限界を迎えることとなった He et al. 2016 ※ Microsoftによるオリジナル論文は、 Web検索を念頭にクエリと（複数の）ドキュメントそれぞれについて表現を計算し relevanceを求めるものだった。

Pensieve Modeling ● 前頁の課題に対応するためスキップ接続※を導入して収束性と性能を改善 ● 逆ピラミッド様のPyramid Blockを構築した ※ Residual Connectionのように前の層の加法ではなく、 concatして渡している点に注意

Nearline embedding serving framework エンティティが登録・変更されたら後続のモデルに合わせて 加工処理（Apache Beam）が走る。Stream-Stream Join。 関連する複数モデルを走らせて embeddingベクトルを出力 （ExecuteScoringFn） 既存のembeddingベクトルと比較して重複排除（ DedupeEmbeddingsFn）を行い、 書き込みを効率化。既存の embeddingはVeniceというKVSから取得。 最終的に得られたembeddingベクトルを、Nearline Feature MarketplaceとVenice （KVS）用にそれぞれ整形して書き込み。 Point ● Efficient Output：embeddingの書き込みを最小化する。逐次計算するのではなく バッチでまとめて処理する、（全ての特徴が Embeddingに影響する訳ではないので） 寄与の小さいエンティティの変更は無視する、など。 ● Experimentation Velocity：システム全体としてどれだけ早く新しい Embeddingを 試せるかが生産性の要。 He et al. 2016

システムパフォーマンスのチューニング ● メッセージ流量に対して適切にスケールしたい ○ でないと、古いデータや欠損データを使うこととなり精度に影響する ● まず、ジョブの処理を最適化 ○ コンテナのスレッドプールを増やした ○ JVMのヒープサイズを増やして固定した

Multi Data Center Strategy ● 下流工程の依存関係の解消 ○ 初期にはデータはそのデータがあるサーバーでのみ処理されていたが、もしどこかのデータセン ターに複雑な依存があると Consumerは全センターの処理を待たないといけなくなる ○ そこで（処理の重複は許容した上で）各センターで全データを処理することで対応 He et al. 2016

Impact of Pensieve ● Pensieveの導入後、各プロダクトで一桁%の改善を達成 ○ Title、Skill、Locationなどスパースなデータをそのまま使うよりも Embeddingの表現が有用 下図：Embeddingの有無別で検証した XGBoostのFeature Importance ○ Embeddingの改善に集中することが可能になり、実験も効率化 ○ （個人的には）部門間のコミュニュケーションコストの低減も大きいのではと想像 He et al. 2016

ニアライン推薦の重要性 ● アクションをトリガーにするケースでは短時間での情報に追従することが重要 ○ 数分以内の更新がクリティカル（下図：過去データを使った性能評価） ○ 詳しくはAppendix参照 Gupta et al. 2020

遅延するフィードバックと代理指標（Surrogate Metrics） ● 推薦した求人がアウトカム（採用につながったか）は数カ月後に分かる ● モデルのイテレーションを高速化するためにアウトカムの代理指標を提案※ Figure2 from Weitao et al. 2021 ※ WSDM2021で発表され、既に詳しい日本語の解説も複数あります。ここでは要点だけ紹介します。 論文紹介 Online Experimentation with Surrogate Metrics Guidelines and a Case Study by Takashi Nishibayashi WSDM2021 paper (Online Experimentation with Surrogate Metrics) by 中江俊博

Surrogate Metricsを使った効果検証 通常の平均介入効果 ※1（Average Treatment Effect; ATE） ※1 Stable Unit Treatment Value Assumption（STUVA）が成り立つと仮定。 Wは割当。 ※2 強い仮定なので、現実には λ=P(Y=y|S,W)/P(Y=y|S)≒1を確認した上でSの妥当性を検証する Surrogate Metricsを使ったATE アウトカムYをSurrogate Metrics Sに置き換える ● SはYと強く相関している必要がある ● Sは短期的に得られる特徴Xから予測したい ● Xは施策でコントロールできる解釈性のあるものがいい ● 唯一の因果パスがW→S→Yになる※2

Surrogate Metricsを使ったA/Bテスト ● 先程のSの元では、分散が過小評価されてしまう ● 結果として、t統計検定量が過大評価され、 p値が過小評価されることで、偽陽性が発生する そこで、以下のように誤差項を加えて t値を補正する Figure1 from Weitao et al. 2021

Predicted Confirmed Hire（PCH） ● 真のアウトカムである Confirmed Hire（CH）に代わり、Predicted Confirmed Hire（PCH）を利用 ● 過去データを使ったバックテストで、強い相関と λ=P(Y=y|S,W)/P(Y=y|S)≒1を確認 Control: Wk=0 Test: Wk=1 Figure3,4 from Weitao et al. 2021

PCHを使った推薦モデル ● 実際に、PCHを使ってランキングモデルの学習を行っている ● 加えて、蒸留の利用、ミスマッチを予測する Facepalm modelの学習も同時に行う Slide from Workshop at KDD2022

まとめ ● KDD2022 WorkshopのLinkedInの講演に関連する話題を紹介 ● データ生成からモデリング、デプロイ、評価にいたるまで様々な工夫を行っていた ○ ナレッジグラフの生成と運用管理 ○ FeatureStoreを使ったニアラインのプラットフォーム Pensieve ○ 処理の分散並列化によるボトルネック（や強い相互依存）の解消 ○ Surrogate Metricsを使った素早いモデル評価の仕組み ● MLプラットフォームの設計思想として参考になる点が多かった ○ 一貫している態度は：実験の高速化、システムの効率化、標準化、分業体制 ○ Kafka、Venice、Pensieveなど独自のエコシステムを構築・運用している ○ エンジニアリングパワーが必要になるので、闇雲にまねる、というよりは思想を理解して自社で 持ち帰れる考えを活用していくのが良さそう

Appendix

アクションに基づいたNear real-time推薦 ● 従来のパイプラインでは、 Offline Data StoreへのETLやBatch Jobを含み、ユーザーアクションに基づい た即時の推薦ができなかった ○ 前述のように、数分内に追従できなければビジネス毀損リスクがある Gupta et al. 2022

Near real-time推薦パイプライン Gupta et al. 2022 必要なイベントだけをスクリーニング ETLではなくKafkaのStreamでData Store（Pinot）に通す ことで、0.1~15秒以内でのingestを実現 アクションのスキーマを標準化 ※ Online StoreとしてPinotを採用 ● Kafkaからのnear real-time ingestionに対応 ● クエリへの応答が早い（ <100msec） ● 水平スケールが可能 ● 古いデータのパージに対応（ここでは 96h）

Near real-time推薦パイプライン ● 1min以内のアクション情報が活用できることで、様々なメトリクスが改善 Gupta et al. 2022