「夫子憮然曰、鳥獣不可與同羣。吾非斯人之徒與、而誰與。
「論語」微子、第十八、六

2013/02/25

いかに記事を推薦するか、その4(A/Bテストの新世界)

先週、 "Mynd Daily" を登録して下さった方は、 既に数回メイルが届いたはずだが、 記事推薦の調子はいかがだろうか。 あなたがかなりの数の記事をクリックしていない限り、 推薦システムはあなたのことをまだそれほど知らない。 つまり、 「コールドスタート」である。 さらに、まだあなたの好みの情報が少ないが故に、 推薦する幅が非常に狭いはずだ。 つまり、 「フィルターバブル」である。 この二つの大きな問題の他にも、多くの問題がある。 我々はできる限り推薦エンジンを改善していきたいし、 デザイン、サーヴィス設計、など、あらゆる点を改善しなくてはならない。

ではどうするか。 今、IT業界では「A/Bテスト、イズ、キング」 ということになりつつある。 つまり、A案がいいかB案がいいか、 ある改善案を試すべきか否か(現状がA、改善案がB)、 ミーティングで延々と議論したり、 または、上司や社長が「よし、分かった!」と轟警部風に決断したりするのは、 旧時代の大間違い。この素晴しき新世界においては、 実際にAとBの両方をやってみることが可能であり、 その結果から統計的判断をすれば良いのである。

例えば、販売サイトのデザイン案がAとBの二種類ある。どちらがいいか。 両方やってみればよい。 ユーザがこのサイトにアクセスしてくる度に、ランダムにAとBに振り分けるのだ。 「ランダムに」という点が味噌で、 これによって比較したいこと以外の因子が (例えば、ユーザの年齢、職業、その日の天気、エトセトラ)、 実験者が気付いている因子は勿論、気付いていない因子まで、 平均化される。よって、もしAとBのどちらかが優れているなら、 まさにその故に、優れている方の売り上げの方が多くなる。 例えば、千人ずつ振り分けた結果、Aでは六百回クリックしてもらえて、 Bでは五百回だった。 これが、偶然に起こりうる程度の偏りではない、と統計的に判断されれば、 Aを採用すればよい。 設計と判断にやや高度な数学が必要だが、メッセージはシンプルだ。 悩んでないで両方やってみる。勝った方が勝ち。 このプロセスを繰り返していけば、 製品はどんどん良くなっていくだろう。 ついでに言えば、愚かなミーティングも馬鹿な上司も廃止できる。

このように、理論的には薔薇色なのだが、これが実際は易しくない。 まず、比べたいことだけが比べられるという理想が怪しい。 ランダム化の威力は絶大だが、それでも余計な因子は残る。 例えば、社のホームページでA/Bテストを始めた。 しかし、これはAとBを比較しているのだろうか、 もしかして、以前のホームページからAへの変化と、Bへの変化を比較したのではないか。 Aの方がアクセス数が増えたが、これはAのデザインが一見して派手なので、 単に以前のページからの変化が斬新だったからかも知れない。 このように、何を測ったことになっているのかの理解が、 A/Bテストのブラックボックス性(つまり、「理由は分からないが兎に角こちらが勝ち」性) の故に、覆い隠されてしまうため、テスト結果を正しく生かすことが難しい。 時々、ビジネス書の類が「理由は聞くな、A/Bテストに従え」というような、 激しい主張をしていることがあるが、それは一面の真実ではありつつも、極論の類だろう。 (つまり、残念ながら、ミーティングも上司も必要だ。) 確かに、昔、理由も知らないままに統計学で町をコレラから救った医者がいたかも知れないが、 人類が本当にコレラから救われたのは、我々人間がコレラを理解したからである。

それから、A/Bを比べるための物差しが難しい。 例えば、 "Mynd Daily" の場合、何をもって「勝ち」とすればよいのか。 素朴に考えれば、記事のクリック率だが、本当にそれで良いのか。 既に「フィルターバブル」の話をしたときに、満点が満点ではない、と述べた。 また、通常このようなパーソナライズした推薦システムを試験する時、 その対抗馬には人気ベストテンのようなものが選ばれる。 折角、ユーザ毎の好みにあわせたのだから、少なくとも単なる人気商品セットは超えなければ、 というのだが、本当にそうだろうか。私はそれほど自明ではないと思う。 パーソナライズとは一体何であり、何のためにあるのか。 自分たちは何をしようとしているのか。お客は何を求めているのか。 何を物差しにして測るのかという問題は、 こういった質問に答えない限り解けそうにない。

第三に、弊社のようなベンチャーにとって大問題で、 私が個人的に「スタートアップの鶏と卵の問題」と呼んでいるものがある。 製品を改善するためにA/Bテストを有効に行いたいのだが、 そのためには沢山のユーザ数が必要だ。 しかし、既にその製品が優れていなければ、ユーザが沢山いるはずがない。 ユーザを集めるには先に十分なテストが必要で、 十分にテストするには先に多くのユーザが必要なのである。 この問題はかなり一般的だが、 推薦のような計測が難しく柔らかいシステムにとっては、なおさらクリティカルである。 ベンチャーで成功した人は皆、このジレンマを(偶然の力も借りてのことだろうが) 解いたのだろう。