このメモの使い方

・日本語で本文を検索、もしくは斜め読みします
・興味があるセクションが見つかったら、原文にあたってください。 -> http://www.mlyearning.org/

1 Why Machine Learning Strategy

性能を改善したい場合はいろいろな方法が考えられるが、うまくやらないと月日を無駄にすることになる
本書では、何をやるべきか、やらないべきかの手がかりを与えます

2 How to use this book to help your team

本書を読み終えた後は、プロジェクトの進め方について深く理解した状態になっているでしょう
実際に適用しようと同僚に進めるとき、うまく説得できないかもしれません
そんなときにこの章を見せてください。（そのためにこの章を短くした）

3 Prerequisites and Notation

本書を読む進めるための前提条件は、教師付きが学習に親しんだ経験があること
なければcorseraなどのムックで少し勉強してね

4 Scale drives machine learning progress

DLが流行ってる理由は、使えるデータが非常に増えたことと、大量の計算が可能になったこと
それと単純なレグレッションモデルからより複雑なDNNになったことで、データ量に対してサチらなくなったこと
本書の内容は伝統的な手法、DNNのどちらにも有効です

Setting up development and test sets

5 Your development and test sets

定義
- トレーニングセット: 学習アリゴリズムを走らせるためのデータ
- devセット: パラメータ調整、変数選択などに使うデータ
- testセット: アルゴリズムを評価するために使うデータ
testセットは実際に動かす環境のものが望ましい
- モバイル環境上の猫検出器の例
- 訓練にweb上にある高品質画像を使うと、低品質なモバイル画像で良い精度が出ない可能性がある

6 Your dev and test sets should come from the same distribution

dev/testセットを違うところから持ってくると、性能改善時に混乱するのでオススメしない

7 How large do the dev/test sets need to be?

0.1%の正確さの違いを検出するためには、10000件のサンプルが必要
ビッグデータ時代には、ビリオンオーダー以上の件数が必要

8 Establish a single-number evaluation metric for your team to optimize

複数の評価指標で良し悪しを判断するのは大変
F1スコア等、単一の評価値を使えば、開発中に素早く判断できる

9 Optimizing and satisficing metrics

最適化メトリクス(F1スコアとかで表現されるもの)と充足メトリクスに分ける
充足条件: 100ms以下必須とか、24時間以内に１回以上誤認識が発生しないとか
充足しないものは切って、その上で最適化メトリクスで判断すると、素早く進められる

10 Having a dev set and metric speeds up iterations

新しい問題に対しては、前もって最良のやり方を知ることは経験豊富なML研究者でさえ難しい
彼らも、満足する方法を見つけるために多くのアイデアを試している
アイデア - 実装 - 評価のサイクルをいかに早く回せるかが、ゴールまでの時間を決める
上記7から9を抑えることで実現

11 When to change dev/test sets and metrics

dev/testセットと初期のメトリクスの選択は１週間以内で行なっている
完全ではないかもしれないが、考えすぎる前に素早く前進できる
が、メトリクスと実際の良さが逆に感じ始めたら、そこがdev/testセットかメトリクスを考え直すタイミング
上記状況の考えられる発生原因
- 実際の分布と違う: dev/testセットは大人猫、実際にリリースするモバイルappでは子猫画像が多くアップされるかもしれない
- オーバーフィッティング発生: devセットが、testセットより大幅に性能が良い場合はこのサイン
- メトリクスが何か別のものを評価している: その指標は、ポルノ画像をスルーしても悪化しない指標かもしれない
新しい指標として、ポルノ画像等に重いペナルティを課すようにするなどが考えられる

12 Takeaways: Setting up development and test sets

将来適用対象となるデータ群からdev/testセットを選ぶこと
可能ならdevセット、testセットを同じところから持ってくること
最適化には単一評価値を使うこと。複数の評価指標が必要な場合でも単一の値に変換すること。もしくは充足メトリクスを定義してもよい
機械学習では、満足する結果が得られるまでに多くのアイデアを繰り返し試行するプロセスが必要
dev/testセットと単一値指標は、簡単に評価できるゆえに繰り返しプロセスを高速化できる
新たなアプリケーションでは、最初にざっくりde/testセットとメトリクスを決めてさっさと始めるとよい
伝統的な方法では、70/30でdev/testセットを分けていたが、ビッグデータ時代の今はtestセットはだいぶ小さくてよい
細かい単位で精度をあげるには、それに応じた量のデータ数が必要
devセットとメトリクスがもはや正しい方向に機能していない状態になったら、即座に変更すること
- 過学習してるなら、データ数を増やす
- 実際に適用するデータ群と異なっているようなら、新たなデータを探す
- メトリックが重要なものを見落としているようなら、それを変える

