見出し画像
Photo by yellowseppi

機械学習で研究開発する初学者向けガイド

A. Hashi

まえがき．誰に向けたメッセージか．

この記事は，初めて機械学習を活用した研究や開発(以下，プロジェクトと呼ぶ）に挑戦する人や，一度やってみたけど苦労が多くて大変だったと感じている人に向けています．あくまで個人の経験による記事なのですが，他の方にも共感してもらえる部分は多いかなと思います．機械学習技術は深層学習が発明されて以降，職人芸の世界に片足を突っ込んでいます．やってみないとわからないこと，つまり，試行錯誤が必要な部分がどうしてもあります．この試行錯誤を多く回すためには，試行錯誤1回あたりのコストを下げること，つまり，楽をすることです．大抵の人はレベルの高い研究をしたいし，楽もしたいはずです．幸い，楽をすることで試行錯誤が容易になれば研究のレベルは高くなります．この記事は「楽をする」ために必要な苦労を最小化するためのノウハウを，そのインセンティブと共に紹介していくガイダンス的な記事です．
（ちなみに誰が書いた記事かというと，私のCVはこちらです）
あと，日本人は一分で600文字読めるらしく，この記事は多分読むのに14分くらいかかります．長くてすみません…

機械学習プロジェクトのライフサイクル

機械学習(Machine Learning, 以下ML）のプロジェクトを実行するのは初めてという人は，まずプロジェクトがどんな形で進むのかイメージを掴みましょう．以下が簡単にまとめたMLプロジェクトのライフサイクルです．

  1. データセットの選定（あるいは収集）

  2. ベースラインとなるモデルと目的関数のデザイン

  3. 目的関数に合わせてモデルを最適化する処理（学習）

  4. 最適化されたモデルの性能評価（テスト）

  5. 性能が十分でなければ1-4の何処かを見直した後，再度3,4を実行する（性能が十分になるまで繰り返す）

前の説で書いた「試行錯誤」は上記の1-4のループを繰り返す部分です．少ないループで良い結果にたどり着く能力がMLプロジェクトの遂行能力といって差し支えません．ぜひこの記事を読んで，上記の繰り返しコストを最小化しましょう！

ポルシェに載っているライバルを自転車で追い越そうとしない

上記の試行錯誤にかかる時間はまさしく研究の速度です．試行錯誤のための手作業を最小限に抑えるためにライバルはpytorch-lightningやwandb, hydraといったツールを駆使しています．これらのツールを使わずにライバルより早く，インパクトのある成果をだそうとすることはポルシェを運転している相手を自転車で追い抜こうとするようなものです．3,4年前と違い，ツールの淘汰も進み，Web上の良質な記事も充実していて，当面はこの3つを学べば大丈夫なのでは？という印象です．さらに言えば，これらのツールを駆使したテンプレートもgithubに転がっていたりします（こういうものを公開してくれる人には頭があがりません！）．無料でポルシェが落ちている，それがMLの世界(=OSSの世界)です．ツールを使わない場合，さんざん苦労してコーディングしていながら，楽をしているライバルより遅いのです．楽をして良い成果を出すというのとは正に真逆の状況です．楽をして試行錯誤の回数をあげるためにツールの習得(=免許取得)にコストを払いましょう．また，できれば社内ツールや研究室内ツールではなく，どんな環境にいても通用する普遍的なツールを習得することに時間を払いましょう．それはツールの質だけでなく，後で書くようなインセンティブの問題もあるからです．

ちなみに，念の為ですがもっと基本的な話もしておきます．たまによく時々頻繁にですが，shellscriptを使わずに実験を手動で走らせている学生がいます．これではたくさん実験を回すために24時間労働が強いられてしまいます．深夜にGPUを回すのに徹夜をする必要はありません．働くのはコンピュータに任せましょう．具体的にはシェルスクリプトが便利です．`exp.sh`という名前のファイルに動かす予定のコマンドを1行ずつ記入し，下記のコマンドで順番に実行しましょう．あなたは徹夜をする必要は全くありません．

% bash ./exp.sh

インセンティブ：もしあなたが大学の研究室にいる学生なら，研究のテーマ自体は就職後に役に立たないかもしれません．しかし，これらツールの使用経験は確実に求職時に役に立つと思います．できれば，研究の前段階などで作る公開可能なデータセットでの実験用コードを自分のレポジトリで公開しましょう．例えば就活においてあなたが「このツールを使ったコードをこのurlで公開しています」と実績を見せるのと「できま〜す」と宣言するだけなのとでは説得力に象とミジンコほどの差があります．学習の成果として実績を公開しましょう．

スタート地点をゴールの近くに置き，ゴールの方に進む．

研究のゴールに楽に到達するためには，スタート地点ができるだけ前にある方が望ましいです．このために大事なのは「強いベースライン」を作ることです．ベースラインは後で打ち負かさないといけないので弱い方が良いのでは？と思うかもしれません．しかし，弱いベースラインを打ち負かしても「この方法も検証しないとだめなのでは？」という反論に答えることができません．新規技術の価値を示すには，このような検証に耐える高い信頼性が求められます．研究の具体的なゴールとは「この技術は役に立つ」ということを「検証する」ことです．後で検証して成果が覆されると手戻りが発生してしまい，かけた時間が無駄になります．怖がらず，面倒臭がらず，今ある技術で最良のベースラインを作ることでスタートラインをできるだけゴールの近くに置きましょう．
ちなみに，誤解を恐れずにいうと，最良のベースラインは幸いなことにgithubに落ちています．最良のベースラインは「高性能がでる」だけでなく「信頼性がある」ことが大事です．言い方を変えれば「俺が考えた最強のベースライン」はベースラインとしては信頼性の観点で弱いのです．githubに落ちている信頼できるコードをできるだけ改変せずに用いることが最良のベースラインの作り方です（なんて都合が良いのでしょうか…）．「信頼できるコード」の見極めは非常に難しいのですが，大学での研究の場合はたいていは論文を伴う従来手法，特にSoTAとよばれる手法や業界標準になっているstandardな手法のどちらかです．最良のベースラインを作るためにはサーベイをしてコードが公開されていて誰もが納得するTop Conf.の最新手法を見つけたり，みんなが基準にしているstandard手法を見つけましょう．ここをサボるとゴールから遠く離れた場所をスタート地点にしてしまうことになります．

もう一つ注意をするなら，自分のゴールとみんなのゴールが同じかどうかを見極めることが大事です．実はサーベイで得た論文たちと自分がやりたいことがズレていると「検証の内容があさっての方向になってしまって実はゴールに向かっていない，なんてことが起きてしまいます．一方で自分のゴールは他とは違うと思っていても，実は突き詰めれば同じだったということもあります．ゴールがどこにあるかを指導教員や共同研究者と確認することに時間を費やして，スタートからできるだけまっすぐにゴールへ進みましょう．

インセンティブ：最良のベースラインを作る経験は研究ではなく開発をする立場になった場合にはさらに役に立ちます．なぜなら，普通の開発は新しい研究要素(=不確定要素)をできるだけ排除して確実に製品を開発することが目標となるからです．研究におけるスタート(強いベースライン)は開発におけるゴールと一致します．将来研究者になっても，技術者になっても，強いベースラインを作るノウハウは役に立ちます．

データセットを工夫し，単純かつ小規模な問題で試行錯誤する

試行錯誤のコストを減らすために最も重要なのは実はデータセットの準備です．これには2つのポイントがあります．

  1. 正解データがない状況でなにか研究をする場合，手法を駆使するより正解を準備してしまった方が早い場合がある．

  2. データセットが大きい場合は，実験を小さく回せるようにデータセットを切り出す

1.に関して，機械学習において，正解データが十分でない場合(教師なし)でもうまく学習する方法は重要な課題です．しかし，今のMLプロジェクトにおいて，その課題が本質的に解くべきものなのかは十分に考えてください．MLプロジェクトのゴールが教師なし学習手法の改善でない場合，正解データを手動で頑張って与えてしまうことは最も単純で，かつ，もっともパワフルな解決方法です．たいていの場合，情報学を志す人は手動が面倒なので自動化をすることを好みます．しかし，最初に手動でデータセットを作るという矛盾した努力が求められます．嬉しいことに作成した正解データは（正解の定義変更さえなければ）試行錯誤なしに確実にプロジェクトをゴールに近づけます．正解データを作成すること自体も研究の貢献になる可能性が高いです．

2.に関して，学習に何日もかかる実験を10回も回すと1ヶ月が経過してしまいます．ハイパーパラメタの調整が最終段階になるまでは，学習に係る時間は長くても1時間程度に抑えましょう．このためには学習データをある程度間引きする方法が一番単純です．学習データが減ると精度は下がるかもしれませんが，手法の性能改善の有無といった傾向を把握する上では十分な場合が多いです．場合によっては，本当に解きたいデータセットの代わりに，トイデータ（実用性はないが検証のために用意された小規模で単純なデータ）を用意することも有効です．

インセンティブ：特に学習に係るコストを抑えることはクラウド上でGPUサーバを回す費用やオンプレミスのGPUサーバの電気代を抑えることに繋がります．デメリットはほとんどないはずです．面倒でも小さなデータセットで検証を重ねることが成果をだす近道です．いきなり大規模データでSoTAを出そうとはしないようにしましょう．

コミュニケーションツールを使い分ける

ミーティングは多忙な指導教員と一緒に問題解決にあたるための貴重な機会です．色々が学生を見ていると，ミーティングをするたびに研究が進むタイプと，ミーティングをいくらやっても研究が進まないタイプの2通りがあるような印象があります．時間的に同期したコミュニケーションができるミーティングはお互いの誤解を解き，共通理解を構築することに優れています．研究が進むタイプの人はミーティングをプロジェクトのゴールや，そのゴールに向かうための小ゴールを設定する場に使っています．（小ゴールは，例えば性能がでない原因の仮説を立て，それを検証するためのTo Doリストなどがそれに当たります）．以前に設定した小ゴールに基づいて検証した内容を報告し，次の方針を議論してゴールがどの方向にあるかを細かく確認することで，参加者の経験を総動員してゴールに最短経路で向かうようにします．
一方，研究が進まないタイプの人はミーティングをデバグの場として使っています．初学者にとってはデバグが研究にかける時間のほとんどを占めていることでしょう．だからこそ，週一回のミーティングでデバグの相談をするのは非効率です(月4回，年48回しかチャンスがありません！）．バグで困っていたらミーティングを待たずにチャットツールで悩みメンバーと共有しましょう．チャットによるコミュニケーションはコードの共有などがしやすく，相談される側からしても非同期にたっぷりグーグルなどで原因の可能性を探ってから返信ができるのでデバッグに向いています．コードをgithubなどのリポジトリにpushした上で，該当箇所の行へのリンクを添えて相談しましょう．明らかにミーティングで口頭で相談するより正確に問題を共有できます．同じ問題が発生する最小のコードも作れるなら作りましょう．これを作ると，研究室内での相談だけでなく，Web上のオープンなコミュニティでも質問ができるようになり，解決の可能性がぐっと高くなります．それでもどうしても一人で解決できない場合もあるでしょう．その場合は指導教員や研究室の先輩に1回2時間程度のまとまったペアプログラミングの時間を作ってもらいましょう．デバグは初学者にとって最重要課題です．だからこそ，週一回のミーティングを待つのはナンセンスです．月4回のやりとりでバグが取れるなら誰も苦労しません．質問を投げた後で自己解決しても問題ありません．ガンガン悩みをチャットで共有しましょう！

インセンティブ：ミーティングでデバグが始まるとたいていの場合，参加者のほとんどは何もすることがなくなってしまいます．これに巻き込まれた人のあなたに対する印象が下がる危険があります．これにより徐々に精神的安全性が損なわれ，研究が辛く，苦しいものに変わってしまうかもしれません．
一方でバグでの悩みをチャットで共有する場合，研究室の文化にもよりますが，わかる人が率先して答えてくれる可能性があり，少なくともあなたが困っているということはミーティングで相談するのと同じくらい十分に周囲に伝わります．しかも，チャットでの質問はあなたが熱心な学生(orエンジニア)であるような印象も与えます．同じことをしているのに真逆の印象になるなら絶対にチャットの方が良いでしょう．

今いる環境では問題解決能力が十分ではない場合の解決策

様々な理由で，上記のテクニックが通じない場合も存在します．研究室の文化が破綻して学生同士の互助がない場合や，指導教員が忙しすぎて最近の技術に十分に明るくない場合，定年間際で教員のモチベーションが低い場合など，理由は様々です．残念ながら，学生にはそういう研究室を避けるくらいしかできません．既にそういった研究室に配属されている場合でも，できるだけ早く別の研究室に移る方法がないか考えましょう．修士や博士進学に研究室を変えるのは勇気が要ることですが，大抵の教員はやる気にあふれた学生を応援しています（そうでない教員は今いる環境と類似の問題を抱えている可能性が高いので無視しましょう）．大学の先生はどうせ中国やインドから研究室進学の相談メールは大量に受け取っています．その研究室への見学やzoomで質問の場を設ける申し込みなどをしてみましょう．各大学のオープンキャンパスも狙い目です．
別の方法として企業でのインターンで実力を高める方法もあります．PFNやSony，Yahooを初めとして国内にも色々なインターンプログラムがあります．手前味噌ですが，私が所属するオムロンサイニックエックスでも通年でインターンは募集しています．近年はいわゆるAcadexitした元教員がいる研究所や，それと同レベルの企業研究者を多数そなえた環境も多いです．
画像処理分野ならMIRUメンターシッププログラムなどの取り組みもあります（他学会でも類似の取り組みもあるかもしれません）．さらに，本当に学生に無関心な放置系研究室なら，もしかすると修士や博士で別の研究室に進学することが決まった段階で，その進学先の先生とで卒論や修論を進めることを認めてくれる場合もあるかもしれません（そういう学生を指導したことがあります）．あらゆる方法で外部の指導者を探す努力をしましょう．研究室の文化を変えるのは一人の学生が行うにはあまりにも重たい課題です．一人で今いる環境を改革するより，自分がいる場所を変える方が簡単で確実です．やる気のある学生に限りますが，味方は多いです．一刻も早く環境を変えましょう！

インセンティブ：あなたのエンジニア修行のための貴重な1年(人生の1/80)と学費の価値を最大限高めることができます！

業績を積むことを目標にせず，善良で勤勉であることを目標にする．

近年のAI研究の加熱は，最難関国際会議にAcceptされた経験がないと人権がない，と錯覚させる程の雰囲気を醸し出しています．しかし，採択率が20%〜30%の会議で論文が不採録になることは普通です．不採録になったときに必要以上にショックを受けない精神状態で次に向かって頑張るためにはどうしたら良いでしょうか？

まず，最難関国際会議にAcceptされなくても，あなたのことを見てくれている人はいるはずです．どうしても他者からの評価が気になるなら，身近な人のうち，誰か一人の評価を勝ち取ることを目標にしましょう．ちなみに，あなたのことを評価し，採用してくれる人は人生で何人必要でしょうか？あなたが「誰もがすごいと思うような研究者」になりたいのであれば採択論文は山程必要かもしれません．しかし，そこまで思っていないのであれば，自分の生活を保証してくれるような立場の人の中から，誰か一人だけでも評価してくれる人がいれば良いはずです．そう考えれば，身近な人の評価を勝ち取るくらいのハードルがぴったりではないでしょうか？経験上，誰か一人が評価してくれるなら，N人が評価してくれると思います． 対外発表などを通じて，意外な人が見てくれている場合もあります．自分も一回しか発表を聞いていないけれど印象に残っている学生はたくさんいます．論文採択に関わらず，善良で勤勉なエンジニア・リサーチャでいることを心がけましょう．それが他者の信頼を勝ち取る重要な要素です．もしかしたら信頼を勝ち取ることも運かもしれません．査読と違ってN人いて1人の信頼を勝ち取ればよいのであれば，だいぶ分の良い勝負ではないでしょうか？

もっと極論をいえば，他者からの評価というのは本来は給料を受け取るためだけに必要で，MLが楽しいとかそういう動機とは独立しているはずです．このように「MLが楽しいと感じる」といったものは「内発的動機」といいます（他者評価などは「外部動機」）．内発的動機を感じられるような環境に身を置くことは大事です．内発的動機の典型的な例は，自分自身の成長を感じられるということです．この記事で紹介したような高いMLプロジェクト遂行能力を身につけることは成長という内発的動機に繋がります．よくわからない人も騙されたと思ってスキルアップを経験し，その楽しみを覚えましょう．

あとがき．なぜこの記事を書いたのか

出会いに恵まれ，機械学習分野（主に画像処理を中心とした研究者コミュニティ）で大学教員を務める多くの知り合いがおり，自分も教員だったので昨今の大学において教員が研究や教育にさける時間が如何に少ないかをよく知っています．しかも，幸いにして自分は研究型インターンシップのメンターとして機械学習の研究分野の中では多様な学生と触れ合うことができるポジションにいるため，転職してからの4年間で，ものすごく成果を出せる学生と，まだまだ学ぶべきことが多い学生の両方をインターンの指導的立場から近くで接する経験を得ました．特に多様な大学の学生とこのような研究活動をする経験は，特定の大学の学生だけしかみない大学教員では得難い経験であると思い，このような記事を書ける人が少なそうだなと感じたのが執筆の動機です．知人は国内の大学の偏差値なんて誤差，といっていたことがあります．卒業してから5年後であれば，これは正しいでしょう．しかし，今正にその大学にいる人にとっては，身近なライバルや指導教員など色々な点で差があるように思います．この記事が所属大学（あるいは所属企業）などの環境に依らず，多くの人にとって実りのあるものとなり，国内の研究レベルが高くなるようなら幸いです（そして巡り巡ってインターンに来る学生のレベルもあがったら望外の喜びです）．

ダメ押しの駄文…

格好つけましたが，正直にいえば，一番の動機は飛行機の乗り換えに失敗してイスタンブールの市街地から1時間半離れたホテルで缶詰になってしまったことかもしれません．

構想はあったのですが，書く暇がなかった．というわけで，この記事の先頭にある写真は誰かがとったイスタンブールの写真です．トルコ航空の新しい空港はトランジットのセキュリティチェックの列がカオスなので，見えない前方で横入りされてたり色々なことが起きて大変です．タッチの差でgate closedになり，明日乗れると言われたのに結局乗れず，缶詰二日目を過ごしています．自分がorganizerのworkshopはリモート参加になってしまいました．早くACM Multimedia 2022 @ Lisbonに参加したい…

2022.10.10

この記事が気に入ったらサポートをしてみませんか？