データサイエンスのコンペから得られた知見とは?
元No.1 Kagglerが明かす舞台裏

Cutting Edge Data Science Technique #2/2

データサイエンス最先端活用
に開催

Recruit Instituite of Technologyがデータサイエンスの活用事例を広く共有するイベント「データサイエンスの最先端活用」を開催しました。長年Kaggler rankingで1位であったDataRobot社のOwen Zhang氏は、データサイエンスのコンペで行われている内容について語りました。

提供:株式会社リクルートホールディングス

データコンペティションから得られた知見

Owen Zhang氏:残りの時間ですけれども、私が参加したコンペのいくつかの例をご紹介します。どういうものがうまくいくかというアイデアが得られるのではないかと思います。

新しくてすばらしいアイデアを出すには、それに伴って10〜100のアイデアも出てくるということです。それらすべてのアイデアがすばらしいということではありません。

すべての成功には、惨憺たる失敗がたくさんあるということで、私のやっていることのすべてが成功するわけではないということです。先ほど言いましたけれども、(成功の要因には)運も大きいということであります。

反対に、多くのアイデアはまったく使えないということです。データセットを見て、まったくアイデアが出ないときもあります。どうすればいいか全くわからない。これは不可欠ですけれども、データセットが新しいもの、あるいはリレーションが正しくされるということが重要です。

第3に、いいアイデアでリレーションがよくても、時にはほかの参加者があまりにも先に進んでいるので対応できないということもあります。これは基本であります。

どういう理由でうまくいかなかったかということでありますけれども、これはうまくいった例です。

Amazonのユーザーアクセス予測

これはAmazonが提出したユーザーアクセスの予測であります。見てみると、データポイントが非常に多い。商品のほうから特定のリソースに対してアクセスを許可するか却下するかということであります。

ということで、Resource ID、Mgr ID、User ID、それからDept IDというようなかたちで、さまざまな特徴があるということでございます。

多くのフィーチャはカテゴリであるということで、数値値ではないということです。A〜Zというような値ということになります。

これらのフィーチャーは、アルゴリズムにうまくフィットしないといけません。その中で、それらを非数値フィーチャーを数値として表すかという、よくある大きな課題であります。ということで、フィーチャーエンジニアリングの約50パーセントはそういう課題であります。

ということで、カテゴリフィーチャーで複数の分類がある。それを、各レベルでいくつのデータポイントがあるかというようなかたちで数値化することもできますけれども、あるいは100、500というようなかたちで。もう1つできるのは、あるいは各フィーチャーのレベルを平均化するということであります。

そしてすべてのカテゴリのフィーチャーを数値化したあとに、さまざまなことができます。ということで、これらのアルゴリズムすべて数値化のインプットとして取り込むことができます。

もう1つ興味深い点は、すべてのモデルのアルゴリズムが使える、そして最終的なアンサンブルでは改善に繋がるということになります。このモデルに関しましては、ご興味があれば、こちらのURLにアクセスしていただければと思います。

フィーチャーエンジニアリングの難しさ

このカテゴリフィーチャーでございますけれども、フィーチャーエンジニアリングの1つの難しさがここにあります。平均値、グループに1,000ユーザーがいます。

Aを見たときに必ず75パーセントのアクセスを可能にするチャンスがあると思います。これは比較的簡単なアクションです。

しかし平均値を使うと、そういうことになってしまいます。これを防ぐために何かしなければいけないと思います。3つのステップがあります。

レスポンスの平均とありますけれども、特定のrowだけを使っていくと思います。そして、そのインスタンスが少ない場合は、ローレスポンスのところでありますけれども、そのrowというものを選択していきます。

しかし、そのデータの信憑性というものが1パーセントあれば、それにかけていくということであります。

まったくデータがないところから大量のデータがあるという移行がスムーズにできると思います。

最後の問題になりますけれども、小さな任意のノイズを当てはめていくということであります。人口的なノイズを追加することによってモデルの改善に繋がることがあります。ということで、このようなモデルを使います。

すべてのrowを使う必要はありません。Amazonに最も重要なのはフィーチャーを数値化するということになります。

保険会社の予測コンペティション

もう1つは、保険会社がスポンサードしたコンペです。ここで予測したいのは、ユーザーが保険を購入するときに、どのオプションを選んでいるかということです。いろいろなオプションがあるわけですね。上限があったり、控除対象がどのぐらいであったり、そういうのがいろいろあります。

7つのターゲットを設けました。それぞれのターゲットは相関関係があります。つまり、上限が高い場合、この人はこういう人だろうという相関があるわけです。