Basic Error Analysis

13 Build your first system quickly, then iterate

アンチスパムフィルタの例
最初から完璧なシステムを作ろうとしないこと
2,3日でできる簡単なシステムをさっさと作って始めること
完璧な結果から程遠いが、それは時間を次にどこに投資すべきかを知るための手がかりになる
ただし、これらは研究者でなくAIアプリを作りたいと思っている人向けのアドバイス

14 Error analysis: Look at dev set examples to evaluate ideas

猫認識アプリを作ってみたら、猫っぽい犬を誤認識してしまう。そこでメンバーは犬画像をもっとうまく判別できることに１ヶ月使おうとしている。
その前にそれが正答率をどのくらい改善できる可能性があるかを評価してみることを推奨します
その上で、１ヶ月掛けてそれをやるか、別の仕事にその時間を使うかを決めることができます
その評価の具体的な方法
- 誤認識するサンプルを100件集めます
- それらを１つずつ目で見て、原因ごとに分類していきます
  *　このプロセスは、エラー解析と呼ばれています
もしたったの5%が犬画像なら、犬画像について改善してもほとんど効果はないでしょう
この5%は、その改善をした場合の最大の効果です(シーリング)。もし今90%の正答率なら、最大でも90.5%にしかなりません
これが50%だと、最大95%まで改善できるので大きなインパクトがあります
100件エラー解析する時間は、せいぜい２時間くらい。これが月単位の時間を節約することになります

15 Evaluating multiple ideas in parallel during error analysis

判別に失敗した100件を行に、原因をカラムにした表を作る。コメントカラムも付け加えておく
各サンプルを目で見て、原因となるカラムにチェックしていく（複数カラムにチェックしても良い）
途中で新たな原因(Instagramのフィルタが掛けられているなーとか)に気づいたら、カラムを追加してやり直す
新たな原因に気づくことで、改善方法のヒントが得られる: フィルタが掛けられた画像を元に戻してみるとか
各原因ごとの発生率を見れば、改善が有効な対象を知ることができます

16 Cleaning up mislabeled dev and test set examples

エラーの中には、人が誤ってラベル付けしたものも含まれる
すべてのエラーのうち、ラベル誤りが占める比率が高い場合は、ラベル修正を行う価値がある
ラベル品質を上げることに決めた場合は、正解となったサンプルもあわせてチェックすること

17 If you have a large dev set, split it into two subsets, only one of which you look at

大量のdevセットを持っている場合は、２つに分割して、片方のみを使うとよい
すぐ過学習してしまうでしょうが、もう片方をパラメタ調整で使うことができます
例えば5000件でエラー率が20%の場合、1000件程度ミスサンプルが発生する
その中から100件目視チェックするとした場合、500件のdevセットを目視していることになります(このdevセットを目ん玉devセットと呼んでいます)
残りの4500件をブラックボックスdevセットと呼んでいて、アルゴリズムの選択や、パラメタ調整に使います。(このセットは目視チェックしない方がよい）
このようにすることで、エラー解析の反映による過学習を避けることができます
もし、ブラックボックスdevセットより、目ん玉devセットに対するパフォーマンスが著しく早く改善している状況なら、目ん玉devセットに過学習している状況です
このようなケースでは、ブラックボックスdevセットからいくつか加えるか、新しいサンプルを追加する必要があるかもしれません

18 How big should the Eyeball and Blackbox dev sets be?

ミスサンプル件数と解析精度の目安
- ミスサンプルが10件以下: エラー解析の精度がまったくでないが、元々サンプル件数が少ないとなどの理由があれば、ないよりはあった方がましなので仕方ありません。
- ミスサンプルが20件以下: 主因をなんとなく掴める程度
- ミスサンプルが50件以下: 主因をいい感じで掴める
- ミスサンプルが100件以下: 主因をとてもいい感じで掴める。多ければ多いほどよい
エラー率が低いほど多くの目ん玉devセットが必要になります
人が判断できない問題の場合は、目ん玉devセットに分けるこの方法は効果がないです。この場合、どうするかは後ほど説明します。
1,000から10,000件のブラックボックスdevセットがあれば十分で、これ以上あるとあまり良くないかもしれない。100件だと少ないけど、それでも有用です。
devセットが小さい場合は、すべて目ん玉devセットとして扱うことになるかも。その場合は、全件目視チェックすることになります
目ん玉devセットは、ブラックボックスdevセットより重要です
目ん玉devセットのみでも、エラー解析、モデル選択、パラメタ調整をすることができます。しかし、過学習のリスクが大きくなります。

19 Takeaways: Basic error analysis

新しいプロジェクトを始めるとき、特にそれが良く知らない分野だと正しい方向性を推測するのは大変困難です
最初から完璧なシステムを作ろうとしてはいけない。基本的なものをパッと作ってそれを速く回して、エラー解析すれば着実に良い方向に進める
100件程度の目視チェックによるエラー解析を行い、どのタイプのエラーを先に潰すか決めること
目ん玉devセットとブラックボックスdevセットに分けて、前者を目視チェックすること
目ん玉devセットがブラックボックスdevセットより精度が著しく良い場合、過学習しているので目ん玉devセットの件数を増やすこと
目ん玉devセットは、十分なミスサンプルが得られる程度まで確保すること、ブラックボックスdevセットは1,000-10,000件あれば十分です!
もしこのように分けられるほどサンプルがなければ、すべて目ん玉devセットとしてよい

20 Bias and Variance: The two big sources of error

データをむやみに増やしたからといって結果がよくなるとは限らない
２つの主要なエラー要因 -> biasとvariance
これらを理解するとデータを追加すればいいのか、パフォーマンスを改善する他の方法を考えればよいのかを決めることができ、時間を有効に使えます
例: 目標エラー5%の猫認識器: trainセットのエラーが15%, devセットのエラーが16%のとき
- この場合データ追加は効果がない（どころか）悪化してしまいます
devセット、testセットのエラー率は、trainセットの結果より通常悪化するので、trainセットのエラーが大きい場合は、最初の問題はそれを下げることです
devセットのエラーを仮に16%としたとき、それを２つの要素に分けて考えます
1. bias: trainセットのエラー率(15%とする)
2. variance: trainセット、devセットのエラー率の差分: ここでは1%
学習アルゴリズムを変えてみるといったことは、biasに効きます
一般化は、varianceに効きます
biasとvarianceに対する直感を磨くと効率よくアルゴリズムを改善していくことができます

21 Examples of Bias and Variance

理想的な目標はエラー率0%
trainエラー=1%, devエラー=11%のとき
- -> bias=1%, variance=10%
- -> high variance
- -> 一般化できてない(過学習の状態)
trainエラー=15%, devエラー=16%のとき
- -> bias=15%, variance=1%
- -> high bias / low variance
- -> アンダーフィッティング
trainエラー=15%, devエラー=30%のとき
- -> bias=15%, variance=15%
- -> high bias / high variance
- -> 一般化できていない上にアンダーフィッティング
trainエラー=0.5%, devエラー=1%のとき
- -> bias=0.5%, variance=0.5%
- -> low bias / low variance
- -> 素晴らしい性能

22 Comparing to the optimal error rate

雑音が多い場所の音声認識とか人でも聞き分けが難しい場合、理想的なエラー率は高くなる。(14%とか)
この例で、trainエラー=15%, devエラー=30%であれば、biasを下げる余地はほとんどなく、一般化する方法を考えるべき
理想的なエラー率が0%より遥かに大きい場合は、以下に分解して考える
1. 最適エラー率(回避できないbias)
2. 回避可能なbias: trainエラー率 - 最適エラー率
  * まれに負の値になってしまうことがあるが、過学習している可能性が高いので、variance改善に向かうべき
3. variance
最適エラー率: 14%, trainエラー率: 15%, devエラー率: 16%
- -> 回避可能なbias: 1%, variance: 1% なので、改善の余地はほとんど残っていない
この最適エラー率は、ベイズエラー率と呼ばれています

23 Addressing Bias and Variance

biasとvarianceを使った取り組み方
- 回避可能biasが高い場合 -> モデルサイズを増やす(レイヤやユニットを追加してNNの規模を増やすとか)
- varianceが高い場合 -> トレーニングセットのデータを増やす
モデルの規模やサンプル数を無制限に増やすことができれば最高の結果を得られるが、現実にはそうはいかない
異なるアーキテクチャモデルを採用すると、biasとvarianceも違ってくる。ただ、上記のシンプルな方法にくらべると効果を予測しづらい
モデルサイズを増やすとbiasは減るが、varianceが下がるとともに過学習のリスクが増します
しかし、この過学習はレギュラライズを使ってないときに起こるものなので、適切な正則化処理を使えば過学習を気にすることなくモデル規模を増やせます
パラメータ調整済のL2-regularizationかドロップアウトを使ったディープラーニングモデルを使っていると仮定すると、モデル規模を増やすと、性能は変わらないもしくは良くなるのどちらかです
なので、モデルの大規模を避ける唯一の理由は計算コストです

24 Bias vs. Variance tradeoff

biasとvarianceのトレードオフについて聞いたことがあるかもしれない
現代の環境では、データも豊富に取得できるし、大規模なニューラルネットワークを扱うこともできるので、トレードオフの関係性は小さくなっているし、varianceを傷つけることなくbiasを改善する方法がたくさんあります
例
- 正則化処理を調整しながらネットワーク規模を増やすことで、varianceを大きく増やすことなく、biasを減らせる
- 訓練データを増やすことで、biasに影響を与えずに、varianceを減らせる
タスクに対して適切なモデルを選択すると（簡単なことではないですが）、biasとvarianceの両方を同時に改善できます

25 Techniques for reducing avoidable bias

回避可能biasに対する処方箋
- モデル規模を増やす: varianceの増加を感じたら、それを減らすために正則化処理をかますこと
- エラー解析の洞察に基づいて入力となる特徴を変えてみる: 増やした特徴はbias, varianceの両方を改善することがある。理論的にはvarianceが増えるので、正則化処理をかましておくこと
- 正則化を弱める: ただしvarianceは増える
- モデルアーキテクチャを変える: biasとvariance両方に影響がある
- トレーニングデータを追加することは、bias改善には役立たない

26 Error analysis on the training set

devセットで良い性能を得る前に、trainセットの性能を上げる必要がある
biasが特に高い場合、トレーニングデータに対しても、目ん玉devセットのケースと同様のエラー解析を実行することがあります
たとえば、音声認識の場合、雑音があるケースのエラー率が高いことがわかれば、多くの雑音がある場合への対処に時間を多く割けばよいとわかります
人で文字起こしできるかチェックしてみるのよいかも: 雑音が大きくて人が認識できないものは、機械学習にそれを期待するのは無理筋かもしれない

27 Techniques for reducing variance

variance改善の処方箋
- トレーニングデータを追加する
- 正則化処理を追加すつ(L2正則化、L1正則化、ドロップアウト): biasは増える
- 早期停止を追加する(勾配降下の早期停止、devセットエラーベース): biasは増える。正則化の一つとして考える人もいる
- 入力特徴の数やタイプを減らす: biasは増えるかもしれない。
  - 最近のディープラーニング環境では、データが豊富なので、上記処方はあまり行われれず、すべての特徴を与えて、アルゴリズムに取捨選択を任せる方向になっている
  - 用意できるデータが少ない場合は、特徴選択はとても有用
- モデル規模を小さくする: biasは増える可能性がある。ただvariance改善を目的とする場合は非推奨としたい(正則化推奨)
  - 計算コストの削減が意味がある場合のみ有効
- エラー解析の洞察に基づいて入力となる特徴を変えてみる: 増やした特徴はbias, varianceの両方を改善することがある。理論的にはvarianceが増えるので、正則化処理をかましておくこと
- モデルアーキテクチャを変える: biasとvariance両方に影響がある

28 Diagnosing bias and variance: Learning curves

学習曲線は、devセットのサンプル数を増やしながらエラー率をプロットしていくと作ることができる
トレーニングセットが大きくなるにつれて、devセットのエラーは減少する
望ましいエラー率の例
- 人間レベルの性能を望んでいるなら、人間のエラー率が望ましいエラー率になる
- もし学習アルゴリズムを使って製品を提供するなら、ユーザに良い経験を与えるのに必要な性能レベルについて直感を得られるかもしれない
- 長期間使用される重要なアプリなら、次の期・年にどのくらい進歩が見込めるかについての直感が得られるかもしれない
学習曲線に望ましいエラー率を追記すると、どのくらいデータ数を増やせば望ましいエラー率まで改善できそうか目視できる
もし学習曲線がフラットになってしまったら、データをさらに追加しても無駄ということがすぐにわかる
トレーニングデータについても同様の曲線を作っておくとよい

29 Plotting training error

トレーニングセットを大きくするにつれて、トレーニングセットのエラー率は通常上がっていく
- サンプル数が少ないと、アルゴリズムはラベルを簡単に覚えてしまう
- サンプル数を100程度に増やしたとき、ボケている画像など人間が判別できないサンプルも覚えてしまう
エラーとサンプル数をプロットするとサンプル数が増えるにつれて
- devセットのエラーは漸減する
- trainセットのエラーは漸増する

30 Interpreting learning curves: High bias

devエラーが停滞するとそれ以上データを追加しても望んでいる性能に到達することはなさそう
しかしdevエラーのカーブだけを見て、本当に上の状態になっているかどうかを知ることは難しい。特にdevセットのサイズが小さい時はより確信するのは難しい
ここでtrainエラーのカーブを加えてみると確信することができそう
- trainエラーはデータを追加していくと、同じかより悪化するので、望んでいる性能をすでに超えていれば、そこに近づくことはない
- それゆえ、devエラー率は、通常trainエラー率より高いので、望んでいる性能に近づくことはない
trainエラーと希望性能とのギャップが大きい場合は、回避不能バイアスが大きいことを示唆している
trainエラーとdevエラーカーブのギャップが小さい場合は、varianceが小さいことを示唆している
以前の議論では、tranエラーとdevエラーのもっとも右側の１点を対象としていたが、本章のように学習曲線を描いてみるとトレーニングセットのサイズによるアルゴリズムの性能を把握できるようになる

31 Interpreting learning curves: Other cases

trainエラーが希望性能の上、devエラーが結構高い場合
- 低bias、高varianceの状態なので、データを追加すればおそらくtrainエラーとdevエラーの差は小さくなっていく
trainエラーが希望性能よりかなり高く、さらにdevエラーはより高い場合
- 大きなbias、大きなvarianceの状態なので、biasとvarianceの両方を下げる方法を見つける必要がある

32 Plotting learning curves

少量のサンプルしか持っていないとしたとき、少しずつ取り出しながら学習曲線を描くと、最初の少サンプル部分では、かなりノイズが乗ったものになる
特に、クラスの分布が偏っているケースや他クラスのケースでは、取り出したサンプルに入らないクラスが出てくる
もし、このようなノイズでトレンドの読み取りが難しい場合は、次の２つの解決策がある
1. サンプルセットを複数回取り出して、学習・評価し、それらの平均を取る
2. クラスが偏っている場合は、全体の比率に近い割合となるようにそれぞれサンプルを取り出す
サンプル数が大きいときは、計算コストの問題もあるので、リニアに刻んでいく代わりに、1000, 2000, 4000, 6000, 10000といった感じにしてもトレンド感は十分掴める

Comparing to human-level performance

33 Why we compare to human-level performance

もし、人がうまく対処できているタスクをMLでやろうとしている場合、システムの構築がより容易になる理由がいくつかあります
1. 簡単に人手で高精度なラベル付けされたデータが得られること
2. エラー解析で間違い箇所を容易に書き出せること
3. 最適エラー率や望ましいエラー率を見積もるのに人レベルのパフォーマンスが使える
以下の問題に直面することにより人が不得意とする作業に対しては、既にたいていの人を超えています
1. ラベル付けが比較的難しい
2. 人の直感では結果の評価が難しい(例：予測した株価変動がランダム予測に対してどのくらいよいのかとか)
3. 最適エラー率や望ましいエラー率を知ることが難しい

（とりあえずここまで：残り34-52）