連載第3回となる今回は、前々回、前回とは少し話題が変わって機械学習エンジニアや研究者の間で話題のKaggleのお話しからはじまります。そこから機械学習ライブラリとの付き合い方、そしてお二人が機械学習エンジニアとして経験を積んで気づいてしまった事実へ…
Kaggleは機械学習のF1レース！？
本橋： Kaggleみたいなものはどう思いますか？
有賀： 全然やってなくて、1度も真面目にSubmitまで到達したことのない雑魚です。でもKaggleのTalkingDataは面白そうだと思ってやってみたことがあって。 [1] それまではKaggleって与えられた問題を、誰が一番うまく解けるかの選手権だと思っていたんですけど、あれはそうじゃなくて、なんていうんですかね。
すごいできる人達が世界中から集まってきて「俺、こんな風に解いたぜ」「俺はこんな風に解いたぜ」って、カーネルなんかも公開するじゃないですか。最初の探索的データ分析（EDA）をやってみたときに、こういうデータの傾向で、散布図を書くとこうなって、こういう傾向があって、という例を見るだけで飯が何杯も食えるなとｗ 凄い面白いですよね。
本橋： 凄いコミュニティですよね。僕はそんなにKaggle強いわけではないんです。KDD Cupはちょっと頑張って、一応個人でトップ10くらいまでは行きました。 [2] そのあとチームマージしたんですけれど、一応僕も貢献したぞと。ただ、あれはチームでやると個人の貢献が見えなくなるんですよ。その後、Kaggleのコンペをちゃんとやれていないんで、偉そうなことは言えないんですけど。
「Kaggleが役に立つ、役に立たない」とネットの中で話題になったのですが、僕はKaggleと現場のモデリングって、F1と乗用車の世界だと思っていて、F1ってある決まったコースの中で極限までチューニングして競うみたいな世界じゃないですか。なのでF1の技術がそのまま全部、乗用車の世界に来るわけじゃないですけど、やっぱり一部の技術はやって来るんですよね。そこが似ていると思うんです。
例えばXGBoost [3] なんかはコンペから生まれたもので、あれ、良く公開してくれたなと思います。
有賀： 新しいライブラリなり手法をライブラリとして実験する場所を作って、それがKaggleの中で実証されて広まって、というサイクルが回っていて。
有賀： 競技プログラミングをやったことがないので、まちがってたら指摘して欲しいのですが、僕の競技プログラミングのイメージって、個人が自分の実力を全力で出していくみたいな個人プレーみたいなところがあります。それに対して、Kaggleは新しいカーネルを見たらみんなどんどんフォークしていって、更に何かを加えるという感じで、ある意味遺伝的アルゴリズムというか…
本橋： 淘汰されていって…
有賀： そうそう。そういうのを繰り返していって、最後ラストスパートでって感じのところがあるじゃないですか。あれすごい面白いなと思っていて。
本橋： そうですね。僕がKDDCupとかやっていたとき、実はモデルのスタッキング [4] がきちんとわかっていなくて、ほとんど特徴量エンジニアリングで戦ってたんですよ。
スタッキングもどきのようなものはちょっと使っていたのですけれど、スタッキングについては全然知らないで。でも、1位になったチームは、スタッキングを使ってキレイに勝っていて。おお、これは全然レベル違うなって思いました。でもそういう手法の違うチームがぶつかることで、学びがあると思うんですよね。僕はそこでスタッキングを知ったのですけれど、当時はまだそんなに知られていなかったと思います。今はもう、みんな知っている、この広まり方がやっぱりいいなと思います。
有賀： 少し前にメルカリのコンペの解法を見たときに、YouTubeで解説してくださった方がいて…
本橋： tkm2261さんですかね？ [5]
有賀： 彼の動画を見て「なるほど」と思いました。テキストの問題で、与えられた環境の制約が強すぎてトークナイザーが使えないから、2-gramか何かでニューラルネットワークに突っこんだら性能が良かったみたいな話があって「マジか…」っていうｗ
本橋： すごいですよね。
有賀： そう。なんかすごく新しい手法が出てきて、確かにそれはある制約の中で上手くいくっていうのはあり得る。「なるほど」と。
本橋： あれ、なかなか仕事の中でチャレンジできないですよね。
有賀： できない、できない。そういう意味ではWebの開発とも似たようなところがあって。Webの開発では趣味でいろいろライブラリを検証して、ある程度感覚をつかんでから仕事に入れるとかよくあるんですけど、そういう感覚がありますね。Kaggleで新しいことをやってみて…
本橋： まさにそんな感じですね。UXでライブラリを作るのなら自分でできるけれど機械学習はデータありきだから、そういう意味でもKaggleの場ってすごいなと思って。
有賀： そうそう。ある意味では問題定義をするという所は終わってるし、ベースのデータになるCSVを手に入れるところまで終わってるけど、その後のどういう風に考えてどうやるか。カーネルをどんどん読んでいくだけでも勉強になるところが、特に機械学習の分野へ新しく参加した人が勉強できるところが沢山あるなと思うので。
| [1] | https://www.kaggle.com/c/talkingdata-adtracking-fraud-detection |
| [2] | KDD CupはACMのSIGKDDによって開催されているコンペティション。本橋さんが入賞されたのは KDD cup 2015 https://biendata.com/competition/kddcup2015/ |
| [3] | XGBoost https://xgboost.ai/ |
| [4] | モデルの出力を特徴量として別のモデルに入力すること。最近では、スタッキングで差が出るコンペは問題設定が良くないとも言われている。詳細は以下を参照。 https://speakerdeck.com/smly/detafen-xi-kontesutofalseji-shu-tozui-jin-falsejin-zhan |
| [5] | http://yutori-datascience.hatenablog.com/entry/2018/03/05/214331 |
充実されたライブラリを理解して使うことの意味
有賀： 2008年に働き始めた頃は、ここまでライブラリが揃ってはいなかったけど、ここ5年から3年の間に急速に発達してきて。個人的にはscikit-learnの充実っぷりには目からウロコで…
本橋： すごいですよね。
有賀： 昔、R系のデータサイエンスの本を読んだときに「Rだとこんな感じで色んなアルゴリズムを比較できるんだ、すごいな」と思ったことがあって。当時はLIBSVM [6] を使ってたので、「マジか…すげえ…楽だな…複数のアルゴリズム比較して、検証するのこんなに楽ならそりゃR使うよな」と。でも「これAPIライブラリごとに全然違うじゃん」って気づいて。そうしたらscikit-learnがAPIを全部fitとtransformとpredictで行けるようになってて、「なんやこれ…誰でもできるようになってるやん」ってｗ
本橋： 僕は最初、機械学習のことはよく分からないけど、AIに興味があってテレビゲーム好きだったので、マリオのAIとか作ってたんです。 [7] ただライブラリの存在を知らなかったので凄く苦労して。その時はJavaのエミュレータをベースに作ったのですが、Javaで機械学習ライブラリって今はあるんですかね？よく分からないんですけど。
有賀： 昔だとWeka [8] とかかなあ。
本橋： あったんですね。当時は知らなかったので、ファミコンのメモリを入力に、決定木でマリオが動作するようなものを作ってたんです。Javaで決定木アルゴリズムをイチから書いてたんですけれど、スクラッチで雑に書くとパフォーマンスはひどいし、バグもあって大変でした。その後、機械学習ライブラリの存在を知って、「なにこれ？こんなにすごい楽なの」みたいなｗ 昔からやってる人たちってみんなスクラッチで書いていたんですよね？
有賀： そうですね。昔はスクラッチでC/C++を書いてました。
本橋： メモリも全然ない時代ですよね。
有賀： そうですね。もしくは公開されているC++のライブラリを使って、RubyとかPythonのバインディングがあれば使うし、そうじゃなければ、典型的なのはLIBSVMのフォーマットにデータを変換するスクリプトをガーっと書いて。LIBSVMのフォーマットって確か、数字、コロン、バリューみたいなスパースマトリクスを自分でやりましたみたいな感じのもので。前段階でテキストの頻度カウントなんかをしたあとのデータを変換して出力して、あとはそれをLIBSVMに投げて学習するとか、そういう感じで昔はやっていました。古き…よくないですけれどｗ
本橋： そういう意味では、中身をよくわかってますよね。中身を本当にすべてわかる必要があるのかないのかは、また議論が分かれると思うんですけど
有賀： でもそこでいうと、最近オライリーから出てるscikit-learnとTensorFlowの本があって [9] 、元Googleの人が書いているんですけど、あれが非常に良いなと思ってて。例えば決定木は特徴量の値をスケーリングしなくてもいいですよとか、SVMはスケーリングしないと収束しづらくなっちゃう、みたいなことも具体的に整理して、このスケールだとこうだよというのも図解で書いて、そういう意味では決定版だと思っていて。
あの本はオライリーの皮を被った教科書だと思っていて、それこそSVMなんかも双対問題として解きますって話も書いてあって…
本橋： おおっｗ
有賀： 一番最初にエンジニアが読むのはつらいかもしれないんだけど。
本橋： 特性を理解するって意味ではいいですよね。
有賀： 「そうそうそう」っていう所をちゃんと抑えて書いてあって、確率的勾配降下法とか。いいのが「このAPIを叩くといいんですよ」という本はよくあるんですけど、その前にスクラッチっぽく書いていて、 train_test_split() なんかもスクラッチで書いていて「これを、実はscikit-learn使って、このメソッドを使うと一発です」と。
本橋： なるほど、なるほど。
有賀： よくできてて、教育的だなと。スケーリングの話も正規化、要するにstandard scalerみたいにゼロを中心にして分散1にするような話と、そうじゃない0と1の間で正規化する話もあって、こういう時にはこっちを使った方がいいよという話がスムーズに出てきてる。やっぱりその辺がわかったうえで使うのと、わからずになんとなく使うのでは違う。
まさにSVMなんてスケーリングしない値をそのまま突っ込むと、大きな値を持った要素に全部持っていかれて全然性能が出ないという話があるじゃないですか。Deep Learningはちょっと傾向が違うと思うんですけど、とはいえテキストをembeddingするっていう話も、なんでそんなことするのかみたいな話になったときに、そもそも普通にBag of wordsやるときも同じで。可変長の辞書ができてしまう、みたいな所をembeddingすることで固定長にして扱えるようにしてとか、そういう話の流れがわかると思うので。
「なぜこうなっているのか」がわかっている方がライブラリのありがたみもわかるし、もしそれではできなかったときにどういう回避策をとらなきゃいけないのか、どういう次の手を打たないといけないのか、って事を引き出しとして持っておけるんじゃないかと思います。
本橋： 自分でスクラッチで書けなくてもいいけど、なんとなく何が書いてあるかはわかっていたいですよね。このモデルは特徴がこうだから、この場合はこっちの対処法、みたいな。そういうフローチャートが頭の中で書けるといい、みたいな。
有賀： そうですね。
| [6] | https://www.csie.ntu.edu.tw/~cjlin/libsvm/ |
| [7] | https://www.youtube.com/watch?v=kcn07_e6Y4c&t=59s |
| [8] | https://www.cs.waikato.ac.nz/ml/weka/ |
| [9] | 『 scikit-learnとTensorFlowによる実践機械学習』オライリー・ジャパンより絶賛発売中です。 |
機械学習を突き詰めると業務改善を始めることに！？
本橋： 最近は機械学習もだんだん浸透してきて、現場にもわかってる人は増えているんですか？
有賀： どうですかね。聞いてる感じだと、アクティブに動いている人でも、例えばSI的に動いている人は、先ほどお話ししていたPoCだけで終わってしまうみたいなつらい苦しみがあるって聞きますし。詳しい人がいてもそれが100％うまく回っているかっていうと、そこはなかなか限られるのかなと思うし。
前に機械学習工学研究会 [10] ってところにお呼ばれした事があるのですが、他の登壇者とお話しする機会があって色々な話を聞いていると、受託で機械学習やるの大変だな、コンサルで入るの大変だなって思いました。お客さんは詳しくないのに要件がコロコロ変わっていくとかあるじゃないですか。
それをコントロールできないから、いい精度出ましたと言って。これアクセンチュアの工藤さんが話していたのが、そういう「このデータを試しにやってみてよ」とカラム名をマスキングされたデータを渡されて、それで製造業の故障を予測するというのをPoCでやりましたと。ところがそれがPoCで「なかなか良い精度になりました。頑張りました」と言って出したら「お、すごいね。でもこれ別に使えないんだよね」と言われて。
本橋： どういうことですか？
有賀： つまりPoCでやった問題が、別に売上の改善やシステムに貢献できるかといったら全然関係ない問題だったらしいんです。それで「え？」っと言っているうちにそのままそれは終わってしまったというような話を聞いて。PFNの丸山さんが「PoC貧乏」ってお話し [11] をされていたのですけれど…
本橋： ああ！そのスライド読みましたｗ
有賀： その話を聞いて、丸山さんのお話しを思い出して「あー、あー、あー」って。
僕が思うのは、機械学習をやるうえで一番幸せなのは機械学習を適用するプロセスを自分たちでグルグル回せる人達が、自分たちでやるのがいいんじゃないかと思っていて。自分たちなら要件、つまり何をすれば自分たちのお客さんにバリューを提供できるかってことを定義できるじゃないですか。自分でプロダクトを開発するエンジニアがKPIも自分で定義できるし、システムも自分達でできる。
それができる会社ってのは、まだ限られるのかなって思っていて。PFNさんのように共同研究という形でうまくやっている会社さんもあるし、メルカリさんなんかはMLOpsと言って頑張っていると聞きますけど、同じようにモデルをバンバン投入してメンテナンスしているって話はそれほど多くない。色々なところを見ると「これ機械学習でやれば行けるんじゃないの？」という所はいっぱいあると思うのですが。
一方で、会社ごとに見ると、それを解けば行けるという問題はそれほど多くはないと思っていて、1社につき5個とか10個とか。それで終わりいう感じになっちゃうと。
本橋： それでいうと、僕はベンダーに居たので、一番つらい思いがあったのは、ベンダーとしての売上最大化が、お客さんにとってのコスト最大化になってしますということでした。「僕なら1日でできます」というのが、「売上1人日かよ」みたいな話になっちゃうので。
その代わりにレベニューシェアにするという方法もありましたけど、その条件を決められるかといえば実際は難しいですよね。お客さんだって、そんなに儲かるんだったら自分たちで、という思いもあるでしょうし。なのでベンダー時代にやってみたかったんですけど、ほとんど実現できませんでしたね。
そもそも、本当に利益を出すためにはデータ分析の課題だけやってもダメで、もっと価値を出すためには、事業側に入って、ビジネスのやり方を変えないといけない。分析も、今のビジネスの形を変えない中でできることの範囲って限られているんですよね。
有賀： そこは僕も本当にそうだと思っていて、最近思うのは機械学習でいろいろやって改善できましたと。それで上手くいって、すごくサイクルも回っているお客さんとお話しをしていたときに「ここまでくると、ボトルネックは機械学習ではなくて業務フローを改善しなければいけないね」という事になって。僕もお客さんと話をしていると「業務コンサルに片足突っこんでるな」って思うことがあります。（共著の）ところてんは、そういう所も含めてやっていて。
「あれ、これ機械学習突き詰めていくと業務改善しないと無理なのでは？」って言ったら、友人たちから「それはSIの人たちはみんな知っている」って言われ、「ようこそこちらの世界へ」とｗ
本橋： 来ちゃいましたかｗ
有賀： システム全部で見れば機械学習はあくまでパーツなので、そのパーツでボトルネックが解消したとき、次のステップで何をするのかといえば、当然それ以外の場所も改善していきましょうというサイクルになるので。
本橋： 確かにそうですね。そう思うと、例えば僕は実態はしらないのですけど、例えばPFNさんを外から見ると、事業の会社と一緒になって自分達がリサーチを引き受ける、みたいな風に見えますね。同じようなDeep Learningをやってる会社のABEJAさんなんかだと、内部でも事業を持って、かつリサーチャーもいるみたいな感じに見える。どちらの場合も事業部門と研究部門が一緒に働く形で、研究部門を分けるよりいいんでしょうね。
有賀： 研究部門という感じで分かれちゃうと――僕も研究所に居たので分かるんですけど、事業部門の人たちが「恐れ多くも…」みたいな感じになって、凄い距離感ができちゃって。
本橋： そうそうそう。
有賀： 「いや、別にそういうの要らないんで」と。一緒にやっていきましょうというような事を言いつつも「恐れ多くも」というか「お前ら単価高いだろう」みたいなｗ のが伝わってきて。
本橋： 「単価高い」そうですよねｗ 僕はベンダの研究所だったんですけど、半分自分で稼がないといけない研究所で、研究費は半分しかなくて、半分は案件で稼がないと予算が足りないw 若者で経験もないのに、高い単価で自分を売らないといけないので結構ハードだったなあと。
有賀： 僕が居たようなメーカーの研究所みたいなところは、先の話、5年先とかそういうところを見据えるみたいな比較的タイムスケールが長いことをやっていて、一方で事業部は直近のことをやっていて、長期的な基礎となる研究はそれで大事だなとは思うんですけど、営利団体の研究所は傾向としてシーズベースになりがちで「この技術を使えるようにするための事業は何だろう？」というような考え方に陥りやすいと思います。
研究所内でブレストしてもそういう感じになることが多くて、構造として研究所と事業部門がキッチリ分かれていて、基本独立した形になっているとそういう風になりやすいんだろうなと思いました。そこをより実践的にする為だと思いますが、中堅になると事業部門への出向もありました。特に機械学習を使ったデータを活用する取り組みは、複数の部門や役割の人がどう協力するかや、組織構造 [12] も重要じゃないかと思います。
| [10] | https://sig-mlse.wixsite.com/kickoff |
| [11] | 丸山さんのお話は、発表者の控室で行われたそうです。それを受けて書かれたのが以下のスライドの30ページ。 https://www.slideshare.net/mobile/MLSE/ss-98345458 |
| [12] | 組織構造のお話しについては以下のスライドもご参照ください。 https://www.slideshare.net/TokorotenNakayama/kpi-ab-cwt2016 |
（次回につづく）
- 有賀康顕（ありがみちあき）
電機メーカーの研究所、レシピサービスの会社を経て現在はCloudera所属。フィールドデータサイエンティストとして、データ活用や機械学習の支援を行う。
オライリー・ジャパンより『 仕事ではじめる機械学習 』を発行（共著）。
- 本橋智光（もとはしともみつ）
SIerの研究員、Web系企業のデータサイエンティストを経て、現在はデジタル医療スタートアップのサスメド株式会社のCTO。株式会社ホクソエムにも所属。量子アニーリングコンピュータの検証に個人事業主として従事。製造業、小売業、金融業、運輸業、レジャー業、Webなど多様な業種なデータ分析を経験。
技術評論社より『 前処理大全 』を発行。
※このプロフィールは対談時のものです。