AI事業本部 Dynalystのデータ分析担当の金子(@coldstart_p)です.

先の1/25(土)にatma株式会社様が主催するオンサイトデータ分析コンペティション atma杯で,AI事業本部が共催として関わらせていただきました.コンペの際の雰囲気などの当日レポはatma様のblogの方でも記事が書かれる予定なので,今回の記事ではデータ提供側のあれやこれやという視点でのまとめをしたいと思います.残念ながらデータや課題の中身の詳細は触れることができないので,ざっくりとしたお気持ち記事となります.

そもそもデータコンペとは?

広義のデータ分析コンペというのは色々あると思いますが,今回の記事では「主催者が出したデータ,課題設定を元に競技者が機械学習モデルを作成し,予測精度を競い合うコンペ」に限定します.代表的なものだとKaggleやSIGNATEなどのプラットフォームが有名ですね.

昨年には「Kaggleで勝つデータ分析の技術」(書籍公式サイト)という名だたるKagglerが書いた書籍がベストセラーになったり,ここ1~2年でもかなりデータ分析コンペ界隈の広がりと盛り上がりを感じています.

オンサイトコンペ,あるいはatma杯について

特にここ1〜2年で盛り上がりを感じる流れとしてはオンサイトコンペという形式でのコンペ開催の増加です.
オンサイトコンペそのものについては,atma杯第1回優勝者かつKaggle Grandmasterの大越さん(@takuoko1)のインタビュー記事を参考にするのが早いかもしれませんが,要するに1~2日の短期間で開催される会場参加者限定のオンサイトイベントです.

従来Kaggleで行われてきたコンペは2 ~ 3ヶ月の長期に渡って行われるものでした.対照的にオンサイトコンペにおいて特に難しいのはその期間の短さゆえ,圧倒的に手の速さが求められるという点だと思います.

「Kaggleは実務に関係ない/役立たない」という批判に対しての応答としてKaggleの経験を通して得られるPDCAサイクルの高速化といったものがよく挙げられますが,そういう点ではオンサイトコンペの方がより実務的な,短期間で高品質のoutputが求められるという条件に即した形式と言えるかもしれません.(1日限定なのでいいfindingができるかは運も絡みますし,うっかり袋小路に入ってしまいそのままコンペが終わってしまったりすることもあります.また手の速さだけが能力の評価軸ではないので,「オンサイトコンペで弱い = 実務能力が低い」といった極端な評価をするつもりはありません)

データ分析コンペプラットフォームの最大手であるKaggleも,2018年からKaggle Daysという2日間のオンサイトイベントを開催しており,その2日目に参加者限定のデータ分析コンペが開かれるのが通例になっています.

2018年ではワルシャワでの1回でしたが,2019年には東京を含む世界各地で全5回開催され,Kaggle Days Tokyoでは日本経済新聞社がデータ提供,主催をしたことが話題になりました.

日本でも採用などを目的としたオンサイトデータ分析コンペを主催する企業が最近増えているように思いますが,その中でもatma杯は2019年の5月に第0回を開催してから毎四半期ペースでオンサイトコンペを主催し,いち早くデータ分析コンペ界隈の注目を集めていたオンサイトイベントでした.0~2回は大阪開催という形にも関わらず東京からの参加者も多く,またKaggle MasterやKaggle Grandmasterなども参加するなど,レベルの高さと知名度において日本のオンサイトコンペの中では群を抜いた存在でした.その中で東京開催を求める声も多かったため,今回はCAとの共催という形で,初の大阪東京同時開催という形式でのatma杯に関わらせていただきました.

参加者は大阪37名,東京60名の合わせて97名,日本に数名しかいないKaggle Grandmasterが3名も参加,Kaggle Masterも20名前後参加と,非常にレベルの高くかつ盛り上がったイベントとなりました.

結果は1 ~ 3位全員Kaggle Masterというなんともハイレベルな争いでした.

結果発表中

(結果発表中)

東京会場の記念写真

(東京会場の記念写真)

(大阪会場の記念写真)

非常に盛況なイベントとなり,参加者の方々やatma社の方々には大変感謝しています.一方でデータ提供側としては開催まで「こんなに人を集めて低質なコンペしか開催できなかったらどうしよう」という激しい不安を抱えながら過ごすことになったのですが,今日の記事はそれにまつわる話です.

