モデル選択後の相互検証（エラーの一般化）

注：ケースはn >> pです

統計学習の要素を読んでいますが、相互検証を行う「正しい」方法についてさまざまな言及があります（60ページ、245ページなど）。具体的には、私の質問は、モデル検索が行われたときに、k分割CVまたはブートストラップを使用して最終モデルを評価する方法です（個別のテストセットなし）。ほとんどの場合（組み込み機能選択なしのMLアルゴリズム）、

1. 機能選択ステップ
2. メタパラメーターの選択手順（SVMのコストパラメーターなど）。

私の質問：

1. トレーニングセット全体で機能の選択を行い、脇に置いて、機能の選択手順を実行できることを確認しました。次に、kフォールドCVを使用して、特徴選択アルゴリズムが各フォールドで使用され（場合によっては毎回選択される異なる特徴を取得）、エラーが平均化されます。次に、すべてのデータ（確保された）を使用して選択された機能を使用して最終モードをトレーニングしますが、クロス検証からのエラーをモデルの将来のパフォーマンスの推定値として使用します。これは正しいです？
2. クロス検証を使用してモデルパラメーターを選択する場合、モデルのパフォーマンスを後で推定する方法は？上記の＃1と同じプロセスですか、54ページ（pdf）または他の何かに示されているようなネストされたCVを使用する必要がありますか？
3. 両方のステップ（機能とパラメーターの設定）を実行しているとき.....その後、何をしますか？複雑なネストされたループ？
4. 別のホールドアウトサンプルがある場合、懸念はなくなり、クロス検証を使用して機能とパラメーターを選択できます（パフォーマンスの見積もりはホールドアウトセットから取得されるため、心配する必要はありません）？

覚えておくべき重要なことは、交差検証では、（ほぼ）公平なパフォーマンス推定値を提供するために、モデルの適合に関係するすべてのステップも、交差検証手順の各フォールドで独立して実行する必要があるということです。最適な方法は、機能の選択、メタ/ハイパーパラメーター設定、およびパラメーターの最適化をモデルフィッティングの不可欠な部分として表示し、他の2つを実行せずにこれらのステップを実行しないことです。

そのレシピから逸脱することで導入できる楽観的なバイアスは、CawleyとTalbotが示すように驚くほど大きくなる可能性があります。さらに悪い偏りのあるプロトコルは、ハイパーパラメーターの調整に対してより敏感であり、したがってモデル選択基準を過剰適合しやすいため、不良モデルを最も強く支持します！

特定の質問への回答：

ステップ1の手順は、特徴の選択が各フォールドで個別に実行されるため有効です。そのため、交差検証するのは、最終モデルに適合するために使用される手順全体です。各フォールドのデータセットは最終モデルに使用されるデータセット全体よりもわずかに小さいため、相互検証の推定にはわずかな悲観的なバイアスがあります。

2では、交差検証を使用してモデルパラメーターを選択するため、パフォーマンス推定に使用される交差検証の各フォールドで独立してその手順を繰り返す必要があり、ネストされた交差検証になります。

3の場合、基本的には、ネストされたネストされたクロス検証を行う必要があります。基本的に、最終モデルに適合するために行うことを意図したすべての最外部の交差検証（パフォーマンス推定に使用）の各フォールドで繰り返す必要があります。

4-はい、別個のホールドアウトセットがある場合、追加の相互検証を必要とせずに、パフォーマンスの公平な推定が得られます。

私は、取得するのに数百万の費用がかかるデータセットで広範なクロスバリデーション分析を行ってきましたが、利用可能な外部バリデーションセットはありません。この場合、妥当性を確認するために、広範囲にネストされた相互検証を実行しました。各トレーニングセットからのみ機能と最適化されたパラメーターを選択しました。これは、大きなデータセットの場合は計算コストがかかりますが、有効性を維持するために私がしなければならなかったことです。ただし、それに伴う合併症があります。たとえば、各トレーニングセットで異なる機能が選択されます。

したがって、私の答えは、外部データセットへの実行可能なアクセス権がない場合、これは妥当な方法です。外部データセットがある場合、メインデータセットで必要に応じて街に行くことができ、外部データセットで1回テストできます。