"Full Stack Deep Learning - Setting up Machine Learning Projects"のメモ

f:id:meow_memow:20200621121307p:plain

資料URL
- https://full-stack-deep-learning.aerobaticapp.com/e372_eb327323-811b-4de9-8894-76ec4cfd6458/assets/slides/fsdl_2_projects.pdf

What Does it Mean to Deploy a Machine Learning Model? (Deployment Series: Guide 01) - ML in Productionを読んでいたら途中で引用されていたスライド。興味があったので読んでみた。

スライドでは、機械学習プロジェクトのうち、プロジェクトの外観と、プロジェクト計画(目標設定、達成基準の決め方、ベンチマークの決め方)の説明をしている。

英語苦手なのでどのページにどういうこと書いてあったかインデックスがわりにメモっとく。理解できないところは先頭に?マークつけとく

講義の目的(p.2)

MLプロジェクトを理解するためのフレームワークを紹介する
ML prj.の企画と立ち上げのためのベストプラクティスを説明する

この講義で考えるケーススタディ(p.3)

grasp model(ロボットアームがものを掴むために)pose estimationをする
センサ情報からあるものがどこにあって、どの方角を向いているかを推定する

MLプロジェクトのフレームワーク(p.6)

ML prjのライフサイクル

f:id:meow_memow:20200621121601p:plain

①企画と立ち上げ
- 内容:
  - pose estimationすることを決める
  - そのための要件と目標を決める
  - リソースを割り当てる
②データ収集とラベリング
- 内容
  - 学習データを集める
  - センサ(カメラなど)のセットアップ
  - 画像をキャプチャ
  - ラベリングする
- ②をやってみて①へ戻ることも(p.10～11)
  - 要因
    - データ取得が難しい
    - ラベル付けが難しい
③ 学習とデバッグ(p.12)
- 内容
  - OpenCVをベースラインにする
  - 既存研究のSoTAモデルの再現
  - 自分の実装したモデルのデバッグ
  - タスクのための改善活動(モデルとかデータ集めとか)
- ③をやってみて②へ戻ることも(p.14～15)
  - 要因
    - データをさらに集める必要があった。
    - Realize data labeling is unreliable(データが信用できないことに気づく)。
- ③をやってみて①へ戻ることも(p.16～17)
  - 要因
    - タスクが難しいと気づく。
    - 要件同士のトレードオフがあった。(一番重要な手戻りの要因)
④デプロイとテスト(p.18)
- 内容
  - 開発(実験)環境でパイロット版を立ち上げてみて、システムがどう動くか把握する
  - 回帰テストを書く
  - 本番環境へデプロイ
- ④から③へ戻ることも(p.19)
  - 要因: 開発環境の段階で(期待した通りに)動かないので、精度改善を継続
- ④から②へ戻ることも(p.20)
  - 要因
    - 実験時のデータと、本番データに差異があった。
  - データをもっとあつめる。
  - Mine hard cases(多分、推論が難しいデータを探すこと。)
- ④から①へ戻ることも(p.21)
  - 要因
    - 設定したメトリクスは実際のユーザの行動に適ったものではなかった(The metric you picked doesn’t actually drive downstream user behavior. )ため、考え直す。
    - 本番環境でのモデルの性能が良くないので、要求を見直す。(例えば、より速さが必要だったり、より精度が必要だったり)

※↑は、個々のプロジェクトにおける進め方。プロジェクト横断するとなると、企画にはチーム編成や採用活動、それ以降ではインフラ構築やツールの開発を考える必要がある。(p.22～24)

他に知っておく必要のあること(p.25)
- 自分の取り組んでいるドメインにおけるSoTA技術を知ること: 何ができるのかを理解し、次に何を試すべきかを知る
①～④実際にはもっと詳細なステップがある(p.27)
- ①企画と立ち上げ
  1. プロジェクトのゴールを設定
  2. メトリクスの選択
  3. ベースラインはどれだけかを調べる
  4. set up codebase(リポジトリを作ること?)
- ②データ収集とラベリング
  1. データの収集戦略を考える
  2. データを集める
  3. ラベル付け
- ③学習とデバッグ
  1. 一番シンプルなモデルを選んで
  2. それを実装する→モデルをデバッグ
  3. train/val/testを実行
  4. 改善活動案の列挙と優先順位付け
- ④デプロイとテスト
  1. ステージング?本番環境の準備(pilot)
  2. 受け入れテスト
  3. 本番環境へモデルのデプロイ
  4. 監視
今回の講義では①に関して扱っていく。
1. プロジェクトの優先順位決め、目標の選定
2. メトリクスの選定
3. ベースラインの選定

1. プロジェクトの優先順位決め、目標の選定

優先順位決めに大事なポイント(p.31)

f:id:meow_memow:20200621122014p:plain