良いデータ分析コンペとは?

データ分析コンペ界隈では「良コンペ」,「神コンペ」といったコンペそのものへの評価がされることがままあります.じゃあそもそも良いコンペってなんだ? という疑問が生じるわけですね.

以下のYoutubeの動画を参考にしてみましょう.(28:10過ぎから)

この動画はKaggle Grandmasterの小野寺さん(@0verfit)がKaggle Days Tokyoの1日目で行ったPresentationなのですが,その中で良質なテーブルデータコンペの3つの条件といったものを挙げています.そのまま引用すると

1. No leak
2. Meaningful Validation and Public LB
3. Fun

とあります. これをかなりざっくり言い換えると以下のような感じになるでしょう.(間違っていたらすみません!)

1. コンペで精度を上げることがしっかりと課題解決につながる
2. 運ゲーじゃない
3. やってて楽しい

自分も少しKaggleをやっていましたが,この小野寺さんのこの三つの条件には概ね同意します.今回のatma杯も殆どテーブルデータコンペだったため,この三つの条件に注意して準備をしていました.
もう少しこれらの条件について詳細に説明をしていきます.

1. No leak

機械学習におけるleakはよく初心者が踏み抜くあるある地雷として挙げられます.例えば訓練時に予測対象の目的変数と1対1で対応する特徴量を入れてしまって学習時に不当に高い精度が出てしまう,とか,本来訓練時には使えないはずの未来の情報を特徴量に入れてしまう,とかですね.
要するに「モデル作成時に本来は使用できるはずがない情報をモデルやデータに混入してしまう」ことなのですが,このようなケースがデータ分析コンペでも往々にして発生します.この記事におもしろ事例集がよくまとまっているのですが,つい最近でもKaggleのコンペでこのようなleakが発生しコンペがリローンチされたりされなかったりしています.(ここ最近のKaggleのleakについてはu++さんのこの記事がよくまとめています)

これが発生するとどうなるかというと要するに 主催者にとっては全く課題解決に貢献しないtrivialなモデルがwinner’s モデルになってしまう ということですね.しかし,このleakはある程度これらの問題について分かっているはずのKaggleでも最近も発生してしまっているように,注意していてもうっかり発生してしまうことがあります.これを防ぐためにも,コンペの準備の際は事前のモデル作成での検証やデータ準備段階での注意が求められるというわけです.

2. Meaningful Validation and Public LB

(伝説のMalwareコンペ △PubがPublic LBの順位から何位上がった/下がったか? という値)

分析コンペではTrainデータとTestデータが参加者に与えられ,更にTestデータがPublic Leader Board用(Public LB)/ Private Leader Board用(Private LB)に分割されるのが通常の形式です.コンペ参加者はTestデータについての予測値を提出するのですが,参加者は開催期間中はPublic LBでのスコアをフィードバックとして与えられ,Private LBでの順位で最終結果が決定されます.

これらのデータの分割の仕方はコンペにおいて非常に重要です. Train/Public/Privateでのデータの分割に問題があると,訓練時のローカルのCVスコアがPublicやPrivateでのスコアに全く反映されない,さらに酷い場合ではTrainとPublicでのデータの分布が類似しているのにも関わらずPrivateでは全くデータの分布が違い,PublicでのスコアがPrivateでの最終結果と全く相関しないなどの事態が起きたりします.

競技性の担保という意味でも問題になり得るのですが,真に大切なのは このデータ分割の元で予測精度を上げることが本当に主催が解決したい課題解決に貢献するのか? という本質的な側面を考慮したコンペ設計がされているのか? という点だと思います.要するにデータの抽出や分割の設定がそもそもおかしい場合は機械学習モデルを作成したとしても実践的に有効なモデルを作ることは難しいということですね.

完全な運ゲーにならないように,実際の準備ではPublicとPrivateでの相関が取れるように種々の検証を行っていましたが,今回はデータの特性もありなかなか難しいポイントだったと思います.

3. Fun

小野寺さんが動画内で「お気持ち指標」という表現を使っていますが,確かに好みが分かれる要件だとは思っています.上記のleakについてもleakが発生してただのパズルゲーと化しても面白く感じる人はいると思いますし…
なので今回は以下の2点について気をつけていました.

