まずはざっくり箇条書き。もっと説明すべきところは、そのうち別の記事にするかも。
あと本記事内容は、ある分野での機械学習案件における知見であって、そこまで汎用的なものではないかもしれない。
全体的な雰囲気
機械学習技術が必要になる仕事は全体の2割程度。よって、機械学習技術に精通していなくても活躍できる場面は多い。 むしろ、AutoMLや機械学習部分を自動化するようなフレームワークやツールが増えてきており、その他8割の方が今後は重要になるとも言える。 もちろん、その他作業を効率良く進めるためには、詳しいメンバーがいるに越したことはない。
だいたいの流れ
- 解こうとしている課題の理解
- 本当に機械学習必要としているのかも早めに議論が必要
- データの理解
- 可視化とか色々して仮説を立てる準備を整える
- この時点でゴミデータの存在には気づいておくことが大事
- 仮説の検討
- 人がちょっと考えて解ける問題は、入出力前提が同じであれば、(たぶん)機械学習で解ける
- 例)加速度センサーのデータを見て、走っているか歩いているかを判定する
- データが十分にあればDeep Learningを試しても良いだろう
- データが少なかったり、なんとなくルールが見えているような場合は、適切な特徴量エンジニアリングと判別器で解けるだろう
- 仮説検討時の思考過程を参考にすること
- 人が考えてもなんだか分からない場合
- 例)加速度センサーのデータを見て、病気かどうか判定する
- 他のデータを使えるか相談したり、そもそも病気ではないものを判定するタスクに置き換えられないか検討するといいかも
- 機械学習精度どうこうの前に、そもそも実現性の検証が必要となり、だいたいコスパ悪い
- 一方で実現できたときは、優位性が認められることになるので、挑戦することは否定しない(置かれている状況次第)
- 人がちょっと考えて解ける問題は、入出力前提が同じであれば、(たぶん)機械学習で解ける
- データセットの準備
- 学習用、検証用、評価用
- 検証用、評価用データの抽出には時間をかけて良い
- データ不足や偏り
- モデル選択・パラメータチューニング用に評価用データを使うことがないように十分注意すること
- 検証用で色々最適化した結果、評価用でも良い結果。というのが期待される進捗
- 解こうとしているタスクに対して適切かどうか、見極めがとても大事
- 適当に進めて間違っていた場合、このあとのプロセスが全て台無しになるだろう
- 適当に選んでいわゆるleakageがあったりすると悲惨
- モデル選択・パラメータチューニング用に評価用データを使うことがないように十分注意すること
- 学習用、検証用、評価用
- 評価尺度の定義
- ビジネス課題との整合性確認
- 単なるF値やAUCを追い求めたら良いのか?あるいは、Precisionを重視してほしいのか等
- 評価系の構築
- 適切なデータセットと評価尺度が用意できれば、ほぼ終わったも同然(?)
- このあとはここまで色々頑張ってきた準備に対する、収穫の時期となるだろう
- 変な話、機械学習技術について精通した人が、機械学習未満のここまでをちゃんと設計出来ていると良いかも
- 特徴抽出の検討
- あとで色々組み合わせたり、除外したくなるので、特徴量毎に個別CSV化しておくなどしておくと良い
- 機械学習技術の検討
- ルールベースやロジスティック回帰などシンプルな手法で早めにベースラインを用意
- 楽しい ٩( ‘ω’ )و ♬*
- 検討した手法の評価
- 並列化とか早めにして、試行錯誤をすばやくする仕組みが大事
- 評価結果の課題分析
- underfitting
- 表現能力を上げる。Deep Learningだったら層や素子数、その他だったら特徴量増やしたり
- overfitting
- 正則化とかデータ増やしたりとか
- 具体的にうまくいかないデータを見たり、クラスタリング・可視化してみたりして、仮説を立てることはここでも大事
- underfitting
- システム統合
- 精度を犠牲にしてでも、処理速度を上げたりしないといけないかも…
- 統合後の逐次評価
- 未知データの出現や分布、特徴の傾向が変化するかもしれないので継続的な改善は必要
各プロセスで、なにか壁にぶつかったら、必要なところまで戻り、を繰り返すのが機械学習リサーチエンジニアの主な仕事(たぶん)。
進捗が芳しくない状況でありそうなケース
- パラメータチューニングばかりやってる
- データクレンジングしてない
- 課題を適切に分割してない
- 解こうとしている問題のコスパが悪い
- 仮説もってない
- トレードオフを行ったり来たりしてる
- etc
一時的なサポートメンバーに仕事を任せるために考えること
いま一番頭を悩ましている部分…
- 評価系まではきちんと作り込んでおく
- 自走出来なそうなら、試行錯誤するための手順をある程度つけておく
- 任せられるタスク範囲が絞られるのでトレードオフ
- 手順化したようなところは自動化出来てしまったりするので悩ましかったりもする
進捗ミーティングとかで共有すべき内容
やったことではなく、出来たことの説明を優先すべき
- 今回解決しようとした課題
- 今回の課題が全体に占める割合
- 解決方法
- 結果
- 検討開始からの評価結果推移
- 課題解決を確認できそうな代表的なグラフ
- 残課題
場合によっては活きてくるアドバンスドな(?)手法
まずはトイタスクを用意して、原理検証することが大事
- 特権付き機械学習
- ロバスト最適化
- Semi-superised学習
- Positive-unlabeled学習
- 共変量シフト適応
一般的なシステム開発プロジェクトと比べたときの難しさ(外部説明用)
https://medium.com/@l2k/why-are-machine-learning-projects-so-hard-to-manage-8e9b9cf49641
- 事前に難易度の見通しが付きづらい
- その課題で90%の意味するところは?そもそも実現可能?70%でも十分では?
- 想定外に失敗することがある
- 突如としてデータの傾向が変わるなど(金融データとか)
- 十分なデータが必要
- 多ければ良いというわけではなく、適切なデータを集めなくてはならない
- etc.