A インパクトの大きいMLの問題
- 低コストで予測できることが価値のある
- 複雑なパイプライン
B 実現可能性(Feasibility)
- ML pro.にかかるコストは、データがどれだけ使えるかによる。しかし、精度の要求も大きな要素である。

A. インパクトの大きいMLの問題

インパクトが大きくて、実現可能性があるところが、取り組む優先順位が高い場所である。(p.32)

影響の大きいMLプロジェクトのためのメンタルモデル(p.33,34 )

predictionを安価にすることがメリットがある場所はどこか
手作業でやっている複雑な作業のパイプラインのうち、どこが自動化できるか
The economics of AI
- AIは予測のコストを下げる
- 予測は意思決定の中心的存在
- 低コストで予測できることが意味するのは
  - どんな問題にでも予測が使える
  - それまでコストが高かった問題でさえも。（例えば、hiring a driver (?ドライバーを雇う？)）
- すなわち：予測コストを安価にできるとビジネスのインパクトがでかい場所を探そう
Karpathyのツイート(p.35)
- 「悪いね、勾配降下法は君よりいいコードを書くんだ。」
  - 訳注: 複雑なルールベースの推論ロジックを人がコーディングするよりも、MLモデルで推論をさせた方が結果がいい、みたいな意味だと思う。
ソフトウェア2.0(p. 36)
- ソフトウェア1.0は従来の、明示的にロジックをコーディングをしたプログラムのこと。
- ソフトウェア2.0は人間がある目標を定め、(学習)アルゴリズムがその目標を満たすプログラムを探す
- ソフトウェア2.0におけるプログラマは、データセットを用い、optimizerでコンパイルする(実行プログラムを作る)
- Why? Works better, more general, computational advantages(? なぜ2.0がいいか。それは、より良く動作し、より一般的で、計算的なアドバンテージがあるから)

まとめ: 複雑なルールベースのソフトウェアを探し、それをMLに置き換えよう。

B. 実現可能性(Feasibility)

機械学習プロジェクトの実現可能性をコストの面で見積もる(p.38〜44)

f:id:meow_memow:20200621121351p:plain

プロジェクトにかかるコスト要因は3層。
- 下がData availability
  - データ入手の困難さ
  - アノテーションコスト
  - どれだけデータが必要か
- 真ん中がAccuracy requirement:
  - 間違った推論をするとどれだけコストがかかるか。
  - (? 何回くらいシステムを正せば使い物になるか)
- 上がproblem difficulty
  - すでに類似の問題を解く良い方法が世に出回っているか(問題は新しいほど、リスクが高く、技術開発面で骨が折れる)
  - (? 学習は必要?)
  - (? デプロイできる?)

Accuracy requirement(p.44～p.46)

要求する精度を高くするほどプロジェクトのコストが高くなる。増え方は線形では済まない(super linear)
Product design can reduce need for accuracy(p.47)
- (正直、画像だけで何も書かれていないが、多分言いたいのは次のようなこと)
  - AIによる作業の完全な自動化(それ故の高い精度)を目指すのではなく、人に任せる部分も設けることで、精度の要件をへらすようにサービスをデザインする。
  - MLに何をどこまでさせるか(逆にどこからは人が)を設計すれば精度要件の負担を減らせるかを考えよう。
- Designing Collaborative AI - Ben Reinhardt - Medium -https://medium.com/@Ben_Reinhardt/designing-collaborative-ai-5c1e8dbc8810
実現可能性を見積もるにあたってのヒューリスティクス(p.48)
- Andrew Ng「普通の人が1秒未満でできることのほとんどは今のAIで自動化できる」
  - 1秒でできる例:
    - 画像の認識
    - 音声の認識(理解)
    - 音声翻訳
    - 物体認識
  - できない例 -ユーモア、皮肉の理解
    - 手を使う作業をロボットにさせること
    - Generalize to new scenarios(Scenario Generalizationというタスクがあるらしい)

自分のpose estimationプロジェクトの見積もりをやってみる(p.49)

Impact
- 目的はロボットがものをつかめるようになること
- 従来のロボティクスパイプラインでは、ヒューリスティックとオンライン最適化を用いられていた。それ故、動作が遅く、変化にもろい。それ故、ソフトウェア2.0にすることでインパクトがある!
Feasibility
- Data availability
  - データは集めやすい
  - アノテーションはchallengeな課題だけど、実験部屋にセンサーを取り付けることはできる
- Accuracy requirement
  - ものをつかむには高いaccuracyが必要。誤差0.5cm以内。
  - だけど、失敗は低コスト。単位時間あたりのつかむ回数が大事。掴むのに成功した回数はそれほど重要ではない。
Problem difficulty
- 既存研究が自分のところに流用できない

2. メトリクスの選定(p. 51)