a. 課題としての面白さ
b. データとしての面白さ

この2点は完全に独立したものではありませんが,aの方はお題そのものが特徴的で普段からやるような課題ではないか? bの方はanonymizeしすぎて何のデータか意味がわからないといったことになっていないかとか,データそのものが触る機会の少ない珍しいものか? といった点について注意していました.

オンサイトコンペの開催における上記条件の優先度

前項で挙げた3つの条件ですが,全てを完全に達成するのはなかなか難しいことです.上記の条件の達成可否は課題設定やデータセットの準備の段階から殆ど決まってしまうものだと思っていますが,私は準備にあたっては達成できなかったらヤバい度合いや達成難易度を考慮して,1 >>>>>>3 > 2の順で優先度を決めて準備にあたっていました.

1については発生したらそもそも炎上してatma様やCAの評判を著しく傷つけることになるので絶対に起こしてはいけないというプレッシャーがあったため,atma様の方と共同して念入りに検証を行いました.

したがってあとは2と3の問題になります.本来は2と3はトレードオフの関係ではないのですが,最終的に今回のatma杯で使用したデータでは2が達成されづらいデータかつ,3については主催者的に自信が持てるデータ/タスクであるという認識があり,データや課題の設定をし直すか,あるいはそのまま推し進めるかという2択に迫られた訳です.

そこで,2についてはそもそも参加者のアプローチによって発生してしまうこともあれば,レベルの高さ故に上位で僅差になると更にコントロールできない要因なので完全に達成するのは困難だという点で諦め,3の方を優先することになりました. 3もそれはそれで完全に達成するのは困難なのですが,主催として「これはやって面白い」と参加者に自信を持って言えるコンペを提供することが最終的にコンペとしての質を高めることに繋がるというなんとなくの感覚があったからかもしれません.(Kaggleの過去の経験からかもしれません,plasticcとかmoleculeとか,主催が課題に対して真摯だったコンペは往々にして面白かったような記憶があります. 生存バイアスが大きい気もしますが…)

課題と反省

結果上記の3条件が達成されたかなのですが,どれも完全に達成されたわけでもないし,かといって全部ダメだったわけでもないといった感じでした.
良かった点としては

1. 致命的なleakがなかった
2. アンケートで多くの方から課題やタスクが面白いと言って頂いた

という点です.特に2についてはこちらも一番推したかった部分だったので非常に安心しました.

逆に反省点としては
1. 思ったよりShakeが発生してしまった
2. 課題やデータについて意義や意味が不明瞭という感想を頂いた

という2点です.

1については事前にatma様のDSの方に開催直前まで運ゲーにならないようにデータ分割を試行錯誤して頂いたのですが,思ったより起きてしまったのというのが感想です.それだけ上位がかなりの僅差だったのもありますが,個人的には踏んではいけない地雷がありそれを踏んだ人が落ちてしまったのか,あるいは単に運ゲーだったのかという部分が一番気になるというか心残りな点です.

2については特に反省している点で,主催の側で「データについてどこまで明確に話していいか?」という部分が不明確にしたままコンペ開催となってしまい,課題やデータとしての面白さを削いでしまった部分があったと思っています.これについては想定が甘かったため,次回以降は特に注意しないといけないと思っています.

最後に

コンペ主催者としての反省などを書いてきましたが,今後採用などの目的でオンサイトデータ分析コンペを主催する企業などは更に増えてくると思います.そのような流れの中で,例えばleakが発生してしまったりとか完全な運ゲーと化してしまったりなどのオンサイトコンペが開催されることもあるかもしれません.

Kaggleで悪い設計のコンペに1 ~ 2ヶ月ほどコミットしてしまった方がもうKaggleはいいや,と思われてしまうケースを私も見たことがありますが,たかだか1日のオンサイトコンペでも貴重な休日を1日捧げるわけで,そのようなオンサイトコンペは参加してデータ分析コンペそのものへの失望や嫌悪を抱くには十分な出来事です.

今後データ分析コンペを主催したいと考えている方々にこの記事がポジティブに役に立つことがあれば,またデータ分析界隈がコンペというものを通じて更に盛り上がっていけば嬉しく思います.