クックパッドにおける 推薦（と検索）の取り組み ― 99%の失敗と1%の成功 ― クックパッド株式会社 R&Dチーム ソフトウェアエンジニア 林⽥千瑛

Chie Hayashida(@chie8842 ) • Software Engineer @ Cookpad R&Dチーム • 情報推薦の経験： • Apache Sparkクラスタ400+台を⽤いたグローバル推薦システムの開 発など • もともと最新技術を試すとかより推薦システムを精度・パフォーマン スの両⾯で安定して動作させるほうに興味がある • クックパッドではKPI策定から評価まで、ビジネスに近い部分も含めて 検索・推薦の施策をリードしている

Question クックパッドで推薦ってどんなの やってると思いますか？

Answer 実はけっこういろんなことにチャレンジしている。 • レシピ推薦 • プッシュ通知 • レシピ作者フォロー推薦 • 検索キーワード • レシピエディタのオートコンプリート機能 • 広告 etc

今⽇のおはなし 最新アルゴリズムとか、システム⾯のチューニングとか、 技術的にキラキラした話 推薦を⼊れるまでのどろくさーい話 ✖

今⽇のおはなし •ビジネスモデルに即した推薦KPI設計の難しさ •既存システムに推薦を組み込むことの難しさ •効果のある施策を⽣み出すことの難しさ アルゴリズムとか実装⾯の深イイ話はありません あくまでもわたしの経験談であり、他の現場でもあてはまるとは 限らないです

ビジネスモデルに即した推薦 KPI設計の難しさ

推薦の取り組みのはじまり エラい⼈ わたし 推薦システムつくって 何を最適化したいんだろう？

推薦の取り組みのはじまり わたし 要件があやふやだがチャンスを くれているわけだからなんとか 形にできるように 考えてみたい！

何をKPIとおくか • 推薦を⾏うことは⼿段であり、最初に何を最適化したいのかの KPIを決める必要がある。 • 何をKPIとおくかは、ビジネスモデルを理解して決める よくある例： • ECサイトなどでは、売上、購⼊者数 • 広告ならインプレッション、クリック率など

クックパッド • レシピの投稿・検索等ができる⽇本最⼤の料理レシピサービス

クックパッドのビジネスモデル • CGMサービスである（利⽤者がコンテンツをつくる） • 売上の多くはプレミアム会員による会員費収⼊ • 極論でいえば料理に関することをクックパッド内で全て帰結し たいという会社としての野望

クックパッドにおける推薦KPI設計の難しさ • クックパッドでは以前になんどか推薦を導⼊しようとしてうまく いっていなかった（らしい） ➔ 興味のある⼈は多いけど、いざやろうといったときは慎重になってしまう • 検索と推薦の⽬的が相反する（ように捉えられる）場合がある • 検索→クックパッド内で回遊させたい • 推薦→気に⼊ったレシピを（検索に頼らず）いち早く⾒つけたい ➔ 検索が強いクックパッドにおいて、検索のKPIに反しないように考える必要 がある

クックパッドにおける推薦KPI設計の難しさ • 明確なKPIを⽴てづらい（いままでもなかった） • ビジネスモデルとしてはプレミアム会員数を増やすというのが⼤枠の KPIとなるが、施策のゴールとしてみるべき数値への落とし込みができ ていない（⼩さなタスクに対するKPIとしては遠すぎる） • CGMという特性上、⼈気のレシピだけを推薦すると、多くの投稿ユー ザの満⾜につながらない • ユーザが⽬当てのレシピに⾏き着いたかどうかわからない • 単純にレシピを⾒つけて短期的に満⾜してもらうだけでなく、⻑期的 な影響も考慮する必要がある

いきなりひとりでやるぞ！と息巻いても、 うまくいかない • KPI設計にはドメイン知識が必要 • いままでどんなことをやって成功・失敗してきたのか • 他チームが今どういう開発をしているのか • どんなデータがあるのか • 簡単に思いつくことはだいたい過去に誰かが試している • 試しにテーマを決めて簡単なアルゴリズムを実装してデモをし てみたが、反応が薄い • サービス開発側とサイクルがあわなかった（他に優先度の⾼いタスク があった） • テーマ⾃体が筋がよくなかった。