f:id:meow_memow:20200621122343p:plain

メトリクスの選び方、組み合わせ方

メトリクスの選定に重要なこと
1. 実世界は乱雑(messy)。つねに多くのメトリクスを気を払っておくこと。
2. とはいっても、MLシステムは一つのメトリクスを最適化する時はbest
3. 結果として、数あるメトリクスを組み合わせて一つのメトリクス(formula)をつくればいい
4. この式は変えることができるし、変わるだろう。
どうメトリクスを組み合わせるか
- 相加平均、重みつき平均、など。
- Thresholding metrics
  - nつのメトリクスがある時に、n-1つのメトリクスはしきい値を設けて足切り用に使い、残りの1つのメトリクスの良し悪しでモデルを評価する(p.66も参照されたし)
Thresholding metricsで考えるべきこと(p.64)(ここ、意味がわからなくて訳が思い浮かばなかった。)
- どのメトリクスを足切りに使うか
  - Domain judgment (e.g., which metrics can you engineer around?) (? ドメインに応じて決める、的な意味か? 工夫できるメトリクスってどういうこと?)
  - Which metrics are least sensitive to model choice? (? モデル選定にあまり影響を及ぼさない的な意味か?)
  - Which metrics are closest to desirable values? (? モデルの要件に望ましい値に最も近いものを選ぶということか? 見逃しが少ない方がいいからrecallで足切りする、的な。)
- しきい値はどのあたりに定めるか
  - Domain judgment (e.g., what is an acceptable tolerance downstream? What performance is achievable?) (? これもドメインで決める的な意味か。モデルを後の処理で(downstream)使う時の許容範囲で決める、的な。)
  - ベースラインがそのメトリクスでどれだけの値を出すか
  - メトリクスがその時、どれくらい重要かに応じて
Thresholding metricsの例(p.66)
- recallのしきい値を0.6より大きいとする。
- そのうえで、Precisionを代表的なメトリクスとすると、model1はrecallが届いておらず足切りされる。
より複雑、ドメイン固有なメトリクスを作る。(p.69～74)
- より複雑、ドメイン固有なメトリクスを作る。例えばmAP(なぜ、mAPがドメイン固有なのかは書いていなかった)

メトリクス選定の例として自分のpose estimationタスクにあてはめてみる(p.75～p.81)

要件
- 最終的にはロボットが現実世界でものをつかめるようになりたい。
- 位置の誤差は一旦<1cmとする。このしきい値が本当に適切かはわからない。
- 角度の誤差は5°以内。
- 現実世界で100ms以内で動く
実験:
- いくつかモデルを学習
今のパフォーマンスを要件と比べる
- 位置エラーは0.75cm～1.25cmある(ハイパーパラメータによる)。
- 角度誤差は60°くらいある。
- 推論時間は最大300ms
  - → 角度誤差の対策が優先。位置エラーのしきい値は1cm。実行時間の遅さはここでは無視する。
数値が改善したら、メトリクスを見直す(予定)

3. ベースラインの選定(p.82)

f:id:meow_memow:20200621122400p:plain

Key points for choosing baselines(p.83)
1. ベースラインを決めることで、MLモデルに期待する性能の下限を決める事ができる
2. 下限が厳しいほど。ベースラインとして有用
  1. 既存の研究結果
  2. 念入りにチューニングされたパイプライン
  3. human baselineなど)
なぜベースラインは重要か(p.85)
- 定めるベースラインが異なれば。自分のモデルの性能とベースラインの差も異なり、その差に応じて次に打つ試作も異なるから。
ベースラインをどこで見つけるか(p.86)
- External ベースライン:
  - ビジネス
  - エンジニアリングの要件
  - 既存の研究結果← フェアに比較していることを確認して!
- Internal ベースライン:
  - スクリプトベースの方法(OpenCVとか、ルールベースとか)
  - シンプルなMLモデル(標準的な特徴量のモデル bag-of-wordsとか。)
  - 人手で特徴設計された線形分類器(基本的なDNNモデル(batch normarizationのないVGGとか))
human baselineをどう作るか(p.92)
- human baselineのリスト。下に行くほどベースラインの質は高く、また、そのためのデータ入手が困難
  - 無作為に選んだ(一般の)人(例 Amazon Turk)
  - 複数人の無作為に選んだ人
  - ドメインにおけるエキスパート(例医者)
  - より深くドメインに特化したエキスパート(例 specialists)
  - 複数人のエキスパート
- How to create good human baselines(p.93)
  - Highest quality that allows more data to be labeled easily(? 最上級品質のベースラインはより多くのデータのアノテーションを楽にしてくれる)
  - ドメインが特化するほど、アノテーターにスキルが必要
  - モデルの性能が低下するケースを見つけ、(そのケースを解決するような)データ収集に絞る