検証セットとテストセットの両方を使用する理由

ニューラルネットワークについて考えます。

特定のデータセットについて、トレーニング、検証、テストセットに分割します。古典的な60:20:20の比率でそれを行うと仮定し、検証セットでチェックすることによりネットワークを検証することにより、過剰適合を防ぎます。次に、パフォーマンスを確認するためにテストセットでテストする必要はありますか？

ネットワークの場合、検証セットと同じように見えないデータであり、両方の数も同じであるため、テストセットのエラーは検証セットと同じではありませんか？

代わりに、テストセットをマージしてトレーニングセットを増やし、トレーニングデータを増やしてネットワークトレーニングを改善し、検証セットを使用してオーバーフィットを防ぐことはできませんか？なぜこれをしないのですか？

パフォーマンスがハイパーパラメーターのセットに依存するモデルをトレーニングしていると仮定しましょう。ニューラルネットワークの場合、これらのパラメーターは、たとえば学習率やトレーニングの反復回数などです。

ハイパーパラメーター値の選択肢が与えられたら、トレーニングセットを使用してモデルをトレーニングします。しかし、ハイパーパラメーターの値をどのように設定しますか？それが検証セットの目的です。これを使用して、ハイパーパラメータ値のさまざまな組み合わせについてモデルのパフォーマンスを評価し（グリッド検索プロセスなど）、最適なトレーニング済みモデルを維持できます。

しかし、選択したモデルは他の異なるモデルとどのように比較されますか？あなたのニューラルネットワークは、同じトレーニング/テストデータの組み合わせでトレーニングされたランダムフォレストよりもパフォーマンスが良いですか？検証セットはモデルのフィッティングの一部であるため、検証セットに基づいて比較することはできません。これを使用して、ハイパーパラメーター値を選択しました！

このテストセットを使用すると、トレーニング/ハイパーパラメーター選択プロセスのどの部分でも使用されなかったデータに基づいて比較を行うことにより、さまざまなモデルを公平に比較​​できます。

テストセットとクロス検証セットには異なる目的があります。どちらかを落とすと、その利点を失います：

• 交差検証セットは、過剰適合の検出を支援し、ハイパーパラメーター検索を支援するために使用されます。

• テストセットは、モデルのパフォーマンスを測定するために使用されます。

クロス検証セットを使用してモデルのパフォーマンスを正確に測定することはできません。これは、結果を意図的に調整して、おそらく数百のパラメーターのバリエーションにわたって可能な限り最良のメトリックを取得するためです。したがって、相互検証の結果は楽観的すぎる可能性があります。

同じ理由で、相互検証セットを削除して、ハイパーパラメーターを選択するためにテストセットを使用することはできません。モデルがどれだけ優れているかを過大評価することがほぼ確実であるためです。理想的な世界では、テストセットを1回だけ使用するか、「ニュートラル」な方法で使用して異なる実験を比較します。

相互検証を行い、最適なモデルを見つけて、テストデータを追加してトレーニングを行うと、モデルが改善される可能性があります（場合によっては、おそらく非常に可能性が高い）。ただし、それが実際に発生したかどうかを確認する方法はなく、たとえ発生したとしても、新しいパフォーマンスが何であるかについて公平な推定値はありません。

多くのKaggleコンペティションを目の当たりにして、私の経験では、テストセットを使いすぎて調整することは本物であり、それらのコンペティションに大きな影響を与えます。クロス検証についてはそれほど徹底的ではないが、パブリックリーダーボードに登り、テストでベストモデルを選択した競合他社のグループがしばしば存在します（パブリックリーダーボードは事実上テストセットです）。。。これらの競合他社は、新しいテストセットが最後に導入されたときにリーダーボードをドロップダウンします。

妥当なアプローチの1つは、テストする前に、見つけたハイパーパラメーターを使用して（train + cv）データを再利用することです。そうすれば、より多くのデータでトレーニングを行うことができ、最後にパフォーマンスの独立した測定値を取得できます。

相互検証をさらに活用したい場合、通常のアプローチはk-fold cross validationです。Kaggleコンペティションの一般的なトリックは、k倍交差検証を使用し、データをより大きな（train + cv）トレーニングセットに再結合する代わりに、cv結果をメタモデルにアンサンブルまたはスタックすることです。

最後に、検証およびテスト用の分割が、データセット内で発生する可能性のある相関に対して堅牢であることを常に確認します。