クックパッドにおける推薦システムの取り組み

クックパッドにおける推薦システムの取り組み

林田千瑛 氏（以下、林田）：最後の登壇になりますが「クックパッドにおける推薦（と検索）についての取り組み」について、発表させていただきます。ちなみに、前の2人はごりごり数式を出してくれていたのですが、わたしの発表内容はどちらかというとサービス面での推薦の難しさのテーマですので、数式はいっさいでてきません。

最初に自己紹介です。

クックパッドのR＆Dチームでソフトウェアエンジニアをしております、林田と言います。もともと推薦の経験としては、以前にApache HadoopやApache Sparkクラスタ4、500台で推薦のアルゴリズムを組んでいた経験があります。

基本的に新しい論文の立証をどんどんやっていくよりも、アルゴリズムとシステムの両面において推薦を安定して動かすほうが得意なタイプです。クックパッドではビジネスよりのところも含めて、KPIを決めるところやビジネス目線で評価するところまで含めていろいろとやっています。

今日の内容は技術的な内容が薄いのですが、OSS開発を行ったり、いくつかのメディアで技術記事をかいたり、技術ハッカソンや機械学習のコンペにでたりと、エンジニアとしての活動も積極的にやっています。

早速本題に入ります。クックパッドは推薦をやっているというイメージが薄いかもしれませんが、レシピ推薦、プッシュ配信、レシピ作者のフォロー推薦、検索キーワードなど、複数の推薦システムが開発されています。今回はこの中身のアルゴリズムの話ではなく、推薦を入れるまでの「泥臭い話」を行います。

今回話す内容は3つです。

1つ目が「ビジネスモデルに即した推薦のKPI設計の難しさ」、2つ目が「既存システムに推薦を組み込むことの難しさ」、3つ目が「効果のある施策を生み出すことの難しさ」です。

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

最初に「ビジネスモデルに即した推薦KPIの設計の難しさ」です。そもそも私が推薦の取り組みを始めたのは、私2017年の11月にクックパッドに入社したんですが、そのときに「推薦をやってほしい」と言われたのでやることになりました。

しかし、「これを最適化してほしい」というのがなくて、自分で探さなければいけませんでした。推薦は手段であって、最初に何を最適化したいかという目的がなければ話が進みません。なので「どういうKPIを追いかけたいのか」という話を聞いていきました。

こういう話は、だいたいビジネスモデルに基づいてKPIを決めていきます。例えばわかりやすい例ではECサイトでは売り上げや、購入者数やサイトの閲覧数がKPIになります。広告ならインプレッションやクリック率がKPIになると思います。

クックパッドのビジネスモデルはCGMサービスです。レシピを投稿するのもユーザだし、レシピを検索するのもユーザというモデルですね。ちなみに売り上げの多くは、プレミアム会員という月額会費を払ってくれているユーザさんがいて、そのユーザさんの会員費による収入です。

そういったビジネスモデルのもとで、「クックパッドの推薦のKPI設計がけっこう難しい」という状況があったので、順番に説明します。

推薦KPI設計の難しさ

1つ目は、クックパッドでは過去に何度も推薦を導入しようと試みたことがあり、様々な理由で軌道に乗せる前にプロジェクトがおわってしまったりした背景がありました。このため、興味がある人は多いけどいざやろうとしたときは慎重になってしまって尻込みしてしまうという状況でした。

2つ目は、検索と推薦は相反する目的を持ってしまうように捉えられてしまう場合があるという問題です。クックパッドのサービスは有料会員のみ利用できる人気順検索が軸になっています。検索はクックパッド内で回遊させることで利益を得よう、というものです。一方でレシピ推薦は、なるべく早く気に入ったレシピにたどり着くようにしたいという目的です。この2つを補完しあうようにKPIの設計を行う必要がありました。

3つ目は、「施策に特化したKPIの落とし込みの難しさ」です。ビジネスモデルをもとにプレミアム会員を増やすという大枠のKPIを作ることができたとしても、何かしらの施策のゴールを考えていったときにプレミアム会員が増えるというKPIは遠すぎます。

CGMの特性上、良いレシピを推薦できさえすればいいのかというとそうではなくて、人気のレシピだけを推薦するとその投稿ユーザは見てもらいたいので「見てほしいユーザの満足」につながらなくなってしまうということがあり、検索ユーザだけでなく、投稿ユーザの満足度も向上しないといけません。このためKPIの落とし込みが複雑でした。この問題に対しては、より多くのレシピへのフィードバック（つくれぽ）が届くことをKPIとおくようにしました。

4つ目は、ユーザが目当てのレシピに行き着いたかどうかが分かるデータの指標を立てづらいという問題です。ECサイトであれば、購入していれば「ユーザのやりたいことが達成できた」と判断できますが、クックパッドの場合、レシピを見たかどうかはデータでわかるのですが、作ったかどうかや気に入ったかといったことがデータから取得しづらかったです。これに対しては、今あるデータをもとに評価できることをやるとともに、新たなデータを取得することも考えています。

