レコメンドシステムの落とし穴 Part 3 - 「好み」を理解するためにできること

AmazonやYoutubeなどのレコメンドシステムは、AIやビッグデータによってユーザーの「好み」を理解している、という前提がありますが、実はユーザーの「好み」を正確に理解するのは思ったより難しいものです。

「好み」というのは誰もがわかっているようで、実はよくわかっていない。それだけに何らかのプロダクトやサービスを提供している人達にとってユーザーや顧客の「好み」を知るのは難しいという話をこれまで2回に渡ってしてきました。

  • レコメンドシステムの落とし穴 Part 1 - ユーザーの「好み」と「選択」と「幸福」- リンク
  • レコメンドシステムの落とし穴 Part 2 -「好み」の操作と正当化 - リンク

ところで、「好み」を知るのは難しいで終わってしまってはただの学術論文やウンチクと変わりません。そうではなく、そうした前提がある中でそれでも何かできることがあるのではないでしょうか。

このシリーズの最終章である今回は、まさにこうした問いに対していくつかのヒントを提示するために、元の記事である、「What Does it Mean to Give Someone What They Want? The Nature of Preferences in Recommender Systems」から一部を抜粋して紹介したいと思います。

以下、要約。


「明らかにされる好み」を超えたレコメンデーション

これまで「好み」を理解するのは難しいという話をしてきましたが、それでは現実的にどう解決すればいいかという話なしに、こういう話をしてもあまり役に立ちません。

実は運のいいことに、「明らかにされる好み」を改善するために少なくとも2つの戦略があります。

様々な方法でユーザーの「好み」を引き出す

1つ目は、ユーザーのエンゲージメントに関するデータから得られる潜在的なシグナルにだけ頼るのでなく、ユーザーが何が欲しいのか尋ねるやり方を拡大してみるというものです。

例えば、あるトピックやチャンネル(Youtubeなどの場合)を購読するかどうかといった選択をユーザーに頻繁に提示したり、レコメンドされたものをこれ以上レコメンドするのを止めるよう設定できるようにしたりといった方法などが挙げられます。Youtubeなどでは「このチャンネルをレコメンドするのを止める」といった機能が実際にありますね。

ただ、こうした機能を使うのは限られた一部のユーザーであることは確かです。さらに、たとえより多くのユーザーがこうした機能を使うようになったとしても、自分の思うようなものを正確に知らせるのは難しいというのも事実です。

また別の方法としては、自由記述を含んだアンケート、外部の評価サービス(市場調査、世論調査、信頼度評価など)を使って「好み」に関した情報を収集することです。

さらに、ユーザーがプロダクトを使った直後に振り返ってもらい、感想を聞くことで、中毒性のせいや、または十分な情報を与えられてない状況でなんとなく選択してしまったのかどうかに関するインサイト(知見)を得ることができるかもしれません。実際に、ユーザーが読んだ記事に対してそれが有意義なものだったかどうか後から尋ねるようなサービスもあります。

よくデザインされた一連の質問を用意することで、ユーザーの答えの中から矛盾のない、そしてユーザーの好みをより正確に表していると言えるインサイトを引き出すことも可能でしょう。

選択のプロセスを選択、好み、幸福に分けてモデル化する

2つ目の戦略として、ユーザーが選択を行うプロセスを分解し、選択、好み、そして幸福といったものの違いが認識できるようにモデル化するというものです。

例えば、あるツイートの価値を、ベイジアンネットワークにおける潜在的な変数として全体のエンゲージメントに貢献する一部のものとして表現することができます。

別のやり方では、進化していく好みをマーコフモデルにおける内部のステートとしてモデル化し、あるタイプの「好み」の変化は幸福とは関係ないということを手動で定義できます。レコメンドエンジンが倫理的でない方法でユーザーを操作するのを防ぐということです。

さらに別のやり方として、ユーザーを2つの選択を行うプロセスを持っているとモデル化するというのもありでしょう。1つは直感的な選択として、もう1つはユーザーの幸福を反映させるためにしっかりと考えられた選択としてというものです。好み、選択、幸福を異なるものとして明確にモデル化できるのであれば、他にも様々なやり方があるでしょう。

全てのレコメンドシステムは人々の好みをモデル化した上で運用されています。ということは、どのようにモデル化するかはシステム自身がどう機能するかの基準を決めているということなのです。