そして、これは非常に難しいコンペティションになりました。なぜかというと、評価の条件がオールオアナッシングだったんですね。7つのオプションすべてを完璧に正解しないとダメだったわけです。全部合わなければゼロスコアということでした。

それからもう1つ。ユーザーに対してA、B、C、D、E、F、Gというようなコンビネーションがあって、そして最後のE、F、Gになって、最後の選択を予測するということになったわけです。

実はこの最後の選択肢というのは、一番最後に引用されたモデルというのが大体53パーセント正解なわけですけれども、このコンペティションの最高のモデルは53.743正しかったわけですね。そしてこれはプラス47パーセント、私は3位になりました。0.44パーセント改善できたんですね。ちょっとミスりましたけれども。

こういった改善というのは確率的には極めて優位です。現実的に優位かどうかわかりませんけれども、統計的には非常に優位だと思います。

ここにはおもしろいチャレンジがありました。もちろんコーディングのチャレンジがありましたけれども、ここはなんとかレスポンスの変数の間の相関関係を補足しないといけない。そしてベースラインに負けないということが大事だったわけです。ベースラインのほうがいいという場合もあったりしますので。

そこで私たちがやったこと。相関関係のためにChained Dependent Modelをつくりました。まず、1つのターゲットをスタンドアローンでつくりました。仮にFとします。

Fというのが一番自由度の高いターゲットであるということなわけです。そしてFができたら、今度はFに対しての条件づけられたモデルをつくります。確率論をご存知の場合、Fという確率があって、Fの中でのGという確率です。

このようにF、G、B、A、C、E、Dというかたちでやっていた場合に、この相関をうまく表すモデルができたわけです。

ベースラインの問題はより簡単でした。その企業のベースラインがあれば……ちょっと採用してみたんですけどうまくいかなかったんで、別のモデルをつくったわけです。どんなデータポイントで、どのモデルがうまく機能するかというのを予測します。

そして信頼性が高くなければこの予測は実行しないということです。そしてこれらのデータに関してどんどんと改善をしていったということでした。

この予測コンペにおいては、ベースラインを失わず相関関係を求めるということでしたけれども、次の例です。

別の保険会社がスポンサードしたコンペですけれども、保険会社とテクノロジー会社という2種類の企業がコンペを主催したということで、100万のrowがあり、ロスは1000万、フィーチャーは300ということでした。

その中での有用なフィーチャーは30ぐらいしかないということだったので、いろいろと大変なコンペでした。

そして残念ながらほとんどのフィーチャーは匿名化されておりました。方針のフィーチャー、それからGeodemographics、天候と犯罪率がありました。

これを使ってよりrowの数を縮小していったわけですね。Policy Characteristics、これはその保険の内容の特徴なんですけども、これは残しました。

Geodemographicsからは1つのフィーチャー、気候からも1つのフィーチャーを抽出して、犯罪率に関してのフィーチャーは0ということにしました。

このコンペではフィーチャーの抽出よりも選択のほうが大事だったので、いろいろなモデルを作っていきました。全体では6つのモデルがありました。いろいろなフィーチャーをサブセット化して作っていきました。このコンペではフィーチャーの選択、圧縮が非常に重要な課題だったということになります。

広告のクリック数に関するコンペ

最後の例です。こちらは昨年やった広告のクリック数に関するコンペですね。やはり21世紀の一番重要な課題になっていますね。クリック数をいかに集めるかということですけれども。

おもしろいデータがありました。テーブルは8つです。そして匿名化はほとんど行われていなかったので、それはとてもいいなと思ったんです。やっぱりフィーチャー名があるのはいいと思うんですね。

そして比較的大きなデータセットでしたので、4億ローということでした。またサーチにおいても1億ローということでありました。

私の観点から言うと、1つのノードでやっても、やはりビッグデータの場合には分散する必要があると思います。

Avitoというコンペでしたけれども、非常におもしろかったなと思います。とにかくデータが大きかったということ。それからかなり重要な構造が中に入ってたのでフィーチャーエンジニアリングが十分にできました。

大体時間の3分の2ぐらいをフィーチャーエンジニアリングにかけて、モデルのフィッティングを3分の1ぐらいの時間でやりました。

たくさんrowがありましたので、あんまりたくさんのモデルアルゴリズムを試せなかったんですね。最も人気があるeXgboostを唯一のモデルとして構築していきました。

それからデータセットがかなり大きいですね。何百万レベルですので、十分なデータポイントがありますので、オーバーフィテッィングがあまりない。かなり信頼性の高いものができたということでした。このコードはGitHub公開しております。