ドメイン知識のある⼈を巻き込んだ • サービス開発の打ち合わせに潜り込んで⼀緒に（推薦関係なく） 施策を考える • どういうことができるのか説明して営業活動をする • ⼀緒に料理をする（ドッグフーディング） • KPIや取り組むべきタスクを⼀緒に考えようと⾔ってくれる⼈ ができた。 • 最初のKPIを定めることができた。

具体的には。。 • 投稿ユーザも満⾜のいくようなKPI設計を⾏う • 初つくれぽ数（そのレシピに対して初めて「つくった」コメントがつ く数）を増やすなど • 検索を活かす形の推薦を⾏うようなタスク設計を⾏う • 以前検索したユーザに対して、次に検索するクエリを推薦するなど • 作ったかどうかを判定するロジックを定義する • PV、レシピのマイフォルダ保存などを利⽤して間接的につくったと判 定するようにした

既存システムに推薦を組み込む ことの難しさ

既存システムに推薦を組み込むことの 難しさ • 推薦を⼊れる前提なしに作られたシステムのため、 推薦を⼊れることで負の影響がある可能性に対して 慎重だった • クックパッド検索を⽤いた回遊率低下への影響 • 推薦結果が悪い場合のプレミアム会員数低下の可能性 • 巨⼤Railsモノリシックシステムゆえの実装⾯の難しさ

⾃分の得意分野で挑もうとして失敗した • Apache Sparkを使った⼤規模推薦システムの経験があったため、 その知⾒を⽣かした協調フィルタリングシステム（ALS）などを 作ろうとした ➔ クックパッドにはそぐわなかった • 分散システムをメンテナンスできる⼈が他にいない • 次に⾷べたいものを推薦しようとしたが、推薦する対象と⼿法がマッチ しなかった • ECサイトのようにクリックとユーザの購買（料理）が結びつきにくいなど、⼊⼒デー タが難しい • 気分の影響や外⾷で⾷べたものなどの取得できないデータの影響が⼤きく、クック パッドで得られるデータだけではALSのようなアルゴリズムを⽤いた定式化はやりづ らい

最初から⼤きい効果を狙った • ⽬⽴ちそうな（=影響が⼤きい）部分を狙って 推薦システムを組もうとした。 • 複雑なデータを利⽤しようとした プロダクト側がのってこなかった

前に進めるためにやったこと • 推薦の前に検索を知る • 対象をしぼる • シンプルなAPIで実現できることをやる • 弾をたくさんうつ

information retrieval and information filtering are indeed two sides of the same coin. ― Information filtering and information retrieval: two sides of the same coin?(1992) 推薦の前に検索を知る （というか検索もやってみたかったというのもある） ※推薦は情報フィルタリングの結果を提案という形で⾒せるものと捉えることができる • 情報推薦は情報検索の⼀部（⾒せ⽅の違い）ということができる ➔推薦のためのアルゴリズムは検索にも利⽤できる • ⼀⽅で、デリバリ⽅式は異なるので、システムとしては分かれる事 が多い（SolrやElasticsearchなどの検索システムを利⽤して推薦を ⾏うこともできる） そもそも推薦と検索はコインの表裏

検索のプロダクトオーナを巻き込んで いろいろやった • 最初は検索を使っていて直したほうが良 さそうと思ったものを⾒つけてクエリ改 善をやってみる • 機械学習を⽤いたクエリ改善とかは他の メンバも興味を⽰してくれ、施策検討や 実装を⼀緒にやってくれるひとが増えた • 分析を⾏う中でドメイン知識も蓄積して、 徐々に施策の勘所が⾃分でもわかるよう になった 社内の情報共有サイトにやったことを記録。 タイミングが悪くて実にならなかったものも、 別の機会には役に⽴つかもしれない。

対象を絞る • 今だれも⼿を付けていない機能、影響が⼩さい機能、やりたい けど⼿をつけられていない機能にターゲットを変えた • ドメイン知識をもったプロダクトオーナを巻き込むことで、弾 のうちどころがわかってきた • KPI設計、実装、評価がスムーズに進められた • すすんでいろんな⼈が⼿伝ってくれるようになった