さらに、たとえレコメンドされたものがユーザーの好みに完全に沿うものだったとしても、それは全体として私達の住む社会にとって有益となる結果を生むとは言えません。

ユーザーがほんとうに望むものを与えるためには、好み、選択、そして幸福の間にある違いをモデル化する必要があります。システムそのものがユーザーの好みを構築または操ることができる、そうした可能性を持っているということを忘れてはいけません。こうした問題を防ぐためには、ユーザーの選択を元にした行動データからただ推測するだけでなく、ユーザーが何を求めているのかユーザーに対して積極的に聞いていく何らかの仕組みを持っておく必要があるのです。


要約、終わり。

あとがき

AI、ビッグデータ、データサイエンスと言った言葉が飛び交ったりすると、人々の反応は大きく分けて2つに分かれます。

まず1つ目のタイプは、AIやビッグデータがあれば何でもわかるようになる、人々が自分たちを理解している以上にコンピューターが自分たちを理解できるようになる、というものです。やがて人間による意思決定は必要なくなり、AIが全ての意思決定を行うという極端なケースまで行き着くこともあります。

今回のシリーズでは、人間の「好み」を理解することがいかに難しいかについて話してきました。それをもとに考えると、こうしたAIやビッグデータによって人間の好みを理解できるというのはナイーブで理想的であり、さらには、昔からある「理性万能主義」の現代版であると言えるのではないでしょうか。

もう1つのタイプは、AIやデータによって人間を理解することなんてできないので、関わるのも、使うのも無駄だというものです。こういうタイプの人達は、うまくいかなかったニュースを見つけ出し、「だから、俺はデータなんて信用しないんだ」とデータに関するもの全てを否定し、人間の経験に培われた直感を重視します。

今回のシリーズで見てきたように「好み」を理解することが難しいと聞くと、だからデータを使ってもしょうがない、と結論づけてしまうことになります。しかし、こうした視点は、既存のデータを使ってユーザーの好みを理解することは難しいという事と、好みを理解することはできない、という2つのことを同一視しています。

例えばレコメンドシステムによってレコメンドされたものを買ったり、見たりすることでユーザーが自分の持つ価値観に照らし合わせても満足することが実際にある、という点を見逃してしまうことになります。

本文にもあったように、現在のデータのとり方に問題があるのであれば、とり方を変えたり、補足するためのデータを取ったりして、改善していくことができます。また、好みを理解するためのプロセスやモデルに問題があるのであれば、本文にもあったように、好み、選択、幸福と切り分けてモデル化することで改善できるかもしれません。

AI、データ至上主義に走るのも問題ですが、逆にAI、データ懐疑主義に走ってあきらめてしまう、または前に進めなくなるというのも、それはそれで問題ではないかと思います。

好みだけでなく、人間を理解することは難しい、今わかっていることもひょっとしたら間違っているかもしれないということを謙虚に受け止めた上で、ある特定の分析手法や理論だけに頼るのではなく、データの集め方、取り方、仮説や質問の立て方などを含め、大きな視点から見直すことで、複雑な人間をより正しく理解するために前に向かって進んでいくことができるのではないかと思います。

そうして少しづつでも「好み」の理解を改善させていく、そうすることでユーザーにとってよりよい「選択」が実現されるのを支援していく。そうしたことがサービスを提供する側にとっても長期的な価値となる、そうしたサービスを提供するビジネスこそが社会的にも愛され、さらにビジネスとしても長期的に成長していけのではないでしょうか。

少なくとも、毎日データに関わる私は、今回このシリーズを終えてそのような思いを新たにしました。皆様にもこのシリーズが何らかの形でお役に立てたことを願っております。

以上。


データサイエンス・ブートキャンプ・トレーニング

データサイエンス、統計の手法、データ分析を1から体系的に学ぶことで、ビジネスの現場で使える実践的なスキルを身につけたいという方は、ぜひこの機会に参加をご検討ください!

ビジネスのデータ分析だけでなく、日常生活やキャリア構築にも役立つデータリテラシー、そして「よりよい意思決定」をしていくために必要になるデータをもとにした科学的思考もいっしょに身につけていただけるトレーニングとなっています。

詳細を見る

Export Chart Image
Output Format
PNG SVG
Background
Set background transparent
Size
Width (Pixel)
Height (Pixel)
Pixel Ratio