現在、AIや機械学習界隈で最も有名なスタンフォード大学のAndrew Ng教授が、「Machine Learning Yearning」というオンライン書籍を執筆中です。2018年4月に、そのドラフト版（1-22章）がオンラインで公開中です。この投稿では、いち早く翻訳を進めています。
この本は、機械学習プロジェクトの構築方法を提供します。また、機械学習アルゴリズムを教えるのではなく、機械学習アルゴリズムが機能する方法に焦点を当てています。
本投稿は、17-18章の翻訳になります。少しづつ翻訳していきます。※翻訳違っていたらご指摘ください。
本書籍は、とても読みやすく、かつ各章短めに記載されています。
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教授
13-14章の翻訳
機械学習プロジェクトの進め方：『Machine Learning Yearning』13-14章（スタンフォード大学Andrew Ng教授）
15-16章の翻訳
機械学習プロジェクトの進め方：『Machine Learning Yearning』15-16章（スタンフォード大学Andrew Ng教授）
17. If you have a large dev set, split it into two subsets, only one of which you look at（大規模な開発セットをもつならば、2つのサブセットに分割して、一方のサブセットについて人手でエラーチェックを行いましょう。）
あなたは20％のエラーを含む5,000サンプルの大規模な開発セットを持つとしましょう。 つまり、あなたのアルゴリズムは約1000件の開発用の画像を誤分類しています。手作業で1,000枚の画像を検査するには、時間がかかります。そこで、エラー分析においては、すべてのエラーを利用しないことにしましょう。
この場合、私は開発セットを明示的に2つのサブセットに分割します。そのうち一方のサブセットについて検査し、もう1つは検査しません。手作業で検査しているデータに対して、より急速にオーバーフィットするかもしれません。手作業で検査していないデータについては、パラメータチューニングに利用することができます。
上記の例を続けましょう。このアルゴリズムでは、5,000件の開発セットのサンプルのうち、1,000件について誤分類しています。エラー分析のために、100件のエラーについて手動で検査するとしましょう（エラーの10％）。10％の開発セットをランダムに選択して、自分たちの目で確認する対象であることを忘れないように、「目玉の親父開発セット（Eyeball dex\v set）※」と呼びましょう（音声認識のプロジェクトでしたら、オーディオクリップを聴いて検査をすることになるので、ひょっとしたら代わりに「耳開発セット（Ear dev set）」と呼ぶことでしょう。）。したがって、目玉の親父開発セットは500件のサンプルを保持しており、100件については誤分類であることが予想されます。
※良い呼称がなかったので、よしなに和訳しました。
参照：http://dic.nicovideo.jp/a/%E7%9B%AE%E7%8E%89%E3%81%8A%E3%82%84%E3%81%98
開発セットのうち、2つ目のサブセットには、4,500件のサンプルが残っています。なお、この残りのサブセットは「ブラックボックス開発セット（the Blackbox dev set）」と呼ばれます。このブラックボックス開発セットは、エラーの割合を測定することで、自動的に分類器を評価するために利用できます。また、アルゴリズム選択やハイパーパラメータ調整にも利用できます。しかしながら、データの中身を自身の目玉で確認することは避けるべきです。なぜなら、このデータセットは、あくまで分類器の「ブラックボックス評価」として利用するために手に入れたデータサブセットだからです。
なぜ、明示的に「目玉の親父開発セット」と「ブラックボックス開発セット」を分けるのでしょうか。「目玉の親父開発セット」のサンプルについて、何かしらの知識・直感を得ているので、「目玉の親父開発セット」に対するオーバーフィットが進むでしょう。もし、「ブラックボックス開発セット」上でのパフォーマンスよりも早く「目玉の親父開発セット」上でのパフォーマンスが改善されていることがわかったら、「目玉の親父開発セット」に対するオーバーフィット状態となっているしょう。
この場合、「目玉の親父開発セット」を破棄して、「ブラックボックス開発セット」から「目玉の親父開発セット」にサンプルを移動させたり、新たなラベル付きデータを取得したりすることにより、新たな「目玉の親父開発セット」を見つける必要があるでしょう。
開発セットを「目玉の親父開発セット」と「ブラックボックス開発セット」に明示的に分割することによって、あなたの手動でのエラー分析プロセスが「目玉の親父開発セット」に対してオーバーフィットを引き起こしていることを教えてくれるのです。
18. How big should the Eyeball and Blackbox dev sets be?（「目玉の親父」と「ブラックボックス」の開発セットは、それぞれどれくらいのサイズにするべきでしょうか。）
あなたの「目玉の親父開発セット」は、アルゴリズムの主要エラーカテゴリを網羅しているくらい、十分に大きいサイズであるべきです。もし、人間がうまくこなせるタスクに取組んでいるのならば（画像の中から猫を認識する作業など）、ここにいくつかの大まかなガイドラインを用意しました。
- あなたの分類器で10件の誤分類しか存在しない「目玉の親父開発セット」は、とても小さいと考えられます。わずか10件のエラーで、異なるエラーカテゴリの影響を正確に推定することは難しいです。しかし、もし小さなデータしかなく、「目玉の親父開発セット」を拡張する余裕がない場合でも、無いよりはマシです。プロジェクトの優先順位付けに役立ちます。
- あなたの分類器が「目玉の親父開発セット」のサンプル上で最大20件の誤分類をする場合、主要エラー要因について大まかな感覚を得られると思います。
- 最大50件の誤分類を持つ場合、主要エラー要因を知ることができるでしょう。
- 最大100件の誤分類を持つ場合主要エラー要因について十分に理解することができるでしょう。私は、より多くのエラーに手作業で対応する人々を見てきました。時には500件ほど。十分なデータがあるのであれば、これを行うことは悪いことではありません。
あなたの分類器が5%のエラーを持っているとします。「目玉の親父開発セット」で100件の誤ラベリングしたサンプルを確認するために、「目玉の親父開発セット」を2,000サンプル用意しなくてはなりません（2,000サンプル×エラー5%＝100サンプル）。分類器のエラー割合が低いほど、エラー分析するに十分な量を得るために、より巨大な「目玉の親父開発セット」が必要となります。
人間でさえもうまくこなせないタスクに取組んでいるなら、「目玉の親父開発セット」を検査することは有用ではないでしょう。なぜならアルゴリズムが正しくサンプルを分類しなかった理由を理解するのが難しいためです。この場合には、「目玉の親父開発セット」を準備しなくても構いません。このような問題のガイドラインについては、後の章で解説します。
「ブラックボックス開発セット」についてはどうでしょうか。私たちはこれまで、だいたい1,000~10,000件くらいの開発セットを用意することが一般的であると述べてきました。1,000~10,000サンプルの「ブラックボックス開発セット」であれば、ハイパーパラメータの調整やモデル選択に十分なデータが得られます。100件の「ブラックボックス開発セット」でも、小さいですが有用です。
もし、小さな開発セットを持っている場合、「目玉の親父」と「ブラックボックス」それぞれの目的を達成するに十分なサブセットに分けられないかもしれません。代わりに、開発セット全体を「目玉の親父開発セット」として使用する必要があります。つまり、全ての開発セットデータを手作業で調べます。
「目玉の親父」と「ブラックボックス」の開発セットでは、私は「目玉の親父開発セット」がより重要であると考えています（人間がうまく解決できる問題に取り組んでおり、サンプルを調べることで洞察を得ることができることを想定しています）。仮に「目玉の親父開発セット」だけを保持していても、エラー分析・モデル選択・ハイパーパラメータのチューニングの全てを行うことができます。「目玉の親父開発セット」のみを準備することの欠点は、開発セットへのオーバーフィットリスクが大きくなることです。
もし、豊富なデータにアクセスできるのならば、「目玉の親父開発セット」のサイズは、主に「人手で分析する時間がどれくらいあるか」の観点で決定されるでしょう。例えば、1,000件以上のエラーを人手で分析するのを見たことはめったにありません。