このコンペはフィーチャーエンジニアリングのコンペだったわけですね。ですからデータを見てどのぐらいフィーチャーをとれるかということだったわけです。いわゆる生のフィーチャー、データから直接出てくるもの、それから1日のいつ、あるいは曜日などに関わるもの、時間ベースのフィーチャーもあります。

またシーケンスベースのフィーチャーですね。何かクリックストリームがあったりとか映画視聴の履歴とか、そういったものの場合にはシーケンスベースのフィーチャー。

そして以前のレスポンスベースということですね。今までどのぐらいの広告をクリックしたか。なんでもクリックする人というのはいるんですよね。なんでもいいから連続クリックするみたいな人はいます。私はディスプレイ広告は絶対にクリックしませんので、どうしてあそこにお金をかけるのかはわからないんですけど。

またテキストベースのフィーチャーがあります。テキストがあった場合には必ずこれが採用できます。おもしろいカテゴリーフィーチャーとしては、カテゴリーフィーチャーを言葉のように結合するということです。そしてそこでテキストのいろんなことをかけていくということです。

テキストの近似性というのもあります。いわゆる検索ベースの広告というのがあります。この検索後の近似性と広告文の関係を見ていくということができます。

また単純なテキスト、何スペースあるか。また価格ベースのフィーチャーがあります。つまりこういったカテゴリーのものに関しての平均価格はどうなのか、あるいはそれに対してより高いのか低いのかというフィーチャーです。 

そのほかにおもしろいのは、エントロピーベースのフィーチャーなどもあります。つまりその人の履歴がどのぐらい大量かどうか。

たとえば家電だけを見てる人がいるわけです。あるいは衣料を見たり本を見たり、とにかく特定なものに偏ってないような履歴の人もいます。

それから最後のものはグローバルレスポンスのフィーチャーを使っていくということですね。このようなフィーチャーエンジニアリングをやってこのコンペで闘っていたわけです。

おそらくほかのチームではいろんなアプローチ使われてると思いますけれども、本当にリッチなデータがあるときにはこんなふうにやっていくということですね。

データサイエンスのコンペVS現実世界

最後に、データサイエンスのコンペティション 対 現実世界ということで話したいと思います。やっぱりモデルのインプリメンテーションだと思います。というのもインプリにまったく制約がないと本当に複雑なモデルをつくってしまいます。誰も実サービスで35 のコンポーネントモデルがあるような複雑なモデルというのはインプリメンテーションしたくないと思うのです。

2つ目、コンプレックスモデルのインプリが難しいということだけではなくて、それがうまくいかないというリスクがあります。我々が予測をするときにそこに仮定として、将来が過去と同じだと思ってしまうこと。それが必ずしも本当ではないということがあります。

我々が学んだ教訓としましては、例えばデータセットを入れると多くの人がインターネットでは、多分内部でモデルをつくってくるでしょう。データサイエンスの知識がなかったとしても内部のチームでつくってくるでしょう。

しかしながら直接それを実装する人はあまりいません。というのも複雑性を考えてないからです。じゃあ我々は何を学ぶのかというと、このコンペから学んだことというのは、データの問題を特定するいい方法があります。

要は理想的なモデルというのは一体どういうものなのか、どれだけの予測結果を内部のチームの方々と照らし合わせて作業出来ているか。

最後になりましたけれども、今日お話したことはすべてがテクニカルな部分でありました。でも、そのもっと上にはいろいろな要素があります。要は人と一緒に仕事をするということ。データサイエンスコンペティションというのは、人々の行動を変えていきます。

データサイエンティストとして、テクニカルなものだけではなくて、ほかの人とどのようにインタラクションを取れるかということも大事であります。

やはりデータサイエンティストとして優秀な人というのは、人間とのインタラクションもうまいということであります。どうもありがとうございました。

(会場拍手)

Occurred on , Published at

Recruit Instituite of Technology

Recruit Instituite of Technologyに関するログをまとめています。コミュニティをフォローすることで、Recruit Instituite of Technologyに関する新着ログが公開された際に、通知を受け取ることができます。

このログの連載記事

1 DataRobot社・Owen氏が語る、データサイエンスの定義と改善プロセス
2 データサイエンスのコンペから得られた知見とは? 元No.1 Kagglerが明かす舞台裏

スピーカーをフォロー

関連タグ

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

ログミーBizをフォローして最新情報をチェックしよう!

人気ログ

人気スピーカー

人気コミュニティ

ピックアップ

編集部のオススメ

そのイベント、ログしないなんて
もったいない!
苦労して企画や集客したイベント「その場限り」になっていませんか?