シンプルなAPIで実現できることをやる • ⾃分の得意分野にこだわるのをやめて、クックパッドのアーキ テクチャにあう⼿法を考えた • セッションベースの推薦など、クックパッドのデータのみで定 式化しやすいテーマを選んだ

弾をたくさんうつ • ⼀つのタスクのターゲットを⼩さく絞る分、たくさん弾を撃っ た（アイデアを出した） • 5個打って1個あてるくらいの気持ちでやる • やってみるとわたしは案外アイデアマンだった。笑

効果のある施策を⽣み出す ことの難しさ

施策のほとんどがうまく いかなかった。

例：クリックされにくいレシピの 検索スコアを下げる • 画像がないなど、明らかにクリッ クされにくいレシピの特徴がある ことが予めわかっていた。 • そうしたレシピの特徴を抽出して インデックスとして追加し、その 特徴をもつレシピの検索スコアを 下げるようにクエリを変えた • KPIとしてCTR@Kの上昇を期待し たがあがらない なぜか？ 画像がない

例：クリックされにくい特徴をもつ レシピの検索スコアを下げる 理由： クックパッドの多くのユーザは、レ シピをみてほしいと思って投稿して いるらしく、たとえば画像がないレ シピでいうと、驚くことに3.2%しか なかった（治安がよすぎた） (個⼈的には適当な料理メモみたいなかんじで雑に投稿し ている⼈がもっといるだろうとおもっていた) CTR@Kという指標を使ってしまうと、レ シピの3.2%に変化があったところで数値が 向上するまでには⾄らない ただし施策⾃体に意味がないかというとそ うではなく、⾒るべきKPIが間違っていた 画像がない

例：プッシュ通知の配信内容の最適化 • プッシュ通知の開封数が少ないという問題に対して、「〇〇を 検索したあなたに、〇〇を推薦します」の最適化を⾏うと課題 があったが、事前分析の過程で最適化しても開封数があがらな いことがわかった なぜか？

例：プッシュ通知の配信内容の最適化 理由 • そもそも機能開発側で、限られたユーザにしかプッシュ通知を 送られておらず、それをサービス開発側も認識していなかった 対処 • 機械学習で最適化する前にまずはプッシュ通知を送る対象を増 やしてもらった

教訓 • 施策の影響は多⾯的である • あるKPIが悪くても別の⾯からみるといい場合もあるし、その逆もある • 現実の問題は、機械学習の問題にあらかじめ落とし込まれている ものは少ない • 落とし込まれているように⾒えても実はそうではない場合もある

施策の90%は思ったとおりにいかない http://notes.stephenholiday.com/Five-Puzzling-Outcomes.pdf • “Google ran approximately 12,000 randomized experiments in 2009, with [only] about 10 percent of these leading to business changes.” • “80% of the time you/we are wrong about what a customer wants.” • “90% of what they try to be wrong.”

弾を撃ち続けることで形になっていった ものもある • 推薦 • プッシュ通知最適化 • セッションベースのレシピ推薦 • 検索改善はチームとして取り組むようになり、仕組み化できた • ⾃⾝は新規サービスの検索の実装も担当するようになった など

S3 技術の話がなさすぎて不安なので セッションベースの推薦アーキテクチャを 貼っておく RedShift レシピ データ Index 推薦 コンテナ クックパッド アプリ REST API Index作成 コンテナ ⽇次ジョブ実⾏ • レシピタイトルの名詞のみ抽出してfasttextの ⾜し合わせによるレシピベクトル⽣成 • ANNインデックス作成 • レシピタイトルに対して似たレシピを返却する • 多様性確保のため近傍N個からランダムなn個を 抽出

まとめ • 推薦には機械学習の知識も必要だがドメイン知識が重要 • プロダクトオーナーを味⽅につけることでうまくいく • 推薦（・検索）はなかなか思ったとおりには動かない • ⾃分の得意なことにこだわらず、できること、役に⽴つことを ひとつずつやっていく • 失敗するリスクがあるので5個やって1個あてるくらいの気持ち でやる