あとは短期的な満足度だけでなく、長期的な影響度合いをどうやって測るかといった問題もありました。

こうした背景のもとKPI設計をしようすると、ドメイン知識が必要になります。ドメイン知識とは何かと言うと「今までどんなことを試してきて成功した、失敗した」といった情報や、他のチームが今どういう状況で、推薦のアルゴリズムを開発したからといってそれを入れられる状況なのかどうか、あとはそもそもどんなデータや機能があるのかといったことは、入ったばかりの人にはわからないんですね。

興味をもってもらうために、試しにテーマを決めて簡単なアルゴリズムを実装してみたりもしたのですが、反応が薄い。理由としてはサービス開発側とサイクルが合わなかったり、テーマ自体の筋がよくありませんでした。

こういった状況をどう解決していくかというと、ドメイン知識がある人を巻き込んでいくことが必要で、これはけっこう難しかったです。やはり、ドメイン知識のある偉い人は忙しくて、簡単に時間を取ってくれないので（笑）。

最初はサービス開発の打合せに潜り込んで、推薦関係なく「この画面のこの色ちょっと良くないと思うけど」とか「このエディタはこうしたほうがいいと思うんだけど」とか、推薦に関係ない施策も一緒に考えて信頼を勝ち得ていくということをしました。

他にはどんなことができるのか「推薦とは？」みたいなことから説明して営業をしたり、ドッグフーディングをして自分もドメイン知識を得ようということで信頼を得たい人と一緒に料理をしたりしました。

そうしていった結果、ドメイン知識のある人をうまく巻き込むことができ、KPIを決めて「何か一緒にやっていこう！」という状況を作ることができました。

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

次に「既存システムに推薦を組み込むことの難しさ」です。新しいサービスなら「ガンガンやっていこう！」という状況を作るのも難しくありませんが、クックパッドの特性として推薦を入れることで生まれる負の影響に対して慎重なところがありました。検索を用いた回遊率の低下の影響を考えたり、「推薦結果が悪い場合にプレミアム会員数が低下したらどうしよう」とか……。

レコメンデーションはオンラインで入れてみないと影響がわからないので、「まず試す」ということへのハードルが大きかったです。あとはクックパッドは巨大なモノリシックシステムなので、それ故の実装面の難しさもありました。1人で開発して1人でそのシステムに組み込む、みたいなことは簡単にはできませんでした。

また、これは私が悪いのですが、自分の得意分野で挑もうとして失敗しました。

私はもともとApache Sparkというソフトウェアが得意だったので、「自分の得意分野で挑むのが筋がよかろう」と思って、デモを作ってみたりしたのですが、そもそもクックパッドには分散システムに詳しい人がそれほどいなかったので、メンテナンスができないものは、なかなか入れることができませんでした。

他には例えば「次に食べたいものを推薦する」という推薦をしたい場合に、ユーザがレシピを決めるためのデータとして、外食などクックパッドが取得できていないデータの影響があって難しいといったことがありました。

なかなかユーザの興味とレコメンドの結果が結びつかず、気分などの取得できないデータの影響が大きかったです。また、最初から大きい効果を狙ったのも良くなかったと思います。

最初から影響の大きいところに入れることを想定したものを作ったんですね。ですがそうなると、負の影響が出る場合にも範囲が大きいということになりますし、レコメンドの改善のストーリーとしても複雑なものを使おうとすると、プロダクト側としては「忙しいし、そこまではやるのは難しい」となってしまう状況がありました。

それでも前に進めなければいけないので、考え方を変えました。1つは、みんな「検索が大事だ」と言うので、検索と推薦の両方がうまく補完しあえる方法を考えるために、「そもそも検索の中身を知ろう」ということをやりました。まあその結果推薦がいらないということも考えられますが、どちらにしろ一番良い方法がわかればそれでいいわけですし。わたしとしても検索の中身にも興味があったので良い機会だと思いました。

また、対象を絞ってシンプルなAPIでスモールなタスクを定義して取り組むことにしました。あとは、弾をたくさん撃つということをしました。

まず推薦の前に検索を知る、という話です。1992年に発表された有名な論文で『Information filtering and information retrieval: two sides of the same coin?』というものがあります。推薦と検索はコインの表裏で、情報推薦とは情報検索の一部であり、見せ方の違いと言うことができるという話です。一方で、見せ方が違うというのはシステムとして分かれることが多いです。

前にすすめるためにやったこと

検索のプロダクトオーナーを巻き込んでいろいろやりました。

ここに書いていることがいろいろやったことのリストです。

レコメンドや機械学習は関係なく、検索を自分で使ってクエリの改善ポイントを洗い出して改善を行ったり、機械学習を使って得られた特徴をインデックスとして利用してその効果を確認しました。最初は1人でやっていましたが、継続的にやり続けると、しだいに興味をもって、一緒に取り組んでくれる人が増えました。

また、ドメイン知識も増え、より効果的な施策を考えることができるようになりました。このようにして、実装や評価をスムーズに進めることができるようになりました。

「対象を絞る」という話については、最初の失敗として、既存システムがある程度ビジネス的にもシステム的にも安定している状態で不安定な要素を取り入れるということは、思ったよりも大変なことだと学びました。

そこでシステム影響やビジネス影響が少ない部分に取り組みました。実装面でも、技術的に高度なことを行うよりも、なるべくシンプルに実現できることを行うようにしました。そうすることでステークホルダも最小限で済み、小さくても短い期間で成果を得ることができました。

「弾をたくさん撃つ」に関しては、対象を絞って小さくする分、たくさん失敗しても1つ当てるような気持ちで取り組むようにしました。

プロダクトオーナなどに壁打ち相手になってもらって、たくさんアイデアを出していきました。やってみるとわたしは結構アイデアマンでした！

（会場笑）

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

最後に「効果のある施策を生み出すことの難しさ」です。今まで説明したように、検索や推薦の取り組みを継続的に行うサイクルをつくるところまではできるようになりました。しかしながら、施策の結果は全く思ったとおりにはなりませんでした。例えば、画像の有無など、「情報の揃っているレシピのほうが検索スコアが高くなるようにする」ということを行いました。

この施策では、KPIとしてCTR@K（上位K件のクリック率）が上がることを期待していましたが、実際にはほとんどあがりませんでした。これは会場に質問したいと思いますが、どうしてだと思いますか？

発言者1：はい。

林田：はい！

発言者1：情報は揃っていなくてもネタとしておもしろいレシピだった。

林田：……ちがいます！

（会場笑）

発言者2：ユーザは画像がないレシピをサムネイルで判断してクリックせず、そのレシピのクリック率には影響がないのでは。

林田：ありがとうございます。ここでいうCTR@Kはというのは、検索結果の上位K件のクリック率なので、レシピ単体のCTRではないです。

発言者2：なるほど。。

発言者3：データが間違っていたとか？

林田：違う（笑）。

発言者4：そもそも画像がないレシピの数が少なかったから、KPIへの影響が少なかった。

林田：あたりです！　クックパッドに投稿されるレシピのうち、ほとんどが丁寧にかかれたレシピばかりなんですよ。これいいことなんですけどね。他のメディアだとそうはならないと思うんですけど、クックパッドのサービスの治安が良すぎて（笑）。

私の想像としては、自分へのメモ用で適当に投稿する人もたくさんいるんじゃないかなと思っていたのですが、そうしたら3.2パーセントしかありませんでした（笑）。

（会場笑）

「レシピを投稿するユーザは思ったよりも人に見てほしいと思っている」んですね。ユーザやデータへの理解が不十分でした。

もう1つ例を用意しました。プッシュ通知の配信内容の最適化です。

配信内容を個人の検索履歴をもとに最適化するというタスクに取り組みました。こちらは施策を行う前の分析の段階で、ある問題によって、最適化を行っても開封率はあがらないだろうということに気づきました。時間がないのでこちらは答えを言ってしまいます。

理由は、そもそもほとんどのユーザに対象となるプッシュ通知が送れていなかったからです。それを開発側も気づいていませんでした。

（会場笑）

話をきくと、なぁんだ、と思うかもしれませんが、ここで、『Trustworthy online controlled experiments』という論文を紹介します。

この論文では、GoogleやNetflixなどの大企業の事例をもとに議論しており、「施策の90パーセントは思った通りにいかない」と論じています。この論文の内容を鑑みると、検索や推薦の改善は、10個やって1個あてるくらいの気持ちやるのが大事と思っています。！

今回はあえて失敗事例をたくさん出しましたが、成功した施策もたくさんあります。これも面白いのですが、「え、こんなのがこんなに効果あるの？」というよい方向で期待はずれなことがあったりもしました。また、1つのタスクだけ見ると失敗に見えても、そこから思いつくアイデアがあったり、取り組みのプロセスを評価してもらって次の仕事につながることがあったりと成功につながる失敗でもあったとも思っています。

まとめです。

いいたいことは4つです。推薦は機械学習の知識も必要ですが、ドメイン知識も必要ということ、プロダクトオーナーを味方につけることが重要ということ、自分の得意なことにこだわらず、必要とされることを考えて主体的に動くこと、あとは失敗に過度に敏感にならず、複数やって1つ当たればいいという気持ちでやることです。ここでいったことは1個人の経験によるものなので、どの現場でもあてはまることではないかもしれませんが、参考になれば幸いです。ありがとうございました。

（会場拍手）