現在、AIや機械学習界隈で最も有名なスタンフォード大学のAndrew Ng教授が、「Machine Learning Yearning」というオンライン書籍を執筆中です。2018年4月に、そのドラフト版（1-22章）がオンラインで公開中です。この投稿では、いち早く翻訳を進めています。
この本は、機械学習プロジェクトの構築方法を提供します。また、機械学習アルゴリズムを教えるのではなく、機械学習アルゴリズムが機能する方法に焦点を当てています。
本投稿は、15-16章の翻訳になります。少しづつ翻訳していきます。※翻訳違っていたらご指摘ください。
本書籍は、とても読みやすく、かつ各章短めに記載されています。
1～5章の翻訳
【Draft版公開】Machine Learning Yearning 1～5章 by stanford大学Andrew Ng教授
6章の翻訳
【Draft版公開】Machine Learning Yearning 6章 by stanford大学Andrew Ng教授
7-8章の翻訳
【Draft版公開】Machine Learning Yearning 7～8章 by stanford大学Andrew Ng教授
9-10章の翻訳
【Draft版公開】Machine Learning Yearning 9～10章 by stanford大学Andrew Ng教授
11-12章の翻訳
[【Draft版公開】Machine Learning Yearning 11～12章 by stanford大学Andrew Ng教授]
(https://qiita.com/Ishio/items/35c756e073a1f2f1d244)
13-14章の翻訳
機械学習プロジェクトの進め方：『Machine Learning Yearning』13-14章（スタンフォード大学Andrew Ng教授）
15. Evaluating multiple ideas in parallel during error analysis（エラー分析において、複数のアイデアを並列評価する）
あなたのチームには、猫の画像分類器のパフォーマンスを改善するために、以下のようないくつかのアイデアがあります。
- 犬を猫として認識するアルゴリズムの問題を修正する。
- 大型の猫（ライオンやヒョウなど）を飼い猫（いわゆるペットの猫）として認識するアルゴリズムの問題を修正する。
- ぼやけた画像に対するシステムのパフォーマンスを改善する。
- などなど
これらのアイデア全てを効率的に並行して評価することができます。私はいつも、「スプレッドシート（spreadsheet、いわゆる集計表 ）」を作成し、100件までの誤分類した開発セットの画像を確認しながら、それを記入します。具体的なサンプルを書き留めておきました。このプロセスを説明するために、開発セットの4つのサンプルを使ったスプレッドシートの記入例を見ていきましょう
| 画像（Image） | 犬（Dog） | 大型猫（Great cat） | ぼかし（Blurry） | コメント（Comments） |
|---|---|---|---|---|
| 1 | ✔ | ピットブルには珍しい色 | ||
| 2 | ✔ | |||
| 3 | ✔ | ✔ | ライオン；雨の日に動物園で撮影 | |
| 4 | ✔ | 木の後ろにいるヒョウ | ||
| ％ of total | 25% | 50% | 50% |
上記の画像NO3は、「大型猫」と「ぼかし」の両方に列にチェックされています。さらにいうと、1つのサンプルが複数のカテゴリに関連付けられる可能性があるため、最下部のパーセンテージは、加算しても100%にならないことがあります。
カテゴリ（犬、大型猫、ぼかし）を最初に作成することもできますが、手作業で分類を行っていると、実際にはサンプルを確認している中で、新しいエラーのタイプが見つかり、カテゴリ追加するように促されるかもしれません。例えば、十数枚の画像をみて、インスタグラムでフィルターされた写真に多くの誤分類が発生していることを悟ったとしましょう。戻って新しく「インスタグラム（Instagram）」の列をスプレッドシートに追加することができます。
人手でアルゴリズムが誤分類をしているサンプルを探し、人間であればどうやって正確に写真にラベルをつけることができるかを自問自答すれば、エラーの新しいカテゴリ追加を思いつけるようになると思います。
最も有用なエラーのカテゴリには、改善に向けたアイデアが存在するものです。例えば、インスタグラムのカテゴリの場合、インスタグラムのフィルターを元に戻して、オリジナルの画像を復元するアイデアがあれば、追加することができます。しかし、改善する方法を知っているエラーのカテゴリだけに制限する必要はありません。この取組みのゴールは、最も投資すべき有望なアイデアに集中するべきかというあなたの直感を築くことです。
エラー分析は反復的なプロセスです。例えカテゴリが存在しない状態で開始したとしても、何も心配することはありません。いくつかの画像を確認した後で、エラーカテゴリに関するいくつかのアイデアが出てくるかもしれません。いくつかの画像を人手で分類した後で、新しいカテゴリに気づき、そのカテゴリを考慮して画像を再検査することがあるかもしれません。
100件の誤分類された開発セットのサンプルに対するエラー分析が終了したとしましょう。以下のスプレッドシートが出来上がったとします。
| 画像（Image） | 犬（Dog） | 大型猫（Great cat） | ぼかし（Blurry） | コメント（Comments） |
|---|---|---|---|---|
| 1 | ✔ | ピットブルには珍しい色 | ||
| 2 | ✔ | |||
| 3 | ✔ | ✔ | ライオン；雨の日に動物園で撮影 | |
| 4 | ✔ | 木の後ろにいるヒョウ | ||
| ... | ... | ... | ... | ... |
| ％ of total | 8% | 43% | 61% |
犬のカテゴリに関する誤分類に対処することで、最大で8%のエラーを排除できます。大型猫やぼかし画像のエラーに対処することで、より多くのエラーを排除することができます。
したがって、後者の2つのカテゴリのうちの1つを選択して、そのエラーに集中することができます。あなたのチームが、複数の方向（＝エラーカテゴリ）に対して並行して追及するに十分な人員がいる場合には、数人のエンジニアに大型猫のカテゴリへの対応を、その他のエンジニアにはぼかし画像への対応を依頼することが可能です。エラー分析では、最優先に対処すべきタスクが何かを示す厳密な数式は生成されるわけではありません。それぞれのカテゴリでどれくらいの改善が見込まれるか、そしてどれくらいの作業量が見込まれるかを考慮する必要があります。
16. Cleaning up mislabeled dev and test set examples（誤分類された開発/テストセットのサンプルをクレンジングする）
エラー分析の最中に、開発/テストセットの中にいくつか誤ったラベルが付いたサンプルの存在に気づくかもしれません。ここでいう「誤ったラベル付け(mislabeled)（ここでは誤ラベル付けと訳します。。。）」された画像とは、アルゴリズムが判定する以前に、人間の分類担当者（Labeler）が間違ったラベルを付与した画像のことを指します。つまり、サンプル（x, y）は正しくないyの値を持っていることを意味します。
例えば、猫ではない写真の中には、猫を含む写真を誤って分類していることがあるかもしれません。その逆の可能性もあります。もし、誤ったラベル付けの画像の割合が重要であると思うならば、誤分類のサンプルの割合をトラッキングし、以下のようにエラーとしてカテゴリを追加してください。
| 画像（Image） | 犬（Dog） | 大型猫（Great cat） | ぼかし（Blurry） | 誤ったラベル付け（mislabeled） | コメント（Comments） |
|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... |
| 98 | ✔ | 分類担当者は背景の猫を見落としている | |||
| 99 | ✔ | ||||
| 100 | ✔ | 猫が描かれている。本物ではない。 | |||
| ％ of total | 8% | 43% | 61% | 6% |
あなたの開発セットは、ラベルを正すべきでしょうか？思い出してください。開発セットの目的は、アルゴリズムAがBよりも優れているかどうかを判断できることで、すばやくアルゴリズムを評価するための手助けをすることです。もし、開発セットにおける誤ラベル付けの割合が、アルゴリズムの優劣をつける上で無視できない規模である場合には、開発セットの誤ラベル付けを修正することに時間を割くべきです。
例えば、あなたの分類器のパフォーマンスが以下の通りであるとします。
- 開発セット全体の正解率：90%（10%のエラー）
- 誤ラベル付けサンプルによるエラーの割合：0.6%（開発セット上のエラーの6%）
- 他の原因によるエラーの割合：9.4%（開発セット上のエラーの94%）
ここで、誤ラベル付けによる0.6%の不正解は、改善可能な9.4%のエラーと比較して相対的に重要ではないかもしれません。開発セット上の誤ラベル付けされた画像を人手で修正することに何の害もありませんが、それを行うことは重要ではないということです。つまりあなたのシステムが、全体のエラーの割合が10%か9.4%かは、あまり重要ではないということです。
猫画像の分類器を改善し続け、以下のパフォーマンスに到達したとしましょう。
- 開発セット全体の正解率：98%（2%のエラー）
- 誤ラベル付けサンプルによるエラーの割合：0.6%（開発セット上のエラーの30%）
- 他の原因によるエラーの割合：1.4%（開発セット上のエラーの70%）
エラーの30%は、誤ラベル付けされた開発セットの画像によるものです。正解率の推定にとって重大なエラー項目として加えましょう。
開発セット上のラベル付けの品質を改善することは、今回は価値があります。誤ラベル付けされたサンプルに取組むことで、分類器のエラーが1.4%または2%に近づくことを手助けします。これは（先ほどと比較して）相対的にとても重大な差異です。
誤ラベル付けされた開発/テストセットのサンプルを許容し始めることは、珍しいことではありません。ただ後で気が変わるだけです。あなたのシステムが改善してていき、誤ラベル付けされたサンプルの割合が相対的に増加してくることによって。
ひとつ前の章では、アルゴリズムの改善を通して、犬、大型猫、ぼかしのようなエラーカテゴリの改善方法について説明しました。この章では、誤ラベル付けされたカテゴリ上でも作業することができることを学んでいます。
開発セットのラベル修正を適用するプロセスは、テストセットにも適用することを忘れないでください。というのも、開発/テストセットは同じ分布から作り出されるべきです。開発/テストセットを一緒に修正すると、第6章で説明した問題を防ぐことができます。第6章では、チームは開発セットとテストセットが同じ分布から導かれるべきであることを学習しました。
仮にラベルの品質を改善することを決めた場合には、「あなたの分類器が誤分類したサンプルのラベル」と、「正しく分類したサンプルのラベル」の両方について確認してください。特定のサンプルに対して、オリジナルのラベルと学習したアルゴリズムの両方が間違っていた可能性があります。もし分類器が誤分類したラベルのみを修正すると、評価にバイアスが加わる可能性があります。もし、1,000件の開発セットを持っていて、分類器が98%の正解率であるとき、正しく分類された980件のサンプルを全て調べるよりも、20サンプルを確認することは簡単です。実際に誤分類されたサンプルをチェックするほうが簡単であるため、バイアスはいくつかの開発セットに入り込みます。このバイアスは、もし製品やアプリケーション開発にのみ関心があるのであれば許容されるものですが、結果を学術論文で使用する場合や、テストセットの正解率について完全にバイアスがない測定が必要な場合には、問題になります。