相互検証後の「テスト」データセットの使用方法

私が見たいくつかの講義やチュートリアルでは、データを3つの部分（トレーニング、検証、テスト）に分割することを提案しています。しかし、テストデータセットの使用方法や、このアプローチがデータセット全体の相互検証よりも優れている方法は明確ではありません。

データの20％をテストセットとして保存したとします。次に、残りを取得してk分割し、交差検証を使用して、このデータセットの未知のデータに対して最適な予測を行うモデルを見つけます。私たちが見つけた最良のモデルは、75％の精度を提供するとしましょう。

さまざまなQ＆A Webサイトのさまざまなチュートリアルと多くの質問から、保存された（テスト）データセットでモデルを検証できるようになりました。しかし、それがどの程度正確に行われているのか、それが何の要点なのかはまだわかりません。

テストデータセットの精度が70％であるとします。 それでは、次に何をしますか？テストデータセットで高いスコアを取得するまで、別のモデルを試し、次に別のモデルを試しますか？しかし、この場合、限られた（20％のみ）テストセットに適合するモデルを見つけるだけのように見えます。一般的に最適なモデルを見つけるという意味ではありません。

さらに、限られたデータセットでのみ計算される場合、このスコアをモデルの一般的な評価としてどのように考えることができますか？このスコアが低い場合は、不運で「不良」なテストデータを選択した可能性があります。

一方、所有しているすべてのデータを使用してからk分割交差検証を使用してモデルを選択すると、所有しているデータセット全体の未知のデータに対して最適な予測を行うモデルが見つかります。

これは、相互検証とテストセットに関する別の質問に似ています。ここで理解する重要な概念は、独立したデータセットです。次の2つのシナリオを検討してください。

1. 多くのリソースがある場合は、理想的には1つのデータセットを収集し、相互検証によりモデルをトレーニングします。次に、完全に独立した別のデータセットを収集して、モデルをテストします。ただし、前述したように、これは通常、多くの研究者にとって不可能です。

さて、もし私が幸運でない研究者であるならば、私は何をしますか？まあ、あなたはその正確なシナリオを模倣しようとすることができます：

2. モデルのトレーニングを行う前に、データの一部を取り、それを脇に置いておきます（相互検証中に触れないでください）。これは、上記の理想的なシナリオで述べたのとまったく同じ独立したデータセットをシミュレートすることです。同じデータセットから取得された場合でも、モデルトレーニングはそれらのサンプルから情報を取得しません（クロス検証ではすべてのデータが使用されます）。モデルのトレーニングが完了したら、それをテストセットに適用します。これもトレーニング中には見ら​​れなかったため、結果が得られます。これは、モデルをより一般化し、データを学習しただけではないことを確認するために行われます。

他の懸念に対処するには：

テストデータセットの精度が70％であるとします。次に何をしますか。テストデータセットでハイスコアを取得するまで、他のモデルを試し、次に他のモデルを試しますか？

並べ替え、アイデアは、あなたがあなたのデータからあなたができる最高のモデルを作成し、それまでに見たことのないいくつかのデータでそれを評価しているということです。交差検証スキームを再評価できますが、調整されたモデル（ハイパーパラメーター）を作成したら、そのモデルが最善だったため、そのモデルを使用して前進します。重要なのは、テストデータをチューニングに使用しないことです。テストデータの結果は、「一般」データに対するモデルのパフォーマンスです。このプロセスを複製すると、データセットの独立性が失われます（これがポイントでした）。これは、テスト/検証データに関する別の質問でも対応しています。

また、限られたデータセットで計算された場合、このスコアをモデルの一般的な評価としてどのように考えることができますか？このスコアが低い場合、「悪い」テストデータを選択できなかった可能性があります。

データを正しく分割している場合、これはほとんどありません。データをランダムに分割する必要があります（ただし、クラスバランシングのために層化される可能性があります）。データセットが十分に大きく、データを3つの部分に分割する場合、テストサブセットは、不良データを選択した可能性が非常に低くなるように十分大きくする必要があります。モデルが過剰適合している可能性が高くなります。

未処理のデータセットまたは最小限に前処理されたデータセットのデフォルト設定でモデルをトレーニングするだけの場合（ワンホットエンコードやNAの削除など）、別のテストセットは必要ありません。検証セットでセットをトレーニングしてテストするか、さらに良いことに、クロス検証を使用してセット全体でトレーニングを行い、パフォーマンスを推定します。

ただし、データに関する知識が元の戦略から変更を加えるとすぐに、結果が「汚染」されます。以下に例を示します。

• モデルの選択：ロジスティック、投げ縄、ランダムフォレスト、XGBoost、およびサポートベクターマシンをテストし、最適なモデルを選択しました

• パラメーターの調整：XGBoostを調整して、最適なハイパーパラメーターを見つけました

• 特徴選択：後方選択、遺伝的アルゴリズム、ボルタなどを使用して、モデルに含める特徴の最適なサブセットを選択しました

• 欠損補完：欠損変数を平均で補完したか、他の変数に基づいた単純なモデルで補完しました

• フィーチャ変換：数値変数を中央揃えおよびスケーリングして、それらをzスコア（平均からの標準偏差の数）に置き換えました

上記のすべてのケースで、単一のホールドアウトセットまたはクロス検証を使用しても、実際のパフォーマンスの現実的な推定値は得られません。これは、意思決定において将来のデータにない情報を使用しているためです。代わりに、データに最適なモデル、最適なハイパーパラメーター、最適な機能セットなどを選択し、データに戦略をわずかに「オーバーフィット」させる可能性があります。実世界のパフォーマンスの正直な見積もりを得るには、意思決定プロセスにまったく入らなかったデータでスコアリングする必要があります。したがって、トレーニング（モデリング）および検証（テスト）とは別に独立したテストセットを使用する一般的な方法です。モデル、機能、ハイパーパラメータなどの選択）セット。

テストセットを保持する代わりに、ネストされた相互検証と呼ばれる手法を代わりに使用できます。これには、モデリング戦略全体（変換、代入、特徴選択、モデル選択、ハイパーパラメーターチューニング）をノンパラメトリック関数としてコーディングし、その関数全体で単純にモデルフィット関数であるかのように相互検証を実行する必要があります。これはほとんどのMLパッケージでは困難ですが、ラッパーを使用してトレーニング戦略を定義し、ラップされた学習者をリサンプリングすることで、mlrパッケージを使用してRに非常に簡単に実装できます。

https://mlr.mlr-org.com/articles/tutorial/nested_resampling.html

私はあなたが分類をしていると仮定しています。

データを取得して、70/30をtrainingData / testDataサブセットに分割します。trainingDataサブセットを取得して、再び70/30をtrainingData / validateDataサブセットに分割します。これで、元のデータの3つのサブセット-trainingData（.7 * .7）、validateData（.7 * .3）、およびtestData（.3）ができました。

trainingDataを使用してモデルをトレーニングします。次に、validateDataを使用してそのモデルのパフォーマンスを確認します。validateDataは、trainingDataから独立していると考えることができるため、モデルがどの程度一般化されているかを適切に評価できます。75％の精度を達成したとしましょう。

ここで、モデルを任意の回数再トレーニングします。再トレーニングのたびに、異なるハイパーパラメーターのセット（最初にモデルに供給されるパラメーターとモデルが最適化されるパラメーター）を評価していますが、それでもtrainingDataサブセットを使用しています。また、再トレーニングのたびに、validateDataのパフォーマンスをチェックすることにより、新しいモデルが一般化されているかどうかも確認します。

評価することを意味するハイパーパラメーターのすべての組み合わせを確認したら、validateDataで最高のパフォーマンスが得られるハイパーパラメーターのセットを選択します。validateDataで最高のパフォーマンスが80％の精度であるとしましょう。これらは最終的なハイパーパラメーターであり、これらのハイパーパラメーターによって定義されたモデルは、この次のステップで使用するものです。

ここで、最終的なハイパーパラメーターを使用するモデルを取得し、testDataを評価します。このプロセス全体が開始されて以来、testDataに触れたのはこれが初めてです。validateDataでのパフォーマンスに匹敵するtestDataのパフォーマンスが得られた場合（通常はわずかに低下しますが）、モデルが期待どおりに機能し、一般化できると確信できます！その場合は、これが最終モデルです！

なぜこれがすべてなのか？過剰適合を避けようとしています。モデルのトレーニングと調整（検証）を行っているときに、使用するデータに過剰適合しているというリスクが常にあります。1つのデータセットのみを使用してトレーニング、調整（検証）、およびテストを行うと、そのデータが過剰に適合し、十分に一般化されない可能性が高くなります。トレーニングデータとテストデータのセットを分割することで（そしてテストデータを使用して調整すると仮定して）、内部的に自分自身をチェックする機会がありますが、テストデータをオーバーフィットしている可能性があります。そのため、3番目のデータセットを検証して検証します。そのため、内部的に正直に保つための追加レイヤーがあります。validateDataを使用して調整することで、trainingDataに過剰適合しないようにします。testDataを使用した最終テストにより、validateDataへの過剰適合を防ぎます。

次のように見てみましょう

1. 一般的な方法

   a）トレーニングデータ-モデルパラメーターの選択に使用。

    i) E.g., finding intercept and slope parameters for an ordinary linear 
       regression model. 
   
    ii) The noise in the training data-set is used in some extent 
        in over-fitting model parameters. 
   

   b）検証データ-ハイパーパラメーターの選択に使用されます。

    i)  E.g., we may want to test three different models at step 1.a, say 
        linear model with one, two or three variables.   
   
    ii) The validation data-set is independent from training data, and thus, they provide 
        'unbiased' evaluation to the models, which help to decide which 
        hyper-parameter to use. 
   
    iii) We note that, a model trained in 1.a, say y = b_0+b_1*x_1, does 
        not learn anything from this data-set. So, the noise in this data- 
        set is not used to over-fit the parameters (b_0, b_1), but, over- 
        fit exists in choosing which linear model to use (in terms of 
        number of variables). 
   

   c）テストデータ-上記の2つのステップからの出力の信頼性を得るために使用

   i) Used once a model is completely trained
   

2. パート1を見る別の方法

   a）モデル候補プールは5次元セットです。つまり、

   i) Dimension 1: number of variables to keep in the regression model, 
      e.g., [1, 2, 3].
   
   ii) Dimension 2-5: (b_0, b_1, b_2, b_3). 
   

   b）ステップ1aは、モデルの候補を5次元から1次元に減らします。

   c）ステップ1bは、モデルの候補を1次元から0次元（単一モデル）に減らします。

   d）ただし、OPは、上記の「最終」出力がテストデータセットで十分に機能していないと考え、したがって、通常の線形回帰ではなくリッジ回帰を使用して、プロセス全体を再度やり直します。次に、テストデータセットが複数回使用されるため、このデータのノイズにより、線形回帰を使用するかリッジ回帰を使用するかを決定する際に過剰適合が生じる可能性があります。

   e）パラメーター、ハイパーパラメーター、モデルタイプ、および前処理方法を備えた高次元モデルプールを扱うために、利用可能なデータへの分割は、基本的に意思決定プロセスを定義します。

   i)  Sequentially reducing the model pool to zero-dimension.
   
   ii) Allocating data noise overfitting to different steps of dimension 
       reductions (overfitting the noise in the data is not avoidable but 
       could be allocated smartly). 
   

3. 結論とOPの質問への回答

   a）2分割（トレーニングとテスト）、3分割（トレーニング、検証、テスト）またはそれ以上の数の分割は、基本的に次元の削減とデータの割り当て（特にノイズと過剰適合のリスク）に関するものです。

   b）ある段階で、「最終的な」モデル候補プールを作成できます。次に、次元を順次減らすプロセスを次のように設計する方法を考えることができます。

   i) At each step of reducing the dimensions, the output is satisfactory, 
     e.g., not using just 10 data points with large noise to estimate a 
     six-parameter liner model. 
   
   ii) There are enough data for you to reduce the dimension to zero 
      finally. 
   

   c）bを達成できない場合

   i) Use model and data insight to reduce the overall dimensionality of 
     your model pool. E.g., liner regression is sensitive to outliers thus 
     not good for data with many large outliers. 
   
   ii) Choose robust non-parametric models or models with less number of 
      parameter if possible. 
   
   iii) Smartly allocating the data available at each step of reducing the 
       dimensionality. There is some goodness of fit tests to help us decide 
       whether the data we use to train the model is enough or not.