推薦システム実践入門読んだので簡単に所感

書くときは頑張って書く。

以前会社で同僚だったhttps://twitter.com/zr_4から献本してもらった推薦システム実践入門を読んだ。

www.oreilly.co.jp


章立ては以下のようになっている。
1章 推薦システム
2章 推薦システムのプロジェクト
3章 推薦システムのUI/UX
4章 推薦アルゴリズムの概要
5章 推薦アルゴリズムの詳細
6章 実システムへの組み込み
7章 推薦システムの評価
8章 発展的なトピック

推薦システムの書籍だとモデルの部分にフォーカスを置いたものが多い印象だけど、この書籍は4,5章でモデルの話をしている以外ではあまり触れられていない。
むしろ推薦システムをどのような目的で導入するべきなのか、どのようにシステムを作るべきなのか、どのように評価して改善をしていくのか、そういった推薦システムの基本的な部分を広く網羅したものになっている。

そういった意味では、いま推薦システムを作っているエンジニアだけでなく、始めて推薦システムについて知りたい人(エンジニアだけでなく企画職の方でも)が最初に読む本として良さそうに思う。

使われているモデルの理解を深めるのであれば下記の方が良いかもしれない。

www.kyoritsu-pub.co.jp

一応レコメンドシステムを担当している人間ではあるので、今回は5章は軽く目を通して、他の章をメインに読んだ。
全体的に、学術書のような堅苦しい内容というよりは、TechBlogを読んでいるような感じで読みすすめることができるので、(好き嫌いあるかもしれないが)読みやすいと思う。

個人的に良いなと思った章は3章で、推薦システムの利用シーンのケースとそれに対応するアプローチが網羅的に書かれている。
こういう内容をきれいにまとめてくれているものはなかなか無いので、自分でレコメンドシステムを作らないで他社製品を使うような人であってもかなり参考になると思う。
著者がアルゴリズム部分だけでなく推薦システムの広域な領域に知見があるからこそ書ける内容という感じ。

他にも6章、7章はレコメンドをサービスに届けるために必要なシステム周りの話と評価方法についてまとまっていて、このあたりに知見が無い人にとってはとても参考になりそう。
また、各章においてより詳しく知りたい場合の書籍がレコメンドされており、そういった気遣いもありがたい。

個人的には6章の実システムへの組み込みはもっと深堀りしてもいいかなとか思う部分もあったりするけど、推薦システムについて知りたけれはまずこの本を読んでみて、興味があるトピックについて更に別の書籍や文献で深堀りしていくというのが良さそうだった。

献本ありがとうございました!

GW読んだ本

すでに年明けの目標は達成できないでいる。

本を読むときについつい先頭から丁寧に読んでしまう。とてつもなく効率が悪い。
本を読むのが下手なのでコツが知りたい。

チームトポロジー

GW前からのんびり読んでいたチームトポロジー
pub.jmam.co.jp


「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則を踏まえて適切なソフトウェア開発組織を設計するという内容の本。
単純にチームを疎結合にしようとかではなく、以下の4つのチームと3つのインタラクションモードを定義して、それぞれの依存関係を減らして目標に向かって進む組織を作る。

チームの種類
  • ストリームアラインドチーム

価値のある単一の仕事のストリームに沿って働くチーム。ベースとなるチーム。

  • プラットフォームチーム

一部内部サービスをPFとして提供することでストリームアラインドチームを助ける。

  • イネイブリングチーム

特定の領域のスペシャリストから構成され、ストリームアラインドチームの能力ギャップを埋めるのを助ける。

  • コンプリケイテッド・サブシステムチーム

専門知識が必要となるパーツの開発・保守の責任をもつ。

インタラクションモード
  • コラボレーション

チーム間で密接に協力して作業する。

  • X-as-a-Service

最小限のコラボレーションで提供・利用する。

障害を取り除くために支援をしたり受けたりすること。

個人的にはこの組織構成の考え方よりは、チームの認知負荷を制限して、チーム間のコミュニケーションを明確にするという解きたい目的の部分の納得感とともに実態として難しさを感じるなという印象があった。

この形のほうが成果が出るという期待はあるし、おそらく当事者もこちらのほうが成果が出るという理解はできると思うが、認知負荷の制限の進め方を間違えると認知機会を奪われているというふうに考えてしまうことが結構ありそうな気がする。

特に専門家チームがストリームアラインドチームをサポートする体制になったときに、それぞれの役割と考え方を明確に理解させておかないと、「このチームはいい所取りをしている」、「このチームだけ新しいことをやっている」といった軋轢を産むことになりかねないなぁと思った。

また、いろんなことを知っていたい、広く裁量を与えられたいという考えは持ちがちだし、そういった人が評価されやすくなってしまいがちなので、配置の意義から成果報酬の考え方までが一貫していないと機能しないんだろうなと思う。

この辺の話はこの書籍の考え方云々というより組織マネージメントの課題という感じだけど、機能する組織と個人のやりがいみたいなところを完全につなげるのは難しいなというところを改めて感じた。

ジョブ理論

会社の上司から薦められた一冊。

www.amazon.co.jp

イノベーションにおいて大切なのは、どうやってプロダクトの質を高めるのかを考えるのではなくて、ユーザーがどんなジョブ(用事、仕事)を片付けたくてそのプロダクトを雇用するのかであるという主張がされている。

相関関係から何かを見出そうとするのではなくて、因果関係のメカニズムを踏まえてイノベーションを成功させるという考えのもと、少量のインタビューデータなどを深く掘り下げて、ユーザーがどんなジョブを解決するためにそのプロダクトを活用したのをかを様々な事例とともにまとめている。

最初に出てくるミルクシェイクをなぜ購入するのかを掘り下げた内容などは非常に面白い。

プロダクト開発においてそれが十分に優れているかを追い求めすぎると永遠に完成が見えなくなるが、こういうジョブを解決したいユーザーにとって十分に役に立つか、という問いであれば答えが得られやすいというところも納得感があった。

日頃からデータを扱う立場からすると大規模なデータからはイノベーションを生まれなさそうな旨の指摘が結構されており、ビッグデータイノベーションをなかなか産めていないのはそのとおりだよなと同調する部分もあった。
あと人が作ったデータは、人がデータから出した結論には大いにバイアスがあるとかそのへんは難しい課題だなと思わされた。
そう思うと会社の分析部隊を事業から独立させた立場においたり外部から雇うのは割と理にかなっているのかもしれない(それでも会社のデータを扱う以上はバイアスを取り除くのは不可能だけど)と思ったりもした。

余談だけど文中でamazonを優れている例としてあげていたが昨今のamazonはそうだっけ...と思ったところもあったりした。

年明け

2022年になってしまった。

2020年末のブログでこんなことを書いていた。
・毎月1本はブログを書きたい
・社のtechblogを書きたい

達成状況はというと
・ブログは月2回投稿した月もあったが3月と4月、11月と12月が未達
・techblogはタイミングの問題もあって2022/03あたりまでには出せそうだが未達

ということでどっちも未達。

なので今年も一旦同じ目標を組んでみようと思う。
追加で書籍、論文などを読む頻度は上げていきたい。

特に年末を中心に仕事が忙しすぎて自分のことに時間をあまり使えなかったので、今年は立ち回りを含めてうまくやっていきたい。

ちびちび読み進めていたEMPOWEREDをようやく読み終えた。
pub.jmam.co.jp


プロダクトマネージャーの仕事は解決するべき課題を提示して、チームがその課題を解決できるように環境を整えてあげること、というのは納得感があるし、プロダクトマネージャーに限らず管理職の立場としてもできる限りそうするべきなんだろうという気持ちになった。
個人的に一番難しいのはメンバーへの動機づけで、なんでそれをやるのかについて自分なりには説明しているつもりでも、作業してもらっているメンバーが意義を理解できていなかったり、同調していなかったりという印象を感じることが多いので、ここにもっと時間を割か無いといけないなと思わされた。
一方、一部自分の中で意識的にやってきていたことが好例として書かれていたりもしてそのあたりはやってきたことが間違いないと確信を持てたし、今後も続けていきたい。

定期的に読み返して自分の行動を振り返るのにもいい本だなとおもった。

随分前にLearn or Dieについても読了した。
www.kadokawa.co.jp

書籍の中からなにか学びが得られる、というたぐいの本ではないけど、優れた技術集団の考えかたは理解できた。
研究開発の「手段」としてのビジネスという考え方で会社として成り立つことができるのがとんでもないなと思った。

今年も興味の赴くままに知識を得ていきたい。

メモ:EX3 : Explainable Attribute-aware Item-set Recommendations(RecSys2021)

論文
https://dl.acm.org/doi/pdf/10.1145/3460231.3474240

正直こちらのWantedlyさんの参加報告見れば十分説がある。
www.wantedly.com

概要

これまでのレコメンドは関連するアイテム集合を提供することにフォーカスしていたが、ユーザーの嗜好に合わせた重要な属性を抽出し、それに合わせてアイテムセットを提供することで、より説明力が上がり購買につながるはず。
今回は過去のユーザー行動から重要な属性と、それに一致するアイテムの集合を生成するアプローチ(Extract-Expect-Explain Framework)の提案。

手法

問題設定としては、seedとなるアイテムと、そのアイテムと各属性に対するスコアのペア、グループ数が与えられた時に、その数分の説明可能なグループ(属性とそれに対応するクリック、購入されやすいレコメンドアイテムの集合)を出力すること。

論文のタイトル通り、Extract-Expect-Explainという3つのステップが行われる。
f:id:A_Koide0519:20211010144715p:plain

Extract-Step

個々のアイテムをd次元空間にマッピングするStep。
まずアイテムのタイトルなどのメタ情報を用いて特徴量を生成する。
続いて任意のアイテムpに対して関連性のあるアイテム集合N_pとの距離が近くなるようにアイテム空間を定義する。
なおN_pはCo-view(レコメンドなどを通じてseedアイテムと同時に見られている状態)かつView-to-buyされたアイテムからCo−buyアイテムを除いたものと定義する(ポジティブデータ)。
※ユーザー行動としてアイテム間を比べて買ったということを考えると妥当と思われる
また、ネガティブデータとしてView-to-buyのアイテム集合から|N_p|分アイテムをランダムサンプリングするN_p^-
最終的にエンコーダーはhinge lossを用いて、すべてのpに対してpN_pの距離がより近くなるように、pN_p^-の距離が遠くなるように学習される。
このエンコーダーを通してembeddingされたアイテムについて、各アイテム毎に距離の近いTopN件のアイテムをレコメンドの候補集合とする。

Expect-Step

seedのアイテムqに対して、クリックや購入に結びつくアイテム候補pを属性aのもとに学習する。
今回はAttribute Differentiating Networkというニューラルネットワークを提案している。
seedとなるアイテムと、Extract-Stepで抽出した候補アイテムに対して、そのアイテムペア間の関連度と、アイテムペアにおける属性の重要度スコアを同時に算出できる仕組みとなっている。
f:id:A_Koide0519:20211012151845p:plain

入力はExtract-Stepで抽出したアイテムのベクトル、onehot化された属性データ、アイテムのタイトルやカテゴリから抽出した文字ベクトル。
(a)のvalue-difference moduleは、アイテムq,pの属性a_jに対応する文字ベクトルの値の差異が計算される。
(b)のattention-based attribute scorerでは、q,pをconcatして低次元空間にマッピングしたベクトルと、(a)で作ったベクトルを用いて、pの各属性ごとの重要度を算出する
(c)のrelevance predictorでは、q,pをconcatして低次元空間にマッピングしたベクトルと(b)のアウトプットとして計算された全属性の情報をまとめたベクトルを使って、アイテムqpの関連度のスコアを算出する。

Explain-Step

seedのアイテムqに対して、K個の属性が付与されたグループを作成し、各アイテムを適切なグループに割り当てる。
1.Extract-Stepで候補アイテム集合C_qを取得
2.すべての候補アイテムに対して、Expect−Stepの候補アイテムp_iの各属性ごとの重要度と、qp_iの関連度のスコアを計算する。
また、その結果を掛け合わせることで、属性jにおける、アイテムqp_iの関連度のスコア(u_{ij})を計算する
3.候補アイテム×すべての属性に対して、下記を最大化するように候補アイテムをXに配置する
f:id:A_Koide0519:20211014195153p:plain
X_{ij}=1のとき、レコメンドアイテムiが属性jに配置されることを表している
u_{ij}=u(q,p_i,a_j)と考えて良いはず
4.すべての属性、すべての候補アイテムに対して、X_{ij}=1のときそのアイテムをグループG_jにinsertし、u_{ij}で降順ソートする。
その後、グループ全体の平均関連度スコアs_jを計算する
6.すべてのグループをsのスコアで降順ソートし、TopKのグループを返却する

今回は30個の候補アイテムに対して、5個の属性グループを作る。
また、一つの属性グループに対して5つのアイテムを割り当てる。

実験

amazonの7つのサブカテゴリの実データを用いて検証をした。
比較として
・ExtractのEmbeddingのみ
・BPR
・ACCM
・A2CF
との比較を実施。

expect-stepの評価

30個のアイテムからTop10を抽出した際のNDCG、Recall、Precisionで評価。
best baselineのA2CFと比較してもNDCGで10%以上の改善をしている。
Recall、Precisionについても全体で5%以上改善している。
カテゴリによっては30-50%の大幅な改善が見られている。

explain-stepの評価

重要な属性を抽出できているかの評価。
・ランダム:候補アイテムのランダムに任意の属性に割り当てる
・Greedy:候補アイテムに対し、そのタイミングでu_{ij}が一番大きい属性に候補アイテムを割り当てる
との比較を実施。
評価として、ランダムに抽出した1000caseをユーザーに5点満点で評価してもらった。
こちらの結果についても提案手法が最も良い結果を出している。
実際に提案手法では候補となるアイテム集合が異なると属性のランキングが変化している。

オンラインA/Bテスト

コンバーションが+0.080%増加し、売上が+0.105%向上

所感

属性ベースのレコメンド第2弾。
extractとexpectの結果にかなり大きな差があるが、基本的に属性とそれに対応するキーワードの情報を追加しただけでかなりのリフトがあって意外な感じがした。
この問題を実用化する時に、アイテムに対する属性と、それに対応するキーワードを付与する部分が一番大変だと思うので、そのあたりもいい方法があったら知りたい。

メモ:“Serving Each User”: Supporting Different Eating Goals Through a Multi-List Recommender Interface(recsys2021)

論文
https://dl.acm.org/doi/pdf/10.1145/3460231.3474232

概要

レシピサイトでのレコメンデーションを対象にした論文。
食の嗜好はその時々で異なる。今日はヘルシーなものが食べたいけど明日はジャンクなものを食べたいということは日常茶飯事。
この課題をレコメンドの提示方法の工夫で解決する。
具体的には複数のレコメンドリストを提示することで解消を図る。
実験として、

  • 複数のレコメンドを提示する/単一のレコメンドを提示する
  • レコメンドの説明を付与する/説明を付与しない

のパターンでユーザー実験を行った。
結果として複数リストの提示はダイバーシティ、選択の満足度においてユーザーの支持を得られた。

やりたいことは
[RQ1] 説明付きのmulti-listレコメンドが、single-listのレコメンドに比べてユーザーにとって有用なものかの評価
[RQ2] 説明付きのmulti-listレコメンドが、single-listのレコメンドに比べて異なるユーザーのゴールや健康的な食品選択の助けになっているかの評価

の2つ。

実験設定

ロジック

58,000個のレシピから5つのカテゴリ(Casseroles, Toasts. Salads, Pasta, Chicken)のアイテムをランダムに1,000個弱サンプリング。
また、レコメンドのseedになるアイテムを30個ほど選択。
ランキングはタイトルのtermをTFIDFで重み付けした類似度の降順ソート。
更にそこからsub-listを生成する。
まず上述の類似度によってTop40個のレシピを取得し、そこから下記のロジックによって各項目毎にTop5のレコメンドリストを生成する。

  • Similar Recipes:関連度そのまま
  • Fewer Calories:カロリーの低い順に並べ直す
  • Fewer Carbohydrates:100gあたりの炭水化物含有量が少ない順
  • Less Fat:100gあたりの脂質が少ない順
  • More Fiber:100gあたりの食物繊維が多い順

被験者

366人の参加者。男女比は52:48で、年齢の平均は約35歳。

手順

より健康的な選択肢も含めてユーザーが関心のあるレシピを見つけられたかどうかをチェックする.
ユーザーはデモグラと健康状態、料理経験を記入する。
5つのカテゴリ(Casseroles, Toasts. Salads, Pasta, Chicken)のレシピを検索するという形のタスクを行う形。下記の図のように検索結果としてシードアイテムを提示して、その下にレコメンドが掲載される。
ここをsingle listのパターンとmulti listのパターンで出し分けて、どのレシピが好きか、あるいは家で作ってみたくなるかを選択する。
5回の試行の後、進められたレシピセットを、選択の難しさ、多様性やわかりやすさ、の観点から評価してもらう。

f:id:A_Koide0519:20211003000015p:plain

評価指標

  • ユーザーの評価に関連する指標

1つ目の問いを確かめるための指標。
実験におけるユーザーのFB情報をもとに作成する。ユーザーには「選択の難しさ」、「多様性」、「理解のしやすさ」、「選択の満足度」の観点で評価をしてもらう。

  • 選択指標&ユーザー特徴

2つめの問いを確かめるための指標。
それぞれのレシピに対する健康度を表すものとしてFSA Scoreというものを付与する。
rangeは4(健康)~12(不健康)となっていて、UK Food Standard Agtencyというところが公開しているものを使う。
油、砂糖、塩が多くなるとスコアが高くなる。
選んだレシピのFAS Scoreとレコメンドしたレシピの平均FAS Scoreの関係性を利用する。
また、選んだアイテムに対して選んだときの目標があったかを尋ねる。
最後にデモグラと健康状態、料理経験(5pointスケール)を尋ねる。

結果

確認的因子分析

「選択の難しさ」、「多様性」、「理解のしやすさ」、「選択の満足度」のスコアと、それぞれの質問内容の関係性を確認的因子分析で確認した。
f:id:A_Koide0519:20211003005649p:plain

構造方程式モデリング

「選択の難しさ」、「多様性」、「理解のしやすさ」、「選択の満足度」のスコア、レコメンドのロジック、ユーザーの特徴と言った要素の関係性を構造的に明らかにするために、構造方程式モデリング利用する。
結果は以下。
f:id:A_Koide0519:20211003011028p:plain

single-list vs multi-list

レコメンドのパターンと、評価指標の関係性を確認する。
まず、multi-listであることが多様性に大きく寄与していることがわかる。
多様性の観点では、多様性の高さは選択の難しさを高めてしまうこと、multi-listの提示による選択の難しさは多様性によって媒介される事がわかった。一方、説明の有無は関与していない。
また、multi-listの提示による選択満足度は多様性によって媒介され、多様性は選択の満足度に影響を与えていることがわかった。一方、説明の有無は関与していない。

選択指標

対照的な結果として、説明付きmulti-listは非健康的なレシピ選択へ導いてしまっているが、説明の追加自体は健康的なレシピ選択へ導くという結果になった。
また、選択したアイテムのFSAスコアとユーザーのゴールにはネガティブな関係性があった。
これは健康的なレシピの選択がユーザーのゴールに関係を持つことを示している(FSA Scoreは低いほど健康的)。
実際にmulti-listに対して説明の有無による選択アイテムのカテゴリの割合を見てみると、説明ありの方はMore Fiberの選択率が10pt近く上昇している。また、食物繊維の多いレシピはFSAスコアが低くなる傾向がある。
さらに、ユーザーのゴールにマッチした選択によって、高い理解のしやすさを得られる事もわかった。

ユーザー特徴

ユーザの自己申告健康度合いと選んだレシピのFSAスコアにはネガティブな関係がある。
自己申告で健康とした人は健康志向なレシピを選びやすい。
また、ユーザーの料理経験と選択の満足度にはポジティブな関係があり、今回のインターフェースが経験者向けに設計されていることが示唆される。

結論

[RQ1] 説明付きのmulti-listレコメンドが、single-listのレコメンドに比べてユーザーにとって有用なものかの評価
muti-listのほうがユーザーをより満足されられるという結果になった。それは選択の多様性から導かれるものである。
このインターフェースが料理経験がより多い人にとって好まれやすいものである。
ラベルのないmulti-listのインターフェースでは説明を入れても選択肢の過多を減らせないし、満足度も上げられない。これは先行研究の結果とは少し異なる部分。
タイトルや詳細説明などの付加情報が入っていると説明の追加にインパクトがないのかも。

[RQ2] 説明付きのmulti-listレコメンドが、single-listのレコメンドに比べて異なるユーザーのゴールや健康的な食品選択の助けになっているかの評価
multi-listのインターフェースのほうが不健康な関連レシピを選びがちになっているが、一方で説明を加えることで多くのユーザーが食物繊維を多く含むレシピを選択してくれることもわかった。
健康的なレシピを選ぶことがユーザーの食事やレシピのゴールと関係している。
これはより健康的なレシピが存在するのであればそれをサポートしてあげることでユーザーの健康的な食事目標に貢献するかもしれないことを示唆している。

所感

最近こういったインターフェースのレコメンドのパターンが増えてきているんじゃないかという話を周りでしていた中でrecsys2021で発表されていたということで一通り確認。
こういったユーザーヒアリングも自分たちでやるのはなかなか大変なので傾向がなんとなくわかっただけでありがたい。

メモ JiZhi: A Fast and Cost-Eective Model-As-A-Service System for Web-Scale Online Inference at Baidu(KDD2021)

内容

Deepを活用したレコメンドモデルは様々な領域で活用されているが、十分に学習されたモデルを本番環境で通用する速度で推論でき、多くのユーザーから多様な時間帯でのアクセスを捌き、コストを最適化することはチャレンジングな取り組み。
この論文ではJiZhiというModel As A Serviceを提案している。

この仕組によって、推論の効率を犠牲にせずに200%の追加トラフィックに耐えることができ、1000万USドル以上のコスト削減を実現できている。

システム

f:id:A_Koide0519:20210908230458p:plain

Staged event-driven pipeline

各構成要素を以下のように定義する

定義1:ステージプロセッサ

推論のworkflowにおいて、ステージプロセッサpを以下のタプルで定義する。
{ \displaystyle p = \lt op,c \gt }
 op:特定のステージの機能をカプセル化したプリミティブを表す演算子
 c:上流のプロセッサからのイベントをキューイングするチャンネル
推論のworkflowはステージプロセッサの集合でモジュール化される。
 P=\{p_1,p_2,...\}
各ステージプロセッサでは、オペレータが入力されたイベントを処理したイベントを次のステージプロセッサに添付されたチャンネルキューに渡す。

定義2:Staged Event-Driven Pipeline (SEDP)

有向非巡回グラフとして定義される。
 G = (P, E)
Pはステージプロセッサの集合。
Eは2つのステージプロセッサを接続するエッジ
ex.  e_{i,j} p_i p_jを接続するエッジ
SEDPではすべてのエッジが同じステージのプロセッサを指し示し、チャンネルを共有しており、aggやjoinと言った複雑なイベントの処理を可能にしている。

SEDPはここのステージプロセッサの依存関係を自動で分析し、共有されたチャンネルを構築し、完全非同期実行をコンパイルする。

f:id:A_Koide0519:20210911171436p:plain

上記がuser-itemのworkflowの例。
user featureの抽出とitem featureの抽出、変換処理それぞれ別のステージプロセッサで実行される。リクエストのすべての生の特徴量は対応する特徴量パラメータ(embeddingsやsparse vector)を取り出すために再結合される。
最後に取り出したパラメータをDNN networkにfeedしてアイテムの関連スコアを取得する。
ステージプロセッサを非同期に実行することで、ロングテイルアイテムによるパイプラインの停滞の可能性を減らし、全体のスループットを向上させている。
ステージプロセッサのキャパシティ(並列数、メモリなど)は個別に調整できるので共有インフラの利用効率を高められる。

また、SEDPはマルチテナント拡張機能により、単一のパイプラインの中で複数のDNNモデルにアクセスでき、多段でDNNモデルを噛ませたり並列でDNNモデルを噛ませたりできる。これによりレコメンドの性能を上げたりA/Bテストを容易に実施できる。

Heterogeneous and hierarchical storage

f:id:A_Koide0519:20210911180556p:plain

The Distributed Sparse Parameter Cube

レコメンドでは、DNNは通常巨大でスパースなsub-networkと適度な密度のあるネットワークからなる。
そこでスパースなsub-networkの極めて高次元なパラメータを管理する仕組みを導入した。
これはread-onlyのKVSで、keyはコンパクトな特徴量のシグネチャとして定義され、valueはスパースな特徴量に対応するユーザーフィードバックの統計量とモデルの重みを表す。
すべてのキーはメモリに格納され、値はGBサイズにブロックにまとめられてメモリあるいはSSDに格納される。ここはlatencyとハードウェアの容量のtrade-offになる。

Heterogeneous and Hierarchical Cache

上述のcubeによって数ミリsecのlatencyで特徴量のアクセスができるが、オンライン推論のプロセスではまだ通信量が計算量が多いので、いくつかのキャッシュを導入した。

  • Cube cache

提供済みのBaiduのレコメンドサービスの中で、1億のcubeへのアクセス頻度可視化してみると、80%以上のリクエストは全体のたかだか1%の値にしかリクエストしていない。したがってキャッシュの導入はnetwork I/Oコストの削減に有効。
Cube chaceはmemory layerとdisk layerの2層のキャッシュになっており、memory layerにはLFUポリシーに基づいて上位0.1%のkey-valueのペアを格納し、disk layerには同様のポリシーに基づいて上位1%のkey-valueのペアを格納する。
これによってリクエストを90%削減でき、平均のレイテンシが10向上した。

  • Query cache

user-itemのスコアは短時間ではstableであるという考察から、過去のuser-itemのスコアをキャッシュする。
実際にスコアの不変の割合を計算してみると、2分後でも60%以上のスコアは不変だった。
このキャッシュは定められたtime windowを経過するか、ユーザーからのフィードバック(click,unlike)に基づいて更新される仕組みで、更新のポリシはLRUとなっている。結果として20%の計算コストを削減できている。

Intelligent resource manager

オンライン、オフライン両方のオートチューニングコンポーネントになっており、自動でリソース割当や各コンポーネントの負荷軽減の方針を検索、学習する。
#内容がなかなか難しいので詳細は省く

  • オフライン

目的としては、レイテンシの制約下においてリソースの消費を最小化する各種パラメータを探索することになる。
レイテンシの制約はデフォルトの設定以下になるようにする。

  • オンライン

レコメンドの問題では1st pahseでrecallが最大になるように候補を作り、2nd phaseでリランキングして数個のアイテムまで絞るが、2nd pahseに入力するアイテムの中で最初から低品質なものをカットしてしまうことで、リランキングの計算コストを抑えることができるはず。
そこで精度が指定した値以上に小さくならないように低品質な候補アイテムをプルーニングするポリシーを作成する。

評価

既存のBaiduのレコメンドシステムとの比較(リファレンスはあるけど読めていない)。
いくつかのBaiduの本番で動いているレコメンドサービスで比較した結果、各種パフォーマンスが改善。特にスループットインスタンス数が大きく改善している。
f:id:A_Koide0519:20210911191315p:plain

他にもいろいろな評価や分析をしているがここのインパクトがとにかく大きい。

所感

Intelligent resource managerの部分は難しくて読みきれなかった。
推論のパイプライン周りなどはかなり手が込んでいてすぐになにか試せそうという感じはしなかったが、ストレージ側のデータの持ち方やキャッシュの入れ方、キャッシュのポリシーの考え方は参考になりそう。

メモ:Using AntiPatterns to avoid MLOps Mistakes

論文
https://arxiv.org/pdf/2107.00079.pdf

概要

金融分野でのMLOpsアンチパターンをまとめた論文。
技術的な課題もあればMLの結果を使っている周辺のコンテキストが十分な知識を有していなかったことが原因となっている。
これらの状況を議論するに当たり共通のボキャブラリーを提供することで、ステークホルダー間の素早いコミュニケーション並びにより素早く問題を解決する。

ここでは9つのアンチパターンについて取り上げる。
f:id:A_Koide0519:20210810224536p:plain

アンチパターン

Data Leakage AntiPattern

データリークはモデルが本来持っていない、あるいはモデル生成時には利用できないデータを利用してしまうこと。
モデル作成時にモデルを過大評価してしまう可能性があり、そのまま本番提供すると想定よりも性能が全然出ないということが起こりする。
システムやデータの複雑さが時間的な依存を隠してしまいがち。

ユーザーの行動履歴をembeddingしたものを使ったりするとこういう問題が発生しそうな感じがする。

Peek-a-Boo AntiPattern

データが実際に取得できるまでタイムラグが有る場合がある。
例えば、月の労働時間は当該月が終わって次の月にならないとわからない情報。
モデラーがこのデータの日付と実際にデータを受け取れる日付の違いを理解しないと想定しないデータをモデルに含めてしまうかも。

Temporal Leakage AntiPattern

レーニングとテストのデータセット分割の際に、サンプリングの方法を誤ってしまうとリークが発生する。
特に予測問題では、連続性があるデータの分割の仕方を誤るとリークが起こってしまう可能性がある。

Oversampling Leakage AntiPattern.

不均衡データにおいてOverSamplingはよく用いられる手法だが、TrainとTestの前にOverSamplingを実施してしまうとリークが発生する可能性がある。銀行の解約予測を事例にリークが起きていることを説明する。
f:id:A_Koide0519:20210812195057p:plain

この図を見ると(a)の方のOverSamplingしたあとにデータを分割した方は楽観的な性能を示しているが、これはOversamplingのタイミングがTestデータを作る前に行われたことが原因であると考えられる。

Metrics-from-Beyond AntiPattern

データの前処理の段階でTrainデータとTestデータを合わせて正規化などをしてしまうことにより、Testデータの統計的な性質がリークしてしまう可能性がある。

‘Act Now, Reflect Never’ AntiPattern

一度モデルが本番にDeployされると、予測はフィルタリング、更新、反映、定期的な調査も行われないまま現状維持で利用されることがある。
こういったことがコンセプトドリフト、誤った予測結果の提供、敵対的攻撃を引き起こしてしまう。
※コンセプトドリフト:入力データと予測結果の関係が変化した状態. 古いデータに基づいて構築されたモデルが新しいデータと矛盾した状態.
デプロイしたモデルに対してのモニタリングやデバックの仕組みを用意する必要がある。

Tuning-under-the-Carpet AntiPattern

ハイパーパラメータはモデルのパフォーマンスにおいて重要な役割を果たす。実際の例として退会予測のタスクにおいてXGBのハイパラチューニングをした結果としない結果を示す。
f:id:A_Koide0519:20210813165259p:plain
F1スコアが3.5%程度改善していることからも、チューニングは重要であることがわかる。
ハイパーパラメータの最適化に関わる学習パイプラインの部分は、再現性があり容易に適応できるように、明示的かつ丹念に文書化することが必要。

‘PEST’ AntiPattern

新しいML分野の研究が提案される時、主要なコントリビューションは下記に寄って示される。
i)これまで検証されていなかった理論的提案
ii)新しい理論的な提案と経験的な検証の組み合わせ
iii)既存の学習パイプラインを効果的に補強し、パフォーマンスを向上される
経験的検証を行うには、提案手法を過去のアプローチと比較して公正に評価し経験的な性能を評価する必要がある。しかし新たに提案されたML手法の経験的な検証が不十分であったり、欠陥があったり、あるいは期待外れであったりすることはよくある。
こういったケースでは、報告された経験的な利益は経験的優位性の認識 (PEST) antipatternが発生しているということになる。
対策として、まずはシンプルなモデルでBaselineを作ってそこからより高度なモデルの調査をしていく、あるいはSQuADのようなベンチマークのデータセットに対してモデルを検証するパイプラインを構築するといったことが挙げられる。

個人的にこの話で思い出すのはRecSys2019のBestPaperだった下記の論文。
https://arxiv.org/pdf/1907.06902.pdf

Bad Credit Assignment AntiPattern

モデルが改善したときに、MLパイプライン全体のどこに性能向上の要因があったのか特定できない問題が頻繁に起きる。
研究領域においては改善は新しいアーキテクチャによるものであると言われることが多いが、実際には巧妙な問題設定、データの前処理、ハイパラチューニング、既存ロジックを新しいタスクに適用したといったことで性能向上することがほとんど。
こういったことを防ぐために、ablation studyによって新しい学習モデルのどの部分に優位性があったのかを経験的な評価の中に含める必要がある。

Grade-your-own-Exam AntiPattern

ここの章はあまりよくわからなかったが...

モデリング潜在的な威力を探るために好奇心に駆られた反復作業から始まる。このタイミングでは3rd-partyからのレビューなどは必要ないが、この状況が長く続くと検証を行わず、検証されていない結果を他の方法と比較することができない。
これを避けるために、テストと評価のデータは独立してサンプリングされるべきで、堅牢なパフォーマンス分析のためには、モデル開発が完了するまで隠しておき、最終的な評価にのみ使用する必要がある。
実際には、サイエンティストが最終的なテストセットを入手し、このテストセットに対してテストを繰り返すことで、テストセットでのパフォーマンスを向上させるようにモデルを修正してしまう。
これは暗幕的なデータのリークに繋がり、パフォーマンス評価での過学習が選択バイアスにつながる。
これはHARKing「Hypothesizing After Results are Known」(結果が判明したあとに仮説を作る)と呼ばれている。

Set & Forget AntiPattern

モデルのトレーニングと推論にはSet and Forgetの考えが適用されることが主流となっている。しかし、モデルが予測するターゲットの統計的な特徴が時間とともに変化することが頻繁に発生する(concept drift)。
concept driftの対策方法については下記のサイトに良くまとまっていたので勉強になった。
recruit.gmo.jp

モデルをdailyなどで定期的にTrainingしている場合にはForgettingをしている状態と言って問題ないのだろうか。

‘Communicate with Ambivalence’ AntiPattern

モデル自身の不確実性に関する情報についてほとんど注意が払われていない状態。
校正されていないモデルを本番に投入すると、何かあったときに補償や改善のためのパイプラインを導入することが難しくなるので、Brier Score(またはそれに準ずるもの)で注意深くキャリブレーションされているモデルを投入する必要がある。

rindalog.blogspot.com

‘Data Crisis as a Service’ AntiPattern

データの抽出手順を記録せずに手動で抽出したデータを使ってモデルを開発すると、後々モデルを検証したり展開する際にデータの準備に非常に時間がかかる。
センシティブなデータなどで外部のデータ提供者がサニタイズしたりするとこういったことが起こりやすい。
対応として以下のようなものがあげられる。
・専門的なデータエンジニアリングプラクティスの用意
・パイプライン上移動するデータの追跡
・仲介業者を含むすべてのデータプロダクトの系統